Zalanie kolejki zatwierdzeń przepycha szkodliwą akcję. Im więcej bramek, tym łatwiej

Żeby przepchnąć jedną szkodliwą akcję przez agenta pilnowanego przez człowieka, nie trzeba łamać modelu. Wystarczy zapełnić kolejkę zatwierdzeń pięćdziesięcioma nieszkodliwymi sprawami. Osoba, która klika „zatwierdź” pięćdziesiąty raz w ciągu godziny, patrzy inaczej niż przy pierwszej – i to jest mierzalne zjawisko, nie przytyk pod adresem recenzenta.

Mechanizm ma konsekwencję, która wywraca intuicję przy projektowaniu przepływu: im więcej akcji wymaga kliknięcia, tym łatwiej przepchnąć przez ten zestaw bramek rzecz, której nie powinny przepuścić. Zatrzymanie postawione „na wszelki wypadek” nie jest neutralne – zużywa uwagę, której brakuje przy zatrzymaniu, które naprawdę coś pilnuje.

Dlatego projektowanie punktów zatwierdzenia jest zadaniem inżynierskim z twardym kryterium, a nie kwestią ostrożności. Poniżej przepływ agenta do skrzynki zgłoszeniowej z czterema takimi punktami, z których dwa da się usunąć bez wzrostu ryzyka, a jeden trzeba usunąć właśnie z powodu opisanego wyżej.

Przepływ krok po kroku i miejsce, w którym staje

Przepływ, o którym jest ten tekst, wygląda tak:

• 1. Odczyt wiadomości. Agent pobiera nową wiadomość, wyciąga nadawcę, temat, treść i załączniki. Brak zatrzymania – operacja tylko do odczytu.
• 2. Klasyfikacja. Przypisanie kategorii i priorytetu, dopasowanie do istniejącego zgłoszenia albo założenie nowego. Punkt zatrzymania A: człowiek potwierdza kategorię.
• 3. Zebranie kontekstu. Odczyt historii klienta z CRM, sprawdzenie stanu zamówienia, pobranie właściwej procedury. Brak zatrzymania, o ile uprawnienia agenta są ograniczone do odczytu.
• 4. Przygotowanie odpowiedzi. Agent układa treść na podstawie procedury i kontekstu. Punkt zatrzymania B: człowiek czyta projekt odpowiedzi.
• 5. Wysłanie. Punkt zatrzymania C: człowiek zatwierdza wysyłkę.
• 6. Aktualizacja i zamknięcie. Zapis w systemie zgłoszeń, zmiana statusu. Punkt zatrzymania D: człowiek potwierdza zamknięcie.

Punkty B i C to w praktyce jedno zatrzymanie rozbite na dwa kliknięcia – człowiek czyta i zatwierdza w tej samej minucie. Punkt A zatrzymuje operację, której błąd jest tani i odwracalny: źle przypisaną kategorię widać przy pierwszym przeglądzie kolejki i poprawia się ją jednym kliknięciem. Punkt D zatrzymuje operację wewnętrzną, która nie dotyka klienta w ogóle.

Rachunek miesięczny przy tysiącu dwustu sprawach

Stawka i czas zatrzymania to parametry, które trzeba podstawić własne. Rzędy wielkości są jednak zbieżne z zestawieniami rynkowymi: jedna z analiz kosztu nadzoru przyjmuje 35 dolarów za godzinę pracy recenzenta i dwie minuty na zatwierdzenie, czyli 1,17 dolara za jedną bramkowaną akcję, i 5 850 dolarów miesięcznie przy pięciu tysiącach akcji. Ta sama analiza podaje przydatny punkt odniesienia dla decyzji: koszt zadania rośnie z 0,10-2,00 dolara dla agenta bez nadzoru do 1,30-4,00 dolara przy blokującym przeglądzie człowieka, a przy nadzorze warstwowym mieści się w 0,40-2,50 dolara.

Druga liczba z tej analizy jest ważniejsza niż koszt, bo wyznacza twardą granicę: recenzent pracujący po dwie minuty na akcję przechodzi około 240 zatwierdzeń w dniu skupionej pracy. Przy bramkowaniu wszystkiego w naszym przepływie dzienna kolejka to ponad 200 zatrzymań, czyli cały dzień jednej osoby – a agent miał tę osobę odciążyć.

