Waarom AI-projecten niet in productie komen

Vijfennegentig procent. Het getal komt uit een rapport van MIT NANDA van juli 2025 en duikt sindsdien in elke presentatie over AI op: vijfennegentig procent van de organisaties haalt geen rendement uit generatieve AI. Het rapport doet die uitspraak zelf, maar wie het openslaat, ziet dat hij niet controleerbaar is. Het rust op 52 interviews, 153 vragenlijsten en ruim 300 openbaar bekendgemaakte AI-initiatieven. De vijf procent gaat over maatwerk-AI voor een specifieke taak, en "geslaagd" betekent daar dat gebruikers of bestuurders zelf zeiden dat het een merkbaar en blijvend effect had. Welke noemer daarbij hoort, staat er niet. Het rapport noemt zijn cijfers "richtinggevend", gebaseerd op interviews en niet op officiële bedrijfsrapportage, en het is niet door vakgenoten beoordeeld. Futuriom haalde de Wharton-hoogleraar Kevin Werbach aan met dezelfde conclusie: nergens staat hoe de vijfennegentig is berekend.

De andere cijfers zijn op een andere manier zacht. Gartner voorspelde in juli 2024 dat minstens dertig procent van de generatieve-AI-projecten na de proof of concept zou worden afgebroken, door slechte datakwaliteit, ontbrekende risicobeheersing, oplopende kosten of een onduidelijke bedrijfswaarde. Dat is een voorspelling, geen meting. En de "tachtig procent van de AI-projecten mislukt" die RAND in 2024 aanhaalt, is een schatting van anderen die RAND citeert, niet iets dat RAND heeft geteld. Het eigen onderzoek van RAND bestond uit 65 interviews met AI-engineers en onderzoekers, en "mislukt" was daar: door de organisatie zelf als mislukt ervaren.

De cijfers zijn dus zacht. De oorzaken die de onderzoekers noemen, herkennen wij wel, bij bedrijven van tien tot honderd man. En die oorzaken zijn zelden technisch. RAND noemt er vijf, en maar één gaat over wat AI wel of niet kan. De andere vier gaan over het verkeerde probleem oplossen, over data die er niet is, over technologie kiezen voordat het probleem gekozen is, en over het ontbreken van wat nodig is om iets werkelijk te laten draaien. Dat zijn geen AI-problemen, maar problemen van werk dat door een bedrijf beweegt.

Dichter bij huis

MIT en Gartner keken naar budgetten die u niet herkent; Gartner rekent voor de zwaarste aanpak met 5 tot 20 miljoen dollar. Volgens het CBS gebruikte in 2025 27 procent van de bedrijven met 10 tot 50 werkzame personen AI, en 45 procent van de bedrijven met 50 tot 250. Twee jaar eerder was dat 11 en 20 procent; de cijfers over 2025 zijn voorlopig. Van de bedrijven die AI gebruiken, doet 35 procent dat voor marketing of verkoop en 17 procent voor boekhouding, controle of financieel beheer. Een bedrijf telt mee zodra het één AI-technologie uit een vaste lijst gebruikt, hoe klein ook. Of er iets werkt, meet het CBS niet.

MIT zag hetzelfde patroon in de budgetten: die gaan vaker naar verkoop en marketing, omdat het resultaat daar makkelijk zichtbaar is, terwijl het rapport de betere opbrengst juist in de backoffice ziet. De les is smal: kijk niet waar AI het zichtbaarst is, maar waar terugkerend handwerk meetbaar kan verdwijnen.

Een demo is geen productie

Een AI-demo is een gunstig geval dat goed is afgelopen. Meestal kiest de leverancier de order, het model leest hem uit, de regels staan in het scherm, en het klopt. Op onze site staat dat negentig procent makkelijk is en dat de rest bepaalt of het werkt; dat staat er omdat we het zo hebben meegemaakt. Het verschil tussen een demo en een systeem dat op dinsdagochtend draait, zit in wat niet in de demo zat.

Neem de export. Bij Taxi Zoetermeer Direct kwamen de ritten van een vervoerscentrale maandelijks als CSV, en die CSV was elke maand anders opgemaakt: een kolom die van plek wisselde, een datumnotatie die veranderde, een extra regel bovenaan. In productie is het twaalf keer per jaar een ander bestand:

`` maart: ritnr;datum;klant;van;naar;bedrag april: ritnr;klant;datum;van;naar;bedrag mei: Export vervoerscentrale mei ritnr;klant;datum;van;naar;bedrag;opmerking ``

Een gestileerd voorbeeld, geen kopie van dat bestand, maar dit soort verschuiving. Een pilot die op maart is gebouwd, staat in april stil. Niet omdat het model slecht is, maar omdat niemand had gevraagd of het bestand elke maand hetzelfde is.

