AI-agent monitoring en logging

AI-agent monitoring en logging geven organisaties zicht op wat een agent doet nadat deze in gebruik is genomen.

Testen vóór ingebruikname blijft noodzakelijk, maar kan niet iedere praktijksituatie voorspellen. Door prestaties, fouten, acties, goedkeuringen, kosten en afwijkingen doorlopend te volgen, kan een organisatie sneller ingrijpen wanneer een agent anders handelt dan verwacht.

Waarom monitoring nodig blijft na het testen

Een testomgeving bevat maar een selectie van mogelijke opdrachten, gebruikers en omstandigheden. In productie kunnen nieuwe documenten, afwijkende invoer, veranderde systemen en onverwachte combinaties van taken ontstaan. Ook kan het gedrag veranderen door een nieuwe modelversie, aangepaste prompt, gewijzigde rechten of een andere kennisbron.

• fouten kunnen pas zichtbaar worden bij grotere aantallen taken
• gebruikers kunnen de agent anders inzetten dan tijdens de pilot
• bronnen, modellen en gekoppelde systemen veranderen na verloop van tijd
• een kleine afwijking kan zich over meerdere vervolgstappen verspreiden
• misbruik of promptinjectie kan pas in echte gegevensstromen optreden
• kosten en belasting kunnen sterk stijgen door herhalingen of vastlopende taken

Monitoring is daarom geen vervanging van testen, maar een aanvullende controle tijdens het dagelijkse gebruik. Lees ook AI-agents testen.

Verschil tussen monitoring, logging en het agentregister

Koppel deze onderdelen aan elkaar. Een waarschuwing uit monitoring moet terug te voeren zijn op concrete logregels en op de juiste agentversie in het AI-agentregister.

Bepaal vooraf wat je wilt kunnen zien

Begin niet met het verzamelen van zoveel mogelijk gegevens. Bepaal eerst welke vragen de organisatie bij normaal beheer, fouten en incidenten moet kunnen beantwoorden.

• Welke agentversie voerde de taak uit?
• Welke gebruiker, toepassing of andere agent startte de opdracht?
• Welke bronnen, hulpmiddelen en systemen werden gebruikt?
• Welke actie werd voorgesteld, goedgekeurd, afgewezen of uitgevoerd?
• Welke beleidsregel, grenswaarde of toegangscontrole werd toegepast?
• Waar ontstond een fout en welke vervolgstappen zijn daarna gezet?
• Kan de volledige taak worden gereconstrueerd zonder onnodige gevoelige inhoud te bewaren?

Volg resultaten, fouten en afgebroken taken

De meest basale monitoring laat zien hoeveel taken worden gestart en hoe deze eindigen. Maak onderscheid tussen een correct afgeronde taak, een taak met menselijke correctie, een technische fout, een blokkering en een vrijwillig afgebroken taak.

• percentage succesvol afgeronde taken
• aantal fouten per taaktype, systeem en agentversie
• taken die door gebruikers of beheerders worden gestopt
• taken die door een veiligheidsregel of limiet worden geblokkeerd
• herhaalde pogingen na dezelfde fout of afwijzing
• taken waarvoor menselijke overname nodig was

Een stijgend succespercentage is niet automatisch positief. Controleer ook of de agent taken ten onrechte als afgerond markeert, belangrijke controles overslaat of ongewenste acties uitvoert.

Volg plannen, tussenstappen en hulpmiddelen

Bij een AI-agent is het eindresultaat vaak onvoldoende om te begrijpen wat er is gebeurd. Leg daarom op een passende manier vast welke tussenstappen zijn gekozen en welke hulpmiddelen zijn aangeroepen.

• gekozen taakroute of processtappen
• naam en versie van gebruikte hulpmiddelen
• doel van iedere toolaanroep
• doelsysteem en type bewerking, bijvoorbeeld lezen, schrijven of verwijderen
• genormaliseerde parameters, zonder onnodige gevoelige inhoud
• resultaat, foutcode en duur van de aanroep

Het is meestal niet nodig of wenselijk om interne redeneerstappen van het taalmodel woordelijk op te slaan. Leg liever gestructureerde beslisinformatie vast, zoals gekozen actie, toegepaste beleidsregel, risicocategorie, goedkeuringsstatus en uitvoeringsresultaat.