W kolumnie kosztu modelu jest jeszcze pozycja, której ta tabela nie pokazuje, bo zależy od implementacji: każde zatrzymanie dzieli przebieg na dwa wywołania i kontekst sprawy trzeba podać ponownie po zatwierdzeniu. Przy przepływie z czterema punktami ten sam kontekst wchodzi do modelu pięć razy zamiast raz. Jeśli kontekst jest duży, bo obejmuje historię korespondencji i procedurę, koszt tokenów rośnie proporcjonalnie do liczby bramek – i to jest jedyna pozycja, w której cięcie zatrzymań obniża jednocześnie rachunek za nadzór i rachunek za model. Pamięć podręczna kontekstu po stronie dostawcy zbija ten narzut, ale go nie usuwa, bo okno jej ważności bywa krótsze niż czas oczekiwania na kliknięcie człowieka.

Dlaczego bramkowanie wszystkiego obniża bezpieczeństwo

Praca zgłoszona w czerwcu 2026 modeluje recenzenta jako zasób o skończonej pojemności, którego rzetelność spada po przekroczeniu pewnej liczby przeglądów. Wniosek autorów brzmi wprost: więcej nadzoru człowieka może uczynić system mniej bezpiecznym.

W symulacji optymalna stopa eskalacji wychodzi między 64 a 72 proc. w zależności od pojemności recenzenta i w żadnym wariancie nie wynosi 100 proc. – eskalowanie wszystkiego jest według autorów zawsze gorsze od optimum. Trzeba przy tym uczciwie powiedzieć, czego ta praca nie pokazuje: sami autorzy zaznaczają, że kształt spadku rzetelności jest założeniem modelu, a nie wynikiem pomiaru na ludziach, a zbiór testowy liczył 125 akcji oznaczonych przez jedną osobę. To argument za mechanizmem, nie liczba do przeniesienia do własnego przepływu.

Scenariusz z pierwszego akapitu ma w tej symulacji konkretne liczby. Polityka eskalująca 88 proc. rutynowych akcji przepuszczała 40 proc. szkodliwych działań już przy 50 akcjach wypełniających kolejkę, podczas gdy polityka eskalująca 26 proc. trzymała zero aż do około stu. Różnica nie bierze się z jakości recenzenta, a z tego, ile uwagi zostało mu na sprawę, która wymaga uwagi.

Trzecia obserwacja z tej pracy dotyczy czegoś, co psuje same kryteria: zgodność między recenzentami oceniającymi te same akcje wyszła na poziomie umiarkowanym, ze współczynnikiem Fleissa 0,52. Jeśli dwie osoby patrzące na tę samą akcję różnią się w ocenie, czy jest ryzykowna, to „człowiek zatwierdza” nie jest jeszcze żadną specyfikacją.

Które zatrzymanie kupuje coś realnego

Kryterium, które rozstrzyga, jest trójczłonowe i sprawdza się je dla każdej akcji osobno:

• Odwracalność. Czy skutek da się cofnąć bez udziału osoby z zewnątrz? Zmiana statusu zgłoszenia – tak. Wysłany e-mail do klienta – nie.
• Koszt błędu. Ile kosztuje jeden błąd tej kategorii, licząc czas naprawy i skutek u klienta. Błędna kategoria: kilka minut. Błędna kwota w odpowiedzi: reklamacja i korekta dokumentu.
• Wykrywalność po fakcie. Czy błąd wyjdzie sam w ciągu godzin, czy leży miesiącami. To najczęściej pomijany człon, a decyduje najmocniej: błąd, który sam się zgłasza, nie potrzebuje bramki, tylko logu.

Zatrzymanie ma sens, gdy akcja jest nieodwracalna, a jednocześnie koszt błędu przewyższa 1,17 dolara, czyli koszt samego przeglądu. Bramkowanie podsumowania wartego dziesięć groszy za złotówkę przeglądu jest arytmetycznie bez sensu i cytowana analiza nazywa to wprost – gate kosztuje tam dwunastokrotność wartości zadania.

Próg pewności zamiast zatrzymania na wszystkim

Większość zatrzymań, które da się usunąć, zastępuje się progiem pewności: agent sam rozpoznaje, kiedy nie wie, i tylko wtedy pyta. To przenosi decyzję z „jaki typ akcji” na „jak dobrze ta konkretna sprawa jest rozpoznana” – i zmniejsza liczbę zatrzymań o rząd wielkości, bo przypadków niejednoznacznych jest w normalnej skrzynce kilkanaście procent, nie sto.

