De demo was indrukwekkend, de praktijk valt tegen: waarom AI-pilots stranden

Laatst bijgewerkt op 2 augustus 2026

Het betekent niet dat de eerste poging waardeloos was. Een gestrande pilot maakt vaak precies zichtbaar wat er ontbreekt om van een interessante toepassing een werkbare oplossing te maken. Wie daaruit de juiste conclusies trekt, kan een tweede poging veel gerichter aanpakken.

Het verhaal begint meestal met een overtuigende demo. Documenten worden in enkele seconden verwerkt en vragen krijgen onmiddellijk een bruikbaar antwoord. De mogelijkheden lijken duidelijk en de directie beslist om een pilot te starten. Enkele maanden later is er een eerste toepassing, maar na verloop van tijd neemt het gebruik af. Uiteindelijk kan niemand nog precies uitleggen wat de pilot heeft opgebracht of waarom hij niet verder werd uitgerold.

Dat patroon komt niet alleen bij kleinere bedrijven voor. Uit een Gartner-onderzoek bij 782 verantwoordelijken voor infrastructuur en operations (april 2026) haalt slechts 28% van de AI-toepassingen volledig de verwachte return, terwijl 20% ronduit mislukt. De rode draad is niet dat de technologie tekortschiet, maar dat projecten blijven steken voor ze waarde opleveren. Volgens een ander Gartner-onderzoek uit april 2026 investeren organisaties met geslaagde AI tot vier keer meer in hun data- en analytics-fundamenten, zoals datakwaliteit, governance en de mensen eromheen, dan organisaties met tegenvallende resultaten.

De technologie speelt uiteraard een rol, maar verklaart zelden het volledige verhaal. De moeilijkste stap is doorgaans niet aantonen dat een toepassing technisch iets kan. Het is ervoor zorgen dat ze betrouwbaar, betaalbaar en controleerbaar werkt binnen een bestaand bedrijfsproces.

De pilot werd niet stopgezet, maar viel langzaam stil

Veel gestrande AI-pilots worden nooit formeel beëindigd. Er is geen evaluatievergadering, geen duidelijke beslissing en geen afsluitende conclusie. De interne trekker krijgt andere prioriteiten, de leverancier neemt nog enkele keren contact op en na verloop van tijd vraagt niemand nog naar het project.

Dat onderscheid is belangrijk. Een pilot die bewust wordt stopgezet, kan een duidelijke les opleveren: de toepassing is technisch niet haalbaar, de data zijn onvoldoende betrouwbaar of de verwachte opbrengst weegt niet op tegen de investering. Een pilot die gewoon uitdooft, laat vooral frustratie en scepsis achter. Bij een volgend voorstel klinkt dan al snel: “Dat hebben we al geprobeerd.”

Het verloren budget is daarbij niet noodzakelijk het grootste probleem. Verloren vertrouwen kan zwaarder doorwegen, omdat het ook volgende toepassingen afremt die wél een sterke businesscase hebben. Wie wil vermijden dat een tweede poging hetzelfde lot ondergaat, moet eerst begrijpen waarom de eerste pilot stilviel.

Oorzaak 1: de pilot begon bij een tool, niet bij een bedrijfsprobleem

De aanleiding was een aantrekkelijke demonstratie, niet een probleem dat al langer op de agenda stond. Daardoor werd de centrale vraag: “Wat kunnen we met deze tool doen?” De betere vraag was geweest: “Waar verliezen we vandaag tijd, marge of capaciteit, en welke oplossing past daar het best bij?”

Een technologie waarvoor nog een probleem moet worden gezocht, vindt meestal wel een mogelijke toepassing. Dat betekent nog niet dat die toepassing belangrijk genoeg is om tijd, budget en aandacht te krijgen. Zodra de dagelijkse druk opnieuw toeneemt, verliest een project zonder duidelijke noodzaak bijna vanzelf terrein.

