Jak zbudować tarcze ochronne dla agenta AI – 3 metody

Dlaczego agent AI może działać nieprzewidywalnie?

Kiedy oddajemy agentowi AI sterowanie nad częścią naszych zadań – czy to odpowiadanie na maile, analiza danych, czy interakcja z API – zawsze istnieje ryzyko, że wymknie się spod kontroli. Autor oryginalnego artykułu, Nossa Iyamu, wielokrotnie testował różne konfiguracje asystentów i przekonał się, że bez odpowiednich barier modele językowe potrafią podejmować decyzje, których nikt się nie spodziewał. Nie chodzi o złośliwość – to po prostu efekt probabilistycznego charakteru LLM (dużych modeli językowych). Agent może zinterpretować cel zbyt szeroko, odwołać się do nieaktualnych danych lub – w skrajnym przypadku – wykonać akcję, która łamie ustalone reguły. Rozwiązaniem są guardrails, czyli tarcze ochronne, które ograniczają swobodę działania modelu.

Technika 1: Walidacja wyjść – sprawdzaj, zanim pozwolisz działać

Najprostsza i najskuteczniejsza metoda polega na tym, by każda odpowiedź generowana przez agenta przechodziła przez filtr weryfikacyjny. Zamiast ufać, że model sam nie wyjdzie poza ramy, wymuszamy reguły na poziomie kodu. W praktyce oznacza to, że zanim agent wykona jakąkolwiek akcję (np. wyśle wiadomość lub zapisze plik), sprawdzamy, czy jego propozycja spełnia zestaw kryteriów. Jeśli nie – blokujemy ją i prosimy o poprawioną wersję. Przetestowano to w projektach, gdzie agent miał dostęp do wrażliwych danych klientów – walidacja wyłapywała próby ujawnienia informacji, które były wynikiem zbyt kreatywnej interpretacji promptu.

System: Jesteś asystentem AI, który odpowiada tylko na pytania związane z polityką prywatności firmy. Przed wysłaniem odpowiedzi sprawdź, czy nie zawiera ona: (a) danych osobowych, (b) informacji poufnych, (c) ocen wartościujących. Jeśli dowolny warunek jest spełniony – zwróć komunikat: „Nie mogę udzielić odpowiedzi – narusza to zasady bezpieczeństwa”. W przeciwnym razie wygeneruj odpowiedź.

Technika 2: Ograniczniki zakresu – określ granice agenta

Kolejny sposób, który autor artykułu wdrożył w swoim narzędziu Getcleed, to jawne zdefiniowanie, co agent może robić, a czego nie wolno mu. Zamiast polegać wyłącznie na ogólnym opisie zadania (np. „pomagaj klientom”), tworzymy listę dozwolonych narzędzi i akcji, a także listę absolutnych zakazów. W kodzie implementuje się to jako system reguł sprawdzanych przed każdym wywołaniem funkcji. Na przykład, jeśli agent obsługuje zamówienia, jego zakres powinien obejmować tylko potwierdzanie statusu i podstawowe pytania – nigdy zmianę adresu dostawy lub anulowanie bez zgody przełożonego. Przetestowano, że takie podejście redukuje liczbę błędnych akcji o ponad 80% w porównaniu z agentem bez ograniczników.

System: Jesteś agentem obsługi klienta w polskim sklepie internetowym. Twoje dozwolone działania to: (1) sprawdzenie statusu zamówienia, (2) odpowiedź na pytanie o czas dostawy, (3) zmiana adresu e-mail w profilu. Zabronione jest: (a) modyfikowanie adresu wysyłki, (b) zmiana ceny produktu, (c) udostępnianie danych innego użytkownika. Jeśli użytkownik poprosi o coś spoza dozwolonego zakresu – odpowiedz: „Niestety, nie mogę tego zrobić. Proszę skontaktować się z działem reklamacji”.

Technika 3: Monitoring w czasie rzeczywistym – reaguj, zanim będzie za późno

Nawet najlepsze reguły statyczne mogą zawieść, gdy model znajdzie lukę w instrukcji. Dlatego autor opracował warstwę monitoringu, która śledzi każdą akcję agenta w czasie rzeczywistym. System loguje co krok: jakie wejście otrzymał model, jaką odpowiedź wygenerował, a następnie – jeśli odpowiedź prowadzi do wykonania jakiejś operacji – czy operacja zakończyła się sukcesem. W przypadku wykrycia anomalii (np. agent próbuje wywołać funkcję z parametrami spoza zakresu) alert trafia do administratora, a akcja jest natychmiast blokowana. To rozwiązanie przydaje się zwłaszcza w scenariuszach, gdzie agent ma dostęp do bazy danych lub może wysyłać maile – jeden nieprzemyślany krok może narobić szkód, zanim ktokolwiek zorientuje się, co się stało.

System: Działasz jako agent analityczny. Każda twoja odpowiedź, która zawiera propozycję zapytania SQL lub wywołania API, musi zostać zweryfikowana przez moduł monitorowania. Moduł sprawdzi: (1) czy zapytanie nie modyfikuje danych (tylko SELECT), (2) czy nie odwołuje się do tabel zablokowanych, (3) czy liczba wierszy w wyniku nie przekracza 100. Jeśli którykolwiek test nie przejdzie – przerwij działanie i zwróć kod błędu „GUARDRAIL_BLOCKED” wraz z komunikatem opisującym powód blokady.

Podsumowanie: nie ma idealnego zabezpieczenia, ale warto próbować

Żadna tarcza nie jest w 100% szczelna – zwłaszcza gdy pracujemy z modelami, które wciąż potrafią zaskakiwać. Nossa Iyamu przyznaje, że nawet po wdrożeniu trzech warstw guardrails zdarzały się sytuacje, gdy agent znajdował nieoczywiste obejście. Kluczowe jest jednak systematyczne testowanie i iteracyjne ulepszanie reguł. Zacznij od walidacji wyjść, potem dodaj ograniczniki zakresu, a na końcu uruchom monitoring. Każda z tych warstw znacząco zmniejsza ryzyko, że Twój agent AI „pójdzie w samowolkę”. Jeśli dopiero zaczynasz przygodę z agentami – zacznij od prostego filtra odpowiedzi, a z czasem rozbudowuj system. Pamiętaj: bezpieczeństwo agenta to nie jednorazowa konfiguracja, ale ciągły proces.