Kiedy agent AI wymaga zatwierdzenia człowieka?

Nie przy każdym kroku. Jeżeli człowiek ma potwierdzać każdy odczyt i każde niskiego ryzyka wywołanie, szybko zacznie klikać mechanicznie. Zatwierdzenie ma sens tam, gdzie błąd agenta może uruchomić realny skutek: finansowy, zewnętrzny, administracyjny, prawny, bezpieczeństwa albo trudny do cofnięcia.

Najważniejsze jest też coś innego: poziomu kontroli nie powinno się ustalać na podstawie tego, jak pewnie brzmi model. Pewny model nadal może się mylić. Kontrolę dobieramy do skutku operacji.

Model decyzji: pięć pytań przed przyznaniem autonomii

Dla każdego działania agenta sprawdzamy pięć cech.

1. Czy operacja zmienia stan?

Odczyt jest zwykle mniej ryzykowny niż zapis. Nie zawsze — odczyt może ujawnić dane wrażliwe — ale rozróżnienie read/write jest dobrym punktem startu.

2. Czy skutek wychodzi poza system wewnętrzny?

Wysłanie e-maila, publikacja posta, uruchomienie reklamy, wystawienie dokumentu albo odpowiedź klientowi są widoczne na zewnątrz. Błąd staje się natychmiast problemem relacji, kosztu lub reputacji.

3. Czy operacja uruchamia koszt albo zobowiązanie?

Agent może poprawnie wykonać API call i jednocześnie podjąć złą decyzję biznesową. Budżet, zakup, płatność, subskrypcja czy rezerwacja zasobu wymagają osobnej granicy.

4. Czy zmianę można łatwo cofnąć?

Zmiana etykiety i usunięcie konta nie należą do tej samej klasy. Liczy się koszt odwrócenia, czas, utrata danych i wpływ na innych użytkowników.

5. Czy operacja zmienia bezpieczeństwo lub uprawnienia?

Nadanie roli administratora, rotacja sekretu, otwarcie dostępu publicznego czy zmiana zasad MFA zasługują na kontrolę nawet wtedy, gdy technicznie są odwracalne.

Praktyczna macierz autonomii

Poziom	Charakter działania	Przykłady	Domyślna decyzja
A — autonomiczne	odczyt, niski wpływ, zakres ograniczony	status usługi, raport kosztów, lista zadań	agent może wykonać sam
B — autonomiczne z audytem	odwracalny zapis w zamkniętym zakresie	dodanie tagu, zapis draftu, utworzenie zadania	agent może wykonać przy jawnych uprawnieniach i logu
C — approval before effect	skutek zewnętrzny, finansowy lub istotna zmiana	wysłanie wiadomości, publikacja, uruchomienie kampanii	człowiek zatwierdza konkretną operację
D — silna kontrola	destrukcyjne, bezpieczeństwa, trudne do cofnięcia	usunięcie danych, zmiana admina, odwołanie klucza	osobny scope + zatwierdzenie + preview; często dodatkowa weryfikacja

To jest model operacyjny, nie standard prawny. Dla konkretnego systemu poziomy trzeba dostosować do danych, regulacji, konsekwencji i sposobu odwracania zmian.

Zatwierdzenie powinno dotyczyć konkretnego skutku

Najgorszy dialog approval wygląda tak:

Agent chce wykonać akcję. Kontynuować? Tak / Nie.

Człowiek nie wie, co faktycznie autoryzuje.

Lepszy preview pokazuje:

Operacja: ENABLE CAMPAIGN
Konto: Brillnet Ads / [czytelny identyfikator]
Kampania: Search — Pulsar CRA
Budżet dzienny: 80 PLN
Target: Polska
Zmiana: PAUSED → ENABLED
Odwracalność: tak, kampanię można ponownie wstrzymać
Skutek: od zatwierdzenia kampania może generować koszt
Źródło decyzji: zadanie #...

Dopiero pod takim opisem przycisk „Zatwierdź” ma sens.

Approval nie może być ogólną przepustką na przyszłość

Jeżeli człowiek zatwierdził:

wyślij tę wiadomość do 12 odbiorców

a agent po zatwierdzeniu zmieni treść lub listę na 1200 odbiorców, zgoda nie powinna nadal obowiązywać.

Praktyczna zasada brzmi:

zatwierdzenie jest związane z konkretną, znormalizowaną operacją. Materialna zmiana parametrów unieważnia zgodę i wymaga nowego zatwierdzenia.

W implementacji można to osiągnąć przez powiązanie approval ID z hashem parametrów operacji, wersją zasobu albo innym stabilnym identyfikatorem treści do zatwierdzenia.

Model nie powinien sam oceniać, czy może ominąć approval

Można poprosić model, żeby ocenił ryzyko. To bywa użyteczne jako sygnał. Nie powinno być jednak jedyną kontrolą.

Jeżeli zasada brzmi:

gdy model uzna operację za ryzykowną, zapyta człowieka

to model kontroluje również mechanizm, który ma ograniczać skutki jego własnego błędu.

Lepszy układ:

model wybiera narzędzie i parametry
↓
gateway klasyfikuje operację według jawnej polityki
↓
policy engine: wymagane / niewymagane zatwierdzenie
↓
człowiek zatwierdza, jeśli wymagane
↓
dopiero potem wykonanie

Model może dostarczyć opis i uzasadnienie. Ostateczna klasyfikacja powinna wynikać z zasad systemu.

Przykład z własnej automatyzacji: przygotowanie kampanii ≠ uruchomienie wydatku

W wewnętrznym Brillnet Ads MCP rozdzielamy możliwość przygotowania lub zmiany kampanii od uruchomienia wydatku.

