De software werkte. Het project mislukte toch.
Misschien heb je zo’n project van dichtbij meegemaakt. Of je wilt er één starten en je twijfelt of het zinvol is. In beide gevallen gaat je vraag niet over de technologie, want die werkt. Je vraag is of jouw organisatie er iets uit haalt. Dat maakt het een investeringsbeslissing en geen technologiekeuze.
Deze pagina legt niet uit dat AI moeilijk is. Ze legt uit waarom AI-projecten mislukken: ze zet de vier oorzaken op een rij die wij in de praktijk zien, en wat je er vóór de start aan doet. Speelt je data daarin mee, lees dan ook onze analyse van een AI-pilot die mislukt door slechte data.
Je scepsis is terecht. Dit is geen pleidooi om toch maar te beginnen. Maar wat betekent “mislukt” hier eigenlijk, en hoe groot is het?
De statistiek die iedereen citeert over waarom AI-projecten mislukken
Die statistiek verklaart zichzelf niet. Het cijfer dat overal opduikt, “85 procent van de AI-projecten mislukt“, komt uit een voorspelling die Gartner in februari 2018 deed. En ze zegt iets anders dan wat ze geacht wordt te zeggen. Tot en met 2022 zouden 85 procent van de AI-projecten een fout resultaat opleveren, door vertekening in de data, de algoritmes of het team. Dat is geen faalpercentage, en de horizon van die voorspelling ligt achter ons. Wat er wél gemeten is, gaat over iets anders.
McKinsey ondervroeg in de zomer van 2025 bedrijven over hun AI-gebruik en publiceerde de resultaten in november van dat jaar. Bijna twee derde van de organisaties is nog niet begonnen met het uitrollen van AI over het hele bedrijf. En van de bedrijven die er wél iets van terugzien in hun resultaat, 39 procent, zegt het merendeel dat het om minder dan 5 procent van hun bedrijfsresultaat gaat.
Van dichtbij ziet mislukken er anders uit. In de trajecten die wij zien, betekent “mislukt” zelden dat er niets werkt. Het betekent:
– dat de beoogde tijdswinst uitblijft;
– dat het systeem technisch draait maar niemand het gebruikt;
– dat het halverwege stilvalt nadat er al geïnvesteerd is, zonder zichtbaar resultaat;
– of dat het in de pilot werkt en daarbuiten niet.
Vier keer een project dat op papier af is en niets verandert. In de projecten die wij zien, zit de oorzaak daarvan bijna nooit in de technologie zelf. Er liggen vier andere oorzaken onder, en die vier zijn de rest van deze pagina.
Oorzaak 1: het proces was niet klaar voor technologie
Een chaotisch proces automatiseren levert geautomatiseerde chaos op.
Verwerken drie mensen hetzelfde document op drie manieren, dan levert een geautomatiseerd systeem drie uitkomsten op. En er is geen afgesproken norm om te bepalen welke van de drie de juiste is. Dat is het echte probleem: niet dat het systeem er naast zit, maar dat niemand kan aantonen dát het er naast zit. Een systeem kan alleen consequent zijn op een proces dat zelf consequent is. Van de vier oorzaken is dit de oorzaak die wij in onze eigen trajecten het vaakst tegenkomen, en tegelijk de oorzaak die achteraf het minst genoemd wordt.
RAND kwam in 2024 op hetzelfde uit: misverstanden over wat het project eigenlijk moest oplossen, zijn volgens dat onderzoek de meest voorkomende reden waarom AI-projecten mislukken. Wat je daaraan vooraf doet, is geen technisch werk. Je documenteert het proces, je brengt de uitzonderingen in kaart en je spreekt af welke uitkomst je wilt. Dat is organisatiewerk, samen met de mensen die het werk vandaag doen.
Neem een bedrijf dat zijn inkomende facturen wil automatiseren. De leveranciers sturen die facturen in tien verschillende opmaken, en hoe ze intern verwerkt worden, staat nergens opgeschreven. Het zit in de hoofden van drie mensen die het al jaren doen. De automatisering loopt daar niet vast op de software. Ze loopt vast omdat niemand eigenaar is van de vraag hoe het proces hoort te lopen.
Onze vuistregel: steek minstens evenveel tijd in het ontwerpen van het proces als in het ontwerpen van de technologie. Het werk zit vóór de tool. Een gestandaardiseerd proces levert alleen nog geen bruikbare data op. Wat krijgt dat systeem eigenlijk te zien?
Oorzaak 2: de data was niet klaar
Een AI-systeem leert uit voorbeelden uit het verleden. Is die data incompleet, inconsistent of onbetrouwbaar, dan leert het systeem precies dat. Een documentherkenningssysteem dat op slecht gelabelde voorbeelden getraind is, maakt niet af en toe een fout: het maakt structureel dezelfde fout. En die fout kan je er achteraf niet uit halen door het model beter af te stellen. Dat is niet alleen onze waarneming.
Toen Gartner in januari 2026 de redenen opsomde waarom generatieve-AI-projecten na de proof of concept sneuvelen, stond slechte datakwaliteit bovenaan. RAND waarschuwt daarbij voor de meest onderschatte valkuil: data die verzameld is voor iets anders, hergebruiken voor een AI-model. Je lost dat dus niet op ná de implementatie. Het is een vereiste die je vóór de implementatie vaststelt.
Of je data daaraan voldoet, is een aparte maar samenhangende vraag: is je data klaar voor AI? Proces en data kunnen allebei op orde zijn zonder dat iemand zich eigenaar voelt. Wie draagt het project dan?
Oorzaak 3: geen eigenaar in de business
In de projecten die wij zien, krijgt een AI-project dat een IT-project blijft wel een oplevering en geen gebruik. De technologie wordt gebouwd, de mensen die ermee moeten werken adopteren ze niet, en dat is geen onwil. Er is gewoon niemand die verantwoordelijk is voor het gebruik. Niemand had vooraf afgesproken wat goed genoeg was, en dus kan achteraf niemand zeggen of het dat is.
Wat ontbreekt, is één iemand uit de business: een mens met een naam, geen vakje in een organigram. Die persoon heeft vier taken:
– de businesscase bewaken;
– bepalen wat “goed genoeg” is;
– de adoptie in het eigen team sturen;
– terugkoppelen wat er niet werkt.
Zonder die persoon wordt het opgeleverde systeem een weesproject. De IT-afdeling kan een systeem bouwen en opleveren, maar ze kan het gebruik niet afdwingen in een team dat niet van haar is. Het ontbreken van een eigenaar is een organisatiekeuze, geen fout.
Benoem die eigenaar dus vóór je start, niet nadat de technologie klaar is. Dan bepaalt hij mee wat het systeem moet doen, in plaats van te erven wat het geworden is. Een benoemde eigenaar maakt het project nog niet veilig. Wanneer mag je opschalen?
Oorzaak 4: te snel schalen zonder bewijs
De duurste mislukking is de brede uitrol vóór de test.
Stel dat je een AI-systeem uitrolt naar vijfhonderd medewerkers voordat iemand heeft nagegaan of het werkt met jouw documenten, in jouw omgeving. Dan koop je geen oplossing, je koopt een hypothese. De demo is dat bewijs niet. Een demo draait op documenten die voor de demo gekozen zijn. Jouw IT-omgeving zit er niet in, jouw documentformaten zitten er niet in, en jouw uitzonderingen al helemaal niet.
In de trajecten die wij zien, is dat het verschil tussen een systeem dat overtuigt in de vergaderzaal en een systeem dat het net houdt op maandagochtend. Het alternatief is klein en saai: een afgebakende proof of concept op één use case, met echte documenten, in de echte omgeving, met een afgesproken einddatum. Werkt het, dan weet je wat je koopt. Werkt het niet, dan heb je dat vastgesteld op een afgebakende proef in plaats van op een volledige uitrol, voor een fractie van wat die uitrol had gekost.
Een POC is dus geen stap die je overslaat om sneller te gaan. Het is de stap die bepaalt of je de juiste richting op gaat. Die vier oorzaken hebben één ding gemeen: je kan ze alle vier vermijden. Hoe ziet een aanpak eruit die dat doet?
Hoe ziet een aanpak eruit die wél standhoudt?
De AI-projecten die bij Belgische KMO’s wél standhouden, hebben in onze ervaring zes dingen gemeen.
1. Scherpe use case: één proces, niet alle processen tegelijk.
2. Procesontwerp eerst: documenteer het proces vóór je technologie kiest.
3. Data-audit: controleer kwaliteit en volledigheid vóór je begint.
4. Zakelijke eigenaar: benoemd en actief, niet passief.
5. POC vóór uitrol: bewijs in je eigen context vóór je opschaalt.
6. Iteratief verbeteren: geen 100% nauwkeurigheid op dag één; plan verbeterrondes in.
In dat rijtje staat geen enkele technologiekeuze, en dat is geen toeval. RAND vat het samen in één regel: de projecten die slagen, zijn scherp gericht op het probleem dat opgelost moet worden, niet op de technologie.
Zo structureren wij de POC Document Automatisering: één use case in je eigen omgeving, en na afloop weet je of verder investeren zinvol is.
Het grootste deel van deze zes kenmerken heb je niet van ons nodig. De use case afbakenen, de eigenaar benoemen, de succescriteria afspreken, klein beginnen: dat regel je zelf, en het kost je geen euro aan externe hulp. De data-audit is het enige punt waar dat minder makkelijk is, en dat is meteen ook het punt waarop de meeste tijd verloren gaat.
En als je ons wél vraagt: een proef die uitwijst dat je hier beter niet aan begint, is voor ons een geslaagde proef. Dat is precies waarvoor ze dient.