Foutanalyse AI-agents: hallucinatie of ontbrekend beleid?

Foutanalyse van AI-agents betekent dat je elk mislukt AI-gesprek naar oorzaak indeelt voordat iemand het oplost. De meeste fouten die “hallucinaties” worden genoemd, zijn iets anders: een ontbrekend artikel, een verouderd of dubbelzinnig beleid, een mislukte zoekstap, een kapotte tool of een slechte overdracht. Elke oorzaak heeft een andere eigenaar en een andere oplossing, dus het label bepaalt of de oplossing werkt.

In het kort

• “Hallucinatie” beschrijft een symptoom (een zelfverzekerd fout antwoord), geen oorzaak. Behandel het als de laatste verklaring, niet als de eerste.
• Tien oorzaken dekken bijna elk mislukt AI-gesprek in support, van kennishiaten tot verwarring aan de kant van de klant.
• Eén vraag beslist de meeste gevallen: was er een goedgekeurde bron die dit beantwoordde, en heeft de agent die gebruikt?
• Oorzaken in de content gaan naar de eigenaar van de kennis of het beleid, oorzaken in tools naar engineering, en alleen redeneerfouten naar het team dat de AI-agent afstelt.
• Volg de verdeling per oorzaak per 1.000 gesprekken elke week. Alleen aandelen misleiden, want een oorzaak kan als aandeel groeien terwijl ze in aantal krimpt.

Waarom noemen teams elke fout van een AI-agent een hallucinatie?

Teams noemen elke fout een hallucinatie omdat het transcript alleen de output laat zien: een fout antwoord, met zelfvertrouwen gegeven. De oorzaak ligt eerder in de keten, in de content, het beleid, de zoekstap, een tool of de overdrachtsregels. Zonder een stap die de oorzaak indeelt, wint het bekendste woord, en belandt de oplossing bij de prompt.

Het woord heeft een precieze betekenis. Het risicoprofiel van NIST voor generatieve AI definieert confabulatie, “in de volksmond ook hallucinaties genoemd”, als systemen die “foutieve of onware content genereren en die met zelfvertrouwen presenteren” (NIST AI 600-1, paragraaf 2.2, in het Engels). Dat dekt het model dat iets verzint. Het dekt niet een agent die trouw een verouderd artikel over terugbetalingen herhaalde, of een die een beleid volgde dat niemand had opgeschreven.

Het verschil doet ertoe omdat het verkeerde label het werk naar het verkeerde team stuurt. Een promptwijziging kan geen artikel repareren dat niet bestaat. Toen het bedrijf achter de supporttool Pylon zo’n 200 tickets indeelde die zijn AI-agent in één week in de eigen wachtrij had doorgezet, waren kennishiaten “goed voor meer dan de helft van de escalaties” en waren featureverzoeken 15% (Pylon, september 2026, in het Engels). Dat zijn de gegevens van één bedrijf, geen benchmark, maar geen van beide oorzaken is een probleem van het model.

Deze gids hoort bij onze hub over beleid voor AI-agents, die behandelt hoe beleid wordt geschreven, beheerd en van versies voorzien. Hier ligt de focus op de stap vóór de oplossing: de oorzaak juist benoemen.

Wat zijn de tien redenen waarom AI-gesprekken mislukken?

AI-gesprekken in support mislukken om tien hoofdredenen: een kennishiaat, verouderde of tegenstrijdige kennis, een ontbrekend of dubbelzinnig beleid, een mislukte zoekstap (retrieval), een redeneerfout of hallucinatie, een fout in een actie of tool, een mislukte overdracht, een scopefout, een productbug of featureverzoek, en een probleem aan de kant van de klant. Elke oorzaak laat een ander spoor na in het transcript.

De tabel hieronder is de indeling om over te nemen. Gebruik haar als keuzelijst in je beoordelingsformulier, één oorzaak per mislukt criterium.

