Is Claude GDPR Compliant? A 2026 Guide for European Teams
Sonomos Research
The Sonomos research team writes about AI privacy, data protection, and how to use generative AI safely at work.
Short answer: Claude is not GDPR compliant by default for European teams — "compliant" is a posture assembled by the controller, not a label Anthropic can apply. The short version: Claude.ai consumer accounts have no Data Processing Addendum (DPA) and are not suitable for processing personal data of EU data subjects on behalf of an employer. Claude for Work (Team and Enterprise) and the Claude API are DPA-eligible, exclude prompts from training by default, and support Standard Contractual Clauses for EU-to-US transfers. EU data residency is not currently available from Anthropic — all inference runs on US-based infrastructure. This guide explains what each tier means under the GDPR, where the risks sit, and the control stack that holds up under supervisory-authority scrutiny in 2026.
What the GDPR actually requires of an AI tool
The framework is the same regardless of which AI provider you're evaluating. The moment a prompt containing personal data leaves a user's device and reaches Anthropic's infrastructure, six obligations attach to the controller (your organisation):
- Lawful basis (Article 6). Every processing activity needs a documented basis. For most workplace AI prompts involving third-party personal data, legitimate interest is the operative basis — but only if the balancing test is documented and the data subject's expectations support it.
- Special-category data (Article 9). Health, racial or ethnic origin, political opinions, religious beliefs, biometric data, and similar categories require explicit consent or a narrow Article 9(2) exemption. There is no legitimate-interest path for special-category data, regardless of the AI tier.
- Transparency (Articles 13–14). Data subjects must be told that their personal data is being processed using an AI tool, who the recipients are (Anthropic, its sub-processors), and how long the data is retained.
- Data subject rights (Articles 15–22). Access, rectification, erasure, portability, restriction, and the right not to be subject to solely-automated decisions. Workflows that use Claude to make consequential decisions trigger Article 22.
- International transfers (Chapter V). Anthropic is a US company. Transfers from the EEA to Anthropic's US infrastructure require a lawful transfer mechanism — SCCs plus supplementary measures, in practice.
- Security of processing (Article 32). Appropriate technical measures including, explicitly, pseudonymisation. This is the layer where a local-first privacy tool sits.
Anthropic cannot make your organisation "GDPR compliant." It can only avoid being the thing that breaks compliance. Read every "GDPR-ready Claude" marketing claim in that light.
Claude tier-by-tier GDPR posture (2026)
| Tier | DPA available? | Default training | EU data residency | Sub-processors disclosed | Notes | | --- | --- | --- | --- | --- | --- | | Claude.ai Free | No | May be used for training (opt-out in settings) | No | Limited | Consumer contract; not suitable for EU personal data | | Claude.ai Pro | No | Excluded by default on Pro | No | Limited | Still a B2C contract; no controller-processor DPA | | Claude for Work (Team) | Yes — Anthropic DPA | Excluded by default | No | Yes | DPA covers Team tier; SCCs available for EU transfers | | Claude for Work (Enterprise) | Yes — Anthropic Enterprise DPA | Excluded by default | No | Yes | Strongest posture; BAA available; audit logs; SSO | | Claude API | Yes — Anthropic DPA | Excluded by default | No | Yes | Zero-data-retention option for eligible customers; DPA included |
Three things stand out:
Claude.ai Free and Pro have no DPA. Like ChatGPT Free/Plus, they are consumer subscriptions. Using them to process personal data of EU data subjects on behalf of an employer is an Article 28 breach — no DPA means no controller-processor relationship in the sense the GDPR requires. The fact that Pro excludes prompts from training is a welcome default, but it does not cure the absence of a DPA.
EU data residency is not currently offered. Anthropic processes all Claude inference on US-based infrastructure. Every prompt sent to Claude involves an EEA-to-US international transfer under Chapter V. Anthropic's DPA includes Standard Contractual Clauses and references EDPB Recommendations 01/2020 supplementary measures, which is the standard approach — but there is no option to pin data to EU infrastructure the way some competitors offer.
Training is excluded by default on every business tier. This is significant for the Article 5(1)(b) purpose-limitation and Article 5(1)(c) data-minimisation analysis. Prompts sent under a DPA-covered tier are not used to improve Anthropic's models; they are used only to generate the response and subject to the retention terms of the relevant agreement.
The SCC and Schrems II picture
Anthropic's DPA incorporates the European Commission's 2021 Standard Contractual Clauses (Module 2: Controller-to-Processor, or Module 3 where relevant). Anthropic also participates in the EU-US Data Privacy Framework (DPF), which provides an Article 45 adequacy-based transfer mechanism as an alternative to SCCs.
The practical implications:
- SCCs remain the more widely relied-upon mechanism in professional procurement, because DPF adequacy has political risk (Schrems I ended Safe Harbor; Schrems II ended Privacy Shield) and because several EU DPAs have expressed residual concerns about US government access under FISA 702.
- EDPB Recommendations 01/2020 call for supplementary measures when SCCs alone may not be sufficient for US transfers. The most effective supplementary measure is cryptographic: encrypt or pseudonymise personal data in the EU before it is transferred, so the importing party — and US government requests — cannot access the underlying personal data. A local-first browser extension that masks personal data before the prompt leaves the device provides exactly this supplementary measure.
- No EU data residency option means the transfer always happens. Unlike Azure or Google Cloud, which offer EU-only processing regions, Anthropic does not currently offer regional pinning. Every Claude query from an EU controller involves a cross-border transfer governed by the SCC and supplementary-measures framework.
The Anthropic transparency and rights posture
Anthropic publishes a sub-processor list, which enterprise DPA customers should review against their own vendor register. Relevant sub-processors in Anthropic's current disclosure include cloud infrastructure providers (AWS primarily) and support tooling. Anthropic updates this list and provides advance notice to DPA customers before adding new sub-processors, as required by Article 28(2).
Data subject rights under business tiers: Anthropic's DPA commits to assisting controllers in responding to data subject requests. Practically, this means:
- Erasure requests: Anthropic can delete conversation data on enterprise tiers within agreed timelines. The controller must have a process to identify which conversations contained the data subject's personal data — a challenge without conversation tagging or user-level identifiers in the prompt.
- Access requests: Anthropic can provide conversation exports for enterprise accounts, though the format and interface continue to evolve.
- Memory and personalisation features: As Anthropic adds persistent memory capabilities to Claude, these create additional Article 30 register obligations and DPIA triggers. Controllers should evaluate whether memory is off by default on managed accounts.
What goes wrong in European Claude deployments
The patterns of failure are similar to ChatGPT but with one Anthropic-specific nuance:
-
Claude.ai accounts on work devices. An employee signs up for Claude.ai Pro on their work laptop with a work email address. The employer has no DPA with Anthropic. The employee processes a customer email in Claude. This is an Article 28 breach and almost certainly an Article 6 breach — the employer neither authorised the processing nor documented a lawful basis for it. The "it's on a Pro account so it doesn't train" defence does not address the absence of a DPA.
-
Claude API keys in engineering projects without DPA review. Engineering teams integrate the Claude API into internal tools. The API's DPA is available but was not signed as part of the API key provisioning process. Result: a controller-processor relationship exists in practice without the required Article 28 agreement.
-
No DPIA for organisation-wide deployment. Article 35 requires a Data Protection Impact Assessment when processing is likely to result in high risk. European supervisory authorities — the CNIL, ICO, Garante, and EDPB — have collectively indicated that organisation-wide generative AI deployment on personal data clears that bar. Many organisations deploy Claude across their workforce without a DPIA because they (incorrectly) treat the vendor's own compliance posture as a substitute for their own risk assessment.
-
Special-category data in HR workflows. A common use: HR managers using Claude to summarise performance reviews or absence patterns. Absence data can reveal disability, illness, or pregnancy — all special-category under Article 9. Enterprise DPA or not, the controller needs an Article 9(2) basis (typically explicit employee consent or the employment-law necessity carve-out) documented before the workflow touches this data.
The control stack for a defensible deployment
Contract layer
- Sign Anthropic's DPA for the relevant tier (Claude for Work Team, Enterprise, or API).
- Confirm that SCCs are incorporated and that the supplementary measures annex is completed or referenced.
- Review Anthropic's sub-processor list and document the review.
- Note the absence of EU data residency and reflect this in the DPIA.
Tier-and-settings layer
- No personal data on Claude.ai Free or Pro. This is a policy, not a guideline.
- Memory features evaluated, documented in the Article 30 register, and either disabled for managed accounts or specifically scoped.
- API zero-data-retention configured for sensitive workloads.
- Admin audit logs enabled where available.
Data-minimisation layer
This is the layer that does the most work under Chapter V. If personal data is pseudonymised before the prompt leaves the EU controller's device, the international transfer becomes a transfer of pseudonymous data — a category with materially reduced risks under the EDPB Recommendations. A local-first browser extension that detects names, identifiers, health terms, and account numbers, and replaces them with reversible tokens before any network call, provides this supplementary measure at the user interface layer.
Sonomos operates this way: detection and tokenisation happen in the browser, nothing reaches Anthropic's infrastructure in identifiable form, and the user sees a de-tokenised response. From the GDPR's perspective, the personal data never transferred — because the transformed data is no longer personal data within the scope of Recital 26.
Governance layer
- Article 30 record updated to include Claude processing activities, with lawful basis, recipient (Anthropic PBC), transfer mechanism (SCCs + supplementary measures), retention period.
- DPIA completed for high-risk use cases and refreshed on material changes.
- Transparency notices updated to disclose Claude as an AI tool, Anthropic as a recipient, and the transfer mechanism.
- Data subject rights workflow capable of handling erasure and access requests against Claude conversation content.
- AI acceptable-use policy naming Claude specifically, with clear rules on which data categories may and may not be included in prompts.
EU AI Act overlay
The EU AI Act adds a second regulatory layer from August 2025:
- GPAI provider obligations (Articles 51–55) attach to Anthropic directly: transparency documentation, copyright compliance for training data, model evaluation, and serious-incident reporting. Controllers should verify that Anthropic is meeting these requirements; evidence of GPAI compliance is increasingly a procurement-due-diligence item.
- Deployer obligations for high-risk use cases attach to the controller when Claude is used as a component in education, employment, credit, essential services, law enforcement, migration, or justice systems. High-risk deployers must maintain a risk management system, technical documentation, human oversight, and post-market monitoring records.
- Article 50 transparency requires deployers to inform users when they are interacting with an AI system. This runs to the controller, not Anthropic.
- Article 5 prohibited uses — workplace emotion recognition, biometric categorisation, social scoring — run to the deployer. If Claude is instructed to categorise employees' emotional states or make social assessments, that is the controller's prohibition violation.
The EU AI Act's high-risk classification is essentially per se DPIA-triggering under Article 35 of the GDPR.
Frequently asked questions
Is Claude for Work GDPR compliant?
Claude for Work (Team or Enterprise) with a signed DPA is the required starting point for a defensible EU deployment — it is not the end of the analysis. The controller is still responsible for lawful basis, transparency, data subject rights, DPIA where required, and Article 32 measures including pseudonymisation. There is currently no EU data residency option, so the international transfer analysis (SCCs + supplementary measures) is unavoidable. Claude for Work + a local-first pseudonymisation layer + a completed DPIA + an updated Article 30 record is a posture that holds up under audit.
Can EU teams use Claude.ai Pro for work involving personal data?
No. Claude.ai Pro is a consumer subscription without a controller-processor DPA. Using it to process personal data of EU data subjects on behalf of an employer is an Article 28 breach regardless of the training default. The correct tier is Claude for Work or the Claude API under a signed DPA.
Does Anthropic's EU-US DPF participation eliminate the need for SCCs?
It provides an alternative lawful transfer mechanism under Article 45. Most enterprise procurement relies on SCCs because DPF adequacy is potentially reversible (Schrems I and II precedents). An organisation can rely on both: DPF as the primary mechanism, SCCs as a fallback. Neither eliminates the need for data-minimisation supplementary measures if the controller processes categories of personal data that warrant additional protection.
Does Claude train on my data if I use the API?
No. The Claude API excludes prompts and responses from model training by default. This is reflected in Anthropic's API usage policies and the DPA. Consumer Claude.ai Free may use conversations for training unless the user opts out in settings; Pro excludes training by default but has no DPA.
Do we need a DPIA before deploying Claude across our organisation?
Almost certainly yes if the deployment involves personal data at organisational scale. European DPAs (CNIL, ICO, Garante, and EDPB collectively) have indicated that systematic organisation-wide deployment of generative AI on personal data meets the Article 35 threshold. The DPIA should cover the specific tier, data categories, lawful basis, transfer mechanism, and residual risks — not just Anthropic's own privacy documentation.
How does the absence of EU data residency affect our risk assessment?
It means every prompt involving personal data creates an EEA-to-US transfer subject to Chapter V. The transfer is lawful if SCCs and appropriate supplementary measures are in place — but it cannot be avoided the way it could be with a provider offering EU-only inference infrastructure. The DPIA should explicitly document this gap. The most effective supplementary measure is technical: ensure personal data is pseudonymised before the prompt leaves EU infrastructure.
The bottom line
Claude's GDPR posture in 2026 is strong on business tiers — the DPA exists, training is excluded by default, sub-processors are disclosed, and the SCC framework is in place — and has a meaningful gap on EU data residency. Consumer tiers (Free, Pro) are not suitable for processing EU personal data in a business context. The deployments that hold up under supervisory-authority scrutiny combine the right tier and DPA with a data-minimisation layer that pseudonymises personal data before it crosses the Atlantic, plus the governance documentation that makes the whole posture auditable.
The Schrems II issue never goes away with any US-headquartered AI provider. The answer is not to avoid these providers — it is to build the supplementary-measure layer that converts the international-transfer risk from a compliance gap into a manageable, documented residual risk.
Related GDPR guides
Protect your data while using AI
Sonomos detects and masks sensitive information before it reaches AI models. 100% local, zero data collection.
Install FreeRelated Articles
AI Meeting Notetakers: HIPAA, GDPR, and Privacy Compliance in 2026
Otter.ai litigation, Fireflies BIPA claims, Zoom BAA requirements, GDPR DPA gaps — AI notetakers create real compliance obligations that most organisations have not fully addressed. A practical guide to consent, HIPAA, GDPR, and the specific risks of AI transcription at scale.
EU AI Act Compliance Checklist for Enterprise Deployers (2026)
Prohibited AI practices are enforceable now. GPAI obligations live August 2025. High-risk Annex III requirements hit in August 2026. A practical deployer-focused checklist covering every phase — including employment screening, credit tools, and GDPR overlap.
Is Grok GDPR Compliant? A 2026 Guide for European Teams
Grok and xAI carry the highest GDPR regulatory risk of any major AI tool in 2026 — with active investigations by the Irish DPC, France's CNIL, and the UK ICO over training-data practices, no enterprise DPA, and no EU data residency. Here is what European organisations need to know.