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 — AgentWorks runs as managed SaaS on EU-region cloud, with no self-host tier. The trap is a US-hosted model API quietly receiving raw personal data mid-run — which is exactly what an optional, per-tenant PII-detection layer is designed to reduce.

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 the optional PII-detection layer works

An optional, per-tenant PII-detection layer can place a control point between the agent and the language model. When enabled, it scans outbound prompts for personal data — names, emails, phone numbers, IDs, card numbers — and masks or tokenises matched spans before the request reaches the model. It reduces exposure; because free-text personal-data detection can never be 100% complete, we do not market it as a guarantee that personal data never reaches a model. Detection actions are logged for accountability.

The control 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 PII detection enabled, a customer's name and order details flow straight to an external API — a cross-border transfer and a data-minimisation consideration in one. Turning the layer on makes that exposure a decision instead of a default. The architectural guarantee we rely on regardless is EU hosting plus model providers engaged on a no-training, zero-retention basis — the detection layer is a complement to that guarantee, not a substitute for it.

In practice, when enabled, 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 detection ran — what category, how many spans — is written to the audit log.

When enabled, this directly serves two GDPR principles. Data minimisation: the external model only receives the data strictly needed to do the work, with identifiers stripped where detection catches them. 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 is masked before the request leaves the tenant cannot leak from the model provider.

Detection is a useful 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 optional layer in a defence-in-depth posture alongside residency, retention, and access control — not as the guarantee itself. 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 — AgentWorks runs on managed EU-region cloud only, with no self-host tier.
• Consider enabling the optional PII-detection layer so matched personal data is masked before a third-party model call, and confirm detections are 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, an optional PII-detection layer, 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.