Van AI-pilot tot AI in productie

De meeste bedrijven hebben inmiddels een pilot gedraaid. Sommige meerdere. Het patroon herhaalt zich: een klein team kiest een use case, wrapper een model, demo't het voor de leiding, krijgt applaus, en stilt dan ergens tussen 'dit werkt in staging' en 'we kunnen dit shippem'.

Volgens een McKinsey-onderzoek uit 2024 zegt 79% van directeuren dat AI-adoptie hen pijn veroorzaakt. Gartner rapporteert dat slechts 31% van organisaties een formeel meetframework voor production agents heeft. Zet die twee getallen naast elkaar en het probleem wordt duidelijk. De pilots draaien overal. De production discipline vrijwel nergens.

Dit is geen capability-gat. De modellen zijn goed genoeg. De tooling volwassen genoeg. Wat ontbreekt is de vakkundigheid om een experiment om te zetten in iets waar je je kwartaal op durft in te zetten.

Waarom pilots stilvallen aan de drempel

Een pilot is ontworpen om één vraag te beantwoorden. kan dit werken? Het mag fragiel zijn. Iemand let erop. Iemand grijpt in als het half werkt. Iemand checkt handmatig de output voordat het iets echts aanraakt.

Production is een ander contract. Niemand let op elke run. Fouten zijn stil. Kosten stapelen zich op. Gebruikers vormen gewoontes rond het systeem, goed en slecht. En als iets misgaat, moet je het binnen minuten weten, niet weken.

De kloof tussen die twee toestanden is geen sprint opruimen. Het is een ander denken over wat je hebt gebouwd. De meeste teams slaan dat overdenken over omdat de pilot zo veelbelovend leek. Precies daar begint de narigheid.

Er is ook een organisatorische trek naar de demo. Een werkende demo is zichtbaar. Het wekt enthousiasme. Production readiness is onzichtbaar tot het moment dat het voor een klant stukloopt. De prikkel om de demo te shippem en het af te schrijven is dus reëel, en het kost bewuste tegenstand om daar tegenin te gaan.

Drie dingen die tellen in de tweede helft van 2026

Na werk aan production agent-systemen langs meerdere client tracks, zijn het drie disciplines die bepalen welke systemen standhouden en welke stilletjes worden uitgeschakeld.

1. Een meetframework per agent, niet per product

De standaardmetriek voor de meeste live AI-features is adoption. Hoeveel gebruikers openden het. Hoeveel sessies. Hoeveel seats geactiveerd. Dat is een product-metriek, geen agent-metriek. Het zegt niets over of de agent doet wat je hebt gebouwd.

Bruikbare metreken liggen een niveau dieper. Task success rate: heeft de agent de toegewezen taak voltooid zonder dat een mens moet ingrijpen of het opnieuw doen? Tool call accuracy: wanneer de agent een functie of API aansprak, riep hij dan de juiste aan met de juiste argumenten? Cost per outcome: niet cost per token, niet cost per sessie, maar cost per eenheid werkelijke geleverde waarde.

Deze zijn moeilijker in te bouwen, vooral als je agent snel voor een demo in elkaar gezet is. Maar het zijn de enige getallen die je vertellen of het systeem zijn plaats in de stack verdient. Kies twee of drie voor je live gaat. Je kunt later altijd meer toevoegen. Met geen enkele metriek starten betekent blind vliegen.

2. Identiteit, audit logs, rollback en human override zijn de basis, niet het plafond

Elke production agent moet weten namens wie hij handelt, een spoor achterlaten van wat hij deed, omkeerbaar zijn als hij op slechte data werkt, en een duidelijk pad hebben voor een mens om in te grijpen en over te nemen.

Die vier dingen zijn geen compliance-checklist. Ze zijn de mechanische eigenschappen die een agent-systeem veilig op schaal maakt. Zonder ze kan één slechte run state beschadigen, een klant verkeerd berekenen, iets onherstelbaars verwijderen, of een downstream process starten die dagen kost om uit te spoelen.

