Testy adwersarialne AI: od ataku do odporności

Od ataku do odporności: dlaczego testy adwersarialne to nowy standard jakości w tworzeniu systemów AI

Jeszcze kilka lat temu testy adwersarialne AI kojarzyły się głównie z badaniami akademickimi. Eksperymenty polegające na niewielkiej zmianie pikseli obrazu, która prowadziła do całkowicie błędnej klasyfikacji, były fascynującym przykładem ograniczeń modeli uczenia maszynowego, ale często traktowano je jako problem interesujący przede wszystkim naukowców.

Dzisiaj sytuacja wygląda zupełnie inaczej. Modele uczenia maszynowego wspierają decyzje w medycynie, finansach, przemyśle, cyberbezpieczeństwie, logistyce, administracji i transporcie. Analizują obrazy, wykrywają anomalie, klasyfikują dokumenty, oceniają ryzyko transakcji, filtrują treści i coraz częściej stają się elementem procesów mających bezpośredni wpływ na rzeczywisty świat.

W takim środowisku nie wystarczy już pytać, jak dokładny jest model w warunkach laboratoryjnych. Znacznie ważniejsze staje się pytanie, jak zachowa się system, jeżeli ktoś celowo spróbuje doprowadzić go do błędnej decyzji.

Właśnie w tym miejscu zaczynają się testy adwersarialne. O samych mechanizmach tego rodzaju manipulacji pisałam już wcześniej w artykule Ataki adwersarialne jako ciche zagrożenie dla systemów Sztucznej Inteligencji. Ten tekst idzie o krok dalej: zamiast koncentrować się wyłącznie na samym zagrożeniu, przyjrzymy się temu, w jaki sposób testowanie odporności modeli może stać się elementem profesjonalnego procesu Quality Assurance.

Jeżeli natomiast potrzebujesz uporządkowania podstawowych pojęć i zależności pomiędzy AI, Machine Learning, Deep Learning, NLP i LLM, dobrym wprowadzeniem jest również wpis AI, ML, DL, NLP i LLM – mapa powiązań.

Czym są testy adwersarialne AI?

Klasyczne testowanie modeli uczenia maszynowego zakłada zazwyczaj, że dane testowe mają odzwierciedlać rzeczywiste warunki działania systemu. Mierzymy accuracy, precision, recall, F1-score, false positive rate czy inne wskaźniki właściwe dla danego problemu, a następnie oceniamy, czy wyniki spełniają wymagania biznesowe i techniczne.

Takie podejście jest konieczne, ale nie uwzględnia jednego istotnego elementu: przeciwnika. Napastnik nie zachowuje się jak losowy generator błędów. Obserwuje system, analizuje jego zachowanie, szuka granic decyzyjnych i próbuje znaleźć taki zestaw danych wejściowych, który spowoduje niepożądany rezultat. Jeżeli ma możliwość wielokrotnego testowania modelu, może również stopniowo dostosowywać swoją strategię.

Test adwersarialny polega więc nie tylko na sprawdzeniu, czy model działa poprawnie, lecz na celowym poszukiwaniu sposobów, w których może zostać zmuszony do działania niezgodnego z założeniami.

NIST opisuje ten obszar jako Adversarial Machine Learning i wyróżnia między innymi ataki typu evasion, poisoning, privacy oraz – w kontekście generatywnej AI – misuse. Bezpieczeństwo modeli nie jest już traktowane jako odrębna ciekawostka badawcza, ale jako element zarządzania ryzykiem AI w całym cyklu życia systemu.

Dobrym punktem odniesienia jest publikacja NIST AI 100-2e2025: Adversarial Machine Learning – A Taxonomy and Terminology of Attacks and Mitigations.

Evasion attack – kiedy poprawnie działający model zaczyna się mylić

Jedną z najczęściej omawianych klas ataków jest evasion attack. Model został już wytrenowany i wdrożony, a napastnik nie zmienia jego parametrów ani danych treningowych. Manipuluje natomiast informacją przekazywaną do modelu podczas inferencji.

Może to być obraz, dźwięk, tekst, dane tabelaryczne albo dowolny inny typ wejścia. Modyfikacja bywa na tyle niewielka, że człowiek praktycznie jej nie zauważa, ale jednocześnie powoduje zmianę reprezentacji matematycznej na tyle dużą, że model przechodzi na inną stronę swojej granicy decyzyjnej.

Jedną z najbardziej znanych prac opisujących to zjawisko jest publikacja „Explaining and Harnessing Adversarial Examples” autorstwa Iana Goodfellowa, Jonathona Shlensa i Christiana Szegedy’ego. Badacze pokazali, że niewielkie, celowo dobrane perturbacje mogą prowadzić do błędnych klasyfikacji, często przy jednoczesnej wysokiej pewności modelu.

