GDPR and AI: A 2026 Compliance Guide for European Teams Using ChatGPT, Claude, and Gemini

Short answer: European teams can use ChatGPT, Claude, and Gemini under the GDPR — but only after they have a lawful basis, an Article 28 data processing agreement (DPA), an updated record of processing activities (Article 30), and, for higher-risk uses, a Data Protection Impact Assessment (Article 35). Layered on top, the EU AI Act has been phasing in obligations since 2025: transparency duties applied from August 2026, and most high-risk obligations are now scheduled for December 2027 and August 2028. This guide explains, in plain English, what European users — DPOs, security leads, and engineers — actually need to do in 2026.

The two regimes you have to satisfy at once

Generative-AI use in the EU sits inside two overlapping regimes:

• The General Data Protection Regulation (Regulation (EU) 2016/679, GDPR) — applies whenever personal data of individuals in the EU is processed. AI prompts, RAG inputs, fine-tuning datasets, and outputs are all "processing" if they contain personal data.
• The EU AI Act (Regulation (EU) 2024/1689) — entered into force on 1 August 2024. Prohibited practices applied from 2 February 2025 and general-purpose AI and governance rules from 2 August 2025. Most remaining provisions, including Article 50 transparency duties, applied from 2 August 2026. Regulation (EU) 2026/1744 (in force 27 July 2026) postponed the stand-alone high-risk obligations in Annex III to 2 December 2027 and product-embedded high-risk systems (Annex I) to 2 August 2028 (Article 113 as amended). The Act applies to providers and deployers of AI systems used in the EU, regardless of where they are established (Article 2).

For most European deployers of ChatGPT, Claude, or Gemini, GDPR is the day-one regime, and the AI Act adds obligations that compound — they do not replace GDPR.

GDPR obligations that apply to every AI use case

1. A lawful basis for the processing

Article 6 requires one of six lawful bases (consent, contract, legal obligation, vital interests, public task, legitimate interests). For AI use, the realistic options for most B2B contexts are:

• Legitimate interests (Art. 6(1)(f)) — for internal productivity, routing, or summarization use cases, after a documented Legitimate Interests Assessment (LIA) that balances the interests against the data subject's rights and reasonable expectations.
• Contract (Art. 6(1)(b)) — when the AI processing is necessary to perform a contract with the data subject (e.g., AI-assisted customer support).
• Consent (Art. 6(1)(a)) — required for many marketing and profiling use cases. Solely automated decisions with legal or similarly significant effects are a separate question: Article 22(2) permits them only where necessary for a contract, authorised by law, or based on explicit consent, each with Article 22(3) safeguards.

Special category data (Art. 9 — health, biometric, religious, sexual orientation, etc.) and criminal-conviction data (Art. 10) need an additional Article 9 / 10 condition. Pasting a patient summary or HR-discipline note into an AI tool engages this layer.

2. A DPA with the AI provider (Article 28)

The provider becomes a processor (or sub-processor) when it processes personal data on your behalf. Article 28 requires a written Data Processing Agreement (DPA) covering:

• Subject-matter, duration, nature, purpose, and types of personal data.
• The controller's documented instructions.
• Confidentiality obligations on personnel.
• Article 32 security measures.
• Sub-processor authorization and restrictions.
• Assistance with data-subject rights, breach notification, DPIAs, and prior consultation.
• Return or deletion at the end of the engagement.
• Audit rights.

OpenAI, Anthropic, Google, and Microsoft all publish DPAs for their enterprise tiers. For a clause-by-clause walkthrough of one of them, see The Anthropic DPA Explained. The consumer tiers typically do not include an Article 28 DPA — which is one reason consumer ChatGPT / Claude / Gemini accounts are hard to defend for any processing of EU personal data.

3. International transfers (Chapter V)

US-based AI providers transfer EU personal data to the US, which is a third country under GDPR. Lawful transfer requires:

• An adequacy decision (the EU-US Data Privacy Framework, adopted by the Commission on 10 July 2023, covers US companies that participate in it).
• Or standard contractual clauses (SCCs) plus a Transfer Impact Assessment (TIA) that addresses Schrems II concerns about US surveillance laws.
• Or another transfer mechanism (BCRs, Article 49 derogations).

