GDPRuler — waarom compliance een runtime systems-probleem is, geen documentatieprobleem

Compliance is geen documentatieprobleem. Het is een runtime systems-probleem.

Dat is de kernboodschap van GDPRuler, een paper van TU Munich en INESC-ID/IST Lisbon dat geaccepteerd is voor ACM CCS 2026. De auteurs, Stavrakakis, Misono, Pritzi, Unnibhavi, Santos en Bhatotia, stellen iets wat voor de hand ligt maar zelden wordt gebouwd: GDPR-naleving moet niet versnipperd worden over applicatielogica of diep in storage engines worden ingebouwd, maar als trusted policy-enforcement layer tussen applicatie en opslag worden geplaatst.

Het resultaat is een middleware die GDPR-compliance afdwingt voor key-value stores, Redis, RocksDB, zonder de KVS-codebase aan te passen. Draaiend in een Confidential Virtual Machine. Met formeel geverifieerde audit logging.

Wat GDPRuler technisch doet

GDPRuler is een drop-in proxy. Je zet hem tussen je applicatie en Redis/RocksDB. De KVS blijft onaangeroerd, geen schemawijzigingen, geen migratie, geen code changes.

De architectuur draait binnen een Confidential Virtual Machine (AMD SEV-SNP, Intel TDX of ARM CCA) en bestaat uit vijf componenten:

Component	Functie
Configuration & Attestation Service	Registreert entiteiten (data owners, processors, controllers, toezichthouders) via mutual attestation
Policy Compiler	Vertaalt declaratieve policies naar uitvoerbare regels; merge van default policies met per-query overrides
Trusted GDPR Monitor	Centrale enforcement engine, valideert elke KV-operatie tegen GDPR-regels, beheert metadata indexes, scant op verlopen data
Data I/O Subsystem	Encryptie, KV-adapter (Redis/RocksDB API-mapping), tamper-evident logging met batched writes en monotonic counters
KVS Engine	Ongewijzigde Redis of RocksDB, draait ook binnen de CVM

De API is bewust klein. Zeven operaties: get, put, delete, getm (metadata retrieval), putm (metadata update), deletem (bulk deletion), en getLogs (audit trail retrieval). De paper probeert geen relationele database te bouwen bovenop Redis, hij voegt precies genoeg compliance-semantiek toe.

GDPRuler introduceert een declaratieve policytaal op basis van predicatenlogica. GDPR-artikelen worden vertaald naar afdwingbare regels:

GDPR Artikel	Enforcement rule
Art. 5, Purpose limitation	Processor mag alleen lezen als zijn doelen binnen de toegestane doelen van de data-eigenaar vallen
Art. 5, Storage limitation	Data mag alleen gelezen worden als de expiry-tijd niet verstreken is
Art. 17, Right to be forgotten	Alleen de data-eigenaar mag verwijderen
Art. 21, Right to object	Geen reads als het opgevraagde doel onder bezwaar valt
Art. 30, Records of processing	Logging verplicht als de monitor-flag op true staat
Art. 32, Security of processing	Encryptie van data, metadata én logs; CVM-attestation

Elke KV-operatie doorloopt een vier-stage pipeline: policy compilatie → metadata extractie → compliance validatie → uitvoering met audit logging. Het is een runtime enforcement point, geen batch-controle achteraf.

Het securitymodel: wat beschermd wordt en wat niet

Het dreigingsmodel is realistisch. Alles binnen de CVM behoort tot de trusted computing base. De hypervisor, het cloud OS en externe opslag zijn untrusted. GDPRuler beschermt tegen:

• Memory reads via CVM-encryptie
• Log tampering via integrity checks
• Fake identity via mutual attestation
• Rollback van audit logs via monotonic counters in de CVM
• Malicious requests via policy checks en access control

De beveiliging is formeel geverifieerd met de Tamarin Prover onder het Dolev-Yao aanvallersmodel. De attestation protocol-bewijzen tonen aan: mutual authentication is correct, perfect forward secrecy geldt, en na succesvolle log-validatie is elk record traceerbaar naar een daadwerkelijke KV-operatie.

Wat expliciet niet beschermd wordt:

• Side-channel attacks vallen buiten scope
• Denial-of-service valt buiten scope
• Rollback van KV-data zelf, de audit logs zijn beschermd, maar een kwaadwillende cloud provider kan KV-data terugzetten naar een pre-deletion state
• Clock/frequency tampering valt buiten scope

Voor high-risk staatsdata, defensie, opsporing of medische dossiers moet dit expliciet in het risk register staan.

De performance-claim: compliance as a controlled performance tax

