AI Strategie

Je eerste AI-project is mislukt: wat je er nu mee doet

Bijna niemand schrijft eerlijk over een mislukt AI-project. De vijf meest voorkomende oorzaken, een uur-evaluatie, en wanneer stoppen de juiste keuze is.

aiworktalent Redactie · 27 juli 2026 · 10 min leestijd

Het eerste AI-project is misgelopen. De pilot bleef half af, niemand gebruikt de tool nog, of het budget is op zonder dat er iets bruikbaars staat. Bijna niemand schrijft daar hardop over — de meeste stukken over AI gaan over de succesverhalen — terwijl het voor veel mkb-bedrijven de eerste ervaring is. Dat is geen reden om te concluderen dat AI niets voor je bedrijf is, en ook geen reden om onverstoorbaar door te gaan met hetzelfde plan. Dit artikel helpt je vaststellen wat er precies misging, en of een tweede poging zin heeft.

Waarom "het werkt niet" bijna nooit het hele verhaal is

Onderzoek van RAND Corporation uit 2024, gebaseerd op interviews met tientallen data scientists en engineers, vond dat een ruime meerderheid van AI-projecten faalt — ongeveer het dubbele van gewone IT-projecten zonder AI — en dat de oorzaken daarvan bijna altijd organisatorisch zijn: een verkeerd begrepen probleem, zwakke data, of leiderschap dat afhaakt zodra het project schuurt. Techniek was zelden de reden. Gartner voorspelde in 2024 dat minstens 30 procent van de generatieve AI-projecten na de proefopzet wordt stopgezet, vanwege onduidelijke bedrijfswaarde, datakwaliteit en oplopende kosten.

Herkenbaar? Dat is precies het punt: "AI werkt niet voor ons" is bijna nooit de juiste samenvatting, want die zin verbergt een van een handvol specifieke, vaak oplosbare oorzaken. Maar het is ook geen vrijbrief om blind door te gaan met een project dat al twee keer is vastgelopen. Soms is de eerlijke conclusie dat je stopt, en dat is verderop in dit artikel net zo belangrijk als de oorzaken zelf.

De vijf meest voorkomende oorzaken

In vrijwel elk mislukt AI-project is een van deze vijf oorzaken, of een combinatie ervan, aan te wijzen. Herken je jouw project erin, dan weet je meteen waar je moet beginnen.

1. Het verkeerde probleem gekozen

Hoe je het herkent: het project loste iets op dat zich te zelden voordeed om de bouw- en onderhoudstijd te rechtvaardigen, of het probleem bleek bij nader inzien geen technisch knelpunt maar een organisatorisch: afdelingen die elkaar tegenwerken, onduidelijke verantwoordelijkheden, een proces dat toch al niemand op dezelfde manier volgde. AI loste dan een symptoom op in plaats van de oorzaak.

Wat je eraan doet: reken het volume na. Deed je de taak minder dan een paar keer per week, dan was het onwaarschijnlijk dat de investering zich ooit terugbetaalde, hoe goed de techniek ook werkte — zie hoe je dat vooraf doorrekent. Blijkt het onderliggende probleem organisatorisch, dan helpt een volgende poging met een ander model of een andere leverancier niets: eerst het proces of de samenwerking oplossen, dan pas opnieuw kijken of er een taak overblijft die AI kan overnemen.

2. De data was er niet of niet bruikbaar

Hoe je het herkent: de resultaten waren wisselvallig, het systeem verzon dingen die er niet stonden, of het project liep vast omdat iemand halverwege ontdekte dat de benodigde informatie verspreid stond over meerdere systemen, alleen op papier bestond, of te inconsistent was ingevuld om als betrouwbare basis te dienen.

Wat je eraan doet: ga na of het probleem echt de data zelf was, of de manier waarop die werd aangeleverd — vaak is het antwoord allebei een beetje. Breng voor de volgende poging eerst de data op orde voor die ene, specifieke taak. Dat is meestal minder werk dan het klinkt, omdat je niet je hele datahuishouding hoeft te saneren, alleen wat die ene taak nodig heeft.