Check each provider's status on the Department of Commerce DPF participant list; several providers rely on SCCs in their DPAs instead, so confirm which mechanism your DPA actually invokes. Without a documented mechanism, every prompt to a US-hosted model can be a non-compliant transfer.

4. Records of processing (Article 30)

Every controller of more than occasional processing must maintain a record of processing activities. AI use cases need to appear in the ROPA: the categories of data, recipients (the AI provider, its sub-processors), retention, transfer mechanism, and security measures.

5. DPIAs (Article 35)

A DPIA is required when processing is "likely to result in a high risk" (Article 35). The ICO states that AI processing of personal data will trigger a DPIA "in the vast majority of cases", and the CNIL's AI how-to sheets include a sheet on carrying out a DPIA. Article 35(3) separately mandates one for systematic evaluation of personal aspects and for large-scale special-category processing — which is where HR, education, public-service and decision-making uses of generative AI tend to land.

A DPIA addresses risks, mitigations, and the residual risk acceptable to the controller; consult your DPO before deploying any new AI use case that touches significant personal data.

6. Data-subject rights

Articles 15–22 grant rights of access, rectification, erasure, restriction, portability, objection, and the right not to be subject to solely automated decisions with legal or similarly significant effects.

For AI, the practical implications:

• Access / rectification / erasure must be operable through your AI provider. Most enterprise tiers offer admin tools to query and delete data; map them into your DSAR process.
• Article 22 restricts solely automated decisions; either build a human-in-the-loop signoff, or rely on consent / contract necessity with appropriate safeguards.

7. Article 32 — appropriate technical and organisational measures

The standard of "appropriate" depends on the state of the art, the cost of implementation, and the risk (Article 32(1)). The measures controllers typically document include:

• Encryption in transit and at rest.
• Access controls and least privilege.
• Pseudonymization or anonymization where reasonably possible.
• Logging and audit trails.
• Regular testing of security measures.
• Incident response.

Article 32(1)(a) names pseudonymisation, and EDPB Opinion 28/2024 lists pseudonymisation and measures to mask personal data or substitute it with fake data (for example replacing names and email addresses with fake ones) among the mitigating measures for AI processing. Redacting personal data before it leaves the device is one way to implement those measures. Locke runs on the user's device as a desktop app; its companion browser extension screens AI websites, and a local proxy screens command-line, script and SDK traffic. Locke 1.0 detects entities in the prompt — names, IDs, contact details, special-category data — and replaces them with one-way placeholders before the request leaves the device; reversible tokenization is planned shortly after 1.0, and coverage depends on the app, platform and settings. Masking removes identifiers before transfer, which is data minimisation (Art. 5(1)(c)) and a security measure (Art. 32(1)(a)); it does not by itself take the processing outside the GDPR. Recital 26 treats pseudonymised data as personal data, so Chapter V still applies to whatever personal data remains in the prompt. The legal determination is the controller's.

EU AI Act obligations layered on top

The AI Act's risk-tier model adds obligations on top of GDPR:

• Prohibited practices (Art. 5). Applied from 2 February 2025: certain uses are banned outright (e.g., social scoring, real-time biometric ID in public spaces with narrow exceptions, exploitation of vulnerabilities). For most enterprise users, this affects what you cannot build, not what you cannot use.
• General-purpose AI (Chapter V). Applied from 2 August 2025: providers of GPAI models (OpenAI, Anthropic, Google, etc.) have transparency, technical-documentation, copyright-policy, and (for systemic-risk models) safety / cybersecurity obligations. Deployers can rely on the provider's published documentation.
• High-risk AI systems (Chapter III). Annex III use cases — HR, education, credit scoring, law enforcement, migration, justice, biometric ID, critical infrastructure, and similar contexts — must meet conformity assessment, risk-management, data-governance, transparency, human-oversight, and post-market monitoring requirements from 2 December 2027; product-embedded high-risk systems (Annex I) follow from 2 August 2028.
• Limited-risk AI systems. Article 50 transparency obligations applied from 2 August 2026 (with a transition to 2 December 2026 for Article 50(2) marking by generative systems already on the market): chatbots must disclose AI use; AI-generated content (deepfakes, synthetic media) must be labelled; systems generating synthetic content must mark it as such.

