Van proof of concept naar productie:
wat het kost en wie het beheert

De pilot is het makkelijke deel. Er is budget, er is enthousiasme, en na een paar weken staat er iets dat werkt op een scherm. Dan komt de vraag die zelden vooraf is beantwoord: wie zet dit in productie, wie houdt het draaiende en wat kost dat elke maand? Daar sneuvelen de meeste AI-projecten. Niet op de techniek, maar op eigenaarschap en beheer.

Een werkende demo is iets anders dan een werkend systeem

Een demo hoeft één keer te werken, op een gekozen voorbeeld, met de bouwer in de kamer. Een productiesysteem moet elke dag werken, voor mensen die er niet bij waren, op data die niet is opgeschoond. Dat verschil zit in vijf dingen die in een pilot vrijwel altijd ontbreken.

Rechten en toegang

In een proof of concept draai je meestal op één account met leesrechten op testdata. In productie moet het systeem weten wie wat mag zien. Leest je AI-assistent uit een gedeelde documentenmap, dan krijgt een medewerker via de chat opeens antwoorden uit dossiers waar hij in die map nooit bij kon. De AI heeft niets gelekt, jouw rechtenstructuur was alleen nooit ingericht op een systeem dat alles tegelijk leest.

Foutafhandeling

De koppeling ligt er even uit, de leverancier geeft een time-out, het document blijkt een scan. In een demo kies jij het voorbeeld, in productie kiest de werkelijkheid. Elk van die gevallen heeft een afgesproken uitkomst nodig: opnieuw proberen, doorzetten naar een mens, of stoppen met een duidelijke melding. Wat je niet wilt is stil falen.

Monitoring

Bij klassieke software merk je een storing omdat er niets gebeurt. Bij AI merk je een storing niet, want er komt gewoon een antwoord, alleen een slechter antwoord. Je hebt dus iets nodig dat kwaliteit meet en niet alleen beschikbaarheid: hoe vaak een mens ingrijpt, hoe vaak output ongewijzigd wordt overgenomen, hoeveel gevallen naar de uitzonderingsbak gaan.

Versiebeheer

Prompts veranderen, koppelingen veranderen, en modellen worden door je leverancier vervangen, ook als jij niets doet. Leg vast welke versie op welke datum draaide. Anders kun je bij een klacht van drie maanden geleden niet reconstrueren waarom het systeem dat antwoord gaf, en dat is precies wat een auditor of een boze klant je vraagt.

Wat er gebeurt als het model iets raars zegt

Niet of, maar wanneer. Spreek vooraf af wie dat als eerste ziet, waar het gemeld wordt, wie mag besluiten de functie uit te zetten en wat er dan tegen gebruikers wordt gezegd. Een systeem zonder uit-knop en zonder meldroute raakt bij het eerste incident stilletjes uit de gratie.

Wie wordt de eigenaar als het live staat

Een systeem zonder eigenaar verdwijnt. Niet met een knal, maar door verwaarlozing: een koppeling breekt, niemand voelt zich verantwoordelijk, mensen werken eromheen en na een half jaar gebruikt niemand het meer.

Eigenaarschap valt uiteen in drie rollen, die bij één of bij drie mensen kunnen liggen. De proceseigenaar bepaalt wat goed genoeg is en beslist over wijzigingen, en die hoort bij de afdeling die het werk doet, niet bij IT. De functioneel beheerder volgt hoe het draait, verzamelt meldingen, onderhoudt prompts en uitzonderingen en praat nieuwe medewerkers bij. De technisch beheerder zorgt voor koppelingen, sleutels, updates en toegang.

De reële kost zit in die middelste rol en die wordt bijna altijd vergeten. Reken op structurele uren per week, niet op incidenteel opruimwerk. Zet er een naam bij en uren in de weekplanning, anders is de rest van dit artikel theorie.

Wat er structureel bij komt naast de bouwkosten

