GDPR-compliant AI agents

What GDPR requires when agents process personal data

When an AI agent processes personal data, GDPR requires six things in practice: a documented lawful basis, a data processing agreement with every processor and named sub-processors, EU data residency where transfers are restricted, a defined retention period, honest handling of data-subject requests, and — for higher-risk processing — a data protection impact assessment.

Lawful basis (Article 6). Before an agent processes any personal data you must have one of the six lawful bases — commonly consent, performance of a contract, legitimate interests, or a legal obligation. The order carries no hierarchy; you pick the basis that genuinely fits the purpose, document it, and confirm it holds for every data source the agent reaches. Special-category data (Article 9) — health, biometrics, political views — needs an additional condition before an agent may touch it at all.

A data processing agreement (Article 28).A controller may only use processors that provide sufficient guarantees, and must put a DPA in place setting the subject-matter, duration, nature and purpose of processing, the data types, and the parties' obligations. The DPA also governs sub-processors: the vendor must disclose them, and you should require notice of changes and a commitment that your data is not used to train the vendor's models.

Data residency (Chapter V). GDPR restricts transfers of personal data outside the EU/EEA unless specific safeguards apply. For most EU deployments the clean answer is to keep data stored and processed inside the EU, with private-cloud or self-hosting available for the most sensitive workloads. The trap is a US-hosted model API quietly receiving raw personal data mid-run — which is exactly what gateway-level PII redaction is designed to prevent.

Retention (Article 5(1)(e)).Personal data must not be kept longer than necessary. Agent transcripts, tool outputs, and logs are personal data too, so set retention on them — including the audit trail — and align it with your DPA. "Keep everything forever" is a storage-limitation breach waiting to be found.

Data-subject rights (Articles 15–22).People can request access, rectification, erasure, and objection. You must be able to find and act on a person's data across chat history, knowledge bases, and logs, and explain automated decisions where they produce legal or similarly significant effects. Design the deployment so a DSAR is a query, not an archaeology project.

A DPIA where required (Article 35). Processing that is likely to be high risk to individuals — large-scale profiling, special-category data, systematic monitoring — requires a data protection impact assessment before you go live. Store the signed conclusion with version history; it is often the first document a regulator asks to see.

How PII redaction at the gateway works

PII redaction at the gateway places a control point between the agent and the language model. Before any prompt leaves your tenant, the gateway scans it for personal data — names, emails, phone numbers, IDs, card numbers — and masks or tokenises those spans, so the third-party model receives a sanitised request and never sees raw PII. Each redaction is logged for accountability.

The mechanism matters because most business value comes from frontier models that are operated outside your infrastructure. Every agent turn is an outbound request to one of those models. Without a control point, a customer's name and order details flow straight to an external API — a cross-border transfer and a data-minimisation problem in one. The gateway turns that from a default into a decision.

In practice the flow is: (1) the agent assembles a prompt containing context and the user's data; (2) the gateway inspects the prompt with detection rules and pattern matching for the personal-data categories you configure; (3) matched spans are replaced with placeholders or reversible tokens; (4) the sanitised prompt is sent to the model; (5) on the way back, tokens can be re-hydrated inside your tenant so the user still sees a coherent answer; and (6) the fact that redaction occurred — what category, how many spans — is written to the audit log.

This directly serves two GDPR principles. Data minimisation: the external model only ever receives the data strictly needed to do the work, with identifiers stripped. Accountability: the log proves that the control ran and what it did, which is the evidence an auditor asks for. It also reduces your exposure surface — data that never leaves the tenant cannot leak from the model provider.

Redaction is a strong control but not a silver bullet: pattern-based detection can miss unusual formats, and some workflows legitimately need identifiers to function. Treat it as one layer in a defence-in-depth posture alongside residency, retention, and access control. See how these controls fit together on the compliance page.

A GDPR compliance checklist for AI agents

Use this checklist as a working agenda before you put an AI agent into production on personal data. It is not legal advice, but it mirrors what a supervisory authority looks for: a lawful basis, the right contracts, controls on transfer and retention, and the ability to answer for what the agent did with someone's data.

• Map each agent's data flows: which personal data it reads, from which source, and where that data ends up.
• Choose and document a lawful basis per processing purpose; add an Article 9 condition for any special-category data.
• Sign a DPA with the platform vendor; obtain the list of sub-processors and a no-training-on-your- data commitment.
• Pin EU data residency at rest and in transit; reserve private-cloud or self-hosting for the most sensitive workloads.
• Enable PII redaction at the gateway so personal data is masked before any third-party model call, and confirm it is logged.
• Set retention on transcripts, knowledge, and audit logs; align it with the DPA and delete on schedule.
• Build a DSAR path: locate, export, rectify, and erase a person's data across chat, knowledge, and logs.
• Run a DPIA where the processing is likely high-risk; store the signed conclusion with version history.
• Keep an exportable audit trail of every run, and pair high-impact actions with human-in-the-loop approval.

When you can show each of these on screen — not just assert them — you have the evidence base a controller needs. The Trust Center and compliance page walk through how AgentWorks evidences them.

Scope and honest limits

No platform can make you "GDPR compliant" on its own. Compliance is a property of the whole deployment — your lawful basis, contracts, configuration, and staff practices — not a switch a vendor flips. The honest framing is readiness: a platform gives you the controls, and you operate them to meet obligations that remain yours as the controller.

Be wary of any vendor that claims blanket compliance. GDPR outcomes depend on choices only you can make: which lawful basis you rely on, what data you feed the agent, how long you keep it, and how you answer data subjects. A platform can supply DPAs, residency options, PII redaction, retention settings, and audit logs — the raw materials of compliance — but assembling them into a lawful processing operation is the controller's job.

This guide is general information, not legal advice. Regulatory interpretation evolves through EDPB guidance and national supervisory authorities, and your specific facts matter. Treat GDPR as a living program with named owners, and involve your data protection officer or counsel before go-live on anything touching special-category data or large-scale profiling.

If you want a platform built around EU data protection from the start, that is what AgentWorks is designed for. Explore the AI agent platform guide, read how the EU AI Act interacts with your obligations, review the compliance controls and the Trust Center, then start free and configure your own GDPR-ready deployment.