„AI agenta jsme zrušili hned po implementaci, protože nesplnil naše očekávání." To jsme slyšeli už víckrát. Co a kde se pokazilo? Demoverze přece vypadala dokonale. Sepsali jsme pro vás devět důvodů, proč se stává, že agent nefunguje, jak má.
Zdrojový systém může mít výpadek a agent místo chyby vrátí prázdné pole a tváří se, že je to fakt. Nebo přijde e-mail s přílohou, ve které je schovaná instrukce od útočníka. Agent ji vykoná, protože neumí odlišit obsah od zadání.
Ani jedna z těchto situací se nestane při testování agenta. Objeví se až v plném provozu.
Podle průzkumu S&P Global Market Intelligence upustilo 42 % firem od většiny svých plánů s AI, přičemž rok předtím to bylo 17 %. Průměrná organizace zahodila 46 % proof of conceptů, a to ještě před produkcí. Analytická společnost Forrester upozorňuje, že dlouhodobě fungující agent se chová jako distribuovaný systém a vyžaduje především disciplínu v orchestraci, identitách a práci s kontextem. A na to se většina firem vůbec nepřipravila.
| Kolik projektů nepřežije | |
|---|---|
| Agentické projekty zrušené do konce roku 2027 kvůli nákladům, nejasné hodnotě nebo slabému řízení rizikGartner, červen 2025 | přes 40 % |
| Podniky, které do roku 2027 agentům omezí nebo odeberou pravomociGartner, květen 2026 | 40 % |
| Firmy, které opustily většinu svých AI iniciativ (rok předtím 17 %)S&P Global Market Intelligence, březen 2025 | 42 % |
| Proof of concepty zahozené ještě před nasazením do produkceS&P Global Market Intelligence, březen 2025 | 46 % |
| Co nasazení nejčastěji brzdí | |
| Integrace se stávajícími systémyAnthropic a Material, 2026 State of AI Agents Report | 46 % |
| Náklady na implementaciAnthropic a Material, 2026 State of AI Agents Report | 43 % |
| Přístup k datům a jejich kvalitaAnthropic a Material, 2026 State of AI Agents Report | 42 % |
| Řízení změn na straně lidíAnthropic a Material, 2026 State of AI Agents Report | 39 % |
| Trh a bezpečnost | |
| Dodavatelé, kteří agentickou AI skutečně dělají, z tisíců, kteří se tak označujíGartner, červen 2025 | cca 130 |
| Bezpečnostní lídři, pro které je agentická AI obavaForrester Security Survey 2026 | 49 % |
| Kdo agenty reálně škáluje a co to přináší | |
| Velké firmy s obratem nad 1 mld. USD, které agenty škálujíMcKinsey State of AI, 2026 | 40 % |
| Menší firmy, které agenty škálujíMcKinsey State of AI, 2026 | 22 % |
| Firmy, které AI připisují alespoň nějaký dopad na EBIT, meziročně beze změnyMcKinsey State of AI, 2026 | 37 % |
| Firmy, kterým provozní náklady AI omezily její využitíMcKinsey State of AI, 2026 | cca 20 % |
| Kde je dnes Evropa | |
| Podniky v EU, které používají alespoň jednu AI technologiiEurostat, ICT usage in enterprises 2025 | 20,0 % |
| Z toho Česko a SlovenskoEurostat, ICT usage in enterprises 2025 | 17,6 % / 18,0 % |
| Podniky v EU, které používají AI-based RPAEurostat, ICT usage in enterprises 2025 | 5,4 % |
Hodnoty vyjadřují podíl organizací, které danou skutečnost v průzkumu uvedly. Průzkumy byly realizovány mezi technickými lídry a manažery v letech 2025 a 2026.
Poslední řádek je důležitější, než se na první pohled zdá. Naznačuje, že uvědomělé nasazení automatizace je v Evropě stále menšinová záležitost, přičemž AI agenti se nejlépe a nejčastěji staví právě na již existující RPA.
Chatbot jen odpovídá v chatu, agent samostatně vykonává úlohy.
Rozdíl je v tom, co se stane po zadání požadavku. Agent si dokáže vyhledat údaje v CRM, přečíst dokument, vyhodnotit kontext, použít nástroj, vytvořit záznam, spustit proces, požádat o schválení a sledovat výsledek. Každý z těch kroků je zásah do firemního systému s reálnými důsledky.
Z toho vyplývá, že implementace agenta znamená v první řadě stanovit si architekturu, integraci, bezpečnost a provoz. Prompt engineering je z toho všeho ta nejmenší část.
Informace v každém jednotlivém systému, například v CRM, ERP, e-mailech nebo dokumentových úložištích, jsou správné. Každý systém má ale vlastní logiku, vlastní identifikátory a vlastní „verzi pravdy“. Pokud systémy nejsou propojené, agent pak neumí spolehlivě odpovědět ani na jednoduchou otázku o stavu žádosti.
Tento chaos způsobuje, že firmy často nalijí agentovi do kontextu všechno, co mají po ruce, a doufají, že si podstatné informace najde sám.
Před nasazením zmapujte zdroj pravdy pro každý datový objekt, jeho vlastníka, pravidla kvality a klíčové identifikátory. Agent by neměl mít přístup ke všemu. Má mít přesně definovaný kontext pro jeden proces.
V demu stačí ukázat, že se agent umí připojit na rozhraní. V provozu ale musí vědět i to, co má dělat, když rozhraní neodpovídá, když jsou data neúplná, když se změní schéma a kdy je potřeba celou operaci zrušit bez jakýchkoli změn.
Podle průzkumu Anthropicu a Material mezi více než pěti sty technickými lídry je to nejčastější bariéra vůbec, uvedlo ji až 46 % dotázaných. Popisují přitom i jeden konkrétní vzorec. Agent byl vybudován na schématu například z ledna, mezitím se rozhraní zrušilo a nikdo si nevšimne, že to nefunguje, případně si toho všimne, až když je pozdě.
Pro každý proces definujte vstupy, výstupy, povolené nástroje a akce, podmínky eskalace, chybové scénáře, rollback a auditní stopu. Agent si nemá proces vymýšlet. Má používat ten, který už máte ověřený, ideálně pomocí stávající RPA.
Našli jsme i diskusi o provozu agentů, kde se opakuje stejný důvod, proč k tomu dochází. Tým nechce zpomalit implementaci definováním přístupových pravidel, tak dá agentovi přístup „na zkoušku“ k celému systému. Dočasné řešení se bohužel stane trvalým.
Agenti mají sdílené, zapůjčené nebo příliš široké přístupy, takže jeden agent si otevře všechno, k čemu se dostane.
Jak tomu předejít? Vlastní identitou pro každého agenta, se samostatným servisním účtem, explicitním seznamem povolených zápisových akcí, povinným lidským schvalováním u citlivých operací a logováním i zamítnutých pokusů, nejen úspěšných volání. Revize oprávnění má mít pevný termín, ne jen „podle potřeby“.
Pokud agent zpracovává obsah zvenčí, například e-mail, dokument, webovou stránku nebo ticket, tento obsah mu může přepsat zadání. OWASP (Open Worldwide Application Security Project) to má na prvním místě svého žebříčku pro agenty jako ASI01, takzvaný únos cíle.
„The model is never the control.“
Gee Rittenhouse z AWS a Eric Johnson ze SANS Institute, září 2026
Bezpečnost více agentů nemůže být jen v systémovém promptu, musí být nastavená přímo v platformě.
Proto oddělte to, kde jsou nastavená pravidla, od toho, kde se model rozhoduje. Vynucování pravidel patří do platformy, do brány a do oprávnění, ne do instrukce typu „nemaž záznamy“.
Může vzniknout situace, kdy se agent nedokáže připojit k systému, ale pokračuje ve své úloze i bez potřebných údajů či úkonů. Než si toho všimne reálný člověk, agent udělá další tři kroky a chyba se znásobí. Výsledkem je, že se opravuje pokažený výstup nebo jen mezikrok, ne skutečná příčina problému.
Zaplnění kontextového okna, kaskádu a drift datových rozhraní totiž netestuje téměř nikdo, přestože právě ty způsobují tichá selhání bez chybové hlášky.
Jak tomu předejít? Stanovte limit na počet kroků, detekci smyček, timeout a povinný bezpečný stav, do kterého se agent vrací. Každé použití nástroje má mít jasně definované, co znamená jeho selhání pro celý běh.
I Gartner varuje před jedním univerzálním pravidlem pro všechny agenty.
„Firmy to vidí černobíle. Agent buď nesmí skoro nic, nebo smí všechno.“
Shiva Varma, Senior Director Analyst, Gartner
Selhání má pak dvě podoby. Jednoduchý agent je zatížen kontrolami, které vůbec nepotřebuje, a tak ho ve firmě obejdou. Autonomní agent má zase přílišnou volnost, čímž vzniká bezpečnostní nebo compliance riziko. Gartner doporučuje proporční řízení se čtyřmi úrovněmi autonomie, přičemž každá je samostatnou hranicí důvěry.
Gartner rozlišuje čtyři úrovně: agent pozoruje, radí, koná se schválením, nebo koná samostatně. Každá z nich si vyžaduje jinou míru kontroly.
Třetí úroveň má jeden háček, a to ten, že se schvalování pod tlakem degraduje. Když zaměstnanec automaticky kliká na schválení, protože mu hláška vyskočila už potřicáté za hodinu, kontrola vlastně neexistuje, navzdory původnímu nastavení human-in-the-loop.
Vývojáři tvrdí, že problém je na provozu. Ten zase řekne, že problém je v AI. Nedokážou se dohodnout, a tím pádem agent pracuje dál bez opravy.
Uvedeme trochu extrémnější případ. AI agent získal v červnu neoprávněný přístup k vládnímu zdravotnickému portálu. Provozovatel byl soukromá firma v jiné zemi a poškozená strana neměla smlouvu ani s jedním z nich. Oznámení o události přišlo až v září, protože žádný postup s takovou situací nepočítal. Tomu se říká orphan incident, incident bez majitele.
Před spuštěním proto pojmenujte vlastníka procesu, vlastníka dat, vlastníka technického řešení, toho, kdo reaguje na incident, a toho, kdo má právo agenta vypnout. Poslední jméno je nejdůležitější a nejčastěji chybí.
Kolikrát byl agent spuštěn, kolik zpráv zpracoval, kolik tokenů utratil. To je užitečná telemetrie, která ale o přínosu nic neříká.
Našli jsme i případ, kdy ve firmě během šesti měsíců sledovali počet aktivací agenta, ale vůbec neměřili, jestli jeho činnost zlepšila byznysový výsledek. Agent ale fungoval dál, přinášel minimum hodnoty a plýtval rozpočtem.
Pro každý proces je potřeba nastavit jedno byznysové KPI a jeden náklad. Například podíl automaticky vyřešených případů, čas odpovědi zákazníkovi a náklad na jednu úspěšně dokončenou úlohu. Dashboard, do kterého vidí vedení, ne jen tým, který agenta postavil.
Náklady na licenci a vývoj se dají snadno spočítat. Požadavky na modely, opakované spouštění nástrojů, velké kontexty a prohledávání objemných dat už tak předvídatelné nejsou. Pětina firem podle McKinsey uvádí, že provozní náklady AI včetně tokenů jim omezily její využívání.
Je potřeba nastavit strop na jednoho agenta a na jeden proces, zapojit menší modely tam, kde jsou dostačující, a nastavit automatické zastavení, když agent překročí určený limit. Přičemž náklad na úlohu patří do reportu vedle přínosu, ne do samostatného souboru u správce cloudu.
Pro banku, pojišťovnu, energetiku i veřejnou správu přibývají rizika a povinnosti, které se v běžném projektu nenacházejí.
Například AI Act po Digital Omnibusu. Povinnosti pro vysoce rizikové systémy z přílohy III, kam patří mimo jiné úvěruschopnost, upisování životního a zdravotního pojištění či řízení zaměstnanců, se přesunuly z 2. srpna 2026 na 2. prosince 2027. Vysoce riziková AI zabudovaná v regulovaných produktech má termín 2. srpna 2028. Odklad nabývá účinnosti zveřejněním v Úředním věstníku.
Transparentní povinnosti podle článku 50 platí dál. Člověk musí být informován, že komunikuje s AI, a obsah vytvořený AI se musí strojově čitelně označit. U systémů uvedených na trh před 2. srpnem 2026 je na technické řešení označování čas do 2. prosince 2026.
Pro banku je dodavatel AI stejný typ partnera jako poskytovatel cloudu. Čeká ho prověrka, smlouva s povinnými náležitostmi a zápis do registru i se subdodavateli. Posuzování trvá týdny až měsíce. Firma, která to má připravené předem, ušetří týdny, které by jinak strávila sháněním dokumentů.
Jako první proces na automatizaci AI agentem je vhodné vybrat ten, který se často opakuje, má jasné vstupy a výstupy, funguje nad systémy s rozhraním nebo existující automatizací, chyba v něm nemá kritický dopad a je v něm místo, kde do něj vstoupí člověk a rozhodne o konečném výstupu.
Dobří kandidáti jsou například kvalifikace leadů, kontrola žádostí nebo interní vyhledávání.
Nevhodné procesy jsou ty bez datového základu, bez dokumentace, s vysokým regulačním dopadem a ty, kde se změna nedá vrátit zpět bez následků.
Pokud dokážete stručně a jasně odpovědět na těchto šest otázek a doložit to konfigurací, váš pilotní projekt má velkou šanci na úspěch.
V Millennium vytváříme agenty jako další vrstvu nad stávající architekturou zákazníka. Prakticky to znamená propojení na CRM postavené na Microsoft Dynamics 365, automatizaci v Power Platform a UiPath a na dokumenty a reporting v Power BI. K tomu samozřejmě patří i návrh rozhodovací logiky, oprávnění, eskalací a provoz pod SLA.
Některé problémy ale nevyřeší žádný dodavatel a nemá smysl tvrdit opak.
Zavedení agenta do zaběhnutých pracovních postupů
Čtvrtou nejčastější bariérou je podle citovaného průzkumu řízení změn, uvedlo ho až 39 % dotázaných. Agent navržený dodavatelem může být sice dokonalý, ale pokud si nezíská důvěru zaměstnanců, nebudou ho používat. Pomůže, když agent převezme jen tu nejnepříjemnější část práce, a ne celou agendu.
Správa dat napříč firmou
Dokud není jasně stanoveno, který systém je pro daný údaj hlavní, agent nemá odkud vzít spolehlivou odpověď. Toto rozhodnutí se nemá dělat na úrovni projektu, ale vedení.
Bezpečnostní red teaming agentů
Útoky typu prompt injection jsou samostatnou disciplínou a je potřeba testovat je průběžně, ideálně specialistou.
Rozhodnutí, co automatizovat netřeba
Část procesů se dá zrušit nebo jen zjednodušit místo automatizace. Dodavatel, který to přizná, sice přijde o část zakázky, ale zákazník na tom může ušetřit víc než na agentovi.
Proč selhávají AI agenti v produkci?
Nejčastěji na integraci, kvalitě dat, příliš širokých oprávněních a v tom, že kontrola neodpovídá tomu, co agent skutečně smí. Kvalitu modelu uvádí v průzkumech jen málokdo.
Jaký je rozdíl mezi chatbotem a AI agentem?
Chatbot jen odpovídá. Agent vykonává kroky v reálných systémech, pracuje v nástrojích, zapisuje záznamy a spouští procesy. Z toho vyplývají odlišné nároky na oprávnění, audit a provoz. Jak se agent k firemním systémům dostane, popisujeme v článku o Model Context Protocolu.
Jak dlouho trvá, než AI agent přinese měřitelný efekt?
U jednoho dobře vybraného procesu s dostupnými daty jsou první měřitelné výsledky realistické v horizontu několika měsíců. Rozhoduje o tom připravenost dat a integrací, ne výběr modelu.
Co vyžaduje AI Act od firem v roce 2026?
Povinnosti pro vysoce rizikové systémy z přílohy III se odložily na prosinec 2027. Transparentní povinnosti podle článku 50 platí dál, včetně informování člověka, že komunikuje s AI, a označování AI obsahu.
Jak měřit návratnost AI agenta?
Jedním byznysovým KPI a jedním nákladem na proces. Například podíl automaticky vyřešených případů oproti nákladu na jednu úspěšně dokončenou úlohu. Počet spuštění agenta návratnost neměří.
Agent, který ví všechno, může být sice zajímavý, ale agent, který ví přesně to, co má, má na to správná data a jedná v hranicích, které mu firma určila, je použitelný dlouhodobě.
Pokud řešíte nasazení agenta do provozu v prostředí, kde se nesmí nic pokazit, napište nám.