Registreer systeemacties en externe communicatie

Acties met gevolgen buiten de agentomgeving verdienen extra aandacht. Leg voldoende informatie vast om te zien wie of wat de actie veroorzaakte, wat er veranderde en of herstel mogelijk is.

• verzonden berichten, meldingen en documenten
• aangemaakte, gewijzigde of verwijderde records
• bestellingen, betalingen of andere financiële handelingen
• wijzigingen aan accounts, rollen en toegangsrechten
• uitgevoerde scripts, workflows en beheeracties
• status van terugdraaien, herstellen of annuleren

Gebruik bij belangrijke acties een uniek actie-ID en leg de exacte bestemming, parameters, goedkeuring en uitkomst vast. Zo kan worden voorkomen dat dezelfde actie na een time-out of herhaling dubbel wordt uitgevoerd.

Leg menselijke goedkeuringen en correcties vast

Menselijke controle is alleen aantoonbaar wanneer zichtbaar is welke informatie de beoordelaar zag, wat werd besloten en op welke concrete actie de goedkeuring betrekking had.

• identiteit en rol van de beoordelaar
• tijdstip van aanbieden en besluit
• exacte actie, bestemming en relevante parameters
• goedkeuring, afwijzing, aanpassing of doorverwijzing
• geldigheidsduur en eventuele voorwaarden
• uiteindelijke uitvoeringsstatus

Monitor ook opvallende patronen, zoals vrijwel automatische goedkeuringen, veel afwijzingen bij één taaktype of herhaalde pogingen om een afgewezen actie opnieuw aan te bieden.

Monitor toegang en pogingen om grenzen te overschrijden

Een agent kan proberen een bron, hulpmiddel of systeem te gebruiken waarvoor geen toestemming bestaat. Ook misleidende invoer kan proberen de agent tot een onbevoegde handeling te bewegen.

• geweigerde toegang tot gegevens, hulpmiddelen en systemen
• gebruik van verhoogde of afwijkende rechten
• pogingen om een andere technische identiteit te gebruiken
• aanvragen buiten het toegestane proces of gebruikersdomein
• herhaalde pogingen na een blokkering
• wijzigingen aan beleidsregels, rechten of goedkeuringsgrenzen

Lees voor de inrichting ook Bevoegdheden van AI-agents, AI-agent identiteiten en toegangsbeheer en AI agentbeveiliging.

Volg kosten, looptijd en herhalingen

Een agent kan vastlopen in een lus, steeds opnieuw hetzelfde hulpmiddel aanroepen of grote hoeveelheden rekenkracht gebruiken. Financiële en operationele monitoring zijn daarom ook veiligheidsmaatregelen.

• aantal model- en toolaanroepen per taak
• gebruikte tokens, rekentijd en kosten per sessie
• totale doorlooptijd en wachttijd per processtap
• aantal herhalingen en mislukte pogingen
• plotselinge stijging in gelijktijdige taken
• overschrijding van vooraf ingestelde budgetten of limieten

Stel harde grenzen in voor maximale stappen, tijd, kosten en aantallen acties. Laat de agent automatisch pauzeren wanneer een grens wordt bereikt, in plaats van alleen achteraf een melding te tonen.

Herken afwijkend gedrag en kwaliteitsverlies

Afwijkend gedrag betekent niet altijd een aanval. Het kan ook wijzen op een gewijzigde bron, een nieuwe gebruikersgroep, een modelupdate of een fout in een koppeling. Vergelijk daarom actuele patronen met een bruikbare uitgangssituatie.

• plotseling meer fouten of menselijke correcties
• ongebruikelijke keuze van hulpmiddelen of procesroutes
• toename van geweigerde toegangsverzoeken
• meer risicovolle of onomkeerbare acties
• afname van bronkwaliteit of herleidbaarheid
• veranderde verdeling van goedkeuringen en afwijzingen
• opvallende verschillen tussen teams, klanten of tijdsperioden

Gebruik niet één algemene kwaliteitsscore als enige signaal. Combineer inhoudelijke kwaliteit, procesgedrag, veiligheid, kosten en menselijke feedback.

Welke gebeurtenissen horen in een auditlog?

