Human in the loop w praktyce: jak zaprojektować zatwierdzanie i po czym poznać, że stało się klikaniem

W lipcu 2026 r. przez polskie media biznesowe przeszła fala tekstów o tym, że pracownik nadzorujący AI nie może po prostu klikać „zatwierdź” — pisał o tym między innymi Infor 10 lipca 2026 r., powołując się na artykuły 13, 14 i 26 AI Act. Co do meritum ten tekst ma rację, pomija jednak dwie rzeczy: od kiedy te przepisy obowiązują i jak sprawdzić, czy zatwierdzanie u Ciebie już nie stało się klikaniem. Human in the loop nie jest bowiem cechą modelu ani opcją w narzędziu. To projekt jednego kroku procesu — ekranu, kolejki i dziennika — a każdy z nich da się zaprojektować źle w sposób, którego na schemacie nie widać.

Ten tekst opisuje, jak ten krok zbudować i jak go zmierzyć. Nie rozstrzyga klasyfikacji Twojego systemu w rozumieniu AI Act ani podstawy prawnej przetwarzania — to należy do prawnika, nie do wykonawcy. Gdzie w procesie postawić człowieka, rozpisaliśmy w czwartym kroku wdrożenia AI; tutaj zaczynamy o jedno pytanie dalej. Polskich tekstów o human in the loop nie brakuje — od definicji i poradników dostawców po recenzowany artykuł Martyny Kaczmarczyk o pozorności takiego nadzoru; wracamy do niego niżej. Brakuje w nich jednego: metody, którą tę pozorność odczyta się z własnego dziennika zatwierdzeń. Jak wygląda całość takiego projektu, opisaliśmy przy automatyzacji AI w firmie.

Trzy warianty nadzoru — gdzie w nich jest human in the loop, a gdzie human on the loop

Warianty są trzy i wszystkie trzy nazwaliśmy już w czwartym kroku wdrożenia od strony pracy, a nie żargonu. „Człowiek zatwierdza każdy wynik” to human in the loop: decyzja zapada przed skutkiem i dopóki jej nie ma, nic się nie wykonuje. „Człowiek zatwierdza wyjątki” to jego węższa odmiana — nadal decyzja przed skutkiem, tylko dla części spraw. „Człowiek nadzoruje statystycznie” to human on the loop: system działa sam, a nadzór opiera się na próbkach, wskaźnikach i przycisku zatrzymania. Tam jest też argument, dlaczego zaczyna się od pierwszego wariantu nawet wtedy, gdy celem jest ostatni. Pokrewny podział, poprowadzony po innej osi — po uprawnieniach agenta, a nie po tym, gdzie stoi człowiek — to trzy poziomy samodzielności przy agencie AI. Nie pokrywają się jeden do jednego: „człowiek zatwierdza każdy wynik” obejmuje tam i asystenta z samym odczytem, i agenta, którego każdy zapis czeka w kolejce, a nadzór statystyczny nie jest tam osobnym poziomem. Wspólny jest środek — tamten agent z zatwierdzaniem to dokładnie ta kolejka, którą projektujemy niżej.

Oba angielskie terminy bywają używane zamiennie, a różnica jest operacyjna, nie terminologiczna. Nadzór statystyczny wymaga trzech rzeczy naraz — zaprojektowanego losowania próbki, sprawdzonego zatrzymania i kogoś, kto ogląda alerty. Przejście na niego bez nich nie jest poluzowaniem nadzoru, tylko jego zniesieniem. Czwarta możliwość — human out of the loop, czyli sam audyt po fakcie — nie jest tu wariantem, bo nie ma w niej czego projektować. (Polski kalk „człowiek w pętli” istnieje, ale polska Wikipedia opisuje go w kontekście broni autonomicznej.)

Co musi zobaczyć osoba zatwierdzająca

Cztery rzeczy, na jednym ekranie: źródło — dokument, wiadomość albo nagranie, z którego wynik powstał; propozycję systemu razem z jego miarą pewności; różnicę wobec danych, które już są w ERP albo CRM; i powód, dla którego sprawa trafiła do kolejki, zamiast przejść dalej sama. Jeżeli któregokolwiek z tych czterech punktów trzeba szukać w innym oknie, w praktyce nikt go nie sprawdzi.

