AI implementace selhává už ve chvíli, kdy nikdo nevlastní provoz

Gartner 25. června 2025 v oznámení Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 zveřejnil odhad, podle kterého bude do konce roku 2027 zrušeno přes 40 % projektů s agentní AI. Agentní AI je software, který nečeká pouze na jednotlivý dotaz. Plánuje několik kroků, používá další nástroje a může samostatně provést akci v jiném systému. Gartner mezi důvody očekávaného rušení projektů uvádí rostoucí náklady, nejasnou obchodní hodnotu a nedostatečnou kontrolu rizik.

Jde o prognózu, nikoli o výsledek 40 % již uzavřených projektů. Dobře však popisuje změnu, kterou vidím v praxi. Problém už často není ve výběru modelu ani ve vytvoření první ukázky. Objeví se ve chvíli, kdy pilot skončí, projektový tým se rozejde a AI má dál fungovat v běžném procesu.

Zpráva McKinsey The state of AI: How organizations are rewiring to capture value z března 2025 ukázala rozdíl mezi používáním AI a změnou pracovních postupů. Přes 75 % respondentů uvedlo, že jejich organizace používá AI alespoň v jedné firemní funkci. Jen 21 % respondentů využívajících generativní AI, tedy nástroje vytvářející text, obraz nebo jiný obsah, zároveň uvedlo, že jejich organizace zásadně přepracovala alespoň některé pracovní postupy. Průzkum tak dokládá rozdíl mezi používáním AI a přepracováním pracovních postupů, nikoli to, zda organizace určily odpovědnost za každodenní fungování.

Pilot má dočasného majitele

Během pilotu se o AI obvykle stará člověk, který ji prosadil. Kontroluje výstupy, upravuje zadání, řeší chyby s vývojářem a sleduje první výsledky. Proto doporučuji předem stanovit testovací sadu a hranici úspěchu, jak popisuji v článku o tom, proč AI pilot nezačíná výběrem modelu.

Vlastník pilotu ale není automaticky vlastníkem provozu. Projekt může skončit předáním hotové integrace. Integrace je propojení, přes které si systémy předávají data a příkazy. Od té chvíle vývojář sleduje, zda propojení technicky funguje. Vedoucí procesu kontroluje výsledky svého oddělení. Finance vidí účet za službu. Celý řetězec však nemusí sledovat nikdo.

Představme si modelový týden se 300 příchozími zprávami. AI je třídí, připravuje odpovědi a zapisuje údaje do CRM, tedy systému pro práci s obchodními kontakty. V daném týdnu zařadí devět zpráv nesprávně. Z technického hlediska přitom vše funguje. Požadavek se odeslal, systém odpověděl a záznam vznikl. Chybu odhalí až člověk, kterému se ozve nespokojený zákazník nebo který marně hledá poptávku v nesprávné kategorii.

V modelovém příkladu nemusí být za takovou chybu výslovně odpovědný nikdo. Podpora ji opraví. Obchod si vytvoří vlastní náhradní postup. Vývojář se o ní nemusí dozvědět. AI mezitím pokračuje podle stejného pravidla. Jednotlivou chybu mohl způsobit model, její opakování ale umožňuje chybějící provozní odpovědnost.

Vlastník provozu nehlídá jen dostupnost

Vlastník provozu je konkrétní člověk, který odpovídá za výsledek procesu s AI. Nemusí osobně opravovat propojení ani číst každý výstup. Musí však vědět, kdo zasáhne, podle čeho se pozná problém a kdy se automatizace zastaví.

Pro každé ostré nasazení požaduji pět věcí:

• Jednu hlavní metriku procesu, například počet správně vyřízených požadavků, dobu zpracování nebo počet nutných oprav.
• Přípustnou chybovost a přesný způsob kontroly. Nestačí pokyn, že se výstupy mají občas projít.
• Pravomoc AI zastavit, omezit její akce nebo vrátit proces k ručnímu zpracování.
• Přehled nákladů, oprávnění a systémů, ke kterým má nástroj přístup.
• Záznam změn instrukcí, modelu, datových zdrojů a propojení s dalšími aplikacemi.