GDPRuler haalt gemiddeld 61% van native KVS throughput. De CVM-omgeving is de dominante factor: 28-32% overhead. De extra GDPR-compliance-laag voegt daar 8-12% aan toe. De metadata storage overhead blijft onder 20%, audit logging kost ongeveer 2% throughput, en metadata-indexering versnelt GDPR-query's met 13× tot 182×.

Mijn interpretatie: dit is geen "low overhead" in absolute zin. 39% verlies ten opzichte van native throughput is serieus. Maar het is wél verdedigbaar voor workloads waar compliance evidence, purpose enforcement en auditability belangrijker zijn dan maximale Redis-snelheid. De juiste framing is dus niet "gratis compliance", maar compliance as a controlled performance tax.

De metadata indexes zijn hier het kritieke inzicht. Zonder indexes vereisen GDPR-queries, "alle data van gebruiker X ophalen", "alle records met purpose Y verwijderen", full KVS-scans die seconden duren. Met hashmap- en B+ tree-indexes op owner/purpose/expiry is de latency sub-100ms. De indexes maken het verschil tussen "compliance als afterthought" en "compliance als runtime capability."

De echte waarde: het architectuurpatroon

De echte waarde van dit paper zit niet alleen in GDPRuler als systeem, maar in het architectuurpatroon dat het neerzet: de opslaglaag als policy-compliant data plane.

In plaats van compliance achteraf via logging, documentatie of auditprocedures te bewijzen, wordt compliance onderdeel van de runtime data plane. Dat is een volwassenere benadering dan traditionele "governance by process." Zoals we eerder betoogden: AI-soevereiniteit is geen cloudbeleid, het is nationale macht. Datzelfde principe geldt voor compliance: het moet in de data plane zitten, niet in een beleidsdocument.

Dit patroon past in een bredere architectuurbeweging:

• Zero Trust data access, never trust infrastructure, verify identity, enforce policy per request
• Confidential computing, bescherm niet alleen data at rest en in transit, maar ook data in use
• Privacy-by-design, privacy niet als feature flag maar als architectuurprincipe
• Data mesh met federatieve governance, policy enforcement op het storage-niveau, niet op het applicatie-niveau
• Sovereign cloud en EU data spaces, compliance onafhankelijk van cloud-herkomst

GDPRuler maakt het mogelijk om GDPR-compliant te opereren op untrusted Amerikaanse cloud-infrastructuur. Een Nederlandse organisatie kan Redis op AWS draaien, mits GDPRuler in een AMD SEV-SNP CVM de compliance-laag vormt. De CVM-attestation degradeert de cloud provider tot untrusted actor, je hoeft AWS niet te vertrouwen, alleen de AMD SEV-SNP hardware root of trust.

Dit sluit direct aan bij de architectuur die we eerder schetsten: NSA: MCP is de nieuwe enterprise control plane en Van prompt filter naar control plane. GDPRuler is dezelfde gedachte, een harde enforcement layer, maar dan op het storage-niveau in plaats van op het protocol-niveau.

Relevantie voor AI-agenten en agent-memory

Voor agentic systems is dit paper bijzonder bruikbaar. Agents werken steeds vaker met conversation memory, task state, retrieved documents, embeddings, tool outputs, API responses, user preferences, audit logs, credentials en delegated access tokens.

Die data wordt meestal opgeslagen in Redis, SQLite, Postgres, vector databases of object storage. Veel agent frameworks behandelen die opslag als technisch detail. GDPRuler laat zien dat dit fout is. De opslaglaag is juist de plek waar je purpose, retention, access, deletion en auditability hard kunt afdwingen.

Een concrete vertaling naar agent-architecturen:

Agent / Tool / Subagent
        ↓
Policy-aware memory proxy
        ↓
Trusted enforcement layer
        ↓
Redis / Postgres / Vector DB / Object store
        ↓
Tamper-evident audit trail

Dit betekent concreet:

• Iedere agent krijgt een purpose-bound identity
• Iedere memory write krijgt metadata: owner, purpose, retention, sensitivity, origin, allowed consumers
• Iedere tool call krijgt een verifieerbare audit entry
• Iedere memory read wordt policy-gevalideerd
• Deletion en retention worden niet als cronjob behandeld, maar als enforceable control
• Audit logs worden hash-chained of counter-protected
• Sensitive memory kan in een confidential enclave of geïsoleerde local trust boundary worden geplaatst

Dit is precies het ontwerpprincipe waar de MCP-security discussie om draait: MCP-security: de vier-lagen control plane architectuur. GDPRuler voegt de storage-laag toe aan dat model.

Mapping naar AVG, BIO2, NIS2