Użyteczny punkt odniesienia daje wyrok TSUE w sprawie C-203/22 (Dun & Bradstreet Austria, 27 lutego 2025 r.): osobie objętej decyzją z art. 22 RODO trzeba na gruncie art. 15 ust. 1 lit. h wyjaśnić „procedurę i zasady faktycznie zastosowane”, a nie ujawnić algorytm. Zatwierdzającemu nikt tego nie jest winien. Ale jeżeli widzi mniej niż to, co usłyszałaby osoba, której decyzja dotyczy, trudno mówić o realnym wpływie na wynik.

Lepszy ekran nie jest przy tym zabezpieczeniem sam z siebie: w badaniu Bansala i współautorów (CHI 2021) dodanie wyjaśnień do rekomendacji AI zwiększało jej akceptację niezależnie od tego, czy była trafna. Specyfikacja ekranu jest hipotezą do zmierzenia, a nie dowodem — stąd druga połowa tego tekstu.

Kto jest właścicielem kolejki i jaki ma SLA

Właścicielem kolejki jest osoba z imienia i nazwiska, nie dział. Do tego cztery ustalenia: okno obsługi, pułap zaległości, po którym kolejkę uznaje się za niewydolną, co dzieje się ze sprawą po terminie i kto zastępuje właściciela na urlopie. Bez ostatniego punktu SLA obowiązuje przez jedenaście miesięcy w roku.

Art. 26 ust. 2 AI Act — przepis, który zacznie obowiązywać najwcześniej w grudniu 2027 r., o czym niżej — mówi, że podmiot stosujący powierza nadzór osobom mającym „niezbędne kompetencje, przeszkolenie i uprawnienia, a także niezbędne wsparcie”. Pierwsze trzy cytuje się powszechnie, czwartą pomija — a to ona oznacza czas w grafiku, dostęp do systemu źródłowego i prawo do stwierdzenia, że sprawa jest nierozstrzygalna na tym ekranie.

Termin ustala się przy tym w polityce, a nie zostawia narzędziu; co która platforma pod tym względem udostępnia, zebraliśmy w tabeli narzędzi niżej. To nie to samo co podział decyzji w projekcie, opisany w metodyce wdrożenia: tu chodzi o jedną kolejkę i o to, kto odpowiada za to, żeby nie rosła.

Zdolności realnego nadzoru — i cztery projekty, które nie przejdą audytu

Art. 14 ust. 4 AI Act — również odłożony, do tych samych dat — wymienia pięć rzeczy, które osoba nadzorująca ma móc zrobić. Grupujemy je w trzy; to nasze uproszczenie, nie podział z rozporządzenia: zrozumieć (lit. a–c: znać ograniczenia systemu na tyle, żeby wychwycić anomalię, pozostawać świadomym „błędu automatyzacji” i poprawnie zinterpretować wynik), zainterweniować (lit. d: zignorować, unieważnić albo odwrócić wynik) i zatrzymać (lit. e: przerwać działanie przyciskiem „stop” w bezpiecznym stanie).

Cztery projekty kroku zatwierdzania, które tego nie spełniają, wyglądają w firmie zupełnie normalnie:

• Przycisk „zatwierdź wszystko”. Zbiorcza akceptacja zwykle oznacza, że pojedynczej sprawy nikt nie widział. Nie ma dla niej dobrego zakresu: kategoria, która przeszła regułę awansu z dalszej części tekstu, w ogóle nie trafia już do kolejki, a ta, która trafia, trafia z jakiegoś powodu.
• Kolejka, w której mediana czasu decyzji wynosi dwie sekundy. Dwie sekundy wystarczają na kliknięcie i nie wystarczają na przeczytanie czegokolwiek. To zarzut wobec projektu, który — dla przykładu — każe komuś przerobić dwieście spraw dziennie i nazywa to nadzorem, a nie wobec ludzi, którzy w nim pracują.
• Nadpisania bez śladu. Człowiek zmienił kwotę albo kategorię, a w dzienniku został tylko wynik końcowy. Bez pola „co zmieniono” nie da się ani wykazać, że nadzór był realny, ani niczego nauczyć się z korekt.
• Zatrzymanie, którego nikt nigdy nie próbował. Test jest prosty: raz na kwartał ktoś wciska stop na działającej kolejce, w godzinach pracy, i zapisuje trzy liczby — ile sekund minęło do faktycznego zatrzymania, ile spraw zostało w połowie i ile osób dowiedziało się o tym bez pytania. Data ostatniego testu jest polem w polityce zatwierdzania; bez niego przycisk jest deklaracją. Przy agentach z uprawnieniami do działania w systemach ten sam test dotyczy zakresu uprawnień — piszemy o tym przy wdrożeniach agentów AI, a co odróżnia agenta od zwykłego bota, rozstrzygnęliśmy w tekście o różnicy między agentem AI a chatbotem.

