Hvorfor Agentic AI-prosjekter stopper på skala, og hva bedrifter må fikse først

Agentic AI er raskt på vei til å bli en kritisk komponent i alle bedrifter. Bedrifter inkorporerer piloter i sine operasjoner, demo-miljøer imponerer ledelsen og veikartene skrives om rundt autonome AI-arbeidsflyter.

Men for mange av disse prosjektene, skjer noe feil mellom den kontrollerte demoen og produksjonsutviklingen. Prosjektet stopper, utrullinger strekker seg fra måneder til år og teamene som er ansvarlige for leveringen, blir igjen med å forklare hvorfor agenten som fungerte perfekt i testing, oppfører seg uforutsigbart i den virkelige verden.

I nesten alle tilfeller, er svaret ikke modellen selv, men data-estaten, orkestreringslaget, styringsrammen og den legacy-infrastrukturen som de fleste bedrifter aldri fik modernisert før de bestemte seg for å bygge intelligente agenter på toppen av den. Før disse grunnene blir behandlet, vil agentic AI fortsette å produsere demoer som imponerer og utrullinger som skuffer.

POC-miljøet er en felle

De fleste bedrifter vurderer modeller. Langt færre vurderer agent-atferd fra ende til ende. En modell kan være svært nøyaktig og agenten bygget på toppen av den, kan likevel feile dårlig. Dette er fordi agenter kjeder verktyk-kall sekvensielt og ett dårlig skritt produserer et feilaktig svar som neste skritt behandler som korrekt innputt, og forverrer feilen nedover før noen legger merke til det.

POC-miljøet er designet for å skjule dette. Inndata er kontrollert, omfanget er smalt og noen overvåker utdataene. Ingen av disse betingelsene eksisterer i produksjon. Agenten som scoret bra i testing, håndterer nå tvetydige instruksjoner, treff permission-feil og tar sekvensielle avgjørelser på data den aldri ble testet mot. Teamet som bygde den, oppdager at vurderingsrammeverk designet for modell-ytelse, ikke forteller om agenten eskalerte riktig, håndterte en edge-case behagelig eller visste når den skulle stoppe.

Ifølge McKinsey’s State of AI 2025-rapport, bruker 88% av organisasjonene nå AI i minst én forretningsfunksjon, men bare om lag en tredjedel har lykkes å skala det over hele bedriften. Den gapet mellom adopsjon og skala starter med hvordan bedrifter omfavner og vurderer sine piloter. Teamene som skalerer med suksess, behandler feilmodus-analyse som en design-krav. Før utrullingen, bygger de en katalog over hvordan agenten forventes å feile og hva responsen er når den gjør det. Det høres selvinnlysende ut. Veldig få bedrifter gjør faktisk det.

Skralle data, skralle agenter

Bedrifter fortsetter å spørre hvorfor deres agenter underpresterer i produksjon. Svaret kommer nesten alltid tilbake til data. Data-estaten var aldri klar. Kilder var fragmentert over dusinvis av systemer bygget på ulike tidspunkter for ulike formål. Definisjoner var inkonsistente over forretningsenheter. Det var ingen semantisk lag. Det var ingen enkelt kilde til sannhet. Det var bare år med akkumulert data-gjeld som ingen prioritet på grunn av at de gamle systemene fungerte godt nok.

Den gjelden forsvinner ikke når du bygger en agent på toppen av den. Den blir agentens operative virkelighet. En agent som navigerer i fragmenterte data-kilder, er ikke resonerende over et konsistent bilde av bedriften. Den gjør sitt beste med det den kan finne, og produserer utdata som ser plausibelt ut til noen som kjenner bedriften. Agenten er ikke feil. Data den ble gitt, var feil før prosjektet startet.

Data-drift og konsept-drift gjør dette verre over tid. Når den virkelige inndatafordelingen skifter fra det modellen ble trent på, kaster agenten ikke en feil. Den fortsetter å kjøre og begynner å produsere feil utdata, selv med full tillit og i skala. Uten en MLOps eller AIOps-pipeline bygget inn i agent-orkesstrasjonslaget, er det ingen mekanisme for å fange dette før skaden akkumuleres. Agenten som fungerte akseptabelt ved lansering, degraderer stille over flere uker før noen kobler utdatakvaliteten til et data-problem som var der fra begynnelsen.

Data-modernisering og AI-modernisering behandles ofte som parallele arbeidsstrømmer, sekvensert uavhengig og finansiert separat. De er ikke parallele. Du kan ikke bygge en pålitelig agent på toppen av en data-arkitektur som var feil før prosjektet startet. Sekvensen betyr enormt og å hoppe over data-laget for å gå raskere på AI-laget, er en av de vanligste og dyreste feilene bedrifter gjør.

En feil dashboard gir noen feil tall. En feil agent-handling kan utløse en nedstrøms prosess før noen legger merke til det, og godkjenne en faktura som ikke burde være godkjent, eller justere prising utenfor dens mentete område. Agent-systemer trenger formål-bygget overvåkning, ikke resirkulerte dashboards fra generell app-overvåking.