Een auditlog is bedoeld om achteraf te kunnen reconstrueren wie of wat een relevante handeling uitvoerde. Gebruik gestructureerde logvelden zodat gebeurtenissen betrouwbaar kunnen worden gefilterd en gekoppeld.

• datum, tijd en betrouwbare tijdzone
• agent-ID, configuratieversie en omgeving
• taak-, sessie- en correlatie-ID
• gebruiker, aanroepende toepassing of andere agent
• gebeurtenistype en risicocategorie
• tool, doelsysteem en type actie
• autorisatie- en goedkeuringsresultaat
• uitkomst, foutcode en herstelstatus
• toegepaste beleids- en regelversie

Leg bij acties met een hoger risico meer context vast dan bij eenvoudige leesacties. Gebruik een risicogestuurde aanpak, zodat de log bruikbaar blijft zonder alles onbeperkt te bewaren.

Koppel alle stappen met een correlatie-ID

Eén gebruikersopdracht kan leiden tot meerdere modelaanroepen, zoekacties, goedkeuringen en systeemwijzigingen. Geef de volledige taak één correlatie-ID en iedere vervolgstap een eigen gebeurtenis-ID.

• de volledige keten kan in juiste volgorde worden bekeken
• dubbele acties en herhalingen worden sneller zichtbaar
• informatie uit verschillende systemen kan worden samengebracht
• een incident kan worden afgebakend tot betrokken taken en gebruikers
• meerdere agents in dezelfde taak blijven van elkaar te onderscheiden

Bescherm logs tegen verwijderen en manipulatie

Logs verliezen hun waarde wanneer de agent of een gewone beheerder ze ongemerkt kan aanpassen. Beperk schrijfrechten en zorg dat belangrijke gebeurtenissen naar een afzonderlijke, beveiligde omgeving worden gestuurd.

• laat de agent alleen logregels toevoegen, niet wijzigen of verwijderen
• scheid operationeel beheer van beheer van auditlogs
• gebruik integriteitscontroles en betrouwbare tijdstempels
• beveilig transport en opslag van loggegevens
• monitor wijzigingen aan loggingconfiguratie en bewaartermijnen
• test regelmatig of logs werkelijk beschikbaar en doorzoekbaar zijn

Voorkom dat logs een nieuw gegevensrisico worden

Prompts, documenten, foutmeldingen en toolparameters kunnen persoonsgegevens, bedrijfsgeheimen, toegangstokens of andere vertrouwelijke informatie bevatten. Volledige opslag van alle invoer en uitvoer is daarom vaak onnodig en riskant.

• log alleen gegevens die nodig zijn voor een duidelijk doel
• verwijder of maskeer wachtwoorden, tokens en andere geheimen
• gebruik waar mogelijk categorieën, hashes of technische verwijzingen
• beperk volledige inhoud tot specifieke fout- of onderzoeksgevallen
• scheid logs per klant, afdeling, gebruiker en omgeving
• controleer of leveranciers loggegevens voor eigen doeleinden gebruiken

Stem logging af op de afspraken voor AI-agent geheugen en gegevensgebruik.

Beperk toegang tot logs

Omdat logs gevoelige informatie en beveiligingsdetails kunnen bevatten, mag niet iedere gebruiker of ontwikkelaar alle loggegevens bekijken.

• operationele teams zien informatie die nodig is voor dagelijks beheer
• securityteams krijgen toegang tot beveiligings- en incidentgegevens
• privacy- en compliancefuncties kunnen relevante controles uitvoeren
• leveranciers zien alleen gegevens binnen hun afgesproken verantwoordelijkheid
• toegang tot gevoelige logs wordt zelf ook gelogd en gecontroleerd

Bepaal bewaartermijnen per logsoort

Niet iedere logregel hoeft even lang te worden bewaard. Stem de termijn af op operationeel herstel, beveiligingsonderzoek, verantwoording, contractuele afspraken en wettelijke verplichtingen.

• korte termijn voor gedetailleerde technische foutinformatie
• langere termijn voor belangrijke goedkeuringen en systeemacties
• afzonderlijke termijn voor beveiligingsincidenten en onderzoeken
• verwijdering of anonimisering wanneer het doel vervalt
• behoud van noodzakelijke samenvattingen zonder volledige inhoud

