Human-in-the-loop to nie nadzór. To dyscyplina projektowa.

Akceptacja, której nie było

W Marrowfield Specialty Risk tegoroczny wiosenny audyt segregacji szkód doprowadził do krótkiej, niezręcznej wymiany zdań. Ten broker, około 150 pracowników na rynku nadzorowanym przez regulatora, od osiemnastu miesięcy korzystał z systemu AI oznaczającego szkody. Mariela Okafor, Claims Operations Lead, zajmowała to stanowisko od dwunastu lat. Likwidatorzy obsługiwali ponad 200 spraw dziennie; model oznaczał mniej więcej 8 % z nich. Audyt wydobył dwie liczby: 96 % akceptacji spraw oznaczonych przez AI i średni czas przeglądu 23 sekundy. Inspektor ds. zgodności zapytał: „Do jakich progów to dostroiliście?". Odpowiedź: „Do żadnych. Po prostu zatwierdzam to, co przysyła mi AI".

Marrowfield Specialty Risk to postać złożona, oparta na wywiadach z brokerami specjalistycznymi z segmentu średnich firm oraz na literaturze dotyczącej zgodności z wytycznymi BoE/FCA i aktem w sprawie sztucznej inteligencji. Nazwiska zanonimizowano; przytoczone wskaźniki ilustrują wzorce z cytowanych badań.

W oczach organów nadzoru na trzech kontynentach ta wymiana zdań jest dziś odczytywana jako dowód braku nadzoru. Data rozpoczęcia stosowania aktu w sprawie sztucznej inteligencji, sierpień 2026 r., wyznacza termin dla tej wady projektowej, ale sama wada jest starsza niż ten kalendarz.

§1 — Bierna akceptacja to teatr audytowy, nie nadzór

Domyślny model myślowy — „AI oznacza, człowiek zatwierdza" — jest strukturalnie nie do odróżnienia od braku nadzoru. Interfejs z jednym przyciskiem, bez danych wejściowych, bez rozumowania modelu, bez wyniku pewności, daje dokładnie te wskaźniki, które wydobyło Marrowfield. Sygnatura operacyjna pokrywa się z w pełni zautomatyzowanym procesem, w którym człowiek pozostaje w gotowości.

Dane nadzorcze potwierdzają to w skali całej populacji. Badanie BoE/FCA AI in UK Financial Services 2024 wykazało, że „55 % wszystkich zastosowań AI ma pewien stopień zautomatyzowanego podejmowania decyzji, przy czym 24 % z nich jest częściowo autonomicznych, tzn. choć mogą samodzielnie podejmować szereg decyzji, są zaprojektowane tak, by włączać nadzór ze strony człowieka w przypadku decyzji krytycznych lub niejednoznacznych" [9]. Wniosek, spójny z ujęciem ryzyka konfiguracji człowiek–AI w NIST AI 600-1, brzmi: w większości populacji zautomatyzowanego podejmowania decyzji nie ma rzeczywistego momentu, w którym człowiek może zareagować.

Organy nadzoru podjęły działania, by tę lukę zamknąć. Stanowisko ICO jest jednoznaczne: decyzja nie wychodzi spod Article 22 UK GDPR „tylko dlatego, że człowiek ją »przyklepał«" [2]. Te same wytyczne wypowiadają się ostrzej o dowodach operacyjnych: recenzenci, którzy „rutynowo zgadzają się z wynikami systemu AI i nie potrafią wykazać, że rzeczywiście je ocenili", mogą zostać zakwalifikowani jako wyłącznie zautomatyzowani na gruncie UK GDPR [3]. Akt w sprawie sztucznej inteligencji ustanawia równoległy test w art. 14, wymagając systemów „zaprojektowanych i opracowanych w taki sposób ... aby mogły być skutecznie nadzorowane przez osoby fizyczne" [1]. Słowo skutecznie jest nośne w obu tradycjach prawnych. Pytanie projektowe nie brzmi już „czy człowiek jest obecny?", lecz „czy projekt jest taki, że człowiek może wykryć, unieważnić i przerwać — i czy faktycznie by to zrobił?".