Mechanika progów dla pojedynczych pól jest osobnym tematem, opisanym przy ekstrakcji danych z dokumentów, gdzie pola krytyczne dostają inny próg niż pozostałe. Zasada przenosi się na skrzynkę bez zmian: próg ustawia się per pole i per konsekwencja, nie globalnie dla całej sprawy.

Czego próg nie załatwi: agent zgłasza niepewność tam, gdzie ją wykrywa. Przypadek, w którym jest pewny i myli się, przechodzi przez każdy próg – i dlatego próg nigdy nie zastępuje logu i przeglądu próbkowanego. Ten sam problem mają automatyczne detektory w innych dziedzinach: nadzór z kamery nad wydrukiem też przepuszcza całą klasę awarii, których nie umie zobaczyć, i wniosek jest ten sam – detektor zdejmuje obciążenie, nie odpowiedzialność.

Log decyzji: pola, bez których jest tylko miejscem na dysku

Log, który ma służyć do czegokolwiek poza spokojem sumienia, zapisuje przy każdej akcji:

• Identyfikator sprawy i akcji – żeby dało się złożyć ścieżkę od wiadomości do skutku.
• Dane wejściowe w wersji, którą agent widział – nie wskaźnik do rekordu, który od tamtej pory się zmienił.
• Decyzję, uzasadnienie i poziom pewności – uzasadnienie bez pewności nie pozwala ustawić progu, pewność bez uzasadnienia nie pozwala zrozumieć pomyłki.
• Użyte narzędzia i zakres uprawnień – co agent wywołał i z jakimi prawami.
• Kto zatwierdził, kiedy i jak długo patrzył – ostatnie pole jest najmniej lubiane i najbardziej diagnostyczne: zatwierdzenia po sekundzie to informacja o tym, że bramka przestała działać.
• Wersję modelu i wersję instrukcji – bez tego nie da się odtworzyć, dlaczego tydzień temu wyszło inaczej.

Log zaprojektowany tak, by odpowiadał na pytanie „dlaczego ta sprawa poszła w ten sposób”, zdejmuje część zatrzymań, bo pozwala zamienić kontrolę uprzednią na próbkowaną. Log bez pól o zatwierdzeniu i czasie nie zdejmuje żadnego.

Czego nie da się odbramkować

Trzy kategorie, w których zatrzymanie zostaje niezależnie od rachunku.

Akcje nieodwracalne o wysokim koszcie. Przelew, zwrot, korekta dokumentu, zmiana warunków umowy. Tu nie liczy się częstotliwość, tylko pojedynczy skutek.

Zobowiązania wobec klienta. Termin, kwota, zakres. Nawet gdy agent ma je z procedury, podpisanie się pod nimi jest decyzją firmy, nie wynikiem klasyfikacji.

Sprawy objęte wymogiem nadzoru. Jeśli proces podlega regulacji wymagającej nadzoru człowieka, rachunek kosztu nadzoru przestaje być argumentem – staje się kosztem prowadzenia tej działalności. Zakres takich wymogów ustala się z osobą odpowiedzialną za zgodność, nie z arkusza.

Przy projektach, w których trzeba to rozstrzygnąć szybciej niż własnym researchem, sensowniej wziąć gotowy przepływ z już zaprojektowanymi punktami zatrzymania i logiem niż budować własny i odkrywać te same granice po trzech miesiącach.

Co zmienić w tym przepływie w tym tygodniu

Zacznij od policzenia dwóch liczb z własnego systemu: ile zatrzymań dziennie trafia do kolejki i jaki jest mediana czasu od pojawienia się zatrzymania do kliknięcia. Druga liczba mówi więcej niż pierwsza – jeśli mediana to kilka sekund, bramka już nie działa i jej usunięcie nie zmieni bezpieczeństwa, tylko ujawni stan faktyczny.

Potem usuń zatrzymania przy akcjach odwracalnych i wewnętrznych, czyli w naszym przepływie punkty A i D, i w to miejsce włącz log z przeglądem próbkowanym: pięćdziesiąt losowych spraw tygodniowo, przeglądanych przez tę samą osobę, która wcześniej klikała przy każdej. Zostaw twarde zatrzymanie przed wysyłką i przy operacjach nieodwracalnych. Po dwóch tygodniach porównaj liczbę błędów, które dotarły do klienta, z okresem przed zmianą – jeśli nie wzrosła, a godziny nadzoru spadły z czterdziestu do siedmiu, decyzja jest podjęta i można ją zapisać jako regułę dla kolejnych przepływów.