Nowa kampania, jeśli nie podano innego statusu, powstaje jako PAUSED. Sam zapis konfiguracji nie oznacza zgody na rozpoczęcie wydawania pieniędzy. Uruchomienie działania wymaga jawnego zakresu operacyjnego i potwierdzenia.

To jest drobne rozdzielenie, które daje duży efekt:

• agent może wykonać większość pracy przygotowawczej;
• człowiek nie musi ręcznie klikać każdego pola;
• budżet nie startuje tylko dlatego, że model uznał konfigurację za gotową.

Ten sam wzorzec można przenieść na inne procesy:

Przygotowanie	Skutek wymagający osobnej decyzji
draft e-maila	wysłanie
projekt roli użytkownika	nadanie dostępu
plan migracji	wykonanie migracji
lista plików do usunięcia	usunięcie
propozycja zmiany ceny	publikacja nowej ceny
gotowy przelew	autoryzacja płatności

Kiedy approval może być zbędny

Nie każda automatyzacja musi być półautomatyczna.

Zgoda człowieka zwykle niewiele wnosi, gdy wszystkie warunki są spełnione:

• operacja jest tylko odczytem albo ma niski wpływ;
• agent działa w wąskim, wcześniej zatwierdzonym zakresie;
• dane wyjściowe nie są automatycznie publikowane;
• błąd można łatwo wykryć i naprawić;
• nie ma wydatku ani zobowiązania;
• nie są zmieniane uprawnienia lub ustawienia bezpieczeństwa;
• działanie zostawia ślad pozwalający odtworzyć wynik.

Przykład: agent codziennie pobiera stan kampanii i tworzy wewnętrzny raport. Zmuszanie człowieka do zatwierdzenia każdego odczytu nie zwiększa bezpieczeństwa proporcjonalnie do kosztu obsługi.

Kiedy approval jest obowiązkowym minimum

W naszych projektach nie dawałbym autonomii bez osobnej analizy dla operacji, które:

• wysyłają komunikację do klienta lub publicznie;
• rozpoczynają albo zwiększają wydatek;
• usuwają lub nadpisują dane bez prostej ścieżki odzyskania;
• nadają, rozszerzają lub odbierają uprawnienia;
• modyfikują sekrety, konfigurację bezpieczeństwa lub MFA;
• akceptują warunki prawne w imieniu organizacji;
• wykonują akcję na niejednoznacznie zidentyfikowanym zasobie;
• uruchamiają kolejny system, który sam może wykonać działania wysokiego wpływu.

To nie znaczy, że człowiek musi zawsze być jedyną kontrolą. Dla działań krytycznych approval powinien być jedną z kilku warstw.

Uwaga na „approval fatigue”

Jeżeli system prosi o zgodę 80 razy dziennie, użytkownik przestaje czytać komunikaty. Po pewnym czasie approval staje się CAPTCHA dla pracownika.

Najczęściej oznacza to jeden z trzech błędów projektowych:

1. klasyfikacja ryzyka jest zbyt szeroka;
2. workflow nie grupuje logicznie powiązanych zmian;
3. agent ma zbyt mało bezpiecznej autonomii w niskim ryzyku, więc wszystko eskaluje.

Rozwiązaniem nie jest ukrycie ostrzeżeń, tylko lepsze granice.

Jak powinien wyglądać dobry mechanizm zatwierdzania

Pokazuje różnicę, nie cały obiekt

Dla konfiguracji pokaż before → after i pola, które się zmieniają. Nie każ czytelnikowi porównywać dwóch ekranów ręcznie.

Pokazuje skutek

„Zapisz zmianę” jest słabsze niż „Włącz kampanię — od tej chwili może generować koszt do 80 PLN/dzień”.

Ma ważność czasową i zakres

Stare approval nie powinno wiecznie odblokowywać operacji po zmianie kontekstu.

Nie akceptuje zmienionej operacji

Jeśli parametry po zatwierdzeniu różnią się materialnie, approval musi wygasnąć.

Zostawia niezależny zapis

Audyt powinien zawierać: kto zatwierdził, co, kiedy i z jakim identyfikatorem operacji. Nie tylko wiadomość modelu „użytkownik się zgodził”.

Więcej: Ślad audytowy agentów AI

Checklista dla pojedynczej akcji

Przed nadaniem agentowi autonomii odpowiedz:

• Czy akcja jest read-only?
• Czy zmienia stan biznesowy?
• Czy generuje koszt lub zobowiązanie?
• Czy rezultat jest widoczny na zewnątrz?
• Czy dotyczy danych osobowych lub poufnych?
• Czy zmienia role, uprawnienia albo security config?
• Czy jest łatwo odwracalna?
• Czy system jednoznacznie identyfikuje zasób docelowy?
• Czy retry może wykonać akcję drugi raz?
• Czy przed wykonaniem można pokazać konkretny preview?
• Czy approval będzie związany z dokładnymi parametrami?
• Czy po wykonaniu można sprawdzić rzeczywisty stan?

Jeżeli operacja łączy kilka wysokich ryzyk, samo „OK” użytkownika może być za słabą kontrolą.

Źródła

• OWASP AI Agent Security Cheat Sheet — m.in. excessive autonomy, high-impact actions, explicit approval, preview, audit i rollback.
• NIST AI Risk Management Framework — rama zarządzania ryzykiem AI.

Granica

Ten model klasyfikacji jest naszą praktyką projektową, nie poradą prawną ani formalnym standardem oceny ryzyka. Proces regulowany, medyczny, finansowy lub związany z bezpieczeństwem może wymagać ostrzejszych zasad.

Zobacz również MCP i agenci AI: jak projektować bezpieczne narzędzia oraz Najmniejsze uprawnienia dla agentów AI.