GDPR-Compliant AI: 2026 Compliance Guide for Enterprises

An AI is GDPR-compliant when it processes personal data in cumulative respect of GDPR requirements (legality, minimisation, transparency, security) and, since 2024, of the specific obligations of the European AI Act. In practice, six requirements:

An identified legal basis for each processing (consent, legitimate interest, contractual execution, legal obligation)
Effective minimisation: do not send personal data to an LLM if pseudonymised or aggregated data suffices
A documented DPIA as soon as an AI use case is likely to entail high risk (HR, scoring, biometrics, critical infrastructure)
Solid contractual framework with the model provider: DPA, sub-processors, location, deletion on request
A clear distinction consumer / business / on-premise in deployed tools
Documented AI literacy for teams, required by AI Act Article 4

There is no “GDPR certification” of an LLM — it is the use that is compliant or not, not the tool taken in isolation. A Mistral Le Chat Enterprise used without governance can violate the GDPR; a ChatGPT Enterprise used rigorously can be compliant. The deciding factor is governance.

AI compliance in Europe no longer relies on a single text. Three frameworks layer and articulate.

The GDPR (Regulation (EU) 2016/679) remains the foundation for any processing of personal data, including in an AI system. All classical obligations apply: legal basis, minimisation, accuracy, retention limits, security, transparency, rights of individuals (access, rectification, opposition, deletion, portability). AI is not a derogatory regime — it is a case of GDPR application with technical specificities.

The AI Act (Regulation (EU) 2024/1689) has entered phased application since February 2025. It classifies AI systems into four risk categories (unacceptable, high, limited, minimal), imposes specific obligations on providers and deployers, and introduces an AI literacy obligation for organisations. Sanctions can reach €35 million or 7% of global revenue for prohibited practices.

The ePrivacy Directive still governs cookie placement and access to terminal equipment. For most AI cases, it has little direct impact, except on related analytics layers (cf. our CNIL exemption guide).

Practical articulation: GDPR sets what can be done with personal data, AI Act sets specific AI-system requirements, ePrivacy frames technical layers. All three apply simultaneously — no hierarchy that exempts one text.

Four Major Risks of Personal Data in LLMs

Before best practices, understand concrete risks. Four stand out.

1. Training leak

Consumer LLMs (free or Plus ChatGPT, free Claude, consumer Gemini) by default use conversations to improve their models. Personal data sent in a prompt may end up integrated into the model, theoretically extractable by other users via attack prompts (jailbreak, model inversion).

GDPR consequence: uncontrolled transfer and processing of personal data without legal basis or contractual framework. Immediate sanction risk in case of CNIL audit.

2. Undue retention

Even on enterprise offerings (ChatGPT Team/Enterprise, Mistral Le Chat Enterprise), data exchanged is retained on provider servers for variable durations (30 days default at OpenAI, negotiable durations for Mistral). This retention must be:

Documented in the processing register
Consistent with the GDPR retention duration
Covered by a signed DPA

Otherwise, it is a breach of GDPR Article 5(1)(e) (storage limitation).

3. Transfer outside the EU

LLMs hosted in the United States (OpenAI, Anthropic, Google) by default process data across the Atlantic. The Data Privacy Framework (DPF) technically legalises this transfer since July 2023, but remains contested (Latombe appeal, NOYB vigilance). A European organisation founding its AI strategy on the DPF alone exposes itself to a Schrems III that could invalidate these flows overnight.

This is where the question of AI sovereignty meets compliance: choosing a European player (Mistral, Aleph Alpha) or an on-premise solution simply eliminates this risk, rather than mitigating it contractually.

4. Algorithmic inaccuracy

LLMs hallucinate — they produce plausible but false statements. When these statements concern an identifiable person (a candidate wrongly scored as unfit, a client described with invented elements), it is a direct breach of GDPR Article 5(1)(d) (accuracy). The Italian Garante has already sanctioned OpenAI on this ground in 2024.

An AI compliance policy must explicitly plan how to verify generated content on identifiable persons before effective use.

DPIA: When Is It Required for AI Use?

A Data Protection Impact Assessment (DPIA) is mandatory for any processing “likely to result in a high risk to the rights and freedoms of natural persons” (GDPR Article 35). For an AI use, the CNIL and EDPB have specified cases of systematic requirement.

DPIA mandatory for the following AI uses:

Large-scale profiling leading to a decision (credit scoring, insurance scoring, social benefit allocation)
Systematic monitoring in publicly accessible areas (facial recognition, behavioural biometrics)
Sensitive data processing under GDPR Article 9 (health, political opinions, origins, sexual orientation, identifying biometrics) at scale
Automated decisions with legal effect or significant impact (GDPR Article 22)
Systematic employee evaluation by an AI system (HR, productivity, people analytics)
Cross-referencing data from multiple sources to build a profile

DPIA not mandatory but recommended for uses such as:

AI-assisted writing on business data (internal notes, projects, meeting summaries)
Document synthesis on non-personal documents
Automatic translation of published content
Marketing content generation

Case-by-case assessment criteria: the CNIL recommends considering data volume, sensitivity, vulnerability of individuals (minors, employees, patients), innovative nature of processing, and degree of automation.

DPIA must be carried out before implementation, retained in a register, and updated at every substantial change. It also conditions AI Act compliance for high-risk-classified uses.

Seven concrete practices that distinguish a prepared organisation from a risk-exposed one.

