AVG-retrofit voor AI-agents: de 03:00-auditchecklist

Het is 03:14 op een dinsdag. De CTO van een logistieke planner met 38 medewerkers, net buiten Eindhoven, heeft een mail gekregen van de Autoriteit Persoonsgegevens. Onderwerp: verzoek om informatie verwerkingsregister, artikel 30 AVG. Deadline: 72 uur. Drie van hun AI-agents — degene die klantantwoorden opstelt, degene die sales calls samenvat, en degene die bonnetjes classificeert — verwerken persoonsgegevens. Geen ervan staat onder eigen naam in het register.

Ze klapt de laptop open. Ze begint een checklist.

Dit is die checklist.

De 03:00-vraag, opnieuw gesteld

Als een inspecteur je vraagt om aan te tonen welke persoonsgegevens je agents de afgelopen 24 uur hebben aangeraakt, uit welk prompt-pad ze kwamen, en welke sub-processor ze heeft gezien — kun je dat dan in één query beantwoorden?

Bij de meeste Nederlandse MKB-bedrijven onder de €14M die we auditen is het antwoord nee. Niet uit slordigheid. Wel omdat de agents snel zijn opgeleverd, het verwerkingsregister al bestond voordat de agents er waren, en niemand artikel 30 heeft bijgewerkt toen een minor bump van LangChain stilletjes een derde sub-processor toevoegde. De checklist hieronder is degene die we draaien voordat we een AVG-retrofit offreren. Hij scoort drie dingen: DPIA-dekking op de top 20 prompt-paden, sub-processor disclosure op de top 8 vendor-API's, en welke agents een AP-onderzoek zouden overleven zonder om 03:00 het spoor bijster te raken.

Scoren van de top 20 prompt-paden

Een prompt-pad is één route die een gebruikersinput aflegt door je agent: van input handler, via tool calls, naar het uiteindelijke antwoord. De meeste teams onderschatten hoeveel verschillende paden ze hebben. Een enkele inbox-agent met vijf tools en drie branchende prompts zit in productie regelmatig boven de 40 paden. We scoren de top 20 op verkeersvolume — alles in de long tail kan wachten op ronde twee.

Per pad noteren we vijf regels:

• Bevat de input een categorie persoonsgegevens onder art. 4(1) AVG? Naam, e-mail, IBAN, BSN, foto, stem, gezondheid, locatie — ja/nee per categorie.
• Is er een DPIA die exact dít pad dekt, of alleen de agent in het algemeen?
• Bevat het pad een vrij tekstveld waar de gebruiker gegevens van een derde kan plakken? Het verborgen-bijzondere-categorie-probleem.
• Bewaart de agent de prompt of het antwoord buiten de modelprovider — vector store, observability-tool, log aggregator?
• Staat er een retention-timer op elk opslagpunt, of groeit het oneindig door?

Elke regel scoort 0–3. Alles onder 12/15 is een failure. Gefaalde paden gaan op een remediatietabel van één pagina, met owners op naam en deadlines.

Het meest voorkomende gat dat we vinden: de DPIA dekt de agent als product, maar niet het specifieke pad waar een verkoper het cv van een klant in de chat plakt om te vragen "schrijf even een nette afwijzing voor mij". Die plakactie is een aparte verwerking onder art. 35 AVG. Hij erft geen dekking van de product-DPIA van de agent, en de AP leest het als een cv-screening die de MKB'er nooit heeft gemeld.

Sub-processor disclosure op de top 8 vendor-API's

De meeste agent-stacks die we auditen raken acht externe API's: de LLM-provider, de vector DB, de observability-tool, de evaluation-tool, de function-calling-middleware, de speech-to-text-dienst (voor voice agents), de search provider, en de mailverzender. Elk daarvan is een sub-processor onder art. 28(2) AVG. Elk daarvan moet bij naam in het verwerkingsregister staan, met de datacategorieën die het verwerkt en een geldige verwerkersovereenkomst.

Drie dingen die mensen over het hoofd zien:

• De sub-processor van je sub-processor. Anthropic gebruikt Amazon Bedrock als één hosting-laag; OpenAI gebruikt Azure. Je DPA-keten moet dat erkennen, inclusief regio. Je data stopt niet bij de naam van de API op je factuur.
• De version pin. Een minor bump van LangChain in 2025 voegde een nieuw telemetrie-endpoint toe dat stilletjes request-metadata naar een derde stuurde. We troffen varianten daarvan in drie opeenvolgende audits. Als je verwerkingsregister de versie niet vastlegt, of je geen upgrade-reviewproces hebt, dan geef je een lijst leveranciers vrij die al verouderd is.
• Wijzigingen in de auth-flow van de leverancier zelf. Anthropic heeft ID-verificatie voor bepaalde API-mogelijkheden vanaf 8 juli 2026 aangekondigd. Dat verandert wie welk model mag aanroepen, en voor agents die zulke flows aan eindgebruikers tonen verschuift het zowel de beschrijving van de rechtsgrondslag als de grens tussen verwerkingsverantwoordelijke en verwerker.

Per klant houden we een leveranciersmatrix bij van 8 regels. Leverancier, rol onder de AVG, locatie sub-processor, verzonden datacategorieën, URL van de verwerkersovereenkomst, laatste reviewdatum, escalatiecontact, in productie vastgepinde versie. Als één cel leeg is, faalt de audit op die regel. Geen halve punten. De matrix staat náást het verwerkingsregister, niet ergens in Notion waar niemand 'm leest.

De drie agents die overleven

Na veertien productie-agents en ruwweg veertig klantaudits zien we steeds dezelfde drie vormen een AP-inspectie overleven. De rest faalt op de eerste of tweede vraag.

De agent met smalle scope