To istotne z punktu widzenia bezpieczeństwa. Błąd modelu nie musi wyglądać jak niepewność. Model może udzielić błędnej odpowiedzi i jednocześnie przypisać jej bardzo wysokie prawdopodobieństwo.

Patch attack – niewielki fragment obrazu, duża zmiana decyzji

Szczególnie interesującym przykładem ataku jest adversarial patch. W tym przypadku nie trzeba modyfikować całego obrazu. Napastnik przygotowuje specjalny wzorzec, który umieszcza tylko w jego fragmencie, a następnie sprawdza, czy obecność tego elementu wpływa na klasyfikację.

Badania nad adversarial patches pokazały, że odpowiednio skonstruowany wzór może pozostać skuteczny nawet przy zmianie położenia, skali czy perspektywy. Problem przestaje więc dotyczyć wyłącznie danych cyfrowych zapisanych w pliku. Może mieć znaczenie również w systemach wykorzystujących kamery i analizujących rzeczywiste otoczenie.

Adversarial Robustness Toolbox zawiera implementację klasy AdversarialPatch, dzięki której takie scenariusze można odtwarzać w kontrolowanym środowisku laboratoryjnym.

Znak STOP i fizyczne ataki na systemy wizyjne

Jednym z najbardziej znanych przykładów badań nad fizycznymi atakami adwersarialnymi była praca „Robust Physical-World Attacks on Deep Learning Visual Classification”. Badacze analizowali możliwość wpływania na klasyfikację znaków drogowych poprzez odpowiednio przygotowane modyfikacje wyglądające jak naklejki lub graffiti.

W eksperymentach wykazano, że testowany klasyfikator można doprowadzić do błędnej klasyfikacji znaku STOP również w warunkach bardziej zbliżonych do rzeczywistego świata. Jednocześnie warto podkreślić ograniczenia tego przykładu: badacze nie przejmowali rzeczywistego autonomicznego samochodu. Test dotyczył konkretnego komponentu klasyfikującego znaki.

To bardzo ważne rozróżnienie, ponieważ przykłady z obszaru adversarial AI bywają nadmiernie upraszczane. Wnioskiem z eksperymentu nie powinno być stwierdzenie, że „naklejka przejmuje autonomiczny samochód”, lecz raczej to, że model osiągający dobre wyniki na standardowym zbiorze testowym może zachowywać się zupełnie inaczej w obecności celowo skonstruowanych modyfikacji.

Data poisoning – atak rozpoczynający się przed wdrożeniem modelu

Nie wszystkie ataki są wykonywane podczas inferencji. W przypadku data poisoning przeciwnik próbuje wpłynąć na proces uczenia poprzez manipulację danymi treningowymi.

Może zmieniać próbki, etykiety, proporcje danych albo wprowadzać specjalnie przygotowane obserwacje, których celem jest wywołanie określonego zachowania modelu po jego wdrożeniu. Problem staje się szczególnie istotny w rozwiązaniach wykorzystujących ciągłe zbieranie danych oraz automatyczne lub regularne ponowne trenowanie modeli.

W takim środowisku dane są elementem łańcucha dostaw systemu AI. Pytanie o ich pochodzenie, integralność, sposób zatwierdzania i możliwość modyfikacji staje się więc pytaniem z obszaru cyberbezpieczeństwa, podobnie jak analiza pochodzenia bibliotek, obrazów kontenerowych czy zależności wykorzystywanych podczas tworzenia klasycznej aplikacji.

NIST klasyfikuje poisoning jako jedną z podstawowych grup zagrożeń dla modeli predykcyjnych, a ART udostępnia zarówno mechanizmy przeprowadzania takich testów, jak i wybrane techniki obronne.

Model extraction i ataki na poufność

Celem ataku nie zawsze jest spowodowanie błędnej decyzji. W niektórych scenariuszach przeciwnik może próbować odtworzyć zachowanie modelu na podstawie wysyłanych zapytań i obserwowanych odpowiedzi.

Takie techniki określa się między innymi jako model extraction lub model stealing. W innych przypadkach analiza zachowania systemu może służyć do wnioskowania o danych wykorzystanych podczas trenowania.

Dlatego analiza bezpieczeństwa AI nie może kończyć się na samym modelu. Trzeba uwzględnić również API, mechanizmy uwierzytelniania, autoryzację, limity zapytań, sposób monitorowania, przechowywanie artefaktów, proces treningowy, źródła danych oraz infrastrukturę wykorzystywaną podczas wdrożenia.

Adversarial Robustness Toolbox porządkuje wiele z tych zagrożeń w czterech głównych obszarach: Evasion, Poisoning, Extraction oraz Inference.

