Waarom AI-projecten tussen demo en productie stranden

Verwarring rond enterprise-AI-integratie is inmiddels eerder regel dan uitzondering. Bestuurders ontwikkelen hoge verwachtingen, een technisch team bouwt binnen enkele weken een indrukwekkende demo en de eerste gebruikers zien direct potentieel. Zodra het project richting productie gaat, verandert het beeld: kosten lopen op, latency wordt zichtbaar, securityvragen ontstaan, retrievalkwaliteit blijkt wisselend en een architectuur die voor enkele developers prima werkte, gedraagt zich anders zodra honderden medewerkers ermee werken.

Ook onderzoeks- en marktdata laten dit patroon zien. Gartner rapporteert dat gemiddeld slechts 41% van de generative-AI-prototypes uit zijn enterprise-onderzoek daadwerkelijk productie bereikte.[1] In latere analyses noemt Gartner slechte datakwaliteit, onvoldoende risicobeheersing, oplopende kosten en onduidelijke business value als belangrijke redenen waarom GenAI-projecten na de proof-of-concept worden stopgezet.[2] McKinsey beschrijft op basis van werk met meer dan 150 bedrijven vergelijkbare barrières: compliance-frictie, herwerk, risico’s en cost overruns blokkeren de overgang van prototype naar schaal.[3]

Vaak is het model zelf niet het grootste probleem. Het systeem rondom het model is niet voor productie ontworpen.

Een demo bewijst dat iets kan werken; productie moet bewijzen dat het blijft werken

In veel organisaties begint AI bottom-up. Early-adopter developers combineren documentatie, voorbeeldprojecten, video’s en AI-assisted coding en bouwen snel een werkende MVP. Dat is op zichzelf gezond. Het probleem ontstaat wanneer de demo-architectuur zonder fundamentele herbeoordeling de productie-architectuur wordt.

Voor een demo is “werkt het?” soms voldoende. Voor productie moet je ook weten hoeveel concurrent users het systeem aankan, wat een succesvolle taak werkelijk kost, welke gebruiker welke bron mag zien, hoe retrievalfouten worden gemeten, hoe indexversies worden beheerd, wat er gebeurt na een embedding-update en welke p95/p99-latency acceptabel is.

NIST behandelt generative AI daarom als een lifecycle-vraagstuk waarin organisaties risico’s moeten govern, map, measure en manage.[4]

Bij RAG is de vector database slechts één keuze

RAG is logisch wanneer een enterprise-AI-systeem met interne kennis moet werken. De oorspronkelijke RAG-publicatie beschrijft het concept als de combinatie van parametrische modelkennis en externe, niet-parametrische kennis die tijdens generatie wordt opgehaald.[5]

Maar “documenten embedden en in een vector database zetten” is nog geen production-RAG-architectuur. Teams moeten beslissen hoe documenten worden geparsed, hoe chunks worden gevormd, of retrieval dense, sparse of hybrid is, hoe metadatafilters en tenant isolation worden afgedwongen, of reranking nodig is, welk embeddingmodel past, hoe indexen worden geversioned en hoe retrievalkwaliteit wordt geëvalueerd.

Recente RAG-surveys onderscheiden pre-retrieval, retrieval, post-retrieval en generation juist omdat de uiteindelijke kwaliteit uit de interactie tussen al deze lagen ontstaat.[6]

“Het model stelde deze architectuur voor” is geen architectuurbesluit

Vraag een general-purpose model hoe je document-Q&A bouwt en je krijgt vaak een bruikbaar standaardrecept: parse, chunk, embed, sla op in een vector database, retrieve relevante stukken en geef die aan een LLM. Dat recept is een prima startpunt. Het bewijst niet dat het optimaal is voor jouw organisatie.

