10 juni 2026

Van AI-demo naar productie

De demo duurde een kwartier. Een prototype dat vragen beantwoordt over interne documenten, gebouwd in een paar middagen. Het management was enthousiast, iemand riep dat dit volgende maand live moest. Drie maanden later draait er nog steeds niets.

Ik zie deze film vaker. Niet omdat de techniek niet werkt, maar omdat een demo en een productiesysteem twee verschillende dingen zijn die toevallig op elkaar lijken. De demo is makkelijk. Productie is waar AI serieus wordt.

Waarom de demo altijd lukt

Een demo draait onder ideale omstandigheden. Er is een persoon die de vragen stelt, en die persoon weet welke vragen goed werken. De documenten zijn vers geselecteerd, de data is schoon, er is geen drukte op het systeem en niemand probeert iets geks. Het model hoeft maar een keer indruk te maken.

Een productiesysteem moet elke dag goed gaan, ook op de dagen dat niemand kijkt. Met gebruikers die vragen stellen waar je nooit aan had gedacht. Met documenten die verouderen, een API die er soms uit ligt, en een collega die het antwoord van de assistent doorstuurt naar een klant zonder het te lezen. Dat is geen techniekprobleem dat je later even oplost. Dat is het eigenlijke product.

Wat er in productie ineens bij komt

Het verschil tussen demo en productie zit niet in het model. Het zit in alles eromheen. Vier dingen die in een demo niet bestaan en in productie ineens je hele agenda bepalen.

Foutafhandeling. Taalmodellen geven soms een fout antwoord, en ze doen dat met dezelfde stellige toon als een goed antwoord. Daarnaast kan de modelprovider traag zijn, plat liggen of je verzoeken weigeren omdat je tegen een limiet aanloopt. In een demo druk je dan op refresh. In productie heb je een plan nodig: wat doet het systeem bij een time-out, wat is het terugvalscenario, en wanneer zegt de assistent eerlijk "dit weet ik niet" in plaats van iets te verzinnen? Een systeem dat netjes kan falen is in de praktijk waardevoller dan een systeem dat meestal briljant is.

Rechten. In de demo ziet iedereen alles, want de bouwer heeft alle documenten in een vector database gezet. In productie is dat een datalek dat op zijn livegang wacht. Als je bedrijfskennis aan AI koppelt via RAG, moet de retrieval de rechten van de gebruiker respecteren. Anders kan een stagiair via de chatbot stukken opvragen die hij in de documentomgeving nooit te zien krijgt. Rechten zijn niet iets dat je achteraf toevoegt, ze bepalen hoe je je hele kennislaag inricht.

Kosten en latency. Een demo kost een paar cent. Een productiesysteem met duizenden vragen per maand heeft een echte rekening, en die rekening beweegt mee met elk extra document in de context en elk groter model dat je kiest. Tegelijk telt snelheid: in een presentatie wacht iedereen geduldig acht seconden op een antwoord, een gebruiker midden in zijn werk niet. In productie ga je dus kiezen. Een kleiner model voor simpele taken, een groter model waar het ertoe doet, antwoorden streamen, slim hergebruiken wat al berekend is. Dat zijn ontwerpkeuzes, geen optimalisaties voor later.

Monitoring en observability. Bij gewone software kijk je of de server draait. Bij AI is dat niet genoeg, want het systeem kan perfect bereikbaar zijn en toch onzin antwoorden. Je wilt per verzoek kunnen terugzien welke vraag er kwam, welke bronnen zijn opgehaald, welk antwoord eruit ging, wat het kostte en of de gebruiker er iets aan had. Zonder die logs ben je blind. Met die logs heb je niet alleen monitoring, maar ook een audit trail, en die ga je nodig hebben zodra iemand vraagt waarom het systeem iets heeft geantwoord.

Een voorbeeld: de gemeente met de brievenassistent

Stel, een gemeente bouwt een assistent die ambtenaren helpt burgervragen te beantwoorden. De pilot is overtuigend: de assistent vindt de juiste regeling en schrijft een nette conceptbrief. Iedereen wil door.

Dan komt productie. In de index blijkt een verouderde versie van een regeling te staan, dus de assistent citeert beleid dat vorig jaar is vervangen. Een ambtenaar stuurt een conceptantwoord door zonder controle, want het leest zo soepel. Niemand kan achteraf terugvinden welke bron de assistent gebruikte. En de kostenrapportage laat zien dat het duurste model ook wordt ingezet voor vragen over openingstijden.

Geen van deze problemen gaat over het taalmodel. Ze gaan over versiebeheer van kennis, over werkafspraken, over logging en over routing. Precies de laag die in de demo onzichtbaar was.

