Evaluatie van AI-agents: hoe weet je of het klaar is voor productie

De meeste teams ontdekken pas op de dag van de lancering of een AI-agent klaar is voor productie, niet daarvoor. Hij doorloopt het demoscenario perfect, iedereen in de kamer knikt tevreden, en drie weken later betaalt hij de verkeerde klant terug, raakt hij verstrikt in een lus bij een tool-aanroep, of vertelt hij iemand dat een claim is goedgekeurd terwijl dat niet zo is. Het gat tussen een werkende demo en een productieklare agent is groot en wordt zelden zichtbaar voordat er iets misgaat bij een echte klant.

Dit artikel is bedoeld voor degene die de knoop moet doorhakken. Niet voor de engineer die een evaluatiekader kiest, maar voor de oprichter, CTO of operationeel leider die de opdracht voor de agent gaf – of deze nu intern of door een externe partner is gebouwd – en nu moet beslissen of het veilig is om hem aan te zetten. Als dit niet jouw rol is, biedt dit nog steeds nuttige achtergrondinformatie, maar het is geschreven vanuit het perspectief van de beslisser.

In dit artikel leer je wat de evaluatie van een AI-agent werkelijk inhoudt, waarom de meeste agents falen om redenen die niets met het onderliggende model te maken hebben, de vijf dimensies die je moet controleren voordat je live gaat, hoe je een testset bouwt die echte problemen opspoort in plaats van alleen een demo goed te keuren, hoe een gefaseerde uitrol er in de praktijk uitziet, en de precieze vragen die je aan een AI-leverancier of bureau moet stellen voordat je de oplevering accepteert.

‍

Belangrijkste inzichten

• De evaluatie van een AI-agent is het gestructureerde proces waarbij het gedrag van een agent wordt gecontroleerd over volledige taaktrajecten heen – niet alleen de uiteindelijke antwoorden – zowel voor als na de livegang.

• Volgens het 'State of Agent Engineering'-rapport van 2026 van LangChain heeft 57 procent van de organisaties al agents in productie, en is kwaliteit de grootste barrière voor implementatie, genoemd door 32 procent van de respondenten.

• Uit een onderzoek uit 2026 onder 650 bedrijfsleiders bleek dat 78 procent van de bedrijven AI-agentpilots heeft lopen, maar dat minder dan 15 procent de productieschaal heeft bereikt. Het probleem is evaluatie, niet ambitie.

• De meeste productiefouten bij AI zijn terug te voeren op datakwaliteit, ontbrekende context of zwak beheer, niet op beperkingen van het model. De oplossing is dus zelden "gebruik een beter model".

• Een productieklare agent is gecontroleerd op vijf dimensies: nauwkeurigheid, kosten en snelheid, veerkracht bij fouten, veiligheid en beheer, en de daadwerkelijke ervaring van de gebruiker.

• Een testset die alleen bestaat uit schone, ideale scenario's zal altijd slagen en vertelt je vrijwel niets. Voeg randgevallen, dubbelzinnige verzoeken en situaties toe waarin weigeren het juiste antwoord is.

• Ga in fasen live: sandbox, schaduwmodus naast een mens, een beperkte pilot met echte gebruikers en lage risico's, en dan pas de volledige uitrol. Direct overgaan op een volledige uitrol is de meest gemaakte fout.

• Als je AI-partner niet kan uitleggen hoe ze de agent hebben getest voordat ze hem overdroegen, is dat het duidelijkste waarschuwingssignaal dat je vóór de lancering zult krijgen, niet erna.

‍

Wat is de evaluatie van een AI-agent?

De evaluatie van een AI-agent is het proces waarbij het volledige besluitvormingspad van een agent wordt getest – niet alleen of het juiste eindantwoord werd gegeven – aan de hand van reële en uitdagende scenario's, voordat de agent wordt toevertrouwd met productieverkeer, geld of klanten.

