95% van de generatieve AI-pilots mislukt.
Dat is het cijfer uit het MIT-rapport van 2025. Het klinkt alarmerend. Maar als je de reden achter dat cijfer begrijpt, is het eigenlijk geruststellend — want het is een probleem dat je kunt vermijden.
De pilots mislukken niet omdat de technologie niet werkt. Ze mislukken omdat organisaties beginnen bij de tool, niet bij het vraagstuk. Bij de demo, niet bij de diagnose. Bij de leverancier, niet bij de architectuur. Ze bouwen een proof of concept dat imponeert in een presentatie en irrelevant is in productie.
Deze serie heeft zeven weken lang een framework opgebouwd. Nu de vraag: hoe vertaal je dat naar een eerste stap die daadwerkelijk waarde oplevert?
De meest gemaakte fout: beginnen bij de tool
Er is een patroon dat in bijna elk mislukt AI-traject terugkomt:
- Directie ziet een demo en wil “iets met AI”
- IT of een consultantbureau selecteert een platform
- Er wordt een pilot gebouwd op een willekeurige use case
- De pilot imponeert in een presentatie
- De pilot wordt niet uitgerold omdat de businesswaarde onduidelijk is
- Het budget loopt op, het vertrouwen neemt af, het project stopt
De fundamentele fout zit in stap 1 en 2. Je begint bij de oplossing voordat je het probleem hebt gedefinieerd. En je selecteert een platform voordat je weet welke architectuur je nodig hebt.
De juiste volgorde is omgekeerd: begin bij een concreet werkproces met meetbare uitkomst, definieer welke AI-capability dat proces versnelt, en bepaal dán pas welke architectuurkeuzes daarvoor nodig zijn.
Stap 1: Selecteer één use case die geschikt is voor het vliegwiel
Niet elke use case is geschikt als startpunt voor een AI-vliegwiel. De beste eerste use case voldoet aan vier criteria:
Hoge herhalingswaarde. Het moet een proces zijn dat tientallen of honderden keren per week voorkomt. Eenmalige of zelden herhaalde taken leveren onvoldoende data om het geheugen te trainen en het vliegwiel op gang te brengen.
Meetbare uitkomst. Je moet vooraf kunnen definiëren wat succes betekent: doorlooptijd, nauwkeurigheid, escalatierate, conversieratio, kostprijs per eenheid. Vage doelen als “efficiënter werken” zijn ongeschikt als startpunt.
Beheersbaar risico. Begin niet met processen waarbij een fout van het AI-systeem onherstelbare schade aanricht. Klantenservice-routing, offerteondersteuning, documentclassificatie, interne kenniszoekopdrachten — dit zijn processen met hoge herhalingswaarde, meetbare output en beheersbaar risico als het systeem een keer een fout maakt.
Goede databasis. Het geheugen kan alleen bouwen op data die bestaat. Begin met een use case waarvoor al historische data beschikbaar is: klantinteracties, beslissingslogboeken, procesuitkomsten. Een use case zonder databasis kan geen vliegwiel bouwen.
Praktische toets: een use case die scoort op alle vier de criteria en waarvoor je binnen 90 dagen meetbare productieresultaten kunt realiseren, is een goede start.
Stap 2: Maak de drie architectuurkeuzes bewust
Zodra de use case is gekozen, maak je drie expliciete architectuurkeuzes voordat je begint met bouwen.
Modelkeuze. Welk model gebruik je voor welke taak binnen deze use case? Is er redeneerwerk dat een frontier model vereist, of volstaat een kleiner, sneller model voor de meeste stappen? Definieer dit vooraf — en bouw routing in, ook al heb je op dag één maar één model.
Harness-ontwerp. Welke guardrails zijn vereist voor deze use case? Welke acties mag het systeem autonoom uitvoeren? Welke vereisen menselijke goedkeuring? Welke tools worden gekoppeld, met welke validatielogica? Schrijf dit op als ontwerpdocument voordat je een regel code schrijft.
Geheugenstrategie. Wat moet het systeem onthouden? Definieer de drie lagen: wat is episodisch (specifieke interacties), wat is semantisch (domeinkennis), wat is procedureel (geleerde werkwijzen)? Welke storage-oplossing past bij het volume en de complexiteit van deze use case?
Deze drie keuzes kosten een dag om uit te werken. Ze besparen maanden aan herwerk en herbouw.
Stap 3: Bouw klein, meet snel, schaal bewust
Het vliegwiel begint niet groot. Het begint met één proces, één team, één set meetbare KPI’s.
Definieer vóór de lancering de KPI’s per laag:
Model-KPI’s. Task completion rate, hallucination rate op jouw use case (gemeten met jouw evaluatieset, niet op een benchmark), latency per taaktype.
Harness-KPI’s. Tool-call success rate, escalatierate naar menselijke review, fallback-frequentie, gemiddelde kostprijs per taak.
Memory-KPI’s. Retrieval accuracy (haalt het systeem de relevante context op?), geheugengroei per week, verbetering in output-kwaliteit over tijd als maatstaf voor cumulatief leren.
Business-KPI’s. Doorlooptijdreductie, foutenpercentage vergeleken met handmatig proces, medewerkerstevredenheid (vereist het systeem meer of minder handmatige correctie over tijd?).
Meet na vier weken. Meet na drie maanden. Pas aan op basis van data, niet op basis van aannames. Schaal pas als de KPI’s aantonen dat het vliegwiel draait — niet als de demo goed uitpakt.
De interne vraag die niemand stelt, maar iedereen moet beantwoorden
Er is één organisatorische keuze die bepalender is voor succes dan alle technische beslissingen samen: wie is eigenaar van het AI-systeem?
Niet de projecteigenaar van de pilot. Niet de vendor die het platform levert. Maar de structurele eigenaar die verantwoordelijk is voor de kwaliteit van het model, de robuustheid van de harness, de groei van het geheugen, en de verbetering van de KPI’s over tijd.
Organisaties die AI als een project behandelen — met een begin, een einde en een opleverdatum — bouwen iets dat stopt met evolueren zodra het project klaar is. Organisaties die AI als een capaciteit behandelen — zoals finance, compliance of klantbeheer — bouwen iets dat structureel verbetert.
Dat vereist een eigenaar. Niet noodzakelijk een grote afdeling. Maar iemand die maandag de KPI’s bekijkt, vrijdag de verbeteringen doorvoert, en jaarlijks de architectuurkeuzes heroverweegt op basis van wat er is geleerd.
De eerlijke verwachting
AI is geen project. Het is een organisatiecapaciteit die je bouwt.
De eerste negentig dagen leveren meetbare waarde op één use case. Het eerste jaar bouwt het fundament: modelstrategie, harness-architectuur, geheugenstrategie. Na twee jaar heeft een goed gebouwd systeem een institutioneel geheugen dat onderscheidend is ten opzichte van organisaties die later zijn begonnen.
Dat is niet snel. Maar het is ook niet langzaam — vergeleken met de organisaties die nu al het derde pilotproject opstarten zonder structurele aanpak.
25% van de AI-initiatieven levert het verwachte rendement op. De 75% die dat niet doet, heeft vrijwel altijd hetzelfde probleem: geen heldere architectuurkeuzes, geen bewuste modelstrategie, geen geheugenstrategie, geen eigenaarschap na de pilot.
Begin klein. Bouw diep. Maak de drie keuzes bewust. En meet wat er werkelijk telt: niet hoe imponerend de demo is, maar hoeveel beter het systeem is geworden in de afgelopen negentig dagen.
Dat is AI als versneller.
Over deze serie
Deze serie was een poging om eerlijk te zijn over wat AI wél en niet is — en over de architectuurkeuzes die bepalen aan welke kant van dat verschil jij uitkomt.
De zeven posts in vogelvlucht:
- De meeste organisaties bouwen betere RPA — het fundamentele onderscheid tussen automatisering en versnelling
- Het gefragmenteerde landschap als ontwerpprobleem — hoe je architectuurkeuzes maakt in een chaotisch ecosysteem
- Pijler 1: Model Kwaliteit — het juiste model voor de juiste taak, met routing in plaats van één-voor-alles
- Pijler 2: Harness Sterkte — de control plane die een model betrouwbaar maakt in productie
- Pijler 3: Persistent Memory — het organisatorische geheugen dat AI cumulatief maakt
- De drie pijlers in samenhang — het vliegwiel dat sneller wordt naarmate het langer loopt
- Van framework naar eerste stap — een eerlijk stappenplan om te beginnen
Vragen, reacties of een ander perspectief? Reageer hieronder. Ik lees alles.