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 voorkom je door de PoC anders in te richten. Hieronder de redenen die we het vaakst tegenkomen, en wat je als beslisser anders kunt doen.
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 je 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 wil je 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 wil je 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 je persoonsgegevens verwerkt — ook in een PoC of sandbox. Welke verplichtingen precies gelden, hangt af van onder meer je rol, het doel, de grondslag en het risico; een DPIA is niet in alle gevallen verplicht. Werk je in de PoC-fase al met echte persoonsgegevens, zorg dan dat de basis op orde is en laat je 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 merk je 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 leg je 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 je 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 je in de volgende fase opnieuw nodig hebt — koppelprofielen, rol- en autorisatiemodellen, terugvalprocedures. Leg die vast terwijl je 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 verklein je 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 je over productie beslist. Wie die fase overslaat, vergroot het risico dat problemen pas na livegang aan het licht komen.
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 je huidige PoC
Heb je 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 je 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.