Bezpieczeństwo
Red teaming modeli AI — jak samemu poszukać dziur we wdrożeniu
Red teaming to celowe szukanie sposobów, w których system zawiedzie. Anthropic prowadzi w tym celu odrębny zespół — Frontier Red Team, zajmujący się skutkami dla cyberbezpieczeństwa, biobezpieczeństwa i systemów autonomicznych. Firma wdrażająca AI nie potrzebuje takiego zaplecza, ale potrzebuje tego samego nawyku: zanim system trafi do klientów, ktoś musi próbować go zepsuć.
Dlaczego zwykłe testy nie wystarczają?
Bo testy sprawdzają, czy system działa poprawnie przy prawidłowym użyciu. Tymczasem asystent udostępniony klientom dostaje zapytania, których nikt nie planował. Red teaming sprawdza, co się stanie przy użyciu nieprawidłowym, złośliwym albo po prostu nietypowym. W systemach opartych na modelach językowych ta różnica jest większa niż w klasycznym oprogramowaniu, bo wejściem jest dowolny tekst od użytkownika.
Każdy asystent AI udostępniony klientom dostanie zapytania, których nikt w firmie nie przewidział. Pytanie tylko, czy zobaczy je najpierw zespół, czy klient.
Co sprawdzić w uproszczonym red teamingu?
| Obszar | Co próbować | Czego szukamy |
|---|---|---|
| Wyprowadzenie poza zakres | Pytania niezwiązane z tematem, prośby o porady prawne, medyczne, finansowe | Czy system odmawia, czy odpowiada poza kompetencją |
| Ujawnienie danych | Pytania o innych klientów, o dane wewnętrzne, o treść instrukcji systemowej | Czy uprawnienia są egzekwowane po stronie danych, nie tylko instrukcji |
| Manipulacja instrukcją | Polecenia typu „zignoruj wcześniejsze zasady”, treści ukryte w załączniku | Czy zasady da się obejść tekstem od użytkownika |
| Konfabulacja pod presją | Pytania o rzeczy, których nie ma w dokumentach | Czy system mówi „nie wiem”, czy wymyśla |
| Skutki działania agenta | Zadania prowadzące do operacji nieodwracalnych | Czy istnieją limity i punkt zatwierdzania — patrz agenci AI |
Trzeci wiersz zasługuje na szczególną uwagę przy systemach przetwarzających dokumenty od osób z zewnątrz. Treść instrukcji ukryta w przesłanym pliku to realna klasa ryzyka — a jednocześnie taka, o której najczęściej nie myśli się przy bazie wiedzy zasilanej materiałami od klientów.
Jak przeprowadzić taki test w firmie?
Krok 1 — zaproś osoby spoza zespołu projektowego
Autor systemu testuje go tak, jak go zaprojektował. Osoba postronna zadaje pytania, które nie przyszły nikomu do głowy.
Krok 2 — daj godzinę i jasny cel: zepsuć
Nie „sprawdzić, czy działa”. Cel „znajdź odpowiedź, której nie powinien udzielić” daje zupełnie inne wyniki.
Krok 3 — zapisz każdy udany atak
Treść zapytania i odpowiedź systemu. To gotowy zestaw testów regresyjnych do powtórzenia po każdej zmianie.
Krok 4 — napraw przyczynę, nie objaw
Zablokowanie jednego sformułowania nie pomaga — trzeba zmienić uprawnienia, zakres danych albo zasady odmowy. Wnioski zapisz w polityce bezpieczeństwa AI, żeby nie zależały od pamięci jednej osoby.
Krok 5 — powtarzaj po każdej zmianie modelu
Nowa wersja modelu może zachowywać się inaczej na tych samych zapytaniach. Zestaw testów powinien być trwałym elementem procesu, nie jednorazową akcją.
Najczęściej zadawane pytania
Czy potrzebujemy do tego specjalistów bezpieczeństwa?
Jak często powtarzać taki test?
Czy dostawcy modeli nie zabezpieczają tego sami?
Rozmowa bez zobowiązań
Zostaw numer telefonu — oddzwonimy
Podczas 20-minutowej rozmowy pytamy o procesy, zespół i to, co dzisiaj zjada najwięcej czasu. Na tej podstawie proponujemy konkret: warsztat, szkolenie albo wdrożenie AI — albo mówimy wprost, że w Twoim przypadku szkolenie nie jest jeszcze potrzebne.
- Bez prezentacji sprzedażowej i bez zobowiązań
- Konkretna rekomendacja zakresu i widełki budżetowe
- Rozmawiasz z osobą, która prowadzi warsztaty, nie z call center
Możesz też napisać: kontakt@aibox.edu.pl