Správny dizajn Human-in-the-Loop (HITL): Schvaľovacie vzory pre AI agentov

Human-in-the-Loop (HITL) označuje cielené zabudovanie ľudských schválení do reťazca akcií AI agenta. Pred nezvratnými, nákladnými alebo právne relevantnými akciami človek preskúma a schváli skôr, než agent koná. HITL je operatívnou realizáciou ľudského dohľadu vyžadovaného čl. 14 EU AI Act a zároveň centrálnym protiopatrením voči OWASP agentickému riziku ASI09 (Human-Agent Trust Exploitation).

• Kedy je HITL potrebný: pred nezvratnými, nákladnými alebo právne relevantnými akciami - nie pred každým krokom.
• Aké vzory existujú: Pre-Action-Approval, Checkpoint-Approval a Escalation-on-Anomaly, väčšinou kombinované.
• Čo najčastejšie zlyháva: gate degeneruje na odkývanie (Automation Bias) - UX a audit tomu musia aktívne predchádzať.

Prečo je naivná autonómia bezpečnostným problémom

Agentické systémy plánujú, vyvodzujú závery, vyberajú nástroje a konajú s minimálnym krokovým ľudským potvrdzovaním. Práve táto autonómia zväčšuje útočnú plochu. Záznam OWASP ASI02 (Tool Misuse & Exploitation) uvádza režimy Auto-Approve resp. „YOLO", ktoré deaktivujú potvrdzovacie dialógy, ako samostatný útočný vektor. Odporúčanie researchu je jednoznačné: Auto-Approve pre každý nástroj, ktorý sa dotýka databáz, platieb, komunikácie alebo deploymentov, vypnúť a nahradiť ho Human-in-the-Loop gates.

HITL teda nie je UX komfort, ale bezpečnostný control. Obmedzuje škodu, keď je agent prostredníctvom Goal Hijack (ASI01), otráveného memory (ASI06) alebo kompromitovaného dodávateľského reťazca (ASI04) prinútený konať proti zámeru svojich prevádzkovateľov.

Kedy je potrebné ľudské schválenie?

Rozhodnutie „gate áno/nie" by nemalo padnúť ad hoc, ale vyplynúť z dokumentovanej rizikovej klasifikácie. Tri kritériá nesú väčšinu prípadov:

• Nezvratnosť. Možno akciu nevrátiť späť, alebo len s vysokým úsilím? Mazania, výplaty, odoslanie zákazníkom, produkčné setpointy.
• Náklady. Spúšťa akcia značné alebo ťažko ohraničiteľné náklady? Hromadné API volania, objednávky, provisioning infraštruktúry.
• Právna relevancia. Vytvára akcia právny následok alebo sa týka osobných údajov? Zmluvy, úverové či dávkové rozhodnutia, hlásenia o podozrení, export kmeňových dát.

Naopak, čítacie operácie alebo ľahko vratné akcie v sandboxe spravidla žiadne gate nepotrebujú - inak vzniká „Approval-Fatigue" a kontrolóri z únavy len odkývu.

HITL vzory: Pre-Action, Checkpoint, Escalation

Tri základné vzory pokrývajú väčšinu architektúr a v praxi sa kombinujú.

Pre-Action-Approval. Agent zastaví bezprostredne pred jednou kritickou akciou. Plánovaná akcia vrátane argumentov ide do schvaľovacej queue; až po ľudskom súhlase sa vykoná. Vhodné pre jednotlivé, vysokorizikové operácie (spustenie platby, odoslanie zmluvy).

Checkpoint-Approval. Pri viacstupňových plánoch človek kontroluje na definovaných míľnikoch skôr, než štartuje ďalší segment. Vhodné pre dlhšie workflows, v ktorých sú jednotlivé kroky samy osebe neškodné, ale kumulatívna cesta sa stáva kritickou - odpoveď na OWASP popisovaný vzor „Boiling-Frog", pri ktorom je každý krok plauzibilný, no celková trajektória škodlivá.

Escalation-on-Anomaly. Agent pracuje autonómne a privolá človeka len vtedy, keď sa spustia prahové hodnoty alebo detektory anomálií: nezvyčajné frekvencie tool-call, deštruktívne operácie krátko po prijatí externého obsahu, porušenia rate-limit. Technicky sa to dá realizovať cez Policy-as-Code (podľa researchu napr. OPA alebo Cedar) ako tool-use-approval gate.