Trzy liczby z dziennika zatwierdzeń

Wszystkie trzy liczy się osobno dla każdej kategorii spraw — kolejka uśredniona to kolejka, w której nic nie widać.

1. Odsetek korekt i odrzuceń. Udział spraw, w których człowiek zmienił cokolwiek w propozycji albo ją odrzucił.
2. Mediana czasu decyzji. Od otwarcia sprawy do zapisania decyzji. Mediana, nie średnia — jedna sprawa odłożona na weekend psuje średnią.
3. Niezgodność w audycie próbki. Odsetek spraw z wylosowanej próbki zatwierdzonych, w których druga osoba, patrząc na to samo, rozstrzygnęłaby inaczej.

Pierwsza liczba jest najczęściej raportowana i najsłabiej rozstrzyga. Odsetek korekt bliski zeru ma cztery wyjaśnienia: model ma rację w tej kategorii, kolejka dostaje same łatwe sprawy, osoba zatwierdzająca klika albo nie widzi dość, żeby się nie zgodzić. Żadna pojedyncza liczba ich nie rozróżnia. Trzecia odpowiada na inne pytanie — czy zatwierdzone wyniki były trafne — i milknie dokładnie wtedy, gdy model ma rację, bo osoba klikająca i osoba czytająca dają wtedy tę samą pustą próbkę; audytor, który widzi nie więcej niż zatwierdzający, ma zresztą ten sam martwy punkt. Dopiero druga liczba obok niej mówi, czy ktokolwiek patrzył — i dlatego audyt próbki traktujemy jako obowiązkowy element projektu kolejki, a nie jako dodatek, i nigdy nie czytamy go osobno. Kategorie, w których taki dziennik najszybciej się opłaca, wymieniliśmy wśród przykładów automatyzacji AI — punkt o odpowiedziach przygotowanych do zatwierdzenia kończy się obietnicą, którą ten tekst spełnia.

Test na klikanie: mediana czasu decyzji kontra czas czytania

Zacznij od policzenia dolnej granicy dla swojego ekranu, bo to jedyna liczba, której nie musisz od nikogo dostać. Ekran zatwierdzania z około 180 słowami treści, przy tempie czytania 175–300 słów na minutę, daje 36–62 sekundy samego czytania, zanim ktokolwiek porówna cokolwiek z systemem.

Wyliczenie jest ilustracyjne. Zakres 175–300 słów na minutę pochodzi z metaanalizy Marca Brysbaerta (2019) obejmującej 190 badań i 18 573 uczestników i dotyczy angielskiego; polski tekst o tej samej treści ma zwykle mniej słów, więc wynik jest dolną granicą, a nie czasem oczekiwanym. Czytanie to zresztą nie to samo co weryfikacja.

Potem zestaw tę granicę z tym, co pokazuje dziennik:

Tabela jest ilustracyjna, a nie danymi pomiarowymi — pokazuje kształt dziennika zatwierdzeń, a nie wynik konkretnego wdrożenia; każda kategoria ma inny ekran, więc i inny próg czytania, policzony tak samo jak wyżej. Ważny jest w niej pierwszy wiersz: mediana sześciu sekund przy policzonym dla tego ekranu progu trzydziestu pięciu sekund jest mocnym sygnałem, że ta kategoria nie jest zatwierdzana, tylko przeklikiwana, a stojący obok odsetek korekt 1,2% niczego nie dowodzi, bo pochodzi z tych samych sześciu sekund. To jedyny wiersz, który na papierze wygląda na gotowy do poluzowania, i jedyny, którego liczbom nie wolno zaufać. Drugi wiersz jest jego przeciwieństwem: mediana powyżej progu i 14% korekt to kolejka, w której ktoś naprawdę patrzy — i właśnie dlatego ta kategoria nie awansuje, bo człowiek wciąż zmienia co siódmą sprawę.