§2 — HITL to system progowy, nie krok przeglądu

Human-in-the-loop (człowiek w pętli decyzyjnej), potraktowany poważnie, jest systemem: jawne progi pewności, trzy ścieżki decyzyjne, korekta ważona ryzykiem i polityka kolejki. Model zwraca wynik pewności w zakresie 0,0–1,0 i stosuje się trzy progi — auto-odrzucenie poniżej dolnej granicy, przegląd przez człowieka w paśmie środkowym, auto-zatwierdzenie powyżej górnej. Zachowawcze punkty wyjścia dla procesów regulowanych leżą w okolicach 0,3 / 0,95; operacje umiarkowane — blisko 0,5 / 0,9; klasyfikacja niskiego ryzyka — przy 0,7 / 0,95. Progi są celowo asymetryczne: fałszywie pozytywne i fałszywie negatywne wyniki niosą różne koszty, a system progowy koduje tę asymetrię, zamiast grzebać ją w jednej liczbie. NIST AI RMF 1.0 dochodzi do tego samego — jej funkcja MANAGE „polega na regularnym przydzielaniu zasobów ryzyka do zmapowanych i zmierzonych ryzyk" [5], a progi są mechanizmem tego przydziału, wymiarowanym do ryzyka, a nie do wygody.

Na wierzchu działa korekta ważona ryzykiem. Pewność mnoży się przez wskaźnik dotkliwości ryzyka biznesowego — wielkość szkody, nieodwracalność decyzji, narażenie regulacyjne — dając macierz routingu 3×3. Sprawa wysokiego ryzyka o niskiej pewności trafia w eskalacji do przełożonego; sprawa wysokiego ryzyka o wysokiej pewności i tak kierowana jest do standardowego przeglądu HITL, a nie do auto-zatwierdzenia. Wybór między układem dwupoziomowym a trzypoziomowym ma znaczenie: układ dwupoziomowy zsypuje każdą niepewną sprawę do jednej kolejki, kolejka się przepełnia, likwidatorzy domyślnie przechodzą na hurtowe zatwierdzanie — czyli wzorzec, który dał wynik 96 % w Marrowfield. Układ trzypoziomowy nadaje auto-odrzuceniu produktywną rolę. Routing zależy od scentralizowanej strategii AI^EN z usankcjonowanym zestawem narzędzi, który daje spójne wyniki pewności; chaotyczne mnożenie narzędzi ad hoc czyni dyscyplinę progów niemożliwą, ponieważ wyniki z różnych modeli nie są porównywalne.

§3 — Ścieżki awaryjne są projektowane, nie domniemane

„Ścieżka awaryjna" to nie obsługa błędów. To jawna gałąź, którą system obiera, gdy AI nie jest pewne, i potrzebuje ona ścieżki, osoby i SLA. Trzy projekty pokrywają całe pole.

Projekt A — synchroniczny z człowiekiem w pętli: AI wstrzymuje się i zwraca sprawę do kolejki wraz z dołączonym rekordem wejściowym, rozumowaniem i pewnością, w reżimie SLA od 2 do 4 godzin; właściwy dla decyzji zbliżonych do czasu rzeczywistego. Projekt B — asynchroniczny, w kolejce wsadowej: AI zwraca odpowiedź wstępną, a następnie ujawnia ją w partii dziennej lub tygodniowej z retroaktywnym oknem unieważnienia; właściwy dla prac niewrażliwych na czas. Projekt C — hierarchiczny, z eskalacją do eksperta: kieruje sprawy według niepewności AI oraz dotkliwości ryzyka do wielopoziomowej puli recenzentów (standardowy → ekspert → przełożony) z SLA 4 h / 24 h / 72 h; właściwy dla decyzji regulowanych — skierowań do underwritingu, segregacji medycznej, sygnałów ds. zgodności.