Een sterke AI-pilot begint daarom niet met een lijst van functionaliteiten, maar met een afgebakend bedrijfsprobleem. Denk aan terugkerend overtypwerk, lange doorlooptijden, fouten in orderverwerking, tijdrovende controles of medewerkers die telkens dezelfde informatie moeten opzoeken. Pas daarna volgt de vraag of AI daarvoor de meest geschikte oplossing is. Soms volstaat klassieke automatisering, een betere rapportering of een eenvoudiger procesaanpassing.

Oorzaak 2: de demo werkte op nette voorbeelden, de praktijk niet

Een leverancier demonstreert zijn toepassing begrijpelijkerwijs met geschikte voorbeelden: goed leesbare documenten, eenduidige productnamen en volledig ingevulde gegevens. De bedrijfspraktijk is minder geordend. Leveranciers gebruiken verschillende documentformaten, productnamen verschillen tussen systemen en historische gegevens zijn niet altijd op dezelfde manier geregistreerd.

Een pilot kan daardoor goed werken op een beperkte verzameling testgevallen en toch problemen krijgen zodra hij met echte volumes en uitzonderingen wordt geconfronteerd. Dat hoeft geen misleiding door de leverancier te zijn. Het toont vooral het verschil tussen een technisch veelbelovende toepassing en een oplossing waarop een proces daadwerkelijk kan steunen.

Een toepassing die bij de meeste documenten correct werkt, kan nog altijd onbruikbaar zijn wanneer elke afwijking manuele opvolging vraagt. Zeker in facturatie, orderverwerking, planning of prijszetting kan een beperkte foutenmarge dagelijks tientallen uitzonderingen veroorzaken. Het werk om die laatste kloof te dichten, met betere data, validatieregels, procesaanpassingen en controles, is vaak groter dan tijdens de demo zichtbaar was.

Oorzaak 3: niemand was verantwoordelijk voor het resultaat

In veel pilots staat de toepassing naast het bestaande proces in plaats van erin. Medewerkers moeten documenten apart opladen, informatie overtypen of een extra scherm raadplegen. Daardoor ontstaat geen nieuwe werkwijze, maar bijkomend werk boven op de bestaande taken.

Ook het eigenaarschap is vaak onvoldoende geregeld. De toepassing wordt getrokken door een enthousiaste medewerker, IT of de externe leverancier. Zij kunnen het project vooruithelpen, maar kunnen niet altijd beslissen hoe het operationele proces moet veranderen. Zodra hun aandacht verschuift, valt het gebruik terug.

Het resultaat van een pilot moet daarom een duidelijke eigenaar in de business hebben: iemand die verantwoordelijk is voor de beoogde verbetering en voldoende mandaat heeft om de werkwijze aan te passen. IT, dataspecialisten en leveranciers blijven belangrijke partners, maar zij kunnen het zakelijke eigenaarschap niet vervangen. De toepassing moet bovendien deel worden van de dagelijkse workflow. Zolang medewerkers gemakkelijk naar het oude proces kunnen terugkeren, zal dat onder tijdsdruk meestal ook gebeuren.

Oorzaak 4: gebruik en controle waren niet ontworpen

Tijdens een demonstratie gaat veel aandacht naar wat de toepassing kan. Twee andere vragen krijgen minder aandacht: wie gebruikt ze elke dag en hoe worden de resultaten gecontroleerd?

AI-systemen kunnen onjuiste resultaten produceren die geloofwaardig geformuleerd zijn en daardoor niet altijd onmiddellijk als fout herkenbaar zijn. Zonder duidelijke controleafspraken ontstaan twee uitersten. Ofwel vertrouwen medewerkers de output te snel, tot een verkeerde prijs, boeking of beslissing het vertrouwen beschadigt. Ofwel controleren ze elk resultaat volledig opnieuw, waardoor de verwachte tijdwinst verdwijnt.

Een werkbare toepassing kiest niet tussen blind vertrouwen en volledige dubbele controle. Ze bepaalt welke resultaten automatisch verwerkt mogen worden, welke afwijkingen een waarschuwing veroorzaken en wanneer menselijke goedkeuring nodig blijft. Dat kan gebeuren met validatieregels, drempelwaarden, steekproeven en opvolging van fouten.