3. Niemand had de tijd of het mandaat om het in te voeren

Hoe je het herkent: de techniek werkte in de test, maar het project verwaterde omdat de kartrekker het erbij deed, er geen ruimte in de agenda was om collega's mee te nemen, of niemand de bevoegdheid had om een verandering in de werkwijze daadwerkelijk door te voeren.

Wat je eraan doet: dit is zelden met techniek op te lossen. Ga na of er voor een volgende poging wél iemand is die er expliciet tijd en mandaat voor krijgt, niet "erbij", maar als onderdeel van het takenpakket. Is die ruimte er structureel niet, dan is tijdelijke externe ondersteuning een reëlere oplossing dan het nog een keer op dezelfde manier intern proberen; zie wat een AI-expert inhuren daarbij kan betekenen.

4. De oplossing werkte technisch, maar paste niet in de werkdag

Hoe je het herkent: de demo overtuigde, de techniek deed wat hij moest doen, en toch gebruikt niemand het meer na een paar weken. Vaak zit het venijn in een detail: een extra stap die er eerst niet was, een tool die naast in plaats van in het bestaande systeem draait, of output die eerst handmatig moet worden overgezet voordat iemand er iets mee kan.

Wat je eraan doet: vraag de mensen die het werk zouden moeten doen niet alleen of de uitkomst goed was, maar of het gebruik ervan minder moeite kostte dan de oude manier. Is het antwoord nee, dan is het probleem zelden de AI zelf maar de inpassing: een systeem dat een extra stap toevoegt in plaats van een stap wegneemt, wint het nooit van de gewoonte. Vraagt die inpassing meer kennis van je bestaande systemen dan er intern is, dan is dat precies de afweging tussen zelf bouwen en uitbesteden.

5. Er was geen maatstaf afgesproken

Hoe je het herkent: niemand kan met droge ogen zeggen of het project iets heeft opgeleverd. Er is geen getal van vooraf om tegen af te zetten, geen "dit moest twee uur per week schelen" of "dit moest de foutmarge onder de vijf procent brengen", dus wordt de beoordeling een gevoel — en een gevoel verliest het meestal van de eerste tegenvaller.

Wat je eraan doet: leg voor de volgende poging vooraf een getal vast, hoe grof ook, en spreek af wanneer je het meet. Zonder maatstaf is elk resultaat achteraf uit te leggen als succes én als mislukking, en dat helpt niemand verder.

Een eerlijke evaluatie doe je in een uur

Je hoeft geen extern onderzoek te laten doen om erachter te komen wat er misging. Een uur, drie gesprekken en een half A4'tje volstaan meestal. Zo pak je het aan:

• 15 minuten met de opdrachtgever of initiatiefnemer: welk probleem moest dit oplossen, en hoe wist je vooraf dat het dat probleem was? Was er een getal afgesproken, en wat zei dat getal aan het eind?
• 20 minuten met de mensen die het werk zouden moeten doen: hebben ze het gebruikt, en zo niet, waarom niet? Was het gebruik makkelijker of moeilijker dan de oude manier? Dit gesprek levert vaak de eerlijkste antwoorden op, want zij voelen de dagelijkse wrijving het eerst.
• 15 minuten om zelf naar de data en de output te kijken: was de informatie die erin ging op orde, en wat kwam er precies uit? Vaak is in tien voorbeelden al zichtbaar of het probleem in de data, het model of het gebruik zat.
• 10 minuten om samen te vatten: schrijf op welke van de vijf oorzaken hierboven het dichtst in de buurt komt, en of die oplosbaar is voor een volgende poging.

Schrijf het op, ook als het maar een half A4'tje is. Over drie maanden weet niemand meer precies wat er misging, en dan begin je bij een volgende poging weer bij nul.

Wanneer stoppen de juiste keuze is

