Jeden z naszych klientów — firma produkcyjna ze średniej wielkości systemem ERP — wdrożył agenta AI do przetwarzania zamówień. Przez pierwsze trzy tygodnie działał wzorowo: grupował zapytania, weryfikował dostępność i generował propozycje. Potem trafił na przypadek, którego nie było w danych treningowych — klient z niestandardowymi warunkami płatności. Agent ocenił sytuację jako standardową i potwierdził zamówienie. Bez zatwierdzenia. Bez eskalacji. Z błędnymi warunkami.
Agentowi nie przyszło do głowy, żeby się zatrzymać i zapytać. Po prostu nie miał do tego reguł.
To nie jest argument przeciwko agentom AI. To argument za przemyślanym human-in-the-loop (HITL) — zestawem reguł określających, kiedy agent działa samodzielnie, a kiedy czeka na człowieka. Ten artykuł to praktyczna ramka decyzyjna: gdzie postawić granicę, jak technicznie zaimplementować approval flow i jak stopniowo oraz bezpiecznie rozszerzać autonomię agenta.
Dlaczego HITL to nie jest tylko "plaster bezpieczeństwa"
Najczęstszy błąd przy projektowaniu agentów: HITL dodawany jest na końcu jako filtr. Wyjście agenta — decyzja, akcja, dokument — przechodzi przez okno zatwierdzenia, a jeśli człowiek kliknie "OK", idzie dalej.
Takie podejście leczy tylko objaw. Nie widać, co agent robił wcześniej. Nie wiadomo, czy decyzja logicznie wynikała z właściwych kroków, czy agent doszedł do właściwego wyniku złą drogą. A gdy coś pójdzie nie tak, audit trail jest pusty.
Właściwy HITL to wzorzec architektoniczny, nie dodatek. Definiuje się go przed wdrożeniem, a nie po pierwszym incydencie. Obejmuje:
- Klasyfikację akcji według poziomu ryzyka i nieodwracalności
- Explicite punkty przerwania w grafie agenta — nie tylko na wyjściu, lecz bezpośrednio w toku podejmowania decyzji
- Audit trail każdego kroku: co agent widział, co zdecydował, kto zatwierdził
EU AI Act w artykule 14 wymaga nadzoru człowieka nad systemami AI wysokiego ryzyka od 2 sierpnia 2026 roku. Jeśli Państwa system należy do tej kategorii — zautomatyzowane decyzje w sprawach pracowniczych, scorowanie kredytowe, zarządzanie infrastrukturą krytyczną — HITL nie jest rekomendacją. Jest obowiązkiem prawnym.
Akcje, które zawsze wymagają zatwierdzenia
Nie każda akcja agenta niesie takie samo ryzyko. Kluczowe kryterium to nieodwracalność: czy można cofnąć akcję? Jeśli nie — zatwierdzenie jest obowiązkowe.
Drugie kryterium to zakres oddziaływania: kogo dotyka akcja, ile pieniędzy lub danych jest w grze, jaka jest ekspozycja regulacyjna?
Akcje, przy których zalecamy zawsze zatrzymać się i poprosić o zatwierdzenie:
- Transakcje finansowe — wysłanie płatności, wystawienie faktury, zmiana cennika, zamówienie u dostawcy powyżej zdefiniowanego limitu
- Nieodwracalne operacje na danych — usuwanie rekordów, tworzenie kopii zapasowej przed nadpisaniem, eksport do zewnętrznego systemu
- Komunikacja zewnętrzna w imieniu firmy — e-mail do klienta, odpowiedź na reklamację, dokument prawny
- Zmiany w systemach zewnętrznych — zapis do ERP, CRM, SCADA; zmiana konfiguracji środowiska produkcyjnego
- Decyzje eskalacyjne z ekspozycją prawną — odrzucenie reklamacji, rozwiązanie umowy, przyjęcie zobowiązania
W praktyce obserwujemy, że firmy na początku te kategorie bagatelizują. Dopóki agent operuje tylko w wewnętrznym sandboxie, wszystko wygląda bezpiecznie. Problemy pojawiają się w momencie, gdy agent uzyskuje dostęp do narzędzi produkcyjnych.
Human-on-the-loop vs. Human-in-the-loop
Ważne rozróżnienie, które wpłynie na cały projekt:
Human-in-the-loop (HITL) — agent zatrzymuje się i *czeka* na zatwierdzenie przed wykonaniem akcji. Przepływ jest zablokowany. Czas odpowiedzi zależy od dostępności operatora. Odpowiednie dla akcji nieodwracalnych lub wysokiego ryzyka.
Human-on-the-loop (HOTL) — agent działa autonomicznie, ale każdy krok loguje, a operator może interweniować asynchronicznie. Przepływ jest nieblokowany. Odpowiednie dla akcji łatwo odwracalnych lub o niskim wpływie.
Większość systemów produkcyjnych potrzebuje obu trybów. Prosty schemat decyzyjny:
- 1.Czy akcja jest nieodwracalna? → HITL obowiązkowy
- 2.Czy skutek finansowy przekracza limit (np. 1 000 EUR)? → HITL obowiązkowy
- 3.Czy istnieje ekspozycja regulacyjna (RODO, umowa, odpowiedzialność)? → HITL obowiązkowy
- 4.Czy akcja jest rutynowa i odwracalna? → HOTL wystarczy
To nie jest decyzja jednorazowa. Limity zmieniają się wraz z tym, jak agent gromadzi historię i buduje zaufanie.
Implementacja techniczna: LangGraph interrupt()
Najczystsza techniczna implementacja HITL dla agentów stanowych to LangGraph i jego mechanizm interrupt(). Zasada jest prosta: w grafie agenta definiuje się węzły, przy których przepływ zostaje wstrzymany i oczekuje na zewnętrzne wejście — zatwierdzenie, korektę, odrzucenie.
Podstawowy wzorzec:
- Agent przetwarza wejście i decyduje, jaką akcję chce wykonać
- Przed wykonaniem akcji osiąga węzeł przerwania: zapisuje bieżący stan (checkpointing), generuje opis proponowanej akcji dla operatora i czeka
- Operator otrzymuje powiadomienie (e-mail, Slack, zintegrowany panel UI)
- Po zatwierdzeniu przepływ wznawia się od dokładnego punktu kontrolnego — agent pamięta cały kontekst, nie tylko ostatnią wiadomość
- Po odrzuceniu lub korekcie agent otrzymuje informację zwrotną i może ponownie zaplanować działanie
Kluczowa właściwość checkpointingu LangGraph: stan agenta jest serializowany do trwałego magazynu. Zatwierdzenie może nadejść za godzinę lub następnego dnia — agent "przebudzi się" z pełnym kontekstem. To zasadnicza różnica w stosunku do naiwnego podejścia, w którym przerwanie trzeba by implementować ręcznie przez bazę danych i Redis.
Dla wiarygodnego audit trail każdy węzeł przerwania rejestruje: identyfikator agenta, czas, proponowaną akcję, argumenty narzędzia, a następnie również decyzję operatora i jej uzasadnienie.
Więcej o tym, jak architektury agentowe wyglądają w praktyce, opisujemy w artykule Architektury agentów AI: ReAct, Plan-and-Execute — kiedy co stosować.
Projektowanie approval flow
Dobry approval flow ma trzy cechy: kontekstowość (operator widzi, dlaczego agent proponuje daną akcję, a nie tylko jaką), szybkość odpowiedzi (im dłużej agent czeka, tym więcej zadań się blokuje) i eskalacja (jeśli operator nie odpowie w zdefiniowanym czasie, zadanie eskaluje lub jest bezpiecznie kończone).
Zalecana struktura powiadomienia dla operatora:
- Kontekst: Na czym opiera się decyzja — oryginalne żądanie, istotne dane, kroki poprzedzające akcję
- Proponowana akcja: Co dokładnie agent chce zrobić, łącznie z argumentami (np. "Zamówić 500 szt. SKU-4421 u dostawcy X w cenie Y")
- Uzasadnienie: Dlaczego agent doszedł do tej decyzji
- Alternatywy: Jeśli agent rozważał kilka opcji, należy je pokazać (ułatwia korektę)
- Akcje: Zatwierdź / Odrzuć / Popraw z komentarzem / Eskaluj
To nie jest tylko szczegół UX. Operator, który widzi jedynie "Potwierdź akcję?", zatwierdza zazwyczaj odruchowo. Operator, który widzi pełny kontekst, podejmuje świadomą decyzję — i jednocześnie buduje intuicję co do tego, gdzie agent popełnia błędy.
Tematowi bezpieczeństwa i guardrails agentów poświęcamy osobny artykuł: Guardrails dla agentów AI.
Zaufanie vs. szybkość: główny kompromis
HITL ma swoją cenę. Każdy punkt przerwania dodaje opóźnienie — oczekiwanie na odpowiedź człowieka może trwać minuty albo godziny. Jeśli agent ma dziesięć kroków i każdy czeka na zatwierdzenie, system nie jest agentem. To formularzowy workflow z fasadą AI.
Dlatego zaufanie do agenta jest skalowalną zmienną, a nie decyzją binarną.
Praktyczna ramka stopniowego rozszerzania autonomii:
Faza 1 — Uruchomienie w trybie cienia (shadow mode): Agent proponuje akcje, ale zawsze wykonuje je człowiek. Zbierane są dane: jak często agent miał rację, gdzie się mylił, jaki był kontekst błędów. Czas trwania: 2–4 tygodnie lub 100–200 akcji.
Faza 2 — Selektywna autonomia: Na podstawie danych z fazy 1 definiuje się kategorie akcji, w których agent osiągnął > 95% trafności, i przechodzi się na tryb HOTL. Monitoring jest utrzymany. Kategorie wysokiego ryzyka pozostają w HITL.
Faza 3 — Ograniczona autonomia z limitami: Autonomia w kategoriach niskiego ryzyka z explicite określonymi limitami (np. zamówienia do 500 EUR bez zatwierdzenia). Każdy limit ma uzasadnienie i datę przeglądu.
Faza 4 — Adaptacyjna autonomia: System śledzi wydajność w czasie rzeczywistym. Jeśli wskaźnik błędów przekroczy próg, automatycznie wraca do trybu bardziej restrykcyjnego. Jeśli pozostaje niski, limit może zostać rozszerzony.
To nie jest projekt jednorazowy. To ciągły proces kalibracji zaufania — podobnie jak przy wdrażaniu nowego pracownika.
Kwestię kosztów i zwrotu z inwestycji z perspektywy agentów omawiamy w artykule Koszty agenta AI w produkcji.
Czego HITL nie rozwiązuje: limity podejścia
HITL jest niezbędny, ale niewystarczający. Kilka rzeczy, których approval flow sam w sobie nie rozwiąże:
Prompt injection — atakujący umieszcza instrukcje we wejściu agenta (np. w przetwarzanym dokumencie), które agent wykonuje bez sygnału ostrzegawczego w oknie zatwierdzenia. Operator widzi "normalną" akcję, za którą stoi zmanipulowany przepływ. OWASP LLM Top 10 klasyfikuje prompt injection na pierwszym miejscu w środowiskach produkcyjnych.
Zbyt szeroki zakres narzędzi — jeśli agent ma dostęp do zbyt rozległego zestawu narzędzi, HITL chroni tylko przy akcjach explicite oznaczonych flagą. Akcje spoza jawnie monitorowanego zakresu mogą pozostać niezauważone. Rozwiązanie: zasada minimalnych uprawnień dla każdego narzędzia.
Szybkość zatwierdzania jako wąskie gardło — jeśli jeden operator zatwierdza dziesiątki żądań dziennie, jakość jego decyzji spada. Rutynowe żądania są zatwierdzane odruchowo, prawdziwe anomalie przechodzą niezauważone. HITL musi być uzupełniony o triage: nie każde zatwierdzenie jest równie ważne.
Dryf agenta — wydajność agenta zmienia się w czasie, gdy zmieniają się dane lub kontekst promptów. Akcja, która sześć miesięcy temu była bezpiecznie autonomiczna, może być dziś ryzykowna. Dlatego daty przeglądów limitów są obowiązkiem, a nie zaleceniem.
Obserwowalność agenta — śledzenie traces, wskaźnika błędów i opóźnień w czasie rzeczywistym — jest warunkiem koniecznym dla sprawnego HITL. Bez niej nie wiadomo, kiedy dryf następuje. O narzędziach do monitorowania agentów piszemy w artykule Obserwowalność agentów AI.
Praktyczne rekomendacje wdrożeniowe
Z doświadczeń z dziesiątek projektów:
- 1.Zacznij od pełnego HITL dla wszystkich akcji. Nie z ostrożności, lecz po to, żeby zbierać dane. Bez historii nie da się podejmować świadomych decyzji o tym, gdzie rozszerzyć autonomię.
- 2.Kategoryzuj akcje explicite. Listę kategorii z zdefiniowanym ryzykiem i limitem poddaj zatwierdzeniu u właściciela procesu — nie tylko u zespołu IT.
- 3.Loguj wszystko, nie tylko incydenty. Rutynowe zatwierdzenia są równie ważne dla analizy trendów jak odrzucenia.
- 4.Ustaw automatyczną eskalację. Jeśli operator nie odpowiada przez X minut, zadanie eskaluje do zastępcy lub jest bezpiecznie kończone z powiadomieniem. Oczekujący agent nigdy nie może blokować procesu produkcyjnego.
- 5.Testuj złe wejścia. Symuluj wejścia, przy których agent mógłby chcieć wykonać problematyczną akcję. Upewnij się, że przerwanie działa poprawnie.
- 6.Cykl przeglądów co 3 miesiące. Przejrzyj statystyki zatwierdzeń. Tam, gdzie wskaźnik błędów jest niski i historia dobra — rozważ rozszerzenie autonomii. Tam, gdzie pojawiają się niespodzianki — zaostrzyć.
Najczęstsze pytania
Czy musimy mieć HITL także dla wewnętrznego chatbota, który tylko odpowiada na pytania?
Jeśli agent jedynie czyta i odpowiada — żadne narzędzia z dostępem do zapisu, żadne zewnętrzne akcje — HITL nie jest konieczny. Wystarczy HOTL: monitorujesz wyjścia, ustawiasz content guardrails i masz możliwość interwencji. HITL jest istotny tam, gdzie agent *działa*, a nie tylko *odpowiada*.
Jak zapobiec zatwierdzaniu przez operatorów bez zastanowienia?
Dwie sprawdzone techniki: po pierwsze, wyświetlaj pełny kontekst (dlaczego agent proponuje daną akcję), a nie tylko samą akcję. Po drugie, dla krytycznych kategorii wymagaj od operatora krótkiego uzasadnienia zatwierdzenia — choćby jednego zdania. Obowiązkowe uzasadnienie drastycznie redukuje odruchowe zatwierdzanie.
Czy HITL może sprawić, że agent będzie zbyt wolny do użytku produkcyjnego?
Tak, jeśli jest źle zaprojektowany. Kluczem jest selektywność: HITL tylko dla naprawdę wysokiego ryzyka, wszystko inne na HOTL. W praktyce kategoria naprawdę krytycznych akcji stanowi 5–15% całkowitego wolumenu w typowym agencie biznesowym — reszta może działać autonomicznie z monitoringiem.
Co jeśli agent potrzebuje zatwierdzenia w środku długiego zadania — czy straci kontekst?
Właśnie dlatego checkpointing LangGraph jest tak istotny. Agent serializuje stan przy każdym punkcie przerwania. Jeśli zatwierdzenie nadejdzie po godzinie lub nawet następnego dnia, agent wznawia przepływ od dokładnego miejsca bez utraty kontekstu. Bez checkpointingu trzeba by restartować całe zadanie od początku.
Jak HITL ma się do EU AI Act?
Artykuł 14 EU AI Act wymaga nadzoru człowieka nad systemami AI wysokiego ryzyka. Od 2 sierpnia 2026 roku obowiązek ten dotyczy systemów w obszarach takich jak zatrudnienie, edukacja, infrastruktura krytyczna, zarządzanie dostępem do podstawowych usług i innych. Jeśli Państwa agent należy do którejś z tych kategorii, HITL nie jest wyborem — jest wymogiem prawnym, który trzeba umieć wykazać również w audycie.
*Zaprojektowanie i skonfigurowanie HITL flow dla konkretnego agenta to nie projekt na kilka tygodni — to decyzja architektoniczna, która wpłynie na cały cykl życia systemu. W MP Industrial Solutions pomagamy firmom określić, gdzie dokładnie leży granica między autonomią a nadzorem, skonfigurować approval flow odpowiadający ich środowisku regulacyjnemu i stopniowo budować zaufanie do wydajności agenta. Jeśli planujecie wdrożenie lub macie istniejącego agenta bez przemyślanego projektu HITL — zapraszamy na konsultację.*