Hvorfor Agentic AI-projekter stopper på skala, og hvad virksomheder skal løse først

Agentic AI er hurtigt blevet en kritisk komponent i alle virksomheder. Virksomheder integrerer pilotprojekter i deres operationer, demo-miljøer imponerer ledelsen, og vejledninger skrives om på baggrund af autonome AI-arbejdsgange.

Men for mange af disse projekter sker der noget, der går galt mellem den kontrollerede demo og den faktiske produktion. Projektet stopper, udviklingen strækker sig fra måneder til år, og holdene, der er ansvarlige for leveringen, må forklare, hvorfor agenten, der fungerede perfekt under testningen, opfører sig upredsigeligt i den virkelige verden.

I næsten alle tilfælde er svaret ikke modellen selv, men data-estaten, orkestreringslaget, styrestrukturen og den arvede infrastruktur, som de fleste virksomheder aldrig fik moderniseret, før de besluttede at bygge intelligente agenter oven på den. Indtil disse fundamentale problemer er løst, vil agentic AI fortsætte med at producere demos, der imponerer, og installationer, der skuffeer.

The POC Environment Is a Trap

De fleste virksomheder evaluerer modeller. Få evaluere agentadfærd fra ende til anden. En model kan være meget præcis, og agenten, der er bygget oven på den, kan alligevel fejle meget. Dette skyldes, at agenter kæder værktøkskald sekventielt, og et dårligt skridt producerer et forkert svar, som det næste skridt behandler som korrekt input, hvilket forværrer fejlen nedstrøms, før nogen lægger mærke til det.

Proof-of-concept-miljøet er designet til at skjule dette. Inddata er kontrolleret, omfanget er snævert, og nogen overvåger outputtet. Ingen af disse betingelser findes i produktionen. Agenten, der scorede højt under testningen, håndterer nu tvetydige instruktioner, rammer tilladelsesfejl og træffer sekventielle beslutninger på baggrund af data, den aldrig blev testet imod. Holdet, der byggede den, opdager, at evalueringssystemer, der er designet til modelpræstation, ikke fortæller, om en agent eskalerer korrekt, håndterer en kanttilfælde smukt eller ved, hvornår den skal stoppe.

Ifølge McKinsey’s State of AI 2025 rapport, bruger 88% af organisationerne nu AI i mindst én forretningsfunktion, men kun omkring en tredjedel har succesfuldt skaleret det på tværs af virksomheden. Den kløft mellem adoption og skala starter med, hvordan virksomheder definerer og evaluerer deres pilotprojekter. Holdene, der skalerer succesfuldt, behandler fejlmodusanalyse som en designkrav. Før installationen bygger de en katalog over, hvordan agenten forventes at fejle, og hvilken respons der er, når det sker. Det lyder åbenlyst. Meget få virksomheder gør det faktisk.

Garbage Data, Garbage Agents

Virksomheder spørger hele tiden, hvorfor deres agenter underpræsterer i produktionen. Svaret kommer næsten altid tilbage til data. Data-estaten var aldrig klar. Kilder var fragmenterede på tværs af dusinvis af systemer bygget på forskellige tidspunkter til forskellige formål. Definitioner var inkonsistente på tværs af forretningsenheder. Der var ingen semantisk lag. Der var ingen enkelt sandheds kilde. Der var kun år af akkumuleret data-gæld, som ingen prioriterede, fordi de gamle systemer fungerede godt nok.

Den gæld forsvinder ikke, når man bygger en agent oven på den. Den bliver agentens operationelle virkelighed. En agent, der navigerer i fragmenterede datakilder, er ikke rationel over en koherent billed af forretningen. Den gør sit bedste med, hvad den kan finde, og producerer output, der ser plausibel ud, indtil nogen, der kender forretningen, ser nærmere på den. Agenten er ikke defekt. Data, den fik, var defekt, før projektet startede.

Data-drift og koncept-drift gør dette værre over tid. Når den virkelige inputfordeling skifter fra, hvad modellen blev trænet på, kaster agenten ikke en fejl. Den fortsætter med at køre og begynder at producere forkerte output, selv med tillid og i stor målestok. Uden en MLOps eller AIOps-pipeline bygget ind i agent-orkesreringslaget, er der ingen mekanisme til at fange dette, før skaden forværrer sig. Agenten, der fungerede acceptabelt ved lanceringen, nedgraderer stille over flere uger, før nogen kobler outputkvaliteten til et data-problem, der var der fra begyndelsen.

Data-modernisering og AI-modernisering behandles ofte som parallelle arbejdsstrømme, sekventeret uafhængigt og finansieret separat. De er ikke parallelle. Man kan ikke bygge en pålidelig agent oven på en data-arkitektur, der var defekt, før projektet startede. Sekvensen betyder enormt, og at springe data-laget over for at gå hurtigere på AI-laget er en af de mest almindelige og dyre fejl, virksomheder begår.