Dlaczego accuracy nie wystarcza do oceny odporności?

Załóżmy, że model osiąga 98% accuracy na standardowym zbiorze testowym. Na pierwszy rzut oka jest to bardzo dobry rezultat. Jeżeli jednak po zastosowaniu kontrolowanej perturbacji skuteczność spada do 55%, obraz jakości systemu staje się znacznie bardziej złożony.

Obie wartości są prawdziwe. Pierwsza opisuje zachowanie modelu w normalnych warunkach, druga pokazuje natomiast jego odporność w sytuacji celowej manipulacji.

Dlatego w dojrzałym procesie testowania warto rozdzielać clean accuracy od adversarial accuracy. W zależności od przypadku użycia można dodatkowo mierzyć attack success rate, wielkość perturbacji potrzebną do uzyskania określonego efektu, liczbę zapytań, stabilność ataku czy skuteczność mechanizmów detekcji.

W takim ujęciu odporność przestaje być abstrakcyjnym określeniem. Staje się właściwością, którą można mierzyć, porównywać i monitorować.

Testy adwersarialne jako element Quality Assurance

Przez lata rozwój oprogramowania ewoluował od prostego sprawdzania funkcjonalności do rozbudowanego procesu Quality Assurance. Testujemy jednostki kodu, integracje, wydajność, zachowanie interfejsów API, zależności oraz bezpieczeństwo.

W systemach AI pojawia się dodatkowy komponent: model. Jeżeli jego zachowanie może zostać zmienione przez odpowiednio przygotowane dane wejściowe, to jego odporność również powinna być traktowana jako jeden z parametrów jakości.

W praktyce oznacza to, że test adwersarialny nie powinien być wyłącznie widowiskowym eksperymentem wykonywanym podczas prezentacji albo jednorazowego Red Teamingu. Największą wartość uzyskujemy wtedy, gdy taki test można powtórzyć po każdej istotnej zmianie modelu, danych lub architektury.

Wtedy adversarial testing zaczyna pełnić podobną rolę jak testy regresyjne w tradycyjnym oprogramowaniu. Szerzej o samym podejściu ofensywnym do testowania AI pisałam również w artykule AI Red Teaming w praktyce: Jak psuć modele, by budować bezpieczniejsze systemy.

EU AI Act a odporność systemów wysokiego ryzyka

Istotnym elementem tej dyskusji jest EU AI Act. Artykuł 15 rozporządzenia dotyczy dokładności, solidności oraz cyberbezpieczeństwa systemów AI wysokiego ryzyka. Wymaga, aby były one projektowane i rozwijane w sposób zapewniający odpowiedni poziom accuracy, robustness i cybersecurity przez cały cykl życia. Co szczególnie istotne, regulacja nie ogranicza się wyłącznie do ogólnego stwierdzenia, że system AI powinien być bezpieczny. Wprost odwołuje się do zagrożeń specyficznych dla sztucznej inteligencji, takich jak data poisoning, model poisoning oraz adversarial examples i model evasion. Nie oznacza to oczywiście, że każda organizacja musi przeprowadzić identyczny zestaw eksperymentów. Zakres testowania powinien wynikać z przeznaczenia systemu, jego klasyfikacji, potencjalnych konsekwencji błędów i zidentyfikowanych zagrożeń.

Zmienia się natomiast poziom oczekiwanej dojrzałości. Samo stwierdzenie, że model osiąga określony procent accuracy, może być niewystarczające. Organizacja powinna również potrafić wyjaśnić, w jaki sposób oceniała odporność systemu i jakie dowody potwierdzają uzyskany poziom zabezpieczeń. Szersze omówienie regulacji znajduje się we wpisie EU AI Act i polski projekt ustawy o Sztucznej Inteligencji. Warto także przeczytać późniejszą aktualizację Ustawa o sztucznej inteligencji: Rola KRiBSI, dotyczącą rozwoju krajowych regulacji związanych z AI.

ISO/IEC 42001 – od pojedynczego testu do systemu zarządzania

Kolejnym ważnym punktem odniesienia jest ISO/IEC 42001:2023, czyli norma dotycząca Artificial Intelligence Management System. Jej celem jest uporządkowanie sposobu, w jaki organizacja zarządza systemami AI, odpowiedzialnością, ryzykiem, nadzorem i ciągłym doskonaleniem. Nie jest to jednak techniczna instrukcja wykonywania ataków adwersarialnych. ISO/IEC 42001 nie definiuje, jaki algorytm ataku należy uruchomić ani jaką wartość epsilon zastosować w eksperymencie FGSM. Norma tworzy natomiast ramy, w których ryzyka powinny być systematycznie identyfikowane, oceniane, traktowane i monitorowane.

