Proč projekty Agentic AI selhávají ve velkém měřítku a co musí podniky nejprve opravit

Agentic AI se rychle stává kritickým prvkem všech podniků. Společnosti začleňují pilotní projekty do svých operací, demo prostředí ohromují vedení a plány se přepisují kolem autonomních AI pracovních postupů.

Ale pro mnoho z těchto projektů se něco pokazí mezi řízeným demo a produkční nasazení. Projekt se zastaví, nasazení se protáhnou z měsíců na roky a týmy odpovědné za doručení jsou ponechány vysvětlovat, proč agent, který fungoval perfektně v testování, se chová nepředvídatelně ve skutečném světě.

V téměř všech případech není odpověď model sám, ale datový majetek, orchestrace, rámec governance a legacy infrastruktura, kterou většina podniků nikdy nezměnila, než se rozhodla postavit inteligentní agenty na jejím základě. Dokud tyto základy nejsou řešeny, agentic AI bude pokračovat ve vytváření demo, které ohromují, a nasazení, která zklamávají.

Prostředí POC je past

Většina podniků vyhodnocuje modely. Mnohem méně vyhodnocuje chování agentů od začátku do konce. Model může být velmi přesný a agent postavený na jeho základě může stále selhat. To je protože agenti řetězí nástrojové volání sekvenčně a jeden špatný krok produkuje špatnou odpověď, kterou další krok bere jako správný vstup, čímž se chyba zhoršuje po proudu, než někdo všimne.

Prostředí prokazující koncept je navrženo tak, aby toto skrývalo. Vstupy jsou řízené, rozsah je úzký a někdo sleduje výstup. Žádné z těchto podmínek neexistují v produkci. Agent, který skóroval dobře v testování, nyní zpracovává víceznačné instrukce, narazí na chyby oprávnění a činí sekvenční rozhodnutí na základě dat, která nebyla testována. Tým, který ho postavil, zjišťuje, že rámce vyhodnocování navržené pro výkon modelu neříkají, zda se agent eskaloval správně, zda zpracoval okrajový případ elegantně nebo zda věděl, kdy přestat.

Podle McKinsey’s State of AI 2025 report, 88% organizací nyní používá AI alespoň v jedné obchodní funkci, ale pouze asi jedna třetina úspěšně rozšířila AI napříč celou firmou. Ten rozdíl mezi přijetím a rozsahem začíná tím, jak podniky definují a vyhodnocují své pilotní projekty. Týmy, které úspěšně rozšiřují, považují analýzu selhání za požadavek na design. Před nasazením vytvářejí katalog toho, jak se agent očekává, že selže, a co je reakce, když k tomu dojde. To zní zjevně. Velmi málo podniků to skutečně dělá.

Špatná data, špatní agenti

Podniky stále ptají, proč jejich agenti ve produkci nedosahují očekávaných výsledků. Odpověď téměř vždy souvisí s daty. Datový majetek nebyl nikdy připraven. Zdroje byly fragmentované napříč desítkami systémů postavených v různých časech pro různé účely. Definice byly nekonzistentní napříč obchodními jednotkami. Neexistovala žádná sémantická vrstva. Neexistoval žádný jediný zdroj pravdy. Existovaly pouze roky nahromaděného dluhu dat, které nikdo nepriorizoval, protože staré systémy fungovaly dostatečně dobře.

Ten dluh nezmizí, když postavíte agenta na jeho základě. Stává se realitou, ve které agent operuje. Agent, který naviguje fragmentované zdroje dat, nedělá žádný rozumný úsudek o podniku. Snaží se udělat své nejlepší s tím, co najde, a produkuje výstupy, které vypadají přesvědčivě, dokud někdo, kdo zná podnik, nedívá se pozorně. Agent není rozbitý. Data, která mu byla dána, byla rozbitá již předtím, než projekt začal.

Data drift a concept drift situaci zhoršují. Když se reálná distribuce vstupů posune od toho, na čem byl model trénován, agent nevrhne chybu. Pokračuje v běhu a začíná produkovat špatné výstupy, sebevědomě a ve velkém měřítku. Bez MLOps nebo AIOps pipeline postavené do agentovy orchestrace, neexistuje žádný mechanismus, který by chybu zachytil, než se škoda zhorší. Agent, který fungoval akceptabilně při spuštění, se tiše zhoršuje po týdnech, než někdo spojí kvalitu výstupu s problémem dat, který tam byl od začátku.

Modernizace dat a modernizace AI jsou často považovány za paralelní pracovní proudy, sekvencované nezávisle a financované samostatně. Není to paralelní. Nemůžete postavit důvěryhodného agenta na základě datové architektury, která byla rozbitá již předtím, než projekt začal. Posloupnost je enormně důležitá a přeskočení datové vrstvy, aby se urychlilo na AI vrstvě, je jednou z nejčastějších a nejdražších chyb, kterých se podniky dopouštějí.

Špatný dashboard dává někomu špatné číslo. Špatná akce agenta může spustit downstream proces, než někdo všimne, schválení faktury, která by neměla být schválena, nesprávné směrování compliance vlajky nebo úpravu ceny mimo její zamýšlený rozsah. Agentic systémy potřebují speciální pozorovatelnost, ne recyklované dashboardy z obecného app monitoringu.

