Van AI-pilot naar productie: waarom initiatieven blijven hangen en hoe u dat doorbreekt

De demo was overtuigend. De stuurgroep was enthousiast. Het model deed precies wat het moest doen. En toen: niets. Zes maanden later draait de proof-of-concept nog steeds op de laptop van een data scientist, en niemand durft de vraag te stellen wanneer het nu écht in gebruik gaat.

Dit patroon zien we in onze adviespraktijk vaker dan ons lief is. De overgang van proof-of-concept naar productie is in onze ervaring de fase waarin de meeste AI-initiatieven blijven hangen: niet de bouw, niet het model, maar de stap daarna. Het goede nieuws: de oorzaken zijn goed te benoemen, en een deel ervan voorkomt u door de PoC anders in te richten. Hieronder de redenen die we het vaakst tegenkomen, en wat u als beslisser anders kunt doen.

Herken de signalen dat uw pilot blijft hangen

Een pilot die aan het verzanden is, laat dat vroeg zien. De signalen zijn herkenbaar als u weet waarop u moet letten; onderstaand overzicht volgt de checklist van Innovecs:

• Elke maand “nog één modeltest”. Dit kan erop wijzen dat de succescriteria vooraf niet zijn vastgelegd. Zonder vaste lat is er altijd reden om door te testen.
• De demo werkt, het werkproces niet. Het model doet wat het moet doen, maar niemand heeft uitgewerkt waar in het dagelijkse proces de uitkomst landt en wie ermee werkt.
• Niemand weet wie de productie-eigenaar is. Het innovatieteam voelt zich klaar, de lijnorganisatie heeft nooit ja gezegd.
• Het opschonen van data stopt nooit. Een mogelijke verklaring is dat de datafundering niet op orde is en de pilot leunde op handwerk dat in productie niet schaalt.
• De security review begint pas aan het eind. Als governance pas laat aan tafel komt, kan een terechte blokkade van de uitrol het gevolg zijn.
• Er bestaat geen financiële maatstaf. Niemand kan zeggen wat de toepassing moet opleveren of kosten, dus kan niemand besluiten.

Onze vuistregel: herkent u meerdere van deze signalen, dan is het onverstandig erop te rekenen dat het vanzelf goed komt. Het probleem zit dan niet in het model.

De PoC bewijst het verkeerde

De afbakening die wij aanhouden: een proof-of-concept test technische haalbaarheid, een pilot toetst of iets in het echte werkproces standhoudt. Die begrippen worden per organisatie verschillend gebruikt, dus spreek aan het begin af wat u ermee bedoelt: die onnauwkeurigheid schept verwachtingen die een traject al vóór de start laten ontsporen.

Een geslaagde PoC bewijst dus vooral dat de techniek kán werken. Niet dat een investering in productie gerechtvaardigd is.

Veel PoC’s beginnen bovendien met een technologie-eerst-vraag: “wat kunnen wij met generatieve AI?” Als verkenning is dat prima. Als basis voor een productiebeslissing niet: daarvoor is een vooraf benoemd resultaat nodig: kosten omlaag, tijd besparen, betere beslissingen, hogere kwaliteit, of een kritiek proces schaalbaarder maken.

Zonder dat vastgelegde resultaat is het vervolg voorspelbaar. De PoC “slaagt”, iedereen knikt, en vervolgens maakt geen eigenaar budget vrij. Niet omdat het resultaat tegenviel, maar omdat niemand heeft afgesproken wat succes betekent en wie daar wat mee moet.

PoC en pilot zijn niet hetzelfde

In bestuurskamers worden de twee termen door elkaar gebruikt, en dat kost later tijd. Het onderscheid dat wij hanteren: een PoC test technische haalbaarheid; een pilot draait met echte gebruikers, echte werkprocessen en echte operationele randvoorwaarden, in een gecontroleerde maar productie-representatieve omgeving: één stap verwijderd van productie.

Wie een geslaagde PoC behandelt als een bijna-klaar product, slaat de fase over waarin veel praktische problemen aan het licht komen. Het risico is dan dat ze pas ná livegang zichtbaar worden, wanneer bijsturen aanzienlijk lastiger is.

De data was schoon: voor één keer

Een kloof die in onze ervaring vaak wordt onderschat, zit in de data. In veel PoC’s die wij tegenkomen is de data eenmalig handmatig verzameld, opgeschoond en klaargezet, door iemand die precies weet welke rare uitzonderingen eruit gefilterd moeten worden.

In productie is die luxe er meestal niet. Dan wilt u dat data betrouwbaar en herhaalbaar uit bronsystemen stroomt. Zijn de datastromen daarheen broos, dan is de uitkomst van het model dat ook, hoe goed het model zelf ook is. Breng transformaties daarom onder versiebeheer en maak de herkomst van data traceerbaar, van bronsysteem tot modeluitvoer.