Tag het mislukte criterium, niet het hele gesprek, want één gesprek kan om twee oorzaken mislukken. Oorzaken 6 en 7 verstoppen zich vaak in containmentcijfers; onze gids over stille fouten van AI-agents behandelt hoe je ze zichtbaar maakt. Voor menselijke medewerkers staat het vergelijkbare onderscheid in onze gids over een fout van de medewerker of van het proces (in het Engels).

Hoe onderscheid je een hallucinatie van een ontbrekend beleid?

Je onderscheidt een hallucinatie van een ontbrekend beleid door de bron te controleren. Beantwoordde een goedgekeurde, actuele bron de vraag en week de agent ervan af, dan is het een hallucinatie of redeneerfout. Dekte geen enkele bron de case, of bestaat de regel alleen in de hoofden van ervaren medewerkers, dan is het een ontbrekend beleid, en geen enkele wijziging aan het model lost dat op.

De vier paren die het vaakst worden verward:

• Hallucinatie vs ontbrekend beleid. De test is: “had een nieuwe medewerker die alleen je schriftelijke bronnen las, juist kunnen antwoorden?” Zo niet, dan had de AI-agent niets om trouw aan te zijn.
• Hallucinatie vs verouderde kennis. Staat het foute feit woord voor woord in een artikel, dan deed de agent zijn werk. Het artikel is de fout.
• Hallucinatie vs mislukte zoekstap. Bestaat het juiste artikel, maar past het antwoord bij een naburig onderwerp, dan antwoordde de agent trouw vanuit de verkeerde pagina. Retrieval-augmented generation, de methode die veel AI-agents in support gebruiken, koppelt een model aan een zoekopdracht in je content (Lewis et al., 2020, in het Engels), dus de zoekstap kan op zichzelf mislukken.
• Gehallucineerde actie vs toolfout. “Je terugbetaling is onderweg” zonder terugbetaling in het systeem is ofwel een agent die een actie claimt die hij nooit uitvoerde, ofwel een tool-call die stil mislukte. Het toollog vertelt je welke van de twee. Onze gids over de audit van het oplossingspercentage van een AI-agent behandelt hoe je geclaimde acties controleert tegen de records in de achterliggende systemen.

Onze gids over AI-hallucinaties opsporen behandelt de routine voor echte hallucinaties zodra je ze hebt geïsoleerd. Deze pagina is het filter dat bepaalt welke echt zijn.

De beslisboom voor triage: tien vragen op volgorde

De snelste manier om een mislukt AI-gesprek in te delen, is een vaste lijst vragen in een vaste volgorde beantwoorden en te stoppen bij het eerste “ja” of “nee” dat een oorzaak benoemt. De volgorde doet ertoe: ze sluit oorzaken bij de klant, het product en de systemen uit voordat ze de content de schuld geeft, en de content voordat ze het model de schuld geeft.

Neem dit over in je beoordelingsformulier. Beantwoord de vragen voor één mislukt criterium tegelijk.

1. Had een mens uit wat de klant schreef kunnen begrijpen wat die wilde? Nee: aan de kant van de klant (oorzaak 10). Ja: ga door.
2. Was het een verzoek dat de AI-agent überhaupt zou moeten afhandelen? Nee, en hij handelde het toch af: scopefout (oorzaak 8). Ja: ga door.
3. Was het onderliggende probleem een defect, of iets wat het product niet doet? Ja: productbug of featureverzoek (oorzaak 9). Nee: ga door.
4. Moest de agent een actie uitvoeren of controleren (opzoeken, terugbetalen, opzeggen, bijwerken), en mislukte die call, liep hij in een time-out of werd hij geweigerd? Ja: fout in actie of tool (oorzaak 6). Nee: ga door.
5. Had het gesprek naar een mens moeten gaan, op een ander moment of met betere context? Ja: mislukte overdracht (oorzaak 7). Nee: ga door.
6. Beantwoordt een goedgekeurde bron deze vraag? Nee, en de regel is voor iedereen duidelijk: kennishiaat (oorzaak 1). Nee, en de regel hangt af van wie je het vraagt: ontbrekend of dubbelzinnig beleid (oorzaak 3). Ja: ga door.
7. Is die bron actueel, en de enige bron over het onderwerp? Nee: verouderde of tegenstrijdige kennis (oorzaak 2). Ja: ga door.
8. Heeft de agent die bron voor dit antwoord gebruikt? Nee: mislukte zoekstap (oorzaak 4). Ja: ga door.
9. Klopt het antwoord met de bron? Nee: redeneerfout of hallucinatie (oorzaak 5). Ja: ga door.
10. Klopt het criterium zelf? Volgde de agent een actuele, goedgekeurde bron trouw en mislukte het toch, dan is het criterium op de scorecard misschien fout. Stuur het naar de QA-lead voor kalibratie in plaats van een oorzaak te forceren.

