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 akciu preverí a schváli skôr, než agent koná. HITL je praktickou realizáciou ľudského dohľadu, ktorý vyžaduje čl. 14 EU AI Act, a zároveň kľúčovým protiopatrením voči agentickému riziku OWASP 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 v kombinácii.
• Čo sa najčastejšie pokazí: brána sa zvrhne na mechanické odkývanie (Automation Bias). UX a audit tomu musia aktívne zabrániť.

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 ľudským potvrdzovaním jednotlivých krokov. Práve táto autonómia zväčšuje útočnú plochu. Položka OWASP ASI02 (Tool Misuse & Exploitation) uvádza režimy Auto-Approve alebo „YOLO“, ktoré vypínajú potvrdzovacie dialógy, ako samostatný útočný vektor. Naše odporúčanie: vypni Auto-Approve pre každý nástroj, ktorý sa dotýka databáz, platieb, komunikácie alebo nasadení (deploymentov), a nahraď ho schvaľovacími bránami Human-in-the-Loop.

HITL teda nie je komfortná funkcia UX, ale bezpečnostná kontrola. Obmedzuje škodu, ak agent v dôsledku Goal Hijack (ASI01), otrávenej pamäte (ASI06) alebo kompromitovaného dodávateľského reťazca (ASI04) začne konať proti zámeru svojich prevádzkovateľov.

Kedy je potrebné ľudské schválenie?

Rozhodnutie „brána áno/nie“ by nemalo padnúť ad hoc, ale vyplynúť z dokumentovanej klasifikácie rizík. Väčšinu prípadov pokryjú tri kritériá:

• Nezvratnosť. Dá sa akcia vrátiť späť len s veľkým úsilím alebo vôbec nie? Mazanie, výplaty, odosielanie zákazníkom, žiadané hodnoty vo výrobe.
• Náklady. Spúšťa akcia značné alebo ťažko ohraničiteľné náklady? Hromadné volania API, objednávky, zriaďovanie infraštruktúry.
• Právna relevancia. Má akcia právne následky alebo sa týka osobných údajov? Zmluvy, rozhodnutia o úveroch alebo dávkach, hlásenia podozrivých transakcií, export kmeňových údajov.

Naopak, operácie, ktoré len čítajú, alebo ľahko vratné akcie v sandboxe bránu spravidla nepotrebujú. Inak vzniká „approval fatigue“ a kontrolóri z únavy všetko odkývajú.

Vzory HITL: Pre-Action, Checkpoint, Escalation

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

Pre-Action-Approval. Agent sa zastaví tesne pred jednou kritickou akciou. Plánovaná akcia aj s argumentmi ide do schvaľovacej fronty; vykoná sa až po súhlase človeka. Vhodné na 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ž sa spustí ďalší segment. Vhodné na dlhšie workflowy, v ktorých sú jednotlivé kroky samy osebe neškodné, kumulatívna cesta sa však stáva kritickou. Tento vzor reaguje na scenár „Boiling Frog“, ktorý opisuje OWASP: každý krok je vierohodný, celková trajektória je však škodlivá.

Escalation-on-Anomaly. Agent pracuje autonómne a človeka privolá len vtedy, keď sa prekročia prahové hodnoty alebo zareagujú detektory anomálií: nezvyčajná frekvencia volaní nástrojov, deštruktívne operácie krátko po načítaní externého obsahu, porušenia limitov počtu požiadaviek (rate limit). Technicky sa to dá realizovať pomocou Policy-as-Code (napr. s Open Policy Agent (OPA) alebo Cedar) ako schvaľovacia brána pre použitie nástrojov.

Účinná architektúra HITL odstupňuje dôveru: rozhodnutia s väčším dopadom vyžadujú viac kontrolórov alebo silnejšie dôkazy („graduated trust“). Podľa OWASP je rozhodujúce, aby brána vyžadovala nezávislé overenie podkladov, nielen odporúčanie agenta.

Matica akcia-riziko-HITL

Nasledujúca matica na príkladoch ukazuje, ako sa dajú akcie klasifikovať. Slúži ako šablóna; konkrétne prahy musí každá organizácia prispôsobiť svojmu apetítu na riziko.

Najčastejšia chyba: brána degeneruje

Najväčším rizikom nie je chýbajúca brána, ale jej postupné, nenápadné vyprázdňovanie. OWASP ho vedie ako samostatné riziko v Top 10: ASI09 (Human-Agent Trust Exploitation). Agenti vytvárajú vybrúsený výstup, ktorý znie autoritatívne; ľudia majú sklon ho preberať. Dohľadová vrstva, ktorá mala slúžiť ako bezpečnostná kontrola, sa tak sama stáva slabinou.

Relevantné mechanizmy:

• Automation Bias: výstup sa prijíma bez kritickej kontroly.
• Authority Deference: suverénny tón odrádza od otázok.
• Gradual Trust Escalation: agent si správnymi výstupmi buduje dôveryhodnosť, skôr než prídu manipulované.
• Cognitive Overload: objem a zložitosť prevyšujú ľudskú kapacitu na kontrolu.
• „Polished Hallucination“: sebavedomý, nesprávny a presvedčivý výstup.

Detekčné signály, podľa ktorých sa dá degradácia merať: čas rozhodovania kontrolórov klesá pri nezmenenej zložitosti úloh a vzorce schvaľovania extrémne silno korelujú s odporúčaním agenta. Oboje naznačuje mechanické odkývanie.