En forkert dashboard giver nogen det forkerte nummer. En forkert agent-handling kan udløse en nedstrøms-proces, før nogen lægger mærke til det, og godkender en faktura, der ikke burde være godkendt, eller router en compliance-markering forkert eller justerer priser uden for den intendrede rækkevidde. Agenterne behøver specialbygget overvågning, ikke genbrugte dashboards fra generel app-overvågning.

The Advantage of a Unified Data Platform

Virksomheder, der flyttede til en samlet data-platform før de startede deres agentic AI-programmer, skalerer hurtigere end de, der ikke gjorde. Når Lakehouse, data-warehouse, semantisk model og pipelines alle bor i ét miljø, som de gør i Microsoft Fabric, har agenter en konsekvent overflade at forespørge. Det fjerner en hel klasse af fejl, der kommer fra agenter, der hopper mellem systemer med forskellige skemaer, forskellige opdateringscykler og forskellige definitioner af samme forretnings-målepunkt.

Dette er hvorfor de platforme, virksomheder vælger til data-sammenlægning, betyder så meget for deres agentic AI-resultater. Microsoft Fabrics samlede tilgang bringer Lakehouse, data-warehouse, semantisk model og pipelines sammen i ét miljø, hvilket giver Microsoft (MSFT ) -centriske virksomheder en struktural fordel, når de flytter fra eksperimenter til reel operationel brug.

Databricks leverer samme princip gennem Lakehouse-arkitekturen og Unity Catalog, hvilket giver data- og AI-hold en samlet styre-lag på tværs af struktureret og ustruktureret data med MLflow-integrationen til at spore model-opførsel i produktion. Snowflakes tilgang udnytter dets Cortex AI og den tætte kobling mellem data-cloud og AI-inferens, hvilket tillader virksomheder at køre agent-arbejdslast direkte mod styret, levende data uden latency og konsistens-risici, der kommer fra at flytte data mellem systemer.

Hver af disse platforme repræsenterer en anden vej til samme resultat. Et data-lag, der er koherent, overvåget og pålideligt nok til at støtte agent-beslutninger i stor målestok. Det rette valg afhænger af virksomhedens eksisterende stack. Hvad der ikke er valgfrit, er at træffe dette valg og forpligte sig til det, før agent-laget bygges oven på. Hvad adskiller holdene, der gør fremskridt, fra dem, der stadig er fastlåst i pilotprojekter, er ikke, hvilken platform de valgte. Det er, at de fik løst data-laget først.

Governance Before, Not After

Styre, der er bygget efter faktum, er ikke styre overhovedet. Når en agent har nedstrøms beslutningsmyndighed og guardrails tilføjes seks måneder efter installationen, har virksomheden allerede akkumuleret seks måneders unauditerede beslutninger. Audit-stien skal være designet, før agenten går live, ikke retrofittet efter den første incident.

Samme princip gælder for AI-sikkerhed, rolle-baseret adgangskontrol og tilladelser. En agent uden korrekt definerede tilladelser kan få adgang til data, den ikke burde, udføre handlinger uden for dens intenderte grænse eller blive et aktivt angrebs-overflade. Disse er risici, der skal være adresseret i udviklingsfasen, ikke opdaget under installations-gennemgangen.

Hvis styre ikke er indbygget, før trænings-pipelines er bygget, kan forkert eller fjendtlig data komme ind i træningsprocessen uden opdagelse. En model, der er trænet på kompromitteret data, performer godt på benchmarks, men drifter i produktion, præcis den type stille fejl, der er farligst, når agent-beslutninger har virkelige forretnings-konsekvenser.

Den EU AI-lov og voksende reguleringer omkring AI-ansvarlighed gør det sværere at ignorere, og virksomheder, der ikke har bygget styre ind i deres agent-arkitekturer, akkumulerer compliance-eksponering, der vil koste betydeligt mere at løse senere.

From Pilot to Production: What It Actually Takes

Virksomhederne, der lukker produktions-gapet, er dem, der fik løst data-laget, før de byggede agent-laget. De indbyggede styre i designet, ikke efter skaden var sket. De byggede overvågning ind i orkestrerings-arkitekturen og kørte ændringsstyring parallelt med teknisk levering. De behandlede fejlmodusanalyse som et vigtigt design-krav.

Deloittes enterprise AI-forskning viser, at arbejdernes adgang til AI øgede med 50% i 2025 alene, og andelen af virksomheder, der kører mere end 40% af deres AI-projekter i fuld produktion, er sat til at fordobles i de næste seks måneder. Virksomhederne, der vinder lige nu, er ikke dem med de mest avancerede modeller. De er dem, der byggede den operationelle infrastruktur til at køre AI pålideligt og gjorde det, før de byggede agenterne.

Hver virksomhed, der stadig kører separate pilotprojekter, skal fokusere på at sikre, at investeringen i modeller og grænseflader er proportional med investeringen i data-klarhed og styre-arkitektur, der vil bestemme, om disse agenter nogensinde kommer ud af demo-miljøet. Det er her, mange virksomheder fejler.

Indtil det ændrer sig, vil mange af de agentic AI-projekter, virksomheder har investeret ressourcer i og håbede ville bære frugt, dø på stammen.