V první části naší série jsme položili základní otázku: kdy by měl člověk zastavit AI?
Ve druhé jsme analyzovali autonomii agentů a snažili se odpovědět na otázku, jak daleko lze nechat umělou inteligenci působit samostatně.
Ve třetí jsme přešli na úroveň organizace a mluvili jsme o AI Governance, odpovědnosti, bezpečnosti, monitorování a principech kontroly.
Teď je čas spojit všechny tyto prvky dohromady.
Protože můžete mít skvělou AI strategii. Můžete mít dobré postupy. Můžete najmout nejlepší inženýry. Můžete vybrat vynikající model. Ale nakonec vše se smrští na jednu otázku: Jak postavit systém, který je dostatečně autonomní, aby skutečně přinášel hodnotu, ale zároveň dostatečně kontrolovaný, aby se nestal zdrojem nepřijatelného rizika?
To je jeden z nejdůležitějších problémů návrhu systémů AI nové generace. A tady Human-in-the-Loop přestává být prostou funkcí „klikni Schválit“. Stává se součástí celé architektury systému.
AI by nemělo být navrhováno jako „černá skříňka“
Představme si klasický systém:
- Uživatel pošle dotaz.
- Model AI analyzuje data.
- Model vygeneruje odpověď.
- Uživatel ji obdrží.
To může stačit pro jednoduchého chatbota.
Ale situace vypadá úplně jinak, když AI získá přístup k firemním systémům.
Například:
- AI přečte zprávu od klienta.
- Rozpozná jeho záměr.
- Zkontroluje historii objednávek.
- Analyzuje dostupnost produktu.
- Nabídne řešení.
- Odesílá odpověď.
- Spustí reklamační postup.
- Nařídí vrácení peněz.
- A následně aktualizuje data v CRM.
To už není jediný model AI.
To je systém vykonávající akce ve skutečném světě.
A právě proto musí architektura zohledňovat nejen samotný model, ale celý řetězec: data → model → rozhodnutí → nástroje → akce → výsledek → monitoring
Pokud je kterýkoli prvek tohoto řetězce špatně navržený, systém může učinit chybné rozhodnutí nebo — horší — jej automaticky vykonat.
Autonomie by neměla být vypínačem ON/OFF
Jednou z největších chyb v návrhu AI je přemýšlet: „Buď člověk dělá všechno, nebo AI dělá všechno.“
V praxi potřebujeme mnohem větší počet úrovní.
Můžeme si představit model úrovní autonomie:
Úroveň 0 - člověk vykonává všechno
AI nepodniká žádné akce. Může být využívána pouze jako informační nástroj.
Příklad: Programátor se ptá AI na způsob řešení problému.
AI odpoví.
Programátor sám analyzuje odpověď a implementuje řešení.
Úroveň 1 - AI analyzuje
Systém sbírá a zpracovává informace. Člověk činí rozhodnutí.
Příklad: AI analyzuje dokumentaci a připraví shrnutí.
Člověk sám vyhodnotí výsledek.
Úroveň 2 - AI doporučuje
Systém analyzuje situaci a navrhuje akci. Člověk schvaluje.
Příklad: AI detekuje podezřelou transakci a doporučí její další ověření.
Úroveň 3 - AI připravuje akci
AI nejen doporučí rozhodnutí, ale připraví všechny prvky potřebné k jeho provedení. Člověk schvaluje.
Příklad: Agent připraví odpověď pro klienta, aktualizaci CRM a návrh slevy.
Zaměstnanec vše schválí.
Úroveň 4 - AI jedná autonomně v určených hranicích
Systém může samostatně činit rozhodnutí a vykonávat akce. Ale pouze v rámci stanovených pravidel.
Příklad: Agent může sám posunout termín dodání o jeden den, pokud klient takovou možnost přijal.
Nemůže však změnit podmínky smlouvy.
Úroveň 5 - AI jedná autonomně
Systém samostatně analyzuje situaci, přijímá rozhodnutí a provádí akce. Člověk zůstává odpovědný za dohled nad celým systémem.
Taková úroveň autonomie by měla být používána velmi opatrně.
Ne proto, že AI nikdy nemůže fungovat samostatně. Ale proto, že čím větší autonomie, tím větší důsledky případné chyby.
Nejdůležitější zásada: autonomie musí být úměrná riziku
Nemá smysl vytvářet jedinou univerzální zásadu: „AI vždy musí mít souhlas člověka.“
To by mohlo zcela zničit přínosy automatizace.
Představme si systém obsluhující tisíce rutinních operací. Pokud každá z nich vyžaduje ruční schválení, člověk se stane úzkým hrdlem.
Na druhou stranu: „AI může dělat vše samostatně“
je také špatný nápad.
Proto by se rozhodnutí o úrovni autonomie mělo činit na základě rizika.
Můžeme analyzovat mimo jiné:
- potenciální škodu,
- náklady chyby,
- vratnost akce,
- dopad na člověka,
- finanční dopad,
- právní dopad,
- citlivost dat,
- možnost odhalení chyby,
- čas potřebný na reakci.
To vede k velmi praktickému pravidlu:
Čím větší riziko a čím obtížněji vratný dopad, tím větší podíl člověka by měl být v procesu.
Reversible vs Irreversible Actions
Jedním z velmi užitečných kritérií je rozdělení akcí na vratné a nevratné.
Vratné akce
Například:
- změna pořadí úkolů,
- vygenerování pracovní verze dokumentu,
- připravení návrhu odpovědi,
- vytvoření náhledu kampaně.
Pokud AI udělá chybu, člověk ji může snadno opravit.
V takových případech lze systému povolit větší autonomii.
Obtížně vratné akce
Například:
- provedení platby,
- smazání dat,
- podpis smlouvy,
- změna zásadních parametrů systému,
- odeslání právně významné informace,
- přijetí rozhodnutí ovlivňující lidská práva.
Zde by měla být úroveň kontroly výrazně vyšší.
Je to jednoduché, ale velmi efektivní návrhové pravidlo:
AI může mít větší volnost tam, kde je chyba snadno vrátitelná.
Human-in-the-Loop, Human-on-the-Loop a Human-in-Command
Je dobré rozlišit tři přístupy.
Human-in-the-Loop
Člověk se přímo účastní rozhodovacího procesu.
AI doporučuje.
Člověk schvaluje.
To je dobré řešení pro procesy s vyšším rizikem.
Human-on-the-Loop
AI funguje samostatně, ale člověk systém monitoruje a může zasáhnout.
Tento model je vhodný pro opakující se a dobře definované procesy.
Příklad: Systém automaticky optimalizuje pořadí úkolů.
Člověk neschvaluje každou změnu.
Monitoruje ale výsledky a může převzít kontrolu.
Human-in-Command
Člověk zůstává na strategické úrovni.
Nekontroluje každé jednotlivé rozhodnutí.
Nese však odpovědnost za:
- zásady fungování,
- rozsah autonomie,
- cíle systému,
- omezení,
- odpovědnost,
- možnost zastavení systému.
To je obzvlášť důležité u velkých autonomních systémů.
Human Override - člověk musí umět převzít kontrolu
Pokud systém může fungovat autonomně, člověk by měl mít možnost převzít kontrolu.
To je právě Human Override.
Mechanismus může vypadat různě.
Může to být:
- ruční schválení,
- zastavení procesu,
- zrušení akce,
- odvolání rozhodnutí,
- přepnutí systému do manuálního režimu,
- odejmutí agentovi přístupu k nástrojům.
Je však důležité, aby to nebyl mechanismus pouze teoretický.
Pokud člověk může „převzít kontrolu“, ale trvá mu to 48 hodin, zatímco agent provádí akce za několik sekund, máme problém.
Human Override by měl být: dostupný, rychlý a skutečně účinný.
Fail-Safe - co se děje, když si AI není jistá?
Dobrý návrh systému by neměl předpokládat, že AI bude vždy mít pravdu. Měl by předpokládat, že se někdy může mýlit.
Proto potřebujeme mechanismus Fail-Safe.
Pokud systém:
- nemá dostatečná data,
- má nízkou úroveň jistoty,
- zaznamená protichůdné informace,
- narazí na situaci mimo rozsah,
- nemůže vykonat akci v souladu s pravidly,
neměl by za každou cenu rozhodovat.
Měl by říct: „Nevím.“ — a předat případ člověku.
To může být jedna z nejdůležitějších vlastností vyspělého systému AI. Ne schopnost odpovědět na každou otázku. Ale schopnost rozpoznat, kdy by odpověď neměl poskytovat.
Confidence Score - ale opatrně
V AI systémech se často setkáváme s pojmem úrovně jistoty.
Systém může říct: „Moje doporučení má 95% confidence.“
Zní to skvěle. Ale musíme být opatrní.
Úroveň jistoty modelu není vždy totožná s pravděpodobností, že je odpověď skutečně správná. Model může být velmi přesvědčený a zároveň se mýlit.
Proto by měl být confidence score považován za jeden ze signálů, nikoli za absolutní pravdu.
Lze jej ale využít při navrhování procesu.
Například:
- vysoká jistota + nízké riziko = automatizace,
- střední jistota = doporučení pro člověka,
- nízká jistota = povinná eskalace.
To umožňuje vytvářet dynamický Human-in-the-Loop.
Ne každé rozhodnutí vyžaduje člověka. Ale každé rozhodnutí by mělo mít definovanou cestu eskalace.
Dynamický Human-in-the-Loop
To je velmi zajímavý směr návrhu AI systémů.
Místo pevného pravidla: „Každé rozhodnutí schvaluje člověk“
vytvoříme pravidlo: „Člověk se zapojí, když systém detekuje zvýšené riziko.“
Příklad:
Agent zákaznické podpory může sám odpovídat na standardní dotazy.
Pokud zákazník ptá na stav zásilky — agent odpoví.
Pokud zákazník chce změnit adresu — agent může provést operaci v souladu s pravidly.
Pokud zákazník požaduje velkou refundaci — systém předá případ člověku.
Pokud se objeví právní riziko — eskalace.
Pokud systém nerozumí záměru zákazníka — eskalace.
Tímto způsobem člověk nekontroluje vše. Kontroluje to, co skutečně vyžaduje lidské posouzení.
Agent by měl mít jen taková oprávnění, jaká opravdu potřebuje
To je jedno z nejdůležitějších bezpečnostních pravidel. Pokud agent má vykonávat určitou úlohu, měl by dostat pouze nezbytná oprávnění.
Ne: „dejme mu přístup k celému CRM, protože by se to mohlo hodit.“
Pouze: „agent potřebuje číst data klientů a možnost vytvoření požadavku.“
Tento přístup je v kyberbezpečnosti známý jako Least Privilege. Minimální oprávnění.
Pokud bude agent kompromitován nebo udělá chybu, rozsah potenciální škody je omezený.
To je obzvlášť důležité v agentových architekturách.
Agent, který může:
- číst data,
- psát data,
- odesílat zprávy,
- provádět platby,
- měnit konfiguraci systémů,
je potenciálně velmi nebezpečný.
Proto by každá možnost měla být považována za nástroj s určitým rizikem.
Tool Calling - agent by neměl mít neomezený přístup
Moderní AI agenti často používají nástroje.
Model může například volat:
- API,
- databázi,
- ERP systém,
- CRM,
- vyhledávač,
- platební systém.
To je obrovská moc. Ale rovněž velké riziko. Proto by volání nástrojů mělo být řízené.
Systém by měl vědět:
- kdo může daný nástroj volat,
- jaké argumenty jsou povoleny,
- jaké hodnoty jsou přijatelné,
- zda je potřeba souhlas člověka,
- jak je akce logována.
Agent může mít přístup k funkci: create_invoice
ale neměl by automaticky mít přístup k: delete_all_invoices
Zní to absurdně.
Ale právě proto je třeba navrhovat systémy s ohledem na ten nejhorší možný scénář.
Guardrails jako architektura bezpečnosti
Guardrails by měly fungovat na několika úrovních.
Guardrails týkající se dat
Jaké informace může agent číst?
Guardrails týkající se akcí
Jaké operace může provádět?
Finanční guardrails
Do jaké částky může jednat autonomně?
Časové guardrails
V jakých časech může vykonávat operace?
Guardrails týkající se uživatelů
Pro které klienty může vykonávat akce?
Guardrails týkající se rizika
Které akce vyžadují schválení?
Díky tomu agent nedostane prostě přístup k systému.
Dostane kontrolovaný rozsah možností.
AI agent jako digitální zaměstnanec?
To je populární metafora. Agent AI může být vnímán jako digitální pracovník. Ale existuje jeden zásadní rozdíl.
Zaměstnanec má:
- zkušenosti,
- kontext,
- intuici,
- vědomí odpovědnosti.
Agent má:
- model,
- data,
- nástroje,
- instrukce,
- omezení.
Proto bychom agenty neměli navrhovat jen stylem: „Řekneme mu, co má dělat, a uvidíme.“
Agent by měl mít jasně definované:
- cíl,
- rozsah činnosti,
- přístup k datům,
- přístup k nástrojům,
- úroveň autonomie,
- kritéria úspěchu,
- podmínky eskalace,
- podmínky zastavení.
Čím autonomnější systém, tím více se podobá operačnímu systému obchodního procesu. A tím více potřebuje architekturu.
Architektura bezpečného systému AI
Můžeme si představit systém složený z několika vrstev.
Vrstva 1 - data
Zdroje dat organizace.
ERP.
CRM.
CMS.
Databáze.
Dokumenty.
API.
Vrstva 2 - AI modely
Jazykové modely, prediktivní modely a další AI komponenty.
Vrstva 3 - orchestrace
Logika určující, co se děje v jakém pořadí.
Vrstva 4 - agent
Systém analyzuje situaci a plánuje akce.
Vrstva 5 - nástroje
Agent může používat konkrétní API a funkce.
Vrstva 6 - guardrails
Systém kontroluje, co agent může udělat.
Vrstva 7 - Human-in-the-Loop
V určitých případech rozhodnutí putuje k člověku.
Vrstva 8 - monitoring
Systém monitoruje chování a kvalitu rozhodnutí.
Vrstva 9 - audit trail
Všechny relevantní akce jsou zaznamenány.
Vrstva 10 - emergency controls
Existuje možnost zastavení systému nebo převzetí kontroly. To není jediná možná architektura.
Ale ukazuje důležitou zásadu: bezpečný systém AI není jen model.
Je to celý ekosystém kontrolních mechanizmů.
Jak zavádět Human-in-the-Loop v praxi?
Nejlépe začít s malým procesem.
Ne od: „Automatizujeme celou firmu.“
Ale: „Vyberme jeden proces, ve kterém může AI bezpečně pomoci.“
Následně:
Krok 1 - identifikujte rozhodnutí
Co přesně má AI dělat?
Krok 2 - vyhodnoťte riziko
Co se stane, když se systém pomýlí?
Krok 3 - určete úroveň autonomie
Má AI:
- analyzovat,
- doporučovat,
- připravovat akce,
- provádět akce?
Krok 4 - stanovte podmínky eskalace
Kdy musí člověk převzít kontrolu?
Krok 5 - navrhněte guardrails
Které akce jsou zakázány?
Krok 6 - omezte oprávnění
Které nástroje skutečně potřebuje?
Krok 7 - navrhněte monitoring
Jak odhalíme chyby?
Krok 8 - navrhněte Human Override
Jak člověk zastaví systém?
Krok 9 - otestujte nouzové scénáře
Co se stane, když:
- API nefunguje,
- data jsou chybné,
- model odpoví nesprávně,
- uživatel zadá zlovolné instrukce,
- agent provede nežádoucí akci?
Krok 10 - až poté zvyšujte autonomii
Nejdříve pozorování, později doporučení, následně omezená automatizace. Teprve nakonec větší autonomie.
To je mnohem bezpečnější cesta než zavádění plné autonomie od prvního dne.
Nejčastější chyba: automatizujeme proces, kterému nerozumíme
To není problém jen AI. Platí pro každou automatizaci.
Jestliže je proces špatně navržený, automatizace může způsobit, že bude fungovat rychleji.
Ale rychleji neznamená lépe.
Můžeme tak vytvořit: automatizaci chaosu.
AI jen zvýší škálu problému.
Proto před nasazením stojí za to položit si otázku: Je proces, který chceme automatizovat, opravdu dobře navržený?
Pokud ne, nejdříve upravme proces. Až potom přidejme AI.
Nejdůležitější zásada návrhu AI systémů
Nenavrhujme AI tak, aby se nikdy nemýlila. To je nerealistické.
Navrhujme ji tak, aby: chyba byla možná k odhalení, omezení a opravě.
To je zásadní rozdíl. Dospělý systém AI není bezchybný systém. Je to systém odolný vůči chybám.
Checklist bezpečného Human-in-the-Loop
Před nasazením systému stojí za to odpovědět na otázky:
☐ Víme, jaké rozhodnutí AI činí?
☐ Známe náklady případné chyby?
☐ Je rozhodnutí vratné?
☐ Určili jsme úroveň autonomie?
☐ Má AI jen nezbytná oprávnění?
☐ Existují guardrails?
☐ Ví člověk, kdy má zasáhnout?
☐ Dokáže systém předat záležitost člověku?
☐ Existuje Human Override?
☐ Existuje mechanismus nouzového zastavení?
☐ Jsou akce logovány?
☐ Monitorujeme kvalitu rozhodování?
☐ Dokážeme detekovat Model Drift?
☐ Víme, kdo za systém odpovídá?
☐ Máme postup pro reakci na incidenty?
☐ Otestovali jsme nouzové situace?
Pokud na většinu otázek odpovíme „ano“, jsme mnohem blíže k vyspělému nasazení AI.
Slovníček pojmů
Human-in-the-Loop
Model, ve kterém se člověk přímo podílí na rozhodovacím procesu a schvaluje určité akce AI.
Human-on-the-Loop
Model, ve kterém AI pracuje samostatně a člověk systém monitoruje a může zasáhnout.
Human-in-Command
Model, ve kterém člověk zůstává odpovědný za cíle, pravidla, rozsah autonomie a celkovou kontrolu systému.
Human Override
Mechanismus umožňující člověku převzít kontrolu nad AI nebo zrušit její akci.
Fail-Safe
Bezpečnostní mechanismus, kdy systém v případě nejistoty nebo selhání přejde do bezpečného stavu místo pokračování v rizikové akci.
Guardrails
Omezení určující rozsah akcí, které AI může podnikat.
Least Privilege
Zásada udělování systému pouze těch oprávnění, která jsou nezbytná k plnění jeho úkolu.
Tool Calling
Mechanismus umožňující modelu AI používat externí nástroje, API a systémy.
Kill Switch
Mechanismus umožňující rychlé zastavení systému.
Audit Trail
Záznam akcí umožňující pozdější rekonstrukci historie operací provedených systémem.
Model Drift
Zhoršení kvality modelu v důsledku změn v datech nebo prostředí.
Confidence Score
Ukazatel vyjadřující úroveň jistoty modelu ohledně vygenerovaného výsledku. Neměl by být automaticky ztotožňován s pravděpodobností správnosti odpovědi.
Shrnutí celé série
V průběhu čtyř částí naší série jsme prošli cestu od jednoduché otázky: „Měl by člověk kontrolovat AI?“
k mnohem složitější: „Jak navrhnout systém, ve kterém člověk a AI mohou bezpečně spolupracovat?“
Odpověď nezní: „Člověk by měl schvalovat všechno.“
Ani: „AI by měla fungovat zcela samostatně.“
Nejlepší řešení leží mezi těmito extrémy.
AI by měla mít tolik autonomie, kolik skutečně potřebuje. Člověk by měl být přítomen tam, kde jeho znalost, odpovědnost, zkušenost a posouzení situace mají největší hodnotu.
Systém by měl vědět, kdy jednat. Měl by vědět, kdy se zeptat. Měl by vědět, kdy se zastavit. A člověk by měl vždy vědět, jak získat kontrolu zpět.
To je právě vyzrálý přístup k Human-in-the-Loop.
Nejde o to, aby člověk stál nad AI a schvaloval každé jednotlivé rozhodnutí. Jde o vytvoření takové architektury, ve které autonomie je kontrolovaná, odpovědnost jasně přiřazená, riziko monitorované a člověk má reálnou možnost intervence.
Protože budoucnost AI nebude patřit pouze organizacím, které postaví nejautonomičtější systémy.
Může patřit těm, které se nejlépe naučí řídit hranici mezi autonomií stroje a odpovědností člověka.
A možná právě proto nebude nejdůležitější otázkou nadcházející éry AI agentů: „Kolik můžeme povolit AI udělat?“
Ale: „Kolik můžeme povolit AI udělat, přičemž si udržíme plnou kontrolu nad důsledky jejích akcí?“
Tato otázka se bude vracet při každém významném nasazení AI.
A čím autonomnější systémy budou, tím důležitější bude znát odpověď předtím, než agent provede první rozhodnutí.
