AI-agent observability bij de servicedesk

Wanneer een AI-agent een ticket afhandelt, gebeurt er van alles binnen dat proces dat de meeste teams niet kunnen zien. Het ticket wordt getrieerd, een antwoord gaat eruit, een notitie verschijnt, en niemand kan beantwoorden: wat besliste de agent precies, op basis waarvan, met welke mate van zekerheid, en op welk moment besloot hij dat een mens het over moest nemen?

Dat gat is geen kleine onhandigheid. Het is de reden dat AI bij de servicedesk ofwel betrouwbaar wordt ofwel een zwarte doos waar je bang voor bent om aan te sleutelen. Observability is het antwoord: een overzicht per run van wat de agent deed, welke kennis hij gebruikte, welke confidence hij per stap toekende, en waarom hij escaleerde of in zijn rijstrook bleef.

Dit artikel behandelt wat observability betekent voor een AI-agent bij de servicedesk, welke data je per run nodig hebt, hoe confidence-signalen in de praktijk werken, hoe shadow mode daarin past, en wat je met de logs kunt doen zodra je ze hebt.

Waarom observability voor agents meer gewicht heeft dan voor scripts

Een gescriptede automatisering doet wat het script zegt. Als het script zegt "als categorie gelijk is aan hardware, wijs toe aan IT Operations," kun je het script lezen en precies weten wat er zal gebeuren.

Een AI-agent evalueert context en neemt een oordeel. Dat oordeel wordt gevormd door de tickettekst, de kennis die hij ophaalde, de confidence van zijn eigen eerdere stappen, en de ingestelde drempels waarbinnen hij werkt. Niets hiervan is zichtbaar in het ticketrecord alleen. Het ticket toont de uitkomst. Observability toont de redenering.

Dat telt voor drie praktische redenen:

Ten eerste debuggen. Wanneer een agent iets onverwachts doet, of hij een ticket verkeerd categoriseerde, een antwoord stuurde waar het team het niet mee eens was, of naliet te escaleren bij een ticket dat geescaleerd had moeten worden, moet je kunnen terugvoeren wat hij zag en wat hij besliste. Zonder een beslislog raad je maar.

Ten tweede verbetering. Als een agent consistent hoge confidence toekent aan een categorie die onjuist blijkt, zie je dat patroon alleen als je per-run-confidence-scores kunt analyseren. De uitkomst alleen vertelt je dat er fouten zijn. Het confidence-log vertelt je waar het model van de agent het mis heeft.

Ten derde vertrouwen. Een team dat een run-record kan openen en precies kan zien wat de agent stap voor stap deed, calibreert zijn vertrouwen in de agent nauwkeuriger dan een team dat alleen de uitkomst ziet. Zowel te veel vertrouwen als te weinig vertrouwen zijn een probleem. Observability is het calibratiemechanisme.

Wat een run-record moet bevatten

Een bruikbaar run-record voor een AI-agent bij de servicedesk dekt de volledige levenscyclus van een enkel ticketevent. Minimaal zou het moeten bevatten:

Wat de run triggerde. Het eventtype (nieuw ticket, statuswijziging, nieuwe opmerking), de ticketidentificatie, het tijdstip, en welke agentconfiguratie actief was.

Wat de agent las. De ticketinhoud die verwerkt werd: onderwerp, tekst, bestaande notities, overwogen bijlagen, het platform waar het ticket vandaan komt, en eventuele eerder aangebrachte verrijking vanuit vorige runs.

Opgehaalde kennis. Welke kennisbankartikelen of known-error-entries de agent opvroeg, wat de zoekopdracht was, welke resultaten terugkwamen, en welke confidence-score de ophaling toekende aan de beste resultaten. Als de agent een stuk kennis gebruikte in zijn redenering, hoort dat kennisitem bij naam in de log.

Elke beslissingsstap. Voor een typische triage-run kan dat zijn: categorie bepalen, prioriteit bepalen, controleren op een bestaande kennismatch, beslissen of een antwoord of escalatie volgt. Elke stap moet de invoer loggen die hij ontving, de uitvoer die hij produceerde, en de confidence-score voor die uitvoer.

