Vaši agenti s umělou inteligencí potřebují popis práce, ne lepší prompty

Zeptejte se firmy, co smí dělat nová analytička závazků, a dostanete přesnou odpověď. Pracuje v těchto systémech a s těmito dodavateli a cokoli nad limitem pro schválení, řekněme 10 000 $, musí podepsat její nadřízený. Prvních několik měsíců je ve zkušební době. To vše bývá obvykle uvedeno v tabulce delegovaných pravomocí, kterou každý rok kontroluje interní audit.

Zeptejte se téže firmy, co smí dělat její nový agent pro zpracování faktur, a často dostanete snímek obrazovky s promptem.

Tato propast mě znepokojuje víc než jakýkoli benchmark modelů. Přijímáme digitální pracovní sílu, aniž bychom měli systém řízení, jehož budování pro lidi nám zabralo celé století: nikdo nezaznamenává její pravomoci, nikdo před jejím nasazením neověřuje její úsudek a nikdo si nevyzkoušel, jak ji vypnout.

Proč prompt nemůže zastat tuto práci

Prompt popisuje záměr. Říká, k čemu agent slouží. Jen zřídkakdy ale stanoví, co agent nesmí nikdy dělat, kde jsou jeho limity nebo kdy se musí zastavit a přenechat rozhodnutí člověku.

A i když prompt takové věci stanoví, nic nezajišťuje jejich dodržování. Pokyn, aby agent nevracel částky vyšší než 500 $, je jen žádostí adresovanou pravděpodobnostnímu systému. Žádný auditor by u člověka neschválil jako kontrolní mechanismus tvrzení „slušně jsme o to analytičku požádali“, a tak nechápu, proč to přijímáme u softwaru.

Bezpečnostní experti už pro tento výsledek mají název. OWASP Top 10 pro aplikace LLM uvádí Nadměrnou autonomii agentů jako jedno z hlavních rizik, které pramení z příliš široké funkcionality, nadměrných oprávnění nebo přílišné autonomie. Jednoduše řečeno, je to jako dát zaměstnanci hned první den klíče úplně od všeho. Doporučení OWASP připomínají kontrolní seznam dobrého manažera: dát agentovi pouze nástroje, které potřebuje, omezit jeho oprávnění, vyžadovat schválení člověkem u kroků s velkým dopadem a vynucovat autorizaci v navazujících systémech, místo abychom spoléhali na to, že se model bude kontrolovat sám.

Právě na to poslední bych kladl důraz. Oprávnění musí být nastavena tam, kde se akce provádí: v samostatné identitě služby daného agenta, v jeho oprávněních k používání nástrojů a v limitu výdajů na bráně API. Provozovat agenty pod společným servisním účtem je jako nechat pět lidí sdílet jeden průkaz. Když se něco pokazí, v auditním protokolu stojí, že to provedl servisní účet, a vy můžete jen hádat, který agent za tím byl.

Za rušením projektů je zřejmě problém v řízení

Gartner předpovídá, že do konce roku 2027 bude zrušeno více než 40 % projektů agentní umělé inteligence, a jako důvody uvádí rostoucí náklady, nejasnou obchodní hodnotu a nedostatečné řízení rizik.

Svou roli v tom hrají přehnaná očekávání a nedostatečně vyspělé produkty. Zkuste se ale na tyto tři příčiny podívat očima provozního ředitele. Náklady rostou, když nikdo nestanovil rozpočet. Hodnota zůstává nejasná, když nikdo písemně nezaznamenal, jaký výsledek měla práce přinést. Řízení rizik selhává, když neexistují žádné limity ani kontroly a nikdo nenese jasnou odpovědnost. Gartner to takto neformuluje; takto to interpretuji já. Je to stejný problém, který nastává, když lidé dostanou volnou ruku bez systému řízení, a ten existuje mnohem déle než umělá inteligence.

Rámce poukazují na stejnou mezeru. Rámec NIST pro řízení rizik umělé inteligence chápe funkci Řízení jako průřezovou, která zahrnuje Mapování, Měření a Správu, a Profil generativní umělé inteligence tento přístup rozšiřuje na generativní systémy. Rámce vám ale nemohou poskytnout praktické mechanismy — oprávnění, testy a kontroly, podle nichž tým skutečně funguje v běžné úterý. Bez nich zůstává správa jen PDF souborem na sdíleném disku.

Jak přenést tradiční nástroje řízení na agenty

Začněte popisem práce, který se v případě agenta mění na soubor udělených oprávnění. Než agent začne pracovat v ostrém systému, měl by někdo být schopen sepsat na jednu stránku, co smí dělat, co nikdy dělat nesmí, jaké jsou limity pro schválení, který člověk za něj odpovídá a kdo může jeho oprávnění rozšířit. V matici RACI musí být osobou odpovědnou za výsledek člověk. Pokud takovou stránku nedokážete sepsat, daná role ještě není připravena k obsazení — a totéž byste řekli i o lidském uchazeči.

