Gdzie standardy zabezpieczeń AI się kończą — i gdzie ochrona w czasie wykonywania musi się zacząć

Wraz z całym rozgłosem o ryzyku związanym z AI, jeden problem wydaje się być pomijany: fakt, że systemy AI działają tylko poprzez eksponowanie ich najcenniejszych aktywów — modeli i danych.

W przeciwieństwie do tradycyjnego oprogramowania, AI nie wykonuje po prostu 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 zabezpieczenia są 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 dużym stopniu — w momencie, w którym szyfrowanie się kończy — narażając je na potencjalny nieautoryzowany dostęp. Podczas inferencji wrażliwe dane przepływają przez ten sam eksponowany 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, lub ENISA) oraz Open Web Application Security Project (OWASP) zaczęły chartować to terytorium. Opisują ryzyko, nazywają 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 zabezpieczeń AI — nie jako ćwiczenia zgodności, ale jako problem obliczeń samych w sobie. To jest miejsce, w którym szyfrowanie w użyciu, lub szyfrowanie końcowe, odgrywa rolę.

Ślepa plama w nowoczesnym zabezpieczeniu AI

Większość rozmów o zabezpieczeniu 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 rozwiązuje tego, co dzieje się po wdrożeniu, gdy model opuszcza repozytorium i staje się żywym systemem.

Gdy model zostaje wdrożony, jego parametry nie są już abstrakcyjnymi artefaktami. Są one żywymi, mieszczącymi się w pamięci aktywami, ciągle dostępnymi podczas inferencji i często używanymi 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, powodując zwiększenie ryzyka przez wprowadzenie wrażliwych danych wejściowych i zewnętrznie obserwowalnego zachowania.

Traktowanie ochrony modelu jako problemu przed wdrożeniem i zabezpieczeń inferencji jako problemu czasu wykonywania pomija punkt. W rzeczywistych systemach te ryzyka się nakładają. Modele i dane są narażone na inicjalizację, wykonywanie i dane wyjściowe. Zabezpieczenia, które zaczynają się i kończą kontrolami magazynowania, nie rozwiązują tych narażeń.

Co NIST robi dobrze — i gdzie się kończy

Ramowy NIST AI Risk Management Framework stał się kamieniem węgielnym dla organizacji próbujących zarządzać ryzykiem AI. Jego struktura — rządzą, mapuj, mierz, zarządzaj — oferuje zdyscyplinowany sposób myślenia o odpowiedzialności, kontekście, wpływie i łagodzeniu na całym cyklu życia AI.

Co NIST robi szczególnie dobrze, to ramy ryzyka AI jako systemowego, a nie przypadkowego. Awarie AI rzadko są jednopunktowymi zdarzeniami; pojawiają się one z interakcji między modelami, danymi, ludźmi i infrastrukturą. To ramowanie jest niezbędne.

Gdzie ramowy się kończy, to w nieokreśleniu, jak chronić cenne aktywa AI, gdy systemy są żywe. Parametry modelu są niejawnie traktowane jako artefakt czasu projektowania, a nie aktywa czasu wykonywania. Środowiska wykonywania są uznawane za 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, krytyczny aktyw pozostaje poza granicą ryzyka, jak siedząca kaczka.

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

Praca ENISA nad cyberbezpieczeństwem AI prowadzi rozmowę dalej. Ich wielowarstwowa ramowa rozróżnia między tradycyjnym zabezpieczeniem 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 manipulacja podczas wykonywania. Te ryzyka nie wymagają egzotycznych atakujących. Pojawiają się one naturalnie, gdy cenne modele są uruchamiane w środowiskach współdzielonych lub zarządzanych zewnętrznie.

Ramowa ENISA niejawnie uznaje, że zabezpieczenie AI oznacza zabezpieczenie 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ą uruchamiane.

OWASP i koszt obserwowalnej inteligencji

OWASP’s Top 10 for Large Language Model applications oferuje bardziej konkretny widok na to, jak systemy AI ulegają awarii w świecie rzeczywistym. Wstrzyknięcie promtu, ujawnienie informacji poufnych, 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 jedną rzecz jasną: ochrona AI nie polega tylko na zatrzymaniu złych danych wejściowych. Chodzi o ograniczenie 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 na podstawy:

• Ryzyko AI obejmuje 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ę — jedną, która rośnie, gdy systemy AI się skalują.

Szyfrowanie w użyciu zmienia równanie

Szyfrowanie w użyciu przesuwa model zabezpieczeń. Zamiast zakładać, że dane i modele muszą być eksponowane, aby być użytecznymi, traktuje obliczenia jako coś, co można chronić.

W praktyce oznacza to:

• Modele pozostają zaszyfrowane podczas wdrożenia, inicjalizacji i wykonywania
• Dane wejściowe nigdy nie są widoczne w postaci jawnej dla środowiska wykonywania
• Stanów pośrednich nie można inspekcjonować ani modyfikować
• Infrastruktura nie musi być implicite ufań

To nie zastępuje ram zarządzania ani kontroli warstwy aplikacji — to operacjonalizuje je. To zmienia 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: Zabezpieczenie obliczeń AI

Zabezpieczenie AI ulega awarii w czasie wykonywania. Gdy są wdrożone, modele AI i wrażliwe dane muszą być eksponowane w pamięci, aby funkcjonować, tworząc powierzchnię ryzyka, której tradycyjne kontrole — szyfrowanie w spoczynku, szyfrowanie w transmisji i ramy zarządzania — nie został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 wytyczne w dużej mierze traktują modele jako artefakty czasu projektowania i zakładają, że środowiska wykonywania mogą być ufań. 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 zabezpieczeń AI nie jako ćwiczenia zgodności, ale jako problem ochrony obliczeń samych w sobie — gdy modele są żywe, dane są w użyciu, a narażenie jest nieuniknione. Szyfrowanie w użyciu oferuje sposób na utrzymanie modeli AI i wrażliwych danych wejściowych w bezpieczeństwie na każdym etapie cyklu życia AI.