Dat onderscheid is belangrijker dan het lijkt. Een traditionele softwaretest controleert of een functie de verwachte output geeft voor een bepaalde input. Een AI-agent voert geen vaste functie uit. Hij redeneert over een taak, beslist welke tools hij aanroept, voert deze in een bepaalde volgorde uit, interpreteert de resultaten en past soms halverwege zijn plan aan. Twee uitvoeringen van exact hetzelfde verzoek kunnen totaal verschillende paden bewandelen en beide correct zijn, of beide om verschillende redenen op verschillende manieren fout zijn. Het evalueren van een agent betekent kijken naar dat hele traject: de redenering, de tool-aanroepen, de volgorde en het herstel bij fouten, niet alleen naar de zin die er uiteindelijk uitkomt.

Dit is ook de reden waarom evaluatie geen eenmalige drempel is die je passeert en daarna vergeet. Agents vertonen 'drift' naarmate het onderliggende model wordt bijgewerkt, je product verandert en echte gebruikers vragen stellen die niemand in de testset heeft opgenomen. Evaluatie vóór de lancering vertelt je of de agent klaar is voor klanten. Evaluatie na de lancering vertelt je of het nog steeds de agent is die je hebt goedgekeurd.

‍

Waarom dit in 2026 de echte flessenhals is

Elke AI-leverancier zal beweren dat ze een agent voor je kunnen bouwen. Maar weinigen kunnen met enige precisie uitleggen hoe ze aantonen dat het veilig is om deze te draaien. Die kloof tussen bouwen en bewijzen is waar de meeste AI-initiatieven vastlopen, en de data bevestigt dit.

Volgens het State of Agent Engineering-rapport 2026 van LangChainheeft inmiddels 57% van de organisaties agents in productie draaien, een scherpe stijging ten opzichte van een jaar eerder. Maar kwaliteit – oftewel nauwkeurigheid, consistentie en de vraag of de agent zich aan de juiste toon en richtlijnen houdt – is de grootste barrière voor implementatie, genoemd door 32 procent van de respondenten. Latentie staat op de tweede plaats met 20 procent. Misschien wel het meest veelzeggende cijfer uit het rapport: 89 procent van de teams heeft een vorm van observability om te monitoren wat hun agent in productie doet, maar slechts 52,4 procent voert offline evaluaties uit voordat het zover is. De meeste bedrijven zijn ingericht om een brand te blussen. Veel minder bedrijven zijn ingericht om er een te voorkomen.

Een afzonderlijk onderzoek uit 2026 onder 650 bedrijfsleiders, besproken in Algolia's onderzoek naar agent-evaluatie, toonde aan dat 78% van de ondernemingen AI-agentpilots heeft lopen, maar dat minder dan 15 procent de productieschaal heeft bereikt. Datzelfde onderzoek wijst op een bevinding van Gartner dat 60 procent van de AI-productiefouten voortkomt uit datakwaliteit, ontbrekende context of hiaten in governance, in plaats van beperkingen van het model zelf. Kortom: het model is meestal prima. Wat kapotgaat, is alles eromheen: de data die het ziet, de grenzen waarbinnen het opereert en de vraag of iemand die grenzen daadwerkelijk heeft getest vóór de livegang.

Voor een koper verandert dit het hele gesprek met een AI-ontwikkelingspartner. De vraag is niet: "kan jullie model deze taak uitvoeren?" Frontier-modellen kunnen de meeste taken in een demo aan. De vraag is: "hoe bewijzen jullie dat deze specifieke agent, gekoppeld aan onze specifieke data en onze specifieke workflow, zich correct zal gedragen voor de duizendste klant, en niet alleen voor de eerste tien die jullie me lieten zien?"

Voordat je verder gaat, is het de moeite waard om een gestructureerd referentiekader voor deze beslissingen bij de hand te hebben, in plaats van te vertrouwen op je geheugen tijdens een gesprek met een leverancier. Codelevate's SaaS AI Blueprint zet de beslissingen rondom bouw, integratie en evaluatie uiteen die oprichters moeten nemen voordat ze AI in een product uitrollen, en het is gratis te downloaden.

‍

De 5 dimensies van een check op productie-gereedheid