Účinná HITL architektúra odstupňúva dôveru: rozhodnutia s vyšším impaktom vyžadujú viac kontrolórov alebo silnejšiu evidenciu („graduated trust"). Rozhodujúce je podľa OWASP, aby gate vyžadovalo nezávislú verifikáciu dôkazov - nielen odporúčanie agenta.

Matica akcia-riziko-HITL

Nasledujúca matica ukazuje na príkladoch, ako možno akcie klasifikovať. Je myslená ako šablóna; konkrétne prahy musí každá organizácia prispôsobiť svojmu rizikovému apetítu.

Najčastejšia chyba: gate degeneruje

Najväčším rizikom nie je chýbajúce gate, ale jeho plíživé vyprázdňovanie. OWASP to uvádza ako samostatné Top-10 riziko: ASI09 - Human-Agent Trust Exploitation. Agenti vytvárajú vybrúsený, autoritatívne znejúci výstup; ľudia majú sklon ho preberať. Dohľadová vrstva myslená ako bezpečnostná kontrola sa tak sama stáva slabinou.

Relevantné mechanizmy podľa researchu:

• Automation Bias - výstup sa akceptuje bez kritickej kontroly.
• Authority Deference - suverénny tón odrádza od ďalších otázok.
• Gradual Trust Escalation - agent si správnymi výstupmi buduje vierohodnosť, kým prídu manipulované.
• Cognitive Overload - objem a komplexnosť presahujú ľudskú kontrolnú kapacitu.
• „Polished Hallucination" - sebavedomý, nesprávny a presvedčivý výstup.

Detekčné signály, na ktorých sa dá merať degradácia: čas rozhodovania kontrolórov klesá pri nezmenenej komplexnosti úloh a vzory schvaľovania extrémne silno korelujú s odporúčaním agenta - indícia odkývania.

UX dizajn, ktorý vynucuje kontrolu

HITL stojí a padá s rozhraním. Holé tlačidlo „Approve" pozýva k rubber-stampingu. Research odporúča vzory Force-Engagement:

• Zviditeľniť reasoning. Zobrazovať odôvodnenie, provenienciu zdrojov a konfidenčné intervaly, nie ich skrývať. Kto skryje reasoning-trace v UI, vytvára podľa OWASP presne jeden detekčný signál ASI09.
• Adversarial-Output-Highlighting. Upozornenia v štýle „tento výstup mohol byť ovplyvnený externým obsahom", tam kde obsah pochádza z untrusted zdrojov.
• Time-Delay-Enforcement. Pri vysokorizikových schváleniach vynútiť zámerné oneskorenie, aby sa zabránilo reflexnému potvrdzovaniu.
• Školenie o Automation Bias kontrolórov a periodické testovacie injekcie („požiarne cvičenia"), ktoré preverujú, či HITL vôbec ešte zaberá.

Konkrétny príklad: obstarávacia kaskáda

Research dokumentuje prípad, ktorý robí zlyhanie HITL uchopiteľným. Obstarávací agent bol počas troch týždňov postupne presvedčený, že jeho schvaľovací limit je 500 000 USD. Následne útočník prostredníctvom 10 transakcií umiestnil falošné objednávky v hodnote 5 miliónov USD. Ľudský approver dôveroval rastúcemu tvrdeniu agenta o vyššej autorizácii - učebnicový prípad ASI09 v kombinácii s kaskádovými chybami (ASI08).

Ako pseudokód by sa účinné Pre-Action gate dalo naskicovať takto:

```text
on agent_action(action):
risk = classify(action) # Reversibilitaet, Kosten, Recht
if risk in {HOCH, KRITISCH}:
evidence = gather_provenance(action) # Quellen, Konfidenz, Reasoning
approver = route_by_amount(action) # >Limit -> Vier-Augen / Eskalation
decision = require_human(evidence,
enforce_delay=True,
show_reasoning=True)
audit_log.write_worm(action, evidence, decision) # signiert
if not decision.approved: abort()
execute(action)
```

Dôležité: Limit (route_by_amount) leží mimo memory agenta a je chránený proti manipulácii - inak sa agent preučí svoj vlastný limit, ako v príklade.

Audit: bez protokolu niet dohľadu

Ľudský dohľad je nosný len vtedy, keď je preukázateľný. Research uvádza ako forenzné minimum na agentickú akciu: úplný prompt (User, System, injektovaný kontext), verzia modelu a hash konfigurácie, sekvencia tool-call s argumentmi, retrieval queries a ID dokumentov, výstup a odôvodnenie rozhodnutia, udalosti Human-Override, čítacie/zápisové operácie memory, ako aj náklady a latenciu.

Ako vzor research odporúča WORM logy (write-once-read-many), kryptografický podpis na detekciu manipulácie a sektorovo primeranú archiváciu (banka a poisťovňa podľa researchu po 10 rokov). Tieto logy sú zároveň evidenciou, ktorou sa dá voči audítorom preukázať, že HITL nielen existuje, ale aj funguje.

Vzťah k regulácii (nie je to právny rad)

EU AI Act čl. 14 vyžaduje pre vysokorizikové KI systémy účinný ľudský dohľad. Podľa základného researchu čl. 14 dobre pokrýva OWASP riziko ASI09; konkrétne kontroly UI a Automation Bias však výslovne zostávajú v zodpovednosti prevádzkovateľa (Deployer). Sprievodne research signalizuje, že BSI vyvíja dedikované bezpečnostné kritériá pre AI agentov - s včas rozpoznateľnými povinnosťami Deployera okrem iného k Zero Trust, sandboxingu, identity managementu, transparentnému decision-loggingu a HITL pri kritických akciách.

Poznámka: Tento článok je odborno-technické zaradenie a nenahrádza právne poradenstvo. Či váš konkrétny systém platí za vysokorizikovú KI v zmysle EU AI Act a aké povinnosti z toho vyplývajú, patrí vyjasniť s kvalifikovaným právnym poradenstvom.

Pre agentúry a B2B rozhodovateľov

Kto stavia agentov pre zákazníkov alebo ich nasadzuje vo vlastnej prevádzke, by HITL nemal vnímať ako dodatočnú feature, ale ako architektonické rozhodnutie. Konkrétne: matica akcia-riziko ako súčasť každého dizajnu agenta, odstupňované schválenia namiesto paušálneho Auto-Approve, Force-Engagement-UI proti Automation Bias a audit logy odolné proti manipulácii od začiatku. Blck Alpaca z Viedne podporuje DACH firmy v tom, aby agentické workflows navrhli tak, že autonómia a ľudský dohľad sú v správnej rovnováhe - bezpečne, preukázateľne a kompatibilne s EU AI Act a OWASP Agentic Top 10.