Beoordeel een proof of concept van een AI-agent aan de hand van succescriteria die zijn opgeschreven voordat hij werd gebouwd, op een vaste set echte gevallen waar ook de moeilijke tussen zitten. Meet nauwkeurigheid, kosten per taak en latency, controleer bij welke data en tools hij kan en hoe hij faalt, en schaal pas op als de resultaten ook buiten de demo overeind blijven.
Een overtuigende demo is geen bewijs
Een demo laat een AI-agent op zijn best zien, omdat hij draait op voorbeelden die de bouwers hebben gekozen en geoefend. Vóór het opschalen is de vraag een andere: hoe vaak doet de agent echt werk goed, wat kost elke taak, en wat gebeurt er op de dagen dat hij de fout in gaat?
Behandel de proof of concept als een experiment dat eindigt in een besluit: opschalen, aanpassen of stoppen. Dat besluit vraagt om criteria die zijn opgeschreven voordat de resultaten binnenkomen; anders valt bijna elk resultaat als veelbelovend te lezen.
Schrijf de succescriteria op voordat de agent wordt gebouwd
Bepaal wat ‘goed genoeg’ betekent voor het bedrijf en vertaal dat naar meetbare getallen. Voor een agent die supportverzoeken sorteert, kan dat het aandeel verzoeken zijn dat bij het juiste team terechtkomt, het aandeel dat hij terecht weigert af te handelen en de tijd die een mens aan het controleren van elk verzoek besteedt.
- Slagingspercentage op realistische gevallen, met een schriftelijke definitie van een correct resultaat
- De fouten die je kunt tolereren en de fouten die je niet kunt tolereren, zoals een fout antwoord aan een klant
- Kosten per afgeronde taak, inclusief modelgebruik en de tijd van de persoon die het werk controleert
- Een responstijd die bij de workflow past, afhankelijk van of iemand op het antwoord wacht
- Het vertrekpunt: hoe lang mensen nu over de taak doen, en hoe vaak ze het goed doen
Test op een vaste evaluatieset van echte gevallen
Verzamel echte invoer uit je eigen geschiedenis, noteer bij elk geval de juiste uitkomst en houd de set vast. Neem makkelijke gevallen op, twijfelgevallen, zeldzame gevallen en een paar die de agent zou moeten weigeren. Een kleinere set goed gekozen gevallen zegt meer dan een grote set makkelijke.
Laat de agent de hele set doorlopen telkens als de prompt, het model, de tools of de data veranderen, en vergelijk de resultaten met de vorige run. De uitvoer van een model verschilt per run, dus draai elk geval meer dan eens en kijk naar consistentie, niet alleen naar het beste antwoord. Houd de gevallen buiten de prompt en buiten elk voorbeeld dat de agent te zien krijgt, anders valt de score te gunstig uit.
Kijk ook naar hoe je scoort. Automatische controles werken voor gestructureerde uitvoer. Vrije tekst vraagt meestal om een mens, of om een tweede model waarvan je de oordelen op een steekproef met die van een mens hebt vergeleken.
Meet kosten en latency bij het volume dat je verwacht
Een proof of concept die een paar dozijn verzoeken per dag afhandelt, kan kosten verbergen die bij duizenden wél tellen. Leg per taak de modelaanroepen, tokens en toolaanroepen vast, en de tijd die elke taak kost. Agents die in een lus raken, opnieuw proberen of lange documenten lezen, kunnen bij sommige invoer veel meer kosten dan gemiddeld, dus bestudeer de traagste en duurste gevallen, niet alleen het gemiddelde.
Reken daarna de kosten door naar je verwachte volume en vergelijk ze met wat het werk nu kost, inclusief de tijd die mensen nog aan review besteden. Stel per taak harde limieten op stappen, tokens en tijd, zodat één slechte invoer geen hoge rekening kan opleveren. De OWASP Top 10 for LLM Applications noemt dit risico unbounded consumption: onbegrensd verbruik.
Ontwerp menselijke review bewust, en meet die daarna
Menselijke review hoort bij het ontwerp; het is geen tijdelijk vangnet. Bepaal welke acties de agent zelf mag uitvoeren, welke hij alleen mag voorstellen en welke hij nooit mag uitvoeren. Alles wat onomkeerbaar is of zichtbaar voor klanten, zoals een bericht versturen, een record wijzigen of geld uitgeven, hoort te wachten op goedkeuring door een mens tot de agent een lang trackrecord heeft.
Meet de review zelf: hoe lang die duurt, hoe vaak reviewers de uitvoer aanpassen en hoe vaak ze goedkeuren zonder echt te controleren. Kost het reviewen bijna net zoveel tijd als de taak zelf, dan bespaart de agent nog geen tijd. Kan je toepassing onder de Europese AI-verordening (AI Act) als hoog risico gelden, dan is effectief menselijk toezicht volgens artikel 14 een wettelijke eis en geen ontwerpvoorkeur. Betrek je juridisch adviseurs dus vroeg.
Stel grenzen aan data en beveiliging voordat je opschaalt
Opschalen brengt meer data, meer gebruikers en meer tools, en juist dan gaan zwakke grenzen tellen. De OWASP Top 10 for LLM Applications zet prompt injection op de eerste plaats: tekst die de agent leest, zoals een e-mail, een ticket of een webpagina, kan instructies bevatten die hem een andere kant op sturen. De lijst noemt ook excessive agency: meer functies, rechten of autonomie dan de taak vraagt. Regel deze punten voordat de pilot groeit.
- Welke data de agent kan lezen, en of persoonlijke of vertrouwelijke data naar een modelleverancier gaat, onder welk contract en welke bewaartermijnen
- Welke tools hij kan aanroepen, met zo beperkt mogelijke rechten en aparte toegangsgegevens per agent
- Wat hij kan wijzigen, en of elke wijziging te traceren en terug te draaien is
- Wat er wordt gelogd: elke toolaanroep met invoer en uitvoer, zonder persoonsgegevens te lekken
- Hoe de data van elke klant of elk team gescheiden blijft van die van de anderen
Bestudeer hoe hij faalt, en neem dan het besluit
Lees voor je beslist de fouten, niet alleen de score. Sorteer ze op soort: stellige foute antwoorden, terechte weigeringen, overgeslagen stappen, verkeerd toolgebruik, timeouts. Een agent die faalt door om hulp te vragen, is veel makkelijker in te zetten dan een agent die stilletjes faalt met een aannemelijk antwoord.
Beslis daarna. Schaal op als de criteria op de evaluatieset worden gehaald en de resterende fouten van een soort zijn die je proces kan opvangen. Verklein de scope als de agent maar een deel van de taak goed doet. Stop als hij het vertrekpunt niet verslaat, en bewaar de evaluatieset voor de volgende poging. Onze projecten met AI-agents volgen dezelfde volgorde: één taak, echte voorbeelden, review door je team, en pas meer scope als de agent vertrouwen heeft verdiend. Heb je een proof of concept die beoordeeld moet worden, dan kun je die beschrijven via ons formulier ‘Start een project’.
De kern
- Leg succescriteria en een vertrekpunt vast voordat de agent wordt gebouwd, zodat je het resultaat eerlijk kunt beoordelen.
- Test op een vaste set echte gevallen, ook moeilijke en twijfelachtige, en draai die opnieuw na elke wijziging.
- Meet kosten per taak en latency bij het verwachte volume, en kijk naar de slechtste gevallen én het gemiddelde.
- Ontwerp menselijke review bewust en meet hoe lang die duurt en wat ze opvangt.
- Stel grenzen aan data, tools en logging voordat je opschaalt, want prompt injection en excessive agency zijn bekende risico's.
Veelgestelde vragen
Hoeveel gevallen heeft een evaluatieset voor een AI-agent nodig?
Er is geen vast aantal. Er moeten genoeg gevallen in zitten om de belangrijkste varianten van de taak te dekken, de moeilijke en twijfelachtige, en de gevallen die de agent moet weigeren. Begin met wat je zorgvuldig kunt labelen, en voeg elke echte fout toe die je later vindt.
Kan een ander model de uitvoer van de agent beoordelen?
Ja, voor vrije tekst die moeilijk automatisch te controleren is, maar pas nadat je de oordelen op een steekproef van gevallen hebt vergeleken met die van een mens. Controleer die overeenstemming opnieuw telkens als je het model of de prompt verandert.
Wanneer stop je met een proof of concept van een AI-agent?
Als hij de huidige manier van werken niet verslaat op je succescriteria, of als de review die hij nodig heeft evenveel tijd kost als hij bespaart. Een duidelijke stop is een bruikbaar resultaat: bewaar de evaluatieset, want een nieuwer model of een smallere taak kan er later wel doorheen komen.