Compliance
GDPR and AI: using ChatGPT, Claude and LLM APIs with personal data
Short answer
The GDPR doesn't ban using ChatGPT, Claude or LLM APIs with personal data, but you remain the controller. You need a legal basis, a processor agreement, a lawful transfer route and often a DPIA. Masking personal data before it reaches the provider is a strong minimization and pseudonymization measure. It doesn't replace those duties.
It's 4:40 on a Thursday. A support agent in Lyon pastes a complaint into ChatGPT to draft a reply: Ada Lovelace, ada@example.com, IBAN CH93 0076 2011 6238 5295 7, a refund of CHF 2,400 that never arrived. Nobody meant any harm. But your company just disclosed a customer's personal data to a third party in another jurisdiction, and the GDPR has something to say about every step of that.
This page walks through what the GDPR (Regulation (EU) 2016/679) asks of a company that uses AI models, which articles matter, how transfers to US providers work as of October 2026, and where a masking layer like Maskflare fits. It's written for privacy, security and engineering teams who have to make AI use defensible, not just possible.
Who is the controller when you use an AI provider?
You are. When your company decides that customer emails go through an LLM to draft replies, you determine the purpose and means of processing, so you're the controller. The AI provider is usually your processor when you use its API or business offering under a data processing agreement. Most large providers offer such terms for API and enterprise plans.
Consumer accounts are different. When an employee uses a personal ChatGPT or Claude account, the provider's consumer terms apply, and the provider may act as a controller for its own purposes, such as service improvement. You can't fix that with a contract you never signed. That's why shadow AI is a GDPR problem first and a security problem second. Provider terms change often, so check the current terms of each provider rather than relying on a summary, including ours.
Which GDPR articles matter most for AI use?
| Article | What it says | What it means for prompts and API calls |
|---|---|---|
| Art. 5(1)(c) | Data minimization: adequate, relevant and limited to what's necessary. | A model drafting a refund reply rarely needs the real IBAN or email. Sending it anyway is hard to justify. |
| Art. 6 | Every processing operation needs a legal basis. | Usually legitimate interests or contract. Document the balancing test for each AI use case. |
| Art. 9 | Special categories (health, religion, ethnicity and others) need an extra condition. | Health details in a support ticket raise the bar. Many teams simply keep them out of prompts. |
| Art. 25 | Data protection by design and by default, naming pseudonymization as an example. | Build minimization into the integration, not into a policy PDF that staff never read. |
| Art. 28 | Processors only under a contract with the required terms. | Sign the provider's DPA for API use. Consumer accounts don't give you one. |
| Art. 32 | Appropriate security, explicitly including pseudonymization and encryption. | Masking before the provider is a textbook Art. 32 measure. |
| Art. 35 | DPIA where processing is likely to result in high risk. | New technology plus personal data at scale usually triggers one. Write it before rollout. |
| Art. 44 to 49 | Chapter V: transfers outside the EEA need an adequacy decision or safeguards. | US providers need the Data Privacy Framework or standard contractual clauses. |
| Art. 83 | Fines up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. | The top tier applies to breaches of the core principles and transfer rules. |
How do transfers to US AI providers work in 2026?
Most frontier models are run by US companies. Sending personal data to them is a transfer under Chapter V. The main route is the EU-US Data Privacy Framework, the adequacy decision the Commission adopted on 10 July 2023. If the provider is certified under the DPF, transfers to it don't need standard contractual clauses. If it isn't, you need SCCs plus a transfer impact assessment.
The framework has been challenged. The EU General Court dismissed the Latombe challenge on 3 September 2025, and an appeal is pending before the Court of Justice as Case C-703/25 P as of October 2026. Privacy Shield was struck down in 2020, so plan for the possibility that this one is too: know which providers you'd switch to SCCs with, or which workloads you'd move to an EU-hosted or self-hosted model.
Masking changes the size of that risk. If the prompt that crosses the Atlantic says mf_mask_170b... where it used to say ada@example.com, there's far less personal data in the transfer to worry about. It doesn't make Chapter V go away, because names in free text or rare details can still slip through, but it shrinks the exposure from the whole customer record to whatever your rules don't catch.
Is masked data still personal data under the GDPR?
Article 4(5) defines pseudonymization as processing personal data so it can no longer be attributed to a person without additional information, kept separately and protected. Recital 26 says pseudonymized data is still personal data. For you, holding the mapping, it certainly is.
The picture from the recipient's side has moved. In its judgment of 4 September 2025 in EDPS v SRB (C-413/23 P), the Court of Justice held that pseudonymized data may not be personal data for a recipient who has no reasonable means to re-identify the people behind it, while the original controller's obligations still apply. The EDPB's Guidelines 01/2025 on pseudonymisation explain how to design pseudonymization so it actually reduces risk. The Commission's November 2025 Digital Omnibus proposal would also touch the definition of personal data, but as of October 2026 it's still being negotiated and isn't law.
Our practical reading: treat everything you send as personal data on your side, and use masking to make the provider's copy as close to non-identifying as you can. Don't build a compliance case on the provider receiving no personal data at all, because free text rarely gets that clean.
How does masking support data minimization?
Maskflare sits between your people, your applications and the model. It finds personal data in the prompt, replaces each value with a reversible token, sends the masked prompt to the provider and restores the original values where the answer repeats them. The agent still gets a reply addressed to Ada Lovelace. The provider never saw her name, email or IBAN.
Before: Draft a reply to Ada Lovelace (ada@example.com). Her refund of CHF 2,400
to IBAN CH93 0076 2011 6238 5295 7 never arrived.
Sent: Draft a reply to mf_mask_8c1e... (mf_mask_170b...). Her refund of CHF 2,400
to IBAN mf_mask_4d07... never arrived.- Apps: point your SDK at the gateway (
https://<your-gateway>/v1/openai,/v1/anthropicand so on). Streaming is masked event by event and values are restored in responses when you switch that on per gateway key. - People: the desktop agent and browser protection mask text typed into ChatGPT, Claude, Gemini, DeepSeek and Perplexity before it reaches the provider, which is where most shadow AI happens.
- Agents: MCP tool-call arguments and results are masked, and coding-agent hooks cover Claude Code, Cursor and Codex CLI.
- Storage: prompts and responses are never logged or stored. Records hold metadata and counts. Original values behind tokens are kept encrypted for 30 days so they can be restored. Maskflare is EU-hosted by default, with on-premises deployment for enterprise.
What do the Maskflare GDPR profile and coverage report do?
The GDPR (EU/EEA) compliance profile turns on the credentials, global and person-name packs plus country packs for the EEA states you choose: all 30 by default (the EU-27 plus Iceland, Liechtenstein and Norway), at least one. A profile is a floor, not a ceiling. Applying it turns detectors on and raises weaker actions to at least mask. It never turns anything off and never lowers an action, so a rule that already blocks keeps blocking. The change goes through your normal approval flow, including four-eyes approval if you use it.
The coverage report then shows, per environment, which GDPR personal-data categories your live policy covers, and it exports as CSV or PDF for your records of processing or a DPIA annex. Each category reads covered, partial, not covered or out of scope. A detector in shadow mode counts as partial, because it only counts matches. We'd rather show you the gaps than hide them:
| GDPR category | What Maskflare detects | Honest limit |
|---|---|---|
| Names | Person names from word lists and context, plus a local named-entity layer | Test unusual names and spellings on your own data |
| National identifiers | ID, tax and social security numbers per country pack, passport MRZ | Partial until at least one country pack is on |
| Contact details | Email addresses, phone numbers in national formats | None noted |
| Location and addresses | Coordinates, street addresses, postal codes per country pack, and places found by the named-entity layer | Test local place names and spellings on your own data |
| Online identifiers | IPv4 and IPv6, MAC addresses, IMEIs, and URLs that identify someone (record IDs, emails, names or social profiles in the link) | Reference links stay readable; turn on the opt-in strict pack to mask every URL |
| Account and card numbers | IBANs, BICs, cards, CVVs, crypto wallets, national account formats | None noted |
| Racial or ethnic origin, religion (Art. 9) | Ethnicity and religion in free text, in English, German, French and Italian | Context-dependent: review alert-mode results before you mask |
| Health data (Art. 9) | Medical record and health plan numbers, EHIC and German KVNR numbers, ICD-10 codes, conditions and medications near health context, genetic variants | Unusually phrased diagnoses can pass; test on your own notes |
| Political opinions, trade union, genetic, sex life, criminal (Art. 9, Art. 10) | Political opinions, trade-union membership, sexual orientation, genetic variants and criminal records in free text | Starts in alert mode; review results before you mask |
| Biometric data | Not text | Out of scope. The file gate can block or scan images |
GDPR requirements, what Maskflare does, and what stays your job
| Requirement | What Maskflare does | What stays your job |
|---|---|---|
| Minimization (Art. 5(1)(c)) | Masks identifiers before the provider sees them | Decide which use cases need personal data at all |
| Legal basis (Art. 6, 9) | Nothing. A tool can't pick your basis | Document the basis and Art. 9 condition per use case |
| By design (Art. 25) | Policy enforced at the gateway, browser and desktop, not left to each developer | Make AI access go through it: block direct provider access where you can |
| Processor terms (Art. 28) | Maskflare is itself a processor; provider keys encrypted per org | Sign DPAs with Maskflare and each AI provider |
| Security (Art. 32) | Reversible pseudonymization, no prompt logging, audit export up to 366 days | Assess residual risk and access to your console |
| DPIA (Art. 35) | Coverage report and audit export as evidence | Write and own the DPIA |
| Transfers (Chapter V) | Shrinks what crosses the border to tokens and unmatched text | Check DPF certification or sign SCCs and do a TIA |
| Data subject rights | Nothing stored to search: prompts aren't kept | Answer requests for data you and the provider do hold |
A practical GDPR checklist for AI use
- List every AI tool and API in use, including the ones staff use without asking. Shadow AI is the usual gap.
- For each use case, record the purpose, legal basis and whether special-category data could appear.
- Move business use onto API or enterprise plans with a signed DPA. Consumer accounts don't give you processor terms.
- Check each US provider's DPF certification on the official list, or put SCCs and a transfer impact assessment in place.
- Route prompts through a masking layer and apply the GDPR profile for the countries you operate in.
- Read the coverage report. Close partial items with country packs, custom dictionaries or Exact Data Match for your own customer records.
- Run the DPIA with the coverage report attached, and repeat it when you add a provider or a new kind of data.
- Train staff on what still must not go into prompts: health details in prose, opinions, anything about criminal matters.
Where masking doesn't help
Masking replaces identifiers. It doesn't understand that "the only cardiologist in Vaduz" points to one person, it doesn't detect a diagnosis written in a sentence, and it doesn't cover audio in voice sessions (text events are masked, audio isn't). It also doesn't decide whether a use case is lawful. Maskflare's SOC 2 Type II and ISO 27001 audits are in progress, and no tool makes you "GDPR compliant" by itself. Use it as one of the technical measures in your Art. 32 and Art. 25 story, alongside contracts, training and a DPIA.
Frequently asked questions
Can employees use ChatGPT at work under the GDPR?
Yes, if the processing has a legal basis, the provider acts under processor terms, transfers are covered and you've assessed the risk. Personal consumer accounts usually fail the processor test, so most companies move staff to a business plan or route use through a masking layer.
Is the EU-US Data Privacy Framework still valid?
As of October 2026, yes. The General Court upheld it on 3 September 2025 and an appeal is pending before the Court of Justice (C-703/25 P). Check the provider's certification on the DPF list and have a fallback plan with SCCs.
Does masking make data anonymous?
No. Masked data is pseudonymized: you can restore it, so it stays personal data for you. For the provider, well-masked prompts carry far less identifying information, and the CJEU's 2025 SRB judgment suggests that can matter from the recipient's side. Treat it as risk reduction, not anonymization.
Do we need a DPIA for using LLMs?
Often, yes. Supervisory authorities' lists commonly include innovative technology combined with personal data at scale. Even when it isn't strictly required, a short DPIA is the easiest way to show you thought about minimization, transfers and residual risk.
Does Maskflare store the prompts we send?
No. Prompts and responses are never logged or stored. Records keep metadata and counts only, and the original values behind tokens are held encrypted for 30 days so answers can be restored.
About the author
Articles on GDPR, the EU AI Act and sector rules, written by the people at Maskflare who answer customers' data protection questions. They're general information, not legal advice; we cite the regulator or the provider's own terms wherever we can.