Gaten in data governance horen bij de hardnekkigste oorzaken van vastgelopen trajecten die we tegenkomen. Vóór productie wilt u daarom antwoord op vragen als:

• Is de herkomst van data traceerbaar, van bronsysteem tot modeluitvoer?
• Zijn transformaties gedocumenteerd en beheerd, of leven ze in losse scripts?
• Wat gebeurt er als een bronsysteem verandert of een aanlevering uitblijft?
• Wie is eigenaar van de datakwaliteit, en weet die persoon dat zelf ook?

Als het antwoord op deze vragen “dat zoeken we later uit” is, dan is later nu.

Gebouwd als experiment, niet als systeemonderdeel

De pilots die stranden, zijn in onze ervaring vrijwel altijd gebouwd als geïsoleerd experiment in plaats van als onderdeel van een systeemlandschap. Een prototype kan haalbaarheid aantonen in een afgeschermde omgeving, maar mist dan de infrastructuur om echte variabiliteit, beveiligingseisen en operationele belasting aan te kunnen.

Productie stelt eisen die in de PoC-fase vaak minder aandacht kregen:

Integratie. Het model moet praten met bestaande systemen: zaaksystemen, ERP, klantportalen. Die koppelingen kosten in de praktijk vaak meer werk dan gedacht, zeker als beheerteams pas laat bij het initiatief betrokken raken.

Beveiliging en privacy. Belangrijk om scherp te hebben: de AVG geldt zodra u persoonsgegevens verwerkt, ook in een PoC of sandbox. Welke verplichtingen precies gelden, hangt af van onder meer uw rol, het doel, de grondslag en het risico; een DPIA is niet in alle gevallen verplicht. Werkt u in de PoC-fase al met echte persoonsgegevens, zorg dan dat de basis op orde is en laat u zich bij twijfel adviseren. Productie voegt daar doorgaans strengere operationele borging aan toe: uitgewerkte autorisaties, passende logging en beveiliging die bestand is tegen echt gebruik op schaal. Wat “passend” is, volgt uit risico en context, niet automatisch uit de wet.

Beheer en monitoring. Welke monitoring en beschikbaarheid nodig zijn, volgt eveneens uit risico en bedrijfsimpact: welke processen zijn straks afhankelijk van dit systeem, en welke serviceniveaus horen daarbij? Wie grijpt in bij afwijkend gedrag, en hoe merkt u dat überhaupt? Die vragen verdienen een antwoord vóór livegang.

Kosten op schaal. Infrastructuur- en verwerkingskosten bij groot gebruik zijn vooraf te modelleren of te testen. Doe dat vóór de productiebeslissing, niet erna, in een ongemakkelijk gesprek met de controller.

De organisatie deed niet mee

Techniek is lang niet altijd de enige reden dat AI-initiatieven blijven hangen. Adoptie door het team dat ermee moet werken is niet voor niets een van de vier gebieden die wij toetsen voordat een pilot naar productie gaat, naast datakwaliteit, infrastructuurkosten en beveiliging.

In veel PoC’s die wij zien, staan de medewerkers wier werkproces straks verandert grotendeels buitenspel. Als het resultaat dan wordt “uitgerold”, stuit het op terechte vragen: past dit in mijn werk, kan ik erop vertrouwen, wat gebeurt er als het fout zit?

Een AI-toepassing die het werkproces raakt, verschuift verantwoordelijkheden, of vraagt op zijn minst dat ze explicieter worden vastgelegd. Wie is aanspreekbaar op een beslissing die (mede) op modeluitvoer is gebaseerd? Zolang dat onduidelijk is, is het risico reëel dat medewerkers het systeem links laten liggen, en dat is begrijpelijk.

De les: betrek proceseigenaren en eindgebruikers niet ná de PoC, maar tijdens. Laat de pilot draaien in het echte werkproces, met echte gebruikers, en meet niet alleen of het model klopt maar ook of mensen het gebruiken.

Er is geen besliskader voor de volgende stap

Een patroon dat wij herkennen: de PoC eindigt in een presentatie, niet in een beslissing. Er is geen vooraf afgesproken drempel waarboven het initiatief doorgaat en waaronder het stopt. Het resultaat heeft een naam: pilot purgatory: de toestand waarin een werkende proof-of-concept nooit productie haalt, maar ook nooit formeel wordt gestopt.

Dat is schadelijk. Zo’n slepend initiatief blijft aandacht vragen en kan het vertrouwen in volgende initiatieven ondermijnen. Een eerlijk “nee, dit gaan we niet doen” is in onze ogen waardevoller dan een eeuwig “misschien”.