Fordelen med et samlet data-plattform

Bedrifter som flyttet til et samlet data-plattform før de startet sine agentic AI-programmer, skalerer raskere enn de som ikke gjorde det. Når Lakehouse, data-warehouse, semantisk modell og pipelines alle bor i ett miljø, som de gjør i Microsoft Fabric, har agenter en konsistent overflate å spørre. Det fjerner en hel klasse feil som kommer fra agenter som hopper mellom systemer med ulike skjema, ulike oppdaterings-sykluser og ulike definisjoner av samme forretnings-måling.

Dette er hvorfor plattformene bedrifter velger for data-samordning, betyr så mye for deres agentic AI-resultater. Microsoft Fabrics samlede tilnærming bringer sammen Lakehouse, data-warehouse, semantisk modell og pipelines i ett miljø, og gir Microsoft (MSFT ) -sentriske bedrifter en strukturell fordel når de flytter fra eksperimentering til virkelig operasjonell bruk.

Databricks leverer samme prinsipp gjennom Lakehouse-arkitekturen og Unity Catalog, og gir data- og AI-team en samlet styringslag på tvers av strukturert og ustrukturert data med MLflow-integrasjon for å spore modell-atferd i produksjon. Snowflakes tilnærming utnytter sin Cortex AI og dens tette kobling mellom data-sky og AI-inferens, og lar bedrifter kjøre agent-arbeidslast direkte mot styrt, live-data uten latens- og konsistens-risiko som kommer fra å flytte data mellom systemer.

Hver av disse plattformene representerer en annen vei til samme resultat. Et data-lag som er konsistent, overvåket og pålitelig nok til å støtte agent-beslutning på skala. Riktig valg avhenger av bedriftens eksisterende stack. Det som ikke er valgfritt, er å gjøre det valget og å binde seg til det før agent-laget bygges på toppen. Det som skiller teamene som gjør fremgang fra de som fortsatt er fast i piloter, er ikke hvilken plattform de valgte. Det er at de fikset data-laget først.

Styring før, ikke etter

Styring bygget etter faktum, er ikke styring i det hele tatt. Når en agent har nedstrøms beslutningsmyndighet og retningslinjer legges til seks måneder inn i utrullingen, har bedriften allerede akkumulert seks måneder med uauditerte beslutninger. Audit-sporingen må være designet før agenten går live, ikke retrofittet etter den første hendelsen.

Samme prinsipp gjelder for AI-sikkerhet, rolle-basert tilgangskontroll og tillatelser. En agent uten riktig skaledde tillatelser, kan aksessere data den ikke burde, utføre handlinger utenfor dens mentete grenser eller bli et aktivt angreps-overflate. Disse er risikoer som må bli behandlet i utviklingsfasen, ikke oppdaget under utrullings-gjennomgangen.

Hvis styring ikke er innbygget før trening-pipelines bygges, kan feil eller motstridende data komme inn i treningsprosessen uoppdaget. En modell trent på kompromittert data, performer bra på benchmark, men drifter i produksjon, nøyaktig den typen stille feil som er farligst når agent-beslutninger bærer virkelige forretnings-konsekvenser.

EU sin AI-akt og voksende reguleringer rundt AI-ansvar, gjør det vanskeligere å ignorere, og bedrifter som ikke har bygget styring inn i sine agent-arkitekturer, akkumulerer compliance-eksponering som vil koste betydelig mer å løse senere.

Fra pilot til produksjon: Hva det faktisk tar

Bedrifter som lukker produksjons-gapet, er de som fikser data-laget før de bygger agent-laget. De bygger styring inn i designet, ikke etter skaden er skjedd. De bygger overvåkning inn i orkestrerings-arkitekturen og kjører endrings-styring parallelt med teknisk leveranse. De behandler feilmodus-analyse som en viktig design-krav.

Deloittes bedrifts-AI-forskning viser at arbeidstager-tilgang til AI økte 50% i 2025 alene og andelen av bedrifter som kjører mer enn 40% av sine AI-prosjekter i full produksjon, er satt til å dobles i de neste seks månedene. Bedrifter som vinner nå, er ikke de med de mest avanserte modellene. De er de som bygde den operasjonelle infrastrukturen for å kjøre AI pålitelig og gjorde det før de bygde agentene.

Hvert enkelt bedrift som fortsatt kjører separate piloter, bør fokusere på å sikre at investeringen i modeller og grensesnitt er proporsjonal med investeringen i data-klarhet og styrings-arkitektur som vil bestemme om agentene noen gang kommer ut av demo-miljøet. Dette er hvor mange bedrifter feiler.

Før det endrer seg, vil mange av de agentic AI-prosjektene bedrifter har pumpet ressurser inn i, og håpet ville bære frukt, dø på vinran.