Bij een hosted embedding API stopt de pipeline niet na document processing. Na parsing en chunking worden de tekstfragmenten via afzonderlijke API-calls naar een embeddingservice gestuurd en in vectoren omgezet. Dit is een aparte betaalde stap naast de latere LLM-calls van de agent- of generation-laag: embeddingproviders kunnen het aantal embedded tokens afzonderlijk factureren. OpenAI prijst embeddingmodellen op basis van inputtokens.[7] Cohere beschrijft embeddingkosten op basis van het aantal embedded tokens.[8] Daardoor kan de ingestion pipeline al embeddingkosten veroorzaken voordat een gebruiker de eerste production-query uitvoert. Op grotere schaal beïnvloedt de keuze tussen hosted API, lokale embeddings, batch inference en incremental indexing de totale kosten direct.

Engineering betekent hier niet de populairste tool kiezen, maar kwaliteit, latency, throughput, datasensitiviteit, operationele complexiteit en total cost of ownership tegen elkaar afwegen.

De dure anti-pattern: elke tussenbeslissing door een LLM laten nemen

Veel vermijdbare AI-kosten ontstaan in orchestration, niet in de prijs van één modelcall.

Een veelvoorkomende pipeline stuurt hetzelfde gebruikersverzoek eerst naar een LLM voor intent detection, vervolgens naar een tweede call voor schema-selectie, daarna naar query rewriting, vervolgens naar summarization van retrievalresultaten en pas daarna naar de uiteindelijke agent. Eén gebruikersvraag wordt ongemerkt vier of vijf generaties.

Sommige systemen hebben zulke stappen echt nodig. Maar niet elke beslissing verdient een LLM-call. Als intentcategorieën, tool-contracten, datastructuren en beslisgrenzen in de hoofdprompt kunnen worden vastgelegd—of deterministisch in code kunnen worden afgehandeld—voegen extra generation calls vooral duplicatie toe.

Het kosteneffect van deze keten is direct. Elke LLM-invoke verwerkt zijn eigen input- en outputtokens en wordt als een afzonderlijke inference-call gefactureerd.[9] Wanneer één gebruikersverzoek bijvoorbeeld drie vergelijkbare calls activeert—intent detection, schema-selectie en het uiteindelijke antwoord—kan de generation-cost ongeveer drie keer zo hoog worden als bij een ontwerp met één invoke. Grotere contexten of langere outputs kunnen dat verschil verder vergroten. Daarnaast voegt iedere invoke een extra network round trip toe, verhoogt deze de tail latency en verkleint deze de concurrency-headroom. Onderzoek naar LLM-serving laat zien hoe belangrijk batching en memory management voor throughput zijn. De PagedAttention-publicatie achter vLLM rapporteerde 2–4× hogere throughput bij vergelijkbare latency door efficiënter KV-cachebeheer.[10] De omgekeerde les is praktisch: onnodige modelcalls verbruiken direct productiecapaciteit.

Waarom kosten in een demo nauwelijks zichtbaar zijn

Een dure architectuur kan goedkoop lijken wanneer één developer dertig queries per dag uitvoert. De economics veranderen zodra honderden medewerkers het systeem gebruiken, lange contexten steeds opnieuw worden meegestuurd en elke vraag meerdere modelcalls triggert.

Daarom moet AI-cost worden gemeten als cost per successful task, niet alleen als maandelijkse API-factuur. Een goedkoop antwoord dat drie retries vereist kan duurder zijn dan een sterker model dat de taak in één keer correct uitvoert. Slechte retrieval kan bovendien lage tokenkosten combineren met hoge menselijke verificatiekosten.

Ook productivity-onderzoek laat zien dat context bepalend is. In een studie onder 5.179 customer-supportmedewerkers vonden Brynjolfsson, Li en Raymond gemiddeld 14% productiviteitswinst met generative-AI-ondersteuning en 34% bij minder ervaren medewerkers, terwijl de winst bij zeer ervaren medewerkers beperkt was.[11] Er bestaat dus geen universeel percentage voor “AI-efficiency”.

Het andere architectuurprobleem: verwachtingen

Narratieven rond AGI, reasoning en autonomous agents kunnen AI in de hoofden van besluitvormers veranderen van een probabilistisch inference-systeem in een algemene superkracht. Een gecontroleerde demo versterkt dat beeld, omdat demo’s meestal werken met geselecteerde data, bekende prompts en beperkte gebruikersscenario’s.

