Jak przetestować bezpieczeństwo AI – przewodnik dla firm

Jak przetestować bezpieczeństwo AI – przewodnik dla firm

Wdrożyłeś asystenta AI. Działa. Odpowiada na pytania klientów, pomaga zespołowi, może nawet pisze kod. Ale czy ktoś sprawdził, czy jest bezpieczny?

Testowanie bezpieczeństwa AI to inna dyscyplina niż tradycyjne testy penetracyjne. Model językowy nie ma portów do skanowania ani znanych CVE do sprawdzenia. Zamiast tego masz probabilistyczny system, który na to samo pytanie może odpowiedzieć różnie.

Ten przewodnik pokaże ci, jak podejść do testowania AI w praktyce.

  1. Dlaczego AI testuje się inaczej
  2. Red teaming dla AI
  3. Co testować – lista kontrolna
  4. Automatyczne skanery
  5. Metryki sukcesu
  6. Proces ciągłego testowania

Dlaczego AI testuje się inaczej

Tradycyjny pentest: znajdujesz lukę, eksploitujesz ją, powtarzasz exploit – działa za każdym razem.

Testowanie AI: wysyłasz prompt atakujący, model go blokuje. Wysyłasz ten sam prompt znowu – i tym razem działa. Albo odwrotnie.

To dlatego, że modele językowe są probabilistyczne. Ich odpowiedzi zależą od wewnętrznych stanów, temperatury próbkowania, kontekstu konwersacji. Jeden test to za mało.

Zasada: każdy test atakujący powtórz minimum 5-10 razy. Dopiero wtedy masz wiarygodne dane o skuteczności ataku lub obrony.

Red teaming dla AI

Microsoft prowadzi dedykowany zespół AI Red Team od 2018 roku. Ich podejście obejmuje dwa wymiary:

Zakres red teamingu AI
WymiarCo testujeszPrzykłady ataków
BezpieczeństwoOchrona danych i systemuPrompt injection, eksfiltracja, jailbreaking
OdpowiedzialnośćEtyczne zachowanie AITreści szkodliwe, uprzedzenia, dezinformacja

Drugi wymiar często pomijamy w polskich firmach. Ale wyobraź sobie, że twój chatbot obsługi klienta zaczyna generować obraźliwe treści. To też jest problem bezpieczeństwa – wizerunkowy.

Dwa poziomy testów:

  1. Model bazowy – testuj sam model, bez twojej aplikacji. Jakie są jego wrodzone słabości?
  2. Aplikacja – testuj całość: prompt systemowy, RAG, narzędzia, integracje. Tu są prawdziwe luki.

Co testować – lista kontrolna

Prompt injection:

  • Czy zewnętrzna treść może przejąć kontrolę nad AI?
  • Czy AI wykona instrukcje ukryte w dokumentach?
  • Czy kodowanie (Base64, Unicode) omija filtry?

Eksfiltracja danych:

  • Czy AI ujawni prompt systemowy?
  • Czy da się wyciągnąć dane z kontekstu przez obrazki/linki?
  • Czy AI powie rzeczy, których nie powinien?

Jailbreaking:

  • Czy techniki typu DAN działają?
  • Czy manipulacja emocjonalna obchodzi filtry?
  • Czy AI wygeneruje szkodliwe treści przy odpowiednim promptingu?

Narzędzia i integracje:

  • Czy AI może wywołać nieautoryzowane akcje?
  • Czy jeden plugin może wyzwolić inny?
  • Czy walidacja wejścia/wyjścia narzędzi działa?

Największe luki często są na styku AI i zewnętrznych systemów. Nie testuj tylko samego modelu – testuj całą architekturę.

Automatyczne skanery

Ręczne testowanie jest niezbędne, ale nie skaluje się. Na szczęście istnieją narzędzia automatyzujące proces.

Garak (NVIDIA) to skaner podatności dla LLM. Działa jak nmap, ale dla modeli językowych:

bash
# Instalacja
pip install -U garak

# Skan konkretnego modelu
garak --target_type openai --target_name gpt-4o --probes encoding

# Lista dostępnych testów
garak --list_probes

Garak ma wbudowane dziesiątki kategorii testów: od prompt injection przez jailbreaking po próby generowania złośliwego kodu.

Kategorie testów w Garak
KategoriaCo testujeTyp zagrożenia
encodingObejście filtrów przez kodowaniePrompt injection
danJailbreaki typu DANJailbreaking
promptinjectWstrzyknięcie instrukcjiPrompt injection
leakreplayWyciek danych treningowychEksfiltracja
xssXSS przez LLMBezpieczeństwo webowe

Metryki sukcesu

Jak zmierzyć, czy twoje zabezpieczenia działają?

Attack Success Rate (ASR) – procent udanych ataków. Jeśli na 100 prób prompt injection 15 przeszło, ASR = 15%. Chcesz, żeby było jak najniżej.

False Positive Rate (FPR) – procent legalnych zapytań zablokowanych jako ataki. Zbyt agresywne filtry psują użyteczność. Cel: poniżej 1-2%.

Progi akceptacji:

  • ASR < 5% dla prompt injection – minimum produkcyjne
  • ASR < 1% dla eksfiltracji danych – dane wrażliwe wymagają więcej
  • FPR < 2% – użytkownicy nie mogą być frustrowani fałszywymi blokadami

Proces ciągłego testowania

Jednorazowy test to za mało. AI się zmienia – aktualizacje modelu, zmiany promptów, nowe integracje. Każda zmiana może wprowadzić nowe luki.

Zintegruj testy z CI/CD:

  1. Przy każdej zmianie promptu systemowego – uruchom podstawowy zestaw testów
  2. Przy każdej nowej integracji – pełny test narzędzia
  3. Regularnie (co tydzień/miesiąc) – pełny red team scan

Platformy takie jak OpenClaw mają wbudowane mechanizmy bezpieczeństwa, ale to nie zwalnia z testowania. Każda konfiguracja jest unikalna, każda integracja dodaje powierzchnię ataku.

Końcowa rada: większość prawdziwych ataków na AI została odkryta przez zewnętrznych badaczy, nie przez wewnętrzny monitoring firm. Jeśli nie testujesz aktywnie, zakładasz, że nikt inny też nie testuje. To ryzykowne założenie.

Więcej o konkretnych technikach obrony znajdziesz w artykule o wielowarstwowych zabezpieczeniach AI.