Evaluatie en de mens in de lus

Gewone software test je met vaste testen: zelfde input, zelfde output, groen vinkje. Bij een taalmodel werkt dat niet, want de output varieert en "goed" is geen exacte waarde. Wat wel werkt is een evaluatieset: een lijst echte vragen uit je organisatie met daarbij wat een goed antwoord is. Elke keer dat je iets wijzigt, een nieuw model, een andere prompt, een andere manier van documenten opknippen, draai je die set opnieuw en kijk je of het beter of slechter werd. Zonder evaluatieset is elke wijziging gokken.

En dan de mens in de lus. Dat klinkt als een tijdelijke kruk totdat de AI goed genoeg is, maar ik zie het andersom: het is een ontwerpkeuze die bepaalt of je systeem vertrouwen verdient. Laat de assistent concepten maken die een mens goedkeurt, in plaats van antwoorden die automatisch de deur uit gaan. Bekijk steekproefsgewijs wat het systeem produceert. Geef gebruikers een knop om een slecht antwoord te melden, en doe daar ook echt iets mee. Pas als de cijfers laten zien dat controle weinig meer vangt, kun je per stap loslaten. Dit is ook de reden dat ik bij Ployed zoveel tijd steek in precies dit stuk: niet het model, maar het pad van prototype naar iets dat live mag.

Waarom zoveel pilots stranden

De meeste gestrande AI-pilots die ik tegenkom zijn niet gestrand op modelkwaliteit. Ze stranden op een herkenbaar rijtje:

• De pilot was gebouwd als demo, niet als eerste versie van een systeem. Alles moest daarna opnieuw.
• Niemand was eigenaar. Na het applaus was er geen team dat het systeem moest onderhouden, voeden en verbeteren.
• Succes was nooit gedefinieerd. Zonder meetlat kan een pilot niet slagen, alleen doodbloeden.
• Security, privacy en juridisch schoven pas aan toen het af was, en hadden toen terechte bezwaren die eerder ontwerpkeuzes hadden moeten zijn.
• Het budget dekte de zichtbare twintig procent (de demo) en niet de onzichtbare tachtig procent (rechten, logging, evaluatie, beheer).

Het patroon is steeds hetzelfde: de organisatie kocht een antwoordmachine en kwam erachter dat ze een systeem moesten bouwen.

De checklist voor de stap naar live

Wie van prototype naar productie wil, kan deze vragen langslopen. Kun je ze niet beantwoorden, dan weet je waar het werk zit.

• Wat doet het systeem als het model een fout antwoord geeft, en hoe merk je dat zelf voordat een gebruiker het merkt?
• Wat gebeurt er als de modelprovider traag is of plat ligt? Is er een terugvalroute?
• Wie mag welke data zien, en dwingt het systeem dat af op het moment van ophalen, niet alleen bij de invoer?
• Wat kost een gemiddelde vraag, en wat wordt de rekening bij het echte gebruiksvolume?
• Hoe snel moet een antwoord zijn, gemeten bij echte gebruikers in hun echte werk?
• Log je per verzoek de vraag, de gebruikte bronnen, het antwoord, de kosten en de fouten?
• Is er een evaluatieset met echte vragen die je draait na elke wijziging aan model, prompt of data?
• Waar zit de mens in de lus, en op basis van welke cijfers mag die controle ooit losser?
• Wie is eigenaar van het systeem na livegang, met tijd en budget om het te onderhouden?
• Weet je waar prompts, logs en embeddings worden opgeslagen, en mag dat daar volgens je eigen beleid?

Het onderliggende denkmodel is simpel: de demo is het antwoord, productie is het systeem eromheen. Behandel het model als een snelle maar feilbare collega. Je geeft zo'n collega ook geen toegang tot alles, je laat het werk controleren, en je wilt kunnen terugzien wat er is gebeurd.

Begin bij het systeem, niet bij het model

Een AI-pilot die slaagt, is meestal niet de pilot met het beste model. Het is de pilot die vanaf dag een als systeem is ontworpen: met rechten, logging, evaluatie en een mens op de juiste plek. Dat klinkt als meer werk, en dat is het ook. Maar het is het verschil tussen een demo die applaus krijgt en een systeem waar mensen over een jaar nog dagelijks op leunen.

Dus als je deze week een indrukwekkende demo ziet, stel dan de saaie vraag: wat gebeurt er als dit elke dag moet werken? Het antwoord op die vraag vertelt je of je naar een product kijkt of naar een presentatie.

↘︎ ALLE ARTIKELEN