Jak dobrze zaprojektować Human-in-the-Loop (HITL): wzorce zatwierdzania dla agentów AI

Human-in-the-Loop (HITL) oznacza celowe wbudowanie zatwierdzeń przez człowieka w łańcuch działań agenta AI. Gdy działanie jest nieodwracalne, kosztowne lub istotne prawnie, człowiek sprawdza je i zatwierdza, zanim agent je wykona. HITL to operacyjna realizacja nadzoru ze strony człowieka, którego wymaga art. 14 unijnego AI Act, a zarazem kluczowy środek zaradczy wobec ryzyka agentowego OWASP ASI09 (Human-Agent Trust Exploitation).

• Kiedy HITL jest potrzebny: przed działaniami nieodwracalnymi, kosztownymi lub istotnymi prawnie, a nie przed każdym krokiem.
• Jakie są wzorce: Pre-Action Approval, Checkpoint Approval i Escalation-on-Anomaly, zwykle łączone.
• Co najczęściej idzie nie tak: bramka degeneruje się do bezrefleksyjnego zatwierdzania (automation bias). UX i audyt muszą aktywnie temu zapobiegać.

Dlaczego naiwna autonomia jest problemem bezpieczeństwa

Systemy agentowe planują, wnioskują, wybierają narzędzia i działają przy minimalnym potwierdzaniu przez człowieka krok po kroku. Właśnie ta autonomia powiększa powierzchnię ataku. Wpis OWASP ASI02 (Tool Misuse & Exploitation) wymienia tryby automatycznego zatwierdzania, czyli tryby „YOLO”, które wyłączają okna potwierdzeń, jako osobny wektor ataku. Nasza rekomendacja: wyłącz automatyczne zatwierdzanie dla każdego narzędzia, które dotyka baz danych, płatności, komunikacji lub wdrożeń, i zastąp je bramkami Human-in-the-Loop.

HITL nie jest więc wygodą UX, lecz mechanizmem kontroli bezpieczeństwa. Ogranicza szkody, gdy przejęcie celu (ASI01), zatruta pamięć (ASI06) lub skompromitowany łańcuch dostaw (ASI04) skłoni agenta do działania wbrew intencjom jego operatorów.

Kiedy potrzebne jest zatwierdzenie przez człowieka?

Decyzja „bramka: tak czy nie” nie powinna zapadać doraźnie, lecz wynikać z udokumentowanej klasyfikacji ryzyka. Trzy kryteria obejmują większość przypadków:

• Nieodwracalność. Czy działania nie da się cofnąć albo da się je cofnąć tylko dużym nakładem pracy? Usunięcia, wypłaty, wysyłka do klientów, nastawy produkcyjne.
• Koszty. Czy działanie generuje znaczne lub trudne do ograniczenia koszty? Masowe wywołania API, zamówienia, provisioning infrastruktury.
• Istotność prawna. Czy działanie wywołuje skutki prawne lub dotyczy danych osobowych? Umowy, decyzje kredytowe lub decyzje o świadczeniach, zgłoszenia podejrzanych transakcji, eksport danych podstawowych.

Z kolei operacje polegające tylko na odczycie lub łatwo odwracalne działania w sandboksie z reguły nie wymagają bramki. W przeciwnym razie pojawia się „zmęczenie zatwierdzaniem”, a weryfikujący z czystego znużenia zatwierdzają wszystko bez sprawdzania.

Wzorce HITL: Pre-Action, Checkpoint, Escalation

Trzy podstawowe wzorce obejmują większość architektur i w praktyce są łączone.

Pre-Action Approval. Agent zatrzymuje się tuż przed pojedynczym krytycznym działaniem. Planowane działanie wraz z argumentami trafia do kolejki zatwierdzeń; wykonanie następuje dopiero po zgodzie człowieka. Sprawdza się przy pojedynczych operacjach wysokiego ryzyka (zlecenie płatności, wysłanie umowy).

Checkpoint Approval. W wieloetapowych planach człowiek weryfikuje przebieg w określonych kamieniach milowych, zanim ruszy kolejny segment. Sprawdza się w dłuższych workflow, w których pojedyncze kroki same w sobie są nieszkodliwe, ale skumulowana ścieżka staje się krytyczna. Wzorzec odpowiada na opisany przez OWASP schemat „gotowanej żaby”, w którym każdy krok wydaje się wiarygodny, ale cała trajektoria jest szkodliwa.