K tomu patří zástupce pro dobu dovolené nebo nemoci. Bez zástupce se kontrola během nepřítomnosti vlastníka zastaví, zatímco automatizace pokračuje.

První dva týdny po spuštění kontroluji provoz každý pracovní den. Potom lze přejít na týdenní rytmus, pokud se výsledky drží v určených mezích. Jednou měsíčně má smysl porovnat kvalitu, počet ručních oprav, spotřebu a změny v procesu. Model může po aktualizaci začít odpovídat jinak. Vstupní data mohou změnit formát. Dodavatel může upravit rozhraní. Výsledky se proto mohou zhoršit, i když se kód nezměnil.

Samostatně hlídám možnost okamžitě zastavit další spotřebu. Nejde o teoretickou starost. Jeden AI agent zůstal spuštěný čtyři dny a provedl 4 819 volání, což dodavatele nástroje stálo téměř 4 000 dolarů. Pokud agent pracuje podle chybného pravidla, bez zásahu pokračuje a dál zvyšuje náklady.

Tři způsoby provozu mají různé náklady

Jeden vlastník uvnitř procesu

U pomocné AI, jejíž výstup vždy schvaluje člověk, obvykle stačí jeden vlastník procesu. Jako plánovací základ počítám během prvních čtyř týdnů se třemi hodinami jeho práce týdně. Po ustálení provozu mohou stačit dvě hodiny týdně a přibližně jedna hodina technické kontroly měsíčně.

Tento režim má nejnižší přímé náklady. Vedle licence vyžaduje především interní čas. Nehodí se pro AI, která sama posílá zprávy, mění objednávky, zapisuje do účetnictví nebo spouští placené služby. V takových případech tento režim nestačí, protože akce proběhne dříve, než ji někdo zkontroluje.

Dvojice procesního a technického vlastníka

Pro AI napojenou na další systémy volím dvojici. Procesní vlastník odpovídá za správnost výsledku. Technický správce hlídá propojení, přístupy, provozní záznamy a změny na straně dodavatelů.

Potřebný čas obou rolí určuji podle objemu kontrolovaných výstupů, počtu propojení, rizikovosti akcí a požadované dostupnosti. V prvních šesti týdnech vyhrazuji více času na kontrolu výstupů, řešení chyb a úpravy pravidel. Po stabilizaci lze rozsah snížit podle zjištěné chybovosti a počtu zásahů. K tomu patří náklady na nástroj pro sledování provozu a rozpočet na opakované testování při změně modelu nebo propojení.

Tento způsob vyžaduje více času, ale rozděluje práci podle skutečných pravomocí. Procesní vlastník nemusí rozumět technickým záznamům. Technik nemusí rozhodovat, zda je nesprávně zařazená poptávka ještě přijatelná. V ostrém provozu se proto vyplácí také omezit samostatnost AI agentů na kroky, u kterých lze chybu bezpečně opravit.

Externí technická správa s interním vlastníkem

Technickou část lze předat dodavateli. U jednoho úzce vymezeného procesu odvozuji rozsah externí práce od počtu propojení, objemu změn a požadované dostupnosti. Interní vlastník stále potřebuje pravidelný čas na kontrolu výsledků a rozhodování o změnách.

Tento režim dává smysl tam, kde není volná technická kapacita. Nemůže však nahradit interní odpovědnost. Dodavatel pozná výpadek nebo neobvyklou spotřebu. Bez znalosti procesu ale nemusí odhalit odpověď, která je zdvořilá a technicky bezchybná, ale z obchodního hlediska nedává smysl.

Předání do provozu

Před spuštěním chci mít na jedné stránce jméno vlastníka a jeho zástupce, metriku, hranici pro zastavení, limit spotřeby, náhradní postup a datum první provozní kontroly. Náhradní postup má smysl i u spolehlivého dodavatele. Stejný princip používám při přípravě procesu na výpadek AI služby.

Dříve jsem považoval propojení za hotové, jakmile systémy vracely správné technické odpovědi. Taková kontrola však neukázala, zda celý proces dává smysl. Dnes předání do provozu dokončuji až ve chvíli, kdy konkrétní člověk umí AI zkontrolovat, zastavit a bezpečně nahradit.