De genomen actie. Wat de agent daadwerkelijk deed: een antwoord stuurde, een interne notitie plaatste, het ticket toewees, escaleerde, of geen actie ondernam omdat de confidence onder de drempel lag. Als hij geen actie ondernam, moet de log aangeven waarom.

Escalatiereden indien van toepassing. Wanneer de agent overdraagt aan een mens, moet de reden expliciet zijn: confidence onder drempel bij de categorie, lage confidence op de kennismatch, sentimentsignaal boven de geconfigureerde limiet, of een harde mens-alleen-regel voor het gevraagde actietype.

Looptijd en uitkomst. Totale tijd, of de run normaal voltooide of werd onderbroken, en eventuele fouten.

Dit is veel data per run. De vraag is altijd hoe je het toegankelijk opslaat. Het volledige run-record opslaan in een gestructureerd formaat gekoppeld aan het ticketidentificateur betekent dat je het kunt opvragen als er iets misgaat, het in de breedte kunt analyseren op patronen, en een samenvatting kunt tonen aan de afhandelende medewerker wanneer die het ticket bekijkt.

Confidence-scores: wat ze betekenen en wat je ermee doet

Confidence is de zelfbeoordeling van de agent over hoe zeker hij is van een beslissing. Een confidence-score van 0,9 op een categorie-toewijzing betekent dat de agent er vrij zeker van is. Een score van 0,4 betekent dat hij een beste gok heeft maar niet zeker is. Deze getallen zijn alleen zinvol als je ze kunt calibreren aan uitkomsten: betekent 0,9 daadwerkelijk dat de categorie 90% van de tijd juist is?

Calibratie vindt plaats over tijd naarmate je de opgegeven confidence van de agent vergelijkt met of zijn beslissingen klopten. Als de agent 0,9 confidence zegt op categorie en 85% van de tijd gelijk heeft, is de calibratie redelijk. Als hij 0,9 zegt en 60% van de tijd gelijk heeft, zijn de confidence-scores opgeblazen en moeten je drempels aangepast worden.

Dit is waarom het run-log confidence op elke stap moet vastleggen, niet alleen bij de uiteindelijke actie. De confidence bij de uiteindelijke actie is de score die escalatie triggert. Maar tussenliggende confidence, bijvoorbeeld lage confidence bij het ophalen van kennis gevolgd door hoge confidence op het antwoord, is een signaal dat het antwoord slecht gefundeerd kan zijn ook al was de agent bereid het te sturen.

Praktisch drempelbeheer ziet er zo uit: zet een initieel conservatieve drempel. Bekijk de run-logs na twee weken. Zoek de verdeling van confidence-scores en waar correcte versus incorrecte beslissingen clusteren. Pas de drempel aan tot een punt waar het incorrecte beslissingspercentage daalt naar een niveau dat je accepteert. Doe dit opnieuw na de volgende categorie tickets die instroomt.

Meer over de werking van toezichtsdrempels staat in wanneer AI moet overdragen aan een mens.

Shadow mode als eerste fase van observability

Voordat je drempels wilt bijstellen op een actieve agent, heb je een nulmeting nodig: wat zou de agent hebben gedaan bij echte tickets, en hoe vaak zou hij gelijk hebben gehad?

Shadow mode lost dit op. In shadow mode verwerkt de agent tickets en schrijft zijn beslissingen, voorgestelde acties en confidence-scores als interne notities in plaats van actie te nemen. Het ticket wordt door mensen afgehandeld zoals gewoonlijk. De shadow-notitie staat naast het ticket ter vergelijking.

Na een periode in shadow mode heb je een dataset: voor elk ticket dat de agent zag, weet je wat hij zou hebben gedaan, met welke confidence, en wat de mens daadwerkelijk deed. Die vergelijking vertelt je waar de agent het eens is met je team (en wat je dus veilig zou kunnen automatiseren), waar hij het oneens is maar het team het ermee eens is dat de aanpak van de agent prima was (configuratieprobleem), en waar hij het oneens is op manieren die echte problemen hadden veroorzaakt.