De medewerkers die met de oplossing moeten werken, horen daarom vanaf het begin bij de pilot betrokken te zijn. Zij kennen de uitzonderingen, informele afspraken en praktische beperkingen die tijdens een demo gemakkelijk buiten beeld blijven. Hun betrokkenheid is niet alleen nodig voor acceptatie, maar ook om de toepassing inhoudelijk beter te maken.

Oorzaak 5: niemand had bepaald wat succes betekende

Voor veel pilots wordt vooraf niet afgesproken wat ze moeten aantonen. Hoeveel tijd moet de toepassing besparen? Welke nauwkeurigheid is nodig? Welk volume moet ze aankunnen? Welke kosten zijn aanvaardbaar? En op welk moment wordt beslist of het project doorgaat?

Zonder zulke afspraken kan een pilot moeilijk slagen of mislukken. Hij blijft dan “interessant” of “veelbelovend”, maar die kwalificaties bieden geen basis voor een investeringsbeslissing. Ook de uitspraak dat een organisatie “ervan leert” is onvoldoende zolang niet is bepaald welke vragen de pilot moet beantwoorden.

Succescriteria hoeven niet ingewikkeld te zijn. Ze moeten vooral meetbaar en relevant zijn. Een pilot kan bijvoorbeeld moeten aantonen dat een bepaald aantal documenten per week binnen een afgesproken foutenmarge wordt verwerkt, dat medewerkers aantoonbaar tijd besparen of dat de kosten per transactie onder een bepaalde grens blijven. Daarnaast is een vaste beslisdatum nodig: doorgaan, bijsturen of stoppen.

Bewust stoppen kan een volwaardige uitkomst zijn wanneer de evaluatie duidelijk maakt waarom verdere investering niet verantwoord is. Een pilot zonder evaluatie of besluit levert doorgaans veel minder bruikbare kennis op.

Zo voorkomt u dat AI-pilots stranden bij een tweede poging

Een gestrande pilot is geen reden om AI volledig af te schrijven. Hij is wel een reden om de volgorde te veranderen. Begin niet opnieuw bij een nieuwe tool, maar bij de problemen waarvoor uw organisatie vandaag tijd, marge of capaciteit verliest. Die juiste volgorde werken we uit bij AI en automatisering.

Breng die problemen eerst in kaart en beoordeel vervolgens welke toepassingen voldoende waarde kunnen opleveren. Daarbij zijn drie criteria nuttig: de mogelijke opbrengst, de betrouwbaarheid van die inschatting en de inspanning die nodig is om de toepassing werkelijk in het proces te integreren.

Druk de verwachte opbrengst bij voorkeur uit als een bandbreedte. Eén exact bedrag suggereert een zekerheid die bij een eerste analyse meestal niet bestaat. Maak daarnaast onderscheid tussen kansen waarvan volumes en verwerkingstijden goed bekend zijn en toepassingen waarvan het effect moeilijker vooraf te voorspellen is. Documentverwerking laat zich bijvoorbeeld doorgaans concreter ramen dan een AI-model dat de verkoop of vraag moet voorspellen.

Neem ten slotte niet alleen licenties en externe ontwikkeling mee in de inspanning. Ook de tijd van medewerkers, de voorbereiding van data, integraties, controles, opleiding en procesaanpassingen behoren tot de werkelijke investering. Een toepassing met een hoge theoretische opbrengst maar veel onzekerheid en een zware implementatie is zelden het beste eerste project.

Laat de gekozen pilot vanaf het begin draaien op representatieve data uit uw eigen systemen. Neem ook moeilijke dossiers, afwijkende documenten en uitzonderingen mee. Een test die alleen werkt op zorgvuldig geselecteerde voorbeelden, zegt weinig over de haalbaarheid in de praktijk.

Wijs vervolgens een eigenaar aan, leg vast waar de toepassing in het proces komt en betrek de toekomstige gebruikers. Bepaal wie welke resultaten controleert en wanneer menselijke tussenkomst nodig blijft. Sluit af met meetbare succescriteria en een vooraf vastgelegde beslisdatum.

Wat uw eerste pilot u al heeft geleerd