Testy adwersarialne mogą być więc jednym z praktycznych mechanizmów dostarczających dowodów na to, że określone ryzyko zostało rzeczywiście zweryfikowane. W tym sensie techniczne testowanie i system zarządzania AI wzajemnie się uzupełniają.

ISO/IEC 23894 i zarządzanie ryzykiem AI

Uzupełnieniem ISO/IEC 42001 jest norma ISO/IEC 23894:2023, koncentrująca się na zarządzaniu ryzykiem związanym ze sztuczną inteligencją. Pomaga ona organizacjom rozwijającym lub wykorzystującym systemy AI włączyć specyficzne ryzyka technologiczne do szerszego procesu risk management.

W praktyce warto patrzeć na te elementy łącznie. AI Act tworzy kontekst regulacyjny i wskazuje określone wymagania. ISO/IEC 42001 pomaga zbudować system zarządzania, ISO/IEC 23894 porządkuje podejście do ryzyka, a narzędzia takie jak ART umożliwiają weryfikację części założeń poprzez powtarzalne testy techniczne.

MITRE ATLAS – baza wiedzy o atakach na AI

Zespoły bezpieczeństwa od lat wykorzystują MITRE ATT&CK do opisywania zachowań przeciwników w klasycznych środowiskach IT. W przypadku sztucznej inteligencji podobną rolę pełni MITRE ATLAS – Adversarial Threat Landscape for AI Systems. ATLAS zawiera informacje o taktykach i technikach związanych z atakami na systemy AI, obejmującymi między innymi Predictive AI, Generative AI oraz Agentic AI.

Z punktu widzenia zespołu projektowego ma to duże znaczenie, ponieważ pozwala odejść od przypadkowego wyboru testów. Zamiast uruchamiać dostępne narzędzia bez wyraźnego celu, można rozpocząć od threat modelingu, wskazać istotne techniki, a następnie przypisać do nich konkretne przypadki testowe i kryteria akceptacji.

Adversarial Robustness Toolbox – praktyczne testowanie modeli

Jednym z najbardziej użytecznych frameworków do testowania klasycznych modeli ML jest Adversarial Robustness Toolbox (ART). ART jest biblioteką Python rozwijaną z myślą o Machine Learning Security. Obsługuje wiele popularnych frameworków, między innymi PyTorch, TensorFlow, Keras, scikit-learn, XGBoost czy LightGBM. Obejmuje ataki dotyczące obrazów, danych tabelarycznych, audio i innych typów danych.

Największą zaletą ART jest to, że pozwala korzystać z gotowych implementacji ataków i mechanizmów ochronnych bez konieczności odtwarzania każdej publikacji naukowej od podstaw.

Demo 1: pierwszy test odporności z ART

Prosty eksperyment można wykonać lokalnie, wykorzystując niewielki klasyfikator i jeden z podstawowych ataków, na przykład Fast Gradient Method.

Najpierw instalujemy wymagane biblioteki:

pip install adversarial-robustness-toolbox torch scikit-learn numpy

Następnie możemy przygotować niewielki model klasyfikacyjny (poniżej pokazany jest fragment kodu):

pred_clean = np.argmax(classifier.predict(X_test), axis=1)
clean_accuracy = np.mean(pred_clean == y_test)

print("Clean accuracy:", clean_accuracy)

attack = FastGradientMethod(
    estimator=classifier,
    eps=0.15
)

X_adversarial = attack.generate(x=X_test)

pred_adv = np.argmax(
    classifier.predict(X_adversarial),
    axis=1
)

adversarial_accuracy = np.mean(
    pred_adv == y_test
)

print("Adversarial accuracy:", adversarial_accuracy)

Najważniejszym elementem tego ćwiczenia nie jest sam atak. Znacznie istotniejsze jest porównanie stanu bazowego z wynikiem uzyskanym po kontrolowanej manipulacji.

Jeżeli model osiąga na przykład 94% accuracy dla prawidłowych danych, ale tylko 40% po zastosowaniu ataku, oznacza to, że jego zachowanie pod presją przeciwnika znacząco różni się od zachowania mierzonego klasycznym testem.

Jednocześnie aplikacja może nadal działać prawidłowo z punktu widzenia infrastruktury. Nie pojawi się wyjątek, serwer nie zwróci błędu HTTP 500, a monitoring może nie zgłosić żadnej awarii. Problemem jest nie dostępność systemu, lecz jakość podejmowanych przez niego decyzji.

Demo 2: budowanie krzywej odporności

Znacznie ciekawszy rezultat uzyskamy, jeżeli zamiast jednej wartości perturbacji przetestujemy cały ich zakres.