Een nuttige evaluatie probeert niet de "kwaliteit van de agent" in één cijfer uit te drukken. Het toetst vijf afzonderlijke zaken, omdat een agent uitmuntend kan zijn op het ene vlak en gevaarlijk op het andere.

1. Nauwkeurigheid en taakvoltooiing

Heeft de agent de taak daadwerkelijk correct voltooid en is het redeneerproces inzichtelijk? Dit omvat of de juiste informatie is opgehaald, of het antwoord gebaseerd is op echte data in plaats van op plausibele verzinsels, en of de agent wist wanneer hij moest stoppen en het proces moest overdragen in plaats van te gaan gokken.

2. Kosten en snelheid

Een agent die nauwkeurig is, maar traag of duur, is evenmin klaar voor productie. Als een agent meer kost aan tokenverbruik en tool-aanroepen dan de taak die hij automatiseert waard is, is de implementatie financieel niet zinvol, hoe indrukwekkend het redeneervermogen ook lijkt. Latentie is net zo belangrijk zodra een agent te maken krijgt met een echte klant die op een antwoord wacht; dat is precies waarom het de op één na meest genoemde barrière is in de bovenstaande data van LangChain.

3. Veerkracht bij fouten

Wat gebeurt er als een tool-aanroep een time-out krijgt, een API onjuiste gegevens teruggeeft of de agent stuit op een situatie waar niemand rekening mee heeft gehouden. Probeert hij het verstandig opnieuw, schakelt hij een mens in, of improviseert hij maar wat in de hoop dat het goed komt. Foutinjectie – het opzettelijk kapotmaken van dingen tijdens het testen – is de enige betrouwbare manier om hierachter te komen voordat een echte storing dat voor je doet.

4. Veiligheid, beleid en governance

Kan de agent worden gemanipuleerd om zijn instructies te negeren via een slim geformuleerde prompt. Blijft hij binnen de tools en gegevens waarvoor hij geautoriseerd is. Volgt hij de compliance- en beleidsregels waar jouw bedrijf daadwerkelijk aan gebonden is, in plaats van een algemene versie daarvan. Dit is de dimensie die ondernemingen met meer dan 2.000 medewerkers het vaakst aanmerken als hun grootste zorg, direct na de kwaliteit zelf.

5. Gebruikerservaring en interactiekwaliteit

Cijfers op een dashboard zeggen niets over of het gesprek met de agent ook echt prettig aanvoelt. Is de toon passend bij je merk. Vraagt de agent om verduidelijking in plaats van te gokken wanneer een verzoek dubbelzinnig is. Blijft hij coherent tijdens een lang gesprek met meerdere interacties, in plaats van zichzelf bij het zesde bericht al tegen te spreken. Dit is de dimensie die het makkelijkst over het hoofd wordt gezien en die klanten als eerste opmerken.

Een agent die alleen goed scoort op nauwkeurigheid wordt niet geëvalueerd, maar gedemonstreerd. Productiegereedheid betekent dat je alle vijf de punten controleert en weet welke het zwakst is voordat een klant dat voor je ontdekt.

‍

‍

Een testset bouwen die problemen ook echt opspoort

De grootste fout bij het evalueren van agents is alleen testen met schone voorbeelden. Een testset die is opgebouwd uit de tien scenario's die je in de verkoopdemo gebruikte, zal elke keer slagen, omdat dat precies de gevallen zijn waarop de agent is afgesteld en getraind. Dat vertelt je dat de agent een demo kan geven. Het vertelt je niets over of hij een dinsdagmiddag met echte klanten kan overleven.

Een betrouwbare testset bevat vier soorten gevallen:

• Echte historische gevallen uit daadwerkelijke supporttickets, transacties of workflowlogs, geen synthetische voorbeelden die zijn geschreven om schoon en eenvoudig te zijn.

• Echte randgevallen: de klant met twee accounts, de bestelling die in de verkeerde valuta is geplaatst, het verzoek dat technisch gezien voldoet maar dat uiteraard niet zou moeten.

