Wyobraźcie sobie piątek, godzina 17:40. Agent AI w dziale zobowiązań przetwarza fakturę od stałego dostawcy. Kwota: 380 tysięcy złotych. Wszystko się zgadza - poza numerem rachunku, który różni się od tego z umowy. Agent ma w danych treningowych tysiące przypadków, w których dostawcy zmieniali rachunki legalnie. Klasyfikuje rozbieżność jako niskie ryzyko i przygotowuje płatność do realizacji.
Kto w tym momencie powinien dostać powiadomienie? W dobrze zaprojektowanym procesie - konkretna osoba, z pełnym kontekstem, zanim cokolwiek wyjdzie z firmy. W wielu wdrożeniach, które oglądamy na rynku - nikt. Bo autonomia agenta została ustawiona jako właściwość domyślna, a nie jako decyzja, którą ktoś świadomie podjął i ograniczył.
O tej właśnie decyzji jest ten tekst. Nazywa się bramka human-in-the-loop, w skrócie HITL gate, i naszym zdaniem to najważniejszy element architektury agentowej w 2026 roku. Ważniejszy niż wybór modelu.
Autonomia to nie cecha modelu. To decyzja architektoniczna
W rozmowach o agentach AI dominuje pytanie „co agent potrafi”. To pytanie z demo. Pytanie z produkcji brzmi inaczej: czego agentowi nie wolno zrobić samodzielnie i kto zatwierdza resztę.
Różnica jest zasadnicza. Model językowy, który napędza agenta, nie zna pojęcia odpowiedzialności. Generuje kolejne kroki na podstawie kontekstu i - co pokazujemy niżej - potrafi z pełnym przekonaniem ogłosić sukces, nie uruchomiwszy żadnej weryfikacji. Odpowiedzialność trzeba dobudować warstwę wyżej: w orkiestracji procesu i w polityce platformy.
Regulacje mówią to samo, tylko innym językiem. Artykuł 14 AI Act wymaga skutecznego nadzoru człowieka nad systemami wysokiego ryzyka - a 2 sierpnia 2026, czyli za dwa tygodnie, wchodzi kolejna fala obowiązków tego rozporządzenia. Dla podmiotów objętych NIS2 i DORA dochodzi wymóg audytowalności: każda decyzja systemu, który dotyka danych albo pieniędzy, musi zostawiać ślad, który da się pokazać audytorowi. „Agent sam tak zdecydował” nie jest wpisem do rejestru zdarzeń. Jest początkiem bardzo trudnej rozmowy.
Pisaliśmy o tym szerzej w tekście o governed autonomy - jeśli w Waszej organizacji działa już więcej niż jeden agent, tamten artykuł to dobry punkt wyjścia. Dziś schodzimy poziom niżej: do konkretnych mechanizmów w platformie UiPath.
Anatomia bramki HITL
Bramka human-in-the-loop to punkt w procesie, w którym agent zatrzymuje się i czeka na decyzję człowieka. Definicja brzmi banalnie. Diabeł siedzi w trzech pytaniach projektowych.
Kiedy bramka się otwiera? Nie przy każdym kroku - proces, w którym człowiek zatwierdza wszystko, jest wolniejszy niż praca ręczna i nikt go nie utrzyma. Bramka staje na skrzyżowaniach wysokiego ryzyka: płatność powyżej progu, zmiana danych kontrahenta, akcja na środowisku produkcyjnym, decyzja dotycząca człowieka (reklamacja, roszczenie, wniosek kredytowy). Katalog takich skrzyżowań to pierwsza rzecz, którą spisujemy z klientem - przed konfiguracją czegokolwiek.
Kto decyduje? Rola, nie osoba. Z jasną ścieżką eskalacji, gdy pierwszy adresat nie reaguje w zadanym czasie, i z limitem SLA, po którym proces nie wisi w próżni, tylko przechodzi w zdefiniowany stan bezpieczny.
Co widzi decydent? To pytanie najczęściej pomijane. Człowiek, który dostaje do zatwierdzenia goły komunikat „agent proponuje płatność, akceptujesz?”, nie sprawuje nadzoru. Klika. Bramka ma sens, gdy podaje kontekst: co agent ustalił, na jakiej podstawie, co odbiega od normy i jakie są konsekwencje obu decyzji. I gdy sama decyzja trafia do rejestru audytowego razem z tym kontekstem.
Te trzy pytania są uniwersalne. Odpowiedzi na nie w ekosystemie UiPath mieszkają w dwóch miejscach: w orkiestracji (Maestro, Action Center) i w warstwie governance (AI Trust Layer). Przejdźmy przez oba.
Maestro: człowiek jako uczestnik procesu, nie wyjątek od procesu
UiPath Maestro to warstwa orkiestracji procesów agentowych - pisaliśmy o niej, gdy wchodziła na rynek. Z perspektywy HITL najważniejsza jest jedna właściwość: w Maestro człowiek jest pełnoprawnym uczestnikiem procesu, na równi z robotem RPA i agentem AI. Etap ludzki modeluje się tak samo jak etap automatyczny: ma wejście, wyjście, kryteria sukcesu, limit czasu i ścieżkę eskalacji.
To brzmi jak szczegół notacji, ale zmienia sposób myślenia. W klasycznych wdrożeniach RPA człowiek pojawiał się w procesie jako obsługa wyjątku - coś poszło nie tak, leci mail do zespołu. W procesie agentowym zaprojektowanym w Maestro człowiek pojawia się tam, gdzie proces tego wymaga z definicji: na bramce.
W praktyce wygląda to tak. Proces obsługi faktur z naszego przykładu ma w Maestro cztery etapy. Pierwszy: agent analizuje dokument i porównuje dane z umową oraz historią dostawcy. Drugi: robot transakcyjny wykonuje księgowanie w systemie ERP - deterministycznie, powtarzalnie, z pełnym logiem. Trzeci: wszystko, co agent oznaczył jako odstępstwo, trafia do Action Center, gdzie kontroler widzi fakturę, rozbieżność i rekomendację agenta obok siebie i podejmuje decyzję. Czwarty: powiadomienia i zamknięcie obiegu. Zmiana rachunku bankowego z naszej sceny nie ma prawa ominąć etapu trzeciego - niezależnie od tego, jak pewny swojej klasyfikacji jest agent. Do tego „niezależnie” jeszcze wrócimy, bo to najczęściej łamany element całej układanki.
W naszych przeglądach architektury traktujemy to zero-jedynkowo: pipeline Maestro, który dla etapów wysokiego ryzyka nie ma punktu eskalacji do człowieka, dostaje status krytyczny i nie przechodzi do wdrożenia. Nie dlatego, że lubimy blokować projekty. Dlatego, że ten brak zawsze wychodzi na jaw - pytanie tylko, czy na przeglądzie, czy na produkcji.
Drugi przykład, bliższy naszym projektom SAP. Agent wspierający zespół Basis analizuje zgłoszenia i proponuje zmiany: odblokowanie użytkownika, korektę parametru, transport poprawki między środowiskami. Odblokowanie konta w systemie testowym może iść automatycznie, z wpisem do logu. Transport do środowiska produkcyjnego - nigdy. W Maestro ta różnica to po prostu dwie różne ścieżki procesu: jedna przechodzi przez etap ludzki, druga nie. Agent nie musi „rozumieć”, dlaczego produkcja jest inna. Proces to wie za niego.
Warto też docenić mechanikę etapu ludzkiego w Maestro, bo to ona decyduje, czy bramka przeżyje kontakt z codziennością. Etap ma limit czasu - gdy kontroler nie podejmie decyzji w zadanym oknie, sprawa eskaluje do kolejnej roli albo proces przechodzi w zdefiniowany stan bezpieczny, na przykład wstrzymanie płatności do wyjaśnienia. Ma też jawny przepływ danych: wszystko, co agent ustalił na wcześniejszych etapach, wędruje do zadania w Action Center jako kontekst decyzji, a decyzja wraca do procesu jako zwykła dana wejściowa kolejnego etapu. Dzięki temu po pół roku da się odtworzyć nie tylko, co postanowił człowiek, ale co dokładnie wiedział w momencie decyzji. Przy sporze z dostawcą albo pytaniu audytora ta różnica jest bezcenna.
Michał Korzeń, CTO SNOK, ujmuje to z perspektywy projektowej: „W projektach agentowych najtrudniejsze nie jest nauczenie agenta działać. Najtrudniejsze jest zdecydowanie, kiedy ma się zatrzymać. U nas około 70 procent pracy koncepcyjnej to definicja bramek, eskalacji i guardrails - sam agent to reszta.”
Agent Builder i Coded Agents: eskalacja wbudowana w agenta
Bramki na poziomie procesu to jedna warstwa. Drugą wbudowuje się w samego agenta.
Agent zbudowany w Agent Builder (low-code, Studio Web) ma punkty eskalacji jako element definicji: gdy trafi na sytuację poza swoim zakresem albo gdy guardrail zgłosi problem, kieruje sprawę do Action Center, na kanał Teams albo Slack - do człowieka, z kontekstem. W naszym review agent bez zdefiniowanej eskalacji dla decyzji wysokiego ryzyka to, ponownie, poziom krytyczny.
Agenci kodowani (Python, LangGraph) mają odpowiednik w postaci interrupt points: agent zatrzymuje wykonanie w zdefiniowanym punkcie grafu, czeka na zatwierdzenie i wznawia pracę dokładnie tam, gdzie stanął. To ważne technicznie - proces potrafi czekać na człowieka godzinami bez trzymania zasobów i bez utraty stanu.
Trzeci mechanizm to guardrails, i tu robi się ciekawie, bo guardrail może być bramką sam z siebie. Platforma UiPath rozróżnia trzy warstwy: guardrails wbudowane na poziomie agenta (wykrywanie ataków na prompt, prompt injection, danych osobowych, treści szkodliwych i ochrona własności intelektualnej), centralne polityki egzekwowane przez Automation Ops na całej platformie (w public preview od końca maja 2026) oraz guardrails własne na poziomie pojedynczego narzędzia, z regułami i wyrażeniami regularnymi. Każda z tych reguł ma przypisaną akcję - i obok „zablokuj” oraz „zaloguj” jest tam akcja „eskaluj”, która kieruje sprawę prosto do Action Center. Guardrail z akcją escalate to mechaniczny HITL gate: nie wymaga niczyjej pamięci ani dobrej woli, po prostu się uruchamia.
AI Trust Layer: bramka potrzebuje fundamentu
Wszystko powyżej dzieje się na poziomie procesu i agenta. Pod spodem pracuje warstwa, którą w rozmowach z klientami opisujemy jako fundament całej konstrukcji: UiPath AI Trust Layer.
AI Trust Layer to centralny punkt kontroli dla całego ruchu generatywnej AI w platformie. Każde zapytanie do modelu - z agenta, z Autopilota, z Document Understanding, z aktywności GenAI - przechodzi tę samą ścieżkę: uwierzytelnienie, egzekwowanie polityk, opcjonalne maskowanie danych osobowych, routing do modelu i zapis w rejestrze audytowym. Nie da się tej ścieżki ominąć od wewnątrz platformy. I to jest cała jej wartość.
Dla projektowania bramek HITL trzy elementy AI Trust Layer mają znaczenie praktyczne.
Rejestr audytowy. Każda akcja AI zostawia wpis: kto, kiedy, z jakiego produktu, jakim modelem, z jakim wynikiem - łącznie ze statusem „zablokowane przez politykę”. Od końca maja 2026 eksport telemetrii OpenTelemetry obejmuje także wyniki ewaluacji guardrails, więc widzicie nie tylko, co agent zrobił, ale też co próbował zrobić i co go zatrzymało. Decyzja człowieka na bramce plus ten rejestr to razem materiał dowodowy, którego oczekuje audytor DORA czy NIS2. O tym, jak duży jest głód takiej widoczności w sektorze publicznym, przekonaliśmy się na webinarze PWCyber - pisaliśmy o tym w relacji z wystąpienia dla podmiotów KSC.
Maskowanie danych osobowych w locie. In-Flight PII Masking pseudonimizuje dane osobowe w prompcie, zanim ten opuści środowisko i dotrze do modelu. Od czerwcowej aktualizacji platformy maskowanie obejmuje także pliki pobierane przez agenta, co domyka istotną lukę przy agentach przetwarzających dokumenty. Jedno zastrzeżenie z praktyki: maskowanie zmienia treść, którą widzi model, więc potrafi zmienić jakość odpowiedzi. Testujcie proces z włączonym maskowaniem przed szerokim wdrożeniem, nie po.
Własny model zamiast zarządzanego. AI Trust Layer pozwala podpiąć model na Waszej subskrypcji lub w Waszej infrastrukturze: Azure OpenAI, AWS Bedrock, Google Vertex, dowolny endpoint zgodny ze standardem OpenAI, a od wersji 25.10 także samodzielnie hostowane modele przez NVIDIA NIM. Dla klientów regulowanych to nie jest opcja z katalogu, tylko warunek wejścia - dane nie mogą wychodzić do modelu, nad którym nie macie kontroli umownej i technicznej. Czerwcowa aktualizacja dodała do wyboru modele Claude Opus 4.7 i GPT-5.5, co przy okazji przypomina o mniej wygodnej prawdzie: modele się zmieniają, a każda zmiana modelu to obowiązkowy powrót do testów regresyjnych agenta.
Jedno chcemy powiedzieć wprost, bo rynek lubi to mylić: AI Trust Layer to warstwa platformowa, nie zwolnienie z myślenia. Governance platformy nie zaprojektuje za Was bramek w procesie, nie zdecyduje, która akcja jest wysokiego ryzyka, i nie przejrzy promptów agenta pod kątem podatności. Obie warstwy są potrzebne. Platformowa bez procesowej daje audyt bez kontroli. Procesowa bez platformowej daje kontrolę bez dowodów.
Pułapka, w którą wpada większość: „uruchomimy człowieka, gdy pewność agenta spadnie poniżej 80%”
Ten pomysł pojawia się w niemal każdym warsztacie projektowym. Brzmi rozsądnie: agent zna swoją pewność, więc niech niska pewność otwiera bramkę, a wysoka pozwala działać samodzielnie. Elegancki próg, jedna liczba, gotowy slajd.
Problem w tym, że dla decyzji agenta taka liczba nie istnieje.
Model językowy nie ma skalibrowanego wskaźnika poprawności własnych decyzji. To, co bywa podawane jako „pewność”, to w rzeczywistości jeden z trzech zupełnie różnych sygnałów: prawdopodobieństwa kolejnych tokenów (które bywają wysokie przy halucynacjach), deklaracja samego modelu w rodzaju „jestem pewien w 95 procentach” (zależna od sposobu zapytania i systematycznie zawyżana przez modele trenowane pod preferencje użytkownika) albo wynik osobnego mechanizmu oceniającego, na przykład klasyfikatora ekstrakcji dokumentów. Tylko ten trzeci nadaje się do progowania - i to dopiero po kalibracji na Waszych danych, osobno dla każdego pola i zadania. Badania nad kalibracją modeli pokazują to od lat: deklarowana pewność i rzeczywista trafność to dwie różne krzywe, a odstęp między nimi trzeba zmierzyć, zanim się na nim cokolwiek zbuduje.
W ekosystemie UiPath to rozróżnienie ma bardzo konkretne przełożenie. Confidence z Document Understanding przy ekstrakcji pól faktury to realny sygnał - klasyfikator zwraca wynik per pole i po walidacji na próbce historycznej można na nim oprzeć próg kierujący dokument do Action Center. Progi guardrails w AI Trust Layer to też realne sygnały, ale o innej semantyce: mierzą ryzyko treści, nie poprawność decyzji. Natomiast „pewność agenta”, że cała wieloetapowa decyzja jest słuszna? Takiego natywnego, skalibrowanego wskaźnika platforma nie ma - i uczciwie mówiąc, nie ma go dziś nikt.
Dlatego w SNOK stosujemy zasadę, którą klienci zapamiętują lepiej niż niejedną metodykę: bramka HITL uruchamia się przy niskim wyniku LUB przy akcji wysokiego ryzyka, niezależnie od wyniku. Zmiana rachunku bankowego kontrahenta idzie do człowieka zawsze. Nawet gdyby wszystkie wskaźniki świeciły na zielono. Ryzyko akcji jest właściwością akcji, nie nastroju modelu.
I jeszcze jedno, bo to wraca w rozmowach o zgodności: próg pewności nie jest nadzorem człowieka w rozumieniu artykułu 14 AI Act. Nadzór to człowiek, który rozumie, co zatwierdza, ma realną możliwość odmowy i zostawia ślad decyzji. Liczba na ekranie tego nie zastąpi.
Jarosław Zdanowski, partner odpowiedzialny w SNOK za cyberbezpieczeństwo SAP, patrzy na to od strony audytu: „Regulator nie zapyta, jak zaawansowany był model. Zapyta, kto zatwierdził tę konkretną decyzję, na podstawie czego i gdzie jest zapis. Jeśli odpowiedź brzmi: agent ocenił swoją pewność na 93 procent - to nie jest odpowiedź, którą chcecie dawać jako pierwszą.”
Autonomia rośnie etapami - i każde przejście to też bramka
Jest jeszcze jeden wymiar, o którym rzadko się mówi, a który w praktyce decyduje o zaufaniu zarządu do całego programu agentowego: autonomia nie jest ustawieniem, które włącza się raz. Jest poziomem, na który agent zasługuje wynikami.
W naszych wdrożeniach agent przechodzi zwykle przez trzy etapy. Na pierwszym działa jak asystent: przygotowuje decyzje, ale każda przechodzi przez człowieka. Ten etap bywa frustrujący dla sponsorów projektu, bo oszczędności są jeszcze niewielkie - za to zbiera się bezcenny materiał: na których sprawach agent się myli, jak często, w jakich warunkach. Na drugim etapie agent dostaje autonomię w wąskim, dobrze zmierzonym zakresie: sprawy rutynowe, niskie kwoty, odwracalne akcje. Wszystko powyżej progu nadal idzie przez bramkę. Na trzecim zakres autonomii rośnie tam - i tylko tam - gdzie dane z poprzednich etapów pokazują, że odsetek korekt ze strony człowieka jest stabilnie niski.
Kluczowe jest to, że każde przejście między etapami to formalna decyzja z danymi na stole, nie stopniowe rozluźnianie, którego nikt nie zauważył. Kto podejmuje tę decyzję? W dobrze poukładanej organizacji ten sam gremialny właściciel ryzyka, który zatwierdzał mapę bramek na początku. W rejestrze zostaje wpis: od dziś agent wykonuje samodzielnie sprawy klasy X, bo przez N miesięcy człowiek korygował mniej niż Y procent z nich.
Ten model rozwiązuje też problem, który zgłasza nam co drugi dyrektor operacyjny: „przecież nie utrzymam ludzi do klikania w Action Center na zawsze”. Nie musicie. Etap ludzki w dojrzałym procesie agentowym nie znika, ale zmienia charakter: z zatwierdzania wszystkiego staje się nadzorem nad wyjątkami i okresową kontrolą próbek. Liczba zadań spada, waga każdego z nich rośnie. To zdrowa ewolucja - pod warunkiem, że jest sterowana pomiarem, a nie zmęczeniem.
I odwrotnie: autonomia potrafi też maleć. Zmiana modelu w AI Trust Layer, nowy typ dokumentów, reorganizacja po stronie dostawcy danych - każde z tych zdarzeń może cofnąć agenta o poziom, dopóki testy regresyjne nie potwierdzą, że jakość wróciła. Organizacje, które projektują tylko drogę w górę, odkrywają brak drogi w dół w najgorszym możliwym momencie.
Ciemna strona bramek: nadzór, który jest teatrem
Bylibyśmy nieuczciwi, gdybyśmy zakończyli na „wdróżcie bramki i po sprawie”. Bramka HITL potrafi zawieść na kilka dobrze udokumentowanych sposobów - i widzieliśmy każdy z nich.
Zatwierdzanie mechaniczne. Człowiek, który dostaje 200 spraw dziennie i w 98 procentach klika „akceptuj”, po dwóch tygodniach przestaje czytać. Formalnie nadzór istnieje. Faktycznie proces jest autonomiczny, tylko wolniejszy i z fałszywym poczuciem bezpieczeństwa. Lekarstwo jest projektowe, nie apelowe: bramka ma dostawać wyłącznie sprawy, które naprawdę wymagają osądu, a jej skuteczność trzeba mierzyć - odsetek odrzuceń bliski zeru przez dłuższy czas to sygnał alarmowy, że próg stoi w złym miejscu.
Zmęczenie alertami. Guardrails ustawione zbyt czule zasypują Action Center szumem, w którym ginie ta jedna sprawa, dla której cały mechanizm powstał. Tuning progów to praca iteracyjna na realnym ruchu, nie jednorazowa konfiguracja.
Koszt i latencja. Każda bramka wydłuża proces. Jeśli obiecaliście biznesowi obsługę faktury w 4 minuty, a kontroler odbiera zadania dwa razy dziennie, to macie konflikt, który wyjdzie w pierwszym tygodniu. SLA etapu ludzkiego trzeba zaprojektować i obsadzić tak samo poważnie jak wydajność robota.
Cicha awaria zabezpieczeń. W agentach kodowanych guardrail podpięty nieprawidłowo potrafi nie robić nic - bez błędu, bez ostrzeżenia. Dlatego w naszych przeglądach weryfikujemy nie tylko, czy zabezpieczenia są zadeklarowane, ale czy realnie się uruchamiają, z testem, który celowo próbuje je ominąć.
Żaden z tych problemów nie unieważnia bramek. Wszystkie unieważniają bramki wdrożone bez pomiaru.
Jak to składamy w SNOK: od mapy ryzyka do go-live
Na koniec konkret - tak wygląda ścieżka, którą przechodzimy z klientami przy projektach agentowych. Nie jako sztywna metodyka, raczej jako kolejność, która chroni przed najdroższymi błędami.
Zaczynamy od mapy decyzji, nie od technologii: które akcje w procesie są nieodwracalne albo kosztowne, kogo dotyczą, co mówi o nich regulacja. Z tej mapy wynika katalog bramek - gdzie człowiek jest wymagany zawsze, gdzie warunkowo, gdzie wystarczy log. Dopiero potem projektujemy proces w Maestro z etapami ludzkimi jako pełnoprawnymi uczestnikami, konfigurujemy guardrails na wszystkich trzech warstwach z akcją eskalacji tam, gdzie ma to sens, i spinamy całość z AI Trust Layer: rejestr audytowy włączony od pierwszego dnia, maskowanie danych osobowych przetestowane na realnych dokumentach, model podpięty zgodnie z wymogami regulacyjnymi klienta.
I zasada, od której nie odstępujemy: bez zestawu ewaluacyjnego nie ma go-live. Agent przechodzi testy na wersjonowanym zbiorze przypadków - szczęśliwych, brzegowych i celowo złośliwych - a każda zmiana modelu oznacza powtórkę tych testów. To nie biurokracja. To jedyny znany nam sposób, żeby po roku działania systemu odpowiedzieć na pytanie „skąd wiecie, że on nadal działa dobrze” czymś lepszym niż wzruszeniem ramion.
Czy to wszystko spowalnia projekt na starcie? Tak, o kilka tygodni. Widzieliśmy też wariant alternatywny: szybki start, autonomia na maksimum, a potem jeden incydent, po którym zarząd wyłącza wszystkich agentów na pół roku. Wolniejszy start jest tańszy.
Jeśli budujecie teraz architekturę agentową - w UiPath albo dopiero wybieracie platformę - i chcecie skonfrontować swój projekt bramek z kimś, kto robił to wielokrotnie, zapraszamy do rozmowy. Przegląd architektury agentowej z mapą ryzyka i katalogiem bramek to u nas standardowy, dobrze zdefiniowany warsztat. Piszcie: office@snok.ai.
Źródła
- UiPath Academy, „Get started with UiPath AI Trust Layer” oraz docs.uipath.com, admin guide „About AI Trust Layer” i „Configuring LLMs” (dostęp: maj-czerwiec 2026)
- UiPath Automation Cloud, release notes czerwiec 2026 (modele agentowe, rozszerzenie In-Flight PII Masking, 2026-06-16/17)
- UiPath docs, guardrails i Automation Ops centralized policies (public preview, 2026-05-29)
- Rozporządzenie UE 2024/1689 (AI Act), art. 14 - nadzór człowieka; harmonogram stosowania od 2 sierpnia 2026
- Guo et al., „On Calibration of Modern Neural Networks” (arXiv:1706.04599); Tian et al., „Just Ask for Calibration” (arXiv:2305.14975); Leng et al., „Taming Overconfidence in LLMs” (arXiv:2410.09724)