AI-agent observability is het stap voor stap vastleggen van wat een AI-agent doet, zodat engineers latency, tokenkosten, fouten in tools en mislukte runs zien. Voor een supportleider is dat maar de helft van het werk. De andere helft is kwaliteitsmonitoring: controleren of de agent klanten het juiste antwoord gaf, het beleid volgde, op tijd escaleerde en echt deed wat hij zei te doen.
In het kort
- Technische observability beantwoordt de vraag “draait de agent?”. Kwaliteitsmonitoring beantwoordt “heeft de agent gelijk?”. Observability-tools zijn vooral voor de eerste vraag gebouwd.
- De duurste fouten in support zien er in de logs uit als succes: foute antwoorden in opgeloste gesprekken, gemiste escalaties, beleidsschendingen en acties die de agent claimde maar nooit uitvoerde.
- Een bruikbaar dashboard voor AI-agent monitoring geeft elke metric een definitie, een databron, een alertdrempel en één eigenaar. De specificatie hieronder telt 13 rijen die je kunt overnemen.
- Leg drempels vast op basis van je eigen baseline van 4 weken en lees elke metric naast een wijzigingslog, zodat afwijkingen na een prompt- of kennisupdate binnen enkele dagen zichtbaar worden.
- Een wekelijkse review van 45 minuten die eindigt met benoemde oplossingen voorkomt dat het dashboard behang wordt.
Wat is AI-agent observability?
AI-agent observability betekent dat je elke run van een AI-agent vastlegt als een trace: het bericht van de klant, elke aanvraag aan het model, elke aanvraag aan een tool of API, de opgehaalde data en het antwoord, met tijden, aantallen tokens en fouten. Engineers gebruiken die traces om fouten op te sporen, kosten te beheersen en de agent snel en beschikbaar te houden.
De woordenschat komt uit software operations. Het Site Reliability Engineering-boek van Google noemt de vier gouden signalen van monitoring: latency, verkeer, fouten en verzadiging. AI-agent observability voegt toe wat specifiek is voor taalmodellen: prompts, modelversies, tokengebruik, retrieval en het gebruik van tools. De sector groeit naar een gedeeld dataformaat, de OpenTelemetry semantic conventions voor generatieve AI.
Een trace is het verslag van één run van de agent, en elke stap daarbinnen (een aanvraag aan het model, een zoekopdracht in de kennisbank, het opzoeken van een bestelling) is een span. De vraag naar dit inzicht is reëel: in een onderzoek van het IBM Institute for Business Value uit 2025 noemde ongeveer de helft van de leidinggevenden “a lack of visibility into agent decision-making processes as a significant implementation barrier” (IBM).
Wat is het verschil tussen AI-agent observability en AI-agent monitoring op kwaliteit?
Technische observability vertelt je of de AI-agent heeft gedraaid: hij antwoordde snel, zonder fouten, tegen acceptabele kosten. Kwaliteitsmonitoring vertelt je of de agent gelijk had: juist antwoord, toegestane actie, juiste escalatie, klant geholpen. Een gesprek kan perfect zijn in de trace en fout voor de klant, en de trace laat dat niet zien.
LangChain, dat het observability-platform LangSmith bouwt, zegt het zonder omwegen: traditionele monitoringtools “focus on metrics like latency, traffic, errors, and saturation”, terwijl “agent observability requires monitoring the inputs and outputs themselves, not just the system metrics around them” (LangChain, februari 2026).
Het juridische risico zit aan de kwaliteitskant. In Moffatt v. Air Canada (2024 BCCRT 149) vertelde de websitechatbot van de luchtvaartmaatschappij een klant dat hij achteraf een rouwtarief kon aanvragen, wat het beleid niet toestond. Het tribunaal veroordeelde de maatschappij tot betalen en schreef dat “it should be obvious to Air Canada that it is responsible for all the information on its website” (uitspraak van het tribunaal). Geen enkele latency-grafiek had dat antwoord gesignaleerd.
| Technische observability | Kwaliteitsmonitoring | |
|---|---|---|
| Vraag | Draait de agent, snel en betaalbaar? | Geeft hij juiste antwoorden en neemt hij juiste acties? |
| Eenheid van data | Trace en span | Gesprek, gescoord met een scorecard |
| Typische metrics | Latency, foutpercentage, fouten in tools, tokens, kosten | Juistheid, beleid, escalatie, overdracht, sentiment, herhaalcontact |
| Wat het mist | Een zelfverzekerd fout antwoord dat het ticket sloot | Een kapotte integratie, tenzij die in het gesprek zichtbaar wordt |
| Gebruikelijke eigenaar | AI-engineering, platformteam | Supportoperations, QA-lead, eigenaar van de AI-agent |
De lagen ontmoeten elkaar in het midden: een lus verschijnt in de trace als herhaalde stappen en in het gesprek als een gefrustreerde klant. De gesprekken zelf scoren aan een geschreven standaard is wat supportteams kwaliteitscontrole van AI-agents noemen.
Wat moet een supportleider monitoren bij een AI-agent?
Een supportleider monitort zeven dingen: antwoorden die fout waren maar als opgelost telden, mislukte escalaties en overdrachten, beleidsschendingen, acties die geclaimd maar niet uitgevoerd zijn, lussen, dalend sentiment en afwijkingen na elke wijziging. Elk daarvan komt door een technische gezondheidscheck, en daarom heeft elk een eigen meting nodig.
- Fout maar opgelost. De klant reageerde niet meer, dus de helpdesk telde een oplossing, maar het antwoord was fout. Dit is de kern van de stille fouten die je dashboard als succes telt, en hallucinaties zijn één oorzaak. Alleen de inhoud van opgeloste gesprekken scoren brengt het aan het licht.
- Mislukte escalaties en overdrachten. Een gemiste escalatie is een case die de agent hield terwijl je regels zeggen dat een mens hem moet overnemen. Een mislukte overdracht is een escalatie die slecht verloopt: geen context meegegeven, de klant moet alles herhalen, of niemand pakt hem op tijd op.
- Beleidsschendingen. De agent beloofde een terugbetaling, kwijtschelding van kosten of uitzondering die je beleid niet toestaat. Eén zo’n belofte kan genoeg zijn voor het management om elke verdere AI-uitrol stil te leggen tot compliance ernaar heeft gekeken.
- Geclaimd maar niet gedaan. De agent zegt “je terugbetaling is onderweg”, maar de backend toont geen terugbetaling. De aanvraag aan de tool mislukte ongemerkt, of de agent beschreef een actie die hij nooit probeerde. Dit vang je alleen af door transcripten te vergelijken met het bronsysteem.
- Lussen. De agent stelt drie keer dezelfde vraag of stuurt de klant heen en weer tussen chat en telefoon. De trace toont een hoog aantal beurten; de klant voelt zich vastzitten en komt terug, of zegt op.
- Dalend sentiment. De klant eindigt bozer dan hij begon, ook bij een technisch opgeloste case. Een stijging op één onderwerp wijst meestal op één antwoord dat de agent slecht afhandelt.
- Afwijkingen na wijzigingen. De kwaliteit verschuift wanneer er iets live gaat: een modelversie, een aangepaste prompt, een herschreven artikel, een nieuw beleid of een nieuwe integratie. Lees elke metric naast een wijzigingslog en een afwijking krijgt een datum en een oorzaak.
Of de agent het überhaupt waard is (oplossing, containment, kosten per oplossing, CSAT) is een andere vraag, die we behandelen in de prestaties van een AI-agent meten. Monitoring is de laag eronder: vangen wat deze week misging, zolang het nog klein is.
De dashboardspecificatie voor AI-agent monitoring
Een monitoringdashboard werkt alleen als elke metric een precieze definitie, een benoemde databron, een alertdrempel en één eigenaar heeft. Zonder die vier velden kleurt een grafiek rood en komt niemand in actie. Neem de specificatie hieronder over en vervang de voorbeelddrempels, die illustraties zijn en geen benchmarks, door cijfers uit je eigen baseline.
| Metric | Definitie | Databron | Alertdrempel (voorbeeld) | Eigenaar |
|---|---|---|---|---|
| Percentage fout maar opgelost | Aandeel door AI opgeloste gesprekken dat niet voldoet aan het juistheidscriterium | QA-scores van opgeloste gesprekken | 0,5 procentpunt boven de baseline van 4 weken, of boven 3% | Eigenaar van de AI-agent |
| Beleidsschendingen | Gesprekken waarin de agent iets beloofde of toekende buiten het geschreven beleid | Beleidscriterium van de scorecard | Elk afzonderlijk geval op een onderwerp van de rode lijst, dezelfde dag; anders boven 0,5% per week | Supportoperations samen met compliance |
| Percentage gemiste escalaties | Gesprekken die je regels naar een mens sturen, maar die de agent hield | Escalatiecriterium van de scorecard | Boven 1% per week, of elk geval op een trigger van de rode lijst | Eigenaar van de AI-agent |
| Percentage mislukte overdrachten | Escalaties zonder meegegeven context, met een klant die zich herhaalt, of zonder oppakken binnen de norm | Overdrachtsevents in de helpdesk plus scorecard | Boven 10% van de overdrachten, of 2 dagen oppakken buiten het serviceniveau | Lead supportoperations |
| Geclaimd maar niet gedaan | Agent meldt een actie (terugbetaling, annulering, wijziging) zonder bijbehorend record in de backend | Claims in transcripten vergeleken met order-, facturatie- of accountlogs | Elk geval bij betalingen; anders boven 0,2% van de gesprekken met een actie | AI-engineering samen met supportoperations |
| Percentage lussen | Dezelfde vraag of hetzelfde antwoord 3 keer of vaker, of heen en weer tussen kanalen | Traces en kanaalhistorie in de helpdesk | Aantal beurten boven het 95e percentiel van de baseline bij meer dan 2% van de gesprekken | Eigenaar van de AI-agent |
| Percentage herhaalcontact | Zelfde klant, zelfde probleem, binnen 72 uur na een AI-oplossing terug | Contacthistorie in de helpdesk | Relatieve stijging van 25% op een onderwerp, week op week | Lead supportoperations |
| Verschuiving naar negatief sentiment | Aandeel gesprekken waarin het sentiment lager eindigt dan het begon | Sentimentscores | Stijging van 5 punten op een onderwerp, week op week | CX-lead |
| Kwaliteitsscore per onderwerp | Gemiddelde scorecardscore per contactreden | QA-scores | Elk onderwerp 5 punten onder zijn baseline | QA-lead |
| Verschil na een wijziging | Elke metric in de 7 dagen na een wijziging tegenover de 7 dagen ervoor | Wijzigingslog plus de rijen hierboven | Elke overschreden drempel binnen 7 dagen na een wijziging leidt tot een review voor terugdraaien | Eigenaar van de wijziging |
| Scoringsdekking | Aandeel door AI afgehandelde gesprekken dat echt gescoord is | QA-tool tegenover het volume in de helpdesk | Onder 95% gedurende een dag | QA-operations |
| Overeenstemming tussen beoordelaars | Overeenstemming tussen automatische scores en menselijke reviewers op een wekelijkse steekproef | Kalibratiesteekproef | Onder het niveau dat bij livegang is afgesproken | QA-lead |
| Technische gezondheid en kosten | Foutpercentage, timeouts, p95-latency, fouten in tools, kosten per gesprek | Traces, APM en facturatie | Je engineering-serviceniveaus en budget | AI-engineering |
Drie regels houden het eerlijk. Elke kwaliteitsmetric linkt naar de gesprekken erachter, zodat een rode cel echte voorbeelden opent in plaats van een discussie. Elke metric wordt per onderwerp uitgesplitst, want een gemiddelde verbergt het ene artikel dat fout is. En de eerste twee rijen wegen zwaarder dan de laatste: een snelle, goedkope agent die foute antwoorden geeft, is niet gezond.
De meeste rijen hangen af van een geschreven scorecard. Heb je die niet, begin dan met de scorecard voor AI-agents en de methoden in de gids over AI-agents evalueren.
Hoe stel je alertdrempels in voor AI-agent monitoring?
Stel alertdrempels in op basis van je eigen baseline. Scoor minstens 4 weken aan gesprekken, noteer de normale wekelijkse bandbreedte van elke metric en geef een alert bij een beweging buiten die bandbreedte of bij een absoluut plafond, wat het eerst komt. Gebeurtenissen op de rode lijst, zoals betaalfouten of juridische toezeggingen, geven al bij één geval een alert, ongeacht het percentage.
De SRE-richtlijn van Google is dat “every page should be actionable”, dus werk met drie niveaus:
- Dezelfde dag: een beleidsschending op de rode lijst, een betaling die geclaimd maar niet gedaan is, dekking onder 95%, een storing.
- Binnen 2 dagen: een overschreden percentagedrempel op een druk onderwerp, of een overschreden drempel binnen 7 dagen na een wijziging.
- Wekelijkse review: tragere trends, onderwerpen met weinig volume, sentiment en herhaalcontact.
Rekenvoorbeeld: waarom volledige dekking verandert wat je ziet
Een illustratie met ronde getallen, berekend voor dit artikel. Een AI-agent handelt 50.000 gesprekken per week af en lost er 35.000 op zonder mens. De baseline voor fout maar opgelost is 2,0%, ongeveer 700 foute antwoorden per week. Op maandag wordt een artikel over retouren herschreven, en de week erna is het percentage 2,8%: ongeveer 980 foute antwoorden, 280 meer dan normaal.
| Een steekproef van 2% scoren | Elk opgelost gesprek scoren | |
|---|---|---|
| Gescoorde gesprekken | 700 | 35.000 |
| Foute antwoorden bij de baseline (2,0%) | 14 | 700 |
| Foute antwoorden na de wijziging (2,8%) | ongeveer 20 | 980 |
| Normale wekelijkse ruis (ongeveer de wortel uit het aantal) | ongeveer 4 | ongeveer 26 |
| Is de wijziging zichtbaar? | Nee: 6 extra gevallen, binnen de ruis | Ja: 280 extra gevallen, meer dan 10 keer de ruis |
Beleidsschendingen zijn zeldzamer. Bij 0,1% zijn het er ongeveer 35 per week op 35.000 opgeloste gesprekken. Een steekproef van 2% bevat er gemiddeld 0,7, dus de kans dat er geen enkele in zit, is ongeveer 50%. In de helft van de weken meldt een review op basis van een steekproef nul schendingen, terwijl 35 klanten iets te horen kregen wat je beleid niet toestaat.
Hoe ziet een wekelijkse kwaliteitsreview van een AI-agent eruit?
Een wekelijkse kwaliteitsreview van een AI-agent is een overleg van 45 minuten waarin de eigenaar van de AI-agent, de QA-lead, supportoperations en de eigenaar van de kennisbank alerts, foutclusters en de wijzigingen van vorige week doorlopen, en vertrekken met benoemde oplossingen. Compliance sluit aan als er een beleidsschending op de lijst staat. De output is een lijst met oplossingen en een bijgewerkt wijzigingslog.
- Alerts sinds vorige week (5 minuten): wat ging af, wat is gedaan, wat staat nog open.
- Top 3 foutclusters (15 minuten): telkens 3 echte gesprekken, op het scherm gelezen, niet samengevat.
- Doorgevoerde wijzigingen (10 minuten): elke wijziging uit het log met de cijfers van 7 dagen ervoor en erna.
- Oplossingen kiezen (10 minuten): één eigenaar en één datum per oplossing, of het nu gaat om een aanpassing in de kennisbank, een guardrail, een escalatieregel of terugdraaien.
- Oplossingen van vorige week controleren (5 minuten): is de metric waar elke oplossing op mikte, verschoven?
Haal oplossingen door je tests van vóór de lancering voordat ze live gaan; AI-agents testen behandelt testsets die voorkomen dat een oplossing voor het ene onderwerp een ander onderwerp breekt. Wie wijzigingen op de rode lijst goedkeurt, en wie een onderwerp kan uitschakelen, hoort in je model voor AI-agent governance.
Welke soorten tools voor AI-agent monitoring zijn er?
Tools voor AI-agent monitoring vallen in vijf categorieën: tracingtools voor developers, suites voor application performance monitoring, de eigen analytics van het agentplatform, conversation-QA-tools die opgeloste gesprekken scoren, en AI-securitytools. Elk beantwoordt een andere vraag, en daarom gebruiken de meeste supportteams met een AI-agent in productie er uiteindelijk twee of drie.
| Categorie | Vraag die de tool beantwoordt | Typische gebruiker | Voorbeelden | Waar het ophoudt |
|---|---|---|---|---|
| Tracing voor developers | Waarom mislukte deze run, en wat kostte hij? | AI-engineers | LangSmith, Langfuse, Arize Phoenix | Gebouwd om runs te debuggen, niet om antwoorden aan je beleid te toetsen |
| Application performance monitoring | Is de dienst beschikbaar en snel? | Platformteams | Datadog, IBM Instana, Splunk | Weinig zicht op de juistheid van antwoorden |
| Analytics van het agentplatform | Hoe doet deze agent het op zijn eigen metingen? | Eigenaar van de AI-agent | Ingebouwd in Fin, Decagon, Agentforce, Zendesk AI agents | Eén platform, eigen definities |
| Conversation QA | Was het antwoord juist, toegestaan en goed geëscaleerd? | QA-lead, supportoperations | QA-tools die gesprekken scoren met je scorecard | Werkt nadat het gesprek is afgelopen; geen debugger voor runs |
| AI-security | Doet de agent iets onveiligs of ongeautoriseerds? | Securityteam | AI-securityplatformen | Toegang en misbruik, niet de kwaliteit van de service |
Kies op basis van de vraag die je vandaag niet kunt beantwoorden: kunnen engineers een mislukte run niet debuggen, begin dan met tracing; kan niemand zeggen hoeveel opgeloste gesprekken vorige week fout waren, begin dan met conversation QA.
Wanneer is dit niveau van AI-agent monitoring niet voor jou?
Volledige kwaliteitsmonitoring is de bouw niet waard zolang de AI-agent een paar honderd gesprekken per week afhandelt over onderwerpen met weinig risico. Bij dat volume volstaat één persoon die wekelijks gesprekken leest, en is de tijd beter besteed aan de kennisbank.
Het is ook de verkeerde eerste stap als de agent nog niet live is (dan heb je tests vóór de lancering nodig) of als je geen geschreven standaard hebt voor een goed antwoord: een tool kan geen alert geven op een regel die niemand heeft opgeschreven.
Zo begin je deze week met AI-agent monitoring
Je kunt deze week met AI-agent monitoring beginnen zonder iets te kopen: schrijf een rode lijst, start een wijzigingslog, lees de opgeloste gesprekken van vorige week voor een eerste baseline en wijs voor elke metric een eigenaar aan. Tooling kan volgen zodra je weet welke vragen je niet kunt beantwoorden.
- Schrijf de rode lijst: 5 tot 10 onderwerpen zoals terugbetalingen, opzeggingen, juridische zaken, veiligheid en kwetsbare klanten.
- Start een wijzigingslog: datum, wat veranderde, wie het veranderde. Vul de afgelopen maand achteraf aan.
- Lees 200 opgeloste AI-gesprekken van vorige week naast je beleid, en tel fout maar opgelost, gemiste escalaties en schendingen.
- Neem de dashboardspecificatie over, schrap de rijen die je nog niet van data kunt voorzien en vul elke eigenaarscel in.
- Plan de wekelijkse review elke week op hetzelfde moment.
Staan je gesprekken in Zendesk of Salesforce en wil je de kwaliteitslaag zonder alles met de hand te lezen, dan is dat het deel dat Kaizo afdekt. AutoPilot scoort elk gesprek met je eigen scorecard zodra het is opgelost en koppelt elke score aan het bewijs, en je test het tegen je eerdere beoordelingen voordat het live gaat. Grondoorzaakanalyse herleidt een kwaliteitsdip tot de gesprekken die hem veroorzaakten. Het vervangt de tracingtools van je engineers niet; zie kwaliteitscontrole van AI-agents voor hoe het past.
Zie het op de gesprekken van je eigen AI-agent. Afspraak boeken.
Veelgestelde vragen
Kun je AI-agents monitoren?
Ja, op twee niveaus. De runs van een agent kun je tracen op fouten, snelheid en kosten, en zijn gesprekken kun je scoren op juistheid, beleid en escalatie. Supportteams hebben allebei nodig, want een technisch gezonde run kan een klant nog steeds een fout antwoord geven.
Wat zijn de beste tools om agentische AI te monitoren?
Er is niet één beste tool, want elke categorie beantwoordt een andere vraag: tracingtools debuggen runs, performancesuites bewaken de beschikbaarheid, platformanalytics rapporteren over één agent en conversation-QA-tools controleren of antwoorden juist en toegestaan waren. Begin met de vraag die je vandaag niet kunt beantwoorden.
Wat is een trace van een AI-agent?
Een trace is het volledige verslag van één run van een AI-agent, van het bericht van de klant tot het antwoord. Elke stap daarbinnen, zoals een aanvraag aan het model of het opzoeken van een bestelling, is een span met eigen tijden, input, output en fouten. Een trace laat zien hoe de agent tot een antwoord kwam, niet of dat antwoord juist was.
Wie is eigenaar van AI-agent monitoring in een supportteam?
Verdeel het eigenaarschap per laag. AI-engineering is eigenaar van technische gezondheid en kosten. Een benoemde eigenaar van de AI-agent, meestal binnen supportoperations, is eigenaar van de kwaliteit van antwoorden, escalaties en lussen. De QA-lead is eigenaar van de scorecard en de overeenstemming tussen beoordelaars. Elke metric op het dashboard hoort precies één naam te dragen.
Is de containment rate genoeg om een AI-agent te monitoren?
Nee. Containment telt elk gesprek dat geen mens bereikte als succes, ook de gesprekken waarin de agent fout zat en de klant het opgaf. Lees het naast het percentage fout maar opgelost, herhaalcontact binnen 72 uur en de verschuiving in sentiment. Zie QA voor gesprekken die AI afhandelt (in het Engels) voor wat je eerst controleert.