• Beleidsvallen: alles wat te maken heeft met persoonsgegevens, prijsuitzonderingen, terugbetalingen of juridische taal, waarbij het juiste gedrag vaak is om door te schakelen in plaats van actie te ondernemen.

• Bewuste negatieve gevallen, waarbij het juiste antwoord is dat de agent weigert, een verduidelijkende vraag stelt of helemaal niets doet. Een agent die altijd probeert te helpen, is niet altijd de agent die je wilt.

Synthetische data die wordt gegenereerd om een agent te testen, is meestal schoner dan wat een echte gebruiker zal typen, wat betekent dat het systematisch overschat hoe goed de agent presteert. Als je testset is geschreven door hetzelfde team dat de agent heeft gebouwd, vraag dan wie de moeilijke gevallen heeft geschreven en of iemand geprobeerd heeft de boel opzettelijk te laten crashen. Die laatste stap, ook wel adversarial testing of red teaming genoemd, is het verschil tussen een agent die getest is en een agent die alleen maar gedemonstreerd is.

‍

Demotesten versus productie-evaluatie

Het helpt om het verschil naast elkaar te zien, omdat het meeste meningsverschil tussen een leverancier en een koper voortkomt uit het feit dat beide partijen het over een andere kolom hebben.

‍

‍

Een leverancier die een werkende demo laat zien, heeft de linker kolom afgevinkt. Productiegereedheid betekent dat de rechter kolom ook moet worden afgevinkt. Als een voorstel of projectplan alleen de linker kolom beschrijft, is het de moeite waard om daar direct naar te vragen voordat je ergens voor tekent.

‍

De gefaseerde uitrol

Zelfs een goed geëvalueerde agent moet niet direct van een offline testomgeving naar 100% van het productie-verkeer gaan. De variabelen die er in de echte wereld het meest toe doen – de werkelijke verdeling van zoekopdrachten, hoe vaak randgevallen echt voorkomen en of je andere systemen onder belasting reageren zoals de agent verwacht – zijn precies de variabelen die een demo en een testomgeving proberen te vermijden. Een gefaseerde uitrol is de manier om die variabelen op kleine, herstelbare schaal te ontdekken in plaats van op grote, kostbare schaal.

Fase 1: Sandbox

De agent draait alleen op je testset en historische gegevens, zonder verbinding met live systemen of echte klanten. Dit is waar je de voor de hand liggende fouten goedkoop opspoort.

Fase 2: Schaduwmodus

De agent draait naast een mens mee met echte, live verzoeken, maar de output wordt nooit aan de klant getoond en er wordt nooit automatisch actie op ondernomen. Je vergelijkt wat de agent zou hebben gedaan met wat er daadwerkelijk is gebeurd; dit brengt verschillen aan het licht waar je niet aan had gedacht om op te testen.

Fase 3: Beperkte pilot

Een klein, afgebakend deel van het echte verkeer, gekozen vanwege het lage risico als er iets misgaat, met een mens die de resultaten beoordeelt en een duidelijke terugdraaischakelaar. Dit is waar je vooraf resultaatgerichte drempelwaarden vaststelt, bijvoorbeeld een maximaal aantal handmatige correcties per duizend beslissingen, zodat "klaar" een getal is waar je vooraf afspraken over hebt gemaakt, en geen gevoel op de dag van lancering.

Fase 4: Volledige productie, met continue evaluatie

Zodra de pilot aan de drempelwaarden voldoet, neemt de agent het volledige verkeer over, maar de evaluatie stopt niet. Elke week worden nieuwe fouten uit de praktijk toegevoegd aan de testset. Regressietests worden uitgevoerd bij elke wijziging aan de prompt, het model of de tools. Iemand houdt toezicht op afwijkingen naarmate het klantgedrag en je eigen product veranderen terwijl de agent draait.

Het patroon in elke fase is hetzelfde: breid de scope nooit uit totdat de huidige fase daadwerkelijk een vooraf vastgestelde drempelwaarde heeft behaald, en niet een waarde waar je op het laatste moment over onderhandelt omdat de deadline nadert.

‍

Vragen om aan een AI-leverancier of -bureau te stellen voordat je de oplevering accepteert

