Waarom Enterprise AI-piloten stilvallen voordat ze in productie gaan: het is de harnas, niet het model

Het model was nooit het moeilijke deel. Vanuit de build wordt productie gewonnen of verloren in de laag eromheen: ophalen, gronding, routing en evaluatie.

Elke grote enquête over enterprise AI beschrijft nu hetzelfde probleem: organisaties kunnen toegang krijgen tot modellen, pilots uitvoeren en iets indrukwekkends demonstreren, en vervolgens bereikt bijna niets van dat alles de productie. De rapporten beschrijven die kloof vanuit het perspectief van de buitenkant, via executives die vragenlijsten beantwoorden. Dit is het perspectief van de andere kant: vanuit de builds, waar pilots óf overgaan naar productie óf stilvallen.

De kloof die iedereen meet

De cijfers zijn vertrouwd geworden. Deloitte’s State of AI in the Enterprise vond dat toegang tot AI nu bijna universeel is, maar slechts ongeveer een kwart van de organisaties zelfs maar 40% van hun experimenten in productie krijgt, en ongeveer één op de vijf meldt volwassen governance voor autonome agenten. MIT’s Project NANDA stelde het nog scherper: bij honderden inzetten leverde de overgrote meerderheid geen meetbaar financieel rendement op. Gartner heeft voorspeld dat een groot deel van de generatieve AI-projecten na de proof-of-concept-fase zal worden stopgezet, vanwege slechte gegevenskwaliteit, stijgende kosten en onduidelijke bedrijfswaarde.

Stapel deze bevindingen op en een enkel patroon komt naar voren. De bottleneck ligt niet in de toegang tot capabele modellen. Dat probleem is opgelost. De bottleneck ligt in de afstand tussen een model dat werkt in een demo en een systeem dat werkt in productie, elke keer, voor elke gebruiker, onder echte belasting, met echte gevolgen voor fouten.

Een voorbehoud dat duidelijk moet worden gesteld: veel pilots komen nooit tot stand om redenen die niets te maken hebben met techniek: geen echte businesscase, geen bruikbare gegevens, geen executive sponsor, of een totale kosten die niemand heeft gemodelleerd. Zet die opzij. Wat volgt gaat over de grote en frustrerende set pilots die technisch echt zijn, overtuigend demonstreren en een echte use case achter zich hebben, en die nog steeds stilvallen op weg naar productie. Voor die pilots is de beslissende factor bijna nooit het model.

Wat de enquêtegegevens je niet kunnen vertellen, is wat die afstand daadwerkelijk overbrugt. Dat antwoord leeft niet in een vragenlijst. Het leeft in de technische beslissingen die worden genomen na de demo die iedereen imponeren, en voordat het systeem wordt vertrouwd met echte klanten.

Het patroon: de beslissende fix is bijna nooit het model

Bij de enterprise AI-inzetten waarover wij kunnen spreken, geldt een consistent patroon: wanneer een stilgevallen pilot uiteindelijk de productie bereikte, was de verandering die het daar bracht zelden een beter model. Het was de laag rond het model: hoe informatie wordt opgehaald en geaard, hoe uitvoer wordt gecontroleerd voordat deze een gebruiker bereikt, hoe werk wordt gerouteerd naar het juiste model in plaats van het meest krachtige, en hoe het hele systeem continu wordt geëvalueerd.

Wij noemen dit de harnaslaag. Een agent, in praktische zin, is een model met toegang tot tools, en de harnas is alles wat bepaalt hoe dat model context opvraagt, die tools gebruikt en verantwoordelijk wordt gehouden voor wat het produceert: ophalen, gronding, modelrouting, beveiligingshekken en evaluatie. Deze componenten werken niet in isolatie. Je moet ze combineren, opzettelijk, voor een specifiek use case. Die gecombineerde discipline is wat wij noemen agentharnas, en dat is waar productiereadiness daadwerkelijk wordt gewonnen of verloren.

Dit herdefinieert de proof-of-concept-valkuil. Teams komen stil te staan omdat ze blijven optimaliseren wat al werkt. Ze wisselen een nieuw model in, herschrijven prompts en wachten op de volgende frontier-release, terwijl de echte foutpunten één laag verderop zitten, in de delen van het systeem die een demo nooit belast.

Gronding, niet een slimmer model, is wat een agent veilig genoeg maakt om te verzenden

Overweeg een aanbevelings- en adviesassistent die wij bouwden in de verzekeringssector, een domein waar een zelfverzekerde verkeerde antwoord geen fout is, maar een aansprakelijkheid. De eerste impuls in zulke gevallen is om te grijpen naar het meest capabele beschikbare model en te veronderstellen dat capaciteit veiligheid koopt. Dat doet het niet. Een meer vloeiend model produceert meer overtuigende hallucinaties, wat in een gereguleerd kader slechter is, niet beter.

Wat het systeem verzendbaar maakte, was de harnas: een ophalingsontwerp dat alleen trok uit beheerde, tenant-veilige bronnen; grondingcontroles die gegenereerde claims verifieerden tegen die bronnen voordat iets een gebruiker bereikte; en een verificatiestap die liever afzag dan iets onondersteund beweerde. Het resultaat was een gemeten reductie van hallucinaties van 80 tot 90 procent tegen een LLM-only-basissituatie, met grondingnauwkeurigheid boven 95 procent, terwijl sub-twee-seconde P95-latentie werd behouden, zodat de veiligheidslaag het systeem nooit langzaam liet aanvoelen.