eps_values = [
    0.01,
    0.03,
    0.05,
    0.10,
    0.15,
    0.20
]

Zamiast stwierdzenia „model jest odporny” otrzymujemy mierzalną informację: jak szybko pogarsza się jego skuteczność wraz ze wzrostem siły perturbacji. Taką charakterystykę można następnie porównywać pomiędzy kolejnymi wersjami modelu.

Demo 3: adversarial patch

Drugim ciekawym eksperymentem jest przygotowanie adversarial patch i sprawdzenie jego skuteczności w różnych warunkach. W laboratorium można wykorzystać lokalny klasyfikator obrazów, a następnie zmieniać położenie patcha, jego wielkość, obrót i inne transformacje. Celem nie powinno być wyłącznie sprawdzenie, czy udało się jednorazowo wprowadzić model w błąd. Znacznie bardziej interesujące jest pytanie, w jakim zakresie zmian atak zachowuje skuteczność.

ART udostępnia gotową implementację AdversarialPatch, co znacznie ułatwia przygotowanie takich eksperymentów.

Poniżej fragmenty kodu pokazujące wartość Clean accuracy oraz wpływu adversarial patches na accuracy i attack success.

Demo 4: kontrolowane data poisoning

Podobne podejście można zastosować do danych treningowych. Najpierw przygotowujemy model bazowy, a następnie modyfikujemy kontrolowany procent danych, na przykład 1%, 3% lub 5%.

Po ponownym treningu porównujemy wyniki z baseline. Możemy analizować accuracy, false positive rate, false negative rate, skuteczność dla konkretnej klasy albo zachowanie wobec specjalnie przygotowanego zbioru testowego.

W kolejnym etapie warto włączyć mechanizm wykrywania nieprawidłowości i sprawdzić, czy potrafimy zidentyfikować zmodyfikowane próbki. Taki eksperyment dobrze pokazuje, że data poisoning nie jest jedynie teoretycznym zagrożeniem. Może zostać przełożony na konkretny, mierzalny test.

Największa wartość: test adwersarialny jako test regresyjny

Największą wartość uzyskujemy wtedy, gdy eksperyment przestaje być wykonywany ręcznie.

Test można włączyć do pipeline’u MLOps:

trening modelu
      ↓
test jakości
      ↓
test danych
      ↓
test adwersarialny
      ↓
ocena metryk
      ↓
quality gate
      ↓
wdrożenie

Po wykonaniu ataku można automatycznie sprawdzić, czy model spełnia ustalone kryteria, np:

assert clean_accuracy >= 0.94
assert adversarial_accuracy >= 0.75
assert attack_success_rate <= 0.20

Oczywiście tych wartości nie należy kopiować bezpośrednio do środowiska produkcyjnego. Progi powinny wynikać z konkretnego zastosowania, potencjalnych konsekwencji błędu, threat modelu oraz przyjętego poziomu akceptacji ryzyka. Najważniejszy jest jednak sam mechanizm: odporność staje się jednym z kryteriów dopuszczenia modelu do wdrożenia.

Adversarial testing jako element MLSecOps jest naturalnym kierunkiem rozwoju MLOps.  Jest to integracja mechanizmów bezpieczeństwa. Pipeline nie powinien sprawdzać wyłącznie tego, czy model został poprawnie wytrenowany, czy artefakt został zapisany i czy podstawowe metryki jakości spełniają oczekiwania. Powinien również weryfikować, czy system zachowuje odpowiednią odporność wobec wcześniej zdefiniowanych klas zagrożeń. Nie oznacza to automatycznego uruchamiania wszystkich dostępnych ataków. Testy powinny wynikać z modelu zagrożeń.

Shift-left w bezpieczeństwie AI

W klasycznym cyberbezpieczeństwie od wielu lat obserwujemy przesuwanie testów bliżej początku procesu wytwarzania oprogramowania. Test penetracyjny wykonywany tuż przed produkcją został uzupełniony przez SAST, DAST, dependency scanning, secret scanning, IaC scanning i policy as code. Podobną ewolucję powinno przejść bezpieczeństwo systemów AI. Jeżeli wiemy, że określony model może być podatny na konkretny rodzaj ataku, nie ma powodu, aby odkrywać ten problem dopiero przed wdrożeniem produkcyjnym. Test można uruchamiać automatycznie po każdym treningu albo po zmianach mających znaczenie dla charakterystyki modelu.

Pojawia się wtedy pojęcie robustness regression. Nowa wersja modelu może osiągać lepszą klasyczną accuracy, a jednocześnie być bardziej podatna na wybrane ataki. Bez testów adwersarialnych taka zmiana może pozostać niewidoczna.

 