Hetzelfde geldt voor adressen. "Bij de ingang van het ziekenhuis" is voor een chauffeur een prima adres en voor een systeem niets. Zulke ritten gingen niet automatisch door, maar in een bak met uitzonderingen, en daar zat de belangrijkste keuze: liever een rit die wordt voorgelegd dan een rit die verkeerd wordt gedeclareerd.

Niemand die de bak leegt

Die bak is waar wij pilots het vaakst zien stranden, en het is geen technisch punt. Een pilot draait bij de leverancier of de IT'er; de uitzonderingen komen bij niemand terecht, want in de pilot waren ze er niet. Zodra het echt draait, staan er op maandag orders die het systeem niet vertrouwde, en dan blijkt dat er geen naam boven die lijst staat. De medewerker die het vroeger overtypte, gaat ervan uit dat het systeem het nu doet. Het systeem gaat ervan uit dat zij het oppakt. Een paar weken later is de lijst te lang om in te halen en gaat iemand weer overtypen, naast het systeem in plaats van ermee.

RAND noemt als eerste oorzaak dat bedrijfsleiding en technici het verkeerde probleem definiëren of elkaar daarover niet begrijpen. De lijst zonder eigenaar is daar een voorbeeld van, uit onze eigen praktijk, niet uit dat onderzoek. Wij noemen het eenvoudiger: er is geen eigenaar in de business. Bij Rene's Autoservice beschreef de klant achteraf wat het verschil had gemaakt: als iets niet duidelijk was, werd het gevraagd in plaats van ingevuld. Dat is een keuze aan het begin. Wie de vraag beantwoordt, is degene die de bak straks leegt, en die persoon moet er zijn voordat er iets gebouwd wordt.

De laatste tien procent is het werk

Wat overblijft, is dit: wat gebeurt er als de mailbox even niet bereikbaar is, en wordt hetzelfde bericht dan twee keer verwerkt? Wie ziet dat de koppeling sinds donderdag niets meer heeft gedaan? Waar staat wat er gisteren is verwerkt, zodat iemand een fout kan terugzoeken? Wie belt u als het stilvalt? Dat is foutafhandeling, logging en beheer, en het is saai. In onze ervaring is het ook het grootste deel van de bouwtijd, en het wordt in een pilot overgeslagen omdat de pilot het moet halen.

Het is ook de plek waar deze aanpak niet werkt. Een proces dat een paar keer per maand voorkomt en elke keer anders is, verdient geen koppeling en geen AI-model; daar is de uitzonderingenbak groter dan het proces. Hetzelfde geldt voor werk zonder regel, waar de medewerker elke keer een afweging maakt die ze niet kan uitleggen. Dan bouwt u een systeem dat vragen stelt die niemand kan beantwoorden.

De pilot die nooit kon slagen

De stilste manier waarop een AI-project mislukt, is dat niemand kan zeggen of het geslaagd is. De pilot begon met enthousiasme en eindigde met een gevoel. Niemand had geteld hoeveel orders er per week binnenkwamen, hoeveel minuten er aan elk zat en hoe vaak het fout ging. Zonder dat getal is er na drie maanden niets om naast te leggen, en dan wint de sterkste mening. Meestal is dat de twijfel.

Die nulmeting kunt u zelf doen, zonder iemand in te huren. Kies één proces. Laat de medewerker die het doet turven: hoe vaak, hoeveel minuten per keer, hoe vaak er iets fout ging of moest worden nagevraagd, en wie daarover besliste. Turf minstens één volledige cyclus; bij maandwerk is een week niet genoeg. Vraag de export van de laatste drie maanden op en leg de koppen naast elkaar. Zit u bij een demo, stel dan deze vragen:

• Wat doet het als het bestand er volgende maand anders uitziet?
• Waar komen de gevallen terecht die het niet vertrouwt, en wie kijkt daarnaar?
• Wat gebeurt er als hetzelfde bericht twee keer binnenkomt?
• Hoe zie ik dat het sinds gisteren niets meer heeft gedaan?
• Wie bel ik als het stilvalt, en wat kost dat per maand?
• Waar staat het cijfer van vóór de pilot waarmee we dit gaan vergelijken?

Wie op de laatste vraag geen antwoord krijgt, kan straks niet beoordelen of het gelukt is.

Wilt u dat wij tellen, dan is dat de Automation Check: één proces stap voor stap doorgenomen, hoe vaak, hoeveel minuten, hoeveel fouten, wat automatiseerbaar is en wat niet, en een advies: bouwen of niet. Dat kost 295 euro, en soms is het antwoord nee.