Een bruikbaar besliskader legt u vast vóór de PoC start. Een vorm die in onze ervaring goed werkt is financiële gating: pas opschalen als de gemodelleerde terugverdientijd een vooraf gestelde drempel haalt, geverifieerd met finance en niet alleen met het projectteam. Vertaald naar vier criteria:

• Businesscriterium: welk meetbaar effect rechtvaardigt de productie-investering, en wie toetst dat?
• Technisch criterium: welke prestaties moet het systeem halen onder realistische omstandigheden, niet alleen op de testset?
• Organisatorisch criterium: is er een eigenaar met budget en mandaat voor de productiefase?
• Stopcriterium: onder welke voorwaarden trekken we de stekker eruit, zonder gezichtsverlies voor betrokkenen?

Ontwerp de PoC alsof productie het doel is

De rode draad: de kloof tussen PoC en productie ontstaat meestal niet bij de overgang, maar bij de start. Een PoC die is ontworpen om te imponeren, levert een demo op. Een PoC die is ontworpen als eerste stap naar productie, levert kennis op die u in de volgende fase kunt hergebruiken.

Praktisch betekent dat:

Kies een use case met een eigenaar. Niet “iets met AI”, maar een concreet proces met een proceseigenaar die het resultaat wil en er verantwoordelijkheid voor neemt.

Test op representatieve data. Gebruik data zoals die er in productie uitziet, inclusief de rommel. Een model dat alleen op opgeschoonde data is getest, heeft haalbaarheid op nette data aangetoond, niet dat het in het echte werkproces overeind blijft.

Documenteer wat herbruikbaar is. Een goede PoC of pilot levert artefacten op die u in de volgende fase opnieuw nodig hebt: koppelprofielen, rol- en autorisatiemodellen, terugvalprocedures. Leg die vast terwijl u ze maakt, niet achteraf uit het geheugen.

Reken vooraf door wat productie kost. Niet op de euro nauwkeurig, maar wel de ordegrootte: infrastructuur, beheer, integratie, training van gebruikers. Zo verkleint u de kans dat de businesscase pas na de demo instort.

Plan de pilotfase in. Reserveer expliciet tijd en budget voor een pilot met echte gebruikers vóórdat u over productie beslist. Wie die fase overslaat, vergroot het risico dat problemen pas na livegang aan het licht komen.

Meet wat de business ziet

Pilots rapporteren vaak in modeltermen: nauwkeurigheid, precisie, recall. Voor een investeringsbesluit zijn die cijfers alleen onvoldoende. Beslissers willen weten wat het scheelt in doorlooptijd, handmatige uren, foutkosten of risico.

Dat vraagt om een nulmeting vóór de pilot start. Hoe lang duurt het proces nu? Hoeveel dossiers worden handmatig gecorrigeerd? Zonder die uitgangssituatie wordt het lastig na afloop iets aan te tonen; historische gegevens of een controlegroep kunnen soms uitkomst bieden, maar een vooraf vastgelegde nulmeting is de eenvoudigste route. Olakai noemt het vastleggen van een baseline vóór uitrol en een eerlijke berekening van de totale kosten als voorwaarden om van experiment naar businesscase te komen.

Wees daarbij eerlijk over de totale kosten. Een model dat in de pilot “bijna niets kost”, brengt in productie doorgaans kosten mee voor zaken als licenties, rekenkracht, beheeruren, hertraining en toezicht; welke precies, hangt af van de oplossing. Als de verwachte opbrengst alleen overeind blijft zolang u die kosten negeert, is dat informatie die u liever vroeg dan laat heeft.

Houd de rapportage simpel: welke prestatie-indicator van het werkproces beweegt, met hoeveel, en wat kost het om dat vol te houden. Daar kan een beslisser mee werken.

Van één pilot naar herhaalbaar opschalen

Organisaties die steeds nieuwe pilots starten zonder ooit iets in productie te brengen, leren van elk experiment iets, maar die lessen worden niet automatisch hergebruikt. De oorzaak zit in veel gevallen niet in de technologie, al kan die een harde beperking zijn. Master of Code komt op basis van marktdata en eigen praktijk tot de conclusie dat de beperking vooral in het operating model rond de technologie zit. In onze woorden: er ontbreekt een vaste manier van werken rond AI-initiatieven.

Wat daarbij helpt, is een aantal zaken standaardiseren:

• Eén intakeformat voor nieuwe ideeën, met verplichte velden voor proceseigenaar, succescriteria, benodigde data en de beoogde beslisser.
• Een vaste beslismomentstructuur, met het driekeuzebesluit (opschalen, repareren, stoppen) op een vooraf geplande datum.
• Een gedeelde datafundering, zodat niet elke pilot opnieuw begint met het bij elkaar schrapen en opschonen van bronnen.
• Een beheerstandaard voor modellen in productie: monitoring, logging, versiebeheer en een uitzetknop.

