AI agenti v enterprise: z PoC do produkce

AI agenta, který si čte dokumenty, volá systémy a vyřizuje úkoly, dnes naklikáte za pár dní. Vím to, protože je stavím — a zároveň dělám architekta v pojišťovně, takže vidím obě strany: jak rychle vznikne působivé demo a co všechno ještě stojí mezi ním a produkcí. A většina z toho s technologií souvisí jen málo.

Proč PoC vypadá hotově za týden

U proof of conceptu se snadno zapomíná na jednu věc: předvádí se na scénářích, které si vybral jeho autor. Deset ukázkových případů projde hladce, publikum je nadšené a všem se zdá, že zbývá „jen to nasadit“.

Jenže PoC většinou běží na vybraných datech, bez reálných oprávnění, bez auditní stopy a s člověkem, který u toho sedí a drobné přešlapy tiše opravuje. Nic z toho v produkci mít nebudete. PoC odpovídá na otázku „umí to fungovat?“ — produkce se ptá, co se stane, když to fungovat přestane.

Jak ten rozdíl vypadá v praxi, ukázala Klarna. V únoru 2024 oznámila, že její AI asistent zvládl za první měsíc dvě třetiny zákaznické podpory — „práci 700 lidí“. O rok později CEO přiznal, že škrty přes AI zašly moc daleko, kvalita šla dolů a firma zase nabírá lidi. Tisková zpráva měřila, kolik konverzací agent vyřídil. Jak dobře — to se řešilo až o rok později.

Co přidává enterprise

V regulovaném prostředí přibývají požadavky, které demo nikdy řešit nemuselo:

• Auditní stopa. Každé rozhodnutí agenta musí být dohledatelné: co viděl na vstupu, proč a jak rozhodl, co provedl. „Model to tak vyhodnotil“ auditorovi ani regulátorovi stačit nebude.
• Odpovědnost. Když agent udělá chybu, musí být předem jasné, kdo za ni odpovídá a jak se opraví. Je to procesní otázka — a odpověď na ni chcete mít dřív, než agenta pustíte do produkce, ne až po prvním průšvihu. Soudy už na to názor mají: kanadský tribunál v únoru 2024 nechal Air Canada zaplatit za slevu, kterou si její chatbot vymyslel. Aerolinka se hájila tím, že chatbot je „samostatná právní entita odpovědná za své vlastní jednání“ — tribunál to označil za pozoruhodné tvrzení a nárok uznal. Šlo o 812 kanadských dolarů, ale ten případ se od té doby cituje jako precedens: za výstupy chatbota odpovídá firma.
• Data governance. V PoC je pohodlné pustit agenta ke všemu. V produkci musí přístup k datům odpovídat účelu — agent na likvidaci pojistných událostí nemá co číst mzdové údaje, i kdyby mu to zlepšilo odpovědi.
• Bezpečnost. Agent je nová útočná plocha: vstupy, kterým věří, se dají podvrhnout (prompt injection je jen ten nejznámější případ), a čím víc akcí smí provést, tím víc škody podvržený vstup napáchá. Dlouho se to ilustrovalo hlavně na kuriozitách, jako byl chatbot dealera slibující Chevrolet Tahoe za dolar. Pak ale v červnu 2025 vyšel EchoLeak: první zero-click prompt injection na produkčního enterprise agenta (Microsoft 365 Copilot, CVSS 9.3). Stačil jeden obyčejně vypadající e-mail v poště — agent si ho sám zatáhl do kontextu a citlivá data odtekla, aniž by uživatel na cokoli klikl. Naštěstí to našli bezpečnostní výzkumníci.

A nejde jen o interní opatrnost. Podle EU AI Act spadá AI pro risk assessment a pricing v životním a zdravotním pojištění rovnou mezi high-risk systémy, s povinnostmi od srpna 2026 (v Bruselu se řeší odklad, ale směr platí). Takže velká část těch odrážek nahoře bude dřív nebo později prostě povinnost ze zákona.

Kde smí agent jednat sám

Nejdůležitější návrhové rozhodnutí celého řešení: které akce smí agent udělat sám a kde musí být člověk ve smyčce. Používám na to jednoduchou mřížku — dvě osy, vratnost a dopad:

• Vratné + malý dopad → agent jedná sám (návrh odpovědi, kategorizace, příprava podkladů).
• Vratné + velký dopad → agent jedná, člověk kontroluje vzorky a metriky.
• Nevratné + malý dopad → agent připraví, člověk potvrdí jedním klikem.
• Nevratné + velký dopad → agent pouze doporučuje; rozhoduje člověk (výplata pojistného plnění, výpověď smlouvy).

Ta hranice navíc není daná jednou provždy. Vyplatí se začít konzervativně a pravomoci agentovi přidávat podle toho, co ukážou čísla z provozu — vyjde to levněji než začít zostra a po prvním incidentu všechno zase zamknout.

Agent jako nový účastník procesu

K agentovi se často přistupuje jako k dalšímu systému, který se prostě „zintegruje“. Mně v praxi víc pomáhá představa nového kolegy: rychlého, co se nikdy nenudí, ale občas si zadání vyloží po svém.

Z té představy plynou praktické otázky, které byste u nového kolegy položili taky: kdo mu zadává práci a v jakém formátu? Komu předává výsledek? Jak pozná, že si neví rady, a komu to řekne? A co se stane s procesem, když zrovna „nepřijde do práce“? Proces, který na tyhle otázky nemá odpověď, na agenta připravený není — bez ohledu na to, jak dobrý ten agent je.

Co měřit, aby šlo říct „funguje to“

Bez metrik se debata o agentovi vede na anekdotách: jeden si pamatuje skvělou odpověď, druhý průšvih. Tohle je minimální sada, kterou chci mít od prvního dne:

1. Úspěšnost na konci procesu — ne „agent odpověděl“, ale „případ byl správně vyřízen“, měřeno stejným metrem jako u lidí. Přesně na tomhle skončila AI v drive-thru McDonald’s: dva roky testů ve víc než stovce restaurací, jenže přesnost objednávek se podle franšízantů držela kolem 80 % a cíl byl 95. To virální video s 260 nugety v jedné objednávce byl jen ten nejviditelnější projev.
2. Míra eskalací — jak často agent předává práci člověku. Nízké číslo nemusí být dobrá zpráva: agent, který nikdy neeskaluje, spíš nepozná, kdy si neví rady.
3. Cena za vyřízený případ — včetně nákladů na kontrolu a opravy po agentovi. Bez nich vám vyjde hezčí číslo, než jaká je realita.
4. Trend oprav — kolik agentových výstupů museli lidé předělat a jak se to vyvíjí. Podle tohohle čísla se posouvá hranice samostatnosti z předchozí kapitoly.

Závěr

Nasadit AI agenta do enterprise znamená hlavně rozhodnout, kolik důvěry mu dáte: co smí udělat sám, kdo za něj odpovídá a čím se měří, že funguje. Technologie je dnes připravenější, než většina organizací tuší. Co obvykle chybí, jsou procesy, odpovědnosti a metriky.