AI audit trail en compliance logging: praktische gids voor MKB

De EU AI Act is in augustus 2024 in werking getreden; sinds augustus 2026 zijn de verplichtingen voor high-risk AI-systemen van toepassing. Daarmee kun je niet meer wegkomen met "we hebben AI in gebruik, maar we kunnen niet precies laten zien wat het deed". Voor high-risk AI-systemen is logging van beslissingen verplicht. Voor lager-risico AI is het feitelijk verplicht zodra een betrokkene of toezichthouder vraagt waarom een AI-beslissing zo uitviel — en geen log betekent geen verdediging.

Maar wat moet je nu écht vastleggen? Hoe lang bewaar je het? Wat zijn de minimale eisen voor een MKB-bedrijf zonder een security operations center? Dit artikel geeft praktische antwoorden, met een referentie-architectuur die je in een paar weken kunt opzetten.

Waarom audit logging meer is dan een wettelijke verplichting

Het is verleidelijk om audit logging te zien als een compliance-vinkje. Maar de bedrijven die het serieus inrichten, ontdekken al snel drie andere voordelen die zwaarder wegen dan de regelgeving zelf.

Debug-vermogen bij incidenten. Een AI-systeem dat een verkeerde beslissing nam — een afgewezen lead, een foutieve prijsbepaling, een misclassificatie — is alleen te diagnosticeren als je weet welke input het kreeg, welke versie van het model het gebruikte, en welke output het gaf. Zonder log staat je team met lege handen.

Bewijs richting klanten. Een klant die zegt "uw AI heeft mij oneerlijk behandeld" is een ander gesprek wanneer je binnen 5 minuten kunt laten zien wat er precies gebeurde, vs. wanneer je dat niet kunt.

Verbetering door analyse. Goede logs zijn de basis voor het meten of je AI beter wordt of slechter. Drift, hallucinaties, en patronen van fouten worden zichtbaar in retrospectieve analyse — niet in real-time monitoring.

Voor de bredere wettelijke context, zie onze pillar over AI-wetgeving in Nederland en de EU AI Act.

Wat de wet minimaal vereist

De EU AI Act (Art. 12, 13, 14) en de AVG (Art. 22, 30) eisen samen een set logging die in de praktijk neerkomt op zes onderdelen:

• Welke AI-component werd ingezet — model, versie, leverancier
• Welke input ging erin — de exacte prompt of data, geanonimiseerd waar mogelijk
• Welke output kwam eruit — inclusief eventuele scores of classificaties
• Welke beslissing volgde — wat deed het systeem of de mens met de output
• Wanneer en door wie — timestamp, gebruiker (mens of systeem), context
• Welke menselijke controle plaatsvond — heeft een mens de output gereviewd? Wat besloot die persoon?

Dit lijkt veel, maar voor de meeste AI-toepassingen is het gestructureerd terug te brengen tot één regel JSON per beslissing. De technische uitvoering is niet de bottleneck — de organisatorische discipline om het ook daadwerkelijk te doen, is dat wel.

De referentie-architectuur voor MKB

Een werkbare opzet die meeschaalt zonder enterprise-tooling kent vijf onderdelen.

Aan de voorkant zit een logging-laag: elke AI-call (intern of extern) wordt afgevangen door een wrapper-functie die de zes hierboven genoemde velden vastlegt. Voor Python is dat een decorator, voor Node.js middleware. Werk je in no-code stacks zoals n8n of Make, dan voeg je een "log-naar-database"-stap toe aan elke AI-flow.

Daarachter komt opslag — een append-only database. Postgres met een immutable_log-tabel werkt prima voor de meeste MKB-volumes (tot tienduizenden beslissingen per dag). Voor hogere volumes stap je over op een time-series database (TimescaleDB, ClickHouse) of een log-platform (Datadog Logs, Logtail).

Logs zijn alleen nuttig als je ze kunt doorzoeken. Bouw daar dus indexering omheen: minimaal zoekbaar op gebruiker, datum, AI-component en beslissingstype. Tools als Grafana Loki of een eenvoudige Elastic-instance bieden dit.

Voor retentie geldt een dubbele eis: de AVG verlangt verwijdering wanneer data niet meer noodzakelijk is; de AI Act verlangt behoud zolang het systeem in productie is plus een redelijke onderzoeksperiode erna. In de praktijk komt dat neer op een bewaartermijn van rond 24 maanden voor de meeste use cases, met expliciete verwijderingsroutines voor persoonsgegevens.

Tot slot: niet iedereen mag in de logs. Gescheiden rollen werken het best — ontwikkelaars zien geanonimiseerde logs voor debugging, compliance-officers zien de volledige logs voor audits. En de toegang zelf wordt ook gelogd, want meta-logging is wat een audit van je audit mogelijk maakt.

Deze opzet kost typisch €200–€800 per maand aan tooling voor een MKB, plus eenmalig €5.000–€15.000 om in te richten.