Jak zaplanować program testów adwersarialnych?

Dobry program testowy powinien rozpocząć się od zrozumienia rzeczywistego zastosowania systemu, a nie od wyboru narzędzia.

W praktyce warto zastosować następujący proces:

1. Zidentyfikować zasoby, procesy i decyzje zależne od AI oraz określić konsekwencje ich błędnego działania.
2. Przygotować threat model uwzględniający dostęp przeciwnika do danych, API, modelu i procesu treningowego.
3. Wybrać realistyczne scenariusze ataku, zamiast testować wszystkie dostępne techniki bez kontekstu.
4. Zdefiniować baseline i mierzalne kryteria odporności.
5. Automatyzować scenariusze, które mają znaczenie regresyjne.
6. Wprowadzić quality gates dla krytycznych parametrów.
7. Kontynuować monitoring po wdrożeniu, ponieważ odporność zmienia się wraz z modelem, danymi i środowiskiem.

Takie podejście pozwala połączyć perspektywę techniczną z zarządzaniem ryzykiem.

Nie testujemy wyłącznie modelu

Jedną z najważniejszych zasad bezpieczeństwa AI jest traktowanie modelu jako elementu większego systemu. Sam model może być stosunkowo odporny, ale aplikacja może zawierać podatne API. Zabezpieczenia interfejsu mogą być poprawne, ale dane treningowe mogą pochodzić z niewiarygodnych źródeł. Model może być odporny na jeden rodzaj perturbacji, ale podatny na inny. W przypadku generatywnej AI problem staje się jeszcze bardziej złożony, ponieważ LLM może komunikować się z bazą wiedzy, wykonywać operacje przez narzędzia, korzystać z systemów tożsamości i wpływać na zewnętrzne zasoby.

Dobrym przykładem tego, dlaczego bezpieczeństwa AI nie można utożsamiać jedynie z bezpieczeństwem samego modelu, jest opisana przeze mnie podatność infrastruktury lokalnego AI: BLEEDING LLAMA: Krytyczna luka w modelu Ollama. Nawet lokalne uruchomienie modelu nie rozwiązuje automatycznie problemów bezpieczeństwa — nadal pozostają biblioteki, parsery, formaty plików, interfejsy API, uprawnienia i infrastruktura wykonawcza.

Dlatego security assessment powinien obejmować cały system AI, a nie tylko jego pojedynczą warstwę.

Shadow AI dodatkowo zwiększa powierzchnię ataku

Testowanie odporności zakłada jeszcze jedno: organizacja musi wiedzieć, że dany system istnieje. W praktyce nie zawsze tak jest. Pracownicy samodzielnie wdrażają narzędzia generatywne, aplikacje korzystające z API modeli, automatyzacje, lokalne modele i agentów. W efekcie powstaje Shadow AI, czyli warstwa technologii funkcjonującej poza oficjalnym nadzorem organizacji.

Firma może więc posiadać bardzo dojrzały proces oceny oficjalnych projektów AI, a jednocześnie korzystać z wielu rozwiązań, które nigdy przez ten proces nie przeszły. Co więcej, wraz z rozwojem agentów AI problem przestaje ograniczać się do ryzyka ujawnienia danych. System może uzyskać możliwość wywoływania API, przeglądania zasobów firmowych czy wykonywania rzeczywistych działań. Przykłady takich scenariuszy – od ukrytej instrukcji w dokumencie, przez zatruwanie bazy wiedzy RAG, aż po nieautoryzowane działania agenta i eksfiltrację danych – opisałam szerzej we wpisie Shadow AI w firmie.

Z tego powodu pierwszy etap budowania programu bezpieczeństwa AI powinien obejmować inwentaryzację systemów, określenie ich właścicieli i zrozumienie rzeczywistych przypadków użycia.

Jednorazowy test nie oznacza trwałej odporności

System AI nie jest rozwiązaniem statycznym. Zmieniają się dane, biblioteki, kod, parametry, preprocessing, źródła danych i modele bazowe. W przypadku usług dostarczanych przez zewnętrznego producenta organizacja może nawet nie kontrolować wszystkich zmian zachodzących w samym modelu.

Dlatego wynik testu bezpieczeństwa nie powinien być traktowany jako trwała właściwość systemu. Odporność trzeba okresowo weryfikować, szczególnie po zmianach mogących wpływać na zachowanie modelu lub po pojawieniu się nowych technik ataku.

W tym miejscu automatyzacja testów adwersarialnych daje największą wartość: pozwala porównywać wersje systemu i wykrywać regresje, zanim trafią do produkcji.

Odporność nie może eliminować użyteczności