For most European companies using ChatGPT / Claude / Gemini in productivity workflows in 2026, the most likely AI Act trigger is transparency (chatbot disclosure, synthetic-content labelling) and the GPAI deployer position (using documentation provided by the model provider, plus internal policies on use). High-risk obligations attach from 2 December 2027 if you are deploying AI in HR, credit, biometric ID, or one of the other Annex III domains.

What examiners and DPAs are asking about

Based on published guidance from the CNIL and the ICO (UK GDPR) and the EDPB's 2026 coordinated enforcement action on transparency and information obligations, the recurring questions are:

• Lawful basis for each AI use case, with a documented LIA when relying on legitimate interests.
• Article 28 DPA in place with each AI provider, and sub-processor flow-downs.
• TIA / transfer mechanism for US-hosted providers.
• DPIA for higher-risk uses, with explicit consideration of residual risk.
• Article 32 measures including pseudonymisation or masking of identifiers before data reaches the provider.
• DSAR readiness — can you delete a person's data from an AI provider on request, including in caches and embeddings if applicable?
• Records of processing that include the AI use cases.
• Training and policies ensuring staff understand the boundaries.
• Vendor diligence documented: what reviews have you performed on the AI provider's security, transfers, and sub-processors?

Examples: what is and is not defensible in 2026

Frequently asked questions

Is consent always needed to use AI on personal data?

No. Consent is one lawful basis among six. For most B2B productivity uses, legitimate interests (with a documented LIA) or contract necessity (where the AI is necessary to deliver a service) are more practical. Consent is necessary when you cannot reach legitimate interests — typically marketing profiling, intrusive monitoring, or automated decisions with significant effects.

Does using ChatGPT API instead of the web app change the analysis?

It changes one piece — the API operates under enterprise terms, content is not used for training, and Zero Data Retention is available subject to OpenAI's approval — but the rest (lawful basis, DPA, transfer mechanism, ROPA, DPIA where applicable) still applies. The API is not a "compliance dodge"; it is one tier of a broader assessment.

What about Schrems II and US transfers?

The EU-US Data Privacy Framework adequacy decision of 10 July 2023 remains in force. Check each provider's DPF status on the Department of Commerce participant list; several providers rely on SCCs in their DPAs instead. Whichever mechanism applies, reference it in the DPA and document your TIA. If the DPF is invalidated (a Schrems III scenario remains a possibility), have SCCs as fallback.

How does the EU AI Act apply if my company is outside the EU?

The Act applies extraterritorially: if your AI system's output is used in the EU, or you are placing an AI system on the EU market, the Act reaches you. For a US company offering an AI product to EU customers, the deployer obligations of the EU customer flow back through the contract; expect EU customers to ask for documentation aligned with the Act.

Is local-first AI privacy required by GDPR?

Not explicitly. Article 32 requires measures appropriate to the risk, taking account of the state of the art, and names pseudonymisation; EDPB Opinion 28/2024 lists pseudonymisation and the masking or substitution of identifiers among mitigating measures for AI processing. By detecting and masking personal data on the device before transmission, a tool like Locke reduces the data shared with processors, simplifies sub-processor flow-downs, and reduces breach impact. It supports a defensible minimisation posture; whether it is sufficient in a given case is the controller's assessment.

How do data-subject erasure requests work for AI providers?

Most enterprise AI providers offer admin tooling to delete a customer's data on request. The harder question is whether deletion extends to derived artifacts (embeddings, caches, fine-tuned models). For now, GDPR erasure obligations focus on the data the controller can reasonably reach; document the technical limits in your DSAR response and your DPA.

What about the AI Act's foundation-model / GPAI obligations — do those apply to me?

Almost certainly not as a provider — those obligations sit with the OpenAI / Anthropic / Google / Microsoft of the world. As a deployer, you rely on the provider's published documentation, plus your own use-case-specific assessment. Keep the provider's GPAI documentation in your AI program file.

A short checklist for European teams

• Identify lawful basis for each AI use case; document an LIA where relying on legitimate interests.
• Sign DPAs with each AI provider; confirm the transfer mechanism (DPF participation or SCCs with a TIA) each DPA relies on.
• Update Records of Processing Activities with AI use cases.
• Run DPIAs for higher-risk uses; document residual risk and DPO consultation.
• Implement Article 32 measures, including masking personal data on the device before it reaches the provider.
• Map DSAR processes onto the AI provider's admin tooling.
• Train staff on the policy; cover both GDPR and the AI Act's transparency obligations.
• Maintain an AI inventory aligned with the AI Act's risk tiers.
• Watch for sector-specific guidance from CNIL, AEPD, ICO, EDPB, and the EU AI Office.
• Re-assess annually; the regulatory landscape is moving every quarter.