De bouwkosten zijn eenmalig en zichtbaar: die staan in een offerte. De rest is doorlopend en staat nergens, en juist die post bepaalt of je over twee jaar nog blij bent met het systeem.

Twee dingen vallen op. Verbruik en licenties schalen mee met succes: hoe beter het werkt, hoe meer het kost. Dat is gezond, zolang je de opbrengst in dezelfde eenheid meet. En de grootste post zit vaak niet in een factuur maar in uren van je eigen mensen, en die worden zelden opgeteld. Het doorontwikkelstuk vangen wij daarom in een vast maandbedrag: een implementatietraject loopt via een vaste projectprijs op scope, of via een retainer van €1.500, €3.000 of €6.000 per maand. Alle tarieven staan op de prijzenpagina.

Vraag bij elke pilot niet alleen wat het bouwen kost, maar wat het draaien kost in maand dertien. Kan niemand die vraag beantwoorden, dan ben je nog niet klaar om te bouwen.

Vier vragen die je vóór de PoC beantwoordt

1. Wat is de meetbare uitkomst, en wat is het nulpunt? Niet “sneller offertes maken”, maar: dit proces gebeurt zoveel keer per week, kost zoveel minuten per keer en gaat zo vaak mis. Zonder nulmeting wordt de evaluatie een discussie op gevoel.
2. Wie is straks de eigenaar, en heeft die persoon er tijd voor? Vraag het bij naam en vraag om uren. “Dat pakken we samen op” is geen antwoord.
3. Wat mag deze AI zien, en wat gebeurt er met wat eruit komt? Welke bronnen, welke gegevens er nooit in mogen, wie de output controleert en waar de logging landt. Bij beslissingen die mensen direct raken, zoals werving of beoordeling, komen daar eisen uit de EU AI Act bovenop.
4. Wat is de drempel voor doorgaan, en wie beslist? Spreek vooraf af welk resultaat genoeg is om door te bouwen en welk resultaat betekent dat je stopt. Achteraf lukt dat niet meer.

Wij doen dit in de gratis PoC-check van dertig minuten, vóór er een euro wordt uitgegeven. Soms is de uitkomst dat de vraag niet in een PoC past. Prima uitkomst, en veel goedkoper dan het na drie weken ontdekken.

Wanneer je beter kunt stoppen dan doorgaan

Doorgaan is de standaardkeuze, want er is al geld en gezicht geïnvesteerd. Toch zijn er vier situaties waarin stoppen het goedkoopste besluit is.

• De tijdwinst valt weg tegen de controletijd. Moet iemand elke uitkomst volledig nalezen, dan heb je werk verplaatst en niet weggehaald.
• Het proces zelf deugt niet. Een slecht proces automatiseren levert een slecht proces op dat sneller gaat.
• Niemand wil de eigenaar zijn. Geen naam, geen uren, geen systeem.
• Het volume is te klein. Een proces dat tien keer per jaar voorkomt verdient het beheer nooit terug.

Stoppen is geen mislukking als je er iets aan overhoudt: je weet nu wat je data waard is, welke uitzonderingen er echt zijn en waar het volgende proces wel kansrijk is. Daarom is een PoC met een vaste prijs en een vaste einddatum een verstandiger instrument dan een pilot die vanzelf doorloopt. Zo’n pilot stopt namelijk nooit uit zichzelf, die verdampt.

Conclusie

De overgang van pilot naar productie is geen technische stap maar een organisatorische. Je koopt er niet alleen bouwwerk bij, maar rechten, foutafhandeling, monitoring, versiebeheer, een eigenaar met uren en een doorlopende rekening voor verbruik, licenties en doorontwikkeling. Beantwoord de vier vragen vóór je begint, spreek de stopdrempel af terwijl je nog nuchter bent en kies een pilotvorm met een vaste prijs en een vaste einddatum. Dan is doorgaan een besluit en niet iets wat vanzelf gebeurt.