Bezpieczeństwo systemów AI: prompt injection, wyciek danych i jak się bronić

AI ma własną powierzchnię ataku

System oparty na modelu językowym dziedziczy wszystkie klasyczne zagrożenia aplikacji — i dokłada własne. Nowość polega na tym, że model wykonuje instrukcje zapisane w zwykłym tekście, a tekst przychodzi z wielu miejsc: od użytkownika, z dokumentów, ze stron, które model czyta. Granica między „danymi” a „poleceniem” się zaciera i to jest źródło większości nowych ryzyk.

Bezpieczeństwo AI nie zastępuje zabezpieczeń, które już masz. Dokłada do nich warstwę, o której trzeba myśleć osobno.

Trzy najważniejsze zagrożenia

Prompt injection. Prompt injection to wstrzyknięcie poleceń, które przejmują zachowanie modelu. Atak może być bezpośredni (użytkownik wpisuje „zignoruj poprzednie instrukcje”) albo pośredni — ukryty w dokumencie czy na stronie, którą model przetwarza. Ta druga odmiana jest groźniejsza, bo ofiara wcale nie musi być złośliwa.

Wyciek danych przez kontekst. Model widzi wszystko, co trafi do jego kontekstu. Jeśli wrzucisz tam dane wrażliwe albo treść promptu systemowego, odpowiednio skłoniony model może je powtórzyć użytkownikowi. To dotyczy też danych jednego klienta wyciekających do sesji drugiego.

Nadużycie narzędzi. Gdy model ma dostęp do narzędzi — bazy, API, wysyłki maili — przejęty przez injection potrafi ich użyć: usunąć rekord, wysłać wiadomość, pobrać dane. Im szersze uprawnienia, tym większa szkoda z jednego udanego ataku.

Zagrożenie i obrona

Zagrożenie	Na czym polega	Obrona
Prompt injection	Wstrzyknięte polecenia przejmują model	Filtry wejścia, oddzielenie danych od instrukcji, guardrails
Wyciek danych	Model powtarza dane z kontekstu	Izolacja sesji, minimalizacja kontekstu, kontrola prywatności
Nadużycie narzędzi	Atakujący wywołuje akcje przez model	Najmniejsze potrzebne uprawnienia, potwierdzenie człowieka
Halucynacja jako fakt	Model zmyśla i działa na zmyśleniu	Wymóg źródła, kontrola wyników przed akcją

Zasada operatora: traktuj każdy tekst, który model czyta, jak potencjalnie wrogi — także własne dokumenty. Bezpieczeństwo zaczyna się od założenia, że injection się uda.

Obrona jest warstwowa, nie pojedyncza

Nie ma jednego filtra, który załatwia sprawę. Guardrails na wejściu i wyjściu łapią część ataków, ale da się je obejść, więc są pierwszą warstwą, nie ostatnią. Pod nimi działają twardsze mechanizmy: ograniczenie uprawnień narzędzi do absolutnego minimum, izolacja danych między sesjami i klientami, logowanie każdego wywołania narzędzia oraz człowiek zatwierdzający decyzje o wysokim ryzyku.

Ta ostatnia warstwa jest kluczowa. Automatyzacja może przygotować akcję — wygenerować maila, zaproponować zmianę w bazie — ale przy realnym ryzyku ostateczne „wyślij” zostaje przy człowieku. To nie jest brak zaufania do systemu; to świadomy projekt, w którym jeden udany atak nie przekłada się od razu na szkodę.

Co to znaczy dla decyzji o wdrożeniu

Bezpieczeństwo nie jest etapem na końcu projektu. Wpływa na architekturę od początku: jakie dane w ogóle trafiają do kontekstu, jakie uprawnienia dostają narzędzia, gdzie wpina się człowiek. System, który ma robić cokolwiek poważnego, projektuje się od razu z tymi warstwami — domykanie ich później jest droższe i mniej skuteczne.