Każda ścieżka awaryjna potrzebuje wskazanego właściciela i udokumentowanego SLA. UK DSIT AI Playbook ujmuje to operacyjnie — „jasno udokumentowane procesy przeglądu i eskalacji ... oraz rada ds. przeglądu AI lub rada na poziomie programu" [4] — a NIST AI RMF MANAGE niesie tę samą instrukcję pod innym kątem, wymagając monitorowania po wdrożeniu z wyznaczonymi kanałami informacji zwrotnej. Antywzorzec audytowy jest stały: zbiorcza kolejka „przeglądu przez człowieka" bez SLA i bez właściciela, w której kolejka rośnie, a rekomendacja AI staje się faktyczną decyzją. W Marrowfield przeprojektowanie przypisało każdą ścieżkę awaryjną: drobne szkody poniżej progu istotności przetwarzane są automatycznie; sprawy z pasma środkowego idą Projektem A w reżimie SLA 4 godzin; sprawy z pasma wysokiego i podprogowe idą Projektem C z wyznaczonymi underwriterami. Kolejki przestały być jednym kanałem przepełnienia i stały się trzema torami obsługi z własnymi wskaźnikami i właścicielami.

§4 — Rejestr unieważnień to artefakt zgodności

To, co audytorzy faktycznie badają, to rejestr unieważnień. Brak rejestru — albo rejestr bez ustrukturyzowanego uzasadnienia — oblewa test, zanim jakakolwiek obrona narracyjna zostanie w ogóle wysłuchana. Minimalny artefakt na każdą decyzję HITL to stały schemat: case_id, pewność AI, rekomendacja AI, identyfikator recenzenta, czas przeglądu w sekundach, decyzja człowieka, uzasadnienie unieważnienia, znacznik czasu, policy_version. Bez policy_version ślad jest po roku nieinterpretowalny, bo progi zdążą się przesunąć. Art. 14 ust. 4 aktu w sprawie sztucznej inteligencji wymaga, by recenzenci mogli „ingerować w działanie ... lub przerwać działanie systemu" [1] — a operacyjny wniosek jest taki, że ta zdolność musi pozostawiać zapis, inaczej jej nie było. NIST AI 600-1 ujmuje to na poziomie działania: „Monitoruj i dokumentuj przypadki, w których operatorzy-ludzie lub inne systemy unieważniają decyzje generatywnej AI" [6]. Rejestr jest centralnym dowodem rzeczywistego przeglądu.

Odpowiedzialność tkwi w górę strumienia od rejestru. FCA AI Update ustanawia zasadę: „jasne linie odpowiedzialności ustanowione w całym cyklu życia AI" [10]. Brytyjskie firmy objęte SM&CR umieszczają stos AI i operacji w funkcji Chief Operations; firmy amerykańskie prowadzą komitety ds. AI na poziomie zarządu; firmy unijne stosują wytyczne EBA i ECB dotyczące odpowiedzialności kierownictwa wyższego szczebla. Zasada jest przenośna między trzema tradycjami, co sprawia, że budowanie ładu AI od pierwszego dnia jest tańsze niż doposażanie po fakcie. ISO/IEC 42001:2023 ujmuje szerszy zestaw mechanizmów kontrolnych jako „zintegrowane podejście do zarządzania projektami AI, od oceny ryzyka po skuteczne postępowanie z tymi ryzykami" [8].

Audytorzy szukają sygnałów odwrotnych. Czas przeglądu poniżej 10 sekund jest odczytywany jako jedynie formalne zatwierdzanie. Wskaźnik akceptacji powyżej 98 % bywa interpretowany jako brak przeglądu. Puste pole uzasadnienia jest sygnałem nieudokumentowanej rzeczywistości przeglądu. Ponad 200 decyzji dziennie na recenzenta wskazuje na zmęczenie. Każdy z tych sygnałów jest osobnym ustaleniem audytu.

§5 — Jak kwartalne strojenie utrzymuje HITL w uczciwości?

