Waarom AI-pilots
blijven steken

Waardoor worden geslaagde AI-pilots zelden opgeschaald naar productie?

AI-pilots blijven steken door oorzaken die geen van alle technisch zijn: de pilot beantwoordt alleen of iets technisch kan, draait buiten het echte werkproces, heeft geen eigenaar voor de fase erna, rekent het beheer niet mee en vermijdt de organisatorische verandering. Een pilot toont haalbaarheid aan en geen waarde. Wat in de praktijk goed werkt, is vóór de start de te beantwoorden vraag, de stopcriteria, de opschaaleigenaar, de beheerraming en de benodigde verandering op één pagina vast te leggen.

Kunnen AI-pilots beter in de echte werkomgeving draaien dan in een aparte omgeving?

Ja, voor AI-pilots geldt als tegenmaatregel: liever een kleinere scope in de echte omgeving dan een grotere scope ernaast, met één team, echte data, het echte proces en echte koppelingen. Die opzet is trager in week één en aanzienlijk sneller in maand zes.

Moet de opschaaleigenaar van AI-pilots al voor de start bekend zijn?

Ja. De opschaaleigenaar van AI-pilots wordt aangewezen voordat de pilot begint: iemand uit de lijn, met budget en een plek in de pilotstuurgroep. Is die persoon niet te vinden, dan is dat zelf een belangrijke uitkomst.

Kunnen AI-pilots doorgaan als er in de organisatie niets mag veranderen?

Ja, maar de businesscase van AI-pilots wordt dan doorgerekend zonder de besparing die verandering vereist. Vaak blijft er dan een reële, kleinere waarde over, en dat is een eerlijker startpunt dan een belofte die later niet waargemaakt kan worden.

Bron: artikel van Dave Willemstein. Bijgewerkt: oktober 2026.

De pilotparadox

Pilots zijn ontworpen om risico te verlagen. Klein beginnen, leren, dan opschalen. In de praktijk doen ze vaak het tegenovergestelde: ze creëren de illusie van vooruitgang zonder dat er iets verandert. Een organisatie met zeven geslaagde pilots en nul productietoepassingen is verder van haar doel dan een organisatie met één toepassing die draait.

De oorzaken zijn opvallend consistent. Vijf stuks, en geen ervan is technisch.

Oorzaak 1: De pilot bewees de verkeerde vraag

De meeste pilots beantwoorden de vraag "kan dit technisch?". Dat antwoord is tegenwoordig bijna altijd ja, en daarmee is de pilot informatief noch besluitvormend.

De vragen die er wél toe doen: kost dit minder dan het oplevert bij honderd keer dit volume? Willen de mensen die ermee moeten werken dit gebruiken als niemand meekijkt? Kunnen we het beheren met de capaciteit die we hebben?

Tegenmaatregel: formuleer voor de start één vraag die de pilot moet beantwoorden, en formuleer die zo dat "nee" een mogelijk antwoord is. Als je vooraf niet kunt bedenken hoe een negatieve uitkomst eruitziet, ben je geen pilot aan het ontwerpen maar een demonstratie.

Oorzaak 2: De pilot draaide buiten het echte werk

Om snelheid te maken wordt een pilot vaak naast het bestaande proces gezet: een aparte omgeving, een selecte groep enthousiaste gebruikers, een losse dataset. Dat levert snel resultaat op en vertelt je niets over opschaalbaarheid.

Wat er dan misgaat bij opschaling: de integratie met het bronsysteem blijkt drie maanden werk, de doorsnee gebruiker heeft niet de context die de pilotgroep had, en de echte data is rommeliger dan de proefdataset.

Tegenmaatregel: liever een kleinere scope in de echte omgeving dan een grotere scope ernaast. Eén team, echte data, echt proces, echte koppelingen. Dat is trager in week één en aanzienlijk sneller in maand zes.

Oorzaak 3: Niemand is eigenaar van de fase erna

De pilot heeft een projectleider. Die is klaar bij oplevering. De lijnorganisatie heeft geen capaciteit ingepland, geen budget gereserveerd en geen doel waarin deze toepassing voorkomt.

Wat er dan gebeurt: de toepassing blijft draaien in pilotvorm, zonder beheer, tot hij omvalt of tot de licentie afloopt. Niemand besluit iets. Het verdampt.

Tegenmaatregel: wijs de opschaaleigenaar aan vóórdat de pilot begint, niet erna. Die persoon zit in de lijn, heeft budget en neemt deel aan de pilotstuurgroep. Als je die persoon niet kunt vinden, is dat op zichzelf een belangrijke uitkomst: blijkbaar is er geen plek in de organisatie waar deze waarde landt.

Oorzaak 4: Beheer is niet meegenomen

AI-toepassingen vragen doorlopend onderhoud: monitoring op kwaliteit, hertraining of herkalibratie, bijhouden van modelversies, een testset die actueel blijft. In de pilotfase doet het projectteam dat impliciet. Na oplevering doet niemand het.

Dit is de reden dat toepassingen die in maand één prima werkten, in maand acht stilletjes slechter presteren zonder dat iemand het merkt.

Tegenmaatregel: neem de beheerlast op in de businesscase, uitgedrukt in uren per maand en toegewezen aan een team. En voer tijdens de pilot minstens één keer een echte beheeractie uit (een hertraining, een modelupdate), zodat je weet wat het kost.

Oorzaak 5: De organisatie mocht niet veranderen

Dit is de diepste oorzaak en degene waar het minst over gesproken wordt. Een AI-toepassing die tijd bespaart, betekent dat mensen hun werk anders doen. Soms dat een functie verschuift. Soms dat een controlestap van de ene afdeling naar de andere gaat.

Pilots worden bewust zo ontworpen dat ze die vragen niet oproepen, want dan gaat het sneller. Bij opschaling komen ze allemaal tegelijk boven, en dan blijkt de businesscase alleen te kloppen als er ook echt iets verandert in de bezetting of de werkverdeling. Dat gesprek was niet voorbereid.

Tegenmaatregel: benoem bij de start welke organisatorische verandering nodig is om de waarde te realiseren, en check of daar draagvlak voor is. Als het antwoord is dat er niets mag veranderen, kun je de pilot nog steeds doen, maar reken de businesscase dan door zonder de besparing die verandering vereist. Vaak blijft er dan een reële, kleinere waarde over. Dat is een eerlijker startpunt dan een belofte die later niet waargemaakt kan worden.

Een pilotcontract van één pagina

Wat in de praktijk goed werkt: leg voor de start vijf dingen vast op één pagina, ondertekend door de opdrachtgever en de opschaaleigenaar.

• De vraag die deze pilot beantwoordt, met een meetbare drempel voor "geslaagd".
• De stopcriteria: bij welke uitkomst stoppen we, en wie besluit dat.
• De opschaaleigenaar: naam, en de afdeling waar de waarde landt.
• De beheerraming: hoeveel uur per maand kost dit na oplevering, en wie levert die uren.
• De benodigde verandering: wat moet er anders in het werk om de waarde te realiseren.

Deze pagina kost een uur om te maken en voorkomt het scenario waarin je een jaar later zeven geslaagde pilots hebt en niets in productie. Het grootste effect zit niet in het document zelf, maar in de gesprekken die je moet voeren om het ingevuld te krijgen. Dat is precies waar de blokkades zichtbaar worden, op het moment dat ze nog op te lossen zijn.