Doet één ding — facturen najagen, leadkwalificatie, ticket triage. Leest uit één bron. Schrijft naar één bron. Logt elke prompt en elk antwoord met een stabiel gepseudonimiseerd gebruikers-ID en een tijdstempel. Heeft een DPIA die op die ene activiteit is afgebakend. Geen vrij tekstvlak waarin je "vraag me alles" kunt typen. Saai met opzet. Auditbaar bij toeval.

De retrieval-bounded agent

Heeft een RAG-laag, maar de retrieval-index is in het verwerkingsregister gedocumenteerd als een aparte verwerking, met een eigen bewaartermijn en rechtsgrondslag. De agent kan niet antwoorden buiten de index om. Als de AP vraagt "waar komt dit antwoord vandaan", staat er een chunk-ID in de log die naar een regel in de index wijst, en die regel wijst naar het brondocument, en het brondocument valt onder dezelfde retention-timer als de chunk.

De audited-tool agent

Gebruikt function-calling, maar elke tool call wordt met argumenten en return value gelogd naar een append-only store met minstens 12 maanden retention. Als de AP vraagt "wat heeft deze agent gedaan op 4 maart om 14:32", ligt het antwoord op één query afstand, geen forensische zoektocht door drie observability-tools met tegenstrijdige tijdstempels.

Agents die falen: het "algemene assistent"-chatvenster dat aan een handvol tools hangt, waar het prompt-pad "wat de gebruiker maar typt" is en de log "wat Datadog op het gratis tier nog had". We hebben er de afgelopen zes maanden vijf van gemigreerd. Geen ervan heeft de eerste audit overleefd. Eentje is teruggebracht tot drie aparte agents; de rest is herbouwd op een router die de set paden inperkt voordat het model de input ziet.

Het verwerkingsregister-spoor om 03:00

Het verwerkingsregister zelf is gewoon een spreadsheet onder art. 30 AVG. Waar mensen om 03:00 op stuk lopen is het spoor — de audit log die bewijst dat een specifieke prompt op een specifiek tijdstip op een specifieke manier is afgehandeld. We standaardiseren op de volgende minimumset, per agent-invocatie weggeschreven:

{
  "ts": "2026-06-22T03:14:08.221Z",
  "agent_id": "invoice-chaser-v3",
  "agent_version_sha": "a91f0c2",
  "user_id_pseudonym": "u_8c1e7d...",
  "prompt_pad_id": "pad.invoice.chase.followup",
  "input_data_categories": ["name", "email", "iban"],
  "model_provider": "anthropic",
  "model_id": "claude-sonnet-4-5",
  "sub_processors_invoked": ["anthropic", "supabase-vector"],
  "tool_calls": [
    { "name": "lookup_invoice", "args_redacted": true, "duration_ms": 142 }
  ],
  "retention_until": "2027-06-22T03:14:08Z"
}

Dit is het minimum waarmee je de vraag van de AP kunt beantwoorden zonder vijf engineers uit bed te trommelen voor een forensische log-export. prompt_pad_id is het veld dat de meeste teams missen; zonder dat kun je wel bewijzen wát het model heeft gezegd, maar niet via welke route dat antwoord tot stand kwam — en dat is de helft van het antwoord waar de inspecteur het écht om gaat.

Het recente voorstel van Cloudflare voor temporary accounts voor AI-agents maakt dit in de praktijk makkelijker. Als elke agent-run start met een afgebakende, verlopende identity, kunnen user_id_pseudonym en sub_processors_invoked uit de identity-laag komen in plaats van achteraf uit drie verschillende logs aan elkaar geplakt te worden.

Wat de retrofit kost, in uren in plaats van euro's

Voor een stack van drie tot vijf productie-agents landt de retrofit grofweg op:

• 4–6 uur om de top 20 prompt-paden te mappen en te scoren.
• 3–4 uur om de matrix van 8 leveranciers in te vullen en missende verwerkersovereenkomsten op te jagen.
• 8–12 uur om de audit log per invocatie aan te leggen als die nog niet bestaat.
• 2–3 uur om de verwerkingsregister-entries te herschrijven zodat ze een side-by-side vergelijking met het draaiende systeem overleven.

Dat is een week geconcentreerd werk voor één engineer die de stack al kent, twee weken als dat niet zo is. Het stuk dat écht niet op het laatste moment kan, is het najagen van verwerkersovereenkomsten, omdat sommige leveranciers er drie weken over doen om te reageren. Begin daar. Begin vandaag.

De afsluitende sanity check

Voor je gaat slapen: pak één willekeurige agent-invocatie van de afgelopen 24 uur. Open de verwerkingsregister-entry voor die agent. Lees de twee naast elkaar. Als de log een datacategorie, sub-processor of bewaartermijn laat zien die het register niet noemt, heb je je eerste remediatieticket. Herhaal met twee andere willekeurige invocaties. Drie mismatches op rij betekent dat het register fictie is en dat de retrofit niet kan wachten.

Toen we afgelopen voorjaar de invoice-chaser bouwden voor een Rotterdamse groothandel, liepen we steeds aan tegen sub-processor drift: de LLM-provider zette er een fine-tuning-endpoint bij, de vector DB rolde een nieuwe regio uit, en het register liep al na zes weken drie versies achter. We hebben het opgelost met een wekelijkse diff-job die live config tegen het register vergelijkt en bij een mismatch automatisch een ticket opent. Datzelfde patroon zit nu onder de meeste van onze AI-agents-trajecten.

Eén ding om vandaag te doen, in vijf minuten: pak je drukstbezochte agent, schrijf de top drie prompt-paden op papier, en zet er per pad de datacategorieën bij die het raakt. Lukt dat niet, dan heb je je audit gap te pakken.