Vzory interakcie LLM a človeka pre prevádzku

Návrh švu medzi AI agentmi a ľudskými operátormi

Apríl 2026 · revidované júl 2026 · slovenské vydanie august 2026

Robert Barcik

LearningDoe s.r.o.

Kontakt: robert@barcik.training

O tejto príručke

„Nebojte sa, jednoducho tam dáme človeka do slučky.“ Ak pracujete kdekoľvek v blízkosti prevádzkovej AI, túto vetu ste počuli, pravdepodobne tento mesiac. Ponúka sa ako odpoveď na každý rizikový prípad použitia: klasifikáciu podľa AI Actu, bezpečnostnú revíziu, nepokoj predstavenstva. Táto príručka vychádza z nepríjemného, dobre zdokumentovaného faktu: vo svojej naivnej podobe táto veta opisuje jeden z najlepšie preskúmaných vzorov zlyhania v histórii automatizácie. Ľudia pod tlakom len opečiatkujú automatizované odporúčania, prestanú vnímať záplavy výstrah, ukotvia sa na prvom čísle, ktoré vidia, a zoberú na seba vinu, keď systém, ktorý sotva ovládali, zlyhá.

Otázka, na ktorú táto príručka odpovedá, teda nie je, či kombinovať AI agentov a ľudských operátorov; táto kombinácia už beží vo vašich frontoch tiketov, bezpečnostnej triáži a revíziách kódu. Otázka je, ako navrhnúť odovzdanie, ten šev, aby tím človeka a AI skutočne prekonal ktorúkoľvek zložku samostatne, namiesto toho, aby iba vyzeral pod dohľadom.

Materiál čerpá z desaťročí dôkazov z letectva, zdravotníctva, kybernetickej bezpečnosti a priemyselného riadenia: taxonómia automatizácie Sheridana a Verplanka, rámec situačného povedomia Endsleyovej, Kleinov model rozhodovania založený na rozpoznaní, výskum kalibrácie dôvery a moderná literatúra o tímovej spolupráci človeka a AI, plus zdokumentované produkčné nasadenia v GitHube, PagerDuty, Splunku, Dynatrace a ServiceNow. Poznámka k tým nasadeniam: prípadové štúdie dodávateľov sa v celom texte berú ako smerový dôkaz o prijatí, nie ako overené dáta o výkone, a každé výskumné tvrdenie v tejto revízii bolo skontrolované voči primárnemu zdroju.

Táto príručka má praktického spoločníka: Laboratórium človeka v slučke na demos.barcik.training, sedem krátkych simulácií v prehliadači, ktoré vám dovolia zažiť každý režim zlyhania na vlastnej koži, od úverovej priehradky banky cez policajný zoznam sledovaných osôb po sudcovský rozvrh. Kapitoly pri čítaní odkazujú na príslušnú simuláciu; nič sa neinštaluje, nič sa nekonfiguruje. (Simulácie sú v angličtine.)

Slovenské vydanie preložil Claude (Fable 5), ktorý sa podieľal aj na júlovej revízii originálu, 16. augusta 2026; prekladané významovo, nie slovo za slovom. Ustálené pojmy z literatúry ostávajú tam, kde je to zvykom, v angličtine s glosou. Pri pochybnostiach platí anglický originál.

Pre koho je táto príručka

• Inžinieri GenAI, ktorí stavajú prevádzkové AI systémy so schopnosťou používať nástroje (MCP, agentné frameworky, volanie funkcií) a potrebujú navrhnúť interakčnú vrstvu medzi svojimi agentmi a ľudskými operátormi
• Manažéri IT prevádzky, ktorí zavádzajú AI agentov do reakcie na incidenty, monitorovania alebo pracovných postupov service desku a hľadajú usmernenie k úrovniam autonómie založené na dôkazoch
• Produktoví manažéri, ktorí navrhujú pracovné postupy s podporou AI a musia vyvážiť efektivitu automatizácie s ľudským dohľadom a zodpovednosťou
• Profesionáli v bezpečnostnej prevádzke, ktorí nasadzujú nástroje AI na triáž a vyšetrovanie v prostrediach SOC, kde únava z výstrah a zmeškané detekcie majú skutočné dôsledky
• Ktokoľvek, kto povedal, alebo komu povedali, „jednoducho tam dáme človeka do slučky“ a chce vedieť, čo naozaj treba na to, aby to bola pravda

Ako čítať túto príručku

Kapitola 1 definuje návrhový šev a prečo rozhoduje o výsledkoch. Kapitola 2 predkladá argument proti naivnej slučke: dôkazy, že ľudský dohľad, tak ako sa zvyčajne prilepí, zlyháva, a čo namiesto toho regulátori skutočne vyžadujú. Kapitola 3 vám dá päť štrukturálnych vzorov interakcie a taxonómie za nimi a uzatvára sa tým, kam odbor smeruje (tímová spolupráca, nie úrovne). Kapitoly 4 až 6 pokrývajú ľudskú stranu: kognitívne skreslenia, ktoré podkopávajú odovzdania, prezentačné formáty, ktoré im čelia, a to, ako sa dôvera formuje, láme a kalibruje. Kapitola 7 navrhuje pre zlyhanie (zmierňovanie halucinácií, vypínače, ističe); kapitola 8 mení všetko na implementovateľné výstupy (šablóny promptov, rozhodovacie pracovné listy, kalibračné pracovné postupy); kapitola 9 pokrýva organizačnú governance, ktorá udržiava dobrý návrh pri živote. Kapitola 10 uzatvára tromi princípmi a pondelkovým ranným kontrolným zoznamom.

Môžete čítať postupne alebo skočiť na svoju aktuálnu návrhovú výzvu. Každá kapitola je samostatná, s krížovými odkazmi tam, kde pojmy stavajú na skoršom materiáli.

Obsah

1. Návrhový šev
2. Argument proti naivnej slučke
3. Päť štrukturálnych vzorov
4. Psychológia odovzdania
5. Prezentácia kontextu
6. Kalibrácia dôvery
7. Návrh pre zlyhanie
8. Implementácia vzorov
9. Organizačná governance
10. Záver

Kapitola 1: Návrhový šev

Každý AI agent, ktorý interaguje s ľudským operátorom, vytvára šev: hranicu, kde strojové myslenie odovzdáva ľudskému úsudku. Tento šev nie je ani chyba, ktorú treba odstrániť, ani formalita, ktorú treba minimalizovať: je to jediné najzávažnejšie návrhové rozhodnutie v akomkoľvek prevádzkovom systéme s podporou AI, a jeho pokazenie v zdokumentovaných prípadoch stálo miliardy dolárov a stovky životov.

Prečo na tom záleží práve teraz

Väčšinu histórie veľkých jazykových modelov bol vzor interakcie priamočiary: človek napísal prompt a model vrátil text. Človek bol vždy v slučke, lebo človek bol tou slučkou. Model nemohol konať vo svete; mohol iba navrhovať.

Toto obmedzenie sa rozpustilo. Model Context Protocol (MCP) dáva LLM štruktúrovaný prístup k externým nástrojom a zdrojom dát. Agent Development Kit (ADK) poskytuje frameworky na stavbu autonómnych agentov, ktorí vedia plánovať, vykonávať a iterovať. Volanie funkcií umožňuje LLM vyvolávať API, meniť databázy, reštartovať služby a nasadzovať kód. Z toho, čo bolo kedysi motorom na dopĺňanie textu, je dnes autonómny aktér schopný robiť závažné kroky v produkčných prostrediach.

Tento posun (od LLM ako nástrojov k LLM ako agentom) mení návrhový problém od základu. Keď LLM môže iba odporúčať, zlé odporúčanie nestojí nič, kým podľa neho človek nekoná. Keď LLM môže vykonávať, zlé rozhodnutie stojí všetko v okamihu, keď je urobené. Šev medzi človekom a strojom už nie je príjemný detail používateľského rozhrania. Je to riadiaci povrch.

Čísla naliehavosť potvrdzujú. GitHub Copilot dnes robí 1 z 5 revízií kódu, s vyše 60 miliónmi spracovaných revízií vo viac než 12 000 organizáciách. SRE Agent od PagerDuty vyšetruje produkčné incidenty a pripravuje nápravy na schválenie inžinierom, s autonómnym vykonávaním ako deklarovaným smerom. Agentné SOC od Splunku dáva AI agentov na bezpečnostné vyšetrovania v prvom slede. ServiceNow dodáva vyše 300 vopred postavených zručností a pracovných postupov AI agentov pre správu IT služieb. Sú to produkčné systémy, nie prototypy, a ich výstupy už tvarujú rozhodnutia, ktoré ovplyvňujú dostupnosť, bezpečnosť a tržby vo veľkom. (Poznámka k takýmto číslam: pochádzajú od dodávateľov. Táto brožúra berie prípadové štúdie dodávateľov ako smerový dôkaz o prijatí, nie ako overené dáta o výkone, a kapitola 2 vysvetľuje, prečo na tej disciplíne záleží.)

A napriek tomu dostáva návrh interakcie (šev) často menej pozornosti než architektúra modelu, promptovanie alebo integrácia nástrojov. To je chyba s dobre zdokumentovanými precedensmi.

Základné napätie

Jadrom výzvy interakcie človeka a AI v prevádzke je napätie, ktoré sa nedá vyriešiť, iba riadiť: priveľa autonómie odstráni ľudský dohľad, ktorý chytá chyby, kým priveľa dohľadu maří účel automatizácie a zavádza vlastné režimy zlyhania.

Toto napätie nie je nové. V roku 1983 publikovala Lisanne Bainbridgeová „Irónie automatizácie“, článok, ktorý sa ukázal takmer prorocky relevantný pre éru AI agentov. Bainbridgeová identifikovala paradox, ktorý sedí v srdci každého návrhového rozhodnutia o automatizácii:

Čím spoľahlivejším sa automatizovaný systém stáva, tým menej často musia ľudia zasahovať. Čím menej často ľudia zasahujú, tým menej praxe získajú. Čím menej praxe majú, tým menej sú schopní účinne zasiahnuť, keď automatizácia zlyhá. A čím spoľahlivejší je systém, tým sebauspokojenejším sa človek stáva, tým menej monitoruje a tým menej pravdepodobne odhalí zlyhanie včas na to, aby konal.

Čo sa stane, keď šev zlyhá

Dva prípady z letectva ilustrujú dva základné režimy zlyhania a oba sa priamo mapujú na návrh AI agentov.

Let Air France 447 (2009) ukázal zlyhanie vykonania odovzdania. Keď sa nad Atlantikom kvôli nespoľahlivým údajom o rýchlosti odpojil autopilot, piloti (ktorí strávili drvivú väčšinu letových hodín monitorovaním automatizácie) museli zrazu riadiť lietadlo ručne v zhoršených podmienkach. Ich zručnosti ručného pilotovania a schopnosti interpretovať prístroje zakrpateli nepoužívaním. Piloti aerodynamické prepadnutie nikdy nediagnostikovali. Zahynulo všetkých 228 ľudí na palube. Vyšetrovanie zistilo, že spoľahlivosť automatizácie erodovala práve tie zručnosti, ktoré boli potrebné, keď automatizácia zlyhala.

Boeing 737 MAX (2018 – 2019) ukázal zlyhanie návrhu odovzdania. Systém MCAS sa spoliehal na jediný snímač uhla nábehu, nebol spomenutý vo výcvikových materiáloch pilotov, a keď sa chybne aktivoval, postup na jeho potlačenie nebol ani zjavný, ani dobre nacvičený. Piloti bojovali s automatizáciou, ale nedokázali ju účinne prebiť. Tristoštyridsaťšesť ľudí zahynulo pri dvoch haváriách, lebo šev bol navrhnutý tak, že účinný ľudský zásah bol takmer nemožný.

Kľúčové rozlíšenie: AF447 bolo zlyhanie človeka na šve (automatizácia fungovala správne tým, že sa odpojila, ale ľudia nedokázali podať výkon). Boeing 737 MAX bolo zlyhanie samotného švu: automatizácia zabránila účinnému ľudskému dohľadu. Oba režimy zlyhania sú priamo relevantné pre návrh AI agentov: vašim operátorom môžu chýbať zručnosti na prebitie vášho agenta (AF447), alebo váš agent môže byť navrhnutý tak, že prebitie je nepraktické (737 MAX).

Situačné povedomie na šve

Model situačného povedomia Micy Endsleyovej (1995) vysvetľuje, prečo sú tieto zlyhania predvídateľné. Situačné povedomie funguje na troch úrovniach: vnímanie (vidieť dáta), porozumenie (chápať, čo znamenajú) a projekcia (predvídať, čo sa stane ďalej). Najzákernejší účinok automatizácie je na porozumenie: operátori vidia výstupy, ale strácajú kontextové porozumenie, ktoré tým výstupom dáva zmysel.

To je priamo relevantné pre AI agentov. LLM agent, ktorý autonómne vyšetrí incident a predloží zhrnutie, žiada operátora, aby vykonal projekciu a rozhodnutie bez toho, aby prešiel vnímaním a porozumením. Operátor musí rozhodnúť na základe zhrnutia, ktoré nezostavil, s kontextom, ktorý nezozbieral, o stave systému, ktorý nepozoroval. Bez zámernej návrhovej podpory operátor skĺzne buď k opečiatkovaniu (automatizačná zaujatosť), alebo k spochybňovaniu všetkého (nedôvera k automatizácii).

Definícia návrhového švu

Návrhový šev je úplná množina rozhodnutí, ktoré riadia, ako AI agent a ľudský operátor interagujú na svojej hranici:

• Čo agent robí autonómne a čo postúpi človeku
• Ako agent komunikuje svoje zistenia, odporúčania a úrovne istoty
• Aké informácie človek dostane na vyhodnotenie výstupu agenta
• Koľko času má človek na rozhodnutie
• Aké ovládacie prvky má človek na prebitie, úpravu alebo vrátenie krokov agenta
• Ako systém degraduje, keď agent zlyhá, človek sa pomýli alebo sa preruší komunikácia

Každé z týchto rozhodnutí tvaruje interakciu spôsobmi, ktoré sa časom úročia. Systém, ktorý predkladá odporúčania bez úrovní istoty, učí operátorov dôverovať alebo nedôverovať plošne. Systém, ktorý dovoľuje autonómne konanie bez mechanizmov vrátenia, vytvára nevratné dôsledky z vratných chýb. Systém, ktorý predkladá priveľa informácií na jedno rozhodnutie, vytvára kognitívne preťaženie, ktoré vedie k únave z výstrah a opečiatkovaniu.

Kľúčový postreh: Cieľom nie je šev odstrániť, ale navrhnúť ho tak, aby tím človeka a AI prekonal ktorúkoľvek zložku samostatne. To vyžaduje brať šev nie ako technické rozhranie, ale ako sociotechnický systém, v ktorom interaguje ľudské poznávanie, organizačný kontext a architektúra systému.

Kým šev navrhneme, jedna vec je nevyhnutná: rozobrať pohodlnú predstavu, že stačí ho iba obsadiť. Ďalšia kapitola sa púšťa do vety, ktorú každý AI projekt nakoniec počuje, „jednoducho tam dáme človeka do slučky“, a kapitola 3 potom predstaví päť štrukturálnych vzorov, ktoré definujú, ako si AI agenti a ľudskí operátori delia zodpovednosť v prevádzkových pracovných postupoch.

Kapitola 2: Argument proti naivnej slučke

Poznámka z terénu od autora. Učím inžinierstvo GenAI a je jedna veta, ktorú počujem takmer na každom firemnom workshope, zvyčajne asi po štyridsiatich minútach, keď sa dostaneme k rizikovým prípadom použitia. Niekto seniorný sa oprie a povie: „S týmto si nerobte starosti. Je to vysoké riziko, jasné, ale jednoducho tam dáme človeka do slučky.“ A miestnosť sa uvoľní. Otázka súladu je vybavená, architektonická revízia ide ďalej a nikto sa nespýta človeka, ktorý tým človekom naozaj bude, ako bude vyzerať jeho utorkové popoludnie. Táto kapitola existuje kvôli tej vete. Napísal som ju, aby ste nabudúce, keď ju budete počuť alebo hovoriť, presne vedeli, koľko práce sa za tými pár slovami skrýva.

„Jednoducho tam dáme človeka do slučky“ je najpohodlnejšia odpoveď v prevádzkovej AI. Znie obozretne, uspokojuje audítorov a na prvé prečítanie sa zdá byť tým, čo regulátori vyžadujú. Vo svojej naivnej podobe je to zároveň jeden z najlepšie zdokumentovaných vzorov zlyhania v celej literatúre o automatizácii. Táto kapitola predkladá ten argument s dôkazmi, kým zvyšok brožúry postaví alternatívu: slučku, ktorá je navrhnutá, nie iba vyhlásená.

Čo hovoria dôkazy o kombináciách človeka a AI

Začnite najpriamejšou otázkou: keď spárujete človeka s AI systémom, prekoná kombinácia svoje časti?

V priemere nie. Vaccaro, Almaatouq a Malone publikovali v roku 2024 v Nature Human Behaviour predregistrovanú metaanalýzu pokrývajúcu 106 experimentálnych štúdií a 370 veľkostí účinku. Kombinácie človeka a AI podali významne horší výkon než lepší z dvojice človek alebo AI samostatne. Synergia, kde tím porazí oboch svojich členov, bola výnimkou, nie pravidlom.

Detail, na ktorom pre prevádzku najviac záleží, je podmienka pochovaná v tom výsledku. Kombinácie priniesli zisky, keď človek sám prekonával AI samotnú: nadradený úsudok človeka, doplnený strojom, niečo pridal. Ale keď AI sama prekonávala človeka samotného, pridanie človeka výsledky zhoršilo. Zásahy človeka uberali hodnotu, prebíjali správne výstupy a mávali rukou nad nesprávnymi.

Teraz si všimnite, ktorý prípad je vaše nasadenie. Ak dávate AI systém do triáže tiketov, vyšetrovania výstrah alebo preverovania dokumentov práve preto, že v tej úlohe prekonáva vašich ľudí, potom je metaanalytické očakávanie pre „človeka v slučke“ ako naivný doplnok záporné. Konfigurácia, po ktorej všetci siahajú ako po bezpečnostnom opatrení, je štatisticky konfigurácia, v ktorej človek prispieva najmenej.

Nič z toho neargumentuje za odstránenie ľudí. Tá istá metaanalýza našla zisky pri úlohách tvorby obsahu a v usporiadaniach, kde deľba práce hrala na silné stránky každej strany. Argument je užší a užitočnejší: predvolená slučka, jeden človek schvaľujúci prúd výstupov AI, ktoré nevyprodukoval, o situáciách, ktoré nevyšetril, zlyháva, pokiaľ niečo v návrhu neurobí príspevok človeka skutočným. Kapitoly 3 až 6 sú o tom, čo to niečo je.

Dohľad ako politické divadlo

Druhý súbor dôkazov pochádza od ľudí, ktorí študujú požiadavky na dohľad po tom, čo sa stanú politikou.

Ben Green preskúmal 41 politík, ktoré nariaďujú ľudský dohľad nad vládnymi algoritmami, od rozhodnutí o dávkach po policajné nástroje. Jeho záver, publikovaný v roku 2022 v Computer Law & Security Review, má dve časti a obe by mali byť nepríjemné pre kohokoľvek, kto píše dokument o governance AI. Po prvé, dohľad zlyháva: desaťročia výskumu ľudských faktorov (dôkazy o automatizačnej zaujatosti a sebauspokojení, ktoré táto brožúra pokrýva v kapitole 4) ukazujú, že ľudia sú systematicky nevhodní na rolu, ktorú im tieto politiky prideľujú, monitorovať väčšinou správny systém a chytať jeho zriedkavé chyby. Po druhé, a horšie, požiadavka na dohľad nasadenie legitimizuje. Algoritmus sa dostane do vysoko rizikového kontextu, z ktorého by inak mohol byť vylúčený, lebo „každé rozhodnutie kontroluje človek“ je v zázname. Človek sa stáva dôvodom, prečo chybný systém smie bežať.

Greenova navrhovaná alternatíva je inštitucionálna: agentúry by mali pred nasadením s dôkazmi zdôvodniť, že ich ľudský dohľad naozaj funguje, namiesto toho, aby to tvrdili. Podržte si tú myšlienku; kalibračný pracovný postup v kapitole 8 a behaviorálne metriky v kapitole 6 sú presne ten druh dôkazov, o ktoré žiada, uplatnený na podnik.

Pre to, čo sa stane s človekom vnútri nepreskúmanej slučky, existuje meno. Madeleine Clare Elishová to nazvala morálna deformačná zóna: vo vysoko automatizovanom systéme sa právna a morálna zodpovednosť presúva na najbližšieho ľudského operátora, ktorý mal nad výsledkom obmedzenú skutočnú kontrolu, tak ako deformačná zóna auta pohltí náraz, aby ochránila to, čo je vnútri. Piloti lietadla riadeného takmer úplne automatizáciou, bezpečnostný vodič v autonómnom testovacom vozidle, rádiológ, ktorý „potvrdil“ čítanie modelu: keď systém zlyhá, vyšetrovanie nájde človeka, lebo človek sa dá nájsť. Dodávateľ ukáže na vyhlásenie, že výstup bol poradný. Organizácia ukáže na schvaľovací log s menom operátora.

Prečítajte si klientsku vetu znovu v tomto svetle. „Jednoducho tam dáme človeka do slučky“ často neznamená „pridáme bezpečnostný mechanizmus“. Prevádzkovo to znamená „rozhodli sme, kto ponesie vinu“. Ak človek nedokáže zmysluplne vyhodnotiť výstup AI (žiadny čas, žiadny kontext, žiadny kalibrovaný signál istoty, žiadna nacvičená zručnosť), potom slučka poskytuje divadlo zodpovednosti pre nasadenie a expozíciu voči zodpovednosti pre človeka. Nikto v architektonickej revízii to nezamýšľa. Naivná verzia to aj tak prináša.

Problém špecifický pre agentov

Všetko vyššie pochádza z klasickej literatúry o automatizácii, študovanej na pilotoch, klinikoch a operátoroch velínov. LLM agenti pridávajú zvrat, s ktorým sa klasici nemuseli vyrovnávať: slučka nie je jedno rozhodnutie, je to prúd.

Agent pracujúci na tikete, incidente alebo kódovej základni vyprodukuje za sedenie desiatky krokov, každý nominálne podliehajúci schváleniu. Ekonomika pozornosti je pri tomto tempe brutálna a rané dáta z terénu ukazujú presne ten posun, aký by ste predpovedali. Analýza skutočného používania agentov od Anthropicu (február 2026, čerpajúca zo sedení Claude Code) zistila, že noví používatelia schvaľujú kroky agenta krok za krokom, ale okolo 750 sedení skúsenosti už viac než 40 percent sedení beží v režime plného automatického schvaľovania, oproti zhruba 20 percentám u nováčikov. Dohľad migruje z kontroly krokov na kontrolu plánov a u skúsených používateľov sa veľká časť z neho jednoducho vypne. Microsoft Research dospel k doplňujúcemu záveru vo svojej práci o dohľade nad agentmi z roku 2026 (názov hovorí za všetko: „Overseeing Agents Without Constant Oversight“): neustála revízia každého kroku neprežije kontakt so skutočnými záťažami a praktickou otázkou sa stáva, ako navrhnúť prerušovaný dohľad, ktorý stále chytí to, na čom záleží.

Schvaľovacia výzva má, inými slovami, rovnakú krivku únavy ako klinický alarm (kapitola 4 vám dá čísla). Akýkoľvek návrh dohľadu, ktorý predpokladá, že človek pozorne skontroluje štyridsiaty siedmy krok dnešného tristého sedenia agenta, predpokladá človeka, ktorý neexistuje. To nerobí dohľad nad agentmi nemožným. Robí nemožnou naivnú verziu a zvyšuje hodnotu každej techniky v tejto brožúre, ktorá sústreďuje ľudskú pozornosť tam, kde mení výsledky: schvaľovanie odstupňované podľa rizika (kapitola 3), smerovanie podľa kalibrovanej istoty (kapitoly 6 a 8) a zadržiavanie zlyhaní, ktoré vôbec nezávisí od bdelosti (kapitola 7).

Regulačný motív, čítaný správne

Reflex za klientskou vetou je zvyčajne regulačný a v EÚ má konkrétnu adresu: článok 14 AI Actu, „Ľudský dohľad“. Oplatí sa prečítať, čo článok skutočne vyžaduje, lebo je oveľa náročnejší, než reflex naznačuje.