Vraag 10 is het veiligheidsventiel: een indeling die niet kan zeggen “ons criterium was fout”, geeft de schuld aan wie er overblijft. Tel hoe vaak je bij vraag 9 uitkomt. Het is het enige pad dat eindigt bij “hallucinatie”.

Wie lost elke oorzaak op, en hoe stuur je het door?

Elke oorzaak heeft één eigenaar, en die wordt bepaald door waar de oplossing moet gebeuren: content gaat naar de eigenaar van de kennis of het beleid, systemen naar engineering, het product naar het productteam, en alleen instructies en redeneren naar de AI-eigenaar. Stuur het gesprek door met het bewijs erbij, nooit alleen een aantal.

Benoem elke eigenaar als persoon, niet als team. Een doorstuurnotitie heeft vier dingen nodig: de oorzaak, twee of drie voorbeeldgesprekken met de foute regels gemarkeerd, de betrokken intent met het volume per week, en de datum waarop je opnieuw scoort. Zonder de voorbeelden discussieert het ontvangende team over de indeling in plaats van het op te lossen.

Een AI-agent repareren is geen mens coachen: de oplossing moet de content of de configuratie veranderen die de agent leest. Ons stuk over mensen coachen vs AI-agents verbeteren behandelt dat onderscheid. Voor oorzaken 6 en 8 is de juiste oplossing soms een limiet, geen beter antwoord. OWASP noemt “excessive functionality”, “excessive permissions” en “excessive autonomy” (te veel functies, rechten en autonomie) als grondoorzaken van schadelijke acties van agents (OWASP LLM06, in het Engels), en daar gaan onze gidsen over guardrails voor AI-agents en autonomieniveaus van AI-agents verder.

Hoe draai je een wekelijkse triage van AI-fouten?

Draai de triage van AI-fouten als wekelijkse sessie van 45 tot 60 minuten: haal de mislukte gesprekken op, groepeer ze per intent, deel de grootste clusters in met de beslisboom, stuur elke oorzaak met voorbeelden naar de eigenaar en controleer of de oplossingen van vorige week standhielden. Deel clusters in, geen losse gesprekken, zodat de sessie meegroeit met het volume.

Een routine die werkt:

1. Maandag: haal de fouten op. Neem elk AI-gesprek dat vorige week op een kritiek criterium is gezakt (juistheid, beleid, actie, escalatie). Scoor je alleen een steekproef, voeg dan elk gesprek toe met een heropening, een klacht of een herhaald contact binnen 7 dagen.
2. Groepeer per intent. Terugbetalingen, adreswijzigingen, inlogproblemen. Begin met de vijf intents met de meeste fouten.
3. Deel per cluster drie tot vijf gesprekken in. Loop de tien vragen af. Zijn ze het eens, tag dan het cluster. Lopen ze uiteen, dan is het cluster twee problemen: splits het.
4. Stuur door. Eén ticket per oorzaak per intent, naar een benoemde eigenaar, met de voorbeelden en een datum om opnieuw te scoren.
5. Controleer vorige week. Vergelijk voor elke doorgevoerde oplossing het aantal fouten op die intent ervoor en erna. Een oplossing die het aantal niet veranderde, was de verkeerde oplossing of de verkeerde oorzaak.
6. Leg het vast. Eén regel per cluster: week, intent, oorzaak, aantal, eigenaar, oplossing, resultaat. Dit log is je foutverdeling door de tijd.

