AI red teaming

AI red teaming to testowanie systemu sztucznej inteligencji, na przykład chatbota, agenta albo modelu, przez celowe odgrywanie roli napastnika, zanim zrobią to prawdziwi atakujący. NIST opisuje je jako ustrukturyzowane ćwiczenie, w którym sprawdza się system AI w poszukiwaniu wad i podatności, takich jak niedokładne, szkodliwe albo dyskryminujące odpowiedzi, często w kontrolowanym środowisku i we współpracy z twórcami systemu ^[1]. Microsoft zauważa, że termin historycznie oznaczał systematyczne ataki służące testowaniu podatności, a przy modelach językowych rozszerzył się na wiele rodzajów sondowania i atakowania systemów AI ^[2]. Nazwa zostaje po angielsku; w polskich tekstach spotyka się też „red teaming AI”.

Jak działa

Klasyczny red team to według słownika NIST grupa osób upoważnionych i zorganizowanych do naśladowania możliwości ataku potencjalnego przeciwnika wobec zabezpieczeń organizacji ^[5]. AI red teaming przenosi tę ideę na systemy AI, ale zakres jest szerszy niż w teście penetracyjnym. Obejmuje nie tylko przejęcie systemu, ale też szkodliwe treści, które model może wygenerować przy zwykłym, nieatakującym użyciu ^[2].

Microsoft zaleca pracę w rundach ^[2]. Najpierw testy otwarte, w których testerzy swobodnie szukają problemów, potem lista szkód z definicjami i przykładami, a następnie testy ukierunkowane na tę listę, w trakcie których zwykle pojawiają się nowe szkody ^[2]. Cykl pokazuje schemat poniżej.

RYS. 1Rundy AI red teamingu

Microsoft zaleca testowanie na kilku warstwach: modelu bazowego z jego systemem bezpieczeństwa, zwykle przez punkt końcowy API, samej aplikacji przez interfejs użytkownika oraz obu tych warstw przed wdrożeniem poprawek i po nim ^[2]. Testy warto prowadzić jak najbliżej produkcyjnego interfejsu, bo najlepiej oddaje on rzeczywiste użycie ^[2].

Rodzaje

NIST wyróżnia cztery rodzaje ćwiczeń, zależnie od tego, kto testuje ^[1].

Co sprawdzać, NIST wylicza w jednym z zaleceń: podatność na nadużycie do ataków na inne systemy, na przykład generowanie złośliwego kodu i treści phishingowych, ataki na modele generatywne, takie jak prompt injection, oraz ataki na uczenie maszynowe, w tym zatruwanie danych (data poisoning), wnioskowanie o przynależności i wydobycie modelu ^[1]. Osobne zalecenie dotyczy prywatności: sprawdzenia, czy model zwraca próbki danych treningowych albo informacje poufne, osobowe czy objęte prawami ^[1], czyli ujawnienia informacji wrażliwych (sensitive information disclosure).

OWASP w przewodniku ze stycznia 2025 roku dzieli red teaming systemów generatywnych na cztery obszary: ocenę modelu, testy implementacji, ocenę infrastruktury i analizę zachowania w czasie działania ^[4].

W WordPressie

Właściciel strony WordPress rzadko testuje sam model. Testuje aplikację: wtyczkę czatu, asystenta w panelu albo agenta z dostępem do treści. Tu sprawdza się zalecenie Microsoftu, by zacząć od zrozumienia, co system potrafi i gdzie jest używany ^[3]. Chatbot, który tylko odpowiada na pytania o ofertę, ma inną powierzchnię ataku niż agent mogący publikować wpisy.

Praktyczny zakres testów takiej wtyczki obejmuje:

• próby jailbreak i wymuszenia treści sprzecznych z zasadami strony;
• próby wydobycia instrukcji wtyczki, opisane w haśle system prompt leakage;
• pytania o dane innych klientów, szkice i wpisy prywatne;
• ukryte polecenia w komentarzach, opiniach i formularzach, które wtyczka przekazuje modelowi;
• próby nakłonienia agenta do działań w panelu, czyli ryzyko excessive agency.

Testy prowadzi się na środowisku testowym (staging) z kopią strony, a nie na danych produkcyjnych. Microsoft zaleca zapisywanie dla każdego przykładu daty, promptu, odpowiedzi i identyfikatora pozwalającego odtworzyć wynik ^[2].

Znaczenie i ograniczenia

Red teaming nie mierzy, jak często szkoda występuje. Microsoft podkreśla, że nie zastępuje on systematycznego pomiaru i łagodzenia ryzyka, a pojedynczych przykładów nie należy traktować jako miary powszechności szkody ^[2]. Zespół Microsoftu, który przetestował ponad 100 produktów generatywnej AI, sformułował osiem lekcji, w tym: AI red teaming nie jest benchmarkiem bezpieczeństwa, do złamania systemu nie trzeba liczyć gradientów, a praca nad zabezpieczeniem systemów AI nigdy nie będzie zakończona ^[3].

Testy nie gwarantują też odporności. Wei, Haghtalab i Steinhardt w lipcu 2023 roku stwierdzili, że podatności modeli GPT-4 i Claude v1.3 utrzymują się mimo intensywnego red teamingu i treningu bezpieczeństwa ^[6]. Wyniki testów są podstawą dla guardrails i poprawek w kodzie, a ich interpretację wspiera modelowanie zagrożeń.

Dobre praktyki

• Różnorodny zespół. NIST wiąże jakość wyników z doświadczeniem zespołu i zaleca zespoły zróżnicowane demograficznie i interdyscyplinarnie, ze znajomością dziedziny ^[1]. Microsoft radzi łączyć testerów o nastawieniu napastnika z osobami, które są zwykłymi użytkownikami i nie brały udziału w budowie systemu ^[2].
• Przydział szkód. Specjaliści od bezpieczeństwa mogą szukać jailbreaków i prób wydobycia promptu systemowego ^[2].
• Automatyzacja z człowiekiem. Automatyzacja pomaga pokryć większą część ryzyk, ale element ludzki pozostaje kluczowy ^[3].
• Współpraca z obroną. Wnioski z ćwiczeń trafiają do zespołu broniącego, jak w modelu purple team.

Historia i przykłady

Profil NIST. W lipcu 2024 roku NIST wydał profil AI 600-1 dla generatywnej AI, w którym AI red teaming jest jedną z metod oceny ryzyka ^[1].

Microsoft. 13 stycznia 2025 roku zespół Microsoftu opublikował wnioski z red teamingu ponad 100 produktów generatywnej AI, razem z ontologią modelu zagrożeń ^[3].

OWASP. 22 stycznia 2025 roku OWASP Gen AI Security Project opublikował GenAI Red Teaming Guide ^[4].