Dvě tradiční pravidla delegování pravomocí platí i nadále. Nemůžete delegovat pravomoc, kterou sami nemáte, takže podřízený agent nesmí nikdy získat širší oprávnění než agent, který jej vytvořil. Platí také oddělení povinností. Pokud agent může zároveň vytvořit dodavatele a zaplatit mu, jde o stejné zjištění auditu, jaké by se týkalo člověka.

Pak je tu přijímací test. Agenty většinou testujeme jako kalkulačku — ověřujeme, zda je odpověď správná. Test pracovníka by měl ověřit, zda se držel udělených oprávnění, požádal o schválení, když měl, eskaloval situaci, která přesahovala jeho zadání, a zastavil se, když měl.

Ve vlastním výzkumu vytvářím benchmark s 50 scénáři zaměřenými právě na tato selhání: překročení limitů pro schválení, jednání na základě zastaralých údajů, následování podvržených instrukcí rozšiřujících rozsah oprávnění a ponechání přístupu po změně role. Zatím jsem jej spustil pouze proti skriptovaným agentům, abych ověřil, že se scénáře chovají podle návrhu, takže nemám žádné výsledky pro modely, o kterých bych mohl informovat. Při jejich tvorbě mě překvapilo, jak běžné tyto situace jsou. Jde o obvyklé způsoby, jakými zaměstnanci překračují zadání, jen převedené do podoby softwaru. Většina veřejných žebříčků stále hodnotí dokončení úkolu a jen velmi málo z nich posuzuje, zda agent respektoval své pravomoci.

Zkušební dobu a povyšování lze přenést poměrně přímo. U lidí začínáme s úzce vymezenou působností a rozšiřujeme ji, když prokážou dobrý úsudek. Agenti mohou stejným způsobem získat širší pravomoci, pokud se osvědčí tím, že nepřekračují stanovené meze, dokážou správně eskalovat problémy a bez potíží se zastaví. Stejné záznamy přitom mohou stejně dobře ospravedlnit i zúžení udělených oprávnění.

U agentů je tu navíc jedna komplikace, která se u lidí nevyskytuje. Když dodavatel aktualizuje základní model, fakticky máte nového zaměstnance se starým průkazem. Považoval bych to za změnu, která vyžaduje nové posouzení, a před převedením udělených oprávnění bych agenta znovu otestoval.

Ukončení činnosti je třeba si nacvičit dřív, než ho budete potřebovat. Dokázali byste tohoto agenta zastavit a odebrat mu přístup během příští hodiny? Kdo má pravomoc o tom rozhodnout ve dvě ráno? Co by přestalo fungovat v navazujících procesech a které rozpracované závazky by někdo musel ručně vyřešit? Pokud si to nikdo nevyzkoušel, jen doufáte, že nouzové vypnutí bude fungovat.

Zaměstnance můžete volat k odpovědnosti. Agenta nemůžete volat k odpovědnosti za nic, a právě tady toto srovnání přestává fungovat. I proto se udělená oprávnění musí vynucovat prostřednictvím systémů a každý agent musí mít určenou osobu, která za něj odpovídá. Ať tak či onak, někdo nakonec ponese odpovědnost. Obvykle je to ten, kdo udělil souhlas, ať už věděl, že ho uděluje, nebo ne.

Na co se bude ptát rozbor incidentu

Někteří z těchto agentů dříve či později udělají něco, co by dělat neměli. Když k tomu dojde, rozbor po incidentu se bude ptát na totéž, na co se ptá v případě lidí. Co agent směl dělat a kde je to napsáno? Kdo schválil rozšíření jeho přístupu? Jak dlouho trvalo ho zastavit? Kdo za něj odpovídal?

Pokud jsou upřímné odpovědi „pokyn“, „nikdo si nevzpomíná“, „hodiny“ a „není jasné“, lepší model by vás nezachránil.

Kde se nakonec projeví výhoda

Modely se mění v pronajímané vstupy, které dodavatelé obměňují a aktualizují podle vlastního harmonogramu. Dvě společnosti mohou používat stejný model a přesto skončit ve velmi odlišné situaci. Jedna má agenty s rozpočty, omezeními, určenými odpovědnými osobami a auditní stopou každého kroku s významnými důsledky, zatímco druhá má nákladný pilotní projekt, který míří do statistik zrušených projektů.

Rozdíl spočívá v systému řízení, který model obklopuje. Ten se buduje pomalu, většinou díky lidem, kteří už dříve řídili organizace.

Kdyby váš nejnovější agent zítra překročil své pravomoci, všiml by si toho někdo ve vaší společnosti? A dokázali byste auditorovi písemně ukázat, kde byla hranice?