De tegenintuïtieve les voor iedereen die veiligheid nog steeds gelijkstelt aan modelkeuze: de gronding- en verificatielaag is de governance. Beleidsdocumenten en goedkeuringscommissies tellen, maar ze stoppen een model er niet mee om feiten te verzinnen op het moment van inferentie. Een ophalings- en verificatieharnas doet dat wel. In onze inzetten is de technische grondinglaag het echte governance-mechanisme: de plek waar “de AI mag niets verzinnen” ophoudt een principe te zijn en een afgedwongen eigenschap van het systeem wordt.

Modelrouting, niet modelselectie, is waar AI-kosten worden beslist

De tweede plek waar pilots stilvallen is de budgetbeoordeling. Een systeem kan prachtig werken en toch worden geannuleerd wanneer de per-token-economie, vermenigvuldigd over duizenden gebruikers en tientallen use cases, uitgroeit tot een totale kostenprobleem dat niemand van tevoren heeft gemodelleerd.

Hier geldt ook hetzelfde instinct, één sterk model kiezen en alles daar doorheen routeren, is de fout. De meeste enterprise-werklasten zijn een mengsel: een groot deel van de verzoeken is routine, en een klein deel is echt moeilijk. Elk verzoek naar een frontier-model sturen betekent betalen voor frontier-prijzen voor triage-werk dat een kleiner, goedkoper model perfect aankan.

In een migratie die wij uitvoerden van een derden LLM-API naar Amazon Bedrock , kwamen de voordelen voort uit het opnieuw ontwerpen van de modellaag in plaats van het model te wisselen. Elk taak routeren naar het passende modelniveau, in combinatie met Bedrock-native kosten- en governancecontroles, leverde een reductie van 42 procent in AI-infrastructuurkosten en 60 procent snellere compliant contentgeneratie op, zonder de applicatie opnieuw te hoeven bouwen.

Verleng dat principe en het compoundt. Een gestructureerde “adviseur” architectuur, goedkope modellen die de meeste verzoeken afhandelen en frontier-modellen die zijn gereserveerd voor de gevallen die deze echt nodig hebben, verandert routing van een eenmalige besparing in een structurele.

Dit patroon heeft de enterprise AI-kosten met 60 tot 80 procent verlaagd voor agentoperaties, en met tot 85 procent in sommige inzetten. Het punt is niet het kopletterpercentage; het is dat de kosten van een AI-systeem worden bepaald door de architectuur, niet door het gekozen model.

Waarom dit onzichtbaar is in de enquêtegegevens

Niets hiervan komt schoon naar voren in een enquête, omdat enquêtes executives vragen over resultaten, niet engineers over mechanismen. “Heeft uw pilot de productie bereikt?” is een ja/nee die een executive kan beantwoorden. “Wat heeft het daar precies gebracht?” is een vraag die alleen het build-team kan beantwoorden, en het antwoord is zelden “we vonden een beter model”. Het is bijna altijd een variant van “we hebben de laag rond het model gefixt”.

Die mismatch verklaart de vreemde persistentie van de proof-of-concept-valkuil. De industrie blijft een modelprobleem diagnosticeren en modeloplossingen kopen, terwijl de werkelijke beperking zit in ophalen, gronding, routing en evaluatie: de onglamoureuze leidingen die geen demo laat zien en geen foundation-model-lancering adverteert.

Het verklaart ook waarom governance en leveringssnelheid niet de tegenpolen zijn die ze worden geacht te zijn. Het gebruikelijke verhaal behandelt governance als de rem op verzending. In onze ervaring is het dichter bij het tegenovergestelde: de gronding- en verificatiewerkzaamheden die een systeem beheersbaar maken, zijn hetzelfde werk dat het vertrouwd genoeg maakt om het aan echte gebruikers te tonen. Uitgevoerd op de harnaslaag is governance niet wat de build vertraagt. Het is wat de build laat verzenden.

Wat dit betekent als uw pilot stilvalt

Als u een generatieve AI-project heeft dat in de proof-of-concept-limbo zit, is de meest nuttige actie die u kunt ondernemen het weerstaan van de neiging om eerst naar het model te kijken. Het model is het deel dat het meest waarschijnlijk al goed genoeg is. Kijk in plaats daarvan naar de laag eromheen:

• Ophalen en gronding: antwoordt het systeem vanuit beheerde, verifieerbare bronnen, of improviseert het vanuit zijn training?
• Verificatie: wordt de uitvoer gecontroleerd voordat een gebruiker deze ziet, of gaat de vertrouwen van het model rechtstreeks door?
• Routing: betaalt elk verzoek frontier-prijzen, of wordt het werk gematcht met het goedkoopste model dat het goed kan doen?
• Evaluatie: wordt kwaliteit continu gemeten tegen uw eigen benchmarks, of werd het eenmaal in de demo gevalideerd en nooit daarna?

De organisaties die in 2026 van pilot naar productie overstappen, zijn niet diegenen met toegang tot de beste modellen. Iedereen heeft dat. Zij zijn degenen die begrepen dat het model nooit het moeilijke deel was, en die hun technische inspanningen in de harnas hebben gestoken, waar productie daadwerkelijk wordt gewonnen.