Sam test — porównanie mediany z policzonym progiem czytania — jest naszym pomysłem, a nie metodą z literatury; literatura dostarcza tylko tempa czytania. Działa w jedną stronę: mediana wyraźnie poniżej progu jest mocnym sygnałem, że nikt nie czyta, ale mediana powyżej progu niczego jeszcze nie dowodzi. Zbyt dobra zgodność człowieka z systemem to powód do sprawdzenia, nigdy diagnoza.

Błąd automatyzacji (automation bias): dlaczego dobry system psuje nadzór

Nadzór psuje się tym szybciej, im lepiej system działa: im rzadziej trzeba poprawiać, tym mniej opłaca się sprawdzać. Rozporządzenie nazywa to wprost — art. 14 ust. 4 lit. b wersji polskiej każe osobie nadzorującej pozostawać świadomą tej tendencji, po polsku „błędu automatyzacji”. Przegląd 74 badań Goddard, Roudsariego i Wyatta (JAMIA 2012) wskazuje jako czynniki łagodzące szkolenie, wyraźne przypisanie odpowiedzialności zatwierdzającemu oraz projekt ekranu — w tym to, czy system podaje informację, czy od razu rekomendację. Lyell i Coiera (JAMIA 2017) dodają, że zjawisko pojawia się także przy pojedynczym zadaniu, jeżeli sprawdzenie wyniku jest kosztowne — i zaraz zastrzegają, że literatura jest rozproszona, a niewiele badań podaje istotność statystyczną wobec grupy kontrolnej.

Ostrożnie więc z rozpoznaniem stawianym z góry. Trzy prerejestrowane eksperymenty Alon-Barkata i Busuioc (JPART 2023) na łącznej próbie 2 854 osób nie wykazały błędu automatyzacji: rada algorytmu była przyjmowana mniej więcej tak samo często jak równoważna rada ludzkiego eksperta. Projekty, które skutecznie ograniczają nadmierne poleganie — jak wymuszenie własnej decyzji przed pokazaniem podpowiedzi w badaniu Buçinki, Malayi i Gajosa (2021) — zbierały w tym samym badaniu najgorsze oceny użytkowników. To laboratorium, nie polska firma, ale spodziewaj się, że rozwiązanie, które zadziała u Ciebie, będzie tym, przeciw któremu zespół zaprotestuje najgłośniej. Samą diagnozę — że nadzór człowieka bywa w praktyce jedynie formalny i sprowadza się do biernego autoryzowania decyzji algorytmu — postawiła w polskim piśmiennictwie Martyna Kaczmarczyk (Studia Prawa Publicznego 2/2026); nowe jest tu tylko to, jak ją zmierzyć.

Reguła awansu i degradacji kategorii

Awans kategorii — z „zatwierdzamy każdą sprawę” na „zatwierdzamy wyjątki” — musi mieć próg liczbowy, inaczej odbywa się na wyczucie w tygodniu, w którym kolejka urosła. Wielkość próby bierzemy z reguły trzech (Hanley i Lippman-Hand, JAMA 1983): po serii n spraw bez błędu górna granica 95-procentowego przedziału ufności dla odsetka błędów wynosi mniej więcej 3/n.

To górna granica 95-procentowego przedziału ufności po serii bez błędu, a nie próg akceptowalnej jakości. Ten drugi jest decyzją biznesową i dla części kategorii brzmi „nie awansujemy wcale”.