Productie bestaat juist uit edge cases: onvolledige vragen, conflicterende bronnen, veranderende rechten, tool-timeouts, prompt-injectionpogingen en onverwachte workloads. Een systeem dat “95% goed” lijkt, kan onbruikbaar zijn als de resterende 5% precies in een kritisch proces valt.

Daarom moeten C-level verwachtingen vóór implementatie worden afgestemd op de werkelijke technische mogelijkheden, de eigen data en processen van het bedrijf en het betrouwbaarheidsniveau dat economisch haalbaar is. NIST’s nadruk op context mapping en measurement biedt hiervoor een bruikbaar kader.[12]

Echte AI-engineering begint bij het eerste klantgesprek

Een goede AI engineer of architect verlaat een discoverygesprek niet alleen met een featurelijst. De taak is om het verschil tussen verwachtingen en technische/economische realiteit zichtbaar te maken.

Minimaal moeten het businessprobleem, de succesmetric, data readiness, de kosten van een fout antwoord, de minimaal noodzakelijke architectuur, scaling economics en expliciete criteria voor de overgang van pilot naar productie worden vastgesteld.

Doe een haalbaarheidsstudie vóór implementatie

De duurste mislukking is niet dat een AI-project faalt. De duurste mislukking is dat je pas maanden later ontdekt dat het project nooit economisch of operationeel haalbaar was.

Een degelijke haalbaarheidsstudie beoordeelt minimaal vier lagen:

• Value feasibility: Is het probleem waardevol genoeg en is succes meetbaar?
• Data feasibility: Is de benodigde data toegankelijk, actueel, kwalitatief en correct geautoriseerd?
• Technical feasibility: Zijn accuracy, latency, throughput en integratie-eisen realistisch haalbaar?
• Economic feasibility: Zijn inference-, retrieval-, storage-, observability- en human-oversightkosten bij de beoogde schaal acceptabel?

In gereguleerde of high-impact omgevingen moet governance- en compliance feasibility daar expliciet bij.

Gartner’s bevindingen ondersteunen precies dit beeld: pilots stranden vaak niet op modelbenchmarks, maar op data, risico, kosten en onduidelijke business value.[13]

Conclusie: ontwerp het systeem voordat je het model kiest

Enterprise-AI-projecten stranden meestal niet omdat het model niet intelligent genoeg is. Ze stranden omdat het verkeerde probleem is gekozen, een demo-architectuur naar productie is gepromoveerd, onnodige LLM-calls kosten en latency vermenigvuldigen, retrieval en authorization pas laat worden ontworpen of managementverwachtingen nooit zijn vertaald naar een meetbare business case.

Een goede demo zegt: dit is mogelijk.

Een goede haalbaarheidsstudie beantwoordt de moeilijkere vragen: Moeten we dit bouwen? Wat is de kleinste architectuur die werkt? Wat kost het op schaal? Hoe weten we dat het succesvol is?

Daar begint production-grade AI-engineering.

Bronnen

1. Gartner, AI Maturity Matters: Proportion of AI and GenAI Prototypes Making It Into Production (2025). Bron
2. Gartner, Why 50% of GenAI Projects Fail — And How to Beat the Odds (2026). Bron
3. McKinsey, Overcoming two issues that are sinking gen AI programs (2025). Bron
4. Autio et al., NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (2024). Bron
5. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020. Bron
6. Huang & Huang, A Survey on Retrieval-Augmented Text Generation for Large Language Models (2024). Bron
7. OpenAI, text-embedding-3-small model documentation. Bron
8. Cohere, How does Cohere pricing work? Bron
9. OpenAI, GPT-5.4 model documentation. Bron
10. Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (2023). Bron
11. Brynjolfsson, Li & Raymond, Generative AI at Work, NBER Working Paper 31161; gepubliceerd in QJE (2025). Bron
12. NIST, AI Measurement and Evaluation. Bron
13. Gartner, Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025 (2024). Bron