De QA-lead leidt de sessie met de AI-eigenaar, de kenniseigenaar en een lead van support operations. Beleid, engineering en product schuiven alleen aan als hun punt op de lijst staat. Mislukte overdrachten zie je vaak pas over meerdere gesprekken heen, en daar helpt customer journey QA.

Hoe meet je de verdeling van AI-fouten door de tijd?

Meet de foutverdeling elke week als fouten per 1.000 AI-gesprekken, uitgesplitst naar oorzaak, naast het aandeel van elke oorzaak. Aantallen per 1.000 laten zien of een oorzaak krimpt. Aandelen laten zien waar het resterende werk zit. Lees beide, want als je één oorzaak oplost, lijken de andere als aandeel groter, ook als er niets veranderde.

Pylon zag dit in zijn eigen gegevens: terwijl de kennishiaten afnamen, gingen bugmeldingen “omhoog van 8,5% van de escalaties naar 19%” (Pylon, in het Engels). Een stijgend aandeel betekent op zichzelf niet meer bugs: de andere stukken van de taart werden kleiner.

Een rekenvoorbeeld (illustratie, getallen verzonnen om de berekening te laten zien)

Neem een AI-agent die 12.000 gesprekken per week afhandelt. In week 1 zakken er 480 op een kritiek criterium: 40 per 1.000. Het team lost in vier weken de grootste clusters in kennis en beleid op. In week 5 is het volume gelijk en zakken er 290: 24,2 per 1.000.

Er zijn drie dingen uit af te lezen. De drie oorzaken in de content daalden van 260 naar 95 fouten, van 54,2% naar 32,8% van de verdeling. Hallucinaties gingen van 7,3% naar 11,4% van de fouten terwijl hun aantal daalde van 35 naar 33: een leidinggevende die alleen naar aandelen kijkt, zou concluderen dat het model slechter werd. En toolfouten veranderden nauwelijks (40 naar 38), wat zegt dat engineering zijn oplossing nog niet heeft uitgerold.

De metrics om op het dashboard te houden:

• Fouten per 1.000 AI-gesprekken, totaal en per oorzaak.
• Aandeel per oorzaak, om te bepalen waar de inzet van volgende week naartoe gaat.
• Terugkeer: fouten in een intent en oorzaak die als opgelost waren gemarkeerd. Boven nul na twee weken betekent dat de oplossing niet standhield.
• Doorlooptijd per eigenaar, van doorgestuurd ticket tot nieuwe score.
• Percentage niet ingedeeld: fouten die niemand kon plaatsen. Stijgt het boven een klein aandeel, dan hebben de indeling of de criteria werk nodig.

Wanneer is deze indeling niet voor jou?

Een indeling in tien oorzaken is niet voor jou, of nog niet, wanneer je AI-agent een paar honderd vragen per maand beantwoordt uit een klein helpcenter en geen acties uitvoert. Dan volstaan drie bakken: content (oorzaken 1 tot 3), AI-agent (4, 5, 8, 10) en al het andere. Stap over op de volledige lijst zodra eigenaren buiten support het werk gaan ontvangen.

Tekenen dat je drie bakken bent ontgroeid: de agent voert acties uit in andere systemen, je hebt meer dan één AI-agent of platform dat klanten antwoordt, beleid verandert vaker dan één keer per kwartaal, of twee teams zijn het elke week oneens over wiens probleem een fout is. Blijft dezelfde intent mislukken na oplossingen, voer dan een diepere oorzaakanalyse uit op dat ene cluster in plaats van categorieën toe te voegen.

Waar Kaizo past