Escalation-on-Anomaly. Agent działa autonomicznie i angażuje człowieka dopiero wtedy, gdy zadziałają progi lub detektory anomalii: nietypowa częstotliwość wywołań narzędzi, destrukcyjne operacje krótko po przyjęciu treści z zewnątrz, przekroczenia limitów żądań (rate limit). Technicznie można to zrealizować za pomocą policy-as-code (np. z Open Policy Agent (OPA) lub Cedar) jako bramkę zatwierdzania użycia narzędzi.

Skuteczna architektura HITL stopniuje zaufanie: decyzje o większym wpływie wymagają większej liczby weryfikujących lub mocniejszych dowodów („graduated trust”). Według OWASP kluczowe jest, aby bramka wymagała niezależnej weryfikacji dowodów, a nie tylko rekomendacji agenta.

Macierz działanie-ryzyko-HITL

Poniższa macierz pokazuje przykładowo, jak można klasyfikować działania. Ma służyć jako szablon; konkretne progi każda organizacja musi dopasować do swojego apetytu na ryzyko.

Najczęstszy błąd: bramka się degeneruje

Największym ryzykiem nie jest brak bramki, lecz jej postępująca erozja. OWASP ujmuje to jako osobne ryzyko z listy Top 10: ASI09 (Human-Agent Trust Exploitation). Agenci generują dopracowane, autorytatywnie brzmiące odpowiedzi; ludzie mają skłonność, by je po prostu przejmować. Warstwa nadzoru pomyślana jako mechanizm kontroli bezpieczeństwa sama staje się w ten sposób słabym punktem.

Kluczowe mechanizmy:

• Automation bias: odpowiedź jest akceptowana bez krytycznej weryfikacji.
• Uległość wobec autorytetu: pewny ton zniechęca do zadawania pytań.
• Stopniowa eskalacja zaufania: agent buduje wiarygodność poprawnymi odpowiedziami, zanim pojawią się zmanipulowane.
• Przeciążenie poznawcze: wolumen i złożoność przekraczają ludzkie możliwości weryfikacji.
• „Dopracowana halucynacja”: pewna siebie, fałszywa i przekonująca odpowiedź.

Sygnały, po których można zmierzyć degradację: czas decyzji osób weryfikujących spada mimo niezmiennej złożoności zadań, a wzorce zatwierdzeń skrajnie silnie korelują z rekomendacją agenta. Jedno i drugie wskazuje na zatwierdzanie bez sprawdzania.

UX, który wymusza weryfikację

Od interfejsu zależy, czy HITL w ogóle działa. Goły przycisk „Zatwierdź” zachęca do bezmyślnego przyklepywania. Pomagają tu wzorce force engagement, które wymuszają rzeczywistą weryfikację:

• Widoczne rozumowanie. Uzasadnienie, pochodzenie źródeł i przedziały ufności trzeba pokazywać, a nie ukrywać. Według OWASP ukrywanie śladu rozumowania w UI jest właśnie jednym z sygnałów wykrywania ASI09.
• Oznaczanie odpowiedzi adwersaryjnych. Komunikaty w stylu „ta odpowiedź mogła być pod wpływem treści zewnętrznych” tam, gdzie treści pochodzą z niezaufanych źródeł.
• Wymuszone opóźnienie. Przy zatwierdzeniach wysokiego ryzyka celowe opóźnienie, które zapobiega odruchowemu potwierdzaniu.
• Szkolenia z automation bias dla osób weryfikujących i okresowe testowe wstrzyknięcia („ćwiczenia przeciwpożarowe”), które sprawdzają, czy HITL w ogóle jeszcze działa.

Przykładowy scenariusz: kaskada zakupowa

Scenariusz pozwala zobaczyć, jak zawodzi HITL. Załóżmy, że agent zakupowy przez trzy tygodnie jest stopniowo przekonywany, że jego limit zatwierdzania wynosi 500 000 USD. Następnie atakujący składa w dziesięciu transakcjach fałszywe zamówienia na łączną kwotę 5 mln USD. Człowiek zatwierdzający wierzy agentowi, który coraz dobitniej twierdzi, że ma uprawnienia do wyższych kwot. Podręcznikowy przypadek ASI09, wzmocniony przez kaskadowe błędy (ASI08).

W pseudokodzie skuteczną bramkę Pre-Action można by naszkicować tak:

