Een AI-agent die vlot handelt, is niet hetzelfde als een agent die de materie begrijpt. Voor je een agent inzet bij een klant in gereguleerde sectoren, moet je aantonen dat hij de nuance van het vakgebied doorheeft, niet alleen de vorm ervan nabootst. In dit artikel deel ik hoe wij bij Blinqx die test inrichten, met concrete stappen die je zelf ook kan toepassen.
Kloppende output hoeft niet altijd juist te zijn
Een agent kan een antwoord geven dat er correct uitziet en toch de plank misslaan zodra de context verschuift. Dat gebeurt vooral bij niet-standaard situaties: een polisclausule met een uitzondering, een jurisprudentie-uitspraak die een eerdere regel nuanceert, een aangifte met een net iets andere fiscale situatie. Generieke taalmodellen halen hun kennis uit brede training data en missen daardoor vaak de laatste stand van sectorregels, en ook de specifieke werkwijze van een kantoor.
Welke testmethode laat zien of een agent de nuance begrijpt?
Bij Blinqx bouwen we deze testsets samen met de vakspecialisten van de klant: juristen, accountants of hypotheekadviseurs die de grensgevallen uit hun eigen praktijk aandragen. Dat levert een testset op die niet generiek is, maar precies aansluit bij waar het in de praktijk misgaat. Niet de vraag “kan de agent een contract samenvatten”, maar “herkent de agent dat clausule 4.2 een uitzondering maakt op clausule 2.1, en past hij dat toe op een nieuw contract”.
Hoe bouw je een domeinkennis-testset per sector?
1 Verzamel eerst de casussen waar junior medewerkers vaker een fout maken dan senioren. Dat zijn per definitie de plekken waar domeinkennis het verschil maakt.
2 Vertaal die casussen naar scenario’s met een duidelijk goed en fout antwoord, en laat de agent ze een voor een doorlopen. Voor sectoren als verzekering en hypotheek werkt dit net iets anders dan voor accountancy: bij hypotheekadvies test je vooral op regelgeving die per klantprofiel verschilt, bij accountancy test je vaker op interpretatie van fiscale grensgevallen. De testmethode blijft hetzelfde, de casussen niet.
3 Documenteer bovendien niet alleen of de agent het goede antwoord geeft, maar ook of hij zijn redenering kan tonen. Een goed antwoord zonder navolgbare redenering is in een gereguleerde sector onvoldoende, want een toezichthouder of auditor wil straks kunnen zien hoe de agent tot zijn conclusie kwam.
4 Herhaal je tests. Domeinkennis testen is geen eenmalige check voor livegang. Sectorregels veranderen, klantcasussen verschuiven, en een agent die vandaag slaagt kan over een half jaar tegen een nieuwe uitzondering aanlopen die nog niet in de testset zat. Bouw de testset daarom als levend document, niet als afvinklijst.
Wanneer is een agent klaar voor launch bij een klant?
Een agent is klaar zodra hij
- de testset met niet-standaard cases consistent goed doorloopt,
- en weet wanneer hij een vraag moet doorzetten naar een mens in plaats van zelf te gokken.
Dat laatste punt onderschatten platform bouwers vaak: een agent die op tijd “ik weet het niet zeker” zegt, is waardevoller dan een agent die altijd een antwoord geeft.
Daarom bouwen we die twijfeldrempel bewust in: onder een bepaalde zekerheidsgrens escaleert de agent automatisch naar een mens, met de casus en de tot dan toe opgebouwde redenering erbij. Dat voorkomt dat een agent zich in domeinen begeeft waar hij de nuance nog niet aantoonbaar beheerst.
Die drempel stel je niet eenmalig in: Naarmate een agent langer draait en meer casussen goed afhandelt, kan je de drempel voorzichtig bijstellen, mits je dat onderbouwt met de testresultaten. Andersom geldt hetzelfde: zodra een sector een nieuwe regel invoert, verlaag je de drempel tijdelijk totdat de agent op die nieuwe casussen is getest.
Wat doe je als de agent zakt voor de test?
Analyseer welk type casus faalt: is het een kennisgat (de agent mist informatie), een redeneerfout (de agent heeft de informatie maar trekt de verkeerde conclusie), of een scopeprobleem (de agent had de vraag moeten doorzetten)? Elk van die drie vraagt een andere oplossing: meer trainingsdata, een strakker afgebakende scope, of een lagere escalatiedrempel. Afhankelijk hiervan, start je weer met Verzamelen, Vertalen of Documenteren.
We bespreken dit soort casussen ook in Tech TalQX, de podcast over AI in gereguleerde sectoren.
Veelgestelde vragen
Een taaltest controleert of de agent vloeiend en begrijpelijk schrijft. Een domeinkennistest controleert of de agent de vakinhoudelijke nuance van een sector correct toepast, inclusief uitzonderingen en grensgevallen. Een agent kan een taaltest glansrijk doorstaan en toch zakken voor domeinkennis.
Er is geen vast getal, maar richt je op dekking van de bekende edge cases in plaats van op een aantal. Begin met de casussen waar junior medewerkers vaker fouten maken, en breid uit zodra je nieuwe grensgevallen tegenkomt in de praktijk.
Beide, in samenwerking. De platform bouwer levert de testmethode en structuur, de vakspecialist bij de klant levert de casussen uit de eigen praktijk. Zonder die praktijkinbreng test je vooral generieke kennis, niet de specifieke situatie van het kantoor.
Ja, mits je een feedbackloop inbouwt waarin fouten uit de praktijk teruggekoppeld worden naar de testset. Zonder die loop blijft een agent hangen op het kennisniveau van de laatste trainingsronde, terwijl sectorregels en jurisprudentie doorlopend veranderen.
Het grootste risico is een agent die zelfverzekerd een fout antwoord geeft in een edge case, zonder dat iemand het merkt tot de klant er last van heeft. In gereguleerde sectoren kan dat leiden tot een verkeerd advies met financiële of juridische gevolgen, en dat ondermijnt het vertrouwen in AI-agents veel sneller dan een agent die op tijd toegeeft het niet zeker te weten.