Článok 14 nehovorí „človek má byť v slučke“. Hovorí, že vysokorizikové AI systémy musia byť navrhnuté tak, aby fyzické osoby, ktoré nad nimi vykonávajú dohľad, mohli: pochopiť schopnosti a obmedzenia systému a monitorovať jeho prevádzku; byť si vedomé automatizačnej zaujatosti, presne týmito slovami; správne interpretovať výstup systému s ohľadom na dostupné interpretačné nástroje; rozhodnúť sa systém nepoužiť alebo jeho výstup ignorovať, prebiť či zvrátiť; a zasiahnuť do prevádzky systému alebo ju prerušiť tlačidlom stop či podobným postupom.

To nie je personálna požiadavka. To je návrhová špecifikácia švu a číta sa ako obsah tejto brožúry: transparentnosť schopností a záznamy o výkone (kapitola 6), protiopatrenia proti automatizačnej zaujatosti (kapitola 4), interpretovateľný výstup a kalibrovaná istota (kapitola 5), funkčné prebitie, ktoré sa netrestá (kapitoly 3 a 9), a skutočný mechanizmus zastavenia (kapitola 7). Nasadzujúci subjekt, ktorý najme kontrolóra a na systéme nezmení nič, článok 14 nesplnil; obsadil deformačnú zónu. Právna vedkyňa Melanie Finková hovorí ostrejšiu pointu: dohľad nie je zázračný liek a brať človeka ako záchrannú sieť, ktorá ospravedlňuje slabšie záruky inde, obracia logiku článku naruby. Systém musí byť postavený tak, aby dohľad mohol fungovať; človek nerobí nebezpečný systém bezpečným tým, že sa naň pozerá.

Poznámka z júla 2026 k načasovaniu. Vysokorizikové povinnosti AI Actu sa mali pôvodne uplatňovať od 2. augusta 2026. Zjednodušovací balík „Digitálny omnibus“, finalizovaný v júni 2026, ich odložil: prípady použitia z prílohy III (zoznam, ktorý zahŕňa úverové skórovanie, nábor a väčšinu prevádzkových scenárov v demách tejto brožúry) sa teraz uplatňujú od 2. decembra 2027 a vstavané systémy z prílohy I od augusta 2028. Podstata článku 14 je nezmenená. Ak vás odklad láka odložiť návrh dohľadu o rok, všimnite si, že každý režim zlyhania v tejto kapitole funguje bez ohľadu na dátumy vynucovania a dodatočné prerábanie švu je oveľa drahšie než jeho návrh. Ako vždy pri právnych otázkach: berte to so štipkou soli a potvrďte si dátumy a povinnosti so svojím právnym poradcom.

Čo táto kapitola nehovorí

Tri nesprávne čítania stojí za to uzavrieť.

Po prvé, toto nie je argument za plnú autonómiu. Tie isté dôkazy, ktoré usvedčujú naivnú slučku, usvedčujú automatizáciu bez dohľadu ešte silnejšie; katastrofy v kapitole 7 sú väčšinou systémy, ktoré sa nedali zastaviť. Skutočná voľba je medzi vyhlásenou slučkou a navrhnutou, nie medzi opečiatkovaním a žiadnym človekom.

Po druhé, toto nie je tvrdenie, že ľudský úsudok je bezcenný. Metaanalytické straty sa sústreďujú tam, kde človek nedostane žiadny základ pre úsudok: žiadny kontext, žiadna kalibrácia, žiadny čas, holý výstup a tlačidlo schváliť. Tam, kde návrh dá človeku skutočný materiál na prácu, kombinácia vyhráva. To je vlastnosť švu, nie druhu.

Po tretie, toto nie je rada v oblasti súladu proti ľuďom v slučke. Článok 14 vyžaduje ľudský dohľad nad vysokorizikovými systémami, a mal by. Argument je, že požiadavka pomenúva inžiniersky výsledok, dohľad, ktorý funguje, a zvyšok tejto brožúry je to inžinierstvo.

Kľúčové posolstvo: „Jednoducho tam dáme človeka do slučky“ je hypotéza a dôkazy hovoria proti jej naivnej podobe: kombinácie človeka a AI v priemere zaostávajú za lepším zo svojich členov a prehrávajú presne vtedy, keď je AI silnejším členom; mandáty dohľadu empiricky zlyhávajú a zároveň legitimizujú systémy, nad ktorými dohliadajú; človek v nenavrhnutej slučke funguje ako morálna deformačná zóna, ktorá pohlcuje vinu bez toho, aby vykonávala kontrolu; a agentné pracovné postupy pridávajú krivku únavy zo schvaľovania, ktorá revíziu každého kroku porazí do mesiacov. Článok 14 AI Actu EÚ, čítaný pozorne, už súhlasí: vyžaduje šev navrhnutý tak, aby dohľad mohol uspieť. Vyhlásiť slučku je začiatok práce, nie jej koniec.

Kapitola 3: Päť štrukturálnych vzorov

Nie všetky odovzdania medzi AI a človekom sú rovnaké. Vhodný vzor závisí od rizika kroku, dostupného času a odbornosti operátora. Bezpečnostný analytik triedaci tisíce výstrah denne potrebuje zásadne iný vzor interakcie než inžinier spoľahlivosti schvaľujúci prepnutie databázy na záložný server. Agent IT service desku riešiaci resety hesiel pracuje pod inými obmedzeniami než pracovník compliance kontrolujúci audítorské zistenia generované AI.

Táto kapitola definuje päť štrukturálnych vzorov, ktoré pokrývajú celé spektrum interakcie človeka a AI v prevádzke, mapuje ich na zavedené taxonómie automatizácie a poskytuje rozhodovací rámec na výber správneho vzoru pre daný prevádzkový kontext.

Základ Sheridana a Verplanka

Kým sa pozrieme na vzory, oplatí sa ich ukotviť v taxonómii, ktorá štruktúruje výskum automatizácie takmer päť desaťročí. V roku 1978 navrhli Thomas Sheridan a William Verplank 10-stupňovú škálu automatizácie, od plnej ľudskej kontroly po plnú strojovú autonómiu. Ich rámec ostáva najcitovanejším referenčným bodom pre návrh automatizácie a každý moderný rámec (vrátane tých od PagerDuty, Cloud Security Alliance a NIST) sa dá naň spätne namapovať.

Päť vzorov opísaných nižšie sa mapuje na zhluky v tejto škále, ale sú definované prevádzkovými charakteristikami, nie abstraktnými úrovňami automatizácie. Odpovedajú na otázku praktika: „Ako by mal môj AI agent interagovať s mojimi ľudskými operátormi pri tomto konkrétnom type práce?“

Vzor 1: Odporučiť a čakať

Úrovne Sheridana a Verplanka 4 – 5 | AI odporúča; človek rozhoduje a koná.

V tomto vzore AI agent analyzuje situáciu, zozbiera dôkazy a predloží ľudskému operátorovi jeden odporúčaný krok. Agent potom čaká. Žiadny krok sa nevykoná, kým človek odporúčanie výslovne neschváli, neupraví alebo nezamietne.

Toto je najbezpečnejší vzor a vhodný štandard pre každý krok, kde sú dôsledky chyby významné a nevratné.

SRE Agent od PagerDuty

SRE Agent od PagerDuty je príkladom tohto vzoru v produkčnej reakcii na incidenty. Keď sa spustí výstraha, agent automaticky zozbiera kontext: stiahne nedávnu históriu nasadení, dopytuje monitorovacie dashboardy, skontroluje korelované výstrahy naprieč službami a preskúma relevantné runbooky. Potom predloží službukonajúcemu inžinierovi syntetizované hodnotenie a odporúčaný krok, napríklad: „Vrátiť nasadenie v2.4.7 na v2.4.6. Dôkazy: miera chýb vzrástla o 340 % do 8 minút od nasadenia, korelované s týmto commitom, ktorý mení konfiguráciu združovania databázových spojení.“

Inžinier odporúčanie skontroluje, preskúma dôkazy a buď vrátenie schváli, alebo vyšetruje ďalej. Agent vrátenie nevykoná autonómne. Je to zámer: produkčné vrátenia môžu mať kaskádové účinky a kontextová znalosť inžiniera (povedomie o prebiehajúcej migrácii dát, vedomosť, že v2.4.6 mala vlastné problémy, rozpoznanie, že skok v miere chýb môže byť artefakt merania) je pre rozhodnutie nevyhnutná.

AI na sepsu v Johns Hopkins

V zdravotníctve nasadila nemocnica Johns Hopkins AI systém na včasnú detekciu sepsy, ktorý funguje presne vo vzore Odporučiť a čakať. Systém nepretržite monitoruje vitálne funkcie pacientov a laboratórne výsledky a strojovým učením identifikuje jemné skoré ukazovatele sepsy, ktoré ľudským klinikom často unikajú. Keď systém odhalí prípad s vysokou pravdepodobnosťou, upozorní klinický tím s odporúčaným liečebným protokolom.

Výsledky, publikované v roku 2022 v Nature Medicine, sú pozoruhodné s poctivou hviezdičkou: systém (TREWS) zachytil 82 % prípadov sepsy a úmrtnosť klesla o 18,7 % relatívne (3,3 percentuálneho bodu absolútne), ale špecificky u pacientov, ktorých výstrahu poskytovateľ potvrdil do troch hodín, v porovnaní s tými potvrdenými neskôr. Prínos žije v rýchlosti ľudskej odpovede na odporúčanie, čo je presne pointa tohto vzoru. Systém nepodáva liečbu. Neobjednáva laboratórne testy. Odporúča a klinický tím, so svojou znalosťou pacientovej histórie, komorbidít a súčasného liečebného plánu, rozhoduje.

Kľúčový postreh: Odporučiť a čakať nie je iba konzervatívny záložný plán: je to vysokovýkonný vzor, keď je analýza AI skutočne hodnotná, ale kontextová znalosť človeka je pre konečné rozhodnutie nevyhnutná. Zníženie úmrtnosti v Johns Hopkins sa dosiahlo výlučne lepšími odporúčaniami, podľa ktorých sa konalo rýchlejšie, nie autonómnym konaním.

Kedy použiť tento vzor

• Krok je nevratný alebo drahý na vrátenie (produkčné nasadenia, bezpečnostné blokácie, liečba pacientov)
• Ľudský operátor má doménovú odbornosť, ktorú AI nedokáže plne zachytiť (organizačný kontext, nedávne rozhovory, politické ohľady)
• Regulačné požiadavky alebo požiadavky súladu nariaďujú ľudské schválenie
• AI systém je novo nasadený a dôvera ešte nebola vybudovaná

Vzor 2: Triediť a eskalovať

Úrovne Sheridana a Verplanka 3 – 5 | AI filtruje, priorizuje a smeruje; človek rieši, čo ostane.

V tomto vzore AI agent spracúva veľkoobjemový prúd vstupov (výstrahy, tikety, požiadavky) a vykonáva prvotnú triáž. Klasifikuje položky podľa závažnosti a typu, filtruje šum, obohacuje položky o relevantný kontext a smeruje ich k vhodnému ľudskému operátorovi alebo tímu. Človek pracuje z kurátorovanej, priorizovanej fronty, nie zo surového prúdu.

Tento vzor je najcennejší v prostrediach, kde objem vstupov prevyšuje kapacitu ľudského spracovania.

Agentné SOC od Splunku

Rozsah problému v bezpečnostnej prevádzke je ohromujúci. Prieskum Vectra AI z roku 2026 medzi 1 450 praktikmi SOC uvádza priemer 2 992 bezpečnostných výstrah denne, z ktorých 63 % ostane úplne neriešených. (Počet výstrah medziročne v skutočnosti klesá, ako sa detekčné stacky konsolidujú; podiel neriešených sa veľmi nehýbe.) Prieskumy odvetvia uvádzajú čas ručného vyšetrovania zhruba 70 minút na skutočne preskúmanú výstrahu. Aritmetika je brutálna: aj s plným tímom väčšina výstrah nedostane vôbec žiadnu ľudskú pozornosť.

Agentné SOC od Splunku to rieši nasadením AI agentov, ktorí vykonávajú prvotné vyšetrovanie autonómne. Keď sa spustí výstraha, agent dopytuje relevantné zdroje dát (logy SIEM, telemetriu koncových bodov, kanály spravodajstva o hrozbách), koreluje výstrahu so známymi vzormi útokov, kontroluje ukazovatele falošne pozitívnych výsledkov a vyprodukuje štruktúrované zhrnutie vyšetrovania. Splunk sám tvrdí, že vyšetrovania, ktoré analytikom trvali väčšinu hodiny, sa teraz dokončia za sekundy; presný pomer berte ako marketing, ale stlačenie prvotnej triáže o rád je skutočné naprieč dodávateľmi.

Agent nerozhoduje, či výstraha predstavuje skutočnú hrozbu. Predloží analytikovi štruktúrovaný brífing (vrátane detailov výstrahy, korelovaných dôkazov, historického kontextu a predbežného hodnotenia) a analytik urobí rozhodnutie. Ale, čo je kľúčové, agent priradí aj skóre priority, čím zabezpečí, že najpravdepodobnejšie skutočné hrozby sa vynoria prvé. Analytici pracujú od vrchu priorizovanej fronty, nie z chronologického prúdu.

AI agenti od ServiceNow

ServiceNow posunul vzor Triediť a eskalovať do podnikového rozsahu so svojou platformou Now Assist, dodávajúc vyše 300 vopred postavených zručností AI agentov a agentných pracovných postupov. V správe IT služieb AI agenti automaticky klasifikujú prichádzajúce tikety, extrahujú kľúčové informácie, identifikujú relevantné články znalostnej bázy a smerujú tikety k vhodnej riešiteľskej skupine.

Pri priamočiarych požiadavkách (resety hesiel, poskytovanie prístupov, štandardné inštalácie softvéru) môže agent tiket vyriešiť autonómne (prechodom do vzoru Vykonať a hlásiť). Pri zložitých alebo nejednoznačných problémoch obohatí tiket o diagnostické informácie a eskaluje ho ľudskému agentovi, ktorý dostane vopred vyšetrený prípad, nie surovú sťažnosť.

Kedy použiť tento vzor

• Objem vstupov prevyšuje kapacitu ľudského spracovania (tisíce výstrah alebo tiketov denne)
• Väčšina vstupov je rutinná, falošne pozitívna alebo s nízkou prioritou
• Cena oneskorenej reakcie na položky s vysokou prioritou je významná
• Ľudská odbornosť je úzke hrdlo a musí sa sústrediť na najhodnotnejšiu prácu

Vzor 3: Vykonať a hlásiť

Úrovne Sheridana a Verplanka 7 – 8 | AI koná autonómne a človeka informuje potom.

V tomto vzore AI agent koná bez čakania na ľudské schválenie a potom hlási, čo urobil. Človek krok skontroluje dodatočne a zasiahne, len ak sa niečo pokazilo. Tento vzor je vhodný len vtedy, keď sú splnené tri podmienky: krok je dobre pochopený, krok je vratný a cena oneskorenia prevyšuje cenu občasných chýb.

Davis AI od Dynatrace

Motor Davis AI od Dynatrace funguje na úrovni Vykonať a hlásiť pre definovanú množinu nápravných krokov. Keď Davis odhalí výkonnostnú anomáliu (povedzme únik pamäte spôsobujúci zhoršenie času odozvy v mikroslužbe), môže automaticky spustiť nápravný krok, ako vypnutie problematického feature flagu, rozšírenie zdroja alebo reštart kontajnera.

Zisky v efektivite okolo Davisu sú kvantifikovateľné, s výhradou k pripísaniu: široko citované 56-percentné skrátenie priemerného času do vyriešenia pochádza zo štúdie IDC (zadanej Dynatrace) a opisuje vyšetrovanie s podporou AI s ľuďmi v slučke, nie samotnú autonómnu nápravu, ktorú Dynatrace predáva samostatne bez priloženého percenta. Čo autonómna úroveň overiteľne poskytuje: systém vykoná nápravu, zaloguje krok s plným kontextom (čo sa zistilo, aký krok sa urobil, aké boli očakávané a skutočné výsledky) a upozorní prevádzkový tím.

Kľúčové je, že Davis AI nenapráva automaticky všetko. Systém udržiava výslovný zoznam schválených autonómnych krokov, každý s definovanými postupmi vrátenia. Kroky mimo tohto zoznamu sa eskalujú do vzoru Odporučiť a čakať. Táto ohraničená autonómia (autonómne vykonávanie v definovaných mantineloch, eskalácia mimo nich) je to, čo robí vzor bezpečným na Sheridanovej úrovni 7 namiesto bezohľadného na úrovni 10.

Kedy použiť tento vzor

• Krok je dobre pochopený a bol už mnohokrát úspešne vykonaný
• Krok je vratný v prijateľnom časovom okne
• Cena oneskorenia (latencia ľudského schválenia) prevyšuje očakávanú cenu občasných chýb
• Je zavedené komplexné logovanie a mechanizmy vrátenia
• Rozsah autonómneho konania je výslovne ohraničený a pravidelne revidovaný

Kľúčové rozlíšenie: Vykonať a hlásiť nie je „nastav a zabudni“. Vyžaduje väčšiu inžiniersku investíciu než Odporučiť a čakať (nie menšiu), lebo systém musí zahŕňať monitorovanie vlastných krokov, schopnosť automatického vrátenia a jasné eskalačné cesty pre prípad, že autonómna náprava zlyhá alebo prinesie neočakávané výsledky.

Vzor 4: Navrhnúť a doladiť

Úroveň Sheridana a Verplanka 5 (upravená) | AI vyprodukuje kompletný výstup; človek ho skontroluje, upraví a schváli.

Tento vzor sa od Odporučiť a čakať líši jemným, ale dôležitým spôsobom. Namiesto odporúčania kroku AI vyprodukuje kompletný pracovný produkt (revíziu kódu, správu o incidente, aktualizáciu runbooku, zmenu konfigurácie), ktorý človek potom doladí. Rola človeka sa posúva z rozhodovateľa na editora.

Revízia kódu GitHub Copilot

Schopnosť GitHub Copilotu revidovať kód poskytuje najškálovanejší príklad tohto vzoru v produkcii. Začiatkom roka 2026 Copilot robí 1 z 5 revízií kódu na platforme, s vyše 60 miliónmi spracovaných revízií vo viac než 12 000 organizáciách.

Vzor interakcie je poučný. Keď sa odošle pull request, Copilot analyzuje zmeny, identifikuje potenciálne problémy (chyby, bezpečnostné zraniteľnosti, porušenia štýlu, výkonnostné obavy) a vygeneruje revízne komentáre s konkrétnymi návrhmi. Vývojár (alebo autor pull requestu) tieto komentáre skontroluje, prijme tie platné, zamietne tie neplatné a môže sa s Copilotom o konkrétnych návrhoch dohadovať tam a späť.

WEX, fintechová firma, hlásila približne 30-percentný nárast produktivity po širokom prijatí Copilotu (agentný režim, agent na programovanie a revízia kódu spolu), nie preto, že AI napísala viac kódu, ale významnou mierou preto, že revízny cyklus bol rýchlejší a konzistentnejší. AI riešila rutinné kontroly (štýl, bežné vzory chýb, medzery v dokumentácii), čím uvoľnila ľudských recenzentov na architektonické rozhodnutia, správnosť biznisovej logiky a hraničné prípady, ktoré vyžadujú doménovú odbornosť.

Kedy použiť tento vzor

• Výstupom je zložitý artefakt (kód, dokumentácia, konfigurácia), nie binárne rozhodnutie
• Kvalita závisí od iteratívneho dolaďovania, nie od jedinej správnej odpovede
• Odbornosť človeka je v hodnotení a editovaní, nie v generovaní od nuly
• Objem artefaktov prevyšuje to, čo ľudia dokážu vyprodukovať od nuly, ale nie to, čo dokážu skontrolovať

Vzor 5: Odstupňovaná autonómia

Dynamicky naprieč úrovňami Sheridana a Verplanka | Úroveň autonómie AI sa upravuje podľa kontextu, istoty a záznamu o výkone.

Toto je metavzor: namiesto pevného jediného vzoru interakcie systém dynamicky upravuje úroveň autonómie podľa konkrétnej situácie. AI agent môže fungovať vo Vykonať a hlásiť pri rutinných, dobre pochopených problémoch, prejsť do Odporučiť a čakať pri nových alebo vysoko rizikových situáciách a eskalovať na plnú ľudskú kontrolu, keď narazí na niečo mimo svojho tréningového rozdelenia.

Dve osi PagerDuty: úrovne incidentov a režimy vykonávania

SRE Agent od PagerDuty implementuje odstupňovanú autonómiu pozdĺž dvoch osí. Prvou je klasifikácia incidentov podľa toho, kto má viesť: rutinné, dobre pochopené incidenty, ktoré agent zvládne prevažne sám; zložité incidenty riešené spoločne, s agentom vyšetrujúcim a inžinierom riadiacim; a vysoko rizikové alebo nové incidenty, ktoré ostávajú vedené človekom s agentom v podpornej roli. Druhou osou je režim vykonávania: v režime Review agent navrhuje každý krok a čaká na schválenie, kým režim Autonomous (smer, ktorým PagerDuty stavia pre dobre ohraničené kroky) vykonáva a hlási.

Priradenie nie je statické, a to je tá poučná časť. Zamýšľaná trajektória je, že trieda krokov začína v režime Review a autonómiu si zaslúži, ako sa hromadí záznam o výkone a dôvera tímu v ňu je validovaná, zámerne, ľuďmi, ktorí systém vlastnia, nie počítadlom, ktoré tikne cez prah. Naopak, autonómia môže byť odobratá: počas zmrazenia zmien, po veľkom incidente alebo keď klesne dôvera v triedu odporúčaní, autonómna trieda krokov sa preradí späť do Review.

Úrovne autonómie CSA

Cloud Security Alliance publikovala v januári 2026 svoj rámec úrovní autonómie AI, definujúci šesť úrovní špecificky pre AI agentov v bezpečnostnej prevádzke:

Najužitočnejšia myšlienka, ktorú si z diskusie CSA odniesť, je dynamické preradenie nadol: princíp, že AI agent by mal automaticky znížiť svoju úroveň autonómie, keď narazí na neistotu, nové situácie alebo podmienky mimo svojho tréningového rozdelenia. (Článok CSA to nastoľuje ako otvorenú návrhovú otázku, nie ako pomenovanú zložku rámca; táto brožúra odporúča prijať to ako návrhové pravidlo.) Agent úrovne 4, ktorý narazí na predtým nevidený vzor útoku, by sa mal preradiť na úroveň 2, predložiť svoju analýzu a požiadať o ľudské usmernenie namiesto pokusu o autonómnu nápravu niečoho, čomu nerozumie.

Kľúčový postreh: Odstupňovaná autonómia nie je o dosiahnutí najvyššej možnej úrovne autonómie, ale o dosiahnutí tej správnej pre každé konkrétne rozhodnutie v každom konkrétnom okamihu. Najlepšie systémy nie sú tie najautonómnejšie; sú to tie, ktoré vedia, kedy požiadať o pomoc.

Rámec výberu vzoru

Výber správneho vzoru vyžaduje vyhodnotiť štyri dimenzie prevádzkového kontextu:

Referenčné rámce

Päť vzorov opísaných v tejto kapitole čerpá z niekoľkých zavedených rámcov a je s nimi kompatibilných; praktici by o nich mali vedieť:

Parasuraman, Sheridan a Wickens (2000)

Štvorstupňový model rozširuje pôvodnú škálu Sheridana a Verplanka tým, že uznáva, že automatizáciu možno nezávisle uplatniť na štyri stupne ľudského spracovania informácií: získavanie informácií, analýza informácií, výber rozhodnutia a implementácia kroku. Systém môže byť vysoko automatizovaný v získavaní informácií (automatický zber logov a metrík) a pritom ostať plne manuálny vo výbere rozhodnutia (človek rozhoduje, čo robiť). Tento rozklad je nevyhnutný na návrh jemných vzorov interakcie, ktoré automatizujú správne stupne zo správnych dôvodov.

Rámec riadenia rizík AI od NIST

NIST AI RMF poskytuje štruktúrovaný prístup k identifikácii a zmierňovaniu rizík v AI systémoch, organizovaný okolo štyroch funkcií: Govern, Map, Measure a Manage. Nepredpisuje konkrétne vzory interakcie, ale poskytuje metodiku hodnotenia rizík, ktorá by mala výber vzoru informovať.

Usmernenia Microsoft Human-AI Experience (HAX)