Výhoda jednotné datové platformy

Podniky, které přešly na jednotnou datovou platformu předtím, než začaly své agentic AI programy, rozšiřují rychleji než ty, které to neudělaly. Když Lakehouse, datový sklad, sémantický model a potrubí all žijí v jednom prostředí, jako v Microsoft Fabric, agenti mají jeden konzistentní povrch, na který se mohou dotázat. To odstraňuje celou třídu selhání, která pochází z agentů, kteří skáčou mezi systémy s rozdílnými schématy, rozdílnými cykly obnovy a rozdílnými definicemi stejné obchodní metriky.

To je důvod, proč platformy, které podniky zvolí pro datovou unifikaci, jsou tak důležité pro jejich agentic AI výsledky. Jednotný přístup Microsoft Fabric spojuje Lakehouse, datový sklad, sémantický model a potrubí v jednom prostředí, což dává podnikům, které jsou zaměřeny na Microsoft (MSFT ), strukturální výhodu při přechodu z experimentů do skutečného provozního použití.

Databricks dodává stejný princip prostřednictvím architektury Lakehouse a Unity Catalog, poskytující datovým a AI týmům jednotnou vrstvu governance napříč strukturovanými a nestrukturovanými daty s integrací MLflow pro sledování chování modelu v produkci. Snowflake’s přístup využívá jeho Cortex AI a těsné spojení mezi datovým cloudem a AI inferencí, umožňující podnikům spouštět agentní úlohy přímo proti spravovaným, živým datům bez latence a rizika konzistence, která pochází z přesunu dat mezi systémy.

Každá z těchto platforem představuje jiný přístup k stejnému výsledku. Datová vrstva, která je koherentní, pozorovatelná a důvěryhodná enough, aby podporovala rozhodování agentů ve velkém měřítku. Správná volba závisí na stávající infrastruktuře podniku. Co není volitelné, je udělat tu volbu a zavázat se k ní, než se agentní vrstva postaví na jejím základě. Co odděluje týmy, které dělají pokroky, od těch, které jsou stále uvíznuté v pilotních projektech, není to, kterou platformu si vybraly. Je to to, že opravily datovou vrstvu jako první.

Governance předtím, ne potom

Governance postavená dodatečně není žádná governance. Když agent má downstream rozhodovací pravomoc a ochranné bariéry se přidávají šest měsíců po nasazení, podnik již nahromadil šest měsíců neauditovaných rozhodnutí. Auditní stopa musí být navržena předtím, než agent půjde naživu, ne retrofitted po prvním incidentu.

Stejný princip platí pro AI bezpečnost, role-based přístup a oprávnění. Agent bez řádně definovaných oprávnění může přistupovat k datům, ke kterým by neměl mít přístup, spouštět akce mimo jeho zamýšlenou hranici nebo se stát aktivním útočným povrchem. Tyto jsou rizika, která musí být řešena ve fázi vývoje, ne objevena při nasazení.

Pokud governance není vložena předtím, než jsou postaveny tréninkové potrubí, nesprávná nebo adversativní data mohou vstoupit do tréninkového procesu bez detekce. Model trénovaný na kompromitovaných datech funguje dobře na benchmarcích, ale driftuje v produkci, přesně ten druh tichého selhání, které je nebezpečné, když agentní rozhodnutí nesou skutečné obchodní důsledky.

EU AI Act a rostoucí regulační rámce kolem AI odpovědnosti dělají to těžší ignorovat a podniky, které nebudují governance do svých agentních architektur, nahromadí compliance expozici, která bude stát mnohem více, aby se později vyřešila.

Z pilotu do produkce: Co to skutečně vyžaduje

Podniky, které uzavírají produkční mezery, jsou ty, které opravily datovou vrstvu, než postavily agentní vrstvu. Vložily governance do designu, ne až poté, co byla škoda způsobena. Postavily pozorovatelnost do orchestrace a běžely změnové řízení paralelně s technickým doručením. Považují analýzu selhání za důležitý designový požadavek.

Deloitte’s enterprise AI research ukazuje, že přístup pracovníků k AI skočil o 50% v roce 2025 samotném a podíl společností, které běží více než 40% svých AI projektů v plné produkci, se má zdvojnásobit v příštích šesti měsících. Podniky, které vyhrávají právě teď, nejsou ty, které mají nejrozvinutější modely. Jsou to ty, které postavily provozní infrastrukturu, aby běžely AI spolehlivě, a udělaly to, než postavily agenty.

Každý podnik, který stále běží nespojené piloty, by se měl soustředit na to, aby zajistil, že investice do modelů a rozhraní je proporcionální k investici do datové připravenosti a governance architektury, která určí, zda tito agenti někdy opustí demo prostředí. To je místo, kde mnoho podniků selhává.

Dokud se to nezmění, mnoho agentic AI projektů, do kterých společnosti vložily zdroje a doufaly, že přinesou ovoce, zemře na révě.