Waarom Agentic AI-projecten stilvallen op grote schaal en wat ondernemingen eerst moeten verhelpen

Agentic AI wordt snel een cruciaal onderdeel van alle ondernemingen. Bedrijven voegen pilots toe aan hun operaties, demo-omgevingen imponeren leiders en wegenkaarten worden herschreven rond autonome AI-workflows.

Maar voor veel van deze projecten breekt er iets tussen de gecontroleerde demo en de productie-implementatie. Het project komt stil te liggen, implementaties strekken zich uit van maanden tot jaren en de teams die verantwoordelijk zijn voor de levering, moeten uitleggen waarom de agent die perfect werkte in het testen, onvoorspelbaar gedraagt in de echte wereld.

In bijna alle gevallen is het antwoord niet het model zelf, maar de data-estate, de orchestratielaag, het governance-kader en de legacy-infrastructuur die de meeste ondernemingen nooit hebben gemoderniseerd voordat ze besloten intelligentie-agents op te bouwen. Tot die fundamenten worden aangepakt, zal agentic AI blijven produceren demos die imponeren en implementaties die teleurstellen.

De POC-omgeving is een valkuil

De meeste ondernemingen evalueren modellen. Veel minder evalueren agent-gedrag eind-tot-eind. Een model kan zeer nauwkeurig zijn en de agent die erop is gebouwd, kan nog steeds ernstig falen. Dit komt doordat agents tool-calls keten en één slechte stap een verkeerd antwoord produceert dat de volgende stap als correcte invoer behandelt, waardoor de fout downstream wordt verergerd voordat iemand het opmerkt.

De proof-of-concept-omgeving is ontworpen om dit te verhullen. Invoer is gecontroleerd, het bereik is smal en iemand kijkt naar de uitvoer. Geen van deze voorwaarden bestaat in productie. De agent die goed scoorde in het testen, behandelt nu dubbelzinnige instructies, raakt permission-fouten en neemt sequentiële beslissingen op basis van data waarop hij nooit is getest. Het team dat het heeft gebouwd, ontdekt dat evaluatiekaders die zijn ontworpen voor modelprestaties, niet vertellen of een agent correct is geëscaleerd, een randgeval op een elegante manier heeft afgehandeld of wist wanneer hij moest stoppen.

Volgens McKinsey’s State of AI 2025-rapport, gebruiken 88% van de organisaties nu AI in tenminste één bedrijfsfunctie, maar slechts ongeveer een derde heeft het succesvol geschaald over de gehele onderneming. Die kloof tussen adoptie en schaal begint met hoe ondernemingen hun pilots scopen en evalueren. De teams die succesvol schalen, behandelen foutmodusanalyse als een ontwerpeis. Voordat ze implementeren, bouwen ze een catalogus van hoe de agent verwacht wordt te falen en wat de reactie is wanneer dit gebeurt. Dat klinkt voor de hand liggend. Zeer weinig ondernemingen doen dit echt.

Afvaldata, afvalagents

Ondernemingen blijven vragen waarom hun agents onderpresteren in productie. Het antwoord komt bijna altijd terug naar data. De data-estate was nooit klaar. Bronnen waren gefragmenteerd over tientallen systemen die op verschillende tijdstippen voor verschillende doeleinden zijn gebouwd. Definities waren inconsistent over bedrijfseenheden. Er was geen semantische laag. Er was geen enkele bron van waarheid. Er was alleen jaren van opgekropte data-schuld die niemand prioriteerde omdat de oude systemen goed genoeg functioneerden.

Die schuld verdwijnt niet wanneer u een agent opbouwt. Het wordt de operationele realiteit van de agent. Een agent die gefragmenteerde data-bronnen navigeert, redeneert niet over een coherent beeld van het bedrijf. Het doet zijn best met wat het kan vinden, verzoent tegenstrijdigheden op de fly en produceert uitvoer die plausibel lijkt totdat iemand die het bedrijf kent ernaar kijkt. De agent is niet kapot. De data die het kreeg, was kapot voordat het project begon.

Data-drift en concept-drift maken dit erger over tijd. Wanneer de echte invoer-verdeling verschuift van wat het model is getraind, gooit de agent geen fout. Het blijft draaien en begint verkeerde uitvoer te produceren, met vertrouwen en op grote schaal. Zonder een MLOps- of AIOps-pijplijn die is ingebouwd in de agent-orchestratielaag, is er geen mechanisme om dit te vangen voordat de schade zich verergert. De agent die acceptabel presteerde bij de lancering, degradeert stil over weken voordat iemand de uitvoerkwaliteit verbindt met een data-probleem dat er vanaf het begin was.

Data-modernisering en AI-modernisering worden vaak behandeld als parallelle werkstromen, onafhankelijk van elkaar en afzonderlijk gefinancierd. Ze zijn niet parallel. U kunt geen betrouwbare agent opbouwen op een data-architectuur die kapot was voordat het project begon. De volgorde is enorm belangrijk en het overslaan van de data-laag om sneller te gaan op de AI-laag is een van de meest voorkomende en kostbare fouten die ondernemingen maken.

Een verkeerd dashboard geeft iemand het verkeerde nummer. Een verkeerde agent-actie kan een downstream-proces triggeren voordat iemand het opmerkt, een factuur goedkeuren die niet had moeten worden goedgekeurd, een compliance-vlag incorrect routeren of prijzen aanpassen buiten het beoogde bereik. Agentic-systemen hebben purpose-built observability nodig, niet hergebruikte dashboards van algemene app-monitoring.