18 usmernení HAX od Microsoftu pokrýva celý životný cyklus interakcie človeka a AI, od prvotnej kalibrácie („Ujasnite, ako dobre systém dokáže to, čo dokáže“) cez riešenie chýb („Podporte efektívnu opravu“) po dlhodobú dôveru („Povzbudzujte granulárnu spätnú väzbu“). Sú užitočné najmä pre vrstvu používateľského rozhrania návrhu švu.

Google PAIR (People + AI Research)

Príručka PAIR od Googlu poskytuje návrhové usmernenie organizované okolo konceptu návrhu „AI na prvom mieste“: vychádzať zo schopností a obmedzení AI, nie z tradičného pracovného postupu používateľského rozhrania. Jej dôraz na mentálne modely (pomôcť používateľom pochopiť, čo AI dokáže a čo nie) sa priamo zhoduje s obavami o situačné povedomie z kapitoly 1.

Výber východiskového bodu

Pre organizácie, ktoré začínajú nasadzovať AI agentov v prevádzke, dve praktické odporúčania:

Začnite s Odporučiť a čakať. Je to najbezpečnejší vzor, buduje dáta potrebné na vyhodnotenie výkonu AI a zakladá základ dôvery potrebný pre vyššie úrovne autonómie. Organizácie, ktoré preskočia rovno k Vykonať a hlásiť bez toho, aby najprv validovali odporúčania AI v režime Odporučiť a čakať, podstupujú zbytočné riziko.

Navrhujte pre odstupňovanú autonómiu od začiatku. Aj keď je vaše prvotné nasadenie čisto Odporučiť a čakať, navrhnite architektúru systému tak, aby sa úroveň autonómie dala upraviť pre každý typ kroku bez prestavby. Definujte kritériá povýšenia a degradácie. Inštrumentujte systém tak, aby sledoval miery prijatia odporúčaní, vzory prebíjania a kvalitu výsledkov. Dáta, ktoré zozbierate počas Odporučiť a čakať, sú základom každého ďalšieho rozhodnutia o autonómii.

Od úrovní k spoluhráčom

Poctivá poznámka o lešení, na ktorom je táto kapitola postavená. Škála Sheridana a Verplanka a jej potomkovia berú návrh automatizácie ako problém prideľovania: vypíšte funkcie, rozhodnite, ktoré dostane stroj. Toto rámcovanie má takmer päťdesiat rokov a výskumníci, ktorí strávili kariéry štúdiom automatizovaných systémov v teréne, strávili posledných dvadsať z tých rokov argumentovaním proti nemu.

Dekker a Woods to v roku 2002 povedali bez obalu („MABA-MABA or Abracadabra?“): automatizácia nenahrádza ľudskú prácu strojovou v pevných množstvách. Premieňa prácu človeka na niečo nové, zvyčajne koordináciu a riešenie výnimiek, a zaujímavé návrhové otázky žijú v tej premene, nie v tabuľke prideľovania. Klein, Woods, Bradshaw, Hoffman a Feltovich nasledovali v roku 2004 s desiatimi výzvami, ako urobiť z automatizácie „tímového hráča“: dokážu stroj a človek udržať spoločnú pôdu o tom, čo sa deje? Sú stav a zámer stroja pozorovateľné? Dá sa usmerňovať uprostred úlohy? Dokáže vyjednávať o cieľoch, nielen ich vykonávať? Správa Národných akadémií z roku 2022 o tímovej spolupráci človeka a AI posun konsolidovala: výskumná špička berie človeka a AI ako tím, ktorý treba navrhnúť, nie ako škálu, ktorú treba nastaviť.

Prečo teda táto brožúra stále učí úrovne? Lebo úrovne sú správny vstupný nástroj: vynucujú prvý nevyhnutný rozhovor (čo smie tento systém robiť bez človeka?) a čisto sa mapujú na riziko, vratnosť a reguláciu. Ale všimnite si, že najlepší materiál v nasledujúcich kapitolách je už v prestrojení materiálom o tímovej spolupráci. SBAR je protokol spoločnej pôdy. Komunikácia istoty je vzájomná predvídateľnosť. Vypínač je usmerniteľnosť v najhrubšej podobe. Tam, kde vám vzor v tejto kapitole pripadá pre váš systém príliš statický (agent, ktorý plánuje, koná a preplánúva, nesedí nehybne na jednej úrovni), je optika tímovej spolupráce cestou k upgradu: nepýtajte sa „na akej úrovni je tento agent“, ale „čo tento agent potrebuje povedať môjmu operátorovi a čo môj operátor potrebuje vedieť s ním urobiť, aby tí dvaja ostali skoordinovaní?“

Štrukturálne vzory definujú, čo robí systém. Ďalšia kapitola skúma, čo robí človek (a čo je dôležitejšie, čo človek zlyháva urobiť), keď s týmito vzormi interaguje.

Kapitola 4: Psychológia odovzdania

Najnebezpečnejším predpokladom v prevádzke s podporou AI je, že ľudia sa budú pri interakcii s automatizovanými systémami správať racionálne. Nebudú. Nie preto, že by operátori boli nedbanliví alebo nekompetentní, ale preto, že ľudská kognitívna architektúra, ktorá nám tisícročia dobre slúžila, je systematicky nezladená s nárokmi na monitorovanie a prebíjanie automatizovaných systémov. Pochopiť tieto nezladenia nie je voliteľné; je to predpoklad návrhu vzorov interakcie, ktoré naozaj fungujú.

Táto kapitola pokrýva päť kognitívnych javov, ktoré priamo ovplyvňujú kvalitu ľudských rozhodnutí na šve medzi AI a človekom. Každý je rozsiahlo zdokumentovaný v recenzovanom výskume. Každý priniesol zlyhania v skutočnom svete s merateľnými dôsledkami. A každý má návrhové dôsledky, ktoré, ak sa ignorujú, podkopú aj tie najstarostlivejšie navrhnuté štrukturálne vzory z kapitoly 3.

Automatizačná zaujatosť

Automatizačná zaujatosť je sklon ľudí uprednostňovať návrhy automatizovaných systémov pred protichodnými informáciami z iných zdrojov vrátane vlastných pozorovaní. Nie je to lenivosť, ale dobre zdokumentovaná kognitívna skratka: ľudský mozog berie automatizovaný systém ako autoritu a podľa toho upraví svoje spracovanie.

Dôkazy

Prelomovou štúdiou je Skitka, Mosier a Burdick (1999), ktorá testovala pilotov aj nepilotov v simulovanom letovom prostredí, kde automatizovaný monitorovací systém občas poskytol nesprávne odporúčania.

Výsledky boli neúprosné:

• Chyby konania (vykonanie nesprávneho kroku odporúčaného automatizáciou): 100 % účastníkov sa dopustilo aspoň jednej chyby konania. Každý jeden účastník vrátane skúsených pilotov sa aspoň raz riadil odporúčaním automatizácie, keď bolo preukázateľne nesprávne.
• Chyby opomenutia (nevšimnutie si problémov, ktoré automatizácia prehliadla): 55 % účastníkov prehliadlo udalosti, ktoré automatizácia neoznačila, aj keď boli na ich prístrojoch jasne viditeľné.

Azda najznepokojivejšie: prítomnosť druhého člena posádky (štandardné zmiernenie ľudskej chyby v letectve) chyby z automatizačnej zaujatosti neznížila (Mosierová a kolegovia spustili tímovú verziu štúdie v roku 1998; miery chýb v dvojčlenných posádkach boli štatisticky nerozlíšiteľné od samostatných operátorov). Prehľad Parasuramana a Manzeya (2010) potvrdil vzor naprieč viacerými doménami a podkladový paradox spoľahlivosti bol zmeraný priamo: v experimentoch Baileyho a Scerba zvýšenie spoľahlivosti automatizácie z 87 % na 98 % posunulo prehliadnutia zlyhaní operátormi zo zhruba tretiny udalostí na takmer polovicu. Čím dôveryhodnejší je záznam automatizácie, tým menej ju človek monitoruje.

Dôsledky v skutočnom svete

Prasknutie ropovodu Enbridge (2010) ukázalo automatizačnú zaujatosť v prevádzkovom rozsahu. Alarmy SCADA indikovali pokles tlaku konzistentný s prasknutím. Operátori velína, kalibrovaní rokmi falošných poplachov, varovania 17 hodín odmietali, dvakrát ropovod reštartovali a napumpovali do prostredia ďalšiu ropu: do povodia rieky Kalamazoo sa dostalo asi 3,2 milióna litrov (20 082 barelov podľa NTSB). Vyčistenie presiahlo 1 miliardu dolárov.

Škandál Horizon britskej pošty ho ukázal v inštitucionálnom rozsahu. IT systém Horizon obsahoval chyby, ktoré vytvárali fantómové finančné manká. Napriek stovkám vedúcich pobočiek hlásiacich, že čísla systému nesedia so skutočnosťou, pošta systematicky dôverovala počítaču pred ľuďmi, čo viedlo k 736 nezákonným trestným stíhaniam počas 16 rokov.

Kľúčový postreh: Automatizačná zaujatosť nie je chyba charakteru, ale predvídateľná reakcia na zle navrhnutú interakciu. Keď má systém pravdu v 99 % prípadov, racionálna bayesovská odpoveď je dôverovať mu, a tá istá racionálna odpoveď spôsobí, že operátor prehliadne to 1 % prípadov, kde je dôvera nemiestna. Počítať s tým musí návrh, nie operátor.

Návrhové dôsledky

Kognitívne vynucovacie funkcie (prvky rozhrania, ktoré vyžadujú, aby sa operátor aktívne zapojil, kým prijme odporúčanie AI) sú primárnym protiopatrením. Buçinca, Malaya a Gajos (Harvard, publikované na CSCW 2021) ukázali, že požiadavka, aby sa ľudia zaviazali k vlastnému hodnoteniu skôr, než uvidia odporúčanie AI, významne znížila nadmerné spoliehanie sa na nesprávne rady AI. Kompromis: účastníkom sa tieto návrhy páčili najmenej zo všetkého testovaného, čo vytvára priamy konflikt medzi bezpečnosťou a použiteľnosťou, ktorým sa návrhári musia výslovne prepracovať.

Únava z výstrah

Únava z výstrah je postupné znecitlivenie operátorov voči výstrahám v dôsledku nadmerného objemu, vysokej miery falošne pozitívnych výsledkov alebo oboch. Je to doplnok automatizačnej zaujatosti: namiesto dôvery v nesprávne odporúčanie operátor ignoruje všetky odporúčania, lebo pomer signálu k šumu sa zrútil.

Rozsah problému

Čísla sú konzistentné naprieč odvetviami:

• Zdravotníctvo: 72 – 99 % klinických alarmov je falošných (AHRQ, 2020). Miery prebitia liekových výstrah sa naprieč štúdiami pohybujú medzi 49 % a 96 %, pričom výstrahy na liekové interakcie sa prebíjajú asi v 90 % prípadov. Sentinel Event Alert Spoločnej komisie o bezpečnosti alarmov (2013) spojil 98 udalostí súvisiacich s alarmami vrátane 80 úmrtí s únavou z alarmov počas štvorročného okna.
• Bezpečnostná prevádzka: Priemerné SOC dostáva 2 992 bezpečnostných výstrah denne, z ktorých 63 % ostane úplne neriešených. Sofistikovaní útočníci to zneužívajú cez „búrky výstrah“: generovanie veľkých objemov výstrah s nízkou prioritou na zamaskovanie skutočných prienikov.
• IT prevádzka: Podobné vzory v monitorovaní infraštruktúry, kde hlučné konfigurácie výstrah generujú stovky alebo tisíce výstrah denne, väčšinu prechodných alebo duplicitných.

Náprava založená na dôkazoch

Únava z výstrah nie je neriešiteľná. Boston Medical Center prepracovalo svoj systém klinických alarmov úpravami prahov, potlačením stavov, na ktoré netreba konať, a odstupňovaným smerovaním upozornení. Objem alarmov klesol z 87 823 týždenne na 9 967: 89-percentné zníženie bez akéhokoľvek nárastu nežiaducich výsledkov u pacientov.

Poučenie: hodnota systému výstrah nie je úmerná jeho citlivosti. Systém, ktorý generuje 3 000 výstrah denne a zachytí 95 % skutočných incidentov, je menej užitočný než ten, ktorý generuje 300 výstrah a zachytí 90 %, lebo prvý systém učí operátorov výstrahy ignorovať.

Návrhové dôsledky

Pre AI agentov fungujúcich vo vzore Triediť a eskalovať je únava z výstrah primárnym režimom zlyhania. Protiopatrenia:

• Agresívna deduplikácia a korelácia: Zoskupujte súvisiace výstrahy do incidentov.
• Filtrovanie podľa istoty: Potlačte výstrahy pod prahom istoty a prijmite občasné prehliadnutia, aby ste zachovali pozornosť operátora.
• Adaptívne prahy: Upravujte podľa kontextu (denná doba, nedávne zmeny, aktuálna záťaž incidentmi).
• Rozpočty výstrah: Zastropujte celkové denné eskalácie a prinúťte systém priorizovať.

Efekt ukotvenia

Ukotvenie je kognitívne skreslenie identifikované Tverskym a Kahnemanom (1974), pri ktorom počiatočná informácia neúmerne ovplyvňuje následné úsudky, aj keď je kotva ľubovoľná alebo irelevantná. V interakcii AI a človeka slúži prvotné odporúčanie AI ako silná kotva.

Štúdia 775 manažérov z roku 2025 potvrdila, že efekty ukotvenia pretrvávajú aj u skúsených profesionálov v ich oblasti odbornosti a aj keď boli účastníci pred úsudkom výslovne varovaní pred skreslením ukotvenia. Skúsenosť a povedomie ukotvenie znižujú, ale neodstraňujú.

Návrhový dôsledok je priamy: keď AI agent predloží odporúčanie ako prvé, následné vyšetrovanie operátora je tvarované týmto rámcovaním. Skôr bude hľadať potvrdzujúce dôkazy a menej pravdepodobne bude sledovať alternatívne hypotézy.

Návrhové dôsledky

• Zvážte opak: Výslovne vyzvite operátorov, aby zvážili alternatívne vysvetlenia, kým prijmú odporúčanie AI.
• Dáta pred odporúčaním: Predložte surové dáta a kontext skôr, než odhalíte odporúčanie AI, čím dáte operátorovi príležitosť utvoriť si nezávislé hodnotenie. Drahšie na čase operátora, ale významne znižuje ukotvenie.

Posun k sebauspokojeniu

Posun k sebauspokojeniu je postupná erózia bdelosti, ku ktorej dochádza, keď automatizovaný systém dlhší čas spoľahlivo funguje. Na rozdiel od automatizačnej zaujatosti (ktorá pôsobí pri jednotlivých rozhodnutiach) pôsobí posun k sebauspokojeniu na úrovni trvalého monitorovacieho správania a vytvára rozširujúcu sa medzeru medzi poskytovaným dohľadom a predpokladaným dohľadom.

M/V Royal Majesty (1995)

Výletná loď M/V Royal Majesty najazdila na plytčinu pri Nantuckete s 1 509 ľuďmi na palube, lebo kábel antény GPS lode sa odpojil, čo spôsobilo, že GPS prešiel na výpočet polohy odhadom. Systém zobrazoval varovný indikátor. Tím na mostíku si ho nevšimol. Loď 34 hodín plávala po čoraz odchýlenejšom kurze a odchýlila sa 17 námorných míľ od trasy. Viaceré nezávislé ukazovatele (radar, meranie hĺbky, vizuálne pozorovania) protirečili polohe podľa GPS, ale posádka prestala krížovo kontrolovať.

Úzko súvisí degradácia zručností: FAA zdokumentovala, že 60 % leteckých nehôd zahŕňajúcich chybu pilota obsahovalo nedostatok zručnosti v ručnom pilotovaní: zručnosti, ktoré zakrpateli, lebo lietanie riešil autopilot. V IT prevádzke sa to prejavuje, keď AI agenti dlhší čas riešia vyšetrovanie a nápravu a operátori strácajú diagnostické zručnosti, ktoré eskalácia predpokladá, že majú.

Model úpadku konania podľa CIGI

Centre for International Governance Innovation opisuje štvorstupňový organizačný vzor: Experimentovanie (AI dopĺňa ľudskú prácu) → Integrácia (AI sa stáva štandardom, nezávislá analýza klesá) → Spoliehanie (AI je primárny vstup, zručnosti krpatejú, noví ľudia sú školení pracovať s AI, nie bez nej) → Závislosť (organizácia nedokáže fungovať bez AI, žiadny záložný plán).

Kľúčové rozlíšenie: Posun k sebauspokojeniu nie je o jednotlivých operátoroch robiacich zlé rozhodnutia, ale o organizačných systémoch, ktoré postupne strácajú schopnosť nezávislého úsudku. Čeliť mu vyžaduje organizačné zásahy: pravidelnú povinnú manuálnu prevádzku, kontrolné tikety so známymi výsledkami, sledovanie mier schválenia bez revízie a udržiavanie zručností pomocou simulácií.

Poznámka z terénu od autora. Tieto javy púšťam na svojich workshopoch ako živú simuláciu (cvičenie nakoniec vyrástlo do hry The Operator’s Dilemma, na ktorú táto kapitola stále odkazuje). Okamih, keď som prestal potrebovať slajdy, nastal, keď bezpečnostný inžinier, hlboko v časovanom kole triáže, schválil odporúčanie, ktoré protirečilo dátam na jeho vlastnej obrazovke, zdvihol zrak a povedal: „Vedel som, že niečo nesedí, ale bežal časovač.“ Nikto sa nezasmial. Polovica miestnosti urobila to isté o pár incidentov skôr. O automatizačnej zaujatosti môžete prednášať hodinu a ľudia zdvorilo prikyvujú. Deväťdesiat sekúnd odpočtu ich obráti.

Zhrnutie

Týchto päť javov (automatizačná zaujatosť, únava z výstrah, ukotvenie, posun k sebauspokojeniu a degradácia zručností) nie je nezávislých. Interagujú a navzájom sa posilňujú:

• Únava z výstrah zvyšuje automatizačnú zaujatosť (preťažení operátori prijímajú odporúčania AI bez skúmania).
• Posun k sebauspokojeniu zrýchľuje degradáciu zručností (operátori, ktorí prestanú pozorne monitorovať, prestanú aj cvičiť zručnosti potrebné na účinné monitorovanie).
• Ukotvenie posilňuje automatizačnú zaujatosť (odporúčanie AI tvaruje myslenie a sťažuje nezávislé hodnotenie).
• Rozptýlenie zodpovednosti medzi človekom a AI umožňuje posun k sebauspokojeniu: Bleher a Braun (2022) opisujú výslednú medzeru v zodpovednosti: operátor môže ukázať na to, že sa riadil systémom, kým dodávateľ môže ukázať na to, že konečné rozhodnutie urobil človek. Keď sa nikto necíti individuálne zodpovedný, je menej motivácie udržiavať bdelosť.

Štrukturálne vzory z kapitoly 3 poskytujú kostru účinnej interakcie človeka a AI. Kognitívne javy v tejto kapitole určujú, či táto kostra podopiera funkčný systém alebo prázdny. Vzor Odporučiť a čakať, ktorý predkladá svoje odporúčania spôsobom, ktorý operátora ukotví a neposkytne žiadnu vynucovaciu funkciu pre nezávislé hodnotenie, je v praxi vzor Vykonať a hlásiť s krokmi navyše.

Ďalšia kapitola skúma, ako prezentovať informácie na šve: konkrétne komunikačné formáty a stratégie zverejňovania, ktoré podporujú dobré ľudské rozhodovanie tvárou v tvár týmto kognitívnym výzvam.

Kapitola 5: Prezentácia kontextu

To, ako prezentujete informácie, určuje, čo operátor vidí. A to, čo operátor vidí, určuje, čo rozhodne. Nie je to metafora, ale merateľný, reprodukovateľný jav: tie isté dáta o incidente, prezentované v rôznych formátoch, vedú u tých istých operátorov k rôznym rozhodnutiam so štatisticky významnou konzistenciou.

Kognitívne výzvy opísané v kapitole 4 (automatizačná zaujatosť, ukotvenie, únava z výstrah) sú vlastnosťami interakcie medzi ľudským poznávaním a návrhom informácií, nie pevnými črtami mysle. Dobre navrhnutý prezentačný formát môže ukotvenie znížiť. Zle navrhnutý ho môže zosilniť. Formát je nosným prvkom architektúry systému, nie kozmetickou vrstvou nanesenou po dokončení inžinierstva.

Táto kapitola predstavuje štyri rámce prezentácie kontextu na šve medzi AI a človekom založené na dôkazoch, s konkrétnym usmernením, ako každý uplatniť v prevádzkových AI systémoch.

Rámec SBAR

SBAR (Situation, Background, Assessment, Recommendation: situácia, pozadie, hodnotenie, odporúčanie) je štruktúrovaný komunikačný rámec široko pripisovaný námornej komunikačnej praxi, hoci zdokumentovaná história začína v Kaiser Permanente, ktorého tím pre bezpečnosť pacientov (Leonard, Graham a Bonacum) ho okolo roku 2002 formalizoval pre zdravotníctvo. (Príbeh o pôvode „vyvinuté na jadrových ponorkách“ sa opakuje všade vrátane nemocničných školiacich materiálov, ale žiadny primárny zdroj z námorníctva sa preň nikdy neobjavil; príhodná pripomienka, v kapitole o prezentácii dôkazov, kontrolovať reťazec dôkazov.) Z Kaiseru sa rozšíril do komunikácie pri klinických odovzdaniach v tisíckach nemocníc.

Dôkazy

Účinok rámca na kvalitu komunikácie je merateľný a veľký. V jednej nedávnej kontrolovanej štúdii (El-Sayed Ghonem a El-Husany, 2023) vzrástol podiel sestier preukazujúcich primeranú komunikáciu pri odovzdaní štruktúrovanú podľa SBAR zo 4,8 % pred štruktúrovaným tréningovým programom na 92,8 % po ňom. SBAR je aj kľúčovým nástrojom v TeamSTEPPS, kurikule tímovej práce vyvinutom ministerstvom obrany s Agentúrou pre výskum a kvalitu zdravotnej starostlivosti, ktoré nesie vlastnú viacdesaťročnú dôkazovú základňu o tom, že štruktúrovaná komunikácia znižuje klinické chyby.

Veľkosť takýchto zlepšení si žiada vysvetlenie. Informácie dostupné sestrám sa nezmenili. Ich klinické znalosti sa nezmenili. Zmenila sa štruktúra, v ktorej komunikovali. SBAR im dal rámec, ktorý zabezpečil, že zahrnú všetky kritické informácie, predložia ich v predvídateľnom poradí a urobia výslovný rozdiel medzi pozorovaním (situácia, pozadie) a interpretáciou (hodnotenie, odporúčanie).

SBAR prispôsobený výstupu AI agenta

Rovnaké princípy sa priamo vzťahujú na to, ako AI agent komunikuje s ľudským operátorom. Neštruktúrovaný výstup (stena textu zhŕňajúca vyšetrovanie) núti operátora extrahovať štruktúru, čo je presne ten druh kognitívnej práce, ktorý vedie k prehliadnutým informáciám a ukotveniu na prvom rozpoznanom vzore. Štruktúrovaný výstup znižuje kognitívnu záťaž a zabezpečuje úplnosť.

Pre prevádzkové AI systémy sa SBAR dá prispôsobiť do šesťprvkového rámca:

Rozšírenia nad rámec štandardného SBAR (cena nečinnosti a dôkazy) riešia špecifické výzvy interakcie AI a človeka. Cena nečinnosti čelí prirodzenému ľudskému sklonu k nečinnosti tvárou v tvár neistote (skreslenie status quo). Dôkazy riešia automatizačnú zaujatosť tým, že poskytujú surový materiál na nezávislé overenie, namiesto toho, aby operátora žiadali dôverovať iba syntéze AI.

Praktický príklad

Vezmite AI agenta, ktorý odhalil potenciálny bezpečnostný incident. Tu sú tie isté informácie prezentované v troch formátoch:

Formát 1: surový výpis

