GDPR and AI Agents: A Practical Checklist for EU Teams
Short answer: GDPR and AI agents mix fine, but only if you can answer the same questions regulators have always asked, for a longer chain of parties. When an agent reads a support ticket or a CRM record, that data can pass through the agent framework, the model provider, a gateway, a logging pipeline, and a memory store. Every one of those hops is a processing activity, and you are accountable for all of them.
This is not legal advice, and we won't pretend compliance is a badge a vendor can hand you. What we can do is map the questions that actually come up when EU teams point agents at customer data, and turn them into a checklist you can send to any vendor in the chain. Us included.
What changes when an agent touches customer data
A classic SaaS integration moves data from A to B under one data processing agreement. An agent setup adds hops, and each hop is a party you have to account for.
The roles don't change. Your company (or your client) is the controller. Every service that processes personal data on your behalf is a processor, and Article 28 says you need a contract with each of them, one that also binds their subprocessors.
Take a support agent that reads tickets and drafts replies. The personal data in those tickets now touches your helpdesk (a processor you already had), the agent runtime, the model provider, and whatever the setup logs or remembers. If the model provider runs inference in the US, you have a third-country transfer, whether or not anyone decided that on purpose.
Five GDPR questions every AI agent setup must answer
Where is the data processed and stored?
Not "where is the company based". Where does inference run, where do logs land, where does memory persist. Any component outside the EU needs a transfer mechanism, an adequacy decision or standard contractual clauses, and you want to know which one before you sign. Ask for regions per component. A vague "EU data residency available" line usually covers the database and nothing else. We wrote up the practical side in [EU hosting for AI infrastructure](/blog/eu-hosting-for-ai-infrastructure).
Who are the processors and subprocessors?
For an agent, the list is longer than you expect: the model provider, the orchestration or gateway layer, the vector database, the logging service. A serious vendor publishes a subprocessor list and notifies you when it changes. If a vendor cannot tell you which model sits behind their agent feature, that is your answer.
Can access be revoked, immediately?
Agents authenticate with OAuth tokens and API keys. When an employee leaves, an agent misbehaves, or a vendor relationship ends, you need to shut one connection off without breaking the rest. Keys [pasted into config files](/blog/stop-pasting-api-keys) fail this test: nobody remembers where they live, so nobody rotates them. Ask whether access is revocable per connection, from one place, with immediate effect. Our post on [MCP gateway security](/blog/mcp-gateway-security) covers what good credential handling looks like in agent setups.
Is there a record of processing?
Article 30 requires a record of processing activities on paper. In practice you also need the runtime version: which data did the agent actually touch, when, and on whose behalf? An [audit trail of every agent call](/blog/ai-agent-audit-trail) is what lets you answer a subject access request, or a regulator asking about an incident, with something better than a shrug.
Is the data minimized?
Agents over-fetch by default. Give a model a broad tool and it will happily pull whole records when it needed one field. Minimization here means narrow tool scopes (read access to one mailbox, not the whole domain), retention limits on logs, and no personal data in prompts that don't need it. It also means deciding what the agent may remember: a persistent memory that stores customer details is itself a data store with GDPR duties, retention rules included.
The checklist: what to ask any vendor
Send these to every vendor whose service sits between your agent and your customer data. Ask for short written answers. Vagueness is a signal.
- In which region is personal data processed and stored, listed per component (inference, storage, logs, memory)?
- Who are your subprocessors, where is the list published, and how are we notified of changes?
- Do you sign an Article 28 data processing agreement, and does it cover the model provider behind your product?
- Is our data used to train models, and where is that stated in writing?
- How do we revoke a single connection or credential, and how fast does revocation take effect?
- What do you log per agent call, how long do you keep it, and can we export or delete it?
- What does the agent persist in memory, and can we set retention or delete entries on request?
- How are credentials stored, and who inside your company can read them?
We build an MCP gateway ourselves, so here is our own answer sheet, without a compliance stamp: Tulimoa is a German company, hosted in the EU, credentials sit in an encrypted per-secret vault, every connection is revocable at any time, and data export is available in the app. We won't call that "GDPR compliant" in a blog post, because that phrase is a legal conclusion, not a feature. Read [our privacy policy](/privacy) and ask us the same questions you'd ask anyone else.
Frequently asked questions
Do we need a DPIA before using AI agents on customer data?
Often yes, or at least a documented screening. Article 35 requires a data protection impact assessment when processing is likely to create high risk, and new technology applied to customer data at scale is the textbook trigger. If you have a data protection officer, involve them before the pilot, not after.
Is the model provider a controller or a processor?
Usually a processor, if it handles your data only to deliver the service. Check two things in writing: that a data processing agreement covers the model API, and that your data is not used for training. If the provider uses your data for its own purposes, it becomes a controller for that use, and your risk picture changes.
Does the EU AI Act replace GDPR for agents?
No, they apply in parallel. The AI Act classifies systems by risk and phases in obligations; GDPR governs personal data regardless of how the system is classified. For most teams wiring agents to SaaS tools, GDPR is the constraint you'll feel first.