Ik zie dit regelmatig en het ligt zelden aan het model. Een pilot beantwoordt één vraag: kan het model deze taak uitvoeren? Productie roept verschillende andere vragen op, en de meeste daarvan stonden nooit op de agenda van de pilot.
Een pilot draait één keer. Productie draait iedere dag.
In een demo krijgt het model een handvol zorgvuldig geselecteerde cases en doet het daar goed op. In productie krijgt het duizenden cases, inclusief de vreemde gevallen. En morgen krijgt het die opnieuw, met een iets andere prompt, iets andere data en mogelijk een andere modelversie.
Taalmodellen zijn niet deterministisch. Dezelfde vraag kan bij een tweede uitvoering een ander antwoord opleveren. De relevante vraag verschuift daarom van "kan het dit?" naar "hoe vaak doet het dit goed, over veel uitvoeringen heen?"
Negen van de tien keer goed kan prima zijn voor een conceptmail die een medewerker controleert voordat die wordt verstuurd. Het is niet prima voor een wijziging in een order in je ERP.
Die verschuiving, van één goed antwoord naar een betrouwbare score over meerdere uitvoeringen, verandert wat je moet bouwen.
Begin met de testset
De catalogus van Martin Fowler met patronen voor GenAI-producten begint hier, en juist deze stap wordt in pilots het vaakst overgeslagen. Verzamel voordat je iets gaat tunen een vaste set echte cases met antwoorden waar je het over eens bent. Test iedere verandering tegen die set: een nieuwe prompt, nieuwe data of een nieuwe modelversie.
Zonder zo'n set wordt kwaliteit beoordeeld door mensen die naar resultaten kijken en zeggen: "Dit is goed." Iedere verandering wordt daarmee een gok, en je ontdekt problemen via klachten.
Met een vaste testset wordt een modelupgrade een routinematige controle in plaats van een sprong in het diepe. Dat is belangrijk, omdat providers modelversies volgens hun eigen planning uitfaseren. Het model waarop je pilot draaide, is over een jaar misschien niet meer beschikbaar.
Het opbouwen van zo'n set is saai werk. Het is ook het enige wat al het andere in dit artikel beheersbaar maakt.
Autonomie moet je stap voor stap verdienen
De meeste pilots springen rechtstreeks van demo naar live. Er is een betere route, die Pramod Sadalage en Prem Chandrasekaran goed beschrijven op de site van Martin Fowler: geef het systeem stap voor stap meer autonomie.
- Shadow mode. Het model doet een aanbeveling. Mensen beoordelen die aanbeveling en voeren het werk vervolgens zelf uit.
- Onder toezicht. Het model bereidt de actie voor. Een persoon keurt die goed voordat er iets gebeurt.
- Autonoom met randvoorwaarden. Het model handelt zelfstandig binnen vooraf bepaalde grenzen en met controles die je kunt inzien.
- Volledig autonoom. Het model handelt zelfstandig en mensen controleren steekproefsgewijs.
Elke fase levert het bewijs voor de volgende. En iedere fase is ook een veilige plek om te stoppen. Een feature die blijvend onder toezicht werkt, kan nog steeds enorm veel tijd besparen.
Eén waarschuwing bij de fase waarin een mens goedkeurt. Meet hoe vaak mensen aanpassen wat het model heeft voorbereid. Daalt dat percentage naar nul, dan is het model óf heel goed, óf mensen zijn gestopt met lezen. Alleen regelmatige steekproeven kunnen uitwijzen welke van de twee het is.
LLM-features falen op een andere manier
Gewone software faalt luid en duidelijk: een exception, een timeout, een alert. Een falende LLM-feature geeft een vloeiend, aannemelijk maar fout antwoord, terwijl je monitoring gewoon een 200 OK ziet. Dat vraagt om een ander soort monitoring: steekproeven van outputs, de testset periodiek opnieuw uitvoeren en bijhouden hoe vaak mensen resultaten corrigeren.
Soms faalt een LLM-feature wel degelijk hard, en ook die situaties komen in pilots zelden aan bod. Rate limits, een storing bij de provider, een stap die halverwege een langer proces een timeout krijgt. Bepaal vooraf wat er dan gebeurt.
Val terug op een ander model of een andere provider. Zorg dat langere processen hervat kunnen worden vanaf de stap waar het misging, in plaats van helemaal opnieuw te beginnen. Thoughtworks' Technology Radar waarschuwt inmiddels expliciet voor het negeren hiervan bij agent-workflows. En zorg dat mislukte items ergens terechtkomen waar een medewerker ze kan zien, in plaats van dat ze simpelweg verdwijnen.
Kosten per taak, en een eigenaar
Twintig enthousiaste gebruikers zorgen voor een prettige factuur. Tweeduizend gebruikers, plus een nachtelijke batchjob die iemand heeft toegevoegd omdat het makkelijk was, zorgen voor een heel andere factuur.
Tokenprijzen zeggen weinig. De kosten per afgehandelde case, per document of per antwoord zijn wat een business owner kan afzetten tegen de opbrengst.
En iemand moet eigenaar zijn. Pilots zijn meestal het domein van een enthousiaste voortrekker. Productie heeft een product owner nodig die bepaalt wat "goed genoeg" betekent, en een operationeel team dat weet hoe falen er bij dit type systeem uitziet.
Niets hiervan is exotisch. Het is de productierijpheid die ieder bedrijfskritisch systeem nodig heeft: monitoring, herstel, eigenaarschap en kostenbeheersing. Het verschil is dat de gebruikelijke signalen hier niet afgaan.
Leg de exitcriteria vooraf vast
Een langere pilot gaat het gat niet dichten. Wat wel helpt, is om de exitcriteria vast te leggen voordat de pilot begint:
- het succespercentage op een vaste set echte cases, over meerdere uitvoeringen;
- de kosten per taak bij het verwachte productievolume;
- wat de feature doet wanneer het model traag, niet beschikbaar of fout is;
- met welke fase van autonomie de feature begint en welk bewijs nodig is om naar de volgende fase te gaan;
- wie na livegang eigenaar is.
Kun je die punten niet opschrijven, dan draai je een demo. Dat is prima, zolang iedereen dat weet. Demo's zijn goed in het creëren van enthousiasme en slecht in het nemen van beslissingen.
Een pilot bewijst dat het model het werk kan uitvoeren. Productie bewijst dat de organisatie ermee kan leven.
Weer op de goede weg
Heb je een pilot die al een tijdje "bijna klaar" is, dan is de kloof meestal kleiner dan hij voelt. En het ligt zelden aan het model. Meestal komt het neer op de vragen hierboven, beantwoord met cijfers.
Ik loop ze graag samen met je door, aan de hand van jouw eigen case.
