Van AI Proof of Concept naar AI in Productie

Tussen een werkende proof of concept en een productiesysteem verandert het model nauwelijks. Wat verandert is alles eromheen: uitzonderingsafhandeling, een menselijke controlestap, een testset met een acceptatienorm, monitoring, toegangsbeheer en logging, een terugvalscenario, een benoemde eigenaar met tijd, en een beheerafspraak met een bekende prijs. Die ring is het werk, en daar gaat het budget heen.

Teams worden hier stelselmatig door verrast, omdat een PoC een andere vraag beantwoordt dan productie. Een PoC vraagt of het model het juiste antwoord kan geven. Productie vraagt of het omliggende systeem het verkeerde antwoord veilig kan afhandelen, op volume, op een dinsdag, terwijl degene die het bouwde op vakantie is.

Dat gat is inmiddels het bepalende probleem in bedrijfs-AI. Deloitte ondervroeg ruim drieduizend leidinggevenden in vierentwintig landen voor het State of AI in the Enterprise-rapport 2026 en vond dat drieentwintig procent nu minstens matig met agentic AI werkt terwijl vierenzeventig procent dat binnen twee jaar verwacht, en dat slechts eenentwintig procent een volwassen governancemodel voor die agents heeft. De ambitie loopt fors voor op het vermogen om het te beheren, en precies die ruimte gaat dit artikel over.

Waarom groeit een proof of concept niet vanzelf uit tot productie?

Omdat de twee op tegengestelde dingen zijn geoptimaliseerd. Een PoC is gebouwd om snel een vraag te beantwoorden, dus draait hij op voorbeelddata, wordt hij met de hand aangeroepen, leeft hij in een demo-omgeving en hangt hij af van degene die hem maakte. Elk van die keuzes is op dat moment juist, en elk ervan moet eruit voordat iets echts erop gaat leunen.

Daar lopen de meeste projecten stuk. RAND sprak vijfenzestig ervaren datascientists en engineers voor het onderzoek naar de oorzaken waarom AI-projecten mislukken en vond dat ruim tachtig procent faalt, ongeveer twee keer zo vaak als vergelijkbare IT-projecten, met implementatie-infrastructuur die pas achteraf aandacht krijgt als een van de hoofdoorzaken. Gartner verwacht dat ruim veertig procent van de agentic AI-projecten voor eind 2027 wordt stopgezet, met oplopende kosten als eerste reden. Beide wijzen naar dezelfde plek: de ring om het model heen.

De tweede reden is dat de uitzonderingen niet in de steekproef zaten. Een PoC wordt doorgaans getest op de gevallen die iemand makkelijk kon verzamelen, en dat scheeft naar de gewone. Productieverkeer bevat het document met twee facturen in één PDF, de order die zonder referentienummer binnenkwam, het record waarin een altijd gevuld veld leeg is. In ons eigen documentwerk is het patroon steeds hetzelfde: de hoofdroute is snel gebouwd, en het laatste stuk nauwkeurigheid komt volledig uit het afhandelen van de lastige gevallen.

Een recent voorbeeld uit onze eigen praktijk maakt de vorm ervan concreet. Bij een project rond het automatisch verwerken van inkoopfacturen hebben we een heel jaar aan facturen als benchmark gedraaid, ongeveer zevenduizend stuks, en kwamen we uit op achtentachtig procent volledig geautomatiseerde verwerking, waarbij facturen zonder annotatie in drieënnegentig en een half procent van de gevallen op de juiste grootboekrekening werden geboekt op basis van boekhistorie. Dat zijn goede cijfers, en het systeem stond nog steeds niet in productie, want op dat moment was er nog niets teruggeschreven naar het financiële systeem. Nauwkeurigheid was nooit de beperking. Het wegschrijven, de controlestap en de rechten waren dat wel.

Wat komt er precies bij?

Acht dingen, en het model zit er niet bij.

