Een chat-log is geen systeemstaat. Het is een transcript van een gesprek dat verloopt, een sessie die expireert, en context die verdwijnt zodra het venster sluit.
Toen ik AI-agenten dagelijks in productie begon te draaien, liep ik daar hard tegenaan. Een agent had iets veranderd, git toonde keurig welke regels, maar de vraag waar het op aankwam bleef onbeantwoord: welke agent besloot dit, op welk moment, met welk model, en waarom.
Die vraag kun je niet beantwoorden met chat-logs. Daarom bouwde ik een AI audit trail die niet leunt op het geheugen van een sessie, maar op een append-only ledger die elke actie vastlegt op het moment dat hij gebeurt.
Waarom chat-logs geen AI audit trail zijn
Het probleem zit niet in de modellen. Het zit in de bewijslast.
Git laat zien wat er veranderde. Een commit toont je de diff, de auteur, het tijdstip. Maar git weet niets van de redenering die eraan voorafging. Het registreert het resultaat, niet de beslissing.
De chat-log zou dat gat moeten dichten. Alleen is een chat-log vluchtig. Sessies verlopen, context-vensters lopen vol, en wat de agent "dacht" op het moment van handelen is een dag later weg. Er is geen lijn die loopt van AI-beslissing naar concrete actie.
Dat is precies het gat waar compliance over struikelt. Je kunt niet reconstrueren wie wat deed als je enige bron een gesprek is dat niet meer bestaat.
De oplossing: een append-only ledger als enige bron van waarheid
Mijn aanpak draait om een append-only NDJSON-ledger. NDJSON staat voor newline-delimited JSON: elke regel is op zichzelf een geldig JSON-object, en het bestand is simpelweg die regels onder elkaar.
Append-only betekent dat er alleen achteraan wordt bijgeschreven. Niets wordt overschreven, niets bewerkt. Eén regel per gebeurtenis: een dispatch die start, een taak die voltooit, een actie die faalt.
Ik noem zo'n regel een "receipt", een bonnetje. Net als een kassabon legt het vast wat er gebeurde op het moment dat het gebeurde, en het verdwijnt niet als het systeem herstart.
De ledger werkt met single-writer streams: per stroom schrijft maar één proces tegelijk. Dat voorkomt de race conditions die je krijgt als meerdere agenten door elkaar in hetzelfde bestand pompen, en het houdt de volgorde van gebeurtenissen betrouwbaar.
Deze keuze is dezelfde governance-familie als waar ik eerder over schreef in Glass Box Governance voor multi-agent AI: als je niet in een systeem kunt kijken, kun je het niet op schaal vertrouwen.
Wat een receipt precies vastlegt
Een receipt is alleen nuttig als het genoeg context draagt om er later iets mee te reconstrueren. Daarom bevat elk receipt twee blokken bewijslast.
Het eerste is provenance, de herkomst van de actie. Daarin staat de git SHA (de unieke vingerafdruk van de commit), de branch waarop gewerkt werd, een is_dirty-vlag die aangeeft of er onopgeslagen wijzigingen waren, en een samenvatting van de diff: welke bestanden veranderden, hoeveel regels erbij kwamen, hoeveel eruit gingen. Plus een timestamp.
Het tweede blok is de sessie-context: een session_id, welke terminal de actie uitvoerde, welk model draaide, en bij welke provider. Zo weet je niet alleen dát een agent iets deed, maar ook met welke motor en in welke context.
Hieronder een receipt zoals het in mijn ledger wegschrijft. Verzonnen waarden, maar exact het formaat dat ik gebruik:
{
"ts": "2026-06-12T14:03:21Z",
"event": "dispatch.complete",
"dispatch_id": "PR-118",
"task": "Refactor de factuur-parser naar het nieuwe schema",
"status": "ok",
"duration_s": 1623,
"provenance": {
"git_sha": "a91f4c2",
"branch": "feature/invoice-schema-v2",
"is_dirty": false,
"files_changed": 4,
"insertions": 212,
"deletions": 88
},
"session": {
"session_id": "s-20260612-1041",
"terminal": "T2",
"model": "claude-opus-4-8",
"provider": "claude-code"
}
}Eén regel JSON (hier uitgevouwen voor leesbaarheid) vertelt me het hele verhaal: welke taak, welk resultaat, op welke commit, door welk model. Geen chat-transcript nodig om dat te reconstrueren.
Crash recovery via ledger-replay
Hier wordt de keuze voor append-only concreet waardevol.
Als er iets misgaat tijdens een lange sessie, lees ik geen chat-transcripts terug. Ik speel de ledger af. Elke gebeurtenis staat er in volgorde, dus ik reconstrueer stap voor stap wat het systeem deed tot het punt waar het brak.
Omdat er nooit wordt overschreven, kan een crash de bestaande regels niet corrumperen. Een halve schrijfactie aan het einde van het bestand raakt de regels daarvoor niet. Het ergste wat je verliest is de laatste regel, en zelfs die is meestal nog leesbaar.
Dat is een eigenschap die een database je niet gratis geeft. Bij een database zit je vast aan een server die draait, migraties die kloppen, en een schema-versie die meebeweegt. Een platte tekstfile heeft niets van dat nodig om te herstellen.
Doorzoekbaar met grep, jq en tail, zonder cloud
Het tweede grote voordeel is dat ik geen speciale tooling nodig heb om de audit trail te bevragen.
Wil ik alles zien wat terminal T2 deed? Een grep op "terminal": "T2". Wil ik live meekijken terwijl een dispatch loopt? tail -f op de stream. Wil ik filteren op gefaalde acties en optellen hoeveel regels ze raakten? Dat is één jq-commando.
Dit zijn standaard Unix-tools die op elke machine al staan. Geen proprietary dashboard, geen vendor-UI, geen exportknop die je naar een externe partij stuurt.
En dat is meteen het derde voordeel: de receipts blijven lokaal. Ze gaan niet naar de cloud. Voor een MKB'er die met gevoelige data werkt, betekent dat de bewijslast je kantoor nooit verlaat. De audit trail is compliance-ready precies omdat hij niet ergens anders staat.
Dat lokaal-blijven is geen detail. De AI Act die vanaf augustus 2026 in werking treedt verwacht dat je logs van AI-systemen kunt overleggen en een periode kunt bewaren. Een ledger die je zelf in handen houdt en met standaard tools doorzoekt, is daar makkelijker op aan te tonen dan een verzameling verlopen chat-sessies bij een externe provider.
Wat de gangbare frameworks niet oplossen
Ik bouw dit niet omdat de bestaande frameworks slecht zijn. Ze zijn goed in wat ze doen.
LangGraph geeft je sterke graph-gebaseerde orchestratie. CrewAI levert rol-gebaseerde agent-teams. AutoGen biedt flexibele multi-agent-gesprekken. Alle drie lossen het orchestratie-probleem netjes op: hoe laat je meerdere agenten samenwerken.
Wat ik in geen van deze frameworks vond, is governance als first-class onderdeel. Audit trails, een doorzoekbare ledger, bewijslast die crashes overleeft, dat is iets wat je er zelf bij moet bouwen. Het zit niet ingebakken in de architectuur.
Mijn governance-framework, VNX Orchestration, draait die volgorde om. De ledger is niet een logbestand dat als bijproduct ontstaat. Het is de enige bron van waarheid waar de rest van het systeem omheen is gebouwd.
De bewijslast in cijfers
Dit is geen schets op een whiteboard. Ik draai dit dagelijks.
Over maanden gebruik heeft de ledger 2.800+ receipts vastgelegd, waarvan 1.466 dispatches getrackt van start tot voltooiing of falen. Elke regel is een gebeurtenis die ik achteraf kan terugvinden zonder een enkel chat-transcript te openen.
Het framework staat open source op github.com/Vinix24/vnx-orchestration. De receipt-schema's, de stream-opzet, de werkende code: allemaal in te zien. En de receipts zelf blijven lokaal, ze gaan niet mee naar GitHub of een cloud-dienst.
Dat is het verschil tussen een audit trail die je gelooft en een die je kunt aantonen.
Wat je minimaal zou moeten loggen als je AI in productie draait
Als je AI-agenten in productie hebt, of dat overweegt, is dit de ondergrens die ik zou aanhouden. Niet de hele VNX-architectuur, maar het minimum waarmee je achteraf nog een verhaal kunt reconstrueren.
Per actie van een agent leg je vast:
- Wat er gebeurde: het event-type en de taak in mensentaal.
- Wanneer: een timestamp in een eenduidig formaat (UTC, ISO 8601).
- Door wie: welke agent, welk model, welke provider.
- Waarop: de git SHA en branch, plus of er onopgeslagen wijzigingen waren.
- Met welk resultaat: status, duur, en een samenvatting van de diff.
Schrijf het append-only weg, één regel JSON per gebeurtenis, in een formaat dat je met standaard tools kunt lezen. Begin niet met een database. Begin met een tekstfile die je crash-bestendig en lokaal houdt.
Want de modellen worden vanzelf beter. De vraag die blijft, is of je over zes maanden nog kunt uitleggen wat ze deden. Met een chat-log kun je dat niet. Met een ledger wel.