GDPR
Regulation (EU) 2016/679 — General Data Protection Regulation
EU personal-data regulation. For agentic AI, the binding Articles are 5(1)(b) purpose limitation, 6 lawful basis, 22 automated decisioning, and 32 security of processing.
Who does it apply to?
- Any organisation processing personal data of EU/EEA data subjects, regardless of where the processing happens.
- Controllers and processors — the GDPR distinction maps to the deployer/provider distinction in the AI Act, with different obligations on each.
- Agentic LLM workflows that touch personal data — prompts containing personal data, model outputs about identified individuals, memory storing prior interactions.
- Cross-border deployments where personal data leaves the EU even briefly (model invocations to non-EU regions, memory writes to non-EU buckets).
Two-minute explainer
The General Data Protection Regulation (GDPR) has been in force since 25 May 2018. It’s the EU’s foundational personal-data regulation. For agentic AI, four Articles bind the runtime: 5 (principles), 6 (lawful basis), 22 (automated decisioning), and 32 (security).
Of these, Article 5(1)(b) — purpose limitation is the one most
hand-rolled implementations get wrong. The principle requires that
personal data is collected for specified, explicit, and legitimate
purposes, and not further processed in a manner incompatible with
those purposes. Translated into agent terms: the agent must enforce
at runtime that the data flowing through this invocation is being used
for the registered purpose. The model picks a tool. The tool’s purpose
must match. If it doesn’t, the call is denied. That’s a
BeforeToolCallback decision, not a documentation exercise.
Article 22 — automated decision-making is the second runtime chokepoint. Solely-automated significant decisions about a data subject are prohibited by default. There are three carve-outs in 22(2): (a) necessary for a contract, (b) authorised by law, (c) explicit consent. For agentic AI making credit decisions, eligibility determinations, or employment screening, the practical answer is “yes you can make the decision, but you need a meaningful human in the loop.” Regulus’s HITL surface — driven by the model-risk plugin’s tier classification — provides that.
Article 32 — security of processing is the umbrella. It requires “appropriate technical and organisational measures” to ensure a level of security appropriate to the risk. For an AI agent, the practical measures include: an audit trail (Regulus audit plugin), identity controls (Regulus identity expiry guard), residency enforcement (Regulus residency plugin), and an incident-response capability (Regulus kill switch).
The Regulus GDPR profile encodes these into runtime rules. The
profile composes with uk-gdpr (UK domestic post-Brexit equivalent),
with eu-ai-act (Article 9 alignment), with dora (financial
services), and with nhs-dspt (healthcare). Where the regulations
overlap, the resolver picks the strictest — typically retention is
GDPR-strict (6 years for most purposes) unless another regulation
demands longer.
What Regulus doesn’t do is decide your lawful basis. The Principal
must carry a lawful_basis claim minted by your IdentityAdapter. The
plugin denies invocations without one. The decision of which basis
applies — consent, contract, legitimate interest, vital interest, public
task, legal obligation — is your DPO’s call, captured in your records
of processing activities.
What it actually requires of an engineer
- Purpose limitation (Art. 5(1)(b)) is a runtime check, not a contract clause. The agent must enforce that the data flowing through this invocation is being used for the registered purpose. Tool calls outside the declared purpose must be denied.
- Lawful basis (Art. 6) attaches to the Principal. The calling user/system's consent or contractual basis must reach the agent's decision point. A Principal without a lawful basis claim is denied at the policy plugin.
- Article 22 prohibits solely-automated significant decisions by default. For high-impact tool dispatches (credit, employment, public-service eligibility), HITL is required unless an Article 22(2) exception applies.
- Article 32 security of processing applies to the agent itself. Audit trail integrity, identity expiry, residency enforcement — all map to specific Article 32 measures.
- Cross-border transfers (Art. 44–50) need a lawful transfer mechanism. A model invocation to a non-EU region is a transfer. The residency plugin denies it without an active Standard Contractual Clause or equivalent.
What Regulus does for you
| Regulus control | Delivers |
|---|---|
RegulusPolicyPlugin | Purpose-limitation enforcement at BeforeToolCallback. Reads the purpose claim on the Principal and denies tool calls whose declared purpose doesn't match the agent's registered purpose. Article 5(1)(b) DENY events cite the registered purpose verbatim. |
RegulusPrivacyPlugin | Article 5(1)(c) data minimisation — PII redaction on prompts and re-redaction on memory writes. Patterns include EU IBAN, NIN, GDPR Special Category indicators (Art. 9 PII), and locale-aware name detection. |
RegulusDataResidencyPlugin | Article 44 transfer enforcement — fail-closed on memory and artifact writes outside the resolved EU region. Cross-border model invocations require an active SCC/IDTA configuration, otherwise denied. |
RegulusModelRiskPlugin | Article 22 automated-decisioning gate — tier-2 and tier-3 model invocations require HITL via ADK's ToolConfirmation primitive, satisfying the Art. 22(2)(b)/(c) human-review carve-out. |
RegulusAuditPlugin | Article 30 records of processing — every event captures controller/processor identity, purposes, data categories, retention period, and recipients (the GRC adapter destinations). Filter by data subject to satisfy Article 15 subject access requests. |
Saves you ~12 engineer-weeks
Estimate based on the following honest assumptions:
- Greenfield implementation of purpose-limitation as a runtime gate (3 weeks).
- GDPR-aligned PII pattern catalogue + jurisdiction wiring (2 weeks).
- Article 22 automated-decisioning HITL surface (2 weeks).
- Article 30 records-of-processing structure end-to-end (2 weeks).
- Article 44 cross-border-transfer enforcement with SCC handling (3 weeks).
- Assumes existing OIDC IdP supplying GDPR-aware claims (lawful_basis, purpose, consent_id).
What an auditor will ask
The questions you'll see in a real walkthrough — and where to point them.
-
Show me your Article 5(1)(b) purpose-limitation evidence.
Filter the audit chain by
framework_citations contains 'gdpr:Article-5'. DENY events show the attempted-purpose vs registered-purpose mismatch. Aggregate by Principal to spot purpose-drift across users. -
Where's the Article 22 human-review evidence?
ToolConfirmation events in the audit chain — filter by
event_type = HITL_RESOLVED. Each includes the reviewer's Principal, the structured justification, and the model invocation it gated. -
How do you handle a data subject access request under Article 15?
The audit chain is filterable by data-subject identifier (typically email or customer ID). Export to JSON:
regulus audit export --subject 'subject-id' > subject-access-export.json. The export is GDPR-formatted with field annotations. -
What happens when a cross-border transfer is attempted without an active SCC?
The residency plugin denies it. Filter by
decision = RESIDENCY_DENIED AND attempted_region NOT IN allowed_regions. Each event records the lawful basis check that failed and the missing SCC reference.
What this doesn't cover
- Lawful basis selection — Regulus enforces that a Principal carries a lawful_basis claim; it doesn't decide whether your basis is correctly chosen. That's your DPO's call.
- DPIA / DPO consultation — Regulus emits the runtime artefacts; the DPIA document itself is governance work.
- Subject rights workflow (erasure, rectification, portability) — Regulus provides the audit-chain export for Article 15 SARs; the workflow that handles SAR fulfilment is your customer-service tooling.
- Breach notification to supervisory authority — Regulus emits incident events; the notification process is your incident-response runbook.
Citations
Activate this profile in your agent
regulus init my-agent --profiles=gdpr