Niet elke evaluatie eindigt met "opnieuw proberen, maar kleiner". Soms is de eerlijke conclusie dat je stopt, en dat is een goede uitkomst, geen falen. Dat geldt in elk geval in drie situaties: het onderliggende probleem blijkt organisatorisch en geen AI-project gaat dat oplossen; het volume is te klein om de bouw- en onderhoudstijd ooit terug te verdienen; of het proces volgt gewoon vaste regels en heeft daarom helemaal geen AI nodig, maar simpele automatisering of een vaste routine.

Een tweede poging heeft alleen zin als minstens een van de vijf oorzaken hierboven aanwijsbaar én oplosbaar is. Is dat niet zo, dan is doorzetten uit koppigheid duurder dan toegeven dat dit specifieke idee niet werkt. Dat is geen falen van je bedrijf, het is een project dat zijn werk heeft gedaan: het heeft je iets geleerd voor minder geld dan een tweede of derde mislukte poging had gekost.

Een voorbeeld uit de praktijk

Ter illustratie: een installatiebedrijf met twaalf medewerkers liet een AI-tool bouwen die inkomende offerteaanvragen automatisch moest samenvatten en een conceptofferte moest klaarzetten. In de test met tien oude e-mails werkte het uitstekend. Drie maanden na livegang bleek bijna niemand de conceptofferte nog te openen: de planners typten liever meteen zelf in hun vertrouwde sjabloon, omdat het overzetten van het AI-concept ongeveer evenveel tijd kostte als opnieuw beginnen.

De uur-evaluatie hierboven liet zien wat er speelde. Het gesprek met de planners maakte duidelijk dat de techniek prima werkte — de samenvatting klopte meestal — maar dat het concept in een apart scherm stond, los van het offertesysteem waarin zij hun hele dag al doorbrachten. Geen dataprobleem, geen verkeerd probleem, gewoon een oplossing die een extra stap toevoegde in plaats van een stap wegnam. Er was bovendien vooraf nooit een getal afgesproken, dus kon niemand hard maken of het al dan niet iets opleverde, tot dit gesprek er kwam.

De conclusie was niet "AI werkt niet voor ons", maar oorzaak vier en vijf: geen inpassing in de werkdag, geen maatstaf. Voor de volgende poging kozen ze een kleinere stap — het AI-concept direct in het bestaande offertesysteem laten verschijnen in plaats van in een los scherm — en spraken vooraf af dat het minstens een kwartier per offerte moest schelen, gemeten over vier weken. Die tweede poging haalde dat kwartier, en werd wél gebruikt.

Wat je meeneemt naar een volgende poging

Los van de specifieke oorzaak die jij hebt gevonden, zijn er drie dingen die vrijwel elke tweede poging beter maken dan de eerste:

• Begin kleiner. Niet het hele proces in één keer, maar het smalste stukje ervan dat al waarde oplevert. Klein beginnen en pas daarna uitbreiden werkt beter dan in één keer groot bouwen; zie het stappenplan voor AI in het mkb.
• Spreek vooraf een getal af. Hoe grof ook: dit moet zoveel tijd schelen, of de foutmarge met zoveel procent verlagen. Zonder getal herhaal je oorzaak vijf, ook al heb je de andere vier keurig opgelost.
• Zet de mensen die het werk doen vanaf het begin aan tafel. Niet pas bij de oplevering, maar al bij het bepalen van de taak en tijdens de bouw. Zij weten het eerst of iets in de praktijk standhoudt, en hun betrokkenheid vanaf het begin is vaak het verschil tussen een tool die blijft hangen en een tool die na drie weken links blijft liggen.

In één oogopslag: symptoom, oorzaak en eerste actie

Herken je een van deze symptomen, dan wijst dat meestal naar een van de vijf oorzaken hierboven.

Een mislukt AI-project is zelden het bewijs dat AI niets voor je bedrijf is. Vaker is het een project dat één specifiek ding miste: het juiste probleem, bruikbare data, tijd en mandaat, een goede inpassing, of een afgesproken maatstaf. Zoek uit welke het was, en beslis dan pas of een tweede poging zin heeft — soms is stoppen de eerlijkste uitkomst. Wil je die evaluatie samen doen, dan plaats je op aiworktalent je opdracht en ontvang je voorstellen van specialisten.