GDPR and AI tools: it's easier than you think to break the rules

ChatGPT is not a GDPR problem by itself. It becomes one the moment you paste in a person’s name, an email address, a case record, an HR document. That happens constantly, without anyone thinking about it.

The issue is not that employees use AI. It is that the threshold for a breach is low, and most organisations do not know where that threshold is.

Why personal accounts are risky

GDPR Article 28 requires a binding contract when a third party processes personal data on your organisation’s behalf. Article 28(3) states:

“Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller.”

With a personal AI account, that contract does not exist. Your employee chooses the provider themselves. You have no agreement with that provider. No control. No visibility.

If personal data is sent into that session, you have a problem. And it is easy to do without noticing: the name of a contact person at a client in an email draft, a case with a national identity number, an HR document you want summarised. It does not have to be intentional to be a breach.

It is the account and the contract, not just the tool

ChatGPT, Claude, Gemini: the tools themselves are not the problem. The real issue is which account is used, and which contract actually governs that account.

With a personal consumer account, your organisation is usually outside the contract. Anthropic’s privacy policy says it does not apply when an employer has provisioned a Claude for Work account, which leaves consumer use on the privacy-policy track instead.¹ OpenAI draws the same line between consumer plans and business services. ChatGPT Business and ChatGPT Enterprise sit under the OpenAI Services Agreement, and that agreement incorporates OpenAI’s DPA.²³

In practice, that means:

1. Your organisation is often not the customer in the contract
2. You cannot give documented instructions under Article 28
3. You cannot rely on a DPA that may not cover that account at all
4. You get weaker visibility into subprocessors, deletion, and incident handling

Nobody in your organisation can audit that session. You are the data controller for that data, but you have zero control over how it is handled.

Personal accounts: a simple decision

This should not be a policy with grey areas and case-by-case assessments. It should be a rule:

Work data is not processed in personal AI accounts. Ever.

It does not matter if it is “just” an email draft. If personal data is in it (names, email addresses, case records, contract details) Article 28 applies. The rule needs to be simple enough to follow without thinking.

Employees using personal accounts today are not acting in bad faith. They lack an alternative. Give them one.

Corporate accounts solve half the problem

With an organisation-managed business workspace, such as Claude Team, Claude Enterprise, ChatGPT Business, or ChatGPT Enterprise, the provider’s business terms and DPA can apply to that workspace.⁴⁵²³ That gives you at least a contractual route for instructions, subprocessors, deletion, and oversight. But it does not happen automatically just because someone paid for a plan. Your organisation has to be the actual customer, and the account has to sit under the right terms.

That is necessary. But it is not sufficient.

Article 5(1)(c) of GDPR (data minimisation) applies regardless of what agreement you have:

“adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’)”

You need to ask: do we need to include the personal data at all?

In many cases the answer is no. You can anonymise, pseudonymise, or refer to a case without pasting in names, national identity numbers, and contact details. It reduces risk, reduces exposure, and is good practice regardless of what agreement you have with the provider.

What you actually need to do

Step 1: Prohibit personal accounts, no exceptions. Put it in a policy. Communicate it. Give clear examples of what counts as work data. Not “sensitive data”: work data. Emails, case records, contracts, HR information, customer data.

Step 2: Give people a corporate account. It does not need to be everyone. Identify the roles that regularly handle personal data in AI tools and start there. A policy without an alternative is a declaration, not governance.

Step 3: Train for data minimisation. Even with a corporate account: train people not to paste in more than necessary. “Describe the customer’s situation” is not the same as “paste the case record with name and national identity number.”

Step 4: Inventory what is being used. You cannot address a problem you cannot see. Ask managers in each department. A short inventory is enough.

Policies without alternatives solve nothing

It is tempting to send an email and consider the matter closed. It does not work if the personal account is the only available tool.

Give people an alternative. Explain why the rule exists. Make it easy to do the right thing.

GDPR Articles 28 and 5 are not administrative requirements to wave away. They exist to protect the people whose data you handle. Personal AI accounts make it hard, and often impossible, to meet Article 28 when personal data is processed for work without an agreement between the provider and your organisation. And even with an agreement in place, the minimisation requirement remains.

This article is part of a series. The parent article Why do we pay for software AI can build for free? goes deeper into shadow AI, vibe coding, and the wider business consequences. See also Shadow AI: managers build tools IT doesn’t know about for a deeper look at the shadow AI phenomenon specifically.

---

Would you like to see how AmpliFlow helps structure an AI policy and manage which tools are used in your organisation? Book a walkthrough.

Footnotes

1. Anthropic, Privacy Policy (effective 12 January 2026). The policy applies where Anthropic acts as controller, for example in consumer use, and says it does not apply where an employer has provisioned a Claude for Work account. Source. ↩

2. OpenAI, OpenAI Services Agreement (effective 1 January 2026). The agreement covers ChatGPT Business, ChatGPT Enterprise, and other business services. Source. ↩ ↩²

3. OpenAI, OpenAI Data Processing Addendum (effective 1 January 2026). The DPA is incorporated into the OpenAI Services Agreement. Source. ↩ ↩²

4. Anthropic, Commercial Terms of Service (effective 17 June 2025). Anthropic’s commercial services sit under separate business terms. Source. ↩

5. Anthropic, Data Processing Addendum (effective 24 February 2025). The DPA forms part of Anthropic’s commercial terms. Source. ↩