Kaizo is QA en governance-toezicht voor supportteams waar mensen en AI-agents het werk delen. Het dekt de bewijskant van foutanalyse: gesprekken scoren, grondoorzaken zichtbaar maken en opnieuw scoren na een oplossing. Het schrijft je artikelen of je beleid niet.

AutoPilot scoort elk afgehandeld gesprek tegen je eigen scorecard, en aan de kant van kwaliteitscontrole van AI-agents voeg je de criteria toe waarop een AI-agent mislukt en koppel je je kennisbank, zodat er tegen je eigen content wordt beoordeeld. Elke score linkt naar het bewijs in het transcript. Insights zet die scores om in grondoorzaken (het kapotte proces, de frictie in het product, het hiaat in vaardigheden), en dat geeft de wekelijkse triage haar startclusters en voorbeelden.

Zie het op je eigen gesprekken. Boek een demo en neem één intent mee die je team een hallucinatieprobleem noemt.

Hoe je deze week begint

Begin met de slechtste AI-gesprekken van vorige week, niet met een nieuwe tool. Voeg de tien oorzaken toe aan je beoordelingsformulier, deel een kleine partij in met de beslisboom, benoem een eigenaar per oorzaak en los het grootste contentcluster eerst op.

1. Plak de tabel met tien oorzaken in je beoordelingsformulier als verplichte keuzelijst bij elk mislukt criterium.
2. Neem de 30 slechtste AI-gesprekken van vorige week en loop bij elk de tien vragen af. Tel hoeveel er bij vraag 9 uitkomen.
3. Benoem één eigenaar per oorzaak, als personen, en spreek het formaat van de doorstuurnotitie af.
4. Plan een terugkerend triagemoment van 45 minuten en begin het log met de clusters van deze week.
5. Kies het grootste contentcluster en los het eerst op. Scoor de intent volgende week opnieuw. De volledige beleidskant van de cirkel staat in onze gids over beleid voor AI-agents.

Veelgestelde vragen

Is elk fout antwoord van een AI-agent een hallucinatie?

Nee. Een hallucinatie is content die het model genereert en die niet wordt gedekt door zijn bronnen of het gesprek. Een fout antwoord dat uit een verouderd artikel is overgenomen, of een gok bij een case die geen beleid dekt, is een fout in de content. De test is of er een juiste, goedgekeurde bron bestond en de agent daarvan afweek.

Stopt het verankeren van een AI-agent in je eigen content hallucinaties?

Verankering in je eigen content (grounding) vermindert verzonnen antwoorden, maar haalt ze niet weg, en voegt nieuwe punten toe waar het mis kan gaan. De agent kan het verkeerde artikel ophalen, een verouderd artikel citeren of toch afwijken van het juiste. Daarom krijgen de zoekstap en verouderde kennis een eigen oorzaak in de indeling, los van hallucinatie.

Wie moet eigenaar zijn van de foutanalyse van AI-agents?

Meestal is de QA-lead eigenaar van de indeling en de wekelijkse triage, omdat de scorecard en het beoordelingsbewijs bij QA liggen. De oplossingen horen bij de eigenaren van elke oorzaak: kennis, beleid, AI-configuratie, engineering, support operations en product. Eén persoon als eigenaar van de indeling houdt de tags van week tot week consistent.

Hoeveel mislukte AI-gesprekken moet je elke week indelen?

Deel clusters in, niet elk gesprek. Drie tot vijf gesprekken per cluster, over de vijf intents met de meeste fouten, zijn 15 tot 25 gesprekken per week, en dat dekt meestal het grootste deel van de fouten. Lees er meer in een cluster wanneer de gesprekken het oneens zijn over de oorzaak.

Moeten featureverzoeken meetellen als fouten van een AI-agent?

Tel ze, maar rapporteer ze apart van de fouten van de agent zelf. Een featureverzoek laat de klant in de steek, niet de agent, en geen wijziging in content of prompt lost het op. Door ze te tellen ziet product hoe vaak klanten erom vragen, en blazen ze het foutpercentage van de AI-agent niet op.