The bottom line

For European teams in 2026, GDPR is the day-one regime and the AI Act is the rapidly adding layer above it. Compliance is achievable — the major AI providers have the contracts, the transfer mechanisms, and the configuration knobs. The work is on the deployer's side: lawful basis, DPA, transfer, ROPA, DPIA, Article 32 controls, DSAR readiness, and documentation. Masking personal data before it reaches the provider is a high-leverage control: it reduces the scope of personal data sent to processors, simplifies the downstream pipeline, and implements the pseudonymisation that Article 32(1)(a) names. Get those right and ChatGPT, Claude, and Gemini are useful tools inside a proper European privacy program. Skip them and you have a multi-regime exposure on every prompt.

Sources and primary references

Reviewed November 2, 2026. Regulations are cited to their official text. Vendor statements are cited to the vendor's own documentation as it read on that date; vendors revise these pages, so confirm before relying on them.

• GDPR Article 6 — Lawfulness of processing — the six lawful bases listed in the post.
• GDPR Article 9 — Processing of special categories of personal data — the special-category list and the Article 9(2) conditions.
• GDPR Article 22 — Automated individual decision-making — the contract, law and explicit-consent routes for solely automated decisions.
• GDPR Article 28 — Processor — the mandatory contents of a data processing agreement.
• GDPR Article 30 — Records of processing activities — the ROPA duty and the narrow small-organisation exemption.
• GDPR Article 32 — Security of processing — "state of the art", cost and risk factors, and pseudonymisation and encryption as named measures.
• GDPR Article 35 — Data protection impact assessment — the "likely to result in a high risk" trigger.
• GDPR Article 45 — Transfers on the basis of an adequacy decision — Chapter V transfer mechanisms.
• GDPR Recital 26 — Not applicable to anonymous data — anonymous information falls outside the GDPR; pseudonymised data does not.
• European Commission — EU-US data transfers — the 10 July 2023 adequacy decision for the Data Privacy Framework.
• European Commission — Regulatory framework on AI — entry into force 1 August 2024 and the revised application timeline after the AI Omnibus.
• EU AI Act, Article 113 — Entry into force and application (as amended) — 2 December 2027 for Annex III and 2 August 2028 for Annex I high-risk systems.
• EU AI Act, Article 2 — Scope — extraterritorial reach where output is used in the Union.
• EU AI Act, Article 50 — Transparency obligations — chatbot disclosure, synthetic-content marking and deep-fake disclosure duties.
• EU AI Act, Annex III — High-risk AI systems — employment, education, creditworthiness and other listed domains.
• EDPB Opinion 28/2024 on AI models (PDF) — case-by-case anonymity, the legitimate-interest three-step test, and pseudonymisation and masking as mitigating measures.
• EDPB — Coordinated Enforcement Framework topic for 2026 — the 2026 coordinated action concerns transparency and information obligations.
• ICO — Accountability and governance implications of AI — a DPIA is triggered "in the vast majority of cases" of AI processing.
• CNIL — What is the scope of the AI how-to sheets — the how-to sheets include one on carrying out a DPIA when necessary.
• CNIL — How to deploy generative AI: initial clarifications — the CNIL's July 2024 deployment recommendations.
• Anthropic Data Processing Addendum — controller/processor roles and SCC-based transfers for Anthropic's commercial products.
• Google Cloud Data Processing Addendum — Google's DPA covering Google Cloud and Google Workspace.
• Microsoft Learn — Enterprise data protection in Microsoft Copilot — Microsoft's DPA coverage and no training on prompts for commercial Copilot.
• OpenAI API — Your data — API content not used for training; Zero Data Retention subject to approval.

Related GDPR guides

• Is ChatGPT GDPR Compliant?
• Is Claude GDPR Compliant?
• Is Gemini GDPR Compliant?
• Is Perplexity AI GDPR Compliant?
• Is Grok GDPR Compliant?
• Is Microsoft Copilot GDPR Compliant?
• GDPR Data Subject Rights and AI
• Claude EU Data Residency in 2026
• Which AI Tools Train On Your Data by Default? The 2026 Audit