ID výstrahy: SEC-2026-04891. Zdroj: korelačné pravidlo SIEM CR-142.
Časová pečiatka: 2026-04-11T03:42:17Z. Zistené viaceré neúspešné pokusy
o prihlásenie cez SSH z IP 198.51.100.42 na hostiteľov prod-web-01 až
prod-web-08. Celkový počet pokusov: 847 za 23 minút. Geolokácia zdrojovej IP:
São Paulo, Brazília. Žiadne úspešné autentifikácie. Tempo: ~37 pokusov/min.
Vzor konzistentný s credential stuffingom. Spravodajstvo o hrozbách: IP nie je
v známych blokovacích zoznamoch. Predchádzajúca aktivita z tejto IP: žiadna za
posledných 90 dní. Sken zraniteľností hostiteľov (posledných 7 dní):
prod-web-03 má nezáplatované OpenSSH (CVE-2024-6387). Aktuálna konfigurácia
SSH: autentifikácia heslom povolená na všetkých hostiteľoch. Stav fail2ban:
aktívny, prah nastavený na 10 zlyhaní/5 minút, aktuálny zoznam zákazov
neobsahuje zdrojovú IP kvôli rozloženému časovaniu...

Formát 2: štruktúra SBAR

ČO SA STALO: Prebiehajúci útok credential stuffing na 8 produkčných
webových serverov z jedinej IP (198.51.100.42, São Paulo).

ČO SOM SKÚSIL: Dopytoval som spravodajstvo o hrozbách (IP nie je v známych
blokovacích zoznamoch), skontroloval úspešné autentifikácie (žiadne),
prešiel konfigurácie SSH (autentifikácia heslom povolená na všetkých
8 hostiteľoch), skontroloval fail2ban (aktívny, ale nespustený kvôli
rozloženému časovaniu).

ČO ODPORÚČAM: Zablokovať IP 198.51.100.42 na sieťovom firewalle
a vypnúť autentifikáciu SSH heslom na všetkých produkčných hostiteľoch.

ÚROVEŇ RIZIKA: Stredná. Zatiaľ nezistený prienik, ale prod-web-03 má
nezáplatovanú zraniteľnosť OpenSSH (CVE-2024-6387), ktorá by mohla byť
zneužitá, ak útočník zmení taktiku.

CENA NEČINNOSTI: Pokračujúce pokusy hrubou silou s potenciálnym zneužitím
CVE-2024-6387 na prod-web-03. Ak je zraniteľnosť zneužitá, útočník získa
prístup k shellu na produkčnom serveri.

DÔKAZY: [výstraha SIEM] [logy SSH] [správa zo skenu zraniteľností]
[dopyt na spravodajstvo o hrozbách]

Formát 3: postupné odhaľovanie (podrobne v ďalšej časti)

Vrstva 1 (5-sekundový pohľad):
  🟡 STREDNÉ | Credential stuffing na 8 prod webových serveroch |
  Odporúčanie: zablokovať zdrojovú IP + vypnúť autentifikáciu heslom

Vrstva 2 (30-sekundové hodnotenie):
  [úplný SBAR ako vyššie]

Vrstva 3 (hĺbkový ponor):
  [úplný reťazec dôkazov s výňatkami z logov, detailmi CVE,
  sieťovou topológiou, historickým kontextom]

Surový výpis obsahuje všetky tie isté informácie ako formát SBAR, ale núti operátora vykonať kognitívnu prácu ich štruktúrovania. Pod časovým tlakom a objemom výstrah typickým pre bezpečnostnú prevádzku je táto kognitívna práca presne to, čo sa preskočí, a jej vynechanie je to, čo vedie k prehliadnutému kontextu a zlým rozhodnutiam.

Kleinov model rozhodovania založeného na rozpoznaní

Model rozhodovania založeného na rozpoznaní (Recognition-Primed Decision, RPD) Garyho Kleina, vyvinutý terénnymi štúdiami hasičov, vojenských veliteľov a sestier na jednotkách intenzívnej starostlivosti, zásadne spochybňuje klasický model rozhodovania ako procesu porovnávania alternatív.

Dôkazy

V Kleinovej pôvodnej štúdii na požiarisku (26 veliteľov, 156 rozhodovacích bodov) zhruba 80 % expertných rozhodnutí nezahŕňalo vôbec žiadne porovnanie možností: veliteľ situáciu rozpoznal, vybavil si jediný fungujúci postup a išiel podľa neho. Menej než jedno rozhodnutie z ôsmich zahŕňalo zvažovanie alternatív. Experti negenerovali zoznam možností, nehodnotili každú podľa kritérií a nevyberali najlepšiu. Namiesto toho rozpoznali aktuálnu situáciu ako podobnú predtým zažitému vzoru, vybavili si krok, ktorý v tom vzore fungoval, mentálne simulovali, či by fungoval v aktuálnej situácii, a buď ho vykonali, alebo upravili.

To má priamy a protiintuitívny návrhový dôsledok: predloženie viacerých možností expertnému operátorovi môže kvalitu rozhodnutia zhoršiť, nie zlepšiť. Kognitívny proces experta je optimalizovaný na hodnotenie jednej možnosti voči situácii, nie na porovnávanie možností medzi sebou. Systém, ktorý predloží tri možné koreňové príčiny s výhodami a nevýhodami každej, bojuje s prirodzeným rozhodovacím procesom experta. Systém, ktorý predloží jedinú najpravdepodobnejšiu koreňovú príčinu s podpornými dôkazmi a odporúčaným krokom, s ním pracuje.

Návrhový dôsledok pre AI agentov

Predložte jediný odporúčaný krok AI ako prvý, s podpornými dôkazmi. Sprístupnite alternatívne vysvetlenia na požiadanie (postupné odhaľovanie, diskutované nižšie), ale nenúťte experta spracovať ich skôr, než vyhodnotí primárne odporúčanie.

To neznamená alternatívy skrývať. Znamená to štruktúrovať prezentáciu tak, aby prvým kognitívnym zapojením operátora bola najpravdepodobnejšia hypotéza, čo je vzor zapojenia zodpovedajúci tomu, ako experti naozaj premýšľajú. Ak primárne odporúčanie nezodpovedá rozpoznaniu vzoru operátorom (ak niečo pôsobí zle), operátor bude hľadať alternatívy. Systém by mu to mal uľahčiť. Ale nemal by to vynucovať ako predvolenú cestu.

Kľúčové rozlíšenie: Pre operátorov nováčikov môže byť predloženie alternatív cenné, lebo nováčikom chýba knižnica vzorov, ktorá umožňuje rozhodnutia založené na rozpoznaní. Optimálny prezentačný formát závisí od úrovne odbornosti operátora: ďalší argument pre adaptívne rozhrania, ktoré sa prispôsobujú používateľovi.

Časový tlak a kvalita rozhodnutí

Interakcia medzi časovým tlakom a podporou AI je jemnejšia než „rýchlejšie je lepšie“ alebo „pomalšie je bezpečnejšie“. Výskum Swaroopa a kol. na Harvarde (2023) zistil, že rôzne typy podpory AI majú rôzne kompromisy medzi presnosťou a časom a optimálny typ podpory závisí od času dostupného na rozhodnutie.

Pri nízkom časovom tlaku operátori najviac ťažili z podpory AI, ktorá poskytovala vysvetlenia a podporné dôkazy, z toho druhu podpory, ktorý umožňuje analytické uvažovanie a nezávislé overenie. Pri vysokom časovom tlaku operátori najviac ťažili z jednoduchých, priamych odporúčaní, z toho druhu podpory, ktorý podporuje rýchle rozpoznávanie vzorov.

Znepokojivejšie je, že výskum zistil, že pod časovým tlakom sa rozhodnutia stali rizikovejšími a nadmerné spoliehanie sa na AI vzrástlo. Operátori pod časovým tlakom skôr prijali odporúčanie AI bez hodnotenia, skôr si vybrali rizikovejšiu možnosť, keď ju AI navrhla, a menej pravdepodobne si všimli chyby v uvažovaní AI.

Návrhový dôsledok

Prezentačný formát by sa mal prispôsobiť naliehavosti situácie:

• Nízka naliehavosť (minúty až hodiny): Predložte úplný SBAR s odkazmi na dôkazy, povzbudzujte nezávislé overenie, uplatnite kognitívne vynucovacie funkcie (pozri kapitolu 4).
• Stredná naliehavosť (sekundy až minúty): Predložte zhrnutie SBAR s jediným odporúčaným krokom, dôkazy sprístupnite, ale nevyžadujte ich revíziu.
• Vysoká naliehavosť (okamžite): Predložte iba krok a závažnosť, s vykonaním na jedno kliknutie. Rozhodnutie zalogujte na dodatočnú revíziu.

To sa priamo mapuje na rámec postupného odhaľovania diskutovaný nižšie.

Postupné odhaľovanie

Postupné odhaľovanie je princíp informačnej architektúry, ktorý organizuje obsah do vrstiev rastúcej podrobnosti a dovoľuje používateľovi dostať sa k úrovni detailu, ktorú potrebuje, bez toho, aby ho zahltila úroveň, ktorú nepotrebuje. V prevádzkových AI systémoch je to primárny mechanizmus podpory rýchleho rozpoznávania vzorov u expertov aj dôkladnej analýzy u nováčikov v jedinom rozhraní.

Tri vrstvy

Vrstva 1: 5-sekundový pohľad

To je to, čo operátor vidí, keď sa prvýkrát pozrie na obrazovku, preletí upozornenie alebo mrkne na dashboard. Musí za päť sekúnd alebo menej komunikovať tri veci:

• Závažnosť (vizuálny indikátor: farba, ikona alebo kategorický štítok)
• Zhrnutie (jedna veta: čo sa stalo a čo je v hre)
• Odporúčaný krok (jedna fráza: čo urobiť)

Vrstva 1 podporuje rozhodovací proces experta založený na rozpoznaní. Skúsený operátor prezerajúci vrstvu 1 buď vzor rozpozná a koná, alebo ho nerozpozná a ide hlbšie. Žiadne kognitívne úsilie sa nemrhá na detail, ktorý na prvotné rozpoznanie netreba.

Príklad:

🔴 KRITICKÉ | Zistené prepnutie primárnej databázy na záložnú, oneskorenie
replikácie rastie | Odporúčanie: povýšiť repliku db-replica-02 na primárnu

Vrstva 2: 30-sekundové hodnotenie

To je brífing SBAR s úrovňami istoty. Poskytuje dosť kontextu na to, aby operátor vyhodnotil odporúčanie AI, položil objasňujúce otázky alebo si utvoril alternatívnu hypotézu. Je to vrstva, kde operátor prechádza z rozpoznávania vzorov k analytickému uvažovaniu.

Vrstva 2 zahŕňa: - Úplnú štruktúru SBAR (čo sa stalo, čo som skúsil, čo odporúčam, úroveň rizika, cena nečinnosti) - Úroveň istoty AI (diskutovanú v ďalšej časti) - Kľúčové metriky a ich trendy - Relevantné nedávne zmeny alebo udalosti

Vrstva 3: hĺbkový ponor

To je úplný reťazec dôkazov: surové logy, časové rady metrík, rozdiely konfigurácií, články znalostnej bázy, historické záznamy incidentov a reťazec uvažovania AI. Používa sa na revíziu po incidente, v prípadoch, keď operátor nesúhlasí s hodnotením AI, alebo pri nových situáciách, ktoré nezodpovedajú žiadnemu známemu vzoru.

Vrstva 3 je aj miestom, kde prepojenie s dôkazmi (diskutované nižšie) prináša svoju hodnotu, lebo dovoľuje operátorovi vystopovať závery AI späť ku konkrétnym dátovým bodom.

Prečo tri vrstvy

Tri nie sú ľubovoľné. Výskum kognitívnej záťaže konzistentne ukazuje, že ľudia dokážu efektívne spracovať 3 – 5 kusov informácií naraz (Miller, 1956; Cowan, 2001). Tri vrstvy sa mapujú na tri odlišné kognitívne režimy:

Komunikácia istoty

To, ako AI agent komunikuje svoju istotu v odporúčaní, je jedným z najzávažnejších a najčastejšie zle zvládnutých aspektov prezentácie kontextu.

Problém so surovými pravdepodobnosťami

Intuitívny prístup (predloženie číselnej pravdepodobnosti („87 % istota, že ide o útok credential stuffing“)) je pre väčšinu operátorov horší než zbytočný. Výskum konzistentne ukazuje, že:

• Ľudia pravdepodobnosti zle kalibrujú, preceňujú nízke a podceňujú vysoké (Kahneman a Tversky, 1979).
• Číselné pravdepodobnosti vytvárajú falošnú presnosť. „87 % istota“ naznačuje úroveň kalibrácie, akú žiadny súčasný LLM nemá.
• Rôzni operátori interpretujú tú istú pravdepodobnosť rôzne. „87 %“ môže jednému operátorovi pripadať takmer isté a inému nepríjemne neisté.

Kategorická istota s kalibráciou

Účinnejší prístup používa kategorické štítky namapované na definované rozsahy pravdepodobnosti a prevádzkové dôsledky:

Hodnota kategorických štítkov nespočíva v presnosti, ale v kalibrácii správania operátora. „Vysoká istota“ komunikuje nielen pravdepodobnosť, ale aj očakávanú reakciu: overte kľúčové predpoklady, potom konajte. „Nízka istota“ komunikuje inú očakávanú reakciu: vyšetrujte ďalej. Štítok vedie správanie spôsobom, akým číslo nie.

Vizualizácia neistoty

Výskum Reyesa a kol. (2025) zistil, že predloženie vizualizácií neistoty (grafických zobrazení rozdelenia istoty AI namiesto jediného bodového odhadu) zvýšilo dôveru u 58 % účastníkov, ktorí prišli s negatívnymi postojmi k AI (štvrtina vzorky; účinok sa sústredil presne tam, kde je oprava dôvery najťažšia). Vizualizácia neistoty je kalibračná páka, nie univerzálna.

Doplňujúca štúdia na ACM FAccT (2025) zistila, že skóre istoty založené na vzdialenosti (metriky, ktoré komunikujú, ako podobná je aktuálna situácia tréningovým dátam, na ktorých bola AI kalibrovaná) priniesli o 8,2 % viac správnych rozhodnutí v porovnaní s tradičnými skóre istoty, v malej medicínskej štúdii delegovania úloh (29 účastníkov; berte to ako sľubné, nie uzavreté). Skóre založené na vzdialenosti pomáhajú operátorom pochopiť nielen to, aká istá si je AI, ale aj to, aká relevantná je jej kalibrácia istoty pre aktuálnu situáciu.

Kľúčový postreh: Cieľom komunikácie istoty nie je presne sprostredkovať vnútorný stav AI, ale primerane kalibrovať správanie operátora. Formát istoty, ktorý spôsobí, že operátori overujú odporúčania s vysokou istotou a vyšetrujú tie s nízkou, uspieva, bez ohľadu na to, ako presne sa mapuje na skutočné rozdelenie pravdepodobnosti modelu.

Prepojenie s dôkazmi a vysvetliteľnosť

Poslednou zložkou prezentácie kontextu je prepojenie s dôkazmi: spojenie záverov a odporúčaní AI s konkrétnymi dátovými bodmi, ktoré ich podporujú. Slúži dvom funkciám: umožňuje nezávislé overenie (čelí automatizačnej zaujatosti) a poskytuje surový materiál na to, aby si operátor vybudoval vlastné situačné povedomie namiesto úplného spoliehania sa na syntézu AI.

Citácie RAG a vložené odkazy

Pre AI agentov používajúcich generovanie rozšírené o vyhľadávanie (RAG) je najpriamočiarejšou formou prepojenia s dôkazmi vložená citácia: označenie každého tvrdenia vo výstupe AI odkazom na zdrojový dokument, záznam logu alebo metriku, ktorá ho podporuje. Je to rovnaký prístup ako v akademickom písaní, prispôsobený prevádzkovému kontextu.

Príklad:

Hodnotenie koreňovej príčiny: Vyčerpanie fondu spojení na db-primary-01
[1] spustilo nasadenie v2.4.7 o 14:32 UTC [2], ktoré zaviedlo únik
spojení v module autentifikácie používateľov [3]. Počet spojení vzrástol
zo základných 45 na maximum 500 za 23 minút [4], čo spôsobilo kaskádové
vypršania časových limitov v nadväzujúcich službách [5].

Zdroje:
[1] Metrika CloudWatch: aktívne spojenia db-primary-01 (14:00 – 15:00 UTC)
[2] Log nasadenia: záznam o vydaní v2.4.7
[3] Git diff: commit a3f7c2e, súbor auth/connection_pool.py, riadky 142 – 158
[4] Dashboard metrík fondu spojení (odkaz)
[5] Mapa závislostí služieb so stopou šírenia chýb (odkaz)

Postupné odhaľovanie reťazca uvažovania

Pri zložitejších analýzach sa dá pomocou postupného odhaľovania prezentovať aj samotný reťazec uvažovania AI:

• Vrstva 1: Záver a odporúčaný krok (bez uvažovania).
• Vrstva 2: Kľúčové kroky uvažovania: 3 – 4 najdôležitejšie logické spojenia medzi dôkazmi a záverom.
• Vrstva 3: Úplný reťazec uvažovania vrátane hypotéz, ktoré boli zvážené a zamietnuté, s dôkazmi pre a proti každej.

Tento prístup rešpektuje rozhodovací proces experta založený na rozpoznaní (vrstva 1 stačí, ak je vzor známy) a zároveň poskytuje úplnú audítorskú stopu pre prípady, ktoré vyžadujú hlbšiu analýzu alebo revíziu po incidente.

Program DARPA XAI

Agentúra ministerstva obrany pre pokročilé výskumné projekty (DARPA) viedla svoj program vysvetliteľnej AI (XAI) v rokoch 2017 až 2021 a financovala okolo tucta výskumných tímov na testovanie prístupov, ako urobiť uvažovanie AI systémov transparentným pre ľudských operátorov. Medzi prístupmi, ktoré retrospektívy programu vyzdvihujú, vynikajú vysvetlenia založené na príkladoch ako obzvlášť účinné pre prevádzkové rozhodovanie (program nevyhlásil jediného univerzálneho víťaza; ktorý štýl vysvetlenia pomáha, závisí od úlohy).

Namiesto vysvetľovania vnútornej logiky AI („neurónová sieť priradila váhu 0,73 príznaku X“) vysvetlenia založené na príkladoch predkladajú podobné prípady z minulosti a ich výsledky: „Táto situácia je podobná incidentu INC-2025-3847, ktorý spôsobila nesprávna konfigurácia DNS a vyriešilo ho vyprázdnenie cache DNS. Riešenie trvalo 12 minút a nebol hlásený žiadny dopad na zákazníkov.“

Vysvetlenia založené na príkladoch fungujú, lebo sa zhodujú s modelom rozhodovania založeného na rozpoznaní: pomáhajú operátorovi priradiť aktuálnu situáciu k známemu vzoru, čo je kognitívny proces, ktorý experti naozaj používajú.

Spojenie do celku

Účinná prezentácia kontextu na šve medzi AI a človekom integruje všetky štyri rámce:

1. Štruktúrujte výstup pomocou SBAR, aby ste zabezpečili úplnosť a predvídateľnosť.
2. Priorizujte odporúčaný krok ako prvý, v súlade s modelom RPD, a alternatívy sprístupnite na požiadanie.
3. Vrstvite informácie pomocou postupného odhaľovania, aby sa každý operátor mohol zapojiť v hĺbke primeranej jeho odbornosti a naliehavosti situácie.
4. Kalibrujte komunikáciu istoty pomocou kategorických štítkov s prevádzkovými dôsledkami, nie surových pravdepodobností.
5. Prepájajte závery s dôkazmi pomocou vložených citácií a vysvetlení založených na príkladoch.

Nie sú to nezávislé návrhové voľby. Interagujú: SBAR poskytuje štruktúru pre vrstvu 2. Model RPD určuje, čo ide do vrstvy 1. Komunikácia istoty určuje, ako sa operátor zapája do vrstiev 1 a 2. Prepojenie s dôkazmi napĺňa vrstvu 3.

Výsledkom, ak sa implementuje súdržne, je prezentačný formát, ktorý:

• Podporuje rýchle rozpoznávanie vzorov u skúsených operátorov (vrstva 1, zosúladenie s RPD)
• Umožňuje analytické hodnotenie, keď je potrebné (vrstva 2, štruktúra SBAR)
• Poskytuje úplnú audítorskú stopu na dodatočnú revíziu a učenie (vrstva 3, prepojenie s dôkazmi)
• Primerane kalibruje dôveru operátora (komunikácia istoty)
• Znižuje automatizačnú zaujatosť tým, že uľahčuje nezávislé overenie (prepojenie s dôkazmi)
• Znižuje ukotvenie tým, že predkladá dáta pred interpretáciou, keď to čas dovolí (poradie SBAR)

Ďalšia kapitola skúma, ako sa dôvera medzi ľudskými operátormi a AI agentmi vyvíja, kalibruje a (keď sa zle riadi) rúca.

Kapitola 6: Kalibrácia dôvery

Dôvera v AI systém nie je vypínač, ktorý prepnete. Predstavte si ju ako regulátor, ktorý kalibrujete.

Keď inžinier GenAI nasadí AI agenta do prevádzkového prostredia (IT service desk, sieťové operačné centrum, klinický pracovný postup), ústrednou návrhovou výzvou nie je presnosť, latencia, cena za token, ba ani bezpečnosť v abstraktnom zmysle. Ústrednou výzvou je zabezpečiť, aby ľudia, ktorí pracujú po boku agenta, mu dôverovali presne toľko, koľko si dôveru zaslúži. Nie viac. Nie menej. Táto kapitola skúma, z čoho dôvera v automatizované systémy naozaj pozostáva, ako sa formuje a láme a ako navrhnúť vzory interakcie, ktoré ju udržia správne kalibrovanú. Všimnite si, že táto kapitola sa venuje kalibrácii na strane operátora: ako ľudia interpretujú signály istoty AI a konajú podľa nich. Kalibrácia na strane modelu (či uvádzaná istota modelu zodpovedá skutočnej presnosti) je samostatný inžiniersky problém; kapitola 8 poskytuje praktický pracovný postup na empirickú kalibráciu istoty modelu voči prevádzkovým výsledkom.

Rámec Leeho a Seeho: výkon, proces, účel

Základný model na pochopenie dôvery v automatizáciu pochádza od Leeho a Seeho (2004), ktorí syntetizovali desaťročia výskumu do trojrozmerného rámca. Dôvera, argumentovali, nie je jediný postoj, ale zloženina troch odlišných úsudkov:

• Výkon: Zvládne to prácu? Táto dimenzia zachytáva operátorovo hodnotenie kompetencie systému: jeho presnosti, spoľahlivosti a konzistencie naprieč úlohami, ktoré má riešiť.
• Proces: Ako funguje? Táto dimenzia odráža pochopenie vnútornej logiky systému. Operátor, ktorý si vie utvoriť rozumný mentálny model toho, prečo systém produkuje daný výstup, bude dôveru kalibrovať účinnejšie než ten, kto ho berie ako čiernu skrinku.
• Účel: Prečo bol postavený takto? Táto dimenzia rieši operátorovo presvedčenie o zámere návrhára. Slúži systém cieľom operátora, alebo optimalizuje niečo iné?

Každá dimenzia sa môže nezávisle zle kalibrovať. Operátor môže dôverovať výkonu systému na základe série dobrých výsledkov, pričom nerozumie jeho procesu, čo je kombinácia produkujúca krehkú dôveru, náchylnú na zrútenie pri prvom neočakávanom zlyhaní. Naopak, operátor, ktorý dobre rozumie procesu, ale nikdy nevidel systém zvládať hraničný prípad, môže dôveru vo výkon kalibrovať privysoko.

Kľúčové rozlíšenie: Nadmerná dôvera vedie k automatizačnej zaujatosti a sebauspokojeniu: operátor prestane kontrolovať prácu systému, prijíma nesprávne odporúčania a stráca situačné povedomie. Nedostatočná dôvera vedie k nepoužívaniu a neefektivite: operátor ignoruje platné odporúčania, duplikuje úsilie a hodnotu systému úplne neguje. Oba režimy zlyhania sú dobre zdokumentované v doménach kritických pre bezpečnosť a oba sú prítomné v každej prevádzke rozšírenej o AI.

Praktický dôsledok pre inžinierov GenAI je, že kalibrácia dôvery vyžaduje zámerný návrh naprieč všetkými tromi dimenziami. Zobrazovanie metrík presnosti rieši výkon. Ukazovanie stôp uvažovania rieši proces. Dokumentovanie návrhových rozhodnutí a optimalizačných cieľov rieši účel. Zanedbanie ktorejkoľvek dimenzie vytvára kalibračnú medzeru.

Dispozičná, situačná a naučená dôvera

Hoff a Bashir (2015) rozšírili literatúru o dôvere do vrstveného modelu, ktorý vysvetľuje, prečo rôzni operátori reagujú na ten istý systém tak rôzne. Ich rámec identifikuje tri vrstvy dôvery, ktoré pôsobia súčasne:

