Is ChatGPT GDPR compliant for company data?

Yes, conditionally, and the conditions are the whole story. The GDPR does not certify tools, it governs processing: the same chatbot can be used lawfully by one team and unlawfully by the team next door. What separates them is which account tier they bought, whether a data processing agreement exists, whether inputs are used for training, and what data anyone is actually pasting in.

That last point is the one most policies miss. Nobody in your company is deciding "shall we use AI"; they are deciding, forty times a day, whether this particular paragraph can go in the box. A policy that answers that question in one page beats a procurement review that answers nothing.

The short answer, and the four conditions

Any AI assistant can be part of GDPR-compliant processing if four things hold at once.

1. A legal basis for the underlying processing, which you needed anyway. The AI tool does not create one and does not remove one.
2. A processing agreement with the provider under article 28, because personal data in your prompts makes them a processor.
3. No training on your inputs, in writing, in the terms you actually signed rather than in a blog post by the vendor.
4. A retention answer: how long prompts are kept, by whom, and whether you can switch it off.

Miss one and you do not have a compliance problem in theory; you have a paragraph you cannot write in your own privacy notice. That is usually the moment teams discover the gap.

Consumer account or business account: the difference that matters

Providers sell the same model twice, on very different terms. The model is not what changes.

	Consumer subscription	Business or API tier
Processing agreement	Usually none	Standard, often self-serve
Training on your inputs	Often the default, sometimes opt-out	Normally excluded by contract
Retention control	None	Defined, sometimes configurable
Who is accountable	The employee who signed up	Your organisation
Suitable for	Public material, personal use	Internal and customer data, under the conditions above

Read your own contract rather than this table, because the terms move. The check takes ten minutes: open the terms, search for "train", search for "retention", and look for the words "data processing agreement". If a search for those three turns up nothing, you are on a consumer product, whatever the invoice says.

Compliance is not a property of the tool. It is a property of the arrangement between you, the provider and the data you send.

Do I need a DPA to use AI at work?

If other people's personal data ends up in your prompts, yes. You are the controller, the AI provider is the processor, and article 28 requires the agreement to be in writing. That is true of a summariser, a support-ticket drafter and a coding assistant that happens to see a customer name in a stack trace.

Ours is summarised on the DPA page and the signable text is one email away, not a sales call, which is a decent standard to hold any provider to: if the terms only appear once you are in a procurement process, that tells you how often they change.

Two things people expect a DPA to do that it does not. It does not give you a legal basis. And it does not make special category data safe to paste; health, biometric and similar data need their own assessment, and the French regulator's guidance on AI and the GDPR is a reasonable starting point for what that assessment should cover.

The four data classes, and what may go where

The reason a blanket ban fails is that most of what people paste is harmless, and the ban trains them to ignore you before they reach the part that is not.

Public

Anything already published: your own marketing copy, a public FAQ, a press release, open documentation. Any tool, any account. There is nothing to leak.

Internal

Roadmaps, drafts, internal metrics, meeting notes without third-party personal data. No GDPR problem, real commercial harm if it surfaces. Business account, and check the training clause, because a model trained on your roadmap is a model that can be prompted about it.

Confidential

Customer contracts, supplier terms, anything covered by a confidentiality clause you signed, plus ordinary personal data such as names, emails and account histories. Approved tool only, under a DPA, with training excluded. This is the class where "we just used the free one" turns into a breach notification conversation.

Regulated

Health data, biometrics, criminal records, union membership, and anything feeding an automated decision about a person, such as sifting job applicants. Not a tooling question. This needs a documented assessment first, and often the honest answer is that the process should not be automated at all.

Shadow AI is the actual risk, not the datacentre

Most company data reaches an AI provider through an employee's personal account on a Tuesday afternoon, not through a procurement decision. Blocking the domain moves that to a phone, where you can neither see it nor log it.

The fix is unglamorous: approve one tool, make it easy to reach, and write down what may go in it. People follow a rule they can remember. They route around a rule that costs them twenty minutes and a ticket, and the second kind of rule is how a customer contract ends up in a consumer chatbot.

The European Data Protection Board's Opinion 28/2024 on AI models is worth reading here, if only for the tone: its recurring answer is that these questions have to be assessed case by case. That is also the practical lesson. There is no setting that makes this go away, only a decision someone has to own.

A one-page AI usage policy you can copy

Short enough that people read it, specific enough to act on. Adapt the tool names and the owner, keep the shape.

1. Approved tools. Name them. One is enough. Anything else needs a request to the owner named below, and the request usually takes a day, not a quarter.
2. What may go in. Public and internal material, freely. Confidential material only in the approved tool. Regulated data never, without written sign-off.
3. What never goes in. Credentials, API keys, personal data of applicants or patients, anything covered by professional secrecy, and anything you would not put in an email to the wrong address.
4. Check the output. Models are wrong with conviction. The person who used the tool owns the result, in exactly the way they own a spreadsheet formula they did not check.
5. Say when you used it. No confessional, just a line in the doc where AI drafted something a colleague will rely on.
6. Report mistakes without drama. If confidential material went somewhere it should not, tell the owner the same day. A quiet mistake becomes a late breach notification, which is the expensive kind.
7. Who owns this. One name, one email, one review date. A policy without an owner decays into a wiki page nobody has opened since onboarding.

Print it, put it in the handbook, spend fifteen minutes on it at a team meeting. That is a bigger compliance win than any vendor questionnaire.

What changes with a European provider, and what does not

It shortens one conversation. If inference happens on infrastructure inside the European Union, the transfer analysis stops being the hardest paragraph in your documentation, and the question "where does this data go" gets a short answer you can put in a privacy notice. The full request path is worth understanding once, because it is also the shape of the answer you will give your own customers.

It changes nothing about the other three conditions. You still need a legal basis, a written agreement, a retention answer and a policy people follow. And it does not make the provider's own chain magically European: ours is published in full, including the three parties with a United States parent entity, because a list that hides those is marketing rather than transparency. What the word sovereign is actually worth, layer by layer, is picked apart in European sovereign AI.

Five checks before you approve a tool

Run these before the pilot, not after the rollout. They take an afternoon.

1. Find the data processing agreement. If there is not one, the tool is out for anything but public material.
2. Search the terms for "train". Read every hit, including the ones about "service improvement", which is often the same thing in a nicer coat.
3. Ask for the subprocessor list. With regions and legal entities. Then count the parents outside the EU, not to disqualify them but to know the number.
4. Ask what happens to a prompt after the answer. Kept for how long, visible to whom, and can you turn it off.
5. Check what your own privacy notice would have to say. If you cannot write that paragraph honestly, you have your answer, and it arrived before the contract rather than after it.

None of this requires a lawyer for the first pass. It requires someone with an afternoon and a habit of reading the clause rather than the landing page. Once a tool clears those five, the remaining question is which kind of provider you want at all, and the four realistic options are compared in European AI providers compared.