Een AI-demo werkt altijd. De productierealiteit is een ander verhaal: vuile data, edge cases, stille fouten en koppelingen die falen. De kloof is groter dan iedereen toegeeft, en de meeste projecten stranden er precies op.
Een AI-demo werkt altijd. De invoer is zorgvuldig gekozen, de data is schoon, de gebruiker weet wat hij moet intypen, en als er iets miszit, wordt dat stukje van de demo overgeslagen. Dat is geen fraude, maar selectie. Een demo laat zien wat mogelijk is, niet wat dagelijks werkt.
De kloof daartussen is groter dan bijna iedereen toegeeft, en precies op die kloof stranden de meeste AI-projecten.
De demo als best-case scenario
Een AI-demo is een gecontroleerd best-case scenario: alles is afgestemd op de vijf procent van de gevallen die het systeem perfect aankan. De testdata is handmatig doorgespit, de vuile records zijn eruit gehaald, de vragen zijn gesteld zoals een ideale gebruiker ze stelt, en de koppeling met het bestaande systeem is vereenvoudigd tot een werkend script. Als het antwoord toch niet klopt, haalt de demonstrateur zijn schouders op: "Dat is een edge case."
De toehoorders in de kamer zien iets indrukwekkends en denken: "Dit gaan we inzetten." Wat ze niet zien, is alles wat buiten beeld is gehouden.
De saaie realiteit van productie
De saaie 95% zijn alle situaties die een demo niet toont maar die een productiesysteem dagelijks moet opvangen. Ze bepalen of een AI-oplossing daadwerkelijk waarde levert, of rustig knaagt aan klantrelaties en medewerkervertrouwen. De categorieën zijn herkenbaar voor iedereen die een systeem ooit echt heeft gedraaid:
- Vuile invoer: Gebruikers typen "klantnaam" als "Bedrijf BV NL", laten verplichte velden leeg, of plakken tekst met onverwachte tekens. De zorgvuldig geteste prompt faalt op invoer die niemand had voorzien.
- Edge cases: De creditnota die er structureel anders uitziet dan een factuur. De klant met twee achternamen. De API-respons die een lege string teruggeeft in plaats van een foutcode. Elk systeem heeft ze, en ze breken aannames die in de demo nooit getoetst zijn.
- Latency en timeouts: Het taalmodel antwoordt in 800 milliseconden in de demo. In productie duurt het af en toe twaalf seconden, of geeft het een timeout. Wat doet het systeem dan?
- Integratiefricties: De koppeling met het CRM of boekhoudpakket werkt prima op dinsdag, maar geeft een 503-fout op vrijdagavond. Wie merkt het, en hoe reageert het systeem?
- Stille fouten: De AI geeft een antwoord dat er goed uitziet maar inhoudelijk niet klopt. Er is geen foutmelding. Niemand merkt het, tot een klant een factuur ontvangt met verkeerde gegevens.
- Kwaliteitsdrift: Over weken verandert de output langzaam. Een modelupdate, een gewijzigde systeemprompt, iets in de datalaag. Wie monitort of de kwaliteit gelijk blijft?
Dit is de saaie 95%. Geen AI-demo toont dit. Maar dit bepaalt precies of de investering iets oplevert.
Waarom zoveel projecten stranden na de demo
De aantallen zijn consistent. Uit IDC-onderzoek blijkt dat 88% van de AI-proefprojecten nooit een volwaardige productie-uitrol bereikt: van elke 33 pilots halen er slechts 4 de eindstreep. Gartner voorspelde in juli 2024 dat minimaal 30% van alle generatieve AI-projecten na het proof-of-concept zou worden stopgezet vanwege slechte datakwaliteit en inadequate risicocontroles. In juni 2025 verwachtte Gartner bovendien dat ruim 40% van alle agentic AI-projecten vóór 2027 geannuleerd wordt vanwege escalerende kosten, onduidelijke businesswaarde of onvoldoende risicobeheersing.
De oorzaken zijn ook consistent. Teams kiezen use cases die in een demo overtuigen maar te complex zijn voor stabiele productie. De productiedata is rommelig en onvolledig. De echte koppeling met bestaande systemen is nooit gebouwd. Er is geen monitoring, geen governance, en niemand die verantwoordelijkheid neemt als het misgaat.
Dit zijn geen AI-problemen. Dit zijn softwarebouwproblemen. En betere modellen lossen ze niet op.
Bouw achteruit vanuit productie
De meest effectieve aanpak draait de ontwerpvolgorde om: begin niet bij wat er in de demo goed uitziet, maar bij wat er in productie mis kan gaan. Dat is geen pessimisme, maar engineering.
Dit zijn de vragen die ik standaard stel voordat een eerste regel code wordt geschreven:
- Invoer: Wat doet het systeem als de gebruikersinput onvolledig, verkeerd gespeld of structureel anders is dan verwacht?
- Fouten: Wat als het AI-model een verkeerd antwoord geeft? Is er een confidence-drempel, een menselijke check, of een fallback naar een vaste waarde?
- Kwaliteit: Hoe weet je als de output-kwaliteit over tijd daalt? Welke metric wordt gemonitord, en wie krijgt een alert?
- Uitval: Wat gebeurt er als een externe API of koppeling uitvalt? Retry, fallback, of hard fail met een duidelijke foutmelding?
- Slechtst denkbare dag: Hoe integreert dit met het bestaande systeem op een drukke vrijdagmiddag, met trage koppelingen en mislukte API-verzoeken?
Wie deze vragen pas stelt nadat de demo indruk heeft gemaakt, bouwt de saaie 95% als afterthought. Dat wordt duur en traag. Wie ze vooraf stelt, bouwt iets dat echt werkt.
Dit geldt ook voor de datalaag. De kwaliteit van je AI-uitvoer staat of valt met je datafundament: het doel is niet perfecte data, maar een systeem dat eerlijk en robuust omgaat met de werkelijkheid van je data. Wachten op perfect is geen strategie.
Het tegenargument: worden de modellen niet steeds beter?
Dat klopt. GPT-5, Fable 5, Gemini 2.5: de modellen worden jaar op jaar sterker, betrouwbaarder en goedkoper. Hallucinaties nemen af. Reasoning wordt solider. Een deel van de productie-uitdagingen lost hierdoor vanzelf op.
Maar het model is nooit het knelpunt.
De 88% projecten die stranden, stranden niet omdat het model te slecht is. Ze stranden omdat de data niet klaar is, de integraties ontbreken, de monitoring er nooit is gekomen, en niemand weet wat er moet gebeuren als het misgaat. Die problemen los je op met engineering, niet met een nieuw model.
Hetzelfde principe geldt voor softwarekeuzes: wie zijn broncode en data niet zelf beheert, verliest controle zodra hij iets wil veranderen. Het instrument is ondergeschikt aan de architectuur eromheen. Bij AI is dat precies zo. Het model is het instrument. De architectuur bepaalt of je er iets mee bereikt.
Het is ook waarom ik sceptisch ben als organisaties beweren dat ze "even AI gaan implementeren". "Even AI implementeren" lost bijna nooit het echte probleem op: het vraagstuk begint pas na de demo.
Wat dit in de praktijk betekent
Als ik een AI-oplossing bouw, staat de demo niet centraal. De demo is een bijproduct van een systeem dat in productie werkt.
Dat betekent concreet: data-validatie is ingebouwd, fallbacks zijn gedefinieerd voordat er een feature bestaat, logging zit er vanaf dag één in zodat kwaliteit meetbaar blijft, en koppelingen degraden graceful bij storingen. Of het nu gaat om een RAG-chatbot die eerlijk omgaat met de rommelige werkelijkheid van jouw eigen documenten en kennisbank, of een AI-agent die taken uitvoert in bestaande systemen en processen: de saaie 95% zit er altijd in.
Dat is ook waarom ik de voorkeur geef aan maatwerk en self-hosted bouwen boven het stapelen van kant-en-klare SaaS-tools. De saaie 95% is precies het deel dat je bij standaardproducten nooit volledig in handen hebt.
De saaie 95% is niet het saaiste deel van het werk. Het is het enige deel dat telt.