Ważnym aspektem jest także równowaga pomiędzy bezpieczeństwem a funkcjonalnością. Mechanizmy obronne mogą wpływać na wyniki modelu. Adversarial training może zmieniać accuracy, dodatkowe filtry mogą zwiększać liczbę false positives, a agresywne mechanizmy wykrywania anomalii mogą odrzucać prawidłowe dane.

Podobny problem występuje w klasycznym cyberbezpieczeństwie. System całkowicie odłączony od sieci może być bardzo odporny na część ataków sieciowych, ale jednocześnie przestaje realizować swoją funkcję biznesową.

Celem nie jest więc stworzenie rozwiązania, którego „nie da się zaatakować”. Celem jest uzyskanie akceptowalnego poziomu ryzyka przy zachowaniu wymaganej jakości, dostępności i funkcjonalności systemu.

Dokumentacja nie zastępuje testów technicznych

EU AI Act, ISO/IEC 42001 i systemy zarządzania ryzykiem zwiększają znaczenie dokumentacji. Nie oznacza to jednak, że dokumentacja może zastąpić praktyczną weryfikację. Jeżeli organizacja deklaruje, że model jest odporny na określoną klasę manipulacji, powinna być w stanie wskazać sposób, w jaki to sprawdziła. Istotne są informacje dotyczące danych testowych, wersji modelu, parametrów ataku, baseline, wyników oraz efektów zastosowanych mechanizmów ochronnych.

Dzięki temu proces audytowy opiera się nie tylko na deklaracjach, lecz także na technicznych dowodach.

Testy adwersarialne jako dowód jakości

Z tego powodu warto patrzeć na AI Red Teaming i adversarial testing nie wyłącznie jako na element bezpieczeństwa, ale także jako część Quality Assurance. Model, który działa poprawnie tylko wtedy, gdy użytkownik i środowisko zachowują się dokładnie zgodnie z oczekiwaniami twórców, może okazać się niewystarczająco odporny do zastosowania produkcyjnego. Dobre systemy powinny uwzględniać możliwość błędów, odstępstw od założeń oraz nietypowych danych. Systemy odpowiedzialne za istotne procesy powinny również brać pod uwagę możliwość, że część tych odchyleń będzie celowa.

Od pentestu aplikacji do pentestu decyzji modelu

W klasycznym pentestingu próbujemy znaleźć sposób na obejście zabezpieczeń aplikacji lub infrastruktury. Szukamy SQL Injection, Broken Access Control, SSRF, RCE, słabych mechanizmów uwierzytelniania czy możliwości przejęcia danych.

W przypadku adversarial machine learning celem ataku może być coś bardziej subtelnego: decyzja modelu. Napastnik nie zawsze potrzebuje przejąć serwer, uzyskać uprawnień administratora ani wykraść bazy danych. Czasami wystarczy mu możliwość systematycznego wpływania na wynik klasyfikacji lub oceny ryzyka. To właśnie dlatego bezpieczeństwo AI znajduje się na styku cyberbezpieczeństwa, software engineeringu, data science i risk managementu.

Twórca systemu AI powinien myśleć jak przeciwnik

Przez lata w cyberbezpieczeństwie powtarzaliśmy programistom, że powinni nauczyć się patrzeć na własne aplikacje z perspektywy atakującego. Ta sama zasada dotyczy obecnie zespołów AI. Tworząc klasyfikator, warto zastanowić się, jakie dane mogą prowadzić do błędnej klasyfikacji. Projektując system fraud detection, trzeba brać pod uwagę fakt, że oszuści będą dostosowywać swoje zachowanie do mechanizmów detekcji. Jeżeli model jest regularnie retrenowany, należy przeanalizować, kto może wpływać na nowe dane. Jeśli rozwiązanie jest dostępne przez API, trzeba uwzględnić możliwość automatycznego odpytywania i analizy odpowiedzi. W przypadku RAG należy zastanowić się nad zaufaniem do źródeł wiedzy, a w przypadku agentów również nad zakresem ich uprawnień oraz wpływem zmanipulowanego kontekstu na wykonywane działania. To nie jest nadmierna ostrożność. To po prostu threat modeling dostosowany do systemów AI.

Od ataku do odporności

Dojrzały program testowania AI nie powinien kończyć się na znalezieniu podatności. Udany atak jest dopiero początkiem procesu. Po jego przeprowadzeniu trzeba zmierzyć efekt, zrozumieć przyczynę, zaprojektować mitygację, ponownie przeprowadzić test i – jeżeli scenariusz jest istotny – zautomatyzować go jako test regresyjny. Wtedy jednorazowy eksperyment staje się częścią procesu inżynierskiego. To właśnie oznacza przejście od ataku do odporności.

