Vraag me waarom een AI-pilot doodbloedt en ik wijs niet naar het model. In vier jaar een AI-adviesbureau runnen heb ik nog geen project zien mislukken omdat de techniek niet werkte — wel talloze projecten zien mislukken omdat niemand er ook maar één functie omheen herontworpen heeft.
Het cijfer dat niemand in de slidedeck zet
Elke AI-verkooppitch dit jaar opent met een benchmark. Bijna geen enkele opent met het cijfer dat daadwerkelijk voorspelt wat er met jouw project gebeurt: onderzoek van MIT dit jaar liet zien dat 95% van de generatieve-AI-pilots bij bedrijven geen meetbaar effect op de winst-en-verliesrekening oplevert, en apart branche-onderzoek naar agentic AI zet het aandeel pilots dat nooit in productie komt op zo'n 89%. Beide onderzoeken komen op dezelfde onderliggende oorzaak uit, en dat is niet de kwaliteit van het model. Onderzoekers noemen het inmiddels, ietwat droog, een "learning gap" — het onvermogen van een bedrijf om een nieuwe tool daadwerkelijk in te bedden in de bestaande werkwijzen, het organogram, de gewone dinsdagochtend. Ik zou het minder droog noemen: niemands functie is veranderd, dus niemands gedrag is dat ook niet.
Ik begin hiermee omdat het de volgorde omdraait waarin de meeste mkb'ers naar AI kijken. Het instinct is om je zorgen te maken over het model — is het nauwkeurig genoeg, is het de juiste leverancier, is het AVG-proof, gaat het hallucineren waar een klant bij is. Dat zijn terechte vragen. Maar ze zijn zelden de reden dat een veelbelovende pilot drie maanden later stilletjes niet meer ter sprake komt in het maandagoverleg. De reden is bijna altijd saaier dan een modelprobleem, en ook makkelijker op te lossen — en dat is het goede nieuws dat verstopt zit in een verder nogal ontnuchterende reeks cijfers.
Wat "de pilot werkte" eigenlijk betekent
Een patroon dat ik voortdurend zie: een pilot draait zes weken, de demo is echt goed, de cijfers op de slide kloppen daadwerkelijk, en iedereen in de zaal knikt. Daarna gebeurt er niets. Niet omdat iemand besloot de stekker eruit te trekken — meestal besluit niemand iets. De tool is gewoon stilletjes niet meer het ding waar mensen naar grijpen, en acht maanden later vraagt iemand wat er ook alweer met dat AI-project gebeurd is, en het eerlijke antwoord is dat het technisch nog steeds draait, op een server, gebruikt door niemand.
"De pilot werkte" is een zin over het model. Het zegt dat het systeem correcte uitkomsten produceerde op een representatieve steekproef van je data. Het zegt helemaal niets over of iemands daadwerkelijke werk erdoor veranderd is — of de leidinggevende nu sneller resultaat verwacht, of de eigen beoordeling de nieuwe manier van werken weerspiegelt, of de vijf minuten die vroeger aan de oude methode gingen nu écht ergens anders aan besteed worden. Een pilot kan tegelijk een compleet technisch succes en een compleet adoptiefalen zijn, en in mijn ervaring ligt die combinatie dichter bij het gemiddelde resultaat dan bij de uitzondering.
Dit is, niet toevallig, precies waar ik eerder over schreef in wat klanten meestal verwachten versus wat er echt gebeurt zodra een project voorbij de demofase komt — de kloof tussen "het werkt" en "het is blijven hangen" is het meest onderschatte onderdeel van elk AI-traject, ook van de onze.
Het soort verandermanagement dat een bedrijf van twintig man daadwerkelijk nodig heeft
Zeg "verandermanagement" tegen de eigenaar van een bedrijf van twintig man en je krijgt meestal een licht pijnlijke blik, want het woord komt met enterprise-bagage: stuurgroepen, cultuurworkshops, een slide met acht cirkels en pijlen ertussen. Dat is niet wat ik bedoel, en het is ook niet wat een bedrijf van die omvang nodig heeft. Wat een bedrijf van twintig man écht nodig heeft, is kleiner, goedkoper en veel minder glamoureus dan het woord doet vermoeden: iemand moet fysiek veranderen hoe een specifieke taak wordt gedaan, op een specifieke dag, en iemand met voldoende gezag moet dat opmerken en het voortaan blijven verwachten.
Dat is het hele mechanisme, teruggebracht tot zijn twee bewegende delen. De taak verandert, en iemand met gezag begint de nieuwe versie te verwachten. Alles wat mensen doorgaans bedoelen met "verandermanagement" — trainingen, interne communicatie, workshops — dient die twee dingen en is waardeloos zonder ze. Ik heb een prachtig geproduceerde interne trainingsvideo niets zien opleveren, en ik heb één zin van een eigenaar tijdens een maandagoverleg — "vanaf nu gaan offertes via het nieuwe systeem, punt uit" — alles zien opleveren waar de trainingsvideo voor bedoeld was. Het verschil zat niet in productiewaarde. Het zat in gezag dat aan een verwachting gekoppeld werd.
Dit is het onderdeel van een AI-project dat niets met AI te maken heeft, en het is ook het onderdeel waar technisch ingestelde teams het slechtst in zijn, omdat het geen technisch probleem is en niet reageert op technische oplossingen. Je kunt je niet naar adoptie patchen. Je kunt alleen hardop besluiten dat de oude manier niet meer bestaat — en dat ook daadwerkelijk menen zodra iemand in week drie toch weer terugvalt.
Drie signalen dat een uitrol dreigt vast te lopen
Ik heb geleerd op dezelfde drie signalen te letten voordat een uitrol stilletjes doodbloedt, en tegen de tijd dat alle drie aanwezig zijn, is het project meestal al verloren — ook als de techniek prima werkt.
- Niemands functieomschrijving is daadwerkelijk veranderd. Als de nieuwe tool bovenop iemands bestaande rol geplakt is als optionele extra, in plaats van een specifieke stap te vervangen die diegene vroeger handmatig deed, verliest het binnen een maand van gewoonte. Mensen adopteren geen tools; ze laten stappen vallen. Is er geen stap verdwenen, dan is er ook niets geadopteerd.
- De tool is in de praktijk optioneel, ook al is hij op papier verplicht. De echte test is niet het uitrol-memo — het is wat er gebeurt de eerste keer dat iemand haast heeft en de nieuwe manier ook maar iets trager of onvertrouwder aanvoelt dan de oude. Kan iemand ongemerkt terugvallen op het spreadsheet, dan gebeurt dat — herhaaldelijk, tot het weer de standaard is.
- Niemand boven de gebruiker hoeft naar de uitkomst te kijken. Adoptie blijft hangen zodra een leidinggevende, een klant of een collega verderop in het proces verwacht de nieuwe versie te zien en het zou opmerken als die er niet is. Zodra de output van een AI-tool verdwijnt in een leegte waar niemand naar kijkt, wordt gebruik theoretisch in plaats van echt — licentie verlengd, dashboard stilletjes leeg.
Elk van deze drie is een managementbeslissing, geen technische, en precies daarom zit ik liever in de kamer waar het proces herontworpen wordt dan dat ik alleen een werkend model overhandig en de klant succes wens.
Wie is er eigenaar van adoptie zodra wij weg zijn
Dit is de ongemakkelijke vraag die ik mezelf stel voordat ik een project aanneem: als wij de dag na livegang zouden verdwijnen, overleeft dit dan het contact met een gewone dinsdag? Is het eerlijke antwoord nee, dan zit het probleem meestal niet in de code — het zit erin dat niemand binnen het bedrijf duidelijk eigenaar is gemaakt van het feit dat de nieuwe manier de enige manier wordt. Ik schreef eerder al over hoe ik meestal binnen het eerste half uur weet of een project gaat werken, en een van de sterkste vroege signalen is of een klant nu al de naam kan noemen van degene aan hun kant die dit gaat bezitten zodra wij weg zijn. Kunnen ze die naam niet noemen in het eerste gesprek, dan breng ik dat ter sprake vóórdat we iets tekenen, want het bouwen van het systeem is de makkelijke helft van het werk.
Dit is ook waarom ik liever iets ruws opleveren dat een echte eigenaar daadwerkelijk in het dagelijks gebruik duwt, dan iets gepolijst dat een kamer imponeert en daarna stilletjes doodbloedt. Ik heb eerder het pleidooi gehouden voor een werkend MVP boven een gepolijste slidedeck, en adoptie is de reden: een ruwe tool met een vastberaden interne eigenaar wint het altijd van een mooie tool zonder iemand die verantwoordelijk is voor het daadwerkelijke gebruik — elke keer dat ik die twee tegen elkaar heb zien uitvechten.
De draai van 2026: goedkopere pilots, dezelfde adoptiekloof
Er is het afgelopen jaar iets echt veranderd dat dit probleem groter maakt in plaats van kleiner, en dat is het benoemen waard. Agentic AI en het Model Context Protocol gingen van onderzoeksjargon naar infrastructuur die overal draait, sneller dan bijna iemand had voorspeld — een werkende demo bouwen die daadwerkelijk aan je eigen data koppelt, kost nu dagen, soms uren, waar het vroeger maanden kostte. Dat is een echte winst. Maar het betekent dat het knelpunt volledig verschoven is van "kunnen we dit bouwen" naar "gaat iemand er daadwerkelijk anders door werken" — en die tweede vraag is geen millimeter makkelijker geworden, alleen omdat de eerste dramatisch goedkoper te beantwoorden werd.
Ik zou zelfs verder gaan: goedkope pilots maken het adoptieprobleem op één specifieke manier erger. Als een demo duur en traag is om te maken, wordt een bedrijf gedwongen om er goed over na te denken voordat het zich eraan committeert — wat toevallig een deel van het verandermanagement-denkwerk al vooraf doet. Kan een demo in een middag in elkaar gezet worden, dan is de verleiding groot om dat denkwerk helemaal over te slaan en gewoon te kijken of het indruk maakt — en zo eindig je precies bij het patroon uit mijn eerdere post over het verschil tussen een demo en een productiesysteem: een echt goede demo, die eeuwig blijft draaien, zonder iets te veranderen.
Wat daadwerkelijk werkt
Het onderzoek hierover is specifieker dan "communiceer meer", en dat is de moeite waard omdat het overeenkomt met wat ik in de praktijk zie. Bedrijven die AI-adoptie serieus nemen, reserveren naar verluidt zo'n twintig tot dertig procent van het budget van een AI-initiatief voor training, interne communicatie en het herontwerpen van werkprocessen — niet als bijzaak achteraf, maar als gepland onderdeel vanaf dag één. Vergelijk dat met de bredere bevinding dat maar ongeveer een derde van de bedrijven iets heeft dat lijkt op een gestructureerd veranderprogramma, ondanks dat de meeste wél technische trainingssessies draaien. Mensen leren op de juiste knop te klikken is niet hetzelfde als veranderen wat hun functie van ze vraagt, en die twee door elkaar halen is een van de meest voorkomende en meest vermijdbare fouten die ik zie.
In de praktijk betekent dit dat het AI-implementatie stappenplan van elke uitrol waar ik nu bij betrokken ben — de echte AI change management voor het mkb, niet alleen de modelspecificatie — vanaf het allereerste voorstel een expliciet antwoord bevat op drie vragen die niets met het model te maken hebben: welke specifieke taak verdwijnt op de dag dat dit live gaat, wie is de met naam genoemde persoon die geacht wordt het op te merken als mensen stilletjes teruggaan naar de oude manier, en wat verandert er in een functioneringsgesprek als gevolg daarvan. Kan een klant die drie nog niet beantwoorden, dan is dat geen reden om af te haken — het is meestal het eigenlijke eerste project, nog voordat het technische project begint.
Wie is hier écht eigenaar van binnen het bedrijf
Een vraag die ik inmiddels in bijna elk intakegesprek stel, en die ik elke eigenaar zou aanraden zichzelf te stellen voordat er iets getekend wordt: wiens werk wordt makkelijker als dit werkt, en wiens werk wordt moeilijker? Adoptie loopt meestal stilletjes vast zodra die twee antwoorden naar verschillende mensen wijzen. Ziet degene die het dagelijkse werk doet alleen maar een nieuwe tool om te leren, zonder dat de eigen inspanning afneemt, terwijl het voordeel vooral bij een dashboard van een leidinggevende drie lagen hoger terechtkomt, dan heb je iets gebouwd waar mensen zich met tegenzin aan houden, niet iets waar ze daadwerkelijk naar grijpen. De uitrollen die beklijven, zijn de uitrollen waarbij degene die de taak uitvoert ook degene is die het meest direct en het meest zichtbaar profiteert — sneller facturen de deur uit voor wie ze vroeger moest achtervolgen, minder herhaalde telefoontjes voor wie ze vroeger moest afhandelen, niet alleen een netter rapport voor iemand die het oorspronkelijke proces nooit heeft aangeraakt.
Dit is ook waarom "wie is eigenaar" een naam nodig heeft, geen afdeling. "IT beheert het" en "operations is verantwoordelijk" klinken allebei als eigenaarschap en functioneren allebei als niemand die verantwoordelijk is. De projecten die ik een jaar na livegang nog zie draaien, hadden stuk voor stuk één aanwijsbare persoon wiens functie daadwerkelijk inhield om wekelijks op te merken of de nieuwe manier nog gebruikt werd — geen stuurgroep, één persoon met genoeg gezag om te vragen "waarom ging deze factuur toch weer via de oude manier de deur uit" en daar een eerlijk antwoord op te krijgen.
Waar je begint
Kijk je naar een AI-pilot die technisch werkt maar niemands dinsdag daadwerkelijk veranderd heeft, dan zit de oplossing zelden in een beter model. Begin met het benoemen van de ene taak die zou moeten verdwijnen en de ene persoon die het zal opmerken als dat niet gebeurt. We hebben realistische budgetten uiteengezet — inclusief de verandermanagement-kant die de meeste offertes weglaten — op onze pagina over wat een AI-project kost, en ben je nog eerder in dat proces en weet je nog niet of dit überhaupt een project is om aan te beginnen, dan is dat het gesprek dat we eerst voeren, vóór welk voorstel dan ook, bij Crux Digits.
Veelgestelde vragen
Waarom mislukken de meeste AI-pilots na een geslaagde proef?
De meeste AI-pilots mislukken na een geslaagde proef niet omdat het model stopt met werken, maar omdat niemand een specifieke taak eromheen herontworpen heeft. Onderzoek liet dit jaar zien dat 95% van de generatieve-AI-pilots bij bedrijven geen meetbaar effect op de winst-en-verliesrekening oplevert, en de oorzaak is steevast organisatorisch, niet technisch: er verdween geen taak, geen leidinggevende verwachtte de nieuwe versie, en gebruik werd stilletjes optioneel.
Wat is AI-adoptie change management en waarom heeft een mkb-bedrijf dat nodig?
AI change management is het werk dat ervoor zorgt dat een nieuwe tool de enige manier wordt om een taak te doen, niet een optionele extra. Voor een mkb-bedrijf betekent dit geen stuurgroepen of cultuurworkshops; het betekent dat één specifieke taak verandert en dat één persoon met genoeg gezag de nieuwe versie voortaan verwacht. Zonder beide valt adoptie binnen enkele weken terug op oude gewoontes.
Hoe voorkom je weerstand tegen AI op de werkvloer?
Weerstand neemt af zodra een tool daadwerkelijk een stap uit iemands werk haalt in plaats van er bovenop geplakt te worden, en zodra het voordeel zichtbaar is voor degene die het werk doet, niet alleen voor het dashboard van een leidinggevende. Eén aanwijsbare persoon die verantwoordelijk is om op te merken of de oude manier terugsluipt, weegt zwaarder dan trainingssessies of interne communicatie alleen.
Wat is het verschil tussen een AI-pilot en een geschaalde AI-implementatie?
Een pilot bewijst dat een model correcte output produceert op een representatieve steekproef van data. Een geschaalde implementatie bewijst dat een bedrijf daadwerkelijk veranderd is in hoe een taak wordt gedaan, met een aangewezen eigenaar die de nieuwe manier verwacht en zou opmerken als mensen stilletjes terugvallen. Een pilot kan technisch slagen terwijl adoptie volledig mislukt, en dat ligt dichter bij het gemiddelde resultaat dan bij de uitzondering.
Hoeveel budget moet je reserveren voor AI-adoptie, naast de techniek zelf?
Bedrijven die adoptie serieus nemen, reserveren naar verluidt zo'n twintig tot dertig procent van het budget van een AI-initiatief voor training, interne communicatie en het herontwerpen van werkprocessen, ingepland vanaf het eerste voorstel in plaats van er later aan toegevoegd. Dat komt bovenop, en los van, de technische bouw en licentiekosten.