Wat je per use case logt

De inhoud van de log varieert per type AI-toepassing. Vier veelvoorkomende patronen:

Chatbot of customer service AI

Per conversatie: gebruikersvraag, opgehaalde kennisbron, antwoord, eventuele escalatie naar mens, of de gebruiker tevreden was. Belangrijk extra veld: confidence score van het antwoord — laag-confidence antwoorden die niet escaleerden zijn de eerste plek waar problemen ontstaan.

Document- of contractanalyse

Per geanalyseerd document: documenttype, model dat draaide, gevonden datapunten, eventuele afgekeurde of gemarkeerde elementen, menselijke review-uitkomst. Dit raakt direct aan wat we beschrijven in AI documenten verwerken.

Beslissings­ondersteuning (recruiting, lending, pricing)

Per beslissing: alle inputvariabelen, gegenereerde score, drempelwaarde, uiteindelijke beslissing, of een mens deze reviewde, en zo ja, of die mens overruleerde. Dit is hoog-risico onder de AI Act — de logging moet hier strenger zijn dan bij andere use cases.

Generatieve AI voor content

Per gegenereerd stuk content: prompt, model, versie, output, plek waar gepubliceerd, of een mens reviewde voordat het naar buiten ging. Dit raakt aan transparantie-vereisten — meer in AI-transparantieplicht voor bedrijven.

Drie veelgemaakte fouten

Drie problemen die in elke audit van AI-logging terugkomen:

Te veel loggen. Sommige bedrijven loggen letterlijk elke API-call met de volledige prompt en output, inclusief persoonsgegevens, en bewaren dat onbeperkt. Dat is geen audit trail — het is een AVG-overtreding waarop de toezichthouder gaat handhaven. Logs moeten doelgericht zijn: alleen wat noodzakelijk is voor verantwoording.

Te weinig loggen. Andere bedrijven loggen alleen "AI gebruikt" zonder enige inhoud. Dat is wettelijk hetzelfde als niets loggen — je kunt geen beslissing reconstrueren. Compliance-toezicht verwacht dat een audit een individuele beslissing kan ophalen en herleiden.

Loggen zonder kunnen lezen. Logs zonder zoekfunctie, zonder rapportage, zonder regelmatige review zijn dode data. Het kost weken om iets terug te vinden, en niemand kijkt er proactief naar. De waarde van logging zit in de toegankelijkheid.

Hoe je dit organisatorisch belegt

Logging is een technisch onderwerp dat snel een organisatieprobleem wordt zodra het over verantwoordelijkheid gaat. Drie rollen die je expliciet moet beleggen:

Logging-eigenaar (technisch). Iemand uit IT of engineering die de pipelines en opslag in stand houdt en verstoringen detecteert. In een MKB vaak de CTO of de hoofdontwikkelaar.

Compliance-reviewer. Iemand die periodiek (per kwartaal) een steekproef van logs doorloopt en kijkt of het systeem doet wat het hoort te doen. Vaak de privacy-aanspreekpunt of een externe consultant.

Incident-responder. Iemand die binnen 24 uur kan reageren als er een vraag komt vanuit een klant, een toezichthouder, of een gemelde fout. Niet noodzakelijk fulltime — wel duidelijk benoemd.

Deze rollen sluiten naadloos aan op het bredere AI governance framework voor MKB en werken het beste in combinatie met een actuele AI compliance checklist. Wie een DPIA heeft uitgevoerd, vindt veel van de input voor logging-vereisten al in dat document — zie DPIA voor AI-projecten.

Wat het kost

Voor een MKB met enkele AI-systemen in productie:

Totaal jaar 1: €12.000–€35.000. Tegenover een potentiële boete onder de AI Act van maximaal €15 miljoen (of 3% van de wereldwijde omzet) is dit goedkope verzekering. En de operationele waarde — debug-vermogen, klantvertrouwen, verbeterinzicht — verdient zich vaak los van de regelgeving al terug.

De kern: logs die uithouden in een audit, niet logs die mooi staan

Een audit trail die werkt is een audit trail die overleeft als iemand in een echte audit-situatie vraagt: "laat zien wat dit systeem op 14 maart om 11:23 deed met klant X." Als je dat in tien minuten kunt laten zien, met de input, output, beslissing en menselijke review, ben je in orde. Als je drie dagen nodig hebt om het terug te vinden of "dat zijn we niet aan het loggen" moet zeggen — dan is het werk dat je hebt gedaan compliance-theater, en geen compliance.

Bouw daarom je logs vanuit dat scenario, niet vanuit een templatelijst van velden. Stel jezelf de vraag: als de Autoriteit Persoonsgegevens of de toezichthouder onder de AI Act morgen aanklopt, kun ik dan binnen een werkdag laten zien wat mijn AI in de afgelopen maand heeft gedaan? Als het antwoord "nee" is, dan weet je waar de eerste investering moet vallen.