10 juni 2026

Observability, logs en audit trails voor AI, kun je terugzien wat er gebeurde?

Een klant belt. De AI-assistent heeft haar verteld dat ze recht heeft op een vergoeding die niet bestaat. Ze heeft een screenshot. Het team gaat zoeken: welke vraag stelde ze precies, welke documenten haalde het systeem erbij, welk model draaide er die dag, en wat was het volledige antwoord?

Niemand weet het. Er is geen log van het gesprek. De prompt is weg, de opgehaalde context is weg, en het model is vorige week stilletjes geüpdatet naar een nieuwe versie. Het enige bewijs van wat er gebeurde is het screenshot van de klant.

Dit is geen verzonnen rampscenario. Dit is de standaardsituatie bij het grootste deel van de AI-toepassingen die ik tegenkom. Er is wel monitoring op de server (draait hij, is hij snel genoeg), maar niemand kan reconstrueren wat de AI inhoudelijk deed en waarom.

En dat is een probleem. Niet alleen als er iets misgaat, maar ook als je gewoon wilt weten of je systeem beter wordt of slechter.

Waarom dit nu speelt

Bij gewone software is logging een opgelost probleem. Een betaling die misloopt kun je terugvinden: welk verzoek, welke response, welke foutcode. Het systeem is deterministisch, dus dezelfde input geeft dezelfde output, en de foutmelding zegt meestal waar het zat.

AI-systemen zijn anders. Hetzelfde verzoek kan vandaag een ander antwoord geven dan gisteren. Het antwoord hangt af van de prompt, de opgehaalde documenten, de systeeminstructies, de modelversie en soms gewoon van toeval, want taalmodellen zijn niet volledig voorspelbaar. Als je alleen logt dat er "een request" was, kun je achteraf niks reconstrueren.

Tegelijk wordt de vraag om verantwoording groter. Een functionaris gegevensbescherming wil weten welke data het systeem verwerkt. Een toezichthouder kan vragen hoe een besluit tot stand kwam. De AI Act stelt voor hoog-risico AI-systemen expliciet eisen aan logging en traceerbaarheid. En je eigen organisatie wil bij een klacht gewoon kunnen terugkijken wat er is gebeurd.

De gebruiker ziet alleen het antwoord. De organisatie moet de hele dataflow kunnen terugzien. Dat is wat observability voor AI betekent.

Wat je wilt loggen

Het denkmodel is simpel: log alles wat je nodig hebt om één interactie volledig te reconstrueren. In de praktijk zijn dat zes dingen.

De input van de gebruiker. De letterlijke vraag of opdracht, plus wie hem stelde (of in elk geval een pseudoniem of sessie-id) en wanneer.

De volledige prompt die naar het model ging. Dit is iets anders dan de gebruikersvraag. Tussen de vraag en het model zit meestal een laag die systeeminstructies toevoegt, gespreksgeschiedenis meestuurt en context erbij plakt. Als je alleen de gebruikersvraag logt, mis je het grootste deel van wat het model daadwerkelijk zag.

De opgehaalde context. Bij RAG-systemen: welke documenten of fragmenten werden gevonden en meegestuurd. Dit is vaak de plek waar het misgaat. Het model verzon de vergoeding uit het voorbeeld misschien niet, maar haalde hem uit een verouderd document dat nooit uit de kennisbank was verwijderd. Zonder log van de opgehaalde fragmenten kom je daar nooit achter.

De modelversie en de instellingen. Welk model, welke versie, welke temperatuur, welke parameters. Modelproviders vervangen versies regelmatig, en een nieuwe versie kan zich anders gedragen op precies jouw taken. Als je niet logt welke versie het antwoord gaf, kun je een gedragsverandering nooit aan een modelwissel koppelen.

Het volledige antwoord. Niet alleen "succes" of "fout", maar de letterlijke tekst die terugkwam, inclusief eventuele weigering of afgekapt antwoord.

