Så designar jag audit logs för AI-system
När ett vanligt script gör fel vill jag veta vilken input det fick, vilken funktion som kördes och vilket exception som kastades. När en AI-agent gör fel räcker inte det.
När ett vanligt script gör fel vill jag veta vilken input det fick, vilken funktion som kördes och vilket exception som kastades. När en AI-agent gör fel räcker inte det. Jag behöver dessutom förstå vilket underlag modellen såg, vilket beslut den tog, vilket verktyg den försökte använda och vilken state transition som följde.
Därför behandlar jag audit logging i AI-system som en del av produktarkitekturen, inte som en efterhandsfunktion för debugging.
Logga beslut, inte bara tokens
En rå dump av prompts och svar kan vara användbar i utveckling, men är en dålig långsiktig auditmodell. Den blir stor, svårsökt och kan innehålla mer känslig information än man egentligen behöver lagra.
Jag vill hellre ha strukturerade händelser:
Då kan jag svara på "varför blev den här artikeln READY?" utan att läsa femtio tusen tokens historik.
State transitions är centrala
I BijoyIQ-fabriken går en artikel genom states som planned, [research](/blogg/sa-skiljer-jag-observationer-fran-slutsatser-nar-ai-analyserar-forskning), evidence-ready, draft, fact-check, editorial, seo-link-qa och ready.
Auditloggen ska registrera varje övergång som en egen händelse. Om A067 går från fact-check till editorial vill jag kunna se vilken Fact Checker som godkände övergången, vilka claims som var kvalificerade och vilka artefakter som var input. Det ger en kedja som går att rekonstruera:
Blockers behöver koder
Fri text som "något saknas" är dålig operationsdata. Jag använder hellre blocker-kategorier som MISSING_PRIMARY_SOURCE, FIRST_HAND_UNVERIFIED, SCHEMA_FAIL, PERMISSION_DENIED eller FRESHNESS_RECHECK_REQUIRED.
Fri text kan fortfarande förklara detaljerna, men koden gör det möjligt att mäta mönster. Om 38 procent av alla stopp beror på MISSING_PRIMARY_SOURCE har jag ett researchproblem. Om de beror på SCHEMA_FAIL har jag sannolikt ett output-contract-problem.
Tool calls måste vara spårbara
När agenten har verktygsaccess blir auditloggen en säkerhetskontroll. Jag vill veta vilket verktyg som kallades, med vilken behörighetsklass och om anropet ledde till en extern effekt.
OWASP rekommenderar att aktivitet i LLM-extensions och downstream-system loggas och övervakas som en del av skyddet mot excessive agency. Det är logiskt: du kan inte upptäcka för bred autonomi om du inte kan se hur den faktiskt används.
Jag skiljer därför gärna på READ, PROPOSE, WRITE, SEND, DELETE och PUBLISH. De sista fyra får högre auditkrav än läsning.
Spara referenser till underlag
Jag vill inte nödvändigtvis duplicera hela dokumentet i loggen. Jag vill spara en stabil referens: source-ID, filversion, commit SHA, URL med retrieved timestamp, eller artefakt-ID.
Det gör provenance möjlig utan att loggen själv blir systemets enda source of truth.
Logga även mänskliga approvals
"Human-in-the-loop" är värdelöst ur auditperspektiv om allt vi vet är att någon klickade OK. Ett approval-event bör åtminstone ha vem, vad, vilken version och vilket beslut som godkändes.
Då går det att skilja på "agenten publicerade" och "agenten förberedde, en människa godkände, systemet publicerade".
Audit logs är också produktdata
n8n:s execution-historik illustrerar en användbar grundprincip: exekveringar måste kunna hittas efter status och köras om med tidigare data. Jag vill samma sak i AI-system: kunna isolera ett misslyckande, återskapa kontexten och testa en ny version av modellen eller prompten mot samma fall.
När loggen är strukturerad kan den dessutom bli ett eval-dataset. De verkliga problemen från produktion blir regressionstester i nästa version. Det är då audit logging slutar vara "loggar för säkerhets skull" och blir en feedbackloop för bättre AI-system.