Dit klinkt als overhead, en voor de eerste pilot is het dat ook. De winst kan bij de tweede en derde toepassing komen, als de discussie over eigenaarschap en beheer niet meer van voren af aan hoeft te beginnen.

Eerlijk over de doorlooptijd

Nog één nuchtere kanttekening. Hoe lang de weg van PoC naar productie duurt, verschilt sterk per toepassing, maar datastromen robuust maken, integraties bouwen, beveiliging inrichten en gebruikers meenemen is serieus werk. Reken er niet op dat het vanzelf snel gaat, en plan er vanaf het begin realistisch voor.

Dat is geen reden om niet te beginnen. Het is een reden om klein te beginnen, met een use case die het waard is, en de randvoorwaarden vanaf dag één serieus te nemen.

De eerste stap: audit uw huidige PoC

Hebt u een AI-initiatief dat al maanden in de PoC-fase hangt? Plan dan geen nieuwe demo, maar een toetsingssessie van een dagdeel met de proceseigenaar, een data-verantwoordelijke, iemand van IT-beheer en iemand van finance.

Beantwoord samen dezelfde vier vragen: is de data-aanvoer productiewaardig te maken, wat kost draaien op schaal, voldoet het aan beveiligings- en privacy-eisen, en wie gaat het gebruiken en beheren? Op elke vraag waar geen antwoord komt, ligt uw eerstvolgende actie.

En durf de uitkomst te accepteren, ook als die “stoppen” is. Een afgeronde beslissing, in welke richting dan ook, geeft duidelijkheid en maakt aandacht en capaciteit vrij voor initiatieven die het wél waard zijn. Ontbreekt de capaciteit om die toets zelf te doen, dan helpt een AI-implementatiepartner die ook na de beslissing aan boord blijft.

Een voorbeeld waar de stap naar productie bijna altijd op verlichting en lijnvariatie stukloopt: AI-kwaliteitscontrole.

Waaraan u een partij herkent die de laatste stap maakt

De vraag “wie is hierin gespecialiseerd?” beantwoordt u het best door naar de werkwijze te kijken, niet naar de referentielijst. Zes kenmerken:

• De partij bouwt én beheert. Wie na oplevering vertrekt, heeft geen belang bij een systeem dat over drie jaar nog draait. Vraag welke systemen de partij nu in beheer heeft en sinds wanneer.
• De slaagvoorwaarde staat vooraf vast, als beslissing. Niet “het model haalt 90 procent nauwkeurigheid”, maar: welke beslissing gaat hierdoor anders, en wie neemt hem. Zonder die zin is er geen criterium om door te gaan.
• Er wordt een eigenaar aan de businesskant aangewezen. Iemand die het resultaat nodig heeft, niet iemand die het interessant vindt.
• Beheer zit in de begroting vanaf dag één. Een model blijft doen wat het deed; de werkelijkheid eromheen verandert wel. Dat vraagt monitoring op verschuivende data en een moment waarop iemand beoordeelt of hertrainen nodig is.
• De pilot draait op echte data, onder echte voorwaarden. Een demo op een schone export bewijst niets over koppelingen, persoonsgegevens en rechten. Wie dat pas in productie ontdekt, begint opnieuw.
• De partij durft te stoppen. In CRISP-DM valt in de fase Evaluation het besluit: naar productie, terug naar het model, of stoppen. Ook stoppen is een uitkomst; liever daar dan in beheer.

Hoe Twentynext dit doet

Onze dienst Projecten loopt van businessvraag tot werkende software, gebouwd door dezelfde mensen die het bedenken, inclusief de stap naar productie. Daarna kan Service & Beheer het overnemen, onder afspraken die op papier staan: wat we monitoren, hoe snel we reageren en wie verantwoordelijk is. Wat een vooraf vastgelegde maatstaf oplevert, laat ons onderzoek naar dagverse producten zien: op één versproduct in tien winkels steeg de winst met 4 tot 7 procent, alleen door de bestelinstellingen aan te passen. Dat is een uitkomst waar een besluit op kan volgen, en dat is wat een pilot hoort op te leveren.

Niet elk idee verdient een pilot. Maar wat een pilot krijgt, verdient vooraf een antwoord op de vraag wat er gebeurt als hij slaagt. Meer over dit vraagstuk staat op de pagina van pilot naar productie.

Heeft u een pilot die al te lang op productie wacht? Plan een kennismaking van 30 minuten; we reageren binnen één werkdag. Eerst weten waar uw organisatie staat met data? Doe de gratis Data Maturity Scan: zestien vragen, direct resultaat.

Zo maken we dit. AI schrijft de eerste versie, een tweede AI controleert, en een mens van Twentynext leest en keurt elk artikel goed voordat het live gaat. We controleren feiten en bronnen zorgvuldig, maar kunnen juistheid en volledigheid niet garanderen. Zie onze disclaimer.