De pilotval
Het patroon is opvallend consistent. Een team bouwt in enkele weken iets dat werkt, de demo valt goed, en dan gebeurt er maanden niets. De pilot is niet mislukt, hij is blijven staan.
Dat komt doordat een pilot en een productiesysteem verschillende dingen zijn die op elkaar lijken. Een pilot moet aantonen dat iets kan. Een productiesysteem moet elke dag werken, ook als de bouwer op vakantie is, ook als het brondocument verandert, ook als een gebruiker iets doet wat niemand had voorzien.
De afstand daartussen wordt structureel onderschat, omdat de pilot juist alles wegneemt wat die afstand veroorzaakt: schone testdata, welwillende gebruikers, geen koppelingen, geen beheer.
Zes oorzaken verklaren het merendeel van de gevallen.
Oorzaak 1. Geen eigenaar met mandaat
De meest voorkomende, en de enige die zonder de andere vijf al fataal is.
Een pilot heeft vaak een enthousiaste initiatiefnemer. Voor productie is iets anders nodig: iemand die verantwoordelijk is voor de uitkomst, die budget kan vrijmaken, en die kan besluiten dat het proces verandert.
Herken het aan de vraag "wie besluit of we hiermee doorgaan". Als het antwoord een commissie is, of "dat moeten we nog bespreken", staat het project stil zonder dat iemand het merkt.
Los het op vóór de bouw. Wijs één persoon aan, met naam, en spreek af welk besluit die persoon zelfstandig neemt.
Oorzaak 2. Het datafundament houdt geen stand
De pilot draaide op vijftig zorgvuldig geselecteerde documenten. Productie draait op tienduizend, waarvan een deel verouderd, een deel dubbel en een deel dat niet iedereen mag zien.
Dat is geen schaalprobleem maar een kwaliteitsprobleem dat door schaal zichtbaar wordt. De pilot bewees dat het werkt op goede data; hij bewees niet dat jouw data goed is.
Het herkenbare signaal: de agent geeft in productie plotseling antwoorden die niemand kan thuisbrengen. Dat is bijna altijd een verouderd of onbedoeld document in de index.
De oplossing is de vier lagen goed neerzetten voordat je opschaalt, met een herinname die automatisch draait. Zie de gids over RAG.
Oorzaak 3. Geen adoptieplan
Een werkende oplossing die niemand gebruikt, levert precies nul op. Toch wordt adoptie vaak behandeld als iets dat na de bouw vanzelf komt.
Dat komt het niet. Mensen hebben een werkwijze die functioneert, en elke nieuwe stap concurreert met tijdsdruk. Zonder plan wint de oude werkwijze, ook als de nieuwe objectief beter is.
Wat wel werkt is bouwen mét de gebruikers in plaats van vóór ze. Wie tijdens de bouw heeft meegedacht en meegetest, verdedigt de oplossing later bij collega's.
Daarna een gefaseerde uitrol: eerst power users die ambassadeur worden, dan het bredere team, met expliciete ruimte voor twijfel. Weerstand die genegeerd wordt, verdwijnt niet maar wordt stil.
Bij Allianz en de Hogeschool van Amsterdam begon het traject daarom met opleiden per doelgroep, niet met techniek.
Oorzaak 4. Geen meetbaar succescriterium
Vraag na een pilot of hij geslaagd is en je krijgt meningen. Dat is het probleem.
Zonder vooraf vastgelegd criterium is er niets om een besluit op te baseren, en dan wordt er geen besluit genomen. Het project verdwijnt in de categorie "interessant, later verder".
Leg vóór de bouw drie dingen vast: wat je meet, wat de nulmeting is, en welke waarde "ga door" betekent. Bijvoorbeeld: het percentage tickets dat zonder tussenkomst correct wordt afgehandeld, nu nul, en doorgaan bij zestig procent.
Meet ook de kwaliteit, niet alleen het volume. Bij Drimble is de relevante vraag niet hoeveel tickets de agent afhandelt, maar hoeveel er correct en gepersonaliseerd worden afgehandeld.
Oorzaak 5. Geen beheerafspraak
Een pilot heeft geen beheer nodig, want de bouwer is er nog. Zodra die weg is, blijkt niemand verantwoordelijk voor iets dat elke dag draait.
Wat er zonder beheer gebeurt: het model wordt vervangen en de uitkomsten verschuiven, de koppeling breekt na een update van het bronsysteem, de kosten lopen op zonder dat iemand kijkt, en een gebruiker meldt een fout die al weken speelde.
Regel vóór livegang wie meldingen opvangt, wie mag wijzigen, hoe vaak er geëvalueerd wordt en wat er gebeurt bij een storing. Ook als je het intern belegt.
Het verschil met een supportcontract is wezenlijk: support wacht tot iets kapot is, beheer zorgt dat het beter wordt terwijl het draait.
Oorzaak 6. Compliance komt pas op het eind
De pilot draaide op testdata, dus niemand keek naar grondslag, bewaartermijnen of logging. Bij productie komt dat allemaal tegelijk op tafel, vaak bij de laatste toets vóór livegang, en dan is herbouwen duur.
De klassieker: een agent die prima werkt maar geen audit-trail heeft, waardoor niemand achteraf kan reconstrueren wat er gebeurde. Achteraf logging inbouwen betekent de architectuur openbreken.
Neem risicoclassificatie, gegevensbescherming en logging op in de ontwerpfase. Dat kost aan het begin dagen en aan het eind weken.
Sinds juli 2026 is dit landschap bovendien gewijzigd; zie de gids over de AI-verordening.
De vijf fasen die wel werken
De volgorde die wij aanhouden bij het uitrollen, na de bouw.
| Fase | Wat er gebeurt |
|---|---|
| 1. Begrijpen | Waar staat het team, wat leeft er, waar zit de twijfel |
| 2. Bouwen mét het team | Gebruikers denken en testen mee, zodat de oplossing van hen wordt |
| 3. Trainen op drie niveaus | Dagelijks gebruik, de motorkap, en zelf aanpassen |
| 4. Begeleid uitrollen | Power users eerst, daarna breder, met ruimte voor weerstand |
| 5. Meten en bijsturen | Gebruik en resultaat meten, bijsturen waar adoptie achterblijft |
Fase 2 doet het meeste werk en wordt het vaakst overgeslagen. Een oplossing die aan mensen wordt opgeleverd, moet worden verdedigd. Een oplossing die mét mensen is gebouwd, verdedigt zichzelf.
Wat je vóór de pilot vastlegt
Vijf regels die de meeste pilotvallen voorkomen, en die niets kosten.
- Eén eigenaar met naam en mandaat.
- Eén meetbaar succescriterium, met nulmeting.
- Drie testgebruikers die tijdens de bouw meekijken.
- Een besluitmoment met een datum, waarop doorgaan of stoppen wordt besloten.
- Een expliciete afspraak over wat er ná livegang gebeurt en wie dat doet.
Punt vier is de belangrijkste. Zonder besluitmoment stopt een pilot nooit officieel, en dan blijft hij bestaan als iets waar op teruggekomen wordt.
Stoppen is trouwens een prima uitkomst. Een pilot die aantoont dat een proces zich niet leent voor automatisering, heeft precies gedaan wat hij moest doen.