Blog
GDPR and AI Agents: How to Ensure Data Security and EU Residency
GDPR and AI agents - what actually falls under the law
An AI agent that picks up requests from email, WhatsApp or phone calls and searches company documents processes personal data just like any other IT system. GDPR does not carve out an exception for artificial intelligence. If a name, phone number, national ID, or - in healthcare - health information shows up in a request, the agent becomes part of the data processing chain and follows the same rules as any other system that data passes through. Automation does not change that - responsibility just shifts to the design stage.
In practice, the company deploying the agent stays the data controller, and the model provider - Anthropic, OpenAI, or someone else - is the processor, meaning a data processing agreement is needed under GDPR's Article 28, not a box ticked at the end. Before an agent goes live, four questions need answers: where does the data physically go, how long is it kept, who else can access it, and can it be deleted on request. Skipping any of these almost always means rebuilding the architecture later.
Where data actually goes when an agent handles a request
When an AI agent processes a message, its content is sent to the language model through the provider's API - the data briefly leaves the client's own infrastructure and lands on servers run by Anthropic, OpenAI, or another provider, usually abroad. That is not a problem by itself, given a proper legal basis and a contract. What matters is what happens next: is the content stored beyond the request, is it used for training, how long does it sit in logs.
Anthropic and OpenAI offer business tiers where API data is not used for training and log retention is limited to a short window for debugging and abuse monitoring. That is not the default on every plan - some consumer tiers use data for model improvement by default, so it has to be turned off deliberately before real data flows through. Picking a model provider is not purely a question of answer quality - I settle data terms and model choice together.
EU data residency - what it means in practice
For companies in HR, legal, or healthcare, EU data residency is often a hard requirement, not a nice-to-have - sometimes written directly into the client contract, or into an internal security policy. In practice that means choosing a European region for every piece of the architecture: the vector database, conversation logs, the task queue, backups, and every supporting service touching the data.
Data residency does not stop at the language model. The model itself might respond from a server in Ireland or Frankfurt, but if the vector database or the task queue sits in a US region, the whole setup loses its point from a GDPR perspective - the data still leaves the EU, just through a different component than the one everyone checks first. That is why, on GenAI product integrations, I check every component separately: the queue, the cache, temporary files, monitoring logs.
API keys, cost limits, and control over the model
Bring-your-own-key setups, or BYOK, give a company full control over what happens to its data - the client is the actual party to the contract with the model provider, not a third-party platform aggregating traffic from many clients under one account. With BYOK, the client signs the processing agreement directly with Anthropic or OpenAI, so it knows exactly under what terms its data is handled. It is also the only way to get real visibility into request logs and usage limits.
Cost limits are not only a budget concern. A hard cap on requests and monthly spend forces discipline over how much data goes to the model and how often - an agent with no cap can end up sending entire documents where a paragraph would do. Routing across more than 35 models adds another lever: picking a provider and region that fits the process - HR data through a model with EU servers, a simple FAQ chatbot through a cheaper one.
Pseudonymization and logs in practice - the Janina case study
Janina, an AI HR assistant in production since 2026, runs on a hybrid RAG setup combining semantic search and BM25 over 40 pieces of legislation and more than 900 documents, including Supreme Court case law. Every answer cites the specific article it is based on - not a cosmetic detail, but a condition for HR staff to actually verify an answer instead of trusting it blindly. The underlying data is pseudonymized at the architecture level, not bolted on as an afterthought.
Pseudonymization means separating identifying data from the content sent to the model - instead of an employee's name, the model sees an internal identifier, and the mapping to the real identity sits separately, in a database with restricted access. Janina tracks ZUS and PIT deadlines, generates HR documents, and integrates with KSeF through WhatsApp, yet employee data never reaches the model in a form allowing direct identification. That mapping has to be designed before the first integration, since bolting it on later means rebuilding most of the logic.
Client cloud, EU cloud, or on-premise - how to choose
Not every process needs the same level of data isolation. For many companies, client cloud or EU cloud with a clearly defined provider and region is enough - cheaper and faster to deploy, and fully GDPR-compliant as long as the provider holds the right certifications and a signed processing agreement. For particularly sensitive data - HR, medical, financial - on-premise is often the better choice, with infrastructure physically located at the client or in a data center they control.
At ClawLabs, the studio I run with a small team, AI agent hosting in production runs on a dedicated server per agent, in EU cloud or on-premise, with more than 35 LLMs and automatic failover between them. That separation limits how far one agent's failure can spread and makes it easier to audit where a process's data is handled. This choice is rarely made once and left alone - I have seen projects start on EU cloud, then move to on-premise once scale and data sensitivity grew.
What secure deployment costs, and the most common mistakes
As a rough market indication for Poland and the EU in 2026, a simple AI agent covering one channel typically runs in the low five figures in euros, while a multi-agent system with orchestration, RAG, and several integrations runs considerably higher depending on scope and hosting. These are general market ranges, not a price list - cost also depends on whether data security is designed from scratch or the client already has standards to build on. Every engagement gets quoted after the initial conversation and prototype.
The mistakes I see most often: no data processing agreement with the model provider, personal data sent without pseudonymization where it was not necessary, no hard cost limits that would also cap how much data gets processed, and logs too thin to demonstrate compliance during an audit. A more organizational mistake shows up too - nobody in the company owns data responsibility for the agent, because the topic bounces between IT and legal. Every one of these can be addressed at the prototype stage, before the agent goes into production.
Frequently asked questions
Is sending customer data to a language model like Claude or GPT compliant with GDPR?
Yes, provided there is a signed data processing agreement with the model provider, training on customer data is disabled, and it is clear where and for how long data is stored. I set this up from day one of a deployment, before the prototype stage even starts.
Can an AI agent run entirely on EU-based infrastructure?
Yes. The language model, vector database, and logs can all run in EU regions, and if that is not enough given how sensitive the data is, the whole agent can be deployed on-premise, on the client's own servers or a data center they control.
How long does it take to deploy a GDPR-compliant AI agent?
The process starts with a one-hour conversation about what is eating up the team's time, followed by two weeks building a prototype on the client's real data. Cost control, logging, and GDPR compliance are part of the architecture from day one, not an afterthought.
What happens to the data if the person it concerns asks for it to be deleted?
It gets handled on two levels: data is removed from the vector database and logs on the client's own infrastructure, and it is confirmed whether the model provider retains the query any longer than needed to answer it. With a properly configured API, that second step just confirms the data is already gone.
See also
If you are wondering whether your company's data would stay secure with AI agents in place, let's talk about the architecture before any code gets written.
Contact
Got a process that eats your team's time?
Send me two sentences about the problem. I'll reply and tell you straight whether it's worth automating.