Is Claude GDPR compliant? What EU teams need to know before deploying

The question “is Claude GDPR compliant?” gets asked by EU developers and DPOs dozens of times a day. The short answer is: Anthropic has done the paperwork. Whether your application is GDPR compliant depends almost entirely on what you do before the prompt reaches Claude.

Here’s the full picture.

What Anthropic actually provides

Anthropic has built a reasonable GDPR baseline for API customers:

Data Processing Agreement (DPA): Anthropic provides a DPA under Art. 28 GDPR, designating them as a data processor when you use the API. This is required — you cannot lawfully send personal data to a sub-processor without one.

No training on API data: By default, Anthropic does not use inputs and outputs from the API to train its models. This matters for data minimization and for the scope of what you’re consenting the processor to do with your data.

EU data residency option: Enterprise customers can request EU data residency, meaning inference runs on infrastructure within the EEA. This reduces exposure under the cross-border transfer rules in Chapter V.

Subprocessor list: Anthropic publishes a list of sub-processors (companies they share data with to deliver the service). Reviewing this list is part of your due diligence under Art. 28(2).

This is a reasonable starting point. It is not a complete GDPR solution.

What GDPR actually requires from you

The regulation imposes obligations on the controller — the entity that determines the purposes and means of processing. That’s you, not Anthropic. Here’s what that means in practice:

Lawful basis (Art. 6)

Before processing any personal data, you need a lawful basis. For most AI applications, the realistic options are:

• Legitimate interest (Art. 6(1)(f)): You can use this if processing is necessary for a legitimate purpose and doesn’t override the individual’s rights. You must conduct a Legitimate Interest Assessment (LIA) documenting the balance. This is the most commonly used basis for B2B AI tooling.
• Performance of a contract (Art. 6(1)(b)): Applies when the processing is strictly necessary to deliver a service the user has agreed to.
• Consent (Art. 6(1)(a)): High bar — must be freely given, specific, informed, and unambiguous. Difficult to rely on as the sole basis for AI processing.

The DPA with Anthropic doesn’t establish your lawful basis. You do, before processing begins.

Data minimization (Art. 5(1)(c))

This is where most AI applications fall down. GDPR requires that personal data be “adequate, relevant and limited to what is necessary” for the stated purpose.

Sending a full customer record to Claude when you only need to answer a specific question about their order violates the minimization principle. Sending a clinical note containing a patient’s name, address, and full history when the question is about a single medication interaction sends far more than necessary.

A DPA with Anthropic doesn’t fix this. Only your prompt construction does.

Cross-border transfers (Art. 44–46)

Even with EU data residency enabled, you need a valid transfer mechanism if any personal data flows outside the EEA — including to subprocessors. Standard Contractual Clauses (SCCs) are the most common mechanism, and Anthropic’s DPA typically incorporates them.

But “EU region” is not the same as “EU-only.” Subprocessors (infrastructure providers, monitoring tools, support systems) may process data outside the EEA. Review Anthropic’s subprocessor list carefully: check where each subprocessor operates, and whether the transfer mechanism in your DPA covers them.

Right to erasure (Art. 17)

If a data subject requests erasure of their personal data, you must be able to comply. If that personal data has been transmitted in prompts to Claude and exists in inference logs, model context, or Anthropic’s systems, your erasure obligation extends there.

The DPA should specify retention periods and erasure procedures. But if the data was never sent to Claude in the first place — because you pseudonymized before the API call — the erasure problem largely disappears.

Records of processing activities (Art. 30)

You must maintain a record of processing activities that includes, among other things, the purposes of processing, categories of data, and transfers to third countries. Your use of Claude as a sub-processor must appear in this record. Anthropic’s DPA helps here, but the record is yours to maintain.

The “EU region” caveat

EU data residency from Anthropic means inference happens on EEA infrastructure. This is genuinely useful — it reduces exposure under Chapter V and avoids Schrems II complications for the primary data flow.

But four things to keep in mind:

