Oversight ma pojemność: dlaczego więcej ludzkiej kontroli może uczynić agentów mniej bezpiecznymi

Gdy agent zaczyna podejmować działania trudne do cofnięcia — uruchamianie shell command, edycję pliku, wypchnięcie deploya — standardowym ruchem na rzecz bezpieczeństwa jest odruch, który wydaje się oczywiście słuszny: postaw człowieka w pętli. Ryzykowne działania zatrzymują się i czekają, aż człowiek je zatwierdzi. Więcej kontroli, więcej bezpieczeństwa. To wzorzec, po który sięga niemal każdy zespół jako pierwszy, i to ten, który badanie z 2026 roku właśnie skomplikowało w niewygodny sposób: powyżej pewnego punktu więcej ludzkiego oversight czyni system mniej bezpiecznym.

To nie paradoks dla samego paradoksu. Wynika on z faktu, który wszyscy znają i który większość projektów bezpieczeństwa ignoruje — człowiek dokonujący przeglądu jest skończonym, męczącym się zasobem. Potraktuj tego człowieka jako nieskończonego, a zbudujesz gate, który po cichu przestaje działać dokładnie wtedy, gdy najbardziej na nim polegasz.

Approval gate i jego ukryty koszt

Human-in-the-loop approval gate to naprawdę dobry projekt dla właściwych działań. Jeśli agent ma za chwilę usunąć produkcyjną bazę danych albo przelać pieniądze, chcesz, żeby człowiek najpierw na to spojrzał. Logika jest słuszna, a dla działań o wysokiej stawce i nieodwracalnych to poprawny wzorzec.

Kłopoty zaczynają się, gdy ten sam odruch zostaje zastosowany do wszystkiego, co wygląda ryzykownie. Każda eskalacja wydaje jednostkę rzadkiego zasobu: ludzkiej uwagi. A ludzka uwaga nie degraduje się łagodnie pod obciążeniem — ona się załamuje. Recenzent poproszony o zatwierdzenie pięciu starannie wybranych działań dziennie czyta każde z nich. Ten sam recenzent poproszony o zatwierdzenie dwustu zaczyna dopasowywać wzorce, potem przybijać pieczątki, a potem odruchowo klikać „zatwierdź”, żeby opróżnić kolejkę. Gate wciąż jest na schemacie organizacyjnym. W rzeczywistości przestał być gate’em.

Więc koszt eskalowania działania nie jest zerowy i nie jest nawet stały — każda zbędna eskalacja degraduje jakość przeglądu każdej innej eskalacji, włącznie z tą, która faktycznie miała znaczenie.

Odwrócona litera U: więcej oversight, mniej bezpieczeństwa

To właśnie postanowił zmierzyć artykuł z 2026 roku Oversight Has a Capacity (arXiv 2606.08919), dokładnie w ustawieniu, które ma znaczenie: „LLM agents [zaczynający] podejmować realne, nieodwracalne działania (shell commands, edycje plików, deploye)”, strzeżeni przez „human-in-the-loop approval gate”. Jego centralny wniosek jest bezceremonialny: „więcej ludzkiego oversight może uczynić system mniej bezpiecznym, a optymalny pod względem bezpieczeństwa gate eskaluje poniżej pełnej eskalacji.”

Kształt tego to odwrócona litera U. Eskaluj za mało, a ryzykowne działania przeciekną nieprzejrzane — oczywiście niebezpieczne. Ale eskaluj za dużo, a zalejesz recenzenta, jakość przeglądu się załamie, a niebezpieczne działania przeciekną zatwierdzone — także niebezpieczne, i bardziej podstępnie, bo teraz noszą pieczątkę człowieka. Faktyczne bezpieczeństwo osiąga szczyt gdzieś pośrodku, przy umiarkowanym wskaźniku eskalacji. „Eskaluj wszystko” nie jest bezpiecznym końcem pokrętła; to przekroczenie szczytu krzywej i zjazd po drugiej stronie.

Warto wyobrazić sobie, jak ta awaria faktycznie nadchodzi, bo nie jest dramatyczna. Nikt nie postanawia przestać przeglądać. Kolejka po prostu rośnie: do wczesnego popołudnia jest sześćdziesiąt oczekujących zatwierdzeń, każde wygląda jak pięćdziesiąt poprzednich, a recenzent — pod presją, żeby odblokować agentów i ludzi czekających na nich — wpada w rytm pobieżnego przeglądania i zatwierdzania. Dziewięćdziesiąte pierwsze zatwierdzenie tego dnia to to, które usuwa tabelę, i przeszło w dwie sekundy jednym kliknięciem, bo do tej pory kliknięcie było przeglądem. Gate nie zawiódł głośno. Erodował, po cichu, dokładnie pod tym wolumenem, który gwarantuje „eskaluj wszystko”. To właśnie pułapka: polityka, która wydaje się maksymalnie ostrożna, jest tą, która produkuje warunki dla przepuszczonej katastrofy.

Instynkt, by maksymalizować oversight, innymi słowy, optymalizuje niewłaściwą wielkość. Nie chcesz maksymalnej liczby eskalacji. Chcesz maksymalnego efektywnego przeglądu, a te dwie rzeczy rozchodzą się w momencie, gdy człowiek się zmęczy.

Oversight to budżet, nie checkbox

Przeformułowanie, które oferuje artykuł, jest użyteczną częścią: „oversight agenta … nie jest tylko problemem klasyfikacji, ale problemem alokacji zasobów: ludzka uwaga jest skończona, a polityka eskalacji gate’u ją wydaje.” To zdanie powinno zmienić sposób, w jaki projektujesz gate.