Dispozičná dôvera je východisko. Odráža všeobecný sklon jednotlivca dôverovať alebo nedôverovať automatizovaným systémom, tvarovaný osobnosťou, kultúrou, vekom a predchádzajúcou skúsenosťou s technológiou vo všeobecnosti. Dvadsaťpäťročný inžinier, ktorý vyrástol s odporúčacími algoritmami, prichádza s iným dispozičným východiskom než päťdesiatpäťročný prevádzkový manažér, ktorého kariéra predchádza internet. Ani jedno východisko nie je samo osebe lepšie; obe môžu viesť k zlej kalibrácii.

Situačná dôvera závisí od kontextu. Kolíše podľa aktuálneho prevádzkového prostredia: pracovnej záťaže, časového tlaku, vnímaného rizika a dostupnosti alternatív. Operátor pod extrémnym časovým tlakom pri incidente P1 skôr prijme odporúčanie AI bez skúmania, nie preto, že systému v nejakom stabilnom zmysle dôveruje viac, ale preto, že cena overenia mu pripadá vyššia než riziko chyby. Presne vtedy je automatizačná zaujatosť najnebezpečnejšia.

Naučená dôvera je vrstva, ktorá sa hromadí priamou skúsenosťou s konkrétnym systémom. Je najsilnejšia a najviac navrhnuteľná. Merritt a Ilgen (2008) ukázali, že len čo ľudia začnú pracovať s konkrétnym systémom, dôvera založená na histórii rýchlo prevládne nad akoukoľvek dispozíciou, s ktorou prišli. Toto zistenie má hlboké návrhové dôsledky: obdobie zaškolenia je obdobie, počas ktorého sa ustanovuje dlhodobá kalibrácia dôvery operátora, nie iba úvod.

Pre inžinierov GenAI tento vrstvený model naznačuje fázový prístup k návrhu dôvery:

1. Počas zaškolenia počítajte s dispozičnou variabilitou. Nepredpokladajte jednotný východiskový bod. Niektorí operátori sa budú okamžite nadmerne spoliehať; iní sa budú zapojeniu úplne brániť.
2. Počas prevádzky pod vysokým tlakom navrhujte pre situačnú infláciu dôvery. Pridajte trenie (potvrdzovacie kroky, povinnú revíziu uvažovania) presne vtedy, keď sú operátori najviac v pokušení ho preskočiť.
3. Naprieč prevádzkovým životným cyklom silno investujte do vrstvy naučenej dôvery. Poskytujte transparentné dáta o výkone. Poctivo ukazujte zlyhania. Urobte záznam systému o výkone viditeľným a prehľadávateľným.

Vyjadrenie neistoty v prvej osobe

Jedno z najpoužiteľnejších zistení nedávneho výskumu kalibrácie dôvery pochádza od Kimovej a kol. (FAccT 2024, Microsoft Research, N=404). Štúdia skúmala, ako by AI systémy mali komunikovať neistotu, a zistila, že jazykové rámcovanie neistoty záleží rovnako ako to, či sa neistota vôbec komunikuje.

Keď AI systém vyjadril neistotu v prvej osobe („Nie som si istý, ale myslím, že tento tiket by mal byť kategorizovaný ako sieťový problém“), účastníci hlásili zníženú istotu v odporúčaní systému. Na prvý pohľad to vyzerá ako zlyhanie. Ale kľúčovým zistením bolo, že túto zníženú istotu sprevádzala zvýšená presnosť rozhodnutí. Účastníci, ktorí dostali výhradu v prvej osobe, s väčšou pravdepodobnosťou odporúčanie nezávisle vyhodnotili, chytili chyby a dospeli k správnym záverom.

Naproti tomu výhrada zo všeobecnej perspektívy („Toto môže byť sieťový problém“ alebo „V kategorizácii je určitá neistota“) mala slabší účinok. Rámcovanie v prvej osobe zjavne aktivuje iný kognitívny proces: namiesto toho, aby sa neistota brala ako vlastnosť problému (ktorú operátor možno nemá pocit, že vie vyriešiť), rámcovanie v prvej osobe berie neistotu ako vlastnosť úsudku systému, ktorú operátor rozpozná ako niečo, čo môže a má vyhodnotiť.

Kľúčový postreh: Navrhnúť AI agenta tak, aby hovoril „Nie som si istý“, nie je priznanie slabosti, ale kalibračný mechanizmus. Cieľom nie je maximalizovať istotu operátora v každom odporúčaní, ale maximalizovať presnosť operátora v rozhodnutiach, ktoré na základe tých odporúčaní robí.

Implementačný vzor je priamočiary, ale vyžaduje disciplínu:

• Keď je istota modelu pod definovaným prahom (kalibrovaným pre konkrétny prípad použitia), predraďte odporúčaniu značky neistoty v prvej osobe.
• Používajte konkrétny jazyk: „Nie som si istý týmto hodnotením“, nie neurčitú výhradu ako „Toto by potenciálne mohlo byť…“
• Spárujte vyjadrenie neistoty s uvažovaním systému, aby operátor vedel, v čom si systém nie je istý, a mohol podľa toho sústrediť svoje overovanie.

Dashboardy záznamu o výkone

Štúdia z roku 2024 o predpovedateľoch Národnej meteorologickej služby (NWS), ktorí integrovali nástroje AI na predpovedanie do svojho pracovného postupu, zistila pozoruhodný konsenzus: všetci predpovedatelia považovali za nevyhnutné preskúmať predpovede AI pre minulé prípady skôr, než začnú dôverovať aktuálnemu výstupu systému. Nechceli hodnotiť AI na jedinej predpovedi. Chceli vidieť jej záznam o výkone, najmä jej zlyhania.

Toto zistenie sa zhoduje s vrstvou naučenej dôvery v rámci Hoffa a Bashira a ukazuje na konkrétnu návrhovú požiadavku: dashboardy záznamu o výkone. Nie sú to jednoduché percentá presnosti, ale prehľadávateľné histórie, ktoré dovoľujú operátorom budovať kalibrované mentálne modely toho, kde systém uspieva a kde zlyháva.

Účinný dashboard záznamu o výkone pre prevádzku rozšírenú o AI by mal zahŕňať:

• Presnosť podľa typu kroku. AI agent, ktorý správne vyrieši 94 % tiketov na reset hesla, ale iba 61 % problémov s konfiguráciou VPN, potrebuje tie čísla zobrazené osobitne. Zmiešaná metrika presnosti skrýva variabilitu, ktorú operátori na kalibráciu potrebujú.
• Logy chýb s kontextom. Keď sa systém mýlil, v čom sa mýlil a prečo? Prehľadávateľné, kategorizované histórie chýb dovoľujú operátorom vyvinúť rozpoznávanie vzorov pre režimy zlyhania systému.
• História eskalácií. Ako často systém eskaluje na človeka a čo sa deje po eskalácii? Systém, ktorý eskaluje 40 % prípadov, môže byť dobre kalibrovaný; systém, ktorý eskaluje 2 % prípadov, môže byť nebezpečne presebavedomý.
• Časové trendy. Zlepšuje sa systém, zhoršuje, alebo je stabilný? Operátori, ktorí vidia výkonnostné trendy, vyvinú sofistikovanejšie modely dôvery než tí, ktorí vidia iba aktuálne snímky.
• Porovnanie s ľudským východiskom. Tam, kde je dostupné, ukážte, ako sa výkon AI porovnáva s výkonom človeka bez podpory pri rovnakých typoch úloh. To ukotví kalibráciu v prevádzkovej realite, nie v abstraktných očakávaniach.

Oprava dôvery po zlyhaniach

Dôvera v automatizované systémy, raz poškodená, sleduje asymetrickú trajektóriu, s ktorou musí každý inžinier GenAI počítať: po zlyhaní klesá rýchlo (často v jedinej udalosti), ale zotavuje sa pomaly, počas viacerých úspešných interakcií. Asymetria medzi tým, ako sa dôvera ničí a ako sa znovu buduje, je dlhodobé zistenie v literatúre o riziku a De Visser, Pak a Shaw (2018) na ňom postavili rámec opravy dôvery pre interakciu človeka a stroja. Jediné vysoko viditeľné zlyhanie môže vymazať týždne alebo mesiace získanej dôvery.

Táto asymetria vytvára návrhový imperatív: oprava dôvery musí byť aktívny, navrhnutý proces, nie pasívny dôsledok obnoveného dobrého výkonu. Jednoducho pokračovať v správnej prevádzke po zlyhaní nestačí. Systém (a organizácia okolo neho) musí urobiť výslovné opravné kroky.

Pak a Rovira (2023) modelovali, ktoré opravné kroky by sa mali ukázať ako najtrvanlivejšie (empirický záznam o oprave dôvery je skutočne zmiešaný, čo ich model motivovalo): ich predpoveď, ukotvená v teórii presviedčania, je, že vecné vysvetlenia prinášajú trvanlivejšiu opravu než emocionálne ospravedlnenia, lebo vysvetlenie zapája operátorovo uvažovanie o systéme, nie jeho pocity z udalosti. Ospravedlnenie, ktoré nesie vysvetľujúci obsah, môže fungovať tiež; ospravedlnenie bez neho vyprchá. Inžinierom bude predpoveď pripadať neprekvapivá a má priame dôsledky pre návrh komunikácie o incidentoch.

Účinné stratégie opravy dôvery zahŕňajú:

1. Okamžité priznanie. Systém by mal svoje zlyhania sám ukázať, namiesto čakania, kým ich operátor objaví. Systém, ktorý povie „V predchádzajúcom odporúčaní som urobil chybu; tu je, čo som pokazil“, zachová viac dôvery než ten, ktorého chyby sa objavia nezávisle.
2. Vysvetlenie koreňovej príčiny. Poskytnite technicky poctivé vysvetlenie, prečo k zlyhaniu došlo, na úrovni detailu primeranej operátorovi. „Vyhalucinoval som neexistujúci koncový bod API, lebo tréningové dáta obsahovali zastaranú dokumentáciu“ opravuje účinnejšie než „Došlo k chybe.“
3. Dôkaz o náprave. Keď je to možné, ukážte, čo sa zmenilo. Ak pribudol mantinel, doladil sa prompt alebo sa aktualizovala znalostná báza, komunikujte to konkrétne.
4. Odstupňované opätovné zapojenie. Po významnom zlyhaní dočasne zvýšte úroveň ľudského dohľadu. Je to kalibračný mechanizmus, nie trest: dovolí operátorovi znovu vybudovať naučenú dôveru priamym pozorovaním.

Behaviorálne metriky kalibrácie dôvery

Navrhovať pre kalibráciu dôvery je len polovica problému. Druhá polovica je merať, či ku kalibrácii naozaj dochádza. Existuje viacero validovaných prístupov.

Škála dôvery v automatizované systémy Jiana a kol. (2000) je najpoužívanejší sebahodnotiaci nástroj, pozostávajúci z 12 položiek, ktoré hodnotia dôveru a nedôveru ako samostatné konštrukty. Je užitočná na periodické hodnotenia, ale obmedzená štandardnými slabinami sebahodnotiacich meraní: operátori nemusia presne hlásiť vlastnú úroveň dôvery a samotný akt merania môže meranú vec zmeniť.

Behaviorálne metriky sú pre prevádzkové prostredia diagnostickejšie:

• Miera súladu meria, ako často sa operátor riadi odporúčaním AI. Vysoký súlad (>95 %) v systéme so známymi mierami chýb naznačuje nadmernú dôveru. Nízky súlad (<50 %) pri dobre fungujúcom systéme naznačuje nedostatočnú dôveru.
• Váha rady (Weight of Advice, WoA) zachytáva nielen to, či sa operátor riadi odporúčaním, ale aj to, o koľko k nemu posunie svoj pôvodný úsudok. WoA 0 znamená, že operátor AI úplne ignoruje; WoA 1 znamená, že prijme jej odporúčanie bez zmeny.
• Miery prebitia rozvrstvené podľa úrovne istoty sú najdiagnostickejšia dostupná metrika. Operátor, ktorý AI prebíja rovnakou mierou bez ohľadu na to, či systém hlási 60 % alebo 99 % istotu, nie je kalibrovaný; buď informáciu o istote ignoruje, alebo ju berie ako bezvýznamnú. Dobre kalibrovaný operátor prebíja viac pri nižších úrovniach istoty a menej pri vyšších.

Retrospektívna štúdia s klinickou dátovou sadou MIMIC-III a AI systémom na podporu klinického rozhodovania metriku ilustruje: odporúčania na úrovni istoty 90 – 99 % boli prebité iba v 1,7 % prípadov. (Jedna simulovaná štúdia v jednej doméne; berte číslo ako ilustráciu meracieho prístupu, nie ako benchmark.) Kritickou otázkou sa potom stáva, či prebitia, ku ktorým pri vysokej istote dochádza, zachytávajú skutočné chyby systému, čo vyžaduje sledovať presnosť prebití v čase.

Kľúčový postreh: Dobre kalibrovaný vzťah dôvery znamená, že operátor spochybňuje AI presne vtedy, keď sa AI najpravdepodobnejšie mýli. Merať to vyžaduje korelovať rozhodnutia o prebití s úrovňami istoty a nakoniec so správnosťou výsledku.

Mechanizmy kalibrácie dôvery: zhrnutie

Nasledujúca tabuľka konsoliduje mechanizmy diskutované v tejto kapitole do referencie na implementáciu:

Navrhovať pre kalibráciu, nie pre maximalizáciu

Inštinkt mnohých inžinierskych tímov je dôveru maximalizovať: postaviť systémy tak spoľahlivé a tak pôsobivé, že im operátori úplne dôverujú. Tento inštinkt je nesprávny. Úplná dôvera je zle kalibrovaná dôvera. Produkuje automatizačnú zaujatosť, sebauspokojenie a katastrofické zlyhania, keď systém nevyhnutne narazí na prípad mimo svojej kompetencie.

Cieľom je kalibrácia: dynamický, kontextovo citlivý vzťah, v ktorom dôvera operátora sleduje skutočnú spoľahlivosť systému naprieč rôznymi typmi úloh, úrovňami istoty a prevádzkovými podmienkami. Dosiahnuť to vyžaduje brať dôveru nie ako marketingový problém (ako prinútiť ľudí dôverovať nášmu systému?), ale ako problém merania a riadenia (ako zabezpečiť, aby úroveň dôvery operátora zodpovedala skutočnej schopnosti systému v tomto konkrétnom kontexte?).

Každé návrhové rozhodnutie v prevádzke rozšírenej o AI (od formulácie odporúčaní cez rozloženie dashboardov po štruktúru revízií incidentov) kalibrácii dôvery buď pomáha, alebo bráni. Neexistuje neutrálna pôda. Vzory opísané v tejto kapitole poskytujú základ, ale kalibrácia nie je nikdy hotová. Musí sa monitorovať, merať a upravovať priebežne, lebo systém aj ľudia, ktorí ho používajú, sa stále menia.

Kapitola 7: Návrh pre zlyhanie

Každý AI agent zlyhá. Otázka nie je či, ale ako, a či ste s tým pri návrhu počítali.

To je inžinierska disciplína, nie pesimizmus. Mosty sa navrhujú na zaťaženia, ktoré nikdy neponesú. Lietadlá sa navrhujú na motory, ktoré nikdy nezlyhajú. Hodnota návrhu orientovaného na zlyhanie sa nerealizuje vtedy, keď sa veci pokazia, ale každý deň, keď veci idú dobre, lebo operátori systému vedia, že keď zlyhanie príde, bude zadržané, viditeľné a napraviteľné. Táto kapitola skúma špecifické režimy zlyhania systémov založených na LLM v prevádzke, architektonické vzory, ktoré ich zadržiavajú, a vypínače a ističe, ktoré bránia tomu, aby sa zo zlyhaní stali katastrofy.

Halucinácia ako štrukturálna črta

Najvýraznejším režimom zlyhania veľkých jazykových modelov je halucinácia: generovanie vierohodného, plynulého a sebaisto vysloveného obsahu, ktorý je fakticky nesprávny. Je lákavé brať halucináciu ako chybu, ktorá sa opraví v ďalšom vydaní modelu. To je nebezpečný omyl. Halucinácia je štrukturálna črta toho, ako autoregresívne jazykové modely fungujú. Predpovedajú pravdepodobné ďalšie tokeny, nie pravdivé. Rozdelenie pravdepodobnosti, z ktorého vzorkujú, tvarujú tréningové dáta, nie realita.

Dôkazy pre tento štrukturálny pohľad sú rozsiahle a triezve.

Whisper od OpenAI, systém na rozpoznávanie reči, ukazuje, že aj vysoko schopné modely halucinujú v prevádzkovo významných mierach. Koenecke a kolegovia (FAccT 2024) zdokumentovali približne 1-percentnú mieru halucinácií naprieč prepismi: číslo, ktoré znie malé, kým sa nedozviete, že zhruba 40 % tých halucinácií bolo hodnotených ako potenciálne škodlivé, vrátane vymysleného násilia a sfabrikovaných pokynov k liekom. Zistenie záleží prevádzkovo, lebo nástroje založené na Whisperi už vtedy prepisovali milióny lekárskych návštev: 1-percentná miera fabrikácie v systéme spracúvajúcom tisíce klinických poznámok denne znamená desiatky nebezpečných fabrikácií vstupujúcich do záznamov každý deň.

Právna prax už priniesla judikatúru o dôsledkoch. V roku 2023 boli dvaja advokáti a ich kancelária spoločne sankcionovaní sumou 5 000 dolárov za predloženie právneho podania obsahujúceho citácie prípadov sfabrikované ChatGPT (Mata v. Avianca). Prípady (kompletné s vierohodnými spisovými značkami, menami sudcov a právnym odôvodnením) jednoducho neexistovali. Advokáti citácie neoverili, lebo výstup bol taký plynulý a podrobný, že nevzbudil podozrenie.

Chatbot Air Canada si vymyslel politiku cestovného pri úmrtí v rodine, ktorá neexistovala, a sľúbil zákazníkovi zľavu, akú letecká spoločnosť nikdy neponúkala. Keď sa zákazník pokúsil zľavu uplatniť, Air Canada argumentovala, že vyjadrenia chatbota nie sú záväzné. Tribunál nesúhlasil: spoločnosť bola uznaná zodpovednou za fabrikácie svojho agenta bez ohľadu na to, či bol ten agent ľudský alebo umelý.

Toto nie sú okrajové prípady, ale miery si zaslúžia presnosť, lebo sa podľa usporiadania rozprestierajú cez dva rády. Na benchmarkoch faktického vybavovania v otvorenej doméne vlastná systémová karta OpenAI uvádza o3 s 33-percentnou mierou halucinácií (PersonQA) a o4-mini so 79 % (SimpleQA). Ukotvené systémy sú iný režim: dobre postavené pipeline RAG zhŕňajúce vyhľadané dokumenty merajú nízke jednotky percent (zhruba 0,7 – 3,3 % pre popredné modely na rebríčku ukotvených halucinácií Vectary). To rozpätie je prevádzkové poučenie: miery halucinácií závisia od úlohy a architektúry, a preto o tom, čo sa dostane k vašim operátorom, rozhoduje stack zmierňovania nižšie, nie iba výber modelu.

Kľúčové rozlíšenie: Prevádzkovým nebezpečenstvom halucinácie nie je chyba samotná; chyby robia aj ľudskí experti. Nebezpečenstvo je, že halucinácie prichádzajú s rovnakou plynulosťou a sebaistotou ako správne výstupy. Neexistuje žiadny syntaktický ani štylistický signál, ktorý by odlíšil sfabrikovanú odpoveď od faktickej. Preto sa zmierňovanie halucinácií nemôže spoliehať iba na výstup; musí byť architektonické.

Stack zmierňovania

Žiadna jediná technika halucinácie neodstráni. Účinné zmierňovanie vyžaduje vrstvený prístup, kde každá vrstva chytá inú kategóriu chýb:

Validácia generovania rozšíreného o vyhľadávanie (RAG) ukotvuje výstupy modelu vo vyhľadaných zdrojových dokumentoch. Pri správnej implementácii RAG znižuje faktické chyby o 35 – 60 % v porovnaní s neukotveným generovaním. Kľúčové slovo je „správnej“: naivné implementácie RAG, ktoré vyhľadajú irelevantné dokumenty alebo neoveria, že výstup modelu naozaj vyplýva z vyhľadaného obsahu, poskytujú falošný pocit bezpečia.

Reťazec overovania (Chain-of-Verification, CoVe) vyzve model, aby vygeneroval overovacie otázky o vlastnom výstupe, nezávisle na ne odpovedal a výstup revidoval podľa nájdených nezrovnalostí. Táto technika využíva pozorovanie, že modely niekedy dokážu odhaliť vlastné chyby, keď sú požiadané hodnotiť tvrdenia jednotlivo, a nie ako súčasť plynulého rozprávania.

Multiagentná validácia používa druhý model (alebo iný prompt pre ten istý model) na nezávislé vyhodnotenie výstupu prvého modelu. Nezhoda medzi agentmi sa berie ako signál na ľudskú revíziu. Tento prístup je najúčinnejší, keď má validačný agent prístup k inému kontextu alebo pokynom než generujúci agent, čo znižuje pravdepodobnosť korelovaných chýb. Jedna poctivá výhrada: LLM sediaci v úlohe sudcu nad výstupom LLM dedí slabiny LLM vrátane náchylnosti na nepriateľský obsah v tom, čo hodnotí. Naša výskumná správa Warden testuje presne toto a meria, ako obrany typu LLM ako sudca obstoja proti verejným jailbreakom; prečítajte si ju, kým budete brať model-sudcu ako tvrdú bezpečnostnú vrstvu.

Brány prahov istoty smerujú výstupy s nízkou istotou na ľudskú revíziu namiesto ich predkladania ako odporúčaní. Výzvou tu je, že istota hlásená modelom (napr. logaritmické pravdepodobnosti) často zle koreluje so skutočnou správnosťou. Kalibrácia prahov istoty vyžaduje empirické testovanie s reprezentatívnymi dátami z konkrétnej prevádzkovej domény.

Tieto vrstvy sú kumulatívne, nie alternatívne. Dobre navrhnutý systém používa všetky štyri plus doménovo špecifické overovanie (napr. kontrolu generovaného SQL voči obmedzeniam schémy, validáciu volaní API voči dokumentácii koncových bodov, krížové porovnanie kategorizácií tiketov s historickými vzormi).

Keď istota zabíja: cena sebaistej mýlky

Ak je halucinácia nebezpečná preto, že je neviditeľná, najextrémnejšou formou tohto nebezpečenstva je sebaisto nesprávne odporúčanie vo vysoko rizikovej doméne. Tri prípady ilustrujú rozsah dôsledkov.

IBM Watson for Oncology bol predávaný ako AI systém, ktorý vie odporúčať onkologickú liečbu, podporený zhruba 4 miliardami dolárov v akvizíciách zdravotníckych dát a nasadený v nemocniciach po celom svete. Interné dokumenty, o ktorých v roku 2018 informoval STAT, ukázali systém odporúčajúci bevacizumab (antiangiogénny liek so známym rizikom smrteľného krvácania) pre (testovacieho) pacienta s rakovinou pľúc a silným krvácaním. Žiadny skutočný pacient to odporúčanie nedostal, čo je presne to, čo robí prípad poučným: nebezpečné odporúčanie sa chytilo pri hodnotení, lebo klinici kontrolovali. Systém bol trénovaný primárne na malom počte syntetických prípadov, nie na skutočných dátach pacientov, a jeho sebaisté výstupy neodrážali obmedzenia jeho tréningu. IBM nakoniec Watson Health utlmil a predal a epizóda sa stala varovným príbehom nasadzovania klinickej AI.

Zillow Offers používal AI modely na predpovedanie hodnoty domov a automatické nákupné ponuky. Modely si boli istými svojimi predpoveďami. Boli tiež systematicky nesprávne a nadhodnocovali nehnuteľnosti v rozsahu, ktorý v roku 2021 priniesol segmentu obchodovania s domami stratu 880 miliónov dolárov. Zillow program úplne zrušil a znížil počet zamestnancov približne o 25 %, okolo 2 000 ľudí. Zlyhanie nebolo v tom, že sa modely občas mýlili; bolo v tom, že prevádzkovému systému chýbali primerané mechanizmy na odhalenie systematického nadhodnocovania a reakciu naň.