Nasze wartości startowe, rewidowane po pilotażu: kategoria awansuje, gdy ma za sobą co najmniej 200 kolejnych spraw bez błędu, który trzeba było odkręcać, odsetek korekt poniżej 2% w tej serii, niezgodność w audycie próbki poniżej 1 na 50 oraz medianę czasu decyzji powyżej progu czytania — ten ostatni warunek jest po to, żeby seria bez błędu nie okazała się serią bez patrzenia. Degradacja ma jeden wyzwalacz i jest natychmiastowa: jedno zatwierdzenie, którego skutek wyszedł poza firmę i wymagał odwołania — korekta u kontrahenta, wycofana wysyłka, cofnięte zobowiązanie — wraca kategorię do zatwierdzania każdej sprawy tego samego dnia. Statystykę robi się potem.

Jak losować próbkę w nadzorze statystycznym

Próbkę losuje się z całej populacji spraw zatwierdzonych w okresie, a nie z tych, które komuś wydały się dziwne — inaczej mierzysz czujność osoby wybierającej, nie jakość kolejki. Trzy warunki wystarczą na start: losowanie jest automatyczne i zapisane w dzienniku razem z decyzją, próbka jest ciągniona osobno dla każdej kategorii, a sprawy z próbki ogląda ktoś inny niż osoba, która je zatwierdziła.

Reszta — wielkość próbki przy różnych wolumenach, co zrobić z serią bez ani jednej niezgodności i jak nie płacić za audyt więcej, niż wart jest sam proces — to materiał na osobny tekst.

Art. 14 i art. 26 AI Act oraz „wyłącznie” z RODO — jako pola w logu, nie jako wykład

Najpierw data, bo brakuje jej w tekście, od którego zaczęliśmy. Art. 14 i art. 26 AI Act jeszcze nie obowiązują: stosuje się je do systemów wysokiego ryzyka z załącznika III od 2 grudnia 2027 r., a do systemów z załącznika I od 2 sierpnia 2028 r. — art. 113 lit. c tekstu skonsolidowanego na 27 lipca 2026 r., sprawdzonego 8 września 2026 r. Nie jest to powód, żeby czekać — dobudowanie ekranu, kolejki i dziennika do działającego procesu jest droższe niż zaprojektowanie ich od razu. Jest to powód, żeby nie kupować niczego pod presją terminu, którego nie ma. Co obowiązuje wcześniej, zebraliśmy przy technicznym sprincie zgodności z AI Act.

Dziś rozstrzyga art. 22 RODO i jego słowo wyłącznie — doktrynę rozłożyliśmy w tekście o RODO a wdrożeniu LLM, tu liczy się jedno zdanie z wytycznych. Grupa Robocza Art. 29 w WP251rev.01, przyjętych następnie przez Europejską Radę Ochrony Danych, pisze rzecz będącą sednem tego tekstu: administrator „nie może symulować interwencji ludzkiej”, a rutynowe stosowanie automatycznie generowanych profili „bez jakiegokolwiek realnego wpływu na wynik” to nadal decyzja oparta wyłącznie na przetwarzaniu automatycznym. Nadzór ma być „istotny, a nie jedynie symboliczny”, sprawowany przez osobę z uprawnieniami i kompetencjami do zmiany decyzji. Czy Twoja kolejka mieści się w tym opisie, rozstrzyga prawnik; my odpowiadamy za to, żeby dało się to wykazać z danych.

Wykazuje się to polami w dzienniku — ale to nasz projekt, a nie lista z rozporządzenia. AI Act wymaga rejestrowania zdarzeń (art. 12), a minimalny zestaw pól wylicza tylko dla systemów biometrycznych z załącznika III pkt 1 lit. a. Nasza lista: kto zdecydował, kiedy, co zobaczył na ekranie w momencie decyzji, jaką pewność podawał system, co zmienił, ile czasu spędził w sprawie i czy uruchomiono zatrzymanie lub eskalację. Przy zakupach zapamiętaj, że art. 14 obciąża dostawcę, a art. 26 podmiot stosujący, czyli zwykle Ciebie. Retencję dziennika ustala się razem z resztą decyzji o danych, o czym piszemy w bezpieczeństwie danych. To opis strony technicznej i organizacyjnej, a nie porada prawna.

Jak to wygląda w narzędziu: n8n, Make i Power Automate (stan na 8 września 2026 r.)