Traktowanie oversight jako klasyfikacji — czy to działanie jest ryzykowne, tak czy nie, eskaluj jeśli tak — niejawnie zakłada, że człowiek może wchłonąć dowolnie wiele przypadków „tak”, które wyprodukuje klasyfikator. Traktowanie tego jako alokacji zasobów startuje z przeciwnej przesłanki: masz stały budżet uwagi na recenzenta na godzinę, a zadaniem polityki eskalacji jest wydać ten budżet tam, gdzie kupuje najwięcej bezpieczeństwa. Każda eskalacja to wypłata. Wydaj ją na autentycznie niejednoznaczne, nieodwracalne decyzje o dużym blast radius; nie wydawaj jej na tysiąc działań o niskiej stawce, które klasyfikator oznaczył tylko na wszelki wypadek, bo każda z tych wypłat zostawia mniej na koncie na decyzję, która się liczy.

Jest drugi wniosek, który czyni podejście kruchego klasyfikatora jeszcze gorszym: ryzyko jest subiektywne. Artykuł donosi, że ludzcy recenzenci „tylko umiarkowanie zgadzają się co do tego, co jest ryzykowne (Fleiss’ kappa = 0,52)” — nie ma jednej poprawnej etykiety dla tego, które działania są niebezpieczne. Więc gate zbudowany jako wyrazisty klasyfikator ryzyka nie tylko wydaje budżet źle; wydaje go wobec celu, co do którego rozsądni ludzie nawet się nie zgadzają. Problem projektowy nie brzmi „zbuduj idealny detektor ryzyka”. Brzmi „mądrze alokuj sporny, skończony zasób w warunkach niepewności”.

Projektowanie gate’u, a nie tylko jego instalowanie

Jeśli oversight to budżet, to polityka eskalacji jest tym, jak go wydajesz, a kilka zasad wynika z tego wprost:

Kategoryzuj działania według odwracalności i blast radius, nie według powierzchownego ryzyka. Działanie trywialnie odwracalne albo sandboxowane ledwie potrzebuje człowieka, jakkolwiek przerażająco wygląda; nieodwracalne działanie o szerokim blast potrzebuje go, nawet jeśli wygląda rutynowo. To tutaj sandboxowanie agenta wypłaca drugą dywidendę: każde działanie, którego blast radius już ograniczyłeś, to działanie, na które nie musisz wydawać ludzkiej uwagi. Powstrzymywanie i oversight wymieniają się: im więcej izolujesz, tym mniej musisz eskalować.
Pozwól agentowi samodzielnie eskalować, gdy trudność rośnie. Agent, który podnosi własny wskaźnik meldowania się, gdy zadanie staje się trudniejsze, niejednoznaczne albo o wyższej stawce, daje uczciwszy sygnał niż pojedynczy confidence score — i koncentruje ludzki budżet dokładnie na tych momentach, które na to zasługują.
Chroń recenzenta przed zmęczeniem, które psuje gate. Ogranicz wskaźnik eskalacji, rotuj recenzentów i traktuj zalaną kolejkę jako incydent bezpieczeństwa, a nie kłopot kadrowy — bo zmęczony recenzent to zawiedziony gate, który wciąż raportuje „zatwierdzone”. Oprzyrząduj to: jeśli twój wskaźnik zatwierdzeń wynosi 99%, a mediana czasu przeglądu to dwie sekundy, nie masz warstwy oversight, masz podatek opóźnienia, który produkuje fałszywy zapis ludzkiego osądu. Te dwie liczby są wczesnym ostrzeżeniem, że budżet jest przewydany.

Myśl przewodnia: human-in-the-loop nie jest funkcją bezpieczeństwa, którą włączasz; to system, który stroisz. Stawialiśmy ten sam argument o warstwie guardrail jako realnej powierzchni produktowej, a nie doczepce, i to ona pozwala ci prowadzić pętle agentów bez nadzoru, gdy śpisz — te pętle pozostają bezpieczne tylko wtedy, gdy polityka tego, kiedy budzić człowieka, jest skalibrowana do człowieka, którego nie da się obudzić sto razy w ciągu nocy.

Dlaczego sprzyja to Azji Południowo-Wschodniej

Oto część, która liczy się dla tego regionu, i jest to teraz znajomy kształt. Zaprojektowanie skalibrowanej polityki eskalacji — kategoryzowanie działań, ustawianie wyzwalaczy samodzielnej eskalacji, budżetowanie uwagi recenzenta — to czysty osąd systemowy. Nie kosztuje GPU, frontierowego modelu ani kapitału. To praca starannego myślenia o tym, które decyzje faktycznie potrzebują człowieka i jak utrzymać tego człowieka w ostrości, a działa w całości na dyscyplinie inżynierskiej.

To przewaga, bo odruchowym ruchem wszędzie indziej jest „dodaj człowieka w pętli” i nazwij to bezpieczeństwem — co, jak pokazują badania, może wyprodukować zmęczonego recenzenta przybijającego pieczątkę kolejce, czyli mniej bezpieczeństwa w kostiumie większego. Zespół w Phnom Penh albo Da Nang, który zamiast tego traktuje oversight jako rzadki budżet — eskalując mniej, ale przeglądając lepiej — buduje agentów faktycznie bezpieczniejszych do wdrożenia na doniosłej, regulowanej pracy, i robi to bez wydania dolara więcej niż konkurent, który topi swoich recenzentów. Gdy agenci podejmują coraz więcej nieodwracalnych działań, zespołami, które zdobędą zaufanie, nie będą te z największym oversight. Będą to te, które wydały skończony budżet ludzkiej uwagi tam, gdzie faktycznie miało to znaczenie.