Waarom AI-projecten mislukken
AI-projecten mislukken zelden door het model. Onderzoek van MIT laat zien dat 95 procent van de bedrijven die met generatieve AI begonnen geen meetbaar resultaat zag, en dat de rem niet bij de techniek zit maar bij integratie en leren: het systeem landt niet in het dagelijkse werk en leert niets van gebruikers.
Van Cloudzicht, Almere · Marc Herdes en John van den Bosch · bijgewerkt op

De meeste artikelen over dit onderwerp geven u een stappenplan. Wij beginnen bij de cijfers, want de pilots die stukliepen, liepen niet stuk op techniek.
Waarom mislukken AI-projecten?
AI-projecten mislukken zelden door het model. Onderzoek van MIT laat zien dat 95 procent van de bedrijven die met generatieve AI begonnen geen meetbaar resultaat zag, en dat de rem niet bij de techniek zit maar bij integratie en leren: het systeem landt niet in het dagelijkse werk en leert niets van gebruikers.
Dat cijfer komt uit *The GenAI Divide: State of AI in Business 2025* van Project NANDA van MIT, juli 2025: ruim 300 openbaar gemaakte AI-projecten bekeken, 52 organisaties gesproken, 153 leidinggevenden ondervraagd. Het verschil tussen de 5 procent die er wel iets aan verdient en de rest wordt niet bepaald door modelkwaliteit of regelgeving, maar door aanpak.
Generatieve AI is software die zelf tekst, code of beeld maakt. Het zijn voorlopige bevindingen uit internationaal onderzoek, geen Nederlandse meting.
Wat wordt er als oorzaak genoemd, en wat gaat er werkelijk mis?
Bijna elke uitleg achteraf wijst naar de techniek of naar de mensen. Het MIT-onderzoek wijst naar iets anders: naar de plek waar de oplossing terechtkwam, en naar wat er daarna mee gebeurde. Hieronder staat de veelgehoorde verklaring naast wat er in de onderzochte projecten feitelijk misging.
| Wat er meestal gezegd wordt | Wat er feitelijk misgaat |
|---|---|
| “Het model was nog niet goed genoeg” | Het model deed zijn werk. De uitkomst kwam alleen nooit terecht in het scherm waar het werk gebeurt |
| “De techniek is nog niet zover” | De techniek stond klaar. Er was niemand die de wens vertaalde naar een opdracht die te bouwen viel |
| “Onze mensen wilden er niet aan” | De oplossing stond náást hun werk in plaats van erin, en meedoen kostte hun extra handelingen |
| “We wachten op duidelijkheid over de regels” | MIT vond regelgeving niet terug als rem. Het systeem leerde niets van wat gebruikers ermee deden |
| “Het was te duur” | Niemand had vooraf gemeten wat het oude werk kostte, dus viel achteraf niet vast te stellen wat het opleverde |
De onderste rij is de stilste van de vijf, en de vervelendste. Zonder meting vooraf is er achteraf geen gesprek meer mogelijk over de opbrengst — alleen nog een gevoel.
Waarom levert een pilot die technisch werkt alsnog niets op?
Omdat werken in een demo iets anders is dan werken op dinsdagochtend. MIT volgde de trechter: van de bedrijven die maatwerk- of leverancierstools voor een specifieke taak bekeken, kwam 60 procent tot een beoordeling, 20 procent tot een pilot en 5 procent tot productie. De uitval zit ná het bewijs dat het technisch kan.
Gebruikers waren in dat onderzoek positief over algemene hulpmiddelen die ze zelf konden openen, en noemden speciaal voor hen gebouwde tools breekbaar en niet passend bij hoe ze werken.
Een pilot bewijst dat iets kán. Hij bewijst niet dat het gedaan wórdt. Die tweede vraag wordt zelden gesteld voordat het geld op is.
Ligt het dan nooit aan het model?
Zelden. MIT noemt het met zoveel woorden een mythe dat modelkwaliteit, juridische zaken of data de grootste rem zijn. De echte rem is dat de meeste AI-tools niet leren en niet goed in bestaande werkstromen passen. Systemen onthouden geen feedback en worden na maanden gebruik geen haar beter.
Dat verplaatst de vraag. Niet “welk model moeten we hebben”, maar “hoe zorgen we dat de uitkomst bij de juiste persoon op het scherm staat”. Dat is bouwwerk, geen instelling.
Wat gaat er mis tussen de wens en de opdracht aan de bouwer?
Daar verdwijnt de context. De directeur kent zijn bedrijf en beschrijft een uitkomst. De bouwer kent techniek en bouwt wat er staat. Wat niemand opschrijft zijn de uitzonderingen en de afspraken die al twintig jaar in iemands hoofd zitten. Precies daar loopt het later vast.
Neem “we willen dat offertes automatisch worden opgemaakt”. Dat klinkt als één opdracht. In de praktijk zitten er tien vragen onder. Wie mag korting geven en tot hoever?
Wij zetten de wens daarom eerst om in een functionele omschrijving in gewone taal: wie doet wat, en wat er gebeurt bij een uitzondering. Die leest u zelf na en schiet u zelf af. Pas als dat stuk klopt, bouwen wij. Zie software laten maken.
Waarom is software die niet in het dagelijkse werk landt geen oplossing?
Omdat uw mensen dan twee systemen bijhouden in plaats van één. Soms is dat geen ongeluk maar een keuze: wie niet is meegenomen in het besluit, houdt het oude aan. En wie zich afvraagt hoe hard dit de komende jaren gaat, leest AI en de toekomst van werk. Daar gaat als uw mensen er niet op zitten te wachten over. Elke oplossing die naast het bestaande werk staat, kost extra handelingen. Bij drukte valt die er als eerste af. MIT noemt dit letterlijk als hoofdreden dat maatwerktools stranden: ze passen niet bij de dagelijkse gang van zaken.
Een oplossing landt pas als hij zit waar het werk al zit. Dat betekent in de praktijk koppelen aan de pakketten die u al gebruikt — Exact Online, SnelStart, AFAS, Nmbrs — zodat gegevens één keer worden ingevoerd en overal kloppen. Niet een nieuw scherm erbij, maar minder schermen.
Uit hetzelfde rapport: projecten die bedrijven volledig intern bouwden, mislukten twee keer zo vaak als projecten die ze samen met een externe partij deden. Een buitenstaander stelt de vragen die intern al lang niet meer gesteld worden.
Waarom worden projecten met AI-agents zo vaak gestopt?
Gartner voorspelde op 25 juni 2025 dat ruim 40 procent van de projecten met AI-agents vóór eind 2027 wordt geannuleerd, door oplopende kosten, onduidelijke zakelijke waarde of onvoldoende beheersing van risico’s. AI-agents zijn programma’s die zelf stappen bedenken en uitvoeren in plaats van één opdracht af te handelen.
Gartner wijst daarbij op iets waar u zelf op kunt letten. Veel leveranciers plakken het woord agent op bestaande chatbots en automatiseringen zonder dat er iets zelfstandigs onder zit. Van de duizenden aanbieders die zich zo presenteren, schat Gartner er ongeveer 130 als echt in.
Vraag daarom niet wat een systeem is, maar wat het doet. Welke handeling neemt het over, en wie controleert de uitkomst?
Geldt dit ook voor het Nederlandse mkb?
Een Nederlands faalcijfer bestaat niet, en wij verzinnen er geen. Wat het CBS wel meet: in 2025 gebruikte 29,8 procent van het mkb met 10 tot 249 werkzame personen AI-technologie, tegen 66,2 procent van het grootbedrijf en 13,8 procent van de microbedrijven. Het mkb staat dus grotendeels nog aan het begin.
Daarom doen deze cijfers ertoe. De meeste Nederlandse bedrijven hebben hun eerste AI-project nog voor zich en kunnen die fout dus nog overslaan. Wie nu begint met een pilot om te kijken “wat het doet”, begint aan datzelfde project.
Er is werk dat iemand doet en niet leuk vindt. En er is werk dat níemand doet — dat blijft liggen en wordt vergeten.
<b>Marc Herdes</b>, oprichter
Wat kunt u anders doen?
Draai de volgorde om. Kies niet eerst een techniek en zoek daar een toepassing bij, maar kies één stuk werk dat vaak terugkomt en veel tijd of fouten kost. Meet wat dat werk nu kost, vóórdat er iets gebouwd wordt. Bouw dan het kleinste stuk dat het overneemt, op de plek waar het al gebeurt.
Wij noemen dat de nulmeting, en het is bij ons geen formaliteit. Zonder getal vooraf is er achteraf geen manier om vast te stellen of het echt scheelt. Dan verzandt de evaluatie in indrukken, en indrukken zijn precies wat 95 procent van de onderzochte projecten overhield.
Zo’n eerste stuk hoeft niet groot te zijn. Bij ons begon het met een offerteconfigurator die zichzelf doorrekent: de klant vult zijn situatie in, de prijs rekent mee, en de offerte staat klaar voordat een verkoper de telefoon heeft gepakt. Te meten in doorlooptijd.
Hoe ziet zo’n nulmeting eruit?
Vier dingen legt u vast voordat er één regel code geschreven wordt. Welk werk u meet en hoe vaak het voorkomt. Hoeveel minuten het per keer kost en hoe vaak het over moet. Wie de meting doet en waar die genoteerd wordt. En op welke datum u dezelfde getallen opnieuw ophaalt.
Drie weken turven levert al een getal op dat u tegen de oplevering kunt aanhouden. Het ongemakkelijke deel: zo’n meting kan ook uitwijzen dat het werk minder kost dan gedacht, en dan moet u dit stuk niet laten bouwen. Dat antwoord geven wij ook.
Dit is de lat waar wij onszelf langs leggen. Software is bij ons pas af als in uren, fouten of omzet is aan te wijzen wat er veranderd is. Daarom draait onze software eerst in onze eigen bedrijven. Wat daar dagelijks in gebruik is, staat bij software voor installatiebedrijven.
Wilt u weten wat er in uw bedrijf te meten valt voordat u iets laat bouwen? Dat gesprek en de functionele omschrijving die eruit volgt kosten niets. Marc Herdes en John van den Bosch van Cloudzicht doen ze zelf. Bel 036 52 98 447 of mail naar info@cloudzicht.nl.
Hoe u het dan wel aanpakt, staat op AI-implementatie.
Zullen we bellen?
Zit het nog in uw hoofd?
Dan is dit het goede moment. U hoeft niet te weten wat u wilt bouwen; vertellen waar het werk vastloopt is genoeg. Wij denken hardop mee, zeggen wat wij zouden doen en wat wij zouden laten. Dat eerste gesprek kost u niets.

Zit u hier tegenaan?
Vertel in een paar zinnen wat er beter moet. U krijgt een eerlijk antwoord: wat wij zouden bouwen, wat wij zouden laten liggen, en of het bij ons thuishoort of bij iemand anders. Het eerste gesprek kost u niets.
Liever meteen even bellen of mailen? Dat kan ook.
Uit de praktijk
Hoe dit er in het echt uitziet, staat als verhaal op de persoonlijke site van Marc Herdes.