Shadow mode is ook de juiste startpositie voor een nieuw agenttype of een nieuwe ticketcategorie. Als je een nieuw product toevoegt aan je servicecatalogus en wilt dat de AI tickets in die categorie afhandelt, begin dan in shadow mode op die categorie specifiek. Ga naar actief zodra de shadow-prestaties voldoen aan de drempel die je hebt gesteld. De volledige aanpak staat in AI uitrollen in shadow mode.

Confidence per kennisitem, niet alleen per actie

Een specifiek observability-gat dat in de praktijk problemen veroorzaakt: de confidence-score op de uiteindelijke actie combineert de confidence van de redenering met de confidence van de kennis waarop de redenering was gebaseerd.

Stel: de agent haalt een kennisartikel op over een procedure voor wachtwoordherstel. De ophaalconfidence is 0,95 omdat het ticket duidelijk overeenkomt. De agent krijgt vervolgens de opdracht een antwoord te schrijven op basis van dat artikel. Hij kent hoge confidence toe aan het antwoord. Maar als het kennisartikel verouderd is (de procedure is vorige maand gewijzigd), zal het antwoord onjuist zijn ondanks hoge confidence op elke stap.

Het apart loggen van de confidence van de kennisophalingstap versus de confidence van de antwoordstap laat je dit patroon identificeren. Als de ophaalconfidence hoog is maar de kwaliteit van het antwoord laag, heb je een nauwkeurigheidsprobleem in de kennisbank. Als de ophaalconfidence laag is maar de agent toch handelde, heb je een drempelprobleem.

Dit sluit aan op waarom hallucinations bij de servicedesk vaak een kennisbankprobleem zijn in plaats van een modelprobleen, verder uitgewerkt in AI-hallucinations bij de servicedesk.

Wat je in de praktijk doet met observability-data

Zodra je een run-log per ticket hebt, worden meerdere praktische operaties mogelijk:

Foutonderzoek. Wanneer een gebruiker een klacht escaleert over een onjuist AI-antwoord, open je het run-record en volgt precies welke kennis de agent gebruikte, welke confidence hij had, en wat hij las. Dat is een onderzoek van vijf minuten in plaats van een halve dag.

Drempelcalibratie. Exporteer de verdeling van confidence-scores per actietype, vergelijk met uitkomstkwaliteit, en stel drempels in op basis van bewijs in plaats van gevoel. Doe dit per kwartaal of na een significante wijziging in je kennisbank of ticketmix.

Detectie van kennisbankgaten. Waar haalt de agent consistent lage-confidence-matches op of helemaal geen match? Die onderwerpen zijn je kennisbankgaten. Artikelen toevoegen op die gebieden verbetert de agentprestaties voordat je ook maar een drempel aanraakt.

Agentprestaties vergelijken. Als je meerdere agentconfiguraties runt, of voor verschillende ticketcategorieen, platforms, of het testen van een configuratiewijziging, laten per-run-confidence-logs je ze op een gemeenschappelijke schaal vergelijken.

Audit voor gereguleerde omgevingen. In sommige omgevingen, met name die persoonsgegevens of gereguleerde diensten verwerken, is het kunnen aantonen dat een AI een specifieke actie uitvoerde, op welke basis, en met welk toezichtmechanisme aanwezig, een compliancevereiste. Een gestructureerde log per run voldoet hieraan waar een algemene "we gebruiken AI"-uitspraak dat niet doet. Hoe ITSM Autopilot omgaat met gegevensverwerking en auditcontroles staat op de beveiligingspagina.

Wat escalatielogs moeten vastleggen

Escalatie is het moment waarop observability de meeste directe waarde heeft, want het is het moment waarop het systeem de controle expliciet overdraagt aan een mens. De escalatielog moet vastleggen:

• Welke stap in de run de escalatie triggerde
• De confidence-score op dat punt en de geconfigureerde drempel
• Of de escalatie werd veroorzaakt door confidence, een harde regel (actietype is mens-alleen), of een sentimentsignaal
• De tekst waarmee de agent aan het werk was op het moment dat hij stopte
• Welke interne notitie (indien aanwezig) de agent achterliet voor de afhandelende mens