Wiersze pochodzą z dokumentacji producentów czytanej 8 września 2026 r. (n8n, Make, Microsoft Learn) i mogą się zmienić. Najważniejsza jest kolumna trzecia: mechanizm zatwierdzania kupujesz gotowy, a pola dziennika i tak dopisujesz sam. Jak zbudować przepływ, opisaliśmy w przewodniku po n8n — tam jest budowa, tutaj to, co ma się w niej znaleźć.

Przy agentach n8n ma osobną bramkę do zatwierdzania wywołań narzędzi: człowiek widzi, które narzędzie model chce uruchomić i z jakimi parametrami. Sama bramka działa w węźle — zatwierdzenie uruchamia narzędzie, odmowa je anuluje. Dokumentacja zaznacza jednak, że w promptcie systemowym trzeba dodatkowo opisać, które narzędzia wymagają zgody i co model ma zrobić po odmowie (dokumentacja n8n, stan na 8 września 2026 r.) — a ta część jest instrukcją, nie kontrolą. Kontrolą jest tylko to, co działa niezależnie od modelu.

Kiedy nie poluzowywać nadzoru — i kiedy kolejka to zły projekt

Reguła awansu ma wyjątki, których nie znosi żadna liczba spraw bez błędu:

• Działania nieodwracalne. Przelew, wysyłka, publikacja, usunięcie danych, zobowiązanie wobec kontrahenta. Tu awansu nie ma — jest co najwyżej węższy zakres, w którym działanie wolno wykonać.
• Rozstrzygnięcia o istotnym skutku dla konkretnej osoby. Zatrudnienie, kredyt, dostęp do usługi. Osobny reżim prawny i osobna odpowiedzialność; części z tych zastosowań w ogóle nie budujemy — piszemy o tym w czego nie robimy.
• Kategorie bez własnego dziennika. Jeżeli nie umiesz policzyć trzech liczb dla tej kategorii osobno, nie masz podstawy do awansu, tylko wrażenie.

Kolejka bywa też po prostu złym projektem. Przy kilku sprawach dziennie zwykle kosztuje więcej niż same sprawy — ekran, dyżur i audyt trzeba utrzymywać niezależnie od wolumenu; gdzie dokładnie leży ta granica, policz dla swojego procesu, bo publicznej liczby na to nie ma. Kolejka bez właściciela jest gorsza od jej braku, bo wygląda jak zabezpieczenie i nim nie jest. A jeżeli proces nie ma jeszcze ustalonego przebiegu, pierwszym krokiem nie jest kolejka, tylko rozstrzygnięcie, kto co zatwierdza i co się dzieje w wyjątkach — to jedno z odradzeń, które wymieniamy przy automatyzacji AI w firmie.

Polityka zatwierdzania na jedną stronę

Wszystko powyższe mieści się na jednej stronie i jest to jedyny dokument, którego ten krok wymaga. Dla każdej kategorii spraw zapisz jedenaście pól:

1. Kategoria i jej wolumen.
2. Wariant nadzoru: każda sprawa, wyjątki albo próbka.
3. Właściciel kolejki z imienia i nazwiska oraz jego zastępca.
4. Okno obsługi, termin i to, co dzieje się po jego przekroczeniu.
5. Co widać na ekranie decyzji.
6. Kto ma prawo zatwierdzać.
7. Co zapisuje się w dzienniku.
8. Procedura zatrzymania i data ostatniego testu.
9. Kryteria awansu: liczba spraw, próg korekt, próg niezgodności, próg czasu.
10. Jedno zdarzenie degradujące natychmiast.
11. Data przeglądu polityki.

To szablon operacyjny, nie wzór dokumentu prawnego — jego wartość polega na tym, że każde pole ma wypełniającego, a pusty wiersz od razu widać.

Co dalej

Weź jedną kolejkę, którą już masz, i wypełnij dla niej te jedenaście pól. Puste są zwykle trzy: właściciel, procedura zatrzymania i data jej ostatniego testu. Potem policz próg czytania dla ekranu decyzji i porównaj go z medianą z ostatniego miesiąca. Jeżeli mediana jest niższa, masz odpowiedź jeszcze przed pierwszym audytem próbki — i konkretny powód, żeby zacząć od zmiany ekranu, a nie od zmiany modelu.