Someone in your company has already pasted customer data into ChatGPT

They probably weren't trying to bypass policy. They needed a support reply drafted. Or a contract summarized. Or a second opinion on a CV before the interview. It felt harmless, useful, and faster than doing it by hand.

Now the question has worked its way up the org chart and landed on your desk:

Is ChatGPT GDPR compliant, and how much trouble are we in?

The honest answer is no... mostly. Not because the GDPR has a view on ChatGPT as a product (it doesn't certify products, it regulates what controllers and processors do with personal data), but because of how ChatGPT actually gets used. The version happening in your company right now, employees with consumer accounts and customer data in the prompt, is the one you can't defend. The API and the business tiers, with the right paperwork and controls around them, you often can.

Is ChatGPT GDPR compliant? It depends which ChatGPT

"ChatGPT" is at least three different legal situations wearing one name, and most arguments about it go wrong by mixing them up.

The first is an employee with a free or Plus account. That's a consumer contract between OpenAI and the employee. Your company isn't a party to it. There's no data processing agreement. Conversations can be used for model training unless the employee found the setting that says otherwise, and none of the vetting the GDPR expects from you ever happened. So when customer data goes into that chat window, you've disclosed personal data to a third party with no processor contract, no transfer mechanism you chose, and no record of what left. I've never met a DPO who'd even try to defend that.

The second and third are ChatGPT Team or Enterprise, and the API. Here OpenAI will sign a data processing addendum, commits not to train on your business data by default, and includes Standard Contractual Clauses for the transfer. The conversation changes. The rest of this piece is about the work that's still yours after you've signed.

And if you were hoping the enforcement record would settle any of this, it does the opposite. Italy's supervisory authority forced ChatGPT offline in Italy for about a month in 2023, then fined OpenAI 15 million euros at the end of 2024 over the legal basis for training data and transparency failures. In March 2026 the Court of Rome annulled that fine without ever reaching the merits: OpenAI had established an Irish entity in February 2024, which under the one-stop-shop mechanism made the Irish regulator the lead authority, so the Garante wasn't competent to issue it. Sit with that for a second. The only GDPR fine ever imposed over a generative AI launch came apart on the question of which regulator was allowed to ask, and whether the training practices actually complied is still open in both directions. Besides, all of that concerns OpenAI's own processing, as a controller. Your use of the tool is a separate analysis, and nobody else's court case answers it for you.

What Article 28 actually requires

Article 28 is why "we signed the DPA" comes up in every one of these meetings, so here's what's actually in it. If a provider processes personal data on your behalf, you need a written contract that binds them to a specific list:

• process only on your documented instructions
• keep their people under confidentiality
• meet the Article 32 security requirements
• use sub-processors only with your authorization, and pass the same obligations down to them
• help you honor data subject rights, breach notifications, and impact assessments
• delete or return the data when the service ends
• submit to audits so you can check all of the above

Run the tiers against that list and the consumer account fails at line one: there's no contract between OpenAI and your company at all, so nothing further down can be fixed. The business tiers and the API clear most of it on paper, because the DPA exists to cover it. Article 28, the article everyone cites, is usually the most solvable part of the whole problem.

One thing does get missed, mostly by teams building products rather than buying tools. Ship a feature on the API and, to your customers, you're the processor and OpenAI is your sub-processor. Article 28 flows down the chain: your own DPA has to disclose that, and your customers' DPOs will ask you every question in this article, so have answers before they do.

Does signing a DPA make you compliant?

No, for two reasons. Accountability doesn't transfer: Articles 5(2) and 24 put the burden of demonstrating compliance on you, the controller, and no contract moves it. I've learned that limit from the vendor side: even an explicit, recorded acknowledgement doesn't fully move liability between the parties, and neither does whatever you sign with OpenAI. And the DPA's scope is OpenAI's obligations as your processor, so yours as controller sit outside it, untouched: lawful basis under Article 6, transparency under Articles 13 and 14, minimization under Article 5(1)(c), the Article 30 records that prove any of it happened. Sign the DPA, then file it under "starting point".

Is the transfer to the US legal?

It can be. Chapter V of the GDPR, Article 44 onward, says every transfer out of the EEA has to stand on a mechanism, and for the US that's either the EU-US Data Privacy Framework or Standard Contractual Clauses plus a transfer impact assessment, the post-Schrems II homework. Which one applies depends on your contract and which entity serves you, so check, and write down what you find: an assessment you didn't document is an assessment that didn't happen. And remember what a mechanism does: it legalizes the route, nothing more. What travels down it is still your problem under minimization, and your analysis turns on where the inference runs, not where the data is stored.

Is pseudonymized data still personal data?

Yes, and the appeal of the shortcut is obvious: strip the names before you send, and the GDPR stops applying... except it doesn't. Recital 26 says data you can tie back to a person using additional information is still personal data, and you keep the mapping, because you need the answer to be about the right customer: that's pseudonymization by definition, not anonymization. So a scrubbed prompt sent to a US model is still a transfer, and everything in the previous section still applies. Scrubbing is still worth doing: it's privacy by design under Article 25, it shrinks what any incident can expose, and it's why our PII firewall pseudonymizes every request before an external model sees it, on by default. But it reduces what's exposed, it doesn't turn a transfer into a non-transfer, and any vendor telling you otherwise is selling you a future audit finding.

Do we need a DPIA?

Probably, and planning for one is cheaper than arguing about whether you need one. Article 35 requires a data protection impact assessment where processing is likely to be high risk for the people involved, particularly with new technologies. The criteria European regulators use include:

• innovative technology
• sensitive data
• vulnerable people
• processing at scale
• evaluating or scoring individuals

The working rule: hit two and you do one. Generative AI hits innovative technology all by itself, and if you're handling patient notes, claims, payroll, or minors' data, you'll hit a second one without trying.

The DPIA is more useful than its reputation: it requires a systematic description of the processing (which data, from where, to which systems, in which countries, kept how long), and that's a data-flow map. It's also the document most teams discover they can't produce, even though everything else in this article depends on it.

The question underneath all of these

Every section above bottoms out in the same place: the Article 28 vetting, the transfer assessment, the DPIA, the Article 30 records all assume you can say where your data actually goes, per request, and prove it later, which is what accountability under Article 5(2) means in practice. Most teams can't; ask "where did this specific request go" and what you'll get is a policy document and a dig through Slack.

I've written the code that makes this decision for our platform, and writing the individual rules wasn't the hardest part. The hard part was deciding what should happen when no rule matches: allow unless a rule blocks, which is how quiet leaks happen, or block unless something explicitly allows. Ours fails closed, a request reaches a non-EU model only when it's pseudonymized or carries a recorded acknowledgement, every request writes a metadata-only audit record of which model ran, where, and why, and whatever you use, that's the shape to ask for.

What I would actually do this week

Separate the two problems first: employees pasting into consumer ChatGPT is a shadow-IT problem, the AI features you're building are an engineering and paperwork problem, and mixing them up stalls both. Close the consumer hole with an alternative, not just a ban, or the pasting moves to personal phones. Map the flows feature by feature (what data, which endpoint, which country, under which mechanism), minimize and pseudonymize what leaves, and decide what never leaves at all: your crown jewels pinned to EU-resident processing with no override. Then put the rule in code, failing closed, with per-request records, so the policy becomes something an auditor can watch working. None of this needs anything from us; it does need someone to decide that "where does our data go" gets answered by a system instead of by whoever happens to be asked.

Where Akumi fits

Akumi is the platform version of everything above. One OpenAI-compatible endpoint. EU-sovereign models served in the EU by default. External models, OpenAI's included, behind a fail-closed egress guard, a PII firewall that's on by default, and a per-request, metadata-only audit trail. We built it because we kept watching good teams have to choose between shipping AI features and being able to answer their DPO.

What I won't do is tell you Akumi makes you GDPR compliant. Nothing does, off the shelf. What a platform can do is make the controls this article keeps arriving at (residency enforced in code, pseudonymization by default, evidence per request) the path of least resistance. If this is the conversation on your desk, here's what that looks like.

Practical guidance from a founder who builds for this problem, not legal advice. Your data, your sector, and your regulator are specific, so involve your DPO and your lawyers. The good ones will recognize everything above.