Progów nie ustawia się raz na zawsze. Modele dryfują, reguły biznesowe się zmieniają, pojawiają się przypadki brzegowe. Kwartalny cykl to najtańsza dyscyplina, która chroni zaprojektowany system HITL przed osunięciem się z powrotem w teatr, i ma on wagę w różnych jurysdykcjach: test „skutecznego" nadzoru z art. 14 jest bez niego niespełnialny, a NIST AI RMF MANAGE oczekuje, że gotowe będą „plany priorytetyzacji ryzyka oraz regularnego monitorowania i doskonalenia" [5].

Miesiąc pierwszy — pomiar bazowy: wolumen HITL tygodniowo, wskaźnik unieważnień w podziale na pasma pewności, rozkład czasu do decyzji, wskaźnik eskalacji według poziomu. Miesiąc drugi — identyfikacja sygnałów dryfu: pasma, w których unieważnienia przekraczają 20 %, oznaczają, że model jest zawodny, a pasmo HITL trzeba poszerzyć lub model przetrenować; pasma poniżej 2 % można bezpiecznie zawęzić; sprawy Projektu B bez przeglądu w obrębie okna oznaczają, że proces wsadowy jest zepsuty. Miesiąc trzeci — korekta i dokumentacja: zaktualizować definicje progów, zwiększyć numer policy_version wraz z przyczyną zmiany, powiadomić dział operacji, zresetować bazę odniesienia.

Cykl zakłada kulturę recenzentów, która sprzyja unieważnianiu. ICO mówi to wprost: rzeczywisty przegląd wymaga, by „recenzenci mieli uprawnienie do unieważnienia wyniku wygenerowanego przez system AI i byli pewni, że nie zostaną za to ukarani" [3]. To samo oczekiwanie tkwi w amerykańskich zamówieniach publicznych na gruncie NIST AI RMF oraz w unijnych regułach odpowiedzialności pod auspicjami EBA i ECB — różne jurysdykcje, identyczny test operacyjny. Tam, gdzie kultura karze odstępstwa, wskaźniki unieważnień załamują się z przyczyn kulturowych, a nie technicznych, a dane, na których cykl się opiera, stają się nieinterpretowalne. UK DSIT Playbook wskazuje właścicielstwo: cykl należy do rady ds. przeglądu AI lub rady na poziomie programu [4]. Typowa odpowiedź firm z segmentu średnich przedsiębiorstw na pytanie „kto jest tego właścicielem" to awans wewnętrzny — patrz argument za najlepszym wyborem AI Lead^EN wewnątrz organizacji.

§6 — Które pięć antywzorców oblewa audyt z art. 14?

W każdym audycie pojawia się ten sam zestaw pięciu trybów awarii.

Interfejs „zatwierdź/odrzuć" jednym przyciskiem. Recenzent widzi tylko decyzję. Objaw: wskaźniki akceptacji powyżej 95 %, przeglądy poniżej 10 sekund. Naprawa: ujawnić pewność, rekord wejściowy i wskazane czynniki niepewności. Art. 14 ust. 4 lit. b) jest jednoznaczny co do skłonności do automatyzacji — recenzenci muszą „pozostawać świadomi możliwej skłonności do automatycznego polegania lub nadmiernego polegania na wyniku wytworzonym przez system AI wysokiego ryzyka" [1].

Pojedynczy recenzent, brak rotacji. Jeden dyrektor operacyjny przegląda każdą sprawę HITL. Objaw: wąskie gardła w weekendy, błędy ze zmęczenia pod koniec dnia, pojedynczy punkt awarii. Naprawa: przeszkolona pula 3–5 recenzentów na udokumentowanym harmonogramie rotacji.

Próg ustawiony raz, nigdy strojony. Wartości domyślne dostawcy pozostają niezmienione. Objaw: wolumen HITL daleko od pasma; wskaźniki unieważnień podejrzanie niskie lub chronicznie powyżej 20 %. Naprawa: kwartalny cykl z §5.

