Gdzie standardy bezpieczeństwa AI się zatrzymują — i gdzie ochrona w czasie wykonywania musi się zacząć

Wśród wszystkich dyskusji na temat zagrożeń związanych z bezpieczeństwem AI, jeden problem wydaje się być pomijany: fakt, że systemy AI funkcjonują tylko poprzez ekspozycję ich najcenniejszych aktywów — modeli i danych.

W przeciwieństwie do tradycyjnego oprogramowania, AI nie wykonuje tylko predefiniowanej logiki. Ciągle łączy własne modele z wrażliwymi danymi wejściowymi, aby generować dane wyjściowe, często na infrastrukturze, która nie została zaprojektowana do ochrony obliczeń.

W ten sposób tradycyjne bezpieczeństwo jest niewystarczające. Szyfrowanie jest skuteczne, gdy dane są przechowywane lub przesyłane przez sieć, ale nie gdy dane są przetwarzane lub operowane. W przypadku AI szczególnie niebezpiecznie jest, gdy model jest wdrożony. Jego parametry są ładowane do pamięci, inicjowane i wykonywane w skali — punkt, w którym szyfrowanie się zatrzymuje — narażając je na potencjalny nieautoryzowany dostęp. Podczas inferencji wrażliwe dane przepływają przez ten sam narażony obszar. Wynikiem jest bardzo wrażliwa powierzchnia ryzyka: systemy AI, które mogą wydawać się bezpieczne — ale są tak naprawdę niechronione w najbardziej krytycznych momentach.

Organizacje takie jak National Institute of Standards and Technology (NIST), Europejska Agencja ds. Cyberbezpieczeństwa (dawniej znana jako Europejska Agencja ds. Bezpieczeństwa Sieci i Informacji, czyli ENISA) oraz Open Web Application Security Project (OWASP) zaczęły kartować to terytorium. Opisują zagrożenia, wymieniają słabości i określają zasady zarządzania. Ale nie przepisują, jak chronić modele jako własność intelektualną i dane jako poufne aktywa, gdy wykonywanie się zaczyna. Zamykanie tej luki wymaga przemyślenia bezpieczeństwa AI — nie jako ćwiczenia zgodności, ale jako problem obliczeń samych w sobie. To jest miejsce, w którym szyfrowanie w użyciu, czyli szyfrowanie od końca do końca, odgrywa rolę.

Ślepa plama w nowoczesnym bezpieczeństwie AI

Większość dyskusji o bezpieczeństwie AI nadal krąży wokół znajomej ziemi: zarządzania danymi szkoleniowymi, kontroli dostępu, monitorowania API oraz odpowiedzialnych polityk użytkowników. Są one konieczne. Jednak żadna z nich nie dotyka tego, co dzieje się po wdrożeniu, gdy model opuszcza repozytorium i staje się żywym systemem.

Gdy model jest wdrożony, jego parametry nie są już abstrakcyjnymi artefaktami. Są one żywe, mieszczące się w pamięci aktywa, ciągle dostępne podczas inferencji i często używane przez wielu najemców lub klientów za pośrednictwem współdzielonych usług AI. To narażenie występuje przed każdym żądaniem inferencji, zwiększając ryzyko przez wprowadzenie wrażliwych danych wejściowych i zewnętrznie obserwowalnego zachowania.

Traktowanie ochrony modelu jako problemu przed wdrożeniem i bezpieczeństwa inferencji jako problemu czasu wykonywania nie jest punktem. W rzeczywistych systemach te ryzyka się nakładają. Modele i dane są narażone na inicjowanie, wykonywanie i dane wyjściowe. Bezpieczeństwo, które zaczyna się i kończy na kontrolach przechowywania, nie rozwiązuje tych narażeń.

Co NIST robi dobrze — i gdzie się zatrzymuje

Ramowy program zarządzania ryzykiem AI NIST stał się kamieniem węgielnym dla organizacji próbujących zarządzać ryzykiem AI. Jego struktura — zarządzanie, mapowanie, pomiar, zarządzanie — oferuje zdyscyplinowany sposób myślenia o odpowiedzialności, kontekście, wpływie i łagodzeniu ryzyka na przestrzeni całego cyklu życia AI.

To, co NIST robi szczególnie dobrze, to ramy ryzyka AI jako systemowe, a nie przypadkowe. Awarie AI rzadko są jednorazowymi zdarzeniami; wynikają one z interakcji między modelami, danymi, ludźmi i infrastrukturą. To ujęcie jest niezbędne.

Tam, gdzie ramy są niewystarczające, jest brak dyktowania, jak cenne aktywa AI są chronione, gdy systemy są żywe. Parametry modelu są traktowane jako artefakty czasu projektowania, a nie aktywa czasu wykonywania. Środowiska wykonywania są zakładane jako wystarczająco godne zaufania.

W praktyce parametry modelu są często najcenniejszą własnością intelektualną, którą posiada organizacja. Są one ładowane do pamięci, kopiowane na węzły, buforowane i ponownie używane. Jeśli zarządzanie ryzykiem AI nie uwzględnia poufności modeli podczas wdrożenia i wykonywania, krytyczne aktywa pozostają poza granicą ryzyka, jak siedząca kaczka.

ENISA i rzeczywistość zagrożeń specyficznych dla AI

