Gdzie kończą się standardy bezpieczeństwa AI — a musi zaczynać się ochrona czasu wykonania

Przy całej tej rozmowie o zagrożeniach bezpieczeństwa związanych z AI, jeden problem wydaje się być pomijany: fakt, że systemy AI funkcjonują tylko poprzez ujawnianie swoich najcenniejszych aktywów — modeli i danych.

W przeciwieństwie do tradycyjnego oprogramowania, AI nie wykonuje po prostu zdefiniowanej z góry logiki. Ciągle łączy zastrzeżone modele z wrażliwymi danymi wejściowymi, aby generować wyniki, często na infrastrukturze, która nie została zaprojektowana do ochrony obliczeń.

W ten sposób tradycyjne zabezpieczenia zawodzą. Szyfrowanie jest skuteczne, gdy dane są przechowywane lub przesyłane przez sieć, ale nie wtedy, gdy dane są przetwarzane lub wykorzystywane. W przypadku AI szczególne niebezpieczeństwo pojawia się, gdy model jest wdrożony. Jego parametry są ładowane do pamięci, inicjowane i wykorzystywane na dużą skalę – w tym momencie szyfrowanie się kończy – co naraża go na potencjalny nieautoryzowany dostęp. Podczas wnioskowania wrażliwe dane przepływają przez tę samą odsłoniętą przestrzeń. Rezultatem jest wysoce podatna powierzchnia ryzyka: systemy AI, które mogą wydawać się bezpieczne – ale w rzeczywistości są niechronione w najbardziej krytycznych momentach.

Organy standaryzacyjne, takie jak National Institute of Standards and Technology (NIST), European Union Agency for Cybersecurity (dawniej znana jako European Network and Information Security Agency, czyli ENISA) oraz Open Web Application Security Project (OWASP), zaczęły wytyczać ten teren. Opisują one ryzyka, nazywają podatności i zarysowują zasady zarządzania. Ale zatrzymują się przed wskazaniem, jak chronić modele jako własność intelektualną i dane jako aktywa poufne, gdy rozpoczyna się wykonanie. Wypełnienie tej luki wymaga przemyślenia bezpieczeństwa AI – nie jako ćwiczenia z zgodności, ale jako problemu samego obliczenia. Tutaj właśnie rolę odgrywa szyfrowanie w użyciu, czyli szyfrowanie end-to-end.

Martwy punkt we współczesnym bezpieczeństwie AI

Większość rozmów o bezpieczeństwie AI wciąż krąży wokół znanego terenu: zarządzanie danymi treningowymi, kontrola dostępu, monitorowanie API i odpowiedzialne polityki 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.

Po wdrożeniu parametry modelu przestają być abstrakcyjnymi artefaktami. Stają się one aktywnymi, rezydującymi w pamięci aktywami, do których ciągle się dostępuje podczas wnioskowania i które są często używane przez wielu najemców lub klientów poprzez współdzielone usługi AI. To odsłonięcie następuje jeszcze przed złożeniem jakiegokolwiek żądania wnioskowania, potęgując tym samym ryzyko poprzez wprowadzenie wrażliwych danych wejściowych i zewnętrznie obserwowalnego zachowania.

Traktowanie ochrony modelu jako kwestii przedwdrożeniowej, a bezpieczeństwa wnioskowania jako kwestii czasu wykonania, jest nietrafione. W rzeczywistych systemach te ryzyka nakładają się na siebie. Modele i dane są odsłonięte podczas inicjalizacji, wykonania i generowania wyników. Zabezpieczenia, które zaczynają się i kończą na kontrolach przechowywania, nie rozwiązują tych ekspozycji.

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ądzaj, mapuj, mierz, zarządzaj — oferuje zdyscyplinowany sposób myślenia o odpowiedzialności, kontekście, wpływie i łagodzeniu ryzyka w całym cyklu życia AI.

To, co NIST robi szczególnie dobrze, to ujmowanie ryzyka AI jako systemowego, a nie przypadkowego. Awarie AI rzadko są zdarzeniami punktowymi; wyłaniają się z interakcji między modelami, danymi, ludźmi i infrastrukturą. To ujęcie jest kluczowe.

Miejsce, w którym ramy zawodzą, to brak dyrektyw, jak chronić wysokowartościowe aktywa AI, gdy systemy są uruchomione. Parametry modelu są domyślnie traktowane jako artefakty fazy projektowej, a nie jako aktywa czasu wykonania. Zakłada się, że środowiska wykonawcze są wystarczająco godne zaufania.

W praktyce parametry modelu są często najcenniejszą własnością intelektualną, jaką posiada organizacja. Są one ładowane do pamięci, kopiowane między węzłami, buforowane i ponownie wykorzystywane. Jeśli zarządzanie ryzykiem AI nie uwzględnia poufności modeli podczas wdrażania i wykonywania, kluczowy składnik pozostaje poza granicą ryzyka, jak przysłowiowe siedzące kaczki.

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