De tegenwerping die ik meestal hoor is dat deze infrastructuur het team vertraagt. Dat doet het, licht, de eerste keer. Na de derde agent is het een tweeuur setup omdat de patronen al op hun plaats liggen. De kosten ervan achteraf na een incident in te bouwen zijn vele malen hoger.

Dit is dezelfde logica die version control onmisbaar maakte voor code. Niemand twistert erover meer. Audit logs en rollback voor agents krijgen daar ook toe. Teams die nu bouwen en deze als optioneel behandelen, lenen gewoon tijd.

3. ROI op outcome-niveau, niet op tool-niveau

Dit is waar veel business cases stilletjes ineenzakken. Een team bouwt een agent, meet de kosten ervan (compute, API calls, engineering tijd), vergelijkt dat met de licentiekosten van het SaaS-tool dat het vervangt, en roept het uit als winst.

Maar de tool-kosten waren nooit de echte kosten. De echte kosten waren de tijd die een persoon spendeerde aan een taak die een resultaat opleverde. De juiste vraag is: levert de agent dat resultaat sneller, nauwkeuriger en met minder downstream correcties op? Dat is een outcome. Dat is waar de ROI zit.

Meten op tool-niveau is comfortabel omdat de getallen makkelijk zijn op te halen. Meten op outcome-niveau vereist dat je definieert hoe een goed resultaat eruitziet, wat een gesprek over kwaliteit afdwingt waar veel teams nog niet klaar voor zijn. Voer dat gesprek voor je shipped. Het maakt alles scherper.

De production-mindset in de praktijk

Bij Studio Hyra zit dit werk in wat we Track B noemen. Track A is de snelle, gevestigde bouw: assisted coding, rapid prototyping, iets echts voor mensen krijgen binnen enkele weken. Track B is de discipline die volgt. Geen handoff, geen apart project. Hetzelfde denken, toegepast op de vraag of wat we hebben gebouwd echt betrouwbaar is in de tijd.

Die framing is belangrijk omdat het het gesprek met de klant verandert. Als Track A en Track B twee aparte projecten met twee aparte budgets zijn, stopt de klant vaak bij Track A en gaat ervan uit dat het werk klaar is. Als het twee fasen van dezelfde boog zijn, verschijnen de production-vragen vroeg, tijdens design, tijdens scaffolding, voor de demo zelfs klaar is.

Het 'Decision Making, Speed of Taste'-principe waarmee we werken is hier ook relevant. Fast taste is het vermogen om een beslissing te nemen zonder een analyse-cyclus van drie weken. In agent production betekent dat: je task success rate op een dinsdagochtend kunnen zien en tegen de middag kunnen besluiten of je de agent moet terugdraaien, een prompt moet afstemmen, of een tool call moet herrouten. Die snelheid van oordeel vereist dat de instrumentering al op zijn plaats ligt. Je kunt het niet halverwege een incident improviseren.

Wat deze maand te doen

Als je een pilot draait en nadenkt over het pad naar production, begin met drie vragen voor je een regel infrastructure-code schrijft.

Eerste. hoe ziet een succesvolle run van deze agent eruit, in één zin die een niet-engineer kan lezen? Als je die zin niet kunt schrijven, kun je het niet instrumenteren.

Tweede. wat is het ergste wat deze agent stilletjes kan doen? Een slechte email-draft is laag risico. Een write naar een customer record of een payment trigger niet. Kaarteer het risicoprofiel voor je beslist hoeveel override en rollback je echt nodig hebt.

Derde. wie voelt zich verantwoordelijk voor deze agent over zes maanden? Niet het team dat het bouwde. De persoon die gebeld wordt als het verloopt, die de logs leest, die beslist of het moet opnieuw trainen of vervangen. Als er geen naam aan die rol vastzit, is de agent niet production-ready ongeacht hoe goed de demo leek.

Die drie vragen kosten een middag. Ze sparen je maanden uit.