Praca ENISA nad cyberbezpieczeństwem AI pcha rozmowę dalej. Ich wielowarstwowa ramy rozróżniają między tradycyjnym bezpieczeństwem infrastruktury a ryzykiem specyficznym dla AI, uznając, że systemy AI zachowują się inaczej — i awaryjnie — niż konwencjonalne oprogramowanie.

Dlaczego jest to ważne? AI wprowadza zagrożenia, które nie mieszczą się ładnie w istniejących kontrolach: ekstrakcja modelu, wyciek parametrów, narażenie na współlokację i manipulację podczas wykonywania. Te ryzyka nie wymagają egzotycznych atakujących. Występują naturalnie, gdy cenne modele są uruchamiane w środowiskach współdzielonych lub zarządzanych zewnętrznie.

Ramka ENISA niejawnie uznaje, że zabezpieczanie AI oznacza zabezpieczanie zachowania, a nie tylko kodu. Ale jak większość standardów, koncentruje się na tym, co powinno być brane pod uwagę, a nie na tym, jak ochrona jest technicznie egzekwowana, gdy modele są uruchomione.

OWASP i koszt obserwowalnej inteligencji

OWASP Top 10 dla aplikacji dużych modeli językowych oferuje bardziej konkretny widok na to, jak systemy AI ulegają awariom w świecie rzeczywistym. Wstrzyknięcie promtu, ujawnienie informacji wrażliwych, wyciek osadzania, nadmierna przejrzystość danych wyjściowych — te nie są teoretycznymi problemami. Są one produktem ubocznym wdrożenia potężnych modeli bez ograniczania tego, co ujawniają.

Chociaż te problemy są często przedstawiane jako problemy warstwy aplikacji, ich konsekwencje są głębsze. Powtarzające się narażenie zachowania modelu może prowadzić do skutecznego klonowania; słabo odizolowane osadzanie może ujawnić strukturę; a nadużycie inferencji staje się ścieżką do replikacji modelu.

Taksonomia OWASP czyni jedno rzecz jasną: ochrona AI nie polega tylko na zatrzymaniu złych danych wejściowych. Chodzi o ograniczanie tego, co modele ujawniają — wewnętrznie i zewnętrznie — gdy są operacyjne.

Wspólny wniosek, niedokończona praca

Przez NIST, ENISA i OWASP istnieje szeroka zgoda co do podstaw:

• Ryzyko AI rozciąga się na cały cykl życia
• Systemy AI wprowadzają nowe kategorie zagrożeń
• Modele i dane są cennymi aktywami
• Narażenie w czasie wykonywania jest nieuniknione

Co te ramy brakuje, to mechanizm egzekwowania poufności, gdy modele są wdrożone i obliczenia się zaczynają. To pominięcie nie jest wadą, ponieważ standardy definiują intencję i zakres. Implementacja jest zwykle pozostawiona projektantowi systemu.

Ale pozostawiają krytyczną lukę — która rośnie, gdy systemy AI się skalują.

Szyfrowanie w użyciu zmienia równanie

Szyfrowanie w użyciu zmienia model bezpieczeństwa. Zamiast zakładać, że dane i modele muszą być narażone, aby być użyteczne, traktuje obliczenia jako coś, co można chronić.

W praktyce oznacza to:

• Modele pozostają zaszyfrowane podczas wdrożenia, inicjacji i wykonywania
• Dane wejściowe nigdy nie są widoczne w postaci jawnej w środowisku wykonywania
• Stanów pośrednich nie można inspekcjonować ani modyfikować
• Infrastruktura nie musi być domyślnie zaufana

To nie zastępuje ram zarządzania ani kontroli warstwy aplikacji — to operacjonalizuje je. Zamienia zasady ryzyka w egzekwowalne gwarancje w momencie, gdy systemy AI są najbardziej narażone.

Innymi słowy, szyfrowanie w użyciu jest brakującą warstwą między polityką AI a rzeczywistością AI.

Gdy zarządzanie kończy się, a wykonywanie się zaczyna: Zabezpieczanie obliczeń AI

Bezpieczeństwo AI się psuje w czasie wykonywania. Gdy są wdrożone, modele AI i wrażliwe dane muszą być narażone w pamięci, aby funkcjonować, tworząc powierzchnię ryzyka, której tradycyjne kontrole — szyfrowanie w spoczynku, szyfrowanie w transporcie i ramy zarządzania — nie były zaprojektowane do ochrony.

Organizacje takie jak NIST, ENISA i OWASP zrobiły krytyczny postęp w definiowaniu ryzyka AI, odpowiedzialności i nadużyć. Ale ich wskazówki w dużej mierze traktują modele jako artefakty czasu projektowania i zakładają, że środowiska wykonywania mogą być zaufane. W praktyce parametry modelu i wrażliwe dane wejściowe są ciągle dostępne, ponownie używane i często przetwarzane w środowiskach współdzielonych lub zarządzanych zewnętrznie.

Zamknięcie tej luki wymaga przemyślenia bezpieczeństwa AI nie jako ćwiczenia zgodności, ale jako problem ochrony obliczeń samych w sobie — gdy modele są żywe, dane są w użyciu i narażenie jest nieuniknione. Szyfrowanie w użyciu oferuje wiarygodny sposób, aby utrzymać modele AI i wrażliwe dane wejściowe bezpieczne na każdym etapie cyklu życia AI.