Vraag me waarom AI-projecten mislukken en ik begin niet bij de techniek. Na een paar honderd eerste gesprekken met oprichters en teams door heel Nederland weet ik meestal binnen het eerste halfuur of een project gaat werken — ruim voordat iemand een regel code schrijft, een model kiest of een architectuurschets maakt. Als een project uiteindelijk mislukt, was die mislukking bijna altijd al zichtbaar bij de start. Alleen in vermomming: een strakke demo, een zelfverzekerde roadmap, een al goedgekeurd budget.
Dat is geen pessimisme, en al helemaal geen verkooptruc. Ik wil dat de projecten die ik aanneem slagen — juist daarom heb ik geleerd de vroege signalen eerlijk te lezen, evenzeer voor de klant als voor mezelf. Werk weigeren dat gaat mislukken is voor iedereen goedkoper dan die mislukking zes maanden en vijftigduizend euro later ontdekken. Dus dit is waar ik in die eerste gesprekken echt naar luister, en wat het me vertelt.
Waarom AI-projecten mislukken — en waarom het zelden de techniek is
De ongemakkelijke cijfers sluiten aan bij wat de gesprekken laten zien. Gartner voorspelde dat minstens 30% van de generatieve-AI-projecten eind 2025 na de proof of concept zou worden stopgezet, met als oorzaken slechte datakwaliteit, onduidelijke businesswaarde en oplopende kosten — niet de prestaties van het model. Een RAND-onderzoek op basis van interviews met ervaren datawetenschappers en engineers legde het faalpercentage van AI-projecten boven de 80%, ongeveer het dubbele van vergelijkbare IT-projecten zónder AI, en herleidde de oorzaken vooral tot mensen en doel, niet tot algoritmes.
Dat komt vrijwel exact overeen met mijn ervaring. Het model is zelden datgene wat een project laat kapseizen. Moderne taalmodellen, vision-systemen en voorspeltools zijn out of the box verbluffend capabel. Het probleem zit stroomopwaarts — in hoe het project is geframed, wie erachter staat, en of de organisatie werkelijk bereid is iets te veranderen op basis van wat het systeem oplevert. Krijg je dat verkeerd, dan automatiseert het elegantste model ter wereld gewoon een beslissing waar toch niemand naar zou handelen.
Er bestaat niet zoiets als een "AI-project"
Een deel van het probleem begint bij het etiket. Zodra iets een "AI-project" heet, wordt het behandeld als een technologie-initiatief — eigendom van wie het meest enthousiast is over de techniek, afgemeten aan of de techniek werd gebouwd, en succesvol verklaard op de dag dat het live gaat. Maar geen enkel bedrijf heeft ooit AI nodig gehad. Ze hebben kortere wachtrijen nodig, minder fouten, snellere offertes, minder verloop. AI is één mogelijk middel tot die doelen, en het werk rond het doel framen in plaats van het middel verandert alles: wie het bezit, hoe je het meet, en of je überhaupt zou merken dat een eenvoudiger oplossing het werk deed. Als ik voorzichtig weiger iets een AI-project te noemen en het in plaats daarvan een "kort-de-offertetijd-project" noem, wordt het gesprek vrijwel altijd scherper.
Deze herformulering beschermt je ook tegen de hypecyclus. Tools veranderen maandelijks; het onderliggende bedrijfsprobleem is jarenlang stabiel. Een project verankerd aan het probleem overleeft een modelupgrade of een leverancier die uit de mode raakt. Een project verankerd aan één specifieke tool moet opnieuw worden verantwoord bij elke verschuiving in het landschap.
De rode vlaggen waar ik in het eerste gesprek op let
Geen van deze gaat over intelligentie of ambitie. Slimme, serieuze mensen lopen er allemaal tegenaan. Ze zijn structureel — en dat is goed nieuws, want structurele problemen zijn oplosbaar vóórdat je echt geld uitgeeft.
Niemand kan de beslissing benoemen die verandert
Mijn eerste echte vraag is bijna altijd een variant op: "Als dit werkt, wat doe je dan op een dinsdagochtend anders?" Is het antwoord scherp — "we triëren deze 400 dagelijkse tickets automatisch en sturen de belangrijkste 10% naar een specialist" — dan ontspan ik. Verzandt het antwoord in "we hebben dan beter inzicht" of "we zijn dan datagedrevener", dan gaat er een belletje rinkelen. AI die geen concrete beslissing of handeling verandert, levert een dashboard op dat niemand een tweede keer opent. Geslaagde projecten zijn verankerd aan één specifiek menselijk gedrag dat aan de andere kant verandert.
De data bestaat nog niet — of niemand is eigenaar
Dit wordt enorm onderschat. Een AI-systeem leert van of redeneert over jouw data — dus als die data verspreid staat over mailboxen, vastzit in het systeem van een leverancier, vol gaten zit of simpelweg nooit is vastgelegd, staat het project al scheef. Erger dan rommelige data is data zonder eigenaar: niemand die met gezag kan zeggen wat een veld betekent of het te vertrouwen is. Ik hoor liever "onze data is een zootje en dit is wie het opknapt" dan een zelfverzekerd "de data is er allemaal" dat drie incompatibele spreadsheets blijkt te zijn. Daarom beginnen we zo vaak met het leidingwerk; eerlijk data-engineering-werk is vaak het échte project achter de AI-vraag.
De opdrachtgever heeft enthousiasme, maar geen mandaat
Sommige van de meest energieke eerste gesprekken zijn met iemand die alles heeft gelezen, de tools heeft geprobeerd en oprecht enthousiast is. Enthousiasme telt. Maar als die persoon geen budget kan vrijmaken, het datateam geen prioriteit kan laten geven aan toegang, en een operationeel team niet kan laten veranderen hoe het werkt, dan stokt het project zodra het organisatorische wrijving tegenkomt — en dat gebeurt altijd. Ik heb briljante proofs of concept stilletjes zien sterven omdat de enige kartrekker niet het mandaat had om iemand het resultaat te laten gebruiken.
De succesmaatstaf is "we gebruiken AI"
Als het doel wordt geformuleerd als AI adopteren in plaats van een probleem oplossen, heeft het project geen finish. "We willen AI inzetten in klantenservice" is een richting, geen doel. "We willen de eerste-reactietijd op onze 20 belangrijkste supportvragen terugbrengen van vier uur naar onder de minuut" is iets waar we naartoe kunnen bouwen, wat we kunnen meten en waarvan we weten of we het halen. Vage doelen zijn onmogelijk te missen — en dus onmogelijk te halen. Soms is het waardevolste wat ik in een eerste gesprek doe, helpen een AI-ambitie te vertalen naar een meetbaar bedrijfsresultaat.
Ze hebben de oplossing al gekozen
"We hebben een chatbot nodig." "We willen een RAG-systeem op onze documenten." Soms klopt dat precies. Maar als een team zich op één specifieke oplossing heeft vastgezet vóórdat we het over het probleem eens zijn, hebben we de belangrijkste stap overgeslagen, en word ik voorzichtig. De juiste volgorde is probleem, dan randvoorwaarden, dan het eenvoudigste dat zou kunnen werken — en dat is soms helemaal niet de AI-zware optie. Leverancier-neutraal zijn betekent dat ik iemand met plezier vertel dat zijn probleem beter is opgelost met een aangepast formulier of een andere workflow dan met een getraind model. Soms is het juiste antwoord om niets te doen, en een goede partner zegt dat ook.
Het plan gaat uit van een rechte lijn
AI-werk is empirisch. Je probeert iets, je meet, je wordt vaak verrast, je stelt bij. Als een plan wordt gepresenteerd als een keurige Gantt-chart met "AI-model uitrollen" netjes in week zes en geen ruimte voor het niet-in-één-keer-werken, is die starheid zelf een risico. Geslaagde projecten begroten voor leren. Ze behandelen de eerste build als een vraag, niet als een belofte, en zijn zo ingericht dat een vroege "dit werkt niet zoals gedacht" een goedkope, nuttige bevinding is in plaats van een dure blamage.
De stillere signalen — cultuur, geen code
Naast de details is er een set zachtere signalen die lastiger op een checklist te zetten zijn, maar net zo voorspellend.
Het eerste is verandermoeheid. Heeft een team net een pijnlijke ERP-migratie of een reorganisatie overleefd, dan is er misschien geen animo meer om de manier van werken te veranderen, hoe goed de tool ook is. Adoptie is waar AI-waarde wordt gerealiseerd of verloren, en uitgeputte teams adopteren niet. Het tweede is het ontbreken van een eigenaar na go-live. Genoeg projecten hebben iemand om ze te bouwen en niemand om ze te draaien; een model dat niemand onderhoudt gaat driften, de data veroudert, en binnen maanden wordt het stilletjes niet meer vertrouwd. Het derde is adoptie als bijzaak behandelen — "we regelen het gebruik later wel." Later komt zelden. Is het veranderplan één trainingsmail, dan belandt de tool op de lange lijst van software die mensen moesten gebruiken en niet gebruikten.
Dit zijn geen redenen om weg te lopen. Het zijn redenen om het project anders te ontwerpen — de eerste scope te verkleinen, vooraf een eigenaar te benoemen, en de menselijke verandering vanaf dag één in het plan te bouwen in plaats van er aan het eind aan vast te plakken.
Hoe een project klinkt dat wél gaat slagen
Het loont om het tegenovergestelde te beschrijven, want dat is verrassend consistent. Projecten die werken komen doorgaans binnen met een smal, bijna saai specifiek probleem: één workflow, één beslissing, één team. Er is een benoemde persoon die de pijn dagelijks voelt en het mandaat heeft om de werkwijze van het team te veranderen. Als ik naar data vraag, kan iemand me vertellen waar die staat, ongeveer hoe schoon die is, en met wie ik moet praten. De succesmaatstaf is een getal dat aan geld of tijd hangt. En er is een gezonde bescheidenheid over de onbekenden — de bereidheid om de riskante aanname goedkoop te bewijzen vóór het opschalen.
Merk op dat niets hiervan gaat over technisch geavanceerd zijn. Enkele van de beste projecten die ik heb gedaan kwamen van teams die het woord "AI" nauwelijks gebruikten en gewoon wilden dat één specifiek, pijnlijk ding ophield pijnlijk te zijn. De helderheid van het probleem deed meer voor de slaagkans dan welke technische ambitie ook.
Een verhaal van twee eerste gesprekken
Twee gesprekken van het afgelopen jaar liggen naast elkaar in mijn geheugen. Het eerste was met een goed gefinancierd team dat binnenkwam met slides, een gekozen architectuur en een plan van zes weken om "een AI-assistent uit te rollen over het hele bedrijf." Toen ik vroeg welk team het als eerste zou gebruiken en wat ze daardoor zouden stoppen te doen, werd het stil. Er was geen eerste team — het was voor iedereen, en dus voor niemand. Ik stelde voor te beginnen met één afdeling en één workflow; zij wilden de grote lancering. We zijn niet samen gaan werken, en voor zover ik weet is die assistent nooit uitgekomen.
Het tweede was bijna het tegenovergestelde: een kleiner bedrijf, geen slides, één gefrustreerde operations-lead die twee uur per dag data overtikte tussen een leveranciersportaal en hun eigen systeem. Ze kon me precies vertellen wat de taak was, waar de data stond en wat een uur van haar tijd waard was. Er was geen grootse AI-visie — alleen een specifieke, dure ergernis. Dat project werkte, want alles wat een project nodig heeft, zat al in de kamer. Het verschil had niets te maken met budget of technische verfijning. Het was helderheid.
Hoe we een project de-risken vóór we ons committeren
De signalen lezen is alleen nuttig als je ernaar handelt, dus de hele samenwerking is zo opgezet dat mislukking vroeg en goedkoop naar boven komt in plaats van laat en duur. Dat is de logica achter werken in fases. We beginnen meestal met een korte, betaalde audit — vanaf ongeveer €2.500 — om de echte use case in kaart te brengen, te toetsen of de data die kan dragen, en te bevestigen dat er een beslissing is die het waard is om te veranderen. Zegt de audit dat het project niet moet doorgaan zoals bedacht, dan is dat een goede uitkomst: je hebt de prijs van een laptop uitgegeven om de prijs van een auto te vermijden.
Is het bouwen waard, dan bewijst een proof of concept (vanaf grofweg €20.000) dat het riskante deel werkt op jouw echte data voordat iemand zich aan productie committeert — en meestal heb je een werkend prototype bij het tweede gesprek. Pas daarna is opschalen naar een productiesysteem logisch. Risico zo structureren is ook wat goede AI-governancekaders aanbevelen; het NIST AI Risk Management Framework is gebouwd rond het continu identificeren en beheersen van risico in plaats van het weg te hopen. De vorm van deze trajecten zie je in onze case studies, en de volledige uitsplitsing op onze prijzenpagina.
De ene vraag die het meeste onthult
Als ik maar één diagnostisch middel mocht houden, was het die dinsdagochtendvraag: als dit werkt, wat verandert er in iemands echte dag? Hij is bedrieglijk eenvoudig en toetst stilletjes alles tegelijk. Om hem goed te beantwoorden moet een team weten wiens dag verandert (de eigenaar), wat diegene nu doet (de workflow), wat diegene in plaats daarvan zou doen (de beslissing), en hoe je zou weten dat het werkte (de maatstaf). Een team dat hem in één heldere zin kan beantwoorden, is meestal klaar. Een team dat er tien minuten en een whiteboard voor nodig heeft, heeft zojuist goedkoop ontdekt dat het project nog niet gedefinieerd is — een veel betere plek om daar achter te komen dan drie maanden in een build.
Merk op waar de vraag niet naar vraagt: welk model, welk framework, welke leverancier. Dat zijn echte beslissingen, maar ze komen later en zijn het makkelijke deel. Het moeilijke deel — het deel dat succes bepaalt — zit volledig in die ene menselijke zin over een dinsdag. Krijg de zin goed en de techniek volgt meestal. Krijg hem verkeerd en geen hoeveelheid engineering redt hem nog.
Wanneer "nog niet" het eerlijke antwoord is
Sommige projecten zijn geen mislukkingen in wording, maar goede ideeën die te vroeg komen. De beslissing is echt en de waarde is echt, maar de data is nog niet verzameld, of het team dat het zou bezitten zit midden in een reorganisatie, of de prioriteit van vorig kwartaal is nog niet geland. In die gevallen is het nuttigste wat ik kan bieden geen build — maar een kort lijstje van wat eerst waar moet zijn, en een eerlijk "kom terug als deze drie dingen op orde zijn." Het levert me zelden de directe opdracht op, maar het is de reden dat mensen terugkomen, en de reden dat de projecten die we wél aannemen doorgaans slagen. Een partner die nooit "nog niet" zegt, vertelt je iets over hoe hij succes meet — en dat is niet jouw resultaat.
Als je je project hierin herkent
Je eigen project in een paar van deze rode vlaggen zien is geen doodvonnis — het is een cadeau, als je het nú opmerkt. De oplossing is bijna altijd kleiner en helderder worden voordat je ambitieuzer wordt. Versmal de scope tot één beslissing. Vind de persoon die die beslissing en de onderliggende data bezit. Vervang "AI gebruiken" door een getal waarop je met plezier wordt afgerekend. Spreek af de meest riskante aanname goedkoop te bewijzen voordat je het geheel bouwt. Doe die vier dingen en de meeste faalscenario's uit dit artikel verdampen simpelweg.
En weet je niet zeker of jouw project een goed project is — dan is dat precies het gesprek dat het waard is om vroeg te voeren. Bekijk onze transparante prijzen, of boek een gratis consult en we brengen je eerste use case samen in kaart, eerlijk, inclusief de mededeling als het eerlijke antwoord "nog niet" is. Ik voer dat gesprek veel liever nu dan nadat het budget op is.
Veelgestelde vragen
Waarom mislukken de meeste AI-projecten?
De meeste AI-projecten mislukken om redenen stroomopwaarts van de techniek: een onduidelijke beslissing die de AI moet veranderen, data die niet bestaat of geen eigenaar heeft, een opdrachtgever zonder mandaat om adoptie af te dwingen, en vage succesmaatstaven. Onderzoek van Gartner en RAND laat hoge faal- en afhaakpercentages zien, en beide wijzen naar mensen, data en doel in plaats van het model zelf.
Kun je vóór het bouwen zien of een project gaat mislukken?
Vaak wel. In het eerste gesprek zijn de sterkste voorspellers of het team de specifieke beslissing kan benoemen die verandert, of de data bestaat en een eigenaar heeft, of de opdrachtgever de werkwijze echt kan veranderen, en of de succesmaatstaf een echt getal is. Een korte betaalde audit is bedoeld om precies dit te toetsen voordat je je aan een build committeert.
Hoe verklein je het risico dat een AI-project mislukt?
Word kleiner en helderder voordat je ambitieuzer wordt. Versmal de scope tot één beslissing, benoem de eigenaar van die beslissing en de bijbehorende data, vervang 'AI gebruiken' door een meetbaar resultaat, en bewijs de meest riskante aanname goedkoop met een proof of concept vóór het opschalen. Werken in fases — audit, dan PoC, dan productie — brengt mislukking vroeg en goedkoop naar boven.
Is het AI-model meestal de reden dat een project mislukt?
Zelden. Moderne modellen zijn out of the box zeer capabel, dus de techniek is zelden de bottleneck. Mislukking is bijna altijd terug te voeren op framing, datagereedheid, organisatorisch mandaat en adoptie. Daarom besteedt een eerlijke partner het eerste gesprek aan het probleem en de organisatie, niet aan welk model je gebruikt.