Praca ENISA nad cyberbezpieczeństwem AI posuwa rozmowę dalej. Jej wielowarstwowe ramy rozróżniają między tradycyjnym bezpieczeństwem infrastruktury a ryzykami specyficznymi dla AI, uznając, że systemy AI zachowują się inaczej — i zawodzą inaczej — niż konwencjonalne oprogramowanie.

Dlaczego to ważne? AI wprowadza zagrożenia, które nie mieszczą się schludnie w istniejących kontrolach: ekstrakcja modelu, wyciek parametrów, ekspozycja współdzielenia (co-tenancy) oraz manipulacja podczas wykonania. Te ryzyka nie wymagają egzotycznych atakujących. Powstają one naturalnie, gdy wysokowartościowe modele działają w środowiskach współdzielonych lub zarządzanych zewnętrznie.

Ramy ENISA domyślnie uznają, że zabezpieczenie AI oznacza zabezpieczenie zachowania, a nie tylko kodu. Ale jak większość standardów, skupiają się one na tym, co należy wziąć pod uwagę, a nie na tym, jak technicznie egzekwować ochronę, gdy modele już działają.

OWASP i koszt obserwowalnej inteligencji

Top 10 OWASP dla aplikacji dużych modeli językowych oferuje bardziej konkretny obraz tego, jak systemy AI zawodzą w rzeczywistym świecie. Iniekcja promptów, ujawnianie poufnych informacji, wyciek embeddingów, nadmierna przejrzystość wyników — to nie są teoretyczne obawy. Są one produktami ubocznymi wdrażania potężnych modeli bez ograniczania tego, co ujawniają.

Chociaż te kwestie są często przedstawiane jako problemy warstwy aplikacyjnej, ich konsekwencje są głębsze. Powtarzająca się ekspozycja zachowania modelu może prowadzić do skutecznego klonowania; słabo odizolowane embeddingi mogą ujawniać strukturę; a nadużycia wnioskowania stają się drogą do replikacji modelu.

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

Wspólny wniosek, niedokończona praca

Wśród NIST, ENISA i OWASP panuje szeroka zgoda co do podstaw:

• Ryzyko AI obejmuje cały cykl życia
• Systemy AI wprowadzają nowe kategorie zagrożeń
• Modele i dane są wysokowartościowymi aktywami
• Ekspozycja czasu wykonania jest nieunikniona

Czego jednak brakuje tym ramom, to mechanizmu egzekwowania poufności, gdy modele są wdrożone i rozpoczyna się obliczanie. To pominięcie nie jest wadą, ponieważ standardy definiują intencje i zakres. Implementacja jest zazwyczaj pozostawiona projektantowi systemu.

Ale pozostawiają one krytyczną lukę — która powiększa się, gdy systemy AI się skalują.

Szyfrowanie w użyciu zmienia równanie

Szyfrowanie w użyciu przesuwa model bezpieczeństwa. Zamiast zakładać, że dane i modele muszą być odsłonięte, aby były użyteczne, traktuje ono obliczenia jako coś, co można chronić.

W praktyce oznacza to:

• Modele pozostają zaszyfrowane podczas wdrażania, inicjalizacji i wykonania
• Dane wejściowe nigdy nie są widoczne w postaci jawnej dla środowiska wykonawczego
• Stany pośrednie nie mogą być badane ani modyfikowane
• Infrastruktura nie musi już być domyślnie zaufana

To nie zastępuje ram zarządzania ani kontroli warstwy aplikacyjnej – wdraża je. Zamienia zasady ryzyka w egzekwowalne gwarancje dokładnie wtedy, gdy systemy AI są najbardziej podatne.

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

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

Bezpieczeństwo AI załamuje się w czasie wykonania. Po wdrożeniu modele AI i wrażliwe dane muszą być odsłonięte w pamięci, aby funkcjonować, tworząc powierzchnię ryzyka, której tradycyjne kontrole — szyfrowanie danych w spoczynku, szyfrowanie danych w ruchu i ramy zarządzania — nigdy nie były zaprojektowane do ochrony.

Organy standaryzacyjne, takie jak NIST, ENISA i OWASP, poczyniły kluczowe postępy w definiowaniu ryzyka AI, odpowiedzialności i nadużyć. Ale ich wytyczne w dużej mierze traktują modele jako artefakty fazy projektowej i zakładają, że środowiskom wykonawczym można ufać. W praktyce parametry modelu i wrażliwe dane wejściowe są ciągle dostępne, ponownie wykorzystywane i często przetwarzane w środowiskach współdzielonych lub zarządzanych zewnętrznie.

Wypełnienie tej luki wymaga przemyślenia bezpieczeństwa AI nie jako ćwiczenia z zgodności, ale jako problemu ochrony samego obliczenia — gdy modele są aktywne, dane są w użyciu, a ekspozycja jest nieunikniona. Szyfrowanie w użyciu oferuje realny sposób na utrzymanie bezpieczeństwa modeli AI i wrażliwych danych wejściowych na każdym etapie cyklu życia AI.