Het voordeel van een unified data-platform

Ondernemingen die zijn overgestapt op een unified data-platform voordat ze hun agentic AI-programma’s zijn gestart, schalen sneller dan die welke dat niet hebben gedaan. Wanneer de Lakehouse, data-warehouse, semantisch model en pijplijnen allemaal in één omgeving leven, zoals in Microsoft Fabric, hebben agents één consistent oppervlak om te bevragen. Dat verwijdert een hele klasse van fouten die voortkomen uit agents die tussen systemen met verschillende schema’s, verschillende refresh-cycli en verschillende definities van dezelfde bedrijfsmetric springen.

Dit is waarom de platforms die ondernemingen kiezen voor data-unificatie, zo veel betekenen voor hun agentic AI-resultaten. Microsoft Fabric’s unified aanpak brengt de Lakehouse, data-warehouse, semantisch model en pijplijnen samen in één omgeving, waardoor Microsoft (MSFT ) -georiënteerde ondernemingen een structureel voordeel hebben wanneer ze overstappen van experimenten naar echte operationele gebruik.

Databricks levert hetzelfde principe via de Lakehouse-architectuur en Unity Catalog, waardoor data- en AI-teams een unified governance-laag hebben over gestructureerde en ongestructureerde data met de MLflow-integratie om modelgedrag in productie te volgen. Snowflake’s aanpak maakt gebruik van zijn Cortex AI en de nauwe koppeling tussen de data-cloud en AI-inferentie, waardoor ondernemingen agent-workloads rechtstreeks kunnen uitvoeren tegen beheerde, live data zonder de latentie- en consistentie-risico’s die voortkomen uit het verplaatsen van data tussen systemen.

Elk van deze platforms vertegenwoordigt een andere weg naar hetzelfde resultaat. Een data-laag die coherent, observeerbaar en betrouwbaar genoeg is om agent-beslissingen op grote schaal te ondersteunen. De juiste keuze hangt af van de bestaande stack van de onderneming. Wat niet optioneel is, is die keuze maken en zich eraan committeren voordat de agent-laag wordt opgebouwd. Wat de teams die vooruitgang boeken, onderscheidt van die welke nog steeds vastzitten in pilots, is niet welk platform ze hebben gekozen. Het is dat ze de data-laag eerst hebben gefixeerd.

Governance voor, niet na

Governance die na de feiten is opgebouwd, is geen governance. Wanneer een agent downstream-beslissingsbevoegdheid heeft en guardrails worden toegevoegd zes maanden na implementatie, heeft de onderneming al zes maanden aan niet-geauditeerde beslissingen verzameld. De audit-trail moet worden ontworpen voordat de agent live gaat, niet naderhand worden aangepast.

Hetzelfde principe geldt voor AI-beveiliging, role-based toegangscontrole en permissions-scoping. Een agent zonder goed gescopeerde machtigingen kan data toegang die het niet zou moeten hebben, acties buiten zijn beoogde grenzen uitvoeren of een actief aanvalsoppervlak worden. Dit zijn risico’s die moeten worden aangepakt in de ontwikkelingsfase, niet ontdekt tijdens de implementatiebeoordeling.

Als governance niet wordt ingebed voordat trainingspijplijnen worden opgebouwd, kan onjuiste of vijandige data ongemerkt de trainingsprocedure binnendringen. Een model dat is getraind op gecompromitteerde data presteert goed op benchmarks, maar dwaalt af in productie, precies het soort stille fouten dat het gevaarlijkst is wanneer agent-beslissingen echte bedrijfsconsequenties hebben.

De EU AI-wet en groeiende regelgevingskaders rond AI-aansprakelijkheid maken het moeilijker om dit te negeren en ondernemingen die geen governance hebben ingebouwd in hun agent-architectuur, verzamelen compliance-risico’s die later veel meer zullen kosten om te ontrafelen.

Van pilot naar productie: wat het eigenlijk kost

De ondernemingen die de productiegap sluiten, zijn die welke de data-laag fixen voordat ze de agent-laag opbouwen. Ze bouwen governance in het ontwerp, niet na de schade is aangericht. Ze bouwen observability in de orchestratie-architectuur en voeren wijzigingsbeheer parallel met technische levering uit. Ze behandelen foutmodusanalyse als een belangrijke ontwerpeis.

Deloitte’s ondernemings-AI-onderzoek toont aan dat toegang van werknemers tot AI met 50% is gestegen in 2025 alleen en het aandeel bedrijven dat meer dan 40% van hun AI-projecten in volle productie uitvoert, zal in de komende zes maanden verdubbelen. De ondernemingen die nu winnen, zijn niet die met de meest geavanceerde modellen. Ze zijn degenen die de operationele infrastructuur hebben opgebouwd om AI betrouwbaar te laten draaien en deden dit voordat ze de agents opbouwden.

Elke onderneming die nog steeds losse pilots draait, moet zich richten op het waarborgen dat de investering in modellen en interfaces evenredig is met de investering in data-klaarheid en governance-architectuur die zal bepalen of die agents ooit uit de demo-omgeving komen. Dit is waar veel ondernemingen falen.

Totdat dit verandert, zullen veel van de agentic AI-projecten waarin bedrijven middelen hebben gestoken en die hadden gehoopt vruchten zouden afwerpen, op de wingerd sterven.