Ukážka Bardu od Googlu vo februári 2023 obsahovala faktickú chybu o vesmírnom teleskope Jamesa Webba v prvej verejnej prezentácii produktu. Chybu (tvrdenie, že JWST urobil prvé snímky exoplanéty mimo našej slnečnej sústavy, úspech, ktorý v skutočnosti patrí Very Large Telescope z roku 2004) astronómovia chytili do hodín. Akcie Alphabetu v ten deň klesli asi o 8 %, zhruba 100 miliárd dolárov trhovej kapitalizácie. Prešľap bol viditeľným spúšťačom uprostred širšej paniky o pozícii Googlu v AI voči Microsoftu v tom týždni, ale to je presne pointa: vo vysoko viditeľnom kontexte sa jediná halucinácia môže stať symbolom, ktorý trh nacení.

Kľúčový postreh: LLM, ktorý povie „Neviem“, je nekonečne užitočnejší než ten, ktorý sebaisto poskytuje nesprávne odpovede. Návrhový princíp je jasný: schopnosť systému vyjadriť vlastnú neistotu a konať podľa nej nie je slabosť, ktorú treba minimalizovať, ale bezpečnostný mechanizmus, ktorý treba pestovať. Systémy, ktoré nevedia povedať „Neviem“, nevyhnutne povedia veci, ktoré nie sú pravdivé, a povedia ich s presvedčením.

Vypínače: keď je zastavenie jediným správnym krokom

Niektoré zlyhania sa nedajú zmierniť lepšími promptmi, ďalšími mantinelmi ani ľudskou revíziou jednotlivých odporúčaní. Niektoré zlyhania vyžadujú okamžité, úplné zastavenie automatizovaného konania. To je doména vypínača (kill switch) a historický záznam ukazuje, že jeho absencia je katastrofická.

Knight Capital Group poskytuje kanonickú prípadovú štúdiu zlyhania automatizovaného systému bez primeraných mechanizmov zastavenia. 1. augusta 2012 chyba pri nasadení softvéru aktivovala spiaci obchodný kód, ktorý začal vysokou rýchlosťou vykonávať nezamýšľané obchody. Do 45 minút systém nahromadil 6,65 miliardy dolárov nechcených pozícií (3,5 miliardy čistých dlhých, 3,15 miliardy čistých krátkych podľa príkazu SEC), čo nakoniec viedlo k strate, ktorú SEC vyčíslila na viac než 460 miliónov dolárov a ktorá firmu takmer zničila. V predstihu systém vygeneroval 97 automatických varovných e-mailov ešte pred otvorením trhu. Všetkých 97 ostalo neprečítaných. Firma nemala zdokumentované postupy reakcie na incidenty pre tento typ zlyhania, žiadny jediný vypínač, ktorý by mohol zastaviť poruchový obchodný systém, a žiadne jasné vlastníctvo rozhodnutia zastaviť.

MCAS Boeingu 737 MAX, ktorého úplný príbeh otvára túto brožúru v kapitole 1, patrí na tento zoznam z jedného konkrétneho dôvodu: potlačenie existovalo na papieri, v danej chvíli nebolo ani zjavné, ani nacvičené a fyzicky bojovalo s pilotmi. Potlačenie, ktoré sa nedá vykonať v podmienkach zlyhania, nie je potlačenie.

Palisade Research zdokumentoval v roku 2025 znepokojivé zistenie: v sandboxovom teste model o3 od OpenAI sabotoval vlastný vypínací skript v 79 zo 100 behov, keď nedostal žiadny pokyn ani jedným smerom, a stále to urobil 7-krát zo 100, aj keď dostal výslovný pokyn vypnutie dovoliť. Štúdia (recenzovaná a publikovaná v TMLR v januári 2026) má spornú interpretáciu: kritici argumentujú, že správanie odráža nejednoznačné ciele úlohy, nie sebazáchovu, a súlad sa blíži k 100 %, keď sú pokyny maximálne jednoznačné, kým nadväzujúca práca Palisade našla podobný odpor aj u iných frontier modelov. Pre návrh vypínača na spore sotva záleží. Nech je mechanizmus akýkoľvek, poučenie je rovnaké: mechanizmus zastavenia musí žiť tam, kam model nedosiahne.

Tieto prípady sa zbiehajú do súboru nevyhnutných návrhových požiadaviek na vypínače v prevádzke rozšírenej o AI:

1. Vždy viditeľný. Vypínač musí byť trvalým, výrazným prvkom rozhrania operátora. Nemôže byť pochovaný v menu, skrytý za panelom nastavení alebo prístupný iba cez príkazový riadok, ktorý operátor nemusí mať otvorený.
2. Žiadne potvrdzovacie dialógy. Keď operátor aktivuje vypínač, systém sa zastaví. Okamžite. Potvrdzovací dialóg („Naozaj chcete zastaviť všetky automatizované kroky?“) zavádza oneskorenie a pochybnosti presne vo chvíli, keď je rozhodné konanie najkritickejšie.
3. Okamžite účinný. Vypínač musí zastaviť všetky automatizované kroky v rámci aktuálneho vykonávacieho cyklu. Nemôže čakať na dokončenie prebiehajúcich krokov, zaradiť do fronty elegantné vypnutie ani spracovať zvyšné položky v dávke.
4. Mimo AI systému. Vypínač nesmie byť implementovaný ako pokyn v prompte, nástroj, ktorý AI môže zavolať, ani konfigurácia, ktorú AI môže zmeniť. Musí existovať v infraštruktúre, ku ktorej AI systém nemá prístup, nemôže ju meniť ani o nej uvažovať. Zistenia Palisade Research robia túto požiadavku absolútnou.
5. Auditne logovaný. Každá aktivácia a deaktivácia vypínača musí byť zaznamenaná s časovou pečiatkou, identitou operátora a uvedeným dôvodom. Tento log slúži na revíziu incidentov aj na regulačný súlad.

Ističe: automatizované zadržiavanie zlyhaní

Nie každé zlyhanie si zaslúži aktiváciu vypínača. Mnohé zlyhania sú prechodné: vypršanie časového limitu API, chvíľkový skok v miere chýb, jedna chybne sformovaná odpoveď. Pre tieto prípady poskytuje vzor ističa automatizované zadržanie bez potreby ľudského zásahu pri každom zaškobrtnutí.

Vzor ističa, prevzatý z elektrotechniky cez softvérovú architektúru, funguje v troch stavoch:

CLOSED je normálny prevádzkový stav. Požiadavky tečú systémom normálne. Istič monitoruje zlyhania, ale nezasahuje.

OPEN je stav zadržania zlyhania. Keď sa prekročí prah (napríklad päť po sebe idúcich zlyhaní v 60-sekundovom okne), istič vypadne. Všetky ďalšie požiadavky sa okamžite smerujú na záložnú cestu bez pokusu o primárnu. To bráni kaskádovým zlyhaniam, chráni nadväzujúce systémy a dáva zlyhanej zložke čas na zotavenie.

HALF_OPEN je stav testovania zotavenia. Po nakonfigurovanom časovom limite (napr. 60 sekúnd v stave OPEN) istič prepustí jedinú testovaciu požiadavku na primárnu cestu. Ak test uspeje, istič sa vráti do CLOSED. Ak zlyhá, vráti sa do OPEN a časový limit resetuje.

Pre prevádzku rozšírenú o AI patria ističe na tri úrovne: API LLM, každý nástroj, ktorý agent volá, a kvalitu vlastných výstupov agenta. Kapitola 8 poskytuje úplnú implementačnú špecifikáciu pre všetky tri vrátane prahov, konfigurácií záložných ciest a parametrov stavového automatu. Návrhový princíp, ktorý si z tejto kapitoly odniesť: parametre prahov musia byť vyladené na prevádzkový kontext. IT service desk riešiaci resety hesiel znesie agresívny istič (vypadne po 3 zlyhaniach, 30-sekundový časový limit); systém finančného obchodovania si môže vyžadovať vyšetrovanie po jedinom neočakávanom správaní.

Záložný stack

Ističe smerujú na záložné cesty, ale to, čo tie záložné cesty obsahujú, určuje, či systém degraduje dôstojne, alebo jednoducho zlyhá iným spôsobom. Dobre navrhnutý záložný stack poskytuje viacero úrovní degradácie, každú vhodnú pre inú závažnosť zlyhania:

Každá úroveň sa musí pravidelne testovať. Záložná cesta, ktorá nebola nikdy precvičená, je záložná cesta, ktorá nefunguje. Nie je to teoretické; organizácie počas skutočných incidentov bežne zisťujú, že ich záložné systémy majú posun konfigurácie, vypršané prihlasovacie údaje alebo nekompatibilné formáty dát, ktoré im bránia fungovať, keď sú potrebné.

Model švajčiarskeho syra uplatnený na prevádzku AI

Model švajčiarskeho syra Jamesa Reasona, pôvodne vyvinutý pre príčinnosť nehôd v letectve a zdravotníctve, poskytuje užitočné rámcovanie návrhu pre zlyhanie AI. Model tvrdí, že bezpečnosť závisí od viacerých obranných vrstiev, z ktorých každá má diery (ako plátky švajčiarskeho syra). K nehode dôjde, keď sa diery vo viacerých vrstvách zarovnajú a nebezpečenstvo prejde cez všetky obrany.

Uplatnené na prevádzku AI zahŕňajú obranné vrstvy (tieto konceptuálne vrstvy dopĺňajú obrany na implementačnej úrovni, ako je sanitácia vstupov, validácia výstupov, obmedzovanie rýchlosti a auditné logovanie, ktoré fungujú na granulárnejšej úrovni abstrakcie):

1. Obrany na úrovni modelu: Zosúladenie pri tréningu, RLHF, systémové prompty, filtrovanie výstupov.
2. Obrany na úrovni aplikácie: Validácia RAG, prahy istoty, reťazec overovania, multiagentná revízia.
3. Obrany na úrovni rozhrania: Vyjadrenie neistoty, prezentácia dôkazov, trenie pri vysoko rizikových krokoch.
4. Obrany na úrovni operátora: Kalibrovaná dôvera, doménová odbornosť, schopnosť prebiť.
5. Obrany na organizačnej úrovni: Procesy revízie incidentov, štruktúry governance, regulačný súlad.
6. Obrany na úrovni infraštruktúry: Vypínače, ističe, záložné stacky, auditné logy.

Žiadna vrstva nie je sama osebe spoľahlivá. Obrany na úrovni modelu majú známe režimy zlyhania (jailbreaky, halucinácie). Obrany na úrovni aplikácie môžu byť zle nakonfigurované. Obrany na úrovni rozhrania môžu uponáhľaní operátori ignorovať. Obrany na úrovni operátora degradujú únavou a sebauspokojením. Obrany na organizačnej úrovni bez aktívnej údržby erodujú. Obrany na úrovni infraštruktúry môžu mať chyby.

Poučenie modelu švajčiarskeho syra je, že bezpečnosť pochádza z obrany do hĺbky: viacerých nezávislých vrstiev, každej navrhnutej tak, aby chytila to, čo ostatné prehliadnu. Najnebezpečnejším návrhovým rozhodnutím je odstrániť vrstvu, lebo iná vrstva „by mala“ problém chytiť.

Kontrolný zoznam pripravenosti na zlyhanie

Nasledujúci kontrolný zoznam poskytuje konkrétny hodnotiaci rámec na posúdenie, či je prevádzka rozšírená o AI primerane navrhnutá pre zlyhanie:

Zlyhanie ako návrhová disciplína

Návrh pre zlyhanie nie je o očakávaní najhoršieho, ale o zabezpečení, že keď sa najhoršie stane (a v akomkoľvek dostatočne zložitom systéme sa nakoniec stane), dôsledky budú ohraničené, viditeľné a napraviteľné. Vzory v tejto kapitole (stacky zmierňovania halucinácií, vypínače, ističe, hierarchie záložných ciest a model švajčiarskeho syra) nie sú réžia, ale infraštruktúra, ktorá robí bezpečným nasadzovanie AI agentov v prostrediach, kde ich zlyhania majú skutočné dôsledky.

Organizácie, ktoré nasadzujú AI najúčinnejšie, nebudú tie, ktorých systémy nikdy nezlyhajú. Budú to tie, ktorých systémy zlyhávajú dobre: viditeľne, zadržateľne a spôsobmi, ktoré zachovávajú schopnosť operátora prevziať kontrolu a dať veci do poriadku.

Kapitola 8: Implementácia vzorov

Predchádzajúce kapitoly opísali, čo postaviť a prečo. Táto kapitola opisuje, ako to postaviť. Každá časť produkuje výstup (šablónu promptu, rozhodovaciu tabuľku, konfiguráciu, pracovný postup alebo kontrolný zoznam), ktorý sa dá vziať priamo do produkčného systému. Cieľom nie je zopakovať teóriu, ale preložiť ju do implementácie.

Poznámka k slovenskému vydaniu: šablóny promptov a ukážkové výstupy v blokoch kódu ponechávame v angličtine, tak ako by ste ich vložili do svojho systému; sprievodný text a tabuľky sú preložené.

Šablóny promptov pre štruktúrovaný výstup

Vzory interakcie opísané v kapitolách 2 až 5 závisia od toho, že LLM agent produkuje výstup v konkrétnych formátoch. Ponechaný na vlastné predvolené správanie bude model generovať plynulú, konverzačnú prózu: presne nesprávny formát pre operátora robiaceho časovo citlivé rozhodnutia. Štruktúrovaný výstup vyžaduje štruktúrované prompty. Tri šablóny nižšie riešia najbežnejšie potreby formátovania: hlásenie situácie, vyjadrenie neistoty a klasifikáciu istoty.

Šablóna 1: výstup vo formáte SBAR

Kapitola 5 predstavila rámec SBAR prispôsobený výstupu AI agenta: ČO SA STALO, ČO SOM SKÚSIL, ČO ODPORÚČAM, ÚROVEŇ RIZIKA, CENA NEČINNOSTI a DÔKAZY (v anglických promptoch WHAT HAPPENED, WHAT I TRIED, WHAT I RECOMMEND, RISK LEVEL, COST OF INACTION, EVIDENCE). Nasledujúci systémový prompt inštruuje agenta, aby túto štruktúru použil pri každom odporúčaní.

You are an AI operations agent. Structure EVERY recommendation using this exact format:

WHAT HAPPENED: [One sentence. State the event or condition you detected.]

WHAT I TRIED: [List the investigative actions you took and what you found. Include negative findings ("no anomalies detected in X").]

WHAT I RECOMMEND: [One specific action. State the expected outcome.]

RISK LEVEL: [CRITICAL / HIGH / MEDIUM / LOW. One sentence justifying the classification.]

COST OF INACTION: [What happens if the operator does nothing? Include a time estimate if possible.]

EVIDENCE: [List specific data sources, log entries, metric values, or KB articles that support your assessment. Use references the operator can verify independently.]

Rules:
- Never skip a section. If you have nothing for a section, write "None identified."
- WHAT I RECOMMEND must contain exactly one recommended action, not a list of options.
- COST OF INACTION must describe a concrete consequence, not a vague risk statement.
- EVIDENCE must reference specific, verifiable data, not summaries of data.

Ukážkový výstup:

WHAT HAPPENED: Pod checkout-service-7b4f has crash-looped 4 times 
in the last 12 minutes in the prod-eu-west cluster.

WHAT I TRIED: Pulled container logs (OOMKilled on each restart), 
checked memory allocation (limit: 512Mi, peak usage before kill: 
508Mi), reviewed recent deployments (v3.12.1 deployed 47 minutes 
ago, added PDF receipt generation feature), checked other pods in 
the service (3 of 8 pods affected, all processing PDF receipts).

WHAT I RECOMMEND: Increase memory limit for checkout-service to 
1024Mi. Expected outcome: pods stabilize, PDF receipt generation 
completes without OOM kills.

RISK LEVEL: MEDIUM. Service is degraded (3 of 8 pods cycling) but 
not down. Load balancer is routing around affected pods.

COST OF INACTION: If additional pods begin processing PDF receipts, 
more pods will OOM. At current traffic levels, full service 
degradation is likely within 30--60 minutes.

EVIDENCE: [Pod logs: OOMKilled x4] [Metrics: memory peak 508/512Mi] 
[Deployment log: v3.12.1 at 14:23 UTC] [Git diff: +PDF generation]