Testy adwersarialne powinny znaleźć się w Definition of Done

Jeżeli system AI wpływa na istotne procesy, jego Definition of Done nie powinna ograniczać się do stwierdzenia, że model został wytrenowany, API działa, a accuracy spełnia oczekiwania. Warto również wiedzieć, jakie scenariusze ataku zostały przetestowane, jakie metryki odporności osiągnięto, jakie ograniczenia systemu są znane, które elementy będą monitorowane na produkcji oraz kiedy testy zostaną wykonane ponownie. W takim podejściu bezpieczeństwo nie jest wydarzeniem wykonywanym raz w projekcie. Staje się właściwością całego procesu wytwarzania i utrzymania systemu AI.

Podsumowanie

Testy adwersarialne AI przestały być wyłącznie eksperymentem naukowym. Coraz częściej stanowią jeden z elementów profesjonalnego procesu oceny jakości i bezpieczeństwa modeli.

EU AI Act wprost odnosi się do zagrożeń takich jak data poisoning, model poisoning czy adversarial examples. NIST rozwija taksonomię Adversarial Machine Learning, MITRE ATLAS porządkuje techniki ataku, ISO/IEC 42001 pomaga budować system zarządzania, a ISO/IEC 23894 wspiera organizacje w systematycznym podejściu do ryzyka.

Narzędzia takie jak Adversarial Robustness Toolbox pozwalają natomiast przełożyć część tej wiedzy na konkretne, mierzalne testy. Największą wartość uzyskujemy jednak dopiero wtedy, gdy te eksperymenty przestają być pojedynczymi demonstracjami, a stają się powtarzalnym elementem MLOps, MLSecOps i procesu Quality Assurance.

Dlatego w 2026 roku pytanie nie powinno już brzmieć: „Czy warto testować modele AI pod kątem ataków adwersarialnych?”.

Znacznie bardziej adekwatne pytanie brzmi:

Dlaczego tych testów nie ma jeszcze w naszym pipeline?

Slajdy z mojego wystąpienia „Od ataku do odporności – Dlaczego testy adwersarialne to nowy standard jakości w tworzeniu systemów AI?” na konferencji Wymiana doświadczeń w zakresie bezpieczeństwa informacji, która odbywała się w dniach 24-25.09.2026 w Krynicy-Zdrój na temat można pobrać z mojego Githuba.

Bezpieczeństwo AI w praktyce z ZALNET

ZALNET wspiera organizacje rozwijające i wdrażające rozwiązania oparte na sztucznej inteligencji w obszarach bezpieczeństwa AI, AI Red Teamingu, threat modelingu, testowania odporności oraz projektowania bezpiecznych architektur AI. Jeżeli przedstawione w tym artykule eksperymenty były dla Ciebie interesujące i chcesz samodzielnie przetestować ataki na modele AI, sprawdzić ich odporność oraz zobaczyć, jak wygląda hardening modeli w praktyce, zapraszam na moje szkolenia i warsztaty.

W ramach warsztatów pracujemy praktycznie z narzędziami i technikami wykorzystywanymi do testowania bezpieczeństwa systemów AI. Uczestnicy mogą eksperymentować z atakami adwersarialnymi, data poisoningiem i innymi scenariuszami, a następnie sprawdzać, jakie mechanizmy obronne można zastosować, aby zwiększyć odporność modeli i całych rozwiązań AI.

Wybierz format warsztatu

W sklepie ZALNET dostępne są między innymi:

• 3-godzinny szybki warsztat – skoncentrowany na najważniejszych zagadnieniach i praktycznych demonstracjach,
• 8-godzinny warsztat popołudniowy – intensywna formuła realizowana w godzinach popołudniowych (2 x 4h – 17:00-21:00),
• 8-godzinny warsztat dzienny – pełny dzień praktycznej pracy, realizowany w godzinach 9:00–17:00.

Aktualnie dostępne warsztaty i terminy znajdziesz w sklepie ZALNET.

Jeżeli szukasz szerszego programu szkoleniowego, obejmującego również inne zagadnienia związane z bezpieczeństwem sztucznej inteligencji, zobacz szkolenia ZALNET. Profesjonalne tworzenie systemów AI nie polega już wyłącznie na umiejętności ich wytrenowania i wdrożenia. Równie istotna staje się wiedza o tym, w jaki sposób mogą zostać zmanipulowane, jak wykrywać ich słabe punkty oraz jak zweryfikować ich odporność, zanim zrobi to rzeczywisty przeciwnik.

Chcesz zobaczyć, jak wygląda bezpieczeństwo AI w praktyce? Zacznij od eksperymentów, a następnie przełóż je na rzeczywiste procesy testowania i hardeningu modeli.