Brak ujmowania uzasadnienia unieważnień. Recenzenci mogą unieważniać, ale pole uzasadnienia jest opcjonalne lub puste. Objaw: nie da się wykazać rzeczywistego przeglądu. Naprawa: ustrukturyzowane ujmowanie — lista rozwijana z trzema głównymi powodami plus pole tekstowe, oba obowiązkowe.

Kolejka awaryjna bez SLA. Sprawy trafiają do „przeglądu przez człowieka" bez odpowiedzialności za rozpatrzenie w określonym oknie. Objaw: długość kolejki rosnąca z miesiąca na miesiąc, recenzenci pomijający starsze pozycje. Naprawa: jawne SLA na każdą ścieżkę awaryjną plus pulpit monitorowania kolejki z wyznaczonym właścicielem. Rozmyte właścicielstwo to ryzyko strukturalne; badanie BoE/FCA zauważa, że odpowiedzialność „bywa często podzielona, przy czym większość firm zgłasza trzy lub więcej osób lub podmiotów odpowiedzialnych" [9], a art. 14 aktu w sprawie sztucznej inteligencji składa nadzór na wskazaną „osobę fizyczną" [1].

§7 — Artykuł 14 i kalendarz na sierpień 2026

Rama zgodności to nie teatr swoisty dla jednej jurysdykcji. Wiele organów nadzoru zbiega się na tym samym teście operacyjnym; akt w sprawie sztucznej inteligencji przypisuje mu najbardziej publiczny termin. Art. 113 ustala datę rozpoczęcia stosowania obowiązków dla wysokiego ryzyka — w tym art. 14 — na 2 sierpnia 2026 r. [1]. Od tej daty firmy wdrażające AI w zakresach wysokiego ryzyka z załącznika III (zatrudnienie, scoring kredytowy, infrastruktura krytyczna, dane na potrzeby egzekwowania prawa) ponoszą ten obowiązek.

Article 22 UK GDPR już obowiązuje, a jego testem jest „rzeczywisty udział człowieka" [3] — uprawnienie, kompetencje, uwzględnienie danych wejściowych i alternatyw, sprzyjająca kultura oraz brak kary za unieważnienie modelu. Tam, gdzie Article 22 ma zastosowanie — wszędzie tam, gdzie decyzja wywołuje skutki prawne lub podobnie istotne — „przyklepywanie" oblewa test [2]. Stanowisko amerykańskie nie jest nieobecne: ustawy stanowe (Colorado AI Act, NYC AEDT, projektowane przepisy California ADMT) oraz egzekwowanie sektorowe (FTC w sprawie zautomatyzowanego podejmowania decyzji, NIST AI RMF jako punkt odniesienia w zamówieniach na użytek federalny) wymuszają tę samą dyscyplinę. ISO/IEC 23894:2023 standaryzuje leżące u podstaw podejście do zarządzania ryzykiem jako „wytyczne, jak organizacje ... mogą zarządzać ryzykiem swoiście związanym z AI" [7] — najczystszą kotwicę pozaregulacyjną dla rynków, na których swoiste dla AI ustawy jeszcze nie weszły w życie, i kręgosłup każdej wielojurysdykcyjnej polityki operacyjnej.

Regulatorzy sektorowi wzmacniają tę myśl: FCA jest neutralny technologicznie [10], unijne odpowiedniki pod auspicjami EBA i ECB zgadzają się co do odpowiedzialności kierownictwa wyższego szczebla, a badanie BoE/FCA z 2024 r. pokazuje, że w większości badanych firm odpowiedzialność jest zazwyczaj rozdrobniona między trzy lub więcej podmiotów [9].

Pytania projektowe z §§2–5 są pytaniami o zgodność w trzech tradycjach prawnych. Zbudowanie HITL w ten sposób płaci się raz; doposażanie po oblanym audycie płaci się co kwartał.

§8 — Jak wygląda czterotygodniowy sprint projektowy HITL?

Przeprojektowanie ma wyznaczone granice: to sprint na poziomie Operations-Lead, nie program.

