GDPR and AI Agents: The Compliance Playbook Your DPO Will Sign Off On

GDPR was drafted in 2016 and signed into law in 2018. Generative AI agents were not in scope. They are now. Every agent that processes personal data — and most do, the moment they read an email, a CRM record, or a chat transcript — falls inside the regulation. The DPO's job is to make sure the agent meets the same standard as any other processing activity, and your job is to make it easy to do that.

This is the playbook. Not a checklist of platitudes, but the actual decisions your DPO needs to record, the documentation they need to produce, and the controls they need to see implemented in the platform.

Decision 1: lawful basis per agent

GDPR Article 6 requires a lawful basis for every processing activity. For AI agents, the candidates are usually:

• Contract performance (Article 6(1)(b)): the agent is operating in service of a contract with the data subject. Customer support agents responding to authenticated customers are usually here.
• Legitimate interest (Article 6(1)(f)): the agent serves a legitimate interest of the controller that is not overridden by the data subject's rights. Internal productivity agents (drafting email summaries, scheduling) often sit here, after a balancing test.
• Consent (Article 6(1)(a)): the data subject has given explicit, specific consent. Required when the agent does something the data subject would not reasonably expect (using their data to train a model, for example).
• Legal obligation (Article 6(1)(c)): the agent is required to process data to comply with the law. Anti-money-laundering agents typically sit here.

Document the basis per agent. "We have a legitimate interest in AI" is not a basis. "The Sales Outreach Drafting Agent processes prospect contact data under legitimate interest because we have a balancing test on file dated 2026-04-12 that concludes [...]" is.

For special-category data (Article 9: health, biometric, racial, political, religious, sexual), an Article 6 basis is not enough; you need an Article 9 condition too. Most AI agents should avoid special-category data entirely unless the business reason is overwhelming and an Article 9 condition applies cleanly.

Decision 2: international transfers under Schrems II

The moment an EU agent calls a US-hosted LLM (OpenAI, Anthropic, Google through US endpoints), you are exporting personal data to a third country. Post-Schrems II that requires:

• An adequacy decision for the destination (the EU-US Data Privacy Framework currently applies for transfers to US organisations that self-certify)
• Or appropriate safeguards (Standard Contractual Clauses with supplementary technical measures)
• And a documented Transfer Impact Assessment (TIA) per recipient

The practical controls that satisfy a serious TIA:

• PII redaction at the gateway before any third-party LLM call — the model never sees the personal data in identified form
• Where redaction is incomplete (e.g., the personal nature of the data is the point), use of EU-jurisdiction models or self-hosted models for that workflow
• Encryption in transit (table stakes) and the contractual commitment that the model provider does not retain content
• Data subject rights propagated to the model provider via their published process

Document the TIA per agent and update annually. The DPO will not accept "we use [vendor] and they say they are compliant" as a substitute.

Decision 3: automated decision-making and Article 22

Article 22 prohibits decisions "based solely on automated processing" that produce legal or similarly significant effects on the data subject, except under limited conditions. The "solely" part is doing a lot of work and people overinterpret it in both directions.

The compliant boundary for AI agents:

• Agents that draft or recommend, with a documented human review before any decision is made or communicated, are not "solely automated" — they are human decisions informed by AI.
• Agents that act without meaningful human review (auto-rejecting applications, auto-cancelling services, auto-pricing for individuals) are within Article 22 scope and require explicit consent, contract necessity, or specific legal authorisation, plus the safeguards of meaningful human review on request.
• "Rubber stamp" human review does not save you. The reviewer must have real ability to override and the override path must be documented and exercised.

Build the platform pattern that makes this distinction visible: agents tagged as "decision support" with human-in-loop default, agents tagged as "automated decision" with explicit Article 22 conditions documented and the data subject's rights pathway operational.

Decision 4: data subject rights pathways

The standard rights still apply: access, rectification, erasure, restriction, portability, objection. Agents add complexity because the personal data is in three places: the source systems the agent reads from, the agent's audit log, and potentially the model provider's logs.

The pathway that works:

• A subject access request triggers a query against every place the data may live, including the agent audit log
• The audit log retention is set per the lawful basis and revisited annually
• Erasure requests propagate to the model provider via their published erasure mechanism, with the timeline tracked
• The pathway documentation includes the typical fulfilment time and the operational owner

This is rarely "automated." It is process work. But it is process work the DPO can describe to a regulator and demonstrate operating.

Decision 5: the records of processing activity (RoPA)

Every agent is a processing activity. The RoPA entry needs:

• Purpose of processing
• Categories of data subjects and data
• Recipients (including the model providers)
• International transfers and the Article 46 safeguards
• Retention periods
• Description of technical and organisational measures

Most teams already have a RoPA. Add an agent entry per agent, not one entry covering "AI processing." Generic entries are exactly what regulators flag as inadequate.

The platform features that make this tractable

The DPO will not approve a deployment if the underlying platform makes compliance harder. What to look for:

• PII detection and masking at the LLM gateway, not as a post-hoc cleanup
• Per-agent audit logs with the kind of detail Article 12 wants (covered in our Article 12 guide)
• Per-agent retention policies, configurable per workspace and data residency setting
• Data residency options (EU-only deployment, self-hosted in your own infrastructure)
• A clear processor / sub-processor list that the DPO can review against the GDPR-required disclosures

These are the platform-side commitments. The rest is process work the DPO owns.

A 30-day compliance bootstrap

Week 1: inventory the agents already running or planned. Tag each with the data categories, the model provider, the data residency, and the proposed lawful basis.

Week 2: write the lawful-basis assessment per agent. Identify any that probably do not have a sustainable basis and remove them from the roadmap.

Week 3: write the TIAs for any third-country transfers. Implement the redaction and EU-jurisdiction routing where required.

Week 4: update the RoPA with one entry per agent. Walk the DPO through the audit log and erasure pathway on a sample agent.

By day 30 the DPO has documentation, the agents have a defensible compliance position, and you have removed the "we have AI but no compliance story" risk that kills enterprise AI programs at the worst possible moment.