Waarom AI-pilots blijven steken — en wat er wél werkt

Herken je dit?

De pilot draait. De demo overtuigde iedereen in de vergadering, het budget voor de volgende stap kwam er — en dat is maanden geleden. Sindsdien is het systeem “bijna klaar”. Niemand durft het aan echte processen te hangen, het team eromheen wordt er niet groter op, en langzaam verschuift de aandacht naar iets anders.

Dit patroon kom ik telkens tegen bij bedrijven die met AI begonnen zijn. Het ligt bijna nooit aan het model, en ook niet aan het idee: de use-case was meestal goed gekozen. Het ligt aan drie dingen die in de pilotfase geen probleem waren — en daarna precies het probleem zijn.

Gebouwd als demo, niet als systeem

Een pilot heeft één doel: laten zien dat iets kan. Voor dat doel zijn shortcuts volkomen logisch — alles in één script, instellingen hier en daar hardgecodeerd, de datastroom met de hand aangezet. In de demo zie je daar niets van.

Het probleem komt daarna. Een demo hoeft één middag te werken; een systeem moet elke dag werken, ook als niemand ernaast zit. Wie op het demo-fundament doorbouwt, merkt dat elke wijziging iets anders breekt, dat niemand meer precies weet waarom iets werkt, en dat “bijna klaar” een blijvende toestand wordt. De pilot is dan geen eerste versie van het systeem — het is een schets die per ongeluk in productie moest.

Klein beginnen is prima; dat adviseer ik zelf ook. Maar klein beginnen en wegwerp bouwen zijn twee verschillende dingen. De eerste versie mag weinig kunnen — als de structuur eronder maar berekend is op wat erna komt.

Niemand kan hem onderhouden

De tweede oorzaak zie je pas als de bouwfase voorbij is: de kennis over het systeem zit in hoofden, niet in documentatie. Zolang de bouwer erbij is, gaat alles goed. Zodra die aan iets anders werkt — of vertrekt — durft niemand er meer aan te komen.

Voor een gewone applicatie is dat al vervelend. Voor een AI-systeem is het erger, want er is meer om te begrijpen: welke keuzes zijn er gemaakt, waarom reageert het systeem zoals het reageert, wat pas je aan als de resultaten verlopen? Zonder antwoorden op papier is het systeem een black box, en een black box wordt niet uitgebreid maar vermeden.

De test is simpel: kan jouw team, zonder de oorspronkelijke bouwer te bellen, een aanpassing doen en uitleggen wat er gebeurde? Zo nee, dan bezit je geen systeem — je huurt er één, betaald in afhankelijkheid.

Geen kaders, dus geen vertrouwen

De derde oorzaak is de stilste: er is nooit vastgelegd wat het systeem mag. Welke gegevens gaan erin, en waarheen? Wat doet het systeem zelf, en waar kijkt een mens eerst mee? Wie grijpt in als er iets vreemds uitkomt — en kún je dan terugzien waarom het gebeurde?

Zolang die vragen open staan, trapt iemand in de organisatie terecht op de rem. Niet uit weerstand tegen AI, maar omdat verantwoordelijkheid dragen voor iets zonder spelregels onverantwoord is. Zo blijft een technisch geslaagde pilot organisatorisch steken: het systeem kan wel, maar niemand kan ervoor tekenen.

Vertrouwen is geen bijproduct dat vanzelf ontstaat als het systeem goed werkt. Het is een ontwerpkeuze: grenzen, controle en herleidbaarheid moeten er vanaf het begin in zitten.

Wat er wél werkt

De drie oorzaken wijzen hun eigen oplossing aan. Zo bouw ik zelf, bij elke opdracht:

• Een fundament in plaats van wegwerp-code. De eerste versie is klein, maar staat op een structuur die uitbreiding aankan. Elke volgende stap bouwt vóórt in plaats van opnieuw.
• Regie bij mensen. Het systeem beslist nooit zonder dat jij dat zo hebt ingericht: controle zit ingebouwd, en van elke uitkomst is terug te zien hoe die tot stand kwam.
• Overdracht als onderdeel van het werk. Documentatie en uitleg horen bij de oplevering, niet bij de nazorg. Je team kan het systeem zelf onderhouden en uitbreiden — geen black box, geen afhankelijkheid.

Wie deze drie vanaf dag één meeneemt, merkt dat “van pilot naar productie” geen sprong is maar een pad: elke week een werkende stap verder, met een team dat meegroeit met het systeem.

Bekijk de dienst AI-platform ontwerp

Als je nu zo’n pilot hebt

Gooi hem niet weg. Een gestrande pilot bevat bijna altijd iets waardevols: een bewezen use-case, geleerde lessen over je data, en draagvlak dat er eerder niet was. De vraag is alleen wat je ermee doet.

De eerste stap is begrijpen wat er staat: wat is herbruikbaar, wat is demo-plakwerk, en welke kaders missen er? Dat onderzoek kan kort zijn en naast je lopende werk plaatsvinden. Daarna weet je of je kunt verbouwen of beter opnieuw fundeert — en wat dat kost, vóór je eraan begint.

Wil je die vraag voor jouw pilot beantwoord hebben? Plan een gesprek via de knop bovenaan, of loop eerst de projecten door om te zien hoe zo’n systeem eruitziet als het af is.