1. Subprocessors operate globally. Anthropic’s subprocessors may include US-based companies handling authentication, monitoring, or infrastructure operations. Data flowing to these systems may exit the EEA even when inference stays in.

2. Enterprise feature, not default. EU data residency is an enterprise-tier option, not on by default. If you’re on a standard API plan, verify where your data is actually being processed.

3. It doesn’t affect your lawful basis or minimization obligations. Data processed in the EU is still personal data subject to GDPR. The location of processing is relevant to transfer rules, not to the rest of the regulation.

4. You can’t independently verify it. Unlike an on-premises deployment or your own Cloudflare account, you’re taking Anthropic’s word for where processing occurs. This matters for some regulatory contexts (public sector, healthcare) where demonstrable control is required.

Where the real risk lives: prompts containing personal data

The single biggest GDPR risk in a Claude deployment isn’t Anthropic’s infrastructure. It’s what you send in the prompt.

A prompt that contains a user’s full name, email address, customer history, or health information is a transmission of personal data to a processor. That transmission:

• Requires a lawful basis
• Must comply with the minimization principle
• Must be covered by your DPA
• Creates a record of processing you need to maintain
• Creates potential erasure obligations

Most teams underestimate this. They focus on the infrastructure question (“where does Claude run?”) and overlook the data question (“what exactly am I sending?”).

The safest architectural approach is to ensure personal data is removed or pseudonymized before it reaches any external API — Claude included. Privedge operates at this layer: it intercepts requests before they leave your infrastructure, detects personal data using pattern matching and entity recognition, replaces it with reversible tokens, and forwards the cleaned prompt to Claude. Claude receives [PERSON_1] instead of “Maria García”. The response is rehydrated on return.

This approach means your GDPR obligations toward Anthropic shrink dramatically — because you’re not sending them personal data in the first place. The DPA still matters, but as a secondary safeguard over a system already designed to prevent exposure. See the GDPR use case for a deeper walkthrough of this architecture.

The EU AI Act angle

Since August 2026, the EU AI Act’s provisions on general-purpose AI models apply. Claude is a general-purpose AI model. Key implications:

• Transparency obligations: Users interacting with AI systems must be informed they are doing so, unless it’s obvious.
• Copyright compliance: Providers of GPAI models must comply with EU copyright law and publish summaries of training data.
• High-risk classification: If you deploy Claude in a high-risk context (healthcare, employment, law enforcement, critical infrastructure), additional requirements apply to your system — not just to Anthropic’s model.

The EU AI Act and GDPR interact: a high-risk AI system processing personal data faces obligations under both. The DPA and data minimization steps above remain required; they’re now joined by conformity assessments, technical documentation, and human oversight requirements that depend on your specific use case.

The practical checklist

Before deploying Claude with EU personal data:

1. Sign the DPA with Anthropic and store it in your records.
2. Document your lawful basis for each processing activity in your ROPA (Art. 30 record).
3. Review Anthropic’s subprocessor list — identify any non-EEA subprocessors and verify your transfer mechanism covers them.
4. Audit your prompts — what personal data categories are you sending? Can you minimize?
5. Implement pseudonymization before the API call for any prompts containing identifiable data.
6. Verify EU data residency status if it matters for your use case — confirm it’s enabled, not assumed.
7. Document your retention and erasure procedures — how long does Anthropic retain inference data, and how do you invoke erasure?
8. Assess EU AI Act applicability if your use case is high-risk.

Conclusion

Claude can be part of a GDPR-compliant AI stack. Anthropic’s DPA, no-training policy, and EU data residency option make it a credible enterprise choice. But the regulation’s obligations — lawful basis, minimization, transfer mechanisms, erasure, transparency — are yours to implement.

The teams getting this right aren’t relying on their AI provider to make them compliant. They’re building compliance into their architecture: stripping personal data before it reaches any external model, maintaining audit logs of what was processed (not what was sent), and documenting their processing activities accurately.

That’s what the regulation requires. A DPA is where compliance starts, not where it ends.