GDPR and LLMs: Where Your Data Actually Goes

Where it goes depends on the route you took, not on the logo.

Ask whether a given model is GDPR compliant and the question has no answer, because the same model is compliant on one route and a problem on another. Claude called through a US endpoint and Claude called through an EU region of a hyperscaler are the same weights and two different data-protection positions. GDPR and LLMs is a question about deployment path, retention settings, and who your processor actually is, all of which you control. Three settings decide most of it, and none of them appear in a model comparison table.

The personal data flow nobody diagrams

When your application calls a hosted model, the prompt leaves your infrastructure. That prompt commonly contains a customer name, an email thread, a case reference, sometimes a health or financial detail that arrived inside a document nobody screened. Under GDPR that is a transfer to a processor, and it needs the same paperwork as any other processor: a data processing agreement, a record in your Article 30 register, and a lawful basis for the underlying processing. Most teams get the model working months before anyone writes that down.

Two properties then decide your exposure. Retention: how long the provider keeps the prompt. Several major providers hold API inputs and outputs for a period measured in days for abuse monitoring, then delete them, and enterprise agreements frequently reduce or remove that window. Training: whether your content improves their model. Business and enterprise API tiers generally exclude training by default, while consumer subscriptions of the same brand frequently do not. That gap is the single most common finding in the audits we run: the company signed a proper agreement for the API, and half the staff are pasting the same data into the consumer app on a personal login.

EU data residency options and what each one buys

Verify all of this against the provider’s current terms before you rely on it. Model vendors change hosting options and retention defaults faster than any article can track, and the state below is as reviewed in August 2026.

• Direct API to the model vendor. Fastest to build, weakest residency guarantees. Some vendors process across multiple regions unless you have specifically contracted otherwise, and a customer-selectable EU-only setting is not universally available. Fine for content with no personal data in it. Harder to defend when the prompt carries a customer record.
• Through a hyperscaler’s EU region. The same frontier models are offered inside the major cloud platforms with regional endpoints, so you pick the region and the processing stays there. This is the route that makes a DPO conversation short, and it is why a company with an existing cloud relationship usually has less work to do than it expects. Watch for one trap: preview model versions often carry weaker residency commitments than generally available ones, in the same console, one dropdown apart.
• EU-domiciled vendors and self-hosting. A European model vendor removes the international-transfer question rather than documenting it. Self-hosting an open-weight model on infrastructure you control removes the processor entirely, at the cost of running it: GPU capacity, evaluation, and someone on call. Worth it for a narrow class of genuinely sensitive workloads, oversold for everything else.

Whichever route you take, the contractual layer looks the same. You need the DPA, you need to know the sub-processors behind your provider (they have their own, and they change), and if any processing lands outside the EEA you need a transfer mechanism such as standard contractual clauses with a documented assessment behind it. Ask for the sub-processor list in writing and put a calendar reminder on it, because a provider adding a sub-processor is a change to your compliance position that arrives as a changelog entry.

Five answers to demand from any model provider

Provider terms move, so the durable control is not a list of who offers what this quarter. It is a fixed set of questions you ask every vendor and file the answers to, with a date on them. These five cover the ground a supervisory authority or an enterprise client will ask about.

• Where is my request processed, by region, for the exact model version I am calling? Not the company’s headquarters. The endpoint. Ask them to confirm it applies to the specific version, since preview and generally available releases sometimes differ.
• How long do you keep prompts and outputs, and how do I shorten it? You want the number in days and the setting that changes it, not a paragraph about how seriously they take security.
• Is my content used for training on this tier, and can you state that in the agreement? The answer often differs between the consumer product and the API under the same brand, which is precisely the gap that catches companies out.
• Who are your sub-processors, and how will you tell me when the list changes? Their processors become your compliance position. A changelog nobody reads is not notification.
• If anything leaves the EEA, what is the mechanism? Standard contractual clauses, an adequacy decision, or nothing. If the answer is vague, treat it as nothing until they put it in writing.

Keep the replies in the same folder as your Article 30 register and stamp each with the date you received it. Every system in our case studies was built with those answers settled before the first integration, which is far cheaper than establishing them after a client’s security questionnaire arrives.

Four design choices that reduce the surface

Redact before the call. The cheapest control available. Strip names, account numbers and identifiers in your own code, send the structure, map the answer back on return. Plenty of tasks (classification, summarising a policy, drafting a reply skeleton) do not need the identity at all, and the team usually discovers this only when somebody asks.

Split by data class, not by department. Route ordinary content to the convenient path and the sensitive minority to the strict one. Companies that try to hold every workload to the strictest standard end up with a slow, expensive system that staff route around, which is worse for compliance than the split would have been.

Keep the personal data at home. The Memórias do Jamor build is the clearest version of this we have shipped: public submissions, photographs stripped of EXIF metadata on our side, processing kept in EU regions, and an explicit consent gate before anything is accepted. The architecture, described in the Memórias do Jamor case study, was designed so the public surface exposes no personal data at all. That constraint shaped the build rather than being bolted on afterwards, which is the only version of this that works.

Configure retention deliberately, then write it down. Set the shortest retention your provider offers, turn off training on your tier, and record both decisions with a date and a name. Half the value is the configuration and half is being able to show a regulator or a client that somebody chose it on purpose. You can see the shape of the systems we build under these constraints on the capabilities page.

The review checklist, and when to get a lawyer instead

Seven questions cover most of a first review. Which systems call a model, and who owns each. What categories of personal data can reach a prompt, including data that arrives inside uploaded documents. Which provider and which route, direct or via a cloud region. What the retention window is and whether training is off. Whether a DPA is signed and where it is filed. Which sub-processors sit behind the provider. What the transfer mechanism is if processing leaves the EEA. If you can answer those seven with a document rather than a memory, the meeting is short.

Get actual legal advice, rather than ours or an article’s, in three cases: special-category data under Article 9 (health, biometrics, union membership, and the rest of that list), any use where the model influences a decision about a person, and any transfer where you cannot identify the legal mechanism. This piece is informational and not legal advice. The related question of which AI Act duties apply on top of GDPR is covered separately in the EU AI Act for SMEs, and the two regimes overlap less than people assume: most of what frightens companies about deploying AI internally is data protection, not the AI Act.