```text
on agent_action(action):
risk = classify(action) # odwracalność, koszty, prawo
if risk in {WYSOKIE, KRYTYCZNE}:
evidence = gather_provenance(action) # źródła, pewność, rozumowanie
approver = route_by_amount(action) # >limit -> cztery oczy / eskalacja
decision = require_human(evidence,
enforce_delay=True,
show_reasoning=True)
audit_log.write_worm(action, evidence, decision) # podpisane
if not decision.approved: abort()
execute(action)
```

Ważne: limit (route_by_amount) znajduje się poza pamięcią agenta i jest chroniony przed manipulacją. W przeciwnym razie agent sam przestawi sobie limit, jak w przykładzie.

Audyt: bez logów nie ma nadzoru

Nadzór ze strony człowieka jest wiarygodny tylko wtedy, gdy da się go udowodnić. Jako minimum na potrzeby analizy śledczej w logu każdego działania agenta powinny się znaleźć: pełny prompt (użytkownik, system, wstrzyknięty kontekst), wersja modelu i hash konfiguracji, sekwencja wywołań narzędzi z argumentami, zapytania retrieval i identyfikatory dokumentów, odpowiedź i uzasadnienie decyzji, zdarzenia ręcznej interwencji człowieka, operacje odczytu i zapisu pamięci oraz koszty i latencja.

Sprawdzają się logi WORM (write-once-read-many) i podpis kryptograficzny, który pozwala wykryć manipulacje. W kwestii przechowywania unijny AI Act ustala dolną granicę dla systemów wysokiego ryzyka: dostawcy i podmioty stosujące muszą przechowywać automatycznie generowane logi, w zakresie, w jakim mają nad nimi kontrolę, przez co najmniej sześć miesięcy (art. 19, art. 26 ust. 6), o ile prawo Unii lub prawo krajowe nie stanowi inaczej. Jeśli agent uruchamia operacje biznesowe, na przykład zamówienia lub płatności, do dowodów księgowych i korespondencji handlowej stosuje się dodatkowo okresy przechowywania wynikające z prawa handlowego, w Austrii siedem lat zgodnie z § 212 UGB. Te logi są jednocześnie Twoim dowodem dla audytorów, że HITL działa w praktyce.

Odniesienie do regulacji (to nie porada prawna)

Unijny AI Act w art. 14 wymaga skutecznego nadzoru ze strony człowieka nad systemami AI wysokiego ryzyka. Ust. 4 lit. b wprost wymienia automation bias, czyli dokładnie mechanizm stojący za OWASP ASI09. Ten obowiązek projektowy spoczywa na dostawcy: musi on zbudować system wraz z interfejsem człowiek-maszyna tak, aby osoby sprawujące nadzór mogły rozpoznać automation bias i interweniować. Podmiot stosujący musi zgodnie z art. 26 ust. 2 wyznaczyć osoby sprawujące nadzór, które mają niezbędne kompetencje, przeszkolenie i uprawnienia. Kto sam buduje i wdraża agentów, pełni obie role.

Uzupełniająco BSI i francuska agencja ANSSI opublikowały w sierpniu 2025 roku dokument Design Principles for LLM-based Systems with Zero Trust. Omawia on m.in. uwierzytelnianie i autoryzację, sandboxing oraz monitoring, a w krytycznych przypadkach wymaga zgody użytkownika jako elementu Human-in-the-Loop.

Uwaga: ten artykuł jest analizą merytoryczno-techniczną i nie zastępuje porady prawnej. To, czy Twój konkretny system jest uznawany za AI wysokiego ryzyka w rozumieniu unijnego AI Act i jakie obowiązki z tego wynikają, należy wyjaśnić z wykwalifikowanym doradcą prawnym.

Dla agencji i decydentów B2B

Kto buduje agentów dla klientów lub wdraża je we własnej firmie, powinien traktować HITL nie jako funkcję dodawaną później, lecz jako decyzję architektoniczną. Konkretnie: macierz działanie-ryzyko jako element każdego projektu agenta, stopniowane zatwierdzenia zamiast ogólnego automatycznego zatwierdzania, UI typu force engagement przeciw automation bias i odporne na manipulacje logi audytowe od samego początku. Blck Alpaca z Wiednia pomaga firmom w całej Europie projektować agentowe workflow tak, aby autonomia i nadzór ze strony człowieka były we właściwej równowadze: bezpiecznie, w sposób weryfikowalny i zgodnie z unijnym AI Act oraz OWASP Agentic Top 10.