Domein	Relevantie van GDPRuler	Aandachtspunt
AVG Art. 5	Purpose limitation en storage limitation worden technisch afdwingbaar	Niet alle AVG-principes zijn storage-layer afdwingbaar
AVG Art. 15/17/21/30	Access, erasure, objection en records of processing worden geoperationaliseerd	Juridische interpretatie blijft buiten systeemscope
ISO 27001	Ondersteunt logging, access control, cryptografie en cloud assurance	Vereist aanvullende governance en risk treatment
NIST CSF	Past sterk bij Protect, Detect en Govern	Recover en Respond zijn beperkt uitgewerkt
BIO2	Relevant voor aantoonbaarheid, logging en scheiding van verantwoordelijkheden	BIO2 vereist ook organisatorische borging en beheerprocessen
Zero Trust	Sterke match: never trust infrastructure, verify per request	Identity lifecycle en token governance ontbreken grotendeels

Het belangrijkste inzicht voor de Nederlandse publieke sector: GDPRuler's tamper-evident logging met CVM-attestation geeft een technisch antwoord op de vraag "hoe bewijs je dat je compliant bent?" De AP kan onafhankelijk verifiëren dat logs integer zijn, zonder de cloud provider te hoeven vertrouwen. Dat is precies waar BIO2 om vraagt.

Kritische beoordeling

Vier beperkingen die je moet kennen vóór je dit patroon adopteert:

Eén: GDPR-compliance gereduceerd tot technisch afdwingbare regels. GDPRuler dekt vooral storage-layer obligations: purpose limitation, storage limitation, access, erasure, objection en records of processing. Breach notification (Art. 33-34) en data portability (Art. 20) vallen expliciet buiten scope. Rechtmatigheid, transparantie en proportionaliteit blijven organisatorische verantwoordelijkheden.

Twee: de trusted computing base is niet klein. Een volledige CVM bevat meer software dan een klassieke enclave. Dat maakt deployment praktischer, maar vergroot de attack surface. Voor enterprise adoption moet je aanvullende controls eisen: measured boot, SBOM, reproducible builds, signed artifacts, attestation policy, runtime monitoring.

Drie: side-channel exclusion is een serieus punt. De paper sluit side-channel attacks expliciet uit. Voor reguliere enterprise compliance kan dit acceptabel zijn. Voor high-risk data, defensie, opsporing, medische dossiers, rechterlijke data, moet dit expliciet in het risk register staan.

Vier: policy quality blijft een governanceprobleem. Een policy engine kan slechte policies perfect afdwingen. Als doeleinden te breed zijn, bewaartermijnen verkeerd staan of data-eigenaarschap niet klopt, krijg je formally enforced non-compliance. Governance is geen technisch probleem, maar GDPRuler maakt governance wél technisch afdwingbaar.

Wat ik zou overnemen in een enterprise-architectuur

Niet per se GDPRuler één-op-één implementeren, maar het patroon is waardevol. Dit zijn de capabilities die ik zou opnemen in een target architecture:

1. Policy-aware data access proxy voor Redis, vector DB, object store en Postgres
2. Purpose-bound service identities, gekoppeld aan OAuth2/OIDC of workload identity
3. Metadata envelope per record: owner, purpose, origin, retention, classification, consent/legal basis, processor, lineage
4. Runtime policy decision point, centraal of sidecar-based
5. Tamper-evident audit trail, hash-chain, monotonic counters, external anchoring
6. Retention and deletion enforcement, niet alleen lifecycle policy, maar runtime afdwingbaar
7. Remote attestation van trusted components waar confidential computing beschikbaar is
8. Compliance query API voor DPO, auditor, SOC, AI Governance Board en regulator response
9. Encryption engine die zowel data als metadata en logs versleutelt

Conclusie

Dit is een sterk paper omdat het compliance niet behandelt als documentatieprobleem, maar als runtime systems-probleem. De kerninnovatie is de combinatie van declaratieve GDPR-policy, trusted middleware, confidential computing, metadata-indexering en tamper-evident logging, bovenop ongewijzigde key-value stores.

De grootste les voor AI-agent-architecturen is dat memory, tool state en agent logs niet langer "platte opslag" mogen zijn. Ze moeten een policy-compliant data plane worden, met purpose, retention, identity, auditability en verifieerbaarheid als first-class primitives.

Compliance is geen feature. Het is een architectuurprincipe.

---

Gebaseerd op: Stavrakakis, D., Misono, M., Pritzi, J., Unnibhavi, H., Santos, N. & Bhatotia, P. (2026). "Policy-Compliant Cloud Storage Systems." arXiv:2606.05423 (PDF). TU Munich & INESC-ID/IST Lisbon. Geaccepteerd voor ACM CCS 2026.

Lees ook: AI-soevereiniteit is geen cloudbeleid, het is nationale macht, NSA: MCP is de nieuwe enterprise control plane, en MCP-security: de vier-lagen control plane architectuur.