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.
- Dlaczego AI testuje się inaczej
- Red teaming dla AI
- Co testować – lista kontrolna
- Automatyczne skanery
- Metryki sukcesu
- 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:
| Wymiar | Co testujesz | Przykłady ataków |
| Bezpieczeństwo | Ochrona danych i systemu | Prompt injection, eksfiltracja, jailbreaking |
| Odpowiedzialność | Etyczne zachowanie AI | Treś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:
- Model bazowy – testuj sam model, bez twojej aplikacji. Jakie są jego wrodzone słabości?
- 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:
# 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_probesGarak ma wbudowane dziesiątki kategorii testów: od prompt injection przez jailbreaking po próby generowania złośliwego kodu.
| Kategoria | Co testuje | Typ zagrożenia |
| encoding | Obejście filtrów przez kodowanie | Prompt injection |
| dan | Jailbreaki typu DAN | Jailbreaking |
| promptinject | Wstrzyknięcie instrukcji | Prompt injection |
| leakreplay | Wyciek danych treningowych | Eksfiltracja |
| xss | XSS przez LLM | Bezpieczeń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:
- Przy każdej zmianie promptu systemowego – uruchom podstawowy zestaw testów
- Przy każdej nowej integracji – pełny test narzędzia
- 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.