1. Uitzonderingsafhandeling staat vooraan omdat het de grootste post is. Bepaal wat er gebeurt bij lage zekerheid, bij een ontbrekend verplicht veld, bij een bovenliggend systeem dat niet bereikbaar is. In de meeste bedrijfsprocessen is deze logica omvangrijker dan het AI-onderdeel, en het is wat een systeem dat mensen vertrouwen onderscheidt van een systeem waar ze achteraan controleren.
2. Een menselijke controlestap heeft een plek en een persoon nodig, geen principe. Waar in de stroom ziet de mens de uitkomst, wat mag hij aanpassen, en wat gebeurt er met zijn correctie? Een correctie die verdwijnt is een gemiste kans, want dezelfde herhaalde correcties zijn de goedkoopste trainingsdata die je ooit krijgt.
3. Een testset met een acceptatienorm maakt van “het lijkt te werken” een getal dat je kunt verdedigen. Verzamel echte gevallen met bekende juiste antwoorden, inclusief de lastige, en leg de drempel vast voordat je meet in plaats van erna.
4. Monitoring en alerting beantwoordt een vraag die niemand stelt tot het ertoe doet: hoe zou je merken dat dit niet meer werkt? Stil falen is de karakteristieke faalvorm van AI-systemen, omdat ze zelfverzekerde uitkomsten blijven produceren nadat de invoer onder hen is veranderd.
5. Toegangsbeheer en logging gaat over welke accounts het systeem gebruikt, wat het mag lezen en schrijven, en welke vastlegging er is van wat het gedaan heeft. Hier landen ook de wettelijke verplichtingen, dus het loont om aan te sluiten op de risicoklasse die tijdens de voorbereiding is vastgesteld in plaats van het achteraf in te bouwen.
6. Een terugvalscenario is de handmatige route die mensen nemen als het systeem eruit ligt. Heeft niemand die beschreven, dan is de terugval improvisatie, en improviseren tijdens een storing is hoe data verloren gaat.
7. Een eigenaar met tijd is de voorwaarde die het vaakst wordt aangenomen in plaats van geregeld. Iemand moet na livegang beslissen over wijzigingen, uitzonderingen en prioriteiten, en als dat niemands taak is wordt het die van de ontwikkelaar, en zo komen teams ertoe dat ze niets nieuws meer kunnen beginnen.
8. Een beheerafspraak met een bekende prijs maakt de doorlopende verplichting expliciet. Wat valt eronder, welke reactietijd geldt, en wat kost het per maand. Zonder die afspraak gebeurt onderhoud informeel, tot het stilletjes helemaal niet meer gebeurt.

Hoe weet je wanneer je echt klaar bent?

Wanneer het proces dat je vervangt uit kan. Die lat ligt bewust hoger dan “het systeem werkt”, en het is de enige die voorkomt dat een nieuw systeem eindeloos naast de oude werkwijze blijft draaien, wat duurder is dan beide opties afzonderlijk.

Het maakt prioriteren bovendien eenvoudig, omdat het een wensenlijst omzet in vier geordende bakken. Bij het factuurproject hierboven hebben we de gevraagde functies precies zo ingedeeld: wat er al stond, wat er in deze fase nodig was, wat een kwartaal kon wachten, en wat we afraadden om te bouwen. Van de functies in de huidige fase hebben we gemarkeerd welke specifiek het uitzetten van het oude pakket blokkeerden, en die werden de definitie van klaar. De drie die we afraadden, waaronder het splitsen van meerdere facturen uit één PDF, waren serieuze verzoeken die meer zouden kosten dan het handwerk dat ze vervingen.

Die laatste categorie telt zwaarder dan hij klinkt. Nee zeggen tegen een functie die de klant heeft gevraagd is ongemakkelijk, en het is vaak het verschil tussen dit kwartaal in productie komen en volgend jaar.

Wat kost draaiende houden?

Drie posten, en organisaties schatten er twee verkeerd in, in tegengestelde richtingen.