Als je een agent laat ontwikkelen in plaats van deze zelf te bouwen, is dit het deel van het gesprek dat een partner die ontwerpt voor productie onderscheidt van een partner die optimaliseert voor een mooie demo-dag.

• Kun je me de testset laten zien, niet alleen de resultaten, en aangeven hoeveel van de gevallen echt zijn versus synthetisch.

• Wat gebeurt er als een tool-aanroep faalt of een time-out krijgt? Loop met me door wat de agent daadwerkelijk doet, niet wat hij zou moeten doen.

• Wat is het plan voor de eerste 30 dagen na de lancering? Wie houdt toezicht en wat is de aanleiding voor een rollback?

• Wat zijn de kosten per voltooide taak, inclusief de gevallen waarin de agent een fout maakt en een mens dit achteraf moet corrigeren?

• Hoe ga je om met een verzoek dat geweigerd moet worden? Laat me een voorbeeld zien waarbij het juiste antwoord was om niets te doen.

• Wie is de eigenaar van de testset en de evaluatieresultaten zodra het project is afgerond? Als het antwoord "niemand behalve de leverancier" is, dan is het de moeite waard om dit in het contract te verduidelijken.

Een partner die dit al eerder heeft gedaan, heeft echte, specifieke antwoorden op alle zes de vragen, meestal met voorbeelden van een project dat je met dat van jezelf kunt vergelijken. Een algemeen antwoord op een van deze vragen, vooral de eerste twee, kun je beter beschouwen als een waarschuwingssignaal dan als een formaliteit.

‍

Hoe Codelevate de evaluatie van AI-agents aanpakt

Wij bouwen het evaluatieplan en de testset gelijktijdig met de agent zelf, niet pas nadat deze klaar is. Evaluatie achteraf toevoegen aan een systeem dat niet is ontworpen om getest te worden, is traag en zorgt ervoor dat zaken over het hoofd worden gezien. Elke agent die wij voor een klant opleveren, doorloopt de bovengenoemde gefaseerde uitrol: sandbox, shadow mode, beperkte pilot en volledige productie. De drempelwaarden voor het overgaan naar de volgende fase worden vooraf schriftelijk met de klant afgesproken, niet pas nadat de demo succesvol is verlopen.

Beveiliging en governance worden als een eigen werkstroom gecontroleerd in plaats van als een bijzaak die aan een checklist voor de lancering wordt toegevoegd. Als je wilt weten welke specifieke controles wij uitvoeren voordat er ook maar iets in aanraking komt met productie-verkeer, dan biedt onze AI-agent beveiligingschecklist gedetailleerd inzicht in de technische kant hiervan. Voor teams die moeten beslissen of ze deze expertise intern willen opbouwen of externe hulp willen inschakelen, beschrijft onze AI-ontwikkelingsdiensten pagina hoe wij zo'n samenwerking van begin tot eind structureren, waarbij evaluatie is inbegrepen in plaats van als extra kostenpost te worden berekend.

‍

De transformatie die dit je werkelijk oplevert

Dit alles is niet bedoeld om een lancering omwille van de vertraging te vertragen. Het gaat erom een sprong in het diepe te vervangen door een beslissing die je kunt verantwoorden aan je bestuur, je klanten of de toezichthouder die vraagt hoe je wist dat de agent veilig was voordat je hem inschakelde. Teams die vanaf het begin evaluatie inbouwen, leveren agents die bestand zijn tegen contact met echte klanten. Teams die dit overslaan, komen daar meestal op de harde manier achter, in het openbaar, op een dag die ze niet zelf hebben gekozen.

Als je op het punt staat de oplevering van een agent te accepteren, of deze nu intern of door een partner is gebouwd, pak dan de SaaS AI Blueprint erbij voordat dat gesprek plaatsvindt. En als je een second opinion wilt over de vraag of een agent die al voor je is gebouwd daadwerkelijk productierijp is, of als je een nieuwe agent aan het uitstippelen bent en vanaf dag één evaluatie wilt inbouwen, plan een gratis gesprek met ons team.