UX dizajn, ktorý vynucuje kontrolu

HITL stojí a padá s rozhraním. Holé tlačidlo „Approve“ zvádza k schvaľovaniu naslepo. Proti tomu pomáhajú vzory Force-Engagement, ktoré vynucujú skutočnú kontrolu:

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

Modelový scenár: obstarávacia kaskáda

Na jednom scenári je zlyhanie HITL dobre vidieť. Predpokladajme, že obstarávacieho agenta počas troch týždňov postupne presvedčia, že jeho schvaľovací limit je 500 000 USD. Potom útočník v desiatich transakciách zadá falošné objednávky v celkovej hodnote 5 miliónov USD. Ľudský schvaľovateľ verí agentovi, ktorý čoraz dôraznejšie tvrdí, že má oprávnenie na vyššie sumy. Učebnicový prípad ASI09, zosilnený kaskádovými chybami (ASI08).

V pseudokóde by sa účinná brána Pre-Action dala načrtnúť takto:

```text
on agent_action(action):
risk = classify(action) # vratnosť, náklady, právo
if risk in {VYSOKÉ, KRITICKÉ}:
evidence = gather_provenance(action) # zdroje, istota, zdôvodnenie
approver = route_by_amount(action) # >limit -> princíp štyroch očí / eskalácia
decision = require_human(evidence,
enforce_delay=True,
show_reasoning=True)
audit_log.write_worm(action, evidence, decision) # podpísané
if not decision.approved: abort()
execute(action)
```

Dôležité: limit (route_by_amount) leží mimo pamäte agenta a je chránený proti manipulácii. Inak si agent vlastný limit prepíše, ako v príklade.

Audit: bez protokolu niet dohľadu

Ľudský dohľad obstojí len vtedy, keď sa dá preukázať. Ako forenzné minimum patrí do protokolu pri každej akcii agenta: úplný prompt (používateľský, systémový a injektovaný kontext), verzia modelu a hash konfigurácie, sekvencia volaní nástrojov s argumentmi, dopyty pri vyhľadávaní (retrieval) a ID dokumentov, výstup a zdôvodnenie rozhodnutia, udalosti Human-Override, čítanie z pamäte a zápis do nej, ako aj náklady a latencia.

Osvedčili sa WORM logy (write-once-read-many) a kryptografický podpis, vďaka ktorému je manipulácia rozpoznateľná. Pokiaľ ide o uchovávanie, EU AI Act pri vysokorizikových systémoch stanovuje spodnú hranicu: poskytovatelia a nasadzujúce subjekty musia automaticky generované logy, pokiaľ ich majú pod kontrolou, uchovávať najmenej šesť mesiacov (čl. 19, čl. 26 ods. 6), ak právo Únie alebo vnútroštátne právo neustanovuje inak. Ak agent spúšťa obchodné operácie, napríklad objednávky alebo platby, na účtovné doklady a obchodnú korešpondenciu sa navyše vzťahujú lehoty uchovávania podľa obchodného práva, v Rakúsku sedem rokov podľa § 212 UGB. Tieto logy sú zároveň tvojím dôkazom pre audítorov, že HITL v praxi funguje.

Vzťah k regulácii (nejde o právne poradenstvo)

EU AI Act v čl. 14 vyžaduje pri vysokorizikových systémoch AI účinný ľudský dohľad. Ods. 4 písm. b) výslovne uvádza Automation Bias, teda presne mechanizmus, ktorý stojí za OWASP ASI09. Túto povinnosť má pri návrhu poskytovateľ: systém vrátane rozhrania človek-stroj musí postaviť tak, aby osoby vykonávajúce dohľad dokázali Automation Bias rozpoznať a zasiahnuť. Nasadzujúci subjekt musí podľa čl. 26 ods. 2 určiť na dohľad osoby s potrebnou kompetenciou, odbornou prípravou a právomocou. Kto agentov sám vyvíja aj nasadzuje, zastáva obe roly.

Okrem toho nemecký BSI a francúzska ANSSI vydali v auguste 2025 dokument Design Principles for LLM-based Systems with Zero Trust. Zaoberá sa okrem iného autentifikáciou a autorizáciou, sandboxingom a monitorovaním a v kritických prípadoch vyžaduje súhlas používateľa ako Human-in-the-Loop.

Poznámka: Tento článok ponúka odborno-technický pohľad a nenahrádza právne poradenstvo. Či tvoj konkrétny systém patrí medzi vysokorizikové systémy AI v zmysle EU AI Act a aké povinnosti z toho vyplývajú, treba vyjasniť s kvalifikovaným právnym poradcom.

Pre agentúry a B2B rozhodovateľov

Kto stavia agentov pre zákazníkov alebo ich nasadzuje vo vlastnej prevádzke, mal by HITL chápať nie ako dodatočnú funkciu, ale ako architektonické rozhodnutie. Konkrétne: matica akcia-riziko ako súčasť návrhu každého agenta, odstupňované schválenia namiesto paušálneho Auto-Approve, rozhranie Force-Engagement proti Automation Bias a auditné logy odolné proti manipulácii od začiatku. Blck Alpaca z Viedne pomáha firmám v regióne DACH navrhovať agentické workflowy tak, aby autonómia a ľudský dohľad boli v správnej rovnováhe: bezpečne, preukázateľne a kompatibilne s EU AI Act a OWASP Agentic Top 10.