• Cloud- en modelverbruik wordt stelselmatig overschat. Bij een recent project had de klant ongeveer tweehonderd euro per maand begroot voor de infrastructuur, terwijl onze engineer op ongeveer zestig uitkwam, omdat de verwerking event-gedreven was in plaats van doorlopend draaiend. Dat verschil is architectonisch en niet onderhandelbaar: een workflow die getriggerd wordt door binnenkomende documenten kost een fractie van een dienst die de hele dag staat te pollen. Het loont om die aanname vroeg te controleren, want opgeblazen beheerkosten hebben business cases gesloopt die eigenlijk gezond waren.
• Onderhoudsuren worden stelselmatig onderschat. Wijzigingen komen er omdat de wereld verandert: een leverancier past een documentindeling aan, een systeem krijgt een upgrade, een regel wijzigt. Een redelijke planningsaanname is een bescheiden aantal uren per maand tegen een normaal engineeringtarief, en dat gesprek voer je eerlijker vóór livegang dan bij de eerste factuur.
• Coördinatie is de post die niemand begroot. Als vuistregel rekenen wij ongeveer tien procent van de ontwikkelinspanning voor projectmanagement, en na livegang geldt iets vergelijkbaars voor de kleinere vraag wie waarover beslist zodra er een patroon in de uitzonderingen zichtbaar wordt.

Welke methode brengt een bouw over de streep?

Korte cycli met de mensen die het systeem gaan gebruiken, in plaats van mijlpaalreviews met de mensen die het hebben goedgekeurd.

Het patroon dat bij ons werkt is een wekelijkse demo gedurende de hele bouw. Bij een klantgerichte assistent die we vorig jaar opleverden, was de vorm een proof of concept van veertig uur gevolgd door tien wekelijkse sprintdemo’s, waarna de assistent live ging in productie op WhatsApp Business. Tien demo’s klinkt als veel overleg en het is aanzienlijk goedkoper dan het alternatief, namelijk in week negen ontdekken dat de toon niet klopt of dat een hele categorie vragen buiten scope viel.

Wekelijks verandert ook wie er komt. Een maandelijkse stuurgroep trekt managers, terwijl een wekelijkse demo de mensen trekt die het werk doen, en zij merken op dat de uitkomst technisch klopt maar op het verkeerde moment in hun dag binnenkomt.

Wat hoort er bij de oplevering te zitten?

Meer dan de meeste contracten benoemen, en juist daarom loont het om het expliciet af te spreken in plaats van aan te nemen.

Broncode, prompts en documentatie zijn de voor de hand liggende onderdelen, en een korte controle vooraf is verstandig zodat wat er aankomt bruikbaar is en niet alleen volledig. Daarnaast vragen drie dingen om een besluit. Of repositoryhistorie en logs meegaan, wat vaak buiten de standaardscope valt en als verrassing komt wanneer niemand ernaar heeft gevraagd. Waar het systeem daarna draait, want een oplossing die als broncode wordt overgedragen verhuist naar de eigen infrastructuur van de klant en hosting wordt daarmee een aparte vraag. En wie de inloggegevens beheert, want een applicatie waar niemand in kan is niet echt overgedragen.

De toets voor een volledige oplevering is simpel: kan een vakbekwame engineer die dit systeem nooit heeft gezien het uitrollen, draaien en een veelvoorkomende storing verhelpen met alleen wat jij hebt aangeleverd? Als het eerlijke antwoord een telefoontje naar de oorspronkelijke ontwikkelaar vereist, is de oplevering niet af.

De kortste bruikbare samenvatting

Een proof of concept beantwoordt of iets mogelijk is, en die vraag is meestal binnen een paar weken beslecht. Alles daarna gaat over het antwoord zo betrouwbaar maken dat een bedrijfsproces erop kan leunen, en dat is gewoon engineeringwerk in plaats van AI-werk. Daar zit het merendeel van de inspanning en vrijwel alle verrassingen.

Begroot daarnaar. De PoC behandelen als het grootste deel van het project is de meest betrouwbare manier om in de groep te belanden die nooit oplevert.

Veelgestelde vragen (FAQ) over AI naar productie brengen