AI van pilot naar productie: waarom de meeste pilots stranden en wat wél werkt

De demo was het makkelijke deel

De meeste AI-initiatieven in het bedrijfsleven volgen dezelfde boog: een pilot maakt indruk in een demo, het management keurt de volgende fase goed, en vervolgens brengt het project maanden door in een toestand die dood noch opgeleverd is. Volgens de meeste schattingen haalt ruim meer dan de helft van de pilots de productie nooit; onze projectervaring bevestigt dat. Het stokken ligt zelden aan het model. Het ligt aan alles wat de demo nooit hoefde te overleven — rommelige productiedata, vijandige invoer, kostenplafonds, auditvereisten en gebruikers die niet bij de kick-off zaten.

De correctie begint met een andere framing. Een pilot bewijst dat een capability bestaat. Productie vereist het bewijs dat een systeem zich acceptabel gedraagt onder echte belasting, met echte data en echte faalmodi — een probleem van systems engineering, niet van data science.

Selecteer use cases op de kosten van een fout

De meest bepalende beslissing valt voordat er één regel code is geschreven. Pilots die rond de indrukwekkendste demo zijn gebouwd, stranden meestal; pilots die rond een draaglijke faalmodus zijn gebouwd, halen het. Vier filters doen het meeste werk:

• Er bestaat een meetbare baseline — minuten per dossier, kosten per ticket, omvang van de werkvoorraad — zodat verbetering een getal is, geen mening.
• Fouten zijn herstelbaar: een fout concept wordt gereviewd, een foute classificatie wordt verderop gecorrigeerd, en geen enkele losse output veroorzaakt een onomkeerbare actie.
• Een menselijk controlepunt past van nature in de workflow, in plaats van er achteraf als compliance-verplichting aan vast te worden geplakt.
• Het volume is hoog genoeg dat een efficiëntiewinst van 30–50% de engineeringinvestering rechtvaardigt.

Let op wat ontbreekt: nieuwigheid. De beste eerste productie-use-case is meestal de minst glamoureuze.

Het datafundament bepaalt het plafond

Welke architectuur u ook kiest — retrieval-augmented generation, fine-tuning of gestructureerde extractie — het kwaliteitsplafond wordt bepaald door de data, niet door de modelkeuze. Drie fundamenten wegen het zwaarst. Ten eerste moet toegangscontrole worden afgedwongen op het moment van retrieval: als een gebruiker een document niet mag openen, mag het systeem het ook niet in een antwoord kunnen citeren, en geen enkele instructie op promptniveau vervangt rechtencontroles in de retrieval-laag. Ten tweede: actualiteit en herkomst. Het systeem moet weten welke versie van een beleid of prijslijst het leest, anders antwoordt het vol overtuiging op basis van verouderde data. Ten derde moet de omgang met gevoelige gegevens — het maskeren van persoonsgegevens, bewaartermijnen, eisen aan datalocatie — vóór de eerste integratie zijn ontworpen, want achteraf inbouwen betekent pipelines opnieuw bouwen.

Evaluatie scheidt demo's van systemen

De sterkste voorspeller die wij zien voor de vraag of een pilot doorbreekt naar productie, is het bestaan van een evaluatieharnas. Teams die kwaliteit beoordelen door outputs door te scrollen, kunnen de enige vraag die er in een review toe doet niet beantwoorden: heeft deze wijziging het systeem beter of slechter gemaakt?

• Bouw een golden dataset op uit echte cases — een paar honderd inputs met gecontroleerde verwachte uitkomsten — voordat u ook maar iets gaat tunen.
• Draai evaluaties bij elke prompt-, model- of retrieval-wijziging, in CI, precies zoals een regressietestsuite.
• Automatiseer de scoring waar mogelijk, maar kalibreer geautomatiseerde beoordelaars aan periodieke menselijke review, zodat de scores iets blijven betekenen.
• Volg kwaliteit in productie, niet alleen vóór de release: steekproefsgewijze menselijke review en gebruikersfeedback zijn onderdeel van het systeem, geen bijzaak.

Guardrails en integratiepatronen

In een productiearchitectuur is het model een onbetrouwbare externe afhankelijkheid en hoort het ook zo te worden geïntegreerd: time-outs, begrensde retries over idempotente operaties en een deterministisch terugvalpad voor wanneer het model faalt of degradeert. Begrens de interface aan beide kanten — valideer en saneer de invoer, eis schema-gebonden output die vóór gebruik wordt gevalideerd in plaats van vrije tekst die op hoop wordt geparst, en geef het model de smalste tool-toegang die de use case toelaat. Outputs die acties in gang zetten — schrijfacties, e-mails, transacties — gaan door een autorisatielaag die de modeloutput behandelt als niet-vertrouwde gebruikersinvoer, want dat is precies wat het is.

Een operating model, geen project

Pilots zijn projecten; productiesystemen zijn producten. Iemand moet na livegang eigenaar zijn van kwaliteit, kosten en incidenten: model- en promptversies worden vastgepind en alleen via review gewijzigd, de kosten per request worden gebudgetteerd en bewaakt, en er is een on-call-antwoord voor de nacht waarin de provider inzakt. Teams die dit eigenaarschap vóór livegang beleggen, houden hun systemen; teams die dat niet doen, zien de kwaliteit wegdrijven tot iemand de functie stilletjes uitzet.

Wat een gestrande pilot vlot trekt, is zelden een beter model. Het is een smallere use case, een echt evaluatieharnas, guardrails die van falen uitgaan en een eigenaar met een naam. Niets daarvan is glamoureus — en precies dat maakt van een demo infrastructuur.