Leg bewaartermijnen, uitzonderingen en verantwoordelijke eigenaren vast. Controleer ook of kopieën, exports en back-ups volgens dezelfde afspraken worden verwijderd.

Werk met waarschuwingen en automatische grenzen

Een dashboard dat alleen achteraf wordt bekeken, is onvoldoende voor risicovolle acties. Stel waarschuwingen en automatische maatregelen in voor situaties die snel ingrijpen vereisen.

Maak duidelijk wie een melding ontvangt, binnen welke termijn wordt gereageerd en wie toestemming geeft om de agent opnieuw te activeren.

Blijf zelf controleren bij leveranciers

Een leverancier kan technische monitoring leveren, maar de organisatie blijft verantwoordelijk voor het eigen proces, de eigen gebruikers en de gevolgen van de agent.

• welke gebeurtenissen en metingen levert de leverancier?
• kan de organisatie ruwe of gestructureerde logs exporteren?
• hoe snel worden incidenten, uitval en modelwijzigingen gemeld?
• waar worden loggegevens opgeslagen en verwerkt?
• welke gegevens zijn niet zichtbaar voor de organisatie?
• blijven logs beschikbaar na contractbeëindiging?

Voorkom dat kritieke monitoring volledig afhankelijk is van één leveranciersdashboard dat geen export, historie of eigen waarschuwingen ondersteunt.

Maak dashboards gericht op beslissingen

Een dashboard hoeft niet iedere technische meting te tonen. Richt schermen in rond de vragen en verantwoordelijkheden van verschillende gebruikers.

• Proceseigenaar: kwaliteit, gebruik, menselijke correcties en gevolgen voor het proces
• Technisch beheer: fouten, prestaties, koppelingen, versies en capaciteit
• Security: afwijkende toegang, misbruiksignalen en risicovolle acties
• Privacy en compliance: gegevensgebruik, bewaartermijnen en aantoonbaarheid
• Management: risico, kosten, incidenten en openstaande maatregelen

Toon trends, grensoverschrijdingen en uitzonderingen. Een groot aantal losse grafieken zonder duidelijke actie maakt toezicht juist moeilijker.

Gebruik rapportages voor periodieke herbeoordeling

Dagelijkse monitoring ondersteunt direct beheer. Periodieke rapportages helpen beoordelen of de agent nog binnen het oorspronkelijke doel, risicoprofiel en goedgekeurde grenzen werkt.

• ontwikkeling van kwaliteit, fouten en menselijke correcties
• wijzigingen in gebruik, gebruikersgroepen en taakvolume
• risicovolle acties, blokkeringen en incidenten
• kosten, capaciteit en operationele belasting
• model-, prompt-, bron- en toolwijzigingen
• effectiviteit van goedkeuringen en andere controles
• openstaande beperkingen en geaccepteerde resterende risico’s

Gebruik deze informatie binnen AI-agent governance om te besluiten of de agent mag doorgaan, moet worden aangepast of tijdelijk moet worden beperkt.

AI Act en logging

De Europese AI Act bevat voor hoogrisico-AI-systemen specifieke eisen rond automatische logging en traceerbaarheid. Logs moeten bij zulke systemen onder meer kunnen bijdragen aan het herkennen van risicosituaties, monitoring na ingebruikname en toezicht op de werking.

Deze eisen gelden niet automatisch voor iedere AI-agent. De juridische kwalificatie hangt af van de toepassing, het beoogde doel en de rol van de organisatie. Ook wanneer een agent niet onder deze specifieke verplichtingen valt, kan passende logging nodig zijn voor beveiliging, beheer, privacy, contractuele afspraken en interne verantwoording.

Praktische voorbeelden

Checklist voor monitoring en logging

Monitoring en logging leveren pas waarde wanneer signalen tot concrete actie leiden. Leg daarom niet alleen vast wat wordt gemeten, maar ook wie onderzoekt, wie mag ingrijpen en onder welke voorwaarden een agent opnieuw wordt geactiveerd.

Verder binnen deze kennisbank

Bronnen en verdere verdieping

• OWASP, AI Agent Security Cheat Sheet
• NIST, AI Risk Management Framework Core
• NIST, AI Risk Management Framework Playbook
• Europese Commissie, AI Act artikel 12 over logging