De manier waarop een pilot strandde, geeft vaak aan wat eerst moet worden aangepakt. Struikelde de toepassing over de eigen gegevens, dan moet de kwaliteit en beschikbaarheid van de data rond dat proces verbeteren. Hoe u die basis op orde krijgt, leest u bij Stuurinformatie. Die investering kan ook zonder AI waarde opleveren, bijvoorbeeld door minder fouten, betere rapportering of efficiëntere controles.

Viel de pilot stil door een gebrek aan eigenaarschap of gebruik, dan ligt de belangrijkste uitdaging bij de inrichting van het proces en de manier waarop veranderingen worden ingevoerd. Geen nieuwe tool lost dat op zonder duidelijke verantwoordelijkheid en betrokkenheid van de medewerkers.

Kon niemand uitleggen wat de pilot financieel of operationeel moest opleveren, dan ontbrak een voldoende scherpe businesscase. De logische volgende stap is dan niet meteen een nieuwe pilot, maar een nuchtere vergelijking van de mogelijke AI-toepassingen op basis van opbrengst, zekerheid en inspanning. Voor wat vandaag al bewezen rendeert, ziet u AI voor KMO’s: toepassingen die vandaag al renderen.

De centrale vraag is daarom niet alleen welke AI-toepassing u wilt testen. Belangrijker is of het bedrijfsprobleem voldoende duidelijk is, de data representatief zijn en de organisatie klaar is om de toepassing in het dagelijkse proces op te nemen.

Een AI-scan van Beyond KPI brengt die voorwaarden vooraf in kaart. Het resultaat is geen lange lijst met mogelijke tools, maar een beslisdocument met geprioriteerde toepassingen, een eerste raming van opbrengst en inspanning en een onderbouwde keuze voor een haalbare volgende stap.

Veelgestelde vragen

Is een gestrande AI-pilot weggegooid geld?

Niet noodzakelijk. De manier waarop de pilot strandde, kan aantonen wat eerst moet worden aangepakt: de data rond een proces, het zakelijke eigenaarschap, de controle of de businesscase. Die kennis heeft echter alleen waarde wanneer de pilot bewust wordt geëvalueerd en de lessen worden vastgelegd. Zonder evaluatie blijft vooral een kost en een negatieve ervaring over.

Hoe herkent u vooraf een AI-pilot die dreigt te stranden?

Drie signalen verdienen bijzondere aandacht. De pilot draait uitsluitend op voorbeelden van de leverancier in plaats van op eigen gegevens. Er is geen eigenaar in de business die verantwoordelijk is voor het resultaat en het proces mag aanpassen. Of niemand kan helder uitleggen wat de pilot moet aantonen om een verdere investering te verantwoorden. Wanneer meerdere van die signalen aanwezig zijn, is het verstandig om eerst de voorwaarden aan te scherpen.

Wanneer stopt u beter een lopende AI-pilot?

Idealiter neemt u die beslissing op het vooraf afgesproken evaluatiemoment en op basis van meetbare criteria. Eerder stoppen kan verstandig zijn wanneer blijkt dat betrouwbare data niet binnen een redelijke inspanning beschikbaar zijn, de toepassing technisch onvoldoende presteert of de verwachte opbrengst zelfs in een gunstig scenario niet opweegt tegen de kosten en inspanningen. Bewust stoppen is beter dan een project zonder beslissing te laten uitdoven.

Begint een tweede poging beter met dezelfde toepassing of met een andere?

Dat hangt af van de oorzaak van het probleem. Was de businesscase sterk, maar schortte het aan data, eigenaarschap, integratie of betrokkenheid van medewerkers, dan kan dezelfde toepassing nog altijd zinvol zijn. Was nooit duidelijk welk probleem werd opgelost of welke waarde de toepassing moest opleveren, vergelijk dan eerst verschillende mogelijkheden op basis van opbrengst, zekerheid en inspanning.

Dennis Houthoofd, oprichter Beyond KPI. 25+ jaar ervaring in finance, data en AI voor Vlaamse KMO's. Meer over Dennis.