Dat laatste punt telt. Een agent die escaleert en een gestructureerde privaat-notitie achterlaat die samenvat wat hij vond, wat hij van plan was te doen, en waarom hij stopte, is nuttiger dan een agent die het ticket simpelweg teruglegt in de wachtrij zonder context. De mens pakt een ticket op met een vooronderzoek al gedaan, geen koude start.

Observability-data nuttig houden over tijd

Run-logs stapelen snel op in een servicedesk-omgeving. De risico's: te veel data om nuttig doorzoekbaar te zijn, logs zo groot dat ze de hoofdapplicatie vertragen, en logs die technisch aanwezig zijn maar nooit daadwerkelijk geraadpleegd worden.

Praktische keuzes die helpen:

Bewaar run-logs apart van het hoofdticketrecord maar gekoppeld aan het ticketidentificateur. Het opvragen van de volledige log voor onderzoek verschilt van het tonen van het ticket aan een medewerker, en de opslag- en toegangspatronen moeten dat weerspiegelen.

Vat samen voor de afhandelende medewerker. De volledige run-log is voor onderzoek en calibratie. Wat een medewerker op het ticket ziet, moet een korte samenvatting zijn: wat de AI deed, met welke confidence, en de kernkennisreferentie die hij gebruikte. Het detail is een klik verder.

Stel een retentiebeleid in. Gedetailleerde run-logs voor 90 dagen met samenvattingsrecords die langer worden bewaard is een redelijk startpunt. Pas aan op basis van hoe vaak je logs van meer dan 90 dagen oud daadwerkelijk gebruikt voor onderzoek versus calibratie.

Markeer lage-confidence-runs voor beoordeling in plaats van ze identiek op te slaan aan hoge-confidence-runs. Als 20% van de runs confidence onder 0,5 heeft op een belangrijke stap, zijn dat de runs die het waard zijn om steekproefsgewijs te beoordelen op kwaliteit, niet de hoge-confidence-runs die vrijwel zeker het juiste resultaat produceerden.

Veelgestelde vragen

Wat is AI-agent observability bij de servicedesk?

Het is een overzicht per run van wat een AI-agent besliste, op welke basis, met welke confidence, en welke actie hij nam of naliet. Het dekt het volledige redeneerproces voor een enkel ticketevent, niet alleen de uiteindelijke uitkomst.

Waarom is confidence-logging nuttiger dan nauwkeurigheid-logging?

Nauwkeurigheid-logging vertelt je achteraf dat de agent goed of fout zat. Confidence-logging vertelt je vooraf hoe zeker de agent was. Samen laten ze je calibreren: voorspelt hoge confidence daadwerkelijk juistheid voor jouw ticketmix? Die calibratie is hoe je drempels instelt die in de praktijk werken.

Geeft shadow mode je observability-data?

Ja. Shadow mode is de helderste vorm van observability omdat de agent alles wat hij zou hebben gedaan schrijft als zichtbaar record, waarna een mens het echte werk doet. De twee vergelijken is de puurste vorm van calibratie. Actieve agents met run-logs bieden observability op live beslissingen in plaats daarvan.

Hoe gedetailleerd moet het run-log zijn?

Genoeg om "waarom deed de agent dat?" te beantwoorden voor elke individuele run, en genoeg om geaggregeerde analyse te doen op confidence-verdelingen en kennisophaalpatronen over veel runs heen. Het volledige redeneerspoor is niet altijd nodig voor elk ticket, maar het moet reconstrueerbaar zijn uit de log wanneer dat nodig is.

Wanneer moet ik confidence-drempels aanpassen?

Na het bekijken van de verdeling van uitkomsten versus confidence-scores over minimaal een paar honderd runs. Niet direct na een enkele slechte uitkomst (te weinig data), en ook niet nooit (drempels ingesteld op dag een passen mogelijk niet bij de ticketmix die je op maand drie daadwerkelijk ziet). Kwartaalreview is een redelijke standaard.

Echte service door echte mensen. Het werk van de machine moet controleerbaar zijn. Observability is hoe je dat regelt.