Tydzień 1 — pomiar stanu obecnego. Zinwentaryzować każdy krok „przeglądu przez człowieka". Wyciągnąć wskaźniki akceptacji, rozkłady czasu przeglądu, stan ujmowania unieważnień, długości kolejek. Sygnatura biernej akceptacji: wysoki wskaźnik akceptacji, niski czas przeglądu, brak ustrukturyzowanego uzasadnienia unieważnień.

Tydzień 2 — projekt ścieżek decyzyjnych. Ustalić progi pewności na każdy proces, korzystając z punktów wyjścia z §2. Zaprojektować ścieżki awaryjne według §3. Zdefiniować schemat ścieżki audytu unieważnień według §4. Udokumentować policy_version v1.0 z wartościami progów, właścicielami i SLA.

Tydzień 3 — wdrożenie, szkolenie, zbieranie danych. Podłączyć zmiany w interfejsie — ujawnić rozumowanie modelu i pewność na ekranie recenzenta. Przeszkolić pulę recenzentów na opracowanych przykładach. Rozpocząć działanie na żywo z pełnym logowaniem audytowym od pierwszego dnia.

Tydzień 4 — pierwszy przegląd strojeniowy i dokumentacja gotowa do audytu. Uruchomić cykl z §5 na danych z tygodnia 3; oczywiste sygnały dryfu ujawniają się nawet w krótkim oknie. Złożyć pakiet artefaktów: definicje progów, pulpit wskaźnika unieważnień, inwentarz ścieżek eskalacji, mapę właścicielstwa. Rezultatem jest pozycja, którą można skonfrontować z 50 pytaniami, jakie decydenci zadają przed wdrożeniem AI^EN, obejmującymi Q3.10, Q5.4, Q5.5 i Q5.7.

Pasmo kosztów: 20–40 godzin czasu Operations-Lead. Wynik: protokół nadzoru gotowy pod art. 14, możliwa do obrony pod Article 22 pozycja „rzeczywistego przeglądu" oraz zgodna z NIST RMF funkcja MANAGE.

Od akceptacji do dyscypliny

Cztery tygodnie po przeprojektowaniu obraz operacyjny się przesunął. Wolumen HITL w procesie szkód spadł o 70 %, bo auto-odrzucenie wykonuje realną pracę na paśmie podprogowym. Średni czas przeglądu spraw, które trafiają do HITL, wzrósł do około czterech minut — czyli do czasu, jakiego ustrukturyzowany przegląd naprawdę wymaga. Wskaźnik unieważnień ustabilizował się na 14 %, wewnątrz zdrowego pasma 5–20 %, a każda unieważniona sprawa niesie ustrukturyzowane uzasadnienie. Pytanie inspektora ds. zgodności ma teraz odpowiedź z dołączonymi numerami wersji.

Różnica między teatrem audytowym a nadzorem, który obroni się w audycie, nie polega na tym, jak poważnie firma mówi o przeglądzie przez człowieka. Polega na tym, czy przegląd jest zaprojektowanym systemem progowym, czy zatwierdzeniem jednym kliknięciem. Jeden przechodzi audyt z art. 14. Drugi nie.

Aby zobaczyć, jak projekt HITL plasuje się w regulowanych procesach całej organizacji, easy-audit.ai mapuje to w ciągu dwóch godzin ustrukturyzowanych pytań.

Podsumowanie

HITL — designed oversight, not passive sign-off
│
├─ The failure · audit theatre
│   ├─ Passive sign-off — one-click approve, no reasoning shown
│   └─ Rubber-stamp test — >98% approve, <10s review fails it
│
├─ The system · thresholds & routes
│   ├─ Three routes — auto-reject / HITL review / auto-approve
│   ├─ Risk overlay — confidence × severity sets escalation
│   └─ Fallback paths — named owner, SLA, override audit log
│
└─ The discipline · stays honest
    ├─ Healthy band — 5–20% override; outside it, tune or retrain
    └─ Quarterly cycle — measure, spot drift, re-version, document