Tool-aanroepen. Dit wordt steeds belangrijker. Zodra een AI-systeem agents of tools gebruikt (zoeken, mailen, een record aanpassen, een API aanroepen), wil je per stap weten: welke tool, met welke parameters, en wat kwam er terug. Een agent die drie acties uitvoert om tot een antwoord te komen, heeft drie logregels nodig, niet één. Juist bij agents is de audit trail je enige manier om achteraf te zien wat het systeem in jouw naam heeft gedaan.

Daarnaast wil je de gewone operationele dingen: latency, tokenverbruik, kosten, foutcodes. Die heb je nodig voor budget en performance, maar ze vertellen je niks over de inhoud.

Het ongemakkelijke spanningsveld: je logs zijn zelf gevoelige data

En hier wordt het interessant. Want als je dit allemaal logt, heb je een nieuw probleem gecreëerd.

Een goede AI-log bevat per definitie wat gebruikers aan het systeem vroegen en wat het systeem terugzei. Bij een interne assistent betekent dat: vragen van medewerkers over reorganisaties, salarissen, conflicten. Bij een klantenservicebot: namen, klantnummers, klachten, soms medische of financiële details. Bij een RAG-systeem komen daar fragmenten uit interne documenten bij.

Je audit trail is dus zelf een verzameling gevoelige gegevens, en daarmee een verwerking onder de AVG. De logging die je aanlegt om verantwoording te kunnen afleggen, is tegelijk een datalek in wording als je hem verkeerd inricht. Dit is geen juridisch advies, maar wel een technische realiteit.

Drie vragen helpen om dit hanteerbaar te maken.

Waar staan de logs? Als je applicatie netjes op Europese infrastructuur draait maar je logging- en tracingtool stuurt elke prompt naar een Amerikaanse SaaS-dienst, heb je je dataflow alsnog uit handen gegeven. De logs verdienen dezelfde afweging als de data zelf: waar staan ze, onder wiens recht, wie kan erbij.

Hoe lang bewaar je ze? Niet alles hoeft even lang bewaard. Een werkbare aanpak is om lagen aan te brengen. Volledige interacties (prompt, context, antwoord) bewaar je kort, bijvoorbeeld dertig tot negentig dagen, lang genoeg om incidenten te onderzoeken. Metadata zonder inhoud (tijdstip, modelversie, tokens, kosten, foutcodes) kun je veel langer houden, want daar zit nauwelijks privacyrisico in. En voor specifieke gevallen, zoals een incident of een klacht, bevries je de betrokken logs apart zolang het onderzoek loopt. Welke termijnen passend zijn hangt af van je context en eventuele wettelijke eisen, dus leg dit naast je privacyjurist.

Wie mag erin kijken? Een log waarin elke vraag van elke medewerker staat, is geen tool die je openzet voor het hele team. Inzage in volledige interacties hoort bij een kleine groep met een duidelijke reden: incidentonderzoek, kwaliteitscontrole, een klacht. Geaggregeerde dashboards (aantallen, kosten, foutpercentages, tevredenheidsscores) kunnen breed beschikbaar zijn. En log wie de logs inzag, want toegang tot de audit trail hoort zelf in de audit trail.

Wat ook helpt: gevoelige velden maskeren waar het kan. Klantnummers, BSN-achtige patronen en e-mailadressen kun je bij het wegschrijven al vervangen door placeholders. Dat maakt het onderzoek soms iets lastiger, maar verkleint de schade als de logs zelf ooit op straat liggen.

Van terugkijken naar vooruitkomen: logs als basis voor evaluatie

Tot nu toe ging het over verantwoording: kunnen reconstrueren wat er gebeurde. Maar dezelfde logs zijn ook het antwoord op een vraag die bijna elke organisatie met AI in productie heeft en bijna niemand kan beantwoorden: worden onze antwoorden eigenlijk beter of slechter?