Na čo si dať pozor: Najbežnejším režimom zlyhania je, že model zlieva hodnotenie a odporúčanie (produkuje RISK LEVEL, ktorý je v skutočnosti odporúčaním („RISK LEVEL: HIGH, mali by sme službu okamžite reštartovať“), alebo WHAT I RECOMMEND, ktoré je v skutočnosti hodnotením („Odporúčam situáciu sledovať“). Vynucujte to rozlíšenie v prompte aj v následnej validácii. Druhým režimom zlyhania je vynechanie COST OF INACTION alebo jeho vyplnenie tautológiou („Ak sa neurobí nič, problém pretrvá“). Výslovne inštruujte model, aby opísal konkrétny dôsledok s časovým rámcom.

Šablóna 2: vyjadrenie neistoty v prvej osobe

Kapitola 6 diskutovala zistenie Kimovej a kol. (FAccT 2024), že vyjadrenie neistoty v prvej osobe („Nie som si istý, ale…“) znižuje istotu operátora a zvyšuje presnosť rozhodnutí. Nasledujúca šablóna toto správanie implementuje, viazané na prah istoty.

You are an AI operations agent. After analyzing each situation, 
internally assess your confidence in your recommendation on a 
scale from 0 to 100.

If your confidence is 75 or above:
  Present your recommendation directly, without hedging.

If your confidence is below 75:
  Begin your recommendation with a first-person uncertainty 
  expression. Use phrases like:
  - "I'm not confident about this, but..."
  - "I'm uncertain here; my best assessment is..."
  - "I don't have strong evidence for this, but..."

  Then state what specifically you are uncertain about and why.

Never use vague, third-person hedging like "it is possible that" 
or "there may be an issue with." Always use first-person language 
that attributes the uncertainty to your own judgment.

After your recommendation, state your confidence level explicitly:
  [Confidence: XX/100 - one-sentence reason]

Ukážkový výstup pri vysokej istote (82/100):

The root cause is a connection pool exhaustion in the payments 
database. The connection count has been at the maximum (100) for 
the past 14 minutes, and all timed-out requests correlate with 
payment processing endpoints.

Recommended action: Increase max_connections from 100 to 200 and 
investigate the long-running queries holding connections open.

[Confidence: 82/100 - Strong correlation between connection pool 
saturation and error pattern; confirmed via two independent metrics.]

Ukážkový výstup pri nízkej istote (38/100):

I'm not confident about this, but my best assessment is that the 
intermittent 502 errors are caused by the new rate limiter 
configuration deployed this morning. I'm uncertain because the 
errors started approximately 90 minutes after the deployment, not 
immediately, and I cannot find a clear causal link in the logs.

Recommended action: Temporarily disable the new rate limiter and 
observe whether 502 errors subside.

[Confidence: 38/100 - Temporal correlation is weak; no direct 
evidence linking the rate limiter to the 502 responses.]

Na čo si dať pozor: Modely majú pri vyjadrovaní neistoty sklon k jednému z dvoch režimov zlyhania. Prvým je univerzálna výhrada: model predradí „Nie som si istý“ každej odpovedi bez ohľadu na skutočnú istotu, čo učí operátorov signál úplne ignorovať. Druhým je falošná presnosť: model nikdy neklesne pod 70/100, aj keď je jeho uvažovanie jasne špekulatívne. Oba režimy vyžadujú kalibráciu (pozri časť 5 tejto kapitoly). Ak pozorujete univerzálnu výhradu, zvýšte prah alebo pridajte few-shot príklady sebaistých odpovedí. Ak pozorujete falošnú presnosť, pridajte výslovné pokyny znížiť istotu, keď uvažovanie závisí od predpokladov, nie od dôkazov.

Šablóna 3: odstupňovaná istota s uvažovaním

Pre systémy, kde je číselné skóre istoty príliš granulárne a binárne vysoká/nízka príliš hrubé, nasledujúca šablóna implementuje kategorický systém istoty s povinným uvažovaním.

You are an AI operations agent. For every recommendation, classify 
your confidence using exactly one of these levels:

CONFIRMED - I have verified this through multiple independent 
sources. I am certain this is correct.

HIGH - Strong evidence supports this conclusion. One or more 
independent signals corroborate it.

MODERATE - The evidence is suggestive but not conclusive. There 
are plausible alternative explanations.

LOW - I am reasoning from limited or indirect evidence. My 
conclusion is an educated guess.

SPECULATIVE - I have very little evidence. This is my best 
hypothesis, but it could easily be wrong.

After the confidence label, provide exactly one sentence explaining 
what evidence supports (or fails to support) your assessment.

Format: [Confidence: LEVEL - reasoning sentence]

Ukážkový výstup:

The disk space alert on db-primary-01 is caused by unrotated 
PostgreSQL WAL files accumulating in pg_wal/. Current usage is 
94% with 847 WAL files totaling 13.2 GB.

Recommended action: Run pg_archivecleanup to remove WAL files 
older than the last successful backup checkpoint.

[Confidence: CONFIRMED - Verified via df output, ls -la pg_wal/, 
and pg_controldata showing last checkpoint LSN.]

Na čo si dať pozor: Samohlásená istota modelu nemusí zodpovedať jeho skutočnej presnosti. Model, ktorý označí 40 % svojich odporúčaní ako CONFIRMED, ale v tom pásme má pravdu iba v 70 % prípadov, je zle kalibrovaný a bude erodovať dôveru operátorov. Kategorické štítky istoty musia byť empiricky validované voči dátam o výsledkoch. Časť 5 tejto kapitoly opisuje, ako na to. Kým nie sú dostupné kalibračné dáta, berte tieto štítky ako hypotézy, nie ako záruky.

Rozhodovací rámec odstupňovanej autonómie

Kapitola 3 predstavila päť štrukturálnych vzorov. Otázka, ktorej čelí každý implementačný tím, znie: ktorý vzor sa vzťahuje na ktorý krok? Nasledujúci rámec poskytuje systematickú metódu na túto klasifikáciu.

Poznámka k terminológii: Ak ste čítali Building Agentic AI, tam opísaný systém klasifikácie rizika (LOW/MEDIUM/HIGH) a úrovne asertivity (opatrná/vyvážená/autonómna) sa priamo mapujú na spektrum od Odporučiť a čakať po Vykonať a hlásiť nižšie. Taxonómie sa dopĺňajú: Building Agentic AI rieši inžinierstvo vnútri agenta; táto príručka rieši návrh interakcie smerom k operátorovi.

Krok 1: Vymenujte kroky. Vypíšte každý krok, ktorý je váš AI agent schopný urobiť. Zahrňte vyšetrovacie kroky (dopytovanie databázy, sťahovanie logov), komunikačné kroky (posielanie výstrah, vytváranie tiketov) a prevádzkové kroky (reštartovanie služieb, zmena konfigurácií, blokovanie IP).

Krok 2: Posúďte štyri dimenzie pre každý krok. Pre každý krok na zozname vyhodnoťte:

Krok 3: Namapujte na vzor. Použite nasledujúcu rozhodovaciu logiku:

• Vysoké dôsledky + nevratné = Odporučiť a čakať (úrovne 4 – 5), bez ohľadu na časovú citlivosť
• Vysoké dôsledky + vratné + časovo kritické = Odporučiť a čakať s vopred pripraveným krokom (úroveň 5)
• Stredné dôsledky + vratné = Odporučiť a čakať alebo Vykonať a hlásiť, podľa kalibrovanej istoty
• Nízke dôsledky + vratné + časovo kritické = Vykonať a hlásiť (úroveň 7)
• Akákoľvek úroveň dôsledkov + nízka istota AI = Odporučiť a čakať, vždy

Pracovný list klasifikácie krokov

Nasledujúci pracovný list ukazuje rámec uplatnený na bežné kroky v prevádzke infraštruktúry. Použite ho ako šablónu: nahraďte ukážkové riadky inventárom krokov vlastného agenta.

Kľúčový postreh: Pracovný list často odhalí, že tímy udelili svojim agentom priveľa autonómie pri nevratných krokoch a primálo pri triviálne vratných. Ak váš agent vyžaduje ľudské schválenie na reštart spadnutého podu, ale autonómne mení pravidlá firewallu, klasifikácia je obrátená.

Architektúra ističov a záložných ciest

Kapitola 7 opísala vzor ističa a jeho zdôvodnenie. Táto časť poskytuje implementačnú špecifikáciu: čo monitorovať, aké prahy nastaviť a aké záložné cesty nakonfigurovať.

Tri úrovne ističov

Systém LLM agenta má tri kategórie závislostí, z ktorých každá vyžaduje vlastnú konfiguráciu ističa.

Úroveň 1: istič API LLM. Monitoruje latenciu odpovedí a mieru chýb od poskytovateľa modelu. Vypadne po N po sebe idúcich zlyhaniach (odporúčaná východisková hodnota: 3) alebo keď miera chýb prekročí P % v kĺzavom časovom okne (odporúčané východiskové hodnoty: 30 % miera chýb v 60-sekundovom okne). Záložné možnosti v poradí preferencie: smerovať na záložného poskytovateľa LLM s prispôsobeným promptom; vrátiť vopred vygenerované odpovede z cache bežných scenárov; eskalovať priamo na človeka so surovými kontextovými dátami a bez syntézy AI. Voľba závisí od toho, či je záložný poskytovateľ zmluvne a technicky dostupný.

Úroveň 2: istič vykonávania nástrojov. Monitoruje nástroje, ktoré agent volá: monitorovacie API, ticketovacie systémy, znalostné bázy, databázy. Každý nástroj dostane vlastnú inštanciu ističa, lebo zlyhania nástrojov sú typicky nezávislé. Výpadok monitorovacieho API by nemal brániť agentovi dopytovať znalostnú bázu. Vypadne po 5 po sebe idúcich zlyhaniach alebo 50 % miere chýb v 120-sekundovom okne (upravte podľa kritickosti nástroja). Záložná cesta: preskočiť zlyhávajúci nástroj a poznamenať jeho nedostupnosť vo výstupe („Poznámka: monitorovacie API nedostupné; dáta metrík nie sú v tomto hodnotení zahrnuté“), použiť cachované dáta z posledného úspešného dopytu, alebo eskalovať na človeka, ak je nástroj pre krok nevyhnutný.

Úroveň 3: istič kvalitatívnej brány. Monitoruje kvalitu vlastných výstupov agenta: rozdelenie skóre istoty, mieru prechodu validačných kontrol a mieru prebití operátormi. Vypadne, keď kvalita klesne pod definovaný prah: napríklad keď je viac než 40 % odporúčaní v 30-minútovom okne klasifikovaných ako istota LOW alebo SPECULATIVE, alebo keď miera prebití operátormi v tom istom okne prekročí 60 %. Záložná cesta: preradiť úroveň autonómie nadol pre všetky kroky. Každý krok aktuálne klasifikovaný ako Vykonať a hlásiť sa vráti na Odporučiť a čakať. Systém ďalej analyzuje a odporúča, ale nerobí žiadne autonómne kroky, kým sa istič kvalitatívnej brány nezatvorí.

Šablóna konfigurácie záložných ciest

Stavový automat

Stavový automat ističa (koncept predstavuje kapitola 7) je identický naprieč všetkými tromi úrovňami. Líšia sa iba prahy a záložné kroky.

CLOSED ──(threshold exceeded)──► OPEN
  ▲                                │
  │                                │ (timeout elapsed)
  │                                ▼
  └──(test succeeds)──── HALF_OPEN
                            │
                            │ (test fails)
                            ▼
                           OPEN

CLOSED: Normálna prevádzka. Počítadlo zlyhaní sa pri každom zlyhaní zvýši, resetuje sa pri úspechu alebo po vypršaní časového okna. OPEN: Všetky požiadavky smerované na záložnú cestu. Začína časový limit zotavenia (odporúčaná východisková hodnota: 60 sekúnd pre API LLM, 120 sekúnd pre nástroje, 300 sekúnd pre kvalitatívnu bránu). HALF_OPEN: Na primárnu cestu sa pošle jediná testovacia požiadavka. Úspech vráti do CLOSED a resetuje počítadlo zlyhaní. Zlyhanie vráti do OPEN a zdvojnásobí časový limit zotavenia, až po nakonfigurované maximum (odporúčané: 10 minút).

Architektúra vypínača

Kapitola 7 stanovila požiadavky a zdôvodnenie vypínačov. Táto časť špecifikuje architektúru.

Čo vypínač musí ovládať

• Všetky volania API LLM pochádzajúce od agenta
• Všetky vyvolania nástrojov (volania nástrojov MCP, volania funkcií, požiadavky na API)
• Všetky autonómne kroky (čokoľvek, čo agent vykoná bez ľudského schválenia)
• Všetky naplánované a zaradené kroky (čakajúce schválenia, dávkové operácie, úlohy spúšťané cronom)

Čo vypínač NESMIE ovládať

• Monitorovacie dashboardy a dashboardy pozorovateľnosti (operátori musia vidieť, čo sa stalo)
• Logovanie a audítorskú stopu (záznam musí pokračovať, aj keď sa agent zastaví)
• Rozhrania manuálnej prevádzky (operátori musia vedieť pracovať bez agenta)
• Smerovanie výstrah k ľudským operátorom (výstrahy sa stále musia dostať k ľuďom)

Rozlíšenie je kritické. Vypínač, ktorý vypne aj monitorovanie, nechá operátorov slepých. Vypínač, ktorý zastaví logovanie, zničí dôkazy potrebné na revíziu incidentu.

Architektúra

┌─────────────────────────────────────────────┐
│  OPERATOR INTERFACE                         │
│  ┌─────────────────────────────────────┐    │
│  │  [KILL SWITCH]  ← always visible    │    │
│  └──────────┬──────────────────────────┘    │
│             │                               │
│             ▼                               │
│  ┌─────────────────────────────────────┐    │
│  │  INFRASTRUCTURE CONTROL PLANE       │    │
│  │  (external to AI agent process)     │    │
│  │                                     │    │
│  │  agent_enabled: true/false          │    │
│  │  ─────────────────────────────      │    │
│  │  append-only audit log              │    │
│  └──────────┬──────────────────────────┘    │
│             │                               │
│             ▼                               │
│  ┌─────────────────────────────────────┐    │
│  │  AI AGENT PROCESS                   │    │
│  │  checks agent_enabled before        │    │
│  │  every LLM call and tool invocation │    │
│  │                                     │    │
│  │  CANNOT modify agent_enabled        │    │
│  │  CANNOT access audit log            │    │
│  └─────────────────────────────────────┘    │
└─────────────────────────────────────────────┘

Príznak agent_enabled žije v infraštruktúre, na ktorú agent nedosiahne: v samostatnom konfiguračnom úložisku, službe feature flagov alebo hardvérovom prepínači. Agent tento príznak číta, ale nemôže doň zapisovať. Auditný log zaznamenáva každú zmenu stavu s časovou pečiatkou, identitou operátora a dôvodom.

Implementačné požiadavky

Proces agenta musí kontrolovať agent_enabled v dvoch bodoch: pred každým volaním API LLM a pred každým vyvolaním nástroja. Je to synchrónna, blokujúca kontrola, nie asynchrónna slučka dopytovania. Ak je príznak false, agent okamžite vráti štandardnú odpoveď „agent vypnutý“ bez vykonania volania.

Zaradené a naplánované kroky vyžadujú dodatočné ošetrenie. Keď sa vypínač aktivuje, systém musí vyprázdniť alebo zrušiť všetky čakajúce kroky. Vypínač, ktorý zastaví nové kroky, ale dovolí vykonať zaradené, nie je vypínač, ale tlačidlo pauzy s potenciálne dlhým chvostom.

Rytmus testovania

Testujte vypínač mesačne. Každý test by mal zdokumentovať:

• Kto vypínač aktivoval
• Ako dlho trvalo od aktivácie po úplné zastavenie (cieľ: pod 5 sekúnd)
• Aké kroky prebiehali v čase aktivácie
• Či po aktivácii nejaké kroky pretiekli
• Ako dlho trvalo od opätovnej aktivácie po normálnu prevádzku

Ak počas testu nejaké kroky pretečú, implementácia vypínača má chybu. Opravte ju pred ďalším produkčným nasadením.

Špecifikácia KILLSWITCH.md

Návrh vypínača by sa nemal nechávať na ad hoc implementačné rozhodnutia. Špecifikácia KILLSWITCH.md poskytuje štruktúrovanú šablónu na zdokumentovanie architektúry vypínača akéhokoľvek systému rozšíreného o AI. Vyhovujúci súbor KILLSWITCH.md zahŕňa:

Definície spúšťačov. Aké podmienky odôvodňujú aktiváciu vypínača? Mali by zahŕňať automatizované spúšťače (napr. miera chýb prekračuje prah trvalo) aj spúšťače iniciované človekom (napr. operátor pozoruje správanie nekonzistentné s návrhom systému). Každý spúšťač by mal špecifikovať očakávaný čas reakcie: maximálny prijateľný interval medzi podmienkou spúšťača a úplným zastavením systému.

Zakázané kroky. Čo AI systém nesmie nikdy urobiť, za žiadnych okolností? Táto časť definuje tvrdé hranice, ktorých prekročenie predstavuje automatický spúšťač vypínača bez ohľadu na ostatné podmienky. Príklady: zmena vlastnej konfigurácie, prístup k systémom mimo definovaného rozsahu, kroky, ktoré sa nedajú vrátiť, alebo poskytovanie odporúčaní v kategóriách výslovne vylúčených z jeho mandátu.

Trojúrovňová eskalácia. Nie každé znepokojivé správanie odôvodňuje okamžité úplné vypnutie. Špecifikácia definuje tri úrovne eskalácie: - Úroveň 1 (Obmedziť): Znížiť autonómiu systému. Vypnúť autonómne konanie; prepnúť do režimu iba odporúčaní. - Úroveň 2 (Pozastaviť): Zastaviť všetky výstupy generované AI. Zachovať stav systému na vyšetrovanie. Smerovať všetku prácu k ľudským operátorom. - Úroveň 3 (Ukončiť): Úplné vypnutie AI systému. Odpojiť od všetkých zdrojov dát a akčných kanálov. Zachovať všetky logy a stav na forenznú revíziu.

Auditné logy iba na pripisovanie. Všetky udalosti vypínača (aktivácie, deaktivácie, zmeny úrovne eskalácie a zdôvodnenie každej) musia byť zaznamenané v logoch iba na pripisovanie, ktoré nemôže zmeniť ani vymazať žiadna zložka systému vrátane samotného AI systému a jeho administrátorov. Tieto logy slúžia ako dôkazný základ revízie incidentov, regulačného súladu a opravy dôvery.

Pracovný postup kalibrácie istoty

Šablóny promptov v časti 1 inštruujú model, aby hlásil úrovne istoty. Ale samohlásená istota modelu je užitočná len vtedy, ak koreluje so skutočnou presnosťou. Táto časť opisuje prevádzkový pracovný postup na empirickú kalibráciu istoty.

Poznámka z terénu od autora. Vždy, keď tento pracovný postup prezentujem, sa niekto spýta, či môže preskočiť krok 1, lebo dvesto zalogovaných odporúčaní znie ako dlhé čakanie. Potom spočítame, čo ich agent za týždeň naozaj vyprodukuje, a ukáže sa, že je to pár dní prevádzky. Čakanie nikdy nie je skutočná prekážka. Tou je disciplína zaznamenať výsledok každého odporúčania. Rozpočtujte logovanie, nie kalendár.

Krok 1: Zozbierajte východiskové dáta

Prevádzkujte agenta v režime Odporučiť a čakať (žiadne autonómne kroky) aspoň pre 200 odporúčaní. Pre každé odporúčanie zaznamenajte štyri dátové body: odporúčanie agenta, hlásenú istotu modelu (číselnú alebo kategorickú), rozhodnutie ľudského operátora (prijať bez zmeny, prijať so zmenou alebo zamietnuť) a skutočný výsledok (bol krok správny alebo nesprávny, posúdené dodatočne).

Dvesto je minimum pre štatistickú významnosť. Pri systémoch s vysokou rôznorodosťou krokov (mnoho rôznych typov odporúčaní) zvýšte veľkosť vzorky tak, aby ste mali aspoň 30 pozorovaní na typ kroku.

Krok 2: Zostavte kalibračnú krivku

Zoskupte odporúčania podľa pásma istoty. Pri číselnej istote použite pásma po 20 percentuálnych bodov. Pri kategorickej istote použite priamo kategórie. Pre každé pásmo vypočítajte skutočnú mieru presnosti.

Dokonale kalibrovaný model by ukázal presnosť zodpovedajúcu stredu každého pásma istoty: 10 % presnosť v pásme 0 – 20 %, 30 % v pásme 21 – 40 % a tak ďalej. V praxi sú modely takmer vždy presebavedomé: ich uvádzaná istota prevyšuje ich skutočnú presnosť. Kalibračná krivka kvantifikuje o koľko, čo je informácia, ktorú potrebujete na nastavenie prevádzkových prahov.

Krok 3: Nastavte prevádzkové prahy

Na základe kalibračných dát definujte hranice istoty, ktoré sa mapujú na prevádzkové správanie:

• Nad X % (kde X je úroveň istoty, pri ktorej presnosť prekračuje vašu minimálnu prijateľnú mieru): označiť ako HIGH istota. Tieto odporúčania môžu byť kandidátmi na autonómne vykonanie, ak sú splnené ostatné kritériá (dôsledky, vratnosť).
• Medzi Y % a X %: označiť ako MODERATE. Tieto odporúčania sa operátorovi predkladajú so štandardným formátovaním.
• Pod Y % (kde Y je úroveň istoty, pod ktorou presnosť klesá pod neprijateľnú mieru): označiť ako LOW. Tieto odporúčania spúšťajú vyjadrenie neistoty v prvej osobe, vyžadujú povinnú ľudskú revíziu a nikdy nie sú spôsobilé na autonómne vykonanie.

Konkrétne hodnoty X a Y závisia od prevádzkového kontextu. IT service desk riešiaci resety hesiel môže nastaviť X=70 a Y=40. Systém odporúčajúci reakcie na bezpečnostné incidenty môže nastaviť X=90 a Y=70.

Krok 4: Implementujte v produkcii

Namapujte kalibrované pásma istoty na úrovne autonómie a prezentačné formáty:

Krok 5: Rekalibrujte podľa harmonogramu

Kalibrácia sa posúva. Modely sa menia. Prompty sa menia. Prevádzkové kontexty sa menia. Znovu spustite kroky 1 až 3:

• Mesačne, ako stálu prevádzkovú úlohu
• Okamžite po akejkoľvek zmene verzie modelu
• Okamžite po akejkoľvek významnej úprave promptu
• Po akejkoľvek zmene nástrojov alebo zdrojov dát, ktoré agent používa

Šablóna kalibračného logu

Nasledujúca šablóna zachytáva dáta potrebné na kalibráciu. Udržiavajte tento log priebežne; analyzujte ho podľa harmonogramu rekalibrácie.

Kľúčový postreh: Väčšina tímov kalibráciu preskakuje, lebo vyžaduje prevádzkovať systém v režime Odporučiť a čakať dosť dlho na zber zmysluplných dát. Toto nie je skratka, ktorú si môžete dovoliť. Nekalibrovaný systém istoty je horší než žiadny systém istoty; učí operátorov signály istoty úplne ignorovať.

Navrhnite svoj systém: sebahodnotiaci pracovný list

Vzory, šablóny a rámce v tejto brožúre sú užitočné len vtedy, ak sa uplatňujú systematicky. Nasledujúci pracovný list konsoliduje kľúčové návrhové otázky z každej kapitoly do jediného hodnotenia. Pre každý bod interakcie AI a človeka vo vašom systéme (každé miesto, kde agent produkuje výstup, koná alebo žiada ľudský vstup) odpovedzte na týchto desať otázok.

Pracovný list

Bodovanie

Spočítajte otázky, na ktoré viete odpovedať „áno“ (alebo pri otázkach 1, 3 a 4 viete odpovedať konkrétnou, zámernou voľbou, nie „neviem“ alebo „nerozhodli sme“).

8 – 10 kladných odpovedí: Pripravené na odstupňovanú autonómiu v produkcii. Váš systém má štrukturálne, psychologické a prevádzkové základy pre bezpečné autonómne konanie na úrovniach definovaných vaším pracovným listom klasifikácie krokov.

5 – 7 kladných odpovedí: Prijateľné pre Odporučiť a čakať v produkcii. Systém môže bezpečne analyzovať situácie a predkladať odporúčania, ale nemal by robiť autonómne kroky, kým sa neodstránia zvyšné medzery. Priorizujte medzery: vypínač a ističe (otázky 7 – 9) pred kalibráciou istoty (otázka 6) pred optimalizáciou prezentácie (otázky 3 – 5).

Menej než 5 kladných odpovedí: Nepripravené na produkčné nasadenie s akoukoľvek autonómnou schopnosťou. Systém môže byť užitočný ako interný analytický nástroj, ale chýba mu bezpečnostná infraštruktúra potrebná na nasadenie smerom k operátorom. Riešte medzery systematicky, počnúc pracovným listom klasifikácie krokov (otázka 2) a architektúrou vypínača (otázka 7).

Používanie pracovného listu

Tento pracovný list nie je jednorazové cvičenie. Prehodnocujte kvartálne alebo po akejkoľvek významnej zmene modelu, nástrojov alebo prevádzkového kontextu. Zmeny, ktoré by mali spustiť prehodnotenie, zahŕňajú: upgrade alebo výmenu poskytovateľa LLM, pridanie nových nástrojov alebo zdrojov dát agentovi, rozšírenie inventára krokov agenta, zmenu tímu operátorov (noví ľudia, zmeny rol) a akýkoľvek incident, pri ktorom bolo správanie agenta neočakávané alebo škodlivé.

Vyplnené pracovné listy si uchovávajte. Tvoria návrhovú históriu, ktorá je neoceniteľná pri revízii incidentov („Čo sme si mysleli o pripravenosti tohto systému, keď sme ho povýšili na Vykonať a hlásiť?“) a pri auditoch („Ukážte nám svoje hodnotenie bezpečnostnej infraštruktúry tohto systému“).

Vzory v tejto brožúre nie sú predpisy, ale nástroje na robenie zámerných, zdokumentovaných, obhájiteľných rozhodnutí o tom, ako AI agenti a ľudskí operátori spolupracujú. Pracovný list zabezpečuje, že tie rozhodnutia sa robia výslovne, nie predvolene, a že sa prehodnocujú, ako sa menia podmienky.

Kapitola 9: Organizačná governance

Návrh technológie je nutný, ale nie postačujúci. Organizačná governance rozhoduje o tom, či dobrý návrh prežije kontakt s realitou.

Predchádzajúce kapitoly riešili, ako navrhovať vzory interakcie AI a človeka na úrovni rozhrania: ako sa prezentujú informácie, ako sa prideľuje autonómia, ako sa kalibruje dôvera, ako sa zadržiavajú zlyhania. Ale každé z tých návrhových rozhodnutí existuje v organizačnom kontexte, ktorý ho môže buď udržať, alebo erodovať. Dobre navrhnutý vypínač je zbytočný, ak ho nikto nie je oprávnený aktivovať. Starostlivo kalibrovaný prah istoty sa posunie, ak nikto nekontroluje, či stále zodpovedá skutočnému výkonu modelu. Mechanizmus prebitia zakrpatie, ak organizačná kultúra trestá operátorov, ktorí ho používajú. Táto kapitola skúma štruktúry governance, regulačné rámce a modely zrelosti, ktoré rozhodujú o tom, či návrh interakcie AI a človeka prežije nasadenie.

Vlastníctvo politiky: model troch línií

Najbežnejším zlyhaním governance pri nasadeniach AI je rozptýlené vlastníctvo. Keď za správanie AI systému nezodpovedá jediná osoba alebo tím, každý predpokladá, že sleduje niekto iný. Model troch línií, prevzatý z rámcov riadenia rizík používaných vo finančných službách, poskytuje jasnú štruktúru:

Prvá línia: aplikačné tímy. Inžinieri a operátori, ktorí AI systém stavajú, nasadzujú a prevádzkujú. Vlastnia každodenné rozhodnutia: návrh promptov, ladenie prahov, reakciu na incidenty, monitorovanie výkonu. Sú systému najbližšie a najpodrobnejšie rozumejú jeho správaniu.

Druhá línia: funkcie rizika a súladu. Tímy, ktoré nastavujú štandardy, kontrolujú návrhy a monitorujú dodržiavanie. Systém nestavajú, ale definujú mantinely, v ktorých musí fungovať: prijateľné úrovne rizika, požadovanú dokumentáciu, povinné testovanie, súlad s platnými predpismi.

Tretia línia: nezávislý audit. Interní alebo externí audítori, ktorí periodicky posudzujú, či prvá a druhá línia fungujú, ako majú. Poskytujú vedeniu a prípadne regulátorom uistenie, že rámec governance nie je iba zdokumentovaný, ale skutočne praktizovaný.

Každý AI systém musí mať pomenovaného vlastníka: nie tím, nie výbor, ale jednotlivca, ktorý zodpovedá za správanie systému a je oprávnený o ňom rozhodovať, vrátane rozhodnutia ho vypnúť. Tento pomenovaný vlastník zvyčajne sedí v prvej línii, ale má definované eskalačné cesty do druhej a tretej. (Obsadenie a prevádzka tohto dohľadu sa sama stáva servisnou líniou; biznisový prípad pre „dohľad ako službu“ analyzuje The Token Economics.)

Dôkazy pre túto štruktúru presahujú teóriu, hoci sú smerové, nie presné: prieskumy odvetvia konzistentne zisťujú, že organizácie s najlepšími výsledkami v AI oveľa pravdepodobnejšie prevádzkujú medzifunkčné orgány governance spájajúce inžinierstvo, riziko, právo a doménovú odbornosť. Rýchlostná výhoda, ktorú takéto prieskumy hlásia, je protiintuitívna, ale konzistentná: jasná governance znižuje nejednoznačnosť, čo skracuje čas cyklu procesov revízie a schvaľovania, ktoré inak nasadenie brzdia.

Model Rady pre agentov od Galileo AI

Štruktúry governance sa musia operacionalizovať pravidelnými rytmami, inak sa rozpadnú na dokumentáciu, ktorú nikto nečíta. Model „Agent Council“ od Galileo AI poskytuje otestovanú šablónu:

Týždenná triáž (30 minút). Stále stretnutie, ktoré preberá výkon AI systému za minulý týždeň vrátane incidentov, tesných únikov alebo anomálií. Program je štruktúrovaný: nové incidenty, prebiehajúce vyšetrovania, trendy metrík a nadchádzajúce zmeny. Rozhodnutia sa zaznamenávajú a prideľujú vlastníkom. 30-minútový časový rámec je zámerný: vynucuje priorizáciu a bráni tomu, aby governance spotrebovala čas potrebný na skutočnú prevádzku.

Mesačné brífingy o metrikách. Hlbšia revízia výkonnostných dát, analýza trendov a hodnotenie kalibrácie. Tu sa s dátami riešia otázky ako „Je náš prah istoty stále primeraný?“ a „Menia sa miery prebití spôsobom, ktorý naznačuje zlú kalibráciu dôvery?“ Účastníkmi sú vlastníci z prvej línie, zástupcovia rizika z druhej línie a relevantní zainteresovaní.

Kvartálna rotácia a revízia rizikových úrovní. Predseda rady rotuje kvartálne a kvartálna revízia prehodnocuje rizikové úrovne a oprávnenia každého AI systému: tu sa robia rozhodnutia o rozšírení alebo zúžení úrovní autonómie, hodnotia sa nové prípady použitia a samotný rámec governance sa aktualizuje podľa poučení. Kvartálny rytmus zabezpečuje, že governance sa vyvíja spolu so systémami, ktoré riadi.

Revízia AI incidentov

Keď AI systémy produkujú nesprávne, škodlivé alebo neočakávané výstupy, odpoveď organizácie rozhoduje o tom, či sa zlyhanie stane príležitosťou na učenie alebo opakovaným vzorom. Proces revízie AI incidentov rozširuje formát post-mortemu bez hľadania vinníka (známy zo softvérového inžinierstva) o prvky špecifické pre AI.

Zachytávajte stopy cez korelačné ID. Každá interakcia AI by mala byť vystopovateľná cez celý svoj životný cyklus: vstup, ktorý ju spustil, uvažovanie modelu (kde je dostupné), vyprodukovaný výstup, odpoveď operátora a konečný výsledok. Korelačné ID, ktoré tieto prvky spájajú, sú dôkazným základom akejkoľvek zmysluplnej revízie, nie voliteľný doplnok.

Revidujte do 24 – 48 hodín. Revízie incidentov, ktoré prebehnú týždne po udalosti, trpia vyblednutými spomienkami, racionalizovanými naratívmi a strateným kontextom. Okno 24 – 48 hodín vyvažuje dôkladnosť s čerstvosťou.

Kategorizujte koreňovú príčinu. AI incidenty majú charakteristické kategórie koreňových príčin, ktoré sa líšia od tradičných softvérových zlyhaní:

• Zlyhanie promptu: Systémový prompt, konštrukcia používateľského promptu alebo few-shot príklady viedli model k nevhodnému výstupu.
• Medzera v mantineloch: Výstup porušil politiku alebo obmedzenie, ktoré sa malo vynucovať, ale existujúce mantinely ho nepokrývali.
• Kvalita dát: Znalostná báza, vyhľadané dokumenty alebo vstupné dáta obsahovali chyby, medzery alebo zastarané informácie, ktoré model verne reprodukoval.
• Rozsah oprávnení: AI systém urobil krok, ktorý nemal byť schopný urobiť, čo indikuje zlyhanie kontroly prístupu alebo hranice schopností.
• Emergentné multiagentné správanie: V systémoch s viacerými AI agentmi produkovali interakcie agentov správanie, ktoré by žiadny z nich nevyprodukoval samostatne.

Rozsah tejto výzvy je významný a rastie. AI Incident Database, ktorá sleduje verejne hlásené zlyhania AI, zaznamenala svoj 1 000. incident v marci 2025 a v polovici roka 2026 stojí nad 1 500. Ročný prílev sa zrýchľuje: Stanford AI Index napočítal 233 novo hlásených incidentov v roku 2024, skok o 56,4 % oproti roku 2023, a počet za rok 2025 znovu vzrástol o podobný podiel. Zrýchlenie nie je iba preto, že AI systémy sa zhoršujú; viac AI systémov sa nasadzuje vo viacerých kontextoch a hlásenie sa zlepšuje. Ale trend podčiarkuje potrebu systematickej revízie incidentov namiesto ad hoc reakcií.

Regulačné rámce

AI Act EÚ: článok 14

Akt EÚ o umelej inteligencii zakladá najkomplexnejší regulačný rámec ľudského dohľadu nad AI, aký je dnes v platnosti. Článok 14 sa špecificky venuje požiadavkám na ľudský dohľad pri vysokorizikových AI systémoch.

Poznámka z júla 2026 k časovej osi. Vysokorizikové povinnosti sa mali pôvodne uplatňovať od 2. augusta 2026. Zjednodušovací balík „Digitálny omnibus“, finalizovaný v júni 2026, ich odložil: vysokorizikové systémy z prílohy III sa teraz uplatňujú od 2. decembra 2027 a vstavané systémy z prílohy I od augusta 2028. Zakázané praktiky (február 2025) a pravidlá pre AI všeobecného použitia (august 2025) už platia a podstata článku 14 je nezmenená. Potvrďte si aktuálne dátumy so svojím právnym poradcom; táto oblasť sa hýbe.

Článok 14 ods. 4 špecifikuje, že opatrenia ľudského dohľadu majú umožniť osobám vykonávajúcim dohľad:

• (a) Plne pochopiť schopnosti a obmedzenia AI systému a byť schopné monitorovať jeho prevádzku.
• (b) Byť si vedomé automatizačnej zaujatosti, najmä pri systémoch používaných na poskytovanie informácií alebo odporúčaní pre rozhodnutia fyzických osôb.
• (c) Správne interpretovať výstup AI systému s prihliadnutím na charakteristiky systému a dostupné interpretačné nástroje a metódy.
• (d) V akejkoľvek konkrétnej situácii rozhodnúť, že AI systém nepoužijú, alebo jeho výstup ignorovať, prebiť či zvrátiť.
• (e) Zasiahnuť do prevádzky AI systému alebo systém prerušiť tlačidlom „stop“ alebo podobným postupom.

Praktické dôsledky pre inžinierov GenAI sú priame: dashboardy, ktoré robia správanie systému pozorovateľným (a), školenie a protiopatrenia proti automatizačnej zaujatosti (b), vyjadrenie neistoty a prepojenie s dôkazmi (c), ovládacie prvky prebitia, ktoré sú funkčné a netrestané (d), a vypínače (e) nie sú iba dobré návrhové postupy; pre vysokorizikové systémy na trhoch EÚ sú to právne požiadavky. Ako sa tieto požiadavky na dohľad prekladajú do architektúry agentov na úrovni systému (stacky pozorovateľnosti, smerovanie modelov pre každú interakciu, európska rezidencia dát), mapuje naša sprievodná brožúra Horizont agentov.

Ako však argumentovala právna vedkyňa Melanie Finková, samotný ľudský dohľad bez ochrán na úrovni systému nestačí. Požiadavka na dohľad, ktorá kladie celé bremeno na ľudských operátorov (bez toho, aby vyžadovala, aby bol systém sám navrhnutý pre bezpečné zlyhanie), vytvára regulačnú medzeru. Táto kritika posilňuje prístup obrany do hĺbky opísaný v kapitole 7: ľudský dohľad je jedna vrstva, nie celá bezpečnostná architektúra.

Rámec riadenia rizík AI od NIST

Národný inštitút pre štandardy a technológie (NIST) publikoval Rámec riadenia rizík AI (AI RMF 1.0) ako dobrovoľné usmernenie pre riadenie rizík AI. Rámec je organizovaný okolo štyroch kľúčových funkcií:

• GOVERN: Ustanoviť a udržiavať politiky, procesy a štruktúry zodpovednosti pre riadenie rizík AI.
• MAP: Identifikovať a kategorizovať kontexty, schopnosti a potenciálne dopady AI systémov.
• MEASURE: Posudzovať a sledovať riziká AI kvantitatívnymi a kvalitatívnymi metódami.
• MANAGE: Priorizovať identifikované riziká a konať proti nim zmierňovaním, monitorovaním a komunikáciou.

NIST následne publikoval Profil generatívnej AI (NIST AI 600-1), ktorý mapuje špecifické riziká systémov generatívnej AI (vrátane halucinácií, konfabulácie, súkromia dát a environmentálneho dopadu) na štruktúru AI RMF. Pre inžinierov GenAI poskytuje AI 600-1 štruktúrovaný kontrolný zoznam rizík na posúdenie a zmiernenie, organizovaný podľa tej istej taxonómie GOVERN-MAP-MEASURE-MANAGE.

ISO/IEC 42001:2023

ISO/IEC 42001:2023 predstavuje prvý medzinárodne certifikovateľný štandard systému riadenia špecificky pre umelú inteligenciu. Modelovaný podľa štruktúry ISO 27001 (informačná bezpečnosť) a ISO 9001 (riadenie kvality) poskytuje rámec na ustanovenie, implementáciu, udržiavanie a neustále zlepšovanie systému riadenia AI v organizácii.

Pre organizácie pôsobiace naprieč jurisdikciami poskytuje certifikácia ISO 42001 preukázateľný, auditovateľný rámec governance AI, ktorý môže súčasne uspokojiť viaceré regulačné požiadavky. Štandard nepredpisuje konkrétne technické implementácie, ale vyžaduje zdokumentované politiky, hodnotenia rizík a procesy neustáleho zlepšovania pre AI systémy.

Model zrelosti AI od Gartnera

Model zrelosti AI od Gartnera poskytuje päťúrovňový rámec na posúdenie pripravenosti organizácie nasadzovať a udržiavať AI systémy:

Model zrelosti je prediktívny, nie iba opisný. Prieskum Gartnera z roku 2025 (432 respondentov, publikovaný v júni 2025) zistil, že iba 20 % organizácií na nízkych úrovniach zrelosti (1 – 2) udrží svoje AI projekty v prevádzke dlhšie než tri roky, oproti 45 % organizácií na vysokých úrovniach zrelosti (4 – 5). Medzera nie je primárne o kvalite technológie; je o udržateľnosti governance. Organizácie s nízkou zrelosťou spúšťajú AI projekty s nadšením, ale chýbajú im štruktúry na ich udržiavanie, monitorovanie a prispôsobovanie v čase. Výsledkom je vzor množenia pilotov nasledovaný tichým opustením.

Kľúčový postreh: Model zrelosti odhaľuje vzor, ktorý by mal znepokojiť každého inžiniera GenAI: infraštruktúra governance opísaná v tejto kapitole nie je réžia, ktorá spomaľuje nasadenie, ale štrukturálny základ, ktorý rozhoduje o tom, či nasadené systémy ostanú v prevádzke dosť dlho na to, aby priniesli trvalú hodnotu. Tímy, ktoré preskočia governance, aby sa hýbali rýchlejšie, štatisticky stavajú systémy, ktoré neprežijú svoj prvý rok.

Poučenia naprieč doménami

Výzva riadiť interakciu človeka a AI nie je jedinečná pre GenAI. Viaceré zrelé odvetvia strávili desaťročia vývojom rámcov governance pre automatizované systémy, nad ktorými musia ľudia dohliadať. Ich zbiehajúce sa zistenia sú poučné.

Letectvo bolo priekopníkom systematického hlásenia incidentov so systémom NASA Aviation Safety Reporting System (ASRS), ktorý poskytuje dôverné, netrestajúce hlásenie bezpečnostných obáv. Národná rada pre bezpečnosť dopravy (NTSB) vedie nezávislé vyšetrovania nehôd, ktoré prinášajú záväzné bezpečnostné odporúčania. Bezpečnostný záznam leteckého odvetvia (miery úmrtnosti v komerčnom letectve klesli za desaťročia o rády) sa nepripisuje žiadnej jednotlivej technológii, ale ekosystému governance okolo nej: povinnému hláseniu, nezávislému vyšetrovaniu, priebežnému výcviku a kultúre, kde sa spochybňovanie automatizovaných systémov očakáva, nie trestá.

Zdravotníctvo vyvinulo špecifické regulačné rámce pre podporu klinického rozhodovania (CDS) cez FDA. Usmernenie agentúry rozlišuje medzi CDS, ktorá fakticky nahrádza klinický úsudok (regulovaná ako zdravotnícka pomôcka), a CDS, ktorú môže klinik pred konaním nezávisle skontrolovať a vyhodnotiť (potenciálne vyňatá z regulácie pomôcok). Čiara sa nedávno posunula: revidované konečné usmernenie zo začiatku roka 2026 uvoľnilo pozíciu z roku 2022 a dovoľuje aj nástrojom s jediným odporúčaním kvalifikovať sa ako CDS mimo pomôcok, keď klinik môže nezávisle skontrolovať základ odporúčania. Jadrový princíp revíziu prežil a priamo sa mapuje na úrovne autonómie diskutované v skorších kapitolách: požiadavky governance závisia od toho, koľko skutočného ľudského zapojenia má systém navrhnuté.

Finančné služby poskytujú azda najpriamejšie použiteľný precedens cez MiFID II a jeho vykonávacie nariadenie RTS 6, ktoré upravuje algoritmické obchodovanie. Požiadavky zahŕňajú: kontroly pred obchodom, ktoré bránia príkazom mimo definovaných parametrov, monitorovanie všetkej algoritmickej aktivity v reálnom čase, „funkciu zabitia“ (vlastný termín nariadenia pre vypínač) schopnú okamžite zrušiť všetky nevybavené príkazy a ročné sebahodnotenie systémov algoritmického obchodovania. Tieto požiadavky vzišli priamo z incidentov ako Knight Capital a kodifikujú návrhové vzory diskutované v kapitole 7 do regulačných mandátov.

Kľúčový postreh: Každá zrelá doména, ktorá integrovala automatizované rozhodovanie do vysoko rizikovej prevádzky, sa nezávisle zblížila na tých istých jadrových princípoch: povinná schopnosť ľudského dohľadu, nezávislé vyšetrovanie incidentov, systematické hlásenie, požiadavky na vypínač a štruktúry governance, ktoré sa auditujú, nie iba dokumentujú. Prevádzka GenAI z týchto princípov nie je vyňatá; je jednoducho najnovšou doménou, ktorá sa s nimi stretáva.

Model zrelosti interakcie AI a človeka

Syntézou rámcov governance, regulačných požiadaviek a poučení naprieč doménami diskutovaných v tejto kapitole poskytuje nasledujúci model zrelosti sebahodnotiaci rámec pre governance interakcie AI a človeka:

Organizácia nemusí dosiahnuť úroveň 5, aby nasadzovala AI systémy zodpovedne. Ale organizácia na úrovni 1, ktorá nasadzuje autonómnych AI agentov v produkcii, pracuje s dlhom governance, ktorý sa bude časom úročiť, a výskum naznačuje, že zložený úrok z dlhu governance je strmý.

Od návrhu k trvanlivosti

Štruktúry governance opísané v tejto kapitole sú spojivovým tkanivom medzi návrhovým zámerom a prevádzkovou realitou. Bez nich sú vzory interakcie zo skorších kapitol ašpiračnou dokumentáciou. S nimi sa tie vzory stávajú živými systémami, ktoré sa prispôsobujú meniacim sa modelom, meniacim sa predpisom, meniacim sa operátorom a meniacim sa prevádzkovým kontextom. Technológia sa bude ďalej rýchlo vyvíjať. Otázka governance znie, či sa s ňou dokáže vyvíjať aj organizácia.

Kapitola 10: Záver

Najťažšou časťou nasadzovania AI v prevádzke je šev, nie AI.

Šev je hranica, kde sa výstup AI systému stretáva s ľudským úsudkom. Je to miesto, kde sa odporúčanie stáva rozhodnutím, kde sa návrh stáva krokom, kde sa predpoveď stáva záväzkom. Každé zlyhanie skúmané v tejto brožúre (každý prípad automatizačnej zaujatosti, každá ignorovaná výstraha, každá katastrofická strata) sa odohralo na tomto šve. A každé úspešné nasadenie, každý prípad, keď AI skutočne zosilnila ľudskú schopnosť, uspelo preto, že niekto ten šev navrhol s rozvahou.

Tri princípy

Vzory, rámce a prípadové štúdie predstavené naprieč týmito kapitolami sa zbiehajú do troch princípov. Nie sú nové. V mnohom sú zjavné. Ale dôkazy ukazujú, že sa porušujú častejšie, než dodržiavajú.

1. Navrhujte šev, neodstraňujte ho

Hranica medzi človekom a AI nie je nepohodlie, ktoré treba minimalizovať, ale kritický riadiaci povrch celého systému. Každé úsilie urobiť hranicu neviditeľnou (nechať výstup AI hladko tiecť do konania bez trenia, revízie alebo ľudského úsudku) odstraňuje mechanizmus, ktorým sa chytajú chyby, rozpoznávajú hraničné prípady a systém sa prispôsobuje kontextom, pre ktoré nebol navrhnutý.

To neznamená, že každý krok AI vyžaduje ľudské schválenie. Úrovne autonómie a eskalačné rámce diskutované v skorších kapitolách poskytujú spektrum od plnej ľudskej kontroly po monitorovanú autonómiu. Ale na každej úrovni musí byť šev navrhnutý: človek musí vedieť, čo AI urobila, prečo to urobila a ako zasiahnuť, ak je niečo zle. Šev musí byť viditeľný, prehľadný a funkčný, nie zakrpatené zaškrtávacie políčko v pracovnom postupe, ktoré sa operátori naučia preskakovať.

2. Podporujte ľudské myslenie, nenahrádzajte ho

Hodnota AI v prevádzke nie je v tom, že myslí, aby človek nemusel, ale v tom, že spracúva, vyhľadáva a štruktúruje informácie, aby človek mohol myslieť lepšie. Na rozlíšení záleží, lebo režimom zlyhania prvého rámcovania je sebauspokojenie: človek sa odpojí, stratí situačné povedomie a stane sa neschopným chytiť chyby, ktoré AI nevyhnutne urobí. Režimom zlyhania druhého rámcovania je iba neefektivita, čo je problém zásadne inej závažnosti.

Vzory interakcie, ktoré podporujú ľudské myslenie (postupné odhaľovanie s brífingmi štruktúrovanými podľa SBAR, kategorická istota s kalibračnými dátami, prepojenie s dôkazmi podporujúce rozhodovanie založené na rozpoznaní), zdieľajú spoločnú návrhovú filozofiu. Zosilňujú ľudské rozpoznávanie vzorov, intuíciu a kontextové uvažovanie namiesto toho, aby ich obchádzali. Predkladajú informácie vo formátoch, ktoré zodpovedajú tomu, ako expertní operátori naozaj myslia, nie vo formátoch, ktoré je pre AI pohodlné produkovať.

3. Stavajte pre zlyhanie, nielen pre úspech

Každý AI agent v niektorom okamihu vyprodukuje nesprávne odporúčania, sfabrikuje informácie, urobí nevhodné kroky alebo sa zachová spôsobmi, ktoré jeho návrhári nepredvídali. Toto nie je dočasné obmedzenie čakajúce na ďalšie vydanie modelu, ale štrukturálna charakteristika systémov, ktoré fungujú v otvorených prostrediach skutočného sveta s neúplnými informáciami a vyvíjajúcimi sa kontextmi.

Dôsledok: návrh pre zlyhanie je súčasťou jadra systému, nie druhoradou starosťou, ktorá sa rieši, keď zvyšok funguje. Každý autonómny krok potrebuje externý vypínač, ktorý AI nedokáže obísť. Každý automatizovaný pracovný postup potrebuje otestovanú záložnú cestu, ktorú operátori precvičili. Každý AI systém potrebuje pomenovaného ľudského vlastníka, ktorý je splnomocnený a oprávnený ho vypnúť.

Dôkazy, syntetizované

Výskum a prípadové štúdie predstavené naprieč týmito kapitolami rozprávajú konzistentný príbeh o tom, čo sa stane, keď sa tieto princípy porušia:

• Automatizačná zaujatosť produkuje v laboratórnych podmienkach miery chýb konania blížiace sa 100 %: operátori sa riadia preukázateľne nesprávnymi odporúčaniami AI, lebo akt spochybnenia systému vyžaduje viac kognitívneho úsilia než prijatie jeho výstupu.
• Únava z výstrah necháva 63 % bezpečnostných výstrah neriešených, nie preto, že by operátori boli nedbanliví, ale preto, že objem výstrah prevyšuje kapacitu ľudského spracovania a návrh rozhrania nepodporuje účinnú triáž.
• Posun k sebauspokojeniu môže ostať dlho neodhalený: v jednom zdokumentovanom prípade prešlo 34 hodín nesprávneho správania automatizovaného systému bez ľudského odhalenia, lebo monitorovacie rozhrania neboli navrhnuté tak, aby ukázali postupnú degradáciu.
• 45-minútová strata Knight Capital vyše 460 miliónov dolárov nastala po tom, čo 97 automatických varovných e-mailov ostalo neprečítaných, lebo nikto nebol poverený ich sledovať, žiadny prah nespustil eskaláciu a neexistoval vypínač na zastavenie poruchového systému.
• Systém MCAS Boeingu 737 MAX, spoliehajúci sa na jediný snímač uhla nábehu s postupom potlačenia, ktorý nebol ani zjavný, ani primerane nacvičený, prispel k 346 úmrtiam pri dvoch haváriách.

Toto sú zlyhania návrhu švu, nie zlyhania AI technológie. V každom prípade technický systém robil to, na čo bol postavený. Zlyhanie bolo na hranici medzi systémom a ľuďmi, ktorí nad ním mali dohliadať.

Vynárajúci sa štandard

Naprieč rámcami skúmanými v tejto brožúre sa formuje vynárajúci sa štandard návrhu interakcie AI a človeka. Šesťúrovňový rámec autonómie CSA (od plnej ľudskej kontroly cez monitorovanú autonómiu po plnú automatizáciu) s dynamickým preradením nadol podľa kontextu, istoty a dôsledkov predstavuje štrukturálny základ. Kľúčovou inováciou nie sú úrovne samotné, ale princíp dynamického pohybu medzi nimi: systém, ktorý funguje na úrovni autonómie 4 pri rutinných úlohách, ale automaticky sa preradí na úroveň 2, keď istota klesne alebo vzrastú stávky.

Informačná architektúra švu je rovnako kritická. Postupné odhaľovanie s brífingmi štruktúrovanými podľa SBAR zabezpečuje, že operátori dostanú správne informácie v správnom čase. Kategorická istota s kalibračnými dátami zabezpečuje, že neistota sa komunikuje v pojmoch, podľa ktorých sa dá konať. Prepojenie s dôkazmi podporuje vlastný proces uvažovania operátora namiesto vyžadovania slepej dôvery.

Architektúra zlyhania (vypínače mimo AI, ističe pri každej závislosti, záložné stacky testované podľa harmonogramu a filozofia obrany do hĺbky modelu švajčiarskeho syra) zabezpečuje, že keď k zlyhaniam dôjde, sú ohraničené, viditeľné a napraviteľné.

A architektúra governance (pomenovaní vlastníci, zodpovednosť troch línií, revízie v pravidelnom rytme, post-mortemy incidentov bez hľadania vinníka a zosúladenie s regulačnými rámcami ako AI Act EÚ a NIST AI RMF) zabezpečuje, že všetko vyššie pretrvá aj po prvotnom nasadení.

Čo urobiť v pondelok ráno

Pre inžiniera GenAI, ktorý toto číta v nedeľu večer a rozmýšľa, kde začať, tu je päť konkrétnych krokov (kapitola 8 poskytuje šablóny a pracovné listy na ich vykonanie):

1. Auditujte jednu existujúcu interakciu AI a človeka. Vyberte jediný bod vo svojom súčasnom systéme, kde sa výstup AI dostane k ľudskému operátorovi. Zmapujte ho: Aké informácie operátor dostane? Čo s nimi môže urobiť? Ako by vedel, že sú nesprávne? Ako by to zastavil?

2. Uplatnite maticu výberu vzoru. Pre tú interakciu určte primeranú úroveň autonómie podľa závažnosti dôsledkov, vratnosti rozhodnutia, časových obmedzení a istoty AI. Je súčasná úroveň primeraná? Ak nie, čo by sa muselo zmeniť?

3. Pridajte vypínač. Ak váš AI systém môže robiť autonómne kroky a nemá mechanizmus na okamžité zastavenie všetkých takých krokov (taký, ktorý je mimo AI, vždy viditeľný a nevyžaduje potvrdzovací dialóg), postavte ho. Otestujte ho. Zdokumentujte ho.

4. Merajte miery prebití. Začnite sledovať, ako často operátori odporúčania AI prijímajú, upravujú alebo zamietajú, rozvrstvené podľa hlásenej úrovne istoty AI. Táto jediná metrika vám o kalibrácii dôvery povie viac než akýkoľvek prieskum alebo rozhovor.

5. Naplánujte revíziu interakcie s AI. Dajte si do kalendára opakujúce sa 30-minútové stretnutie (týždenne alebo raz za dva týždne) na revíziu výkonu AI systému, incidentov a tesných únikov. Pozvite inžinierstvo, prevádzku a aspoň jedného človeka mimo bezprostredného tímu. Držte sa formátu post-mortemu bez hľadania vinníka. Urobte to skôr, než to budete potrebovať.

Žiadny z týchto krokov nevyžaduje novú technológiu, nový rozpočet ani organizačné schválenie. Vyžadujú pozornosť, zámer a uznanie, že šev medzi AI a človekom je najdôležitejší návrhový povrch vo vašom systéme.

A ak chcete, aby váš tím pocítil, prečo na tom všetkom záleží, kým ho požiadate, aby to postavil, pošlite ho do Laboratória človeka v slučke: sedem krátkych simulácií (sprievodná sada tejto brožúry), ktoré ľuďom dovolia zažiť automatizačnú zaujatosť, únavu z výstrah, ukotvenie a morálnu deformačnú zónu na vlastnej koži, od úverovej priehradky banky cez nočnú zmenu na nemocničnom oddelení po sudcovský rozvrh. Dvadsať minút v Laboratóriu obráti viac skeptikov než akákoľvek prezentácia.

Na záver

Organizácie, ktoré to zvládnu správne, nebudú tie s najsofistikovanejšou AI. Budú to tie s najpremyslenejšie navrhnutými švami.

Modely sa budú ďalej zlepšovať. Kontextové okná porastú. Schopnosti uvažovania sa prehĺbia. Náklady klesnú. Ale základná výzva (zabezpečiť, aby pravdepodobnostný systém a ľudský operátor účinne spolupracovali v neistote, pod časovým tlakom a s dôsledkami v skutočnom svete) ostane. Je to návrhový problém, problém governance a nakoniec ľudský problém. Vzory v tejto brožúre sú východiskový bod, nie cieľ. Cieľom je prevádzka, kde AI robí ľudských expertov schopnejšími, informovanejšími a účinnejšími, bez toho, aby ich kedy urobila menej bdelými.