1. Enforceable AI usage charter. Short document (3-5 pages) specifying: which tools are authorised, on what data types, with what obligations (verification, traceability, incident reporting). Distributed to all employees, integrated into internal regulations. Without a charter, impossible to prove a compliance approach in case of audit.

2. Mapping AI uses in the processing register. Each AI use case processing personal data must appear as a separate processing, with: purpose, legal basis, data processed, sub-processor, retention, recipients, transfers outside the EU, security measures.

3. Signed DPA with the model provider. For OpenAI, Anthropic, Google: standard DPA but to validate with their downstream sub-processors. For Mistral: DPA available natively. For open-weight LLMs deployed internally: no DPA because no sub-processor — but hosting and MSP providers must themselves sign DPAs.

4. Systematic pseudonymisation before sending. Whenever possible, remove or replace names, identifiers, contacts before sending text to an LLM. Good AI doesn’t need to know who is concerned to draft a summary.

5. Human supervision over automated decisions. GDPR Article 22 prohibits, except in exceptions, decisions “based solely on automated processing”. For any AI use case producing a recommendation with legal or significant effect, plan for documented human review.

6. Transparent information of individuals. GDPR Article 13/14: inform of AI system use, of underlying logic, and of possible consequences. This information must be added to existing legal mentions and privacy policies.

7. Traceability of prompts and outputs. For sensitive uses, retain a log of prompts sent and outputs received, with timestamp and user. Indispensable in case of CNIL investigation or individual request.

Cloud Public vs On-Premise: The Decision Matrix

One of the most structuring choices in AI compliance is deployment mode. Three options, three risk exposure levels.

Criterion	Consumer LLM (free ChatGPT/Claude/Gemini)	Enterprise SaaS LLM (ChatGPT Enterprise, Mistral Le Chat)	On-Premise LLM (Mistral, Llama, Qwen on internal infra)
Data used for training	Yes (default)	No (DPA)	No
DPA available	No	Yes	N/A
Hosting	US primarily	EU (Mistral) or regional choice (OpenAI)	Internal or sovereign cloud
DPF / Cloud Act risk	Very high	Moderate (EU) to high (US)	None
Suitable for non-sensitive personal data	❌	✅ with DPA	✅
Suitable for sensitive data (health, biometrics)	❌	⚠️ DPIA required + sovereign cloud SecNumCloud	✅ recommended
Deployment cost	Low	Medium (€15-60/user/month)	High initial (hardware + integration)
Reversibility	Low	Medium	Total

Simple rule: consumer only for totally non-personal uses (marketing copy, public translation, prototyping). Enterprise SaaS for most business uses. On-premise as soon as data is sensitive, subject to professional secrecy, or service criticality requires it.

FAQ

Yes, under conditions. The Team or Enterprise version (with DPA, training disabled, account control) is exploitable on non-sensitive business data. The free or Plus version (personal account) is never compliant for processing personal data in a professional setting — data feeds the model and exits the contractual perimeter.

Mistral Le Chat Enterprise offers a native GDPR framework (EU hosting, DPA, no training on conversations) that simplifies compliance. But the tool alone does not make compliance: a usage charter, an up-to-date processing register, and respect for minimisation rules are required. Mistral is a good starting point, not a complete answer.

Do I need a DPIA to use an LLM internally?

Not systematically. DPIA is required for high-risk processing (cf. CNIL list). A generic use (writing, summarisation) on pseudonymised business data does not require one. An HR, scoring, or sensitive data use, yes.

Are conversations sent to an LLM considered personal data?

Yes as soon as they contain data identifying a person directly or indirectly. This includes a name, but also sufficiently precise context (“the commercial director who left ACME in March 2025”). In practice, much of professional prompting handles personal data without users being aware.

Does the DPF (Data Privacy Framework) secure the use of a US LLM?

The DPF makes EU-US transfer to a certified provider technically lawful — in April 2026, OpenAI, Anthropic, Google are members. But the DPF remains contested and several European DPAs (German BfDI, Italian Garante) recommend additional measures despite its adoption. For strategic AI use, not depending solely on the DPF is more prudent.

What does the AI Act require for team training?

AI Act Article 4 requires organisations to ensure that people using an AI system in a professional context have a “sufficient level of literacy”, adapted to use context. This obligation entered into force in February 2025 for most systems. See our business AI training guide.

What if a person requests deletion of their data used by an LLM?

If the data is in a SaaS system with configurable retention (ChatGPT Enterprise, Mistral Le Chat Enterprise), deletion is generally operable via API or support. If the data has contributed to training a model, strict deletion is technically impossible (weights cannot be “untrained backwards”). The EDPB tolerates alternative measures (output filtering, periodic retraining) under the condition of demonstrating their effectiveness.

Sources: Regulation (EU) 2016/679 (GDPR); Regulation (EU) 2024/1689 (AI Act), notably articles 4, 9, 35; CNIL recommendations on AI and personal data (cnil.fr); EDPB opinion 28/2024 on AI models and GDPR; Garante per la protezione dei dati personali, OpenAI 2023 and 2024 decisions; CJEU Schrems II ruling, 16 July 2020 (C-311/18); European Commission, Data Privacy Framework adequacy decision, 10 July 2023.

For framing the compliance of a specific AI project, see our GDPR compliance guide, our sovereign AI analysis and the AI literacy obligations for teams.