Je past een prompt aan. Je wisselt van model omdat het nieuwe goedkoper is. Je voegt documenten toe aan de kennisbank. Elke wijziging kan het systeem beter maken op de plek waar je keek en slechter op tien plekken waar je niet keek. Zonder meting is elke wijziging een gok.

Het pad van logs naar evaluatie ziet er in de praktijk zo uit.

Eerst verzamel je signalen. Expliciete feedback, zoals een duimpje omhoog of omlaag bij een antwoord. Impliciete signalen, zoals een gebruiker die het antwoord meteen herformuleert (de vraag was blijkbaar niet beantwoord), een gesprek dat naar een menselijke medewerker escaleert, of een gegenereerde tekst die volledig wordt herschreven voor verzending. Die signalen koppel je aan de gelogde interactie.

Dan bouw je uit je logs een testset. Pak honderd tot tweehonderd echte vragen uit productie, geanonimiseerd, met daarbij wat een goed antwoord zou zijn. Dat vaststellen is mensenwerk en het is saai werk, maar het is de meest waardevolle dataset die je AI-team kan hebben, want hij beschrijft wat jouw gebruikers echt vragen, niet wat de leverancier in de demo liet zien.

Vervolgens draai je die testset bij elke wijziging opnieuw. Nieuwe prompt, nieuw model, nieuwe kennisbank: eerst de testset erdoorheen, scores vergelijken, dan pas live. Beoordelen kan deels automatisch, bijvoorbeeld door een tweede model de antwoorden te laten vergelijken met het referentieantwoord, met steekproefsgewijs een mens die controleert of die beoordelingen kloppen. Softwareteams noemen dit regressietesten en doen het al decennia. Voor AI-systemen is het precies hetzelfde idee, alleen is "goed" hier geen groen vinkje maar een score.

Wie dit niet doet, merkt verslechtering pas via klagende gebruikers. Wie het wel doet, ziet het in een tabel voordat de wijziging live gaat. Bij Ployed is dit standaard onderdeel van elk productietraject geworden, niet omdat het leuk is, maar omdat we te vaak hebben gezien dat een "kleine promptaanpassing" een week later onverklaarbare klachten opleverde.

Het denkmodel

Samengevat in vijf vragen die je aan elke AI-toepassing in je organisatie kunt stellen:

1. Reconstructie. Kunnen we van één willekeurige interactie van vorige week de volledige keten terughalen: input, prompt, context, modelversie, tool-aanroepen, antwoord? 2. Locatie. Waar staan die logs, en is dat een plek die dezelfde toets doorstaat als de data zelf? 3. Retentie. Hoe lang bewaren we wat, en is dat een keuze of een toevallige standaardinstelling? 4. Toegang. Wie kan de inhoud van interacties inzien, en wordt die inzage zelf gelogd? 5. Evaluatie. Als we morgen het model of de prompt wijzigen, kunnen we dan vóór livegang meten of de antwoorden beter of slechter worden?

Vijf keer ja is zeldzaam. Maar elke vraag waar nu "nee" of "geen idee" op volgt, is een concreet punt voor de roadmap.

Tot slot

De demo is makkelijk. Productie is waar AI serieus wordt, en observability is misschien wel het duidelijkste verschil tussen die twee. Een demo hoeft alleen een goed antwoord te geven. Een productiesysteem moet kunnen laten zien wát het antwoordde, waaróm, en of het er over drie maanden nog steeds even goed in is.

Het mooie is dat dit geen exotische technologie vraagt. Loggen, bewaartermijnen, toegangsrechten en testsets zijn gewoon degelijk vakwerk. Het enige wat nieuw is, is dat je het ook op je AI-laag moet toepassen, op het moment dat je die bouwt en niet pas na het eerste incident.

Als er morgen een klant belt met een screenshot, wil je kunnen terugkijken. En als je volgende week de prompt aanpast, wil je kunnen meten. Allebei beginnen op dezelfde plek: bij logs die je bewust hebt ingericht.

↘︎ ALLE ARTIKELEN