AI and Data Protection: Working GDPR-Compliant

AI and data protection in one sentence

The moment you enter personal data into an AI service, that's processing within the meaning of the GDPR — with everything that entails: a legal basis, a data processing agreement, transparency toward the people affected, and clarity about where the data ends up.

The GDPR has no AI exception. A prompt containing a customer's name is legally no different from an email with the same name — except this time the recipient is a US provider that may use the content to train its model. That's exactly where the typical problems come from.

> Note: This article is for orientation and doesn't replace legal advice. Assessing a specific processing activity belongs in the hands of your data protection officer or a specialized law firm.

The most common mistake: personal data in the prompt

In practice, the data protection violation almost never happens in the big system project — it happens on the side. Someone copies a job application into the chat to have it summarized. Someone pastes in a customer conversation to draft a quote from it. Someone uploads a list of participants to sort it.

Personal data covers more than most people assume: names, email addresses, phone numbers, customer numbers, application documents, call transcripts, photos, IP addresses — and any combination of details that makes a person identifiable. Especially sensitive are the special categories under Article 9 of the GDPR: health data, union membership, religious or political beliefs, biometric data. These have no place in a general-purpose AI assistant, as a rule.

The simplest countermeasure is data minimization. For most tasks, the model doesn't need the personal reference at all. “Draft a rejection letter to Mr. Müller, 47, from Dortmund” doesn't produce a better result than “Draft a friendly rejection to an applicant whose professional experience doesn't match the role.” Pseudonymize, shorten, omit — that resolves a large share of cases before any contract is even needed.

The contractual basis: DPA, legal basis, register

If personal data is unavoidable, you need three things.

A data processing agreement (DPA). The AI provider processes data on your behalf — Article 28 of the GDPR requires a contract for that. The major providers offer corresponding Data Processing Addenda, but often only for their business tiers. A private consumer account has no such basis. That's the real reason professional use requires a business plan, not the higher usage limits.

Legal basis. Every processing activity needs a lawful basis under Article 6 — usually legitimate interest or contract performance, or, for employee data, often a works council agreement. Consent is rarely the most solid choice in an employment context, because it must be given voluntarily.

Record of processing activities. Under Article 30, AI use belongs in the register: purpose, data categories, recipients, third-country transfers, deletion periods. It's tedious work, but it's also the first thing a supervisory authority asks about.

If AI is used in a high-risk context — applicant selection, performance evaluation, automated decisions about people — a data protection impact assessment under Article 35 is also required. And Article 22 sets a hard limit: purely automated decisions with a significant effect on people are only permitted in narrow exceptions. In practice, that means: A human must decide, not the model.

Data residency and third-country transfers

Most high-performing models are operated by US companies. A data transfer to the US is only permitted under Chapter V of the GDPR with a suitable legal basis — currently typically via the EU-US Data Privacy Framework adequacy decision combined with standard contractual clauses.

The last option is more realistic today than many think — open models now run on ordinary office hardware. How that works in practice is shown in Using Local LLMs & Open-Source Models. Be honest about the trade-off, though: what you gain in data protection, you pay for in model quality and operational effort.

Provider settings: turning off training

The question “Is our input used for training?” depends less on the provider than on the plan.

• With private consumer plans, training use is often on by default and has to be actively turned off — where that's even possible.
• With business plans (Team, Business, Enterprise), it's contractually excluded. That's the real difference between private and business tiers, not the feature set.
• With API access, the major providers likewise typically don't train on customer data, often combined with short retention periods for abuse monitoring.

Always check three additional settings as well: retention period for chat histories, logging and access by support staff, as well as storage location. What's specifically defined in the plans of the major assistants is covered in ChatGPT for Business .

One special problem remains: the rights of data subjects can hardly be fully enforced once a model has been trained on their data. Once data has been absorbed into the model weights, targeted deletion isn't technically clean to achieve. That's why prevention is more effective here than any after-the-fact fix.

AI data protection and the EU AI Act: two layers

Both frameworks apply side by side and answer different questions. The GDPR asks: Whose data is being processed here, and how? The AI Act asks: What harm could this system cause? A system can be perfectly clean from a data protection standpoint and still be AI Act-relevant — for example, an application pre-filter that only works with anonymized data but still counts as a high-risk application. You'll find the underlying structure in The EU AI Act Explained Simply.

In practice, it pays to run this as a single project: you'll need a system inventory, role clarification, and documentation for both frameworks anyway.

The everyday checklist

1. Check the plan. A business plan with a DPA — no private account for company data.
2. Sign and file the DPA. Including sub-processors and the transfer basis.
3. Exclude training use. Verify it contractually, check it in the settings.
4. Clarify storage location and retention. Activate EU residency where available; set deletion periods.
5. Log it in the register of processing activities. Purpose, data categories, recipients, third-country transfers.
6. Make data minimization the rule. Pseudonymize instead of copying — that's the single most effective measure.
7. Define prohibited data categories. Health data, application documents, draft contracts, access credentials.
8. Ensure human decision-making. No automated decisions about people without review.
9. Train your team and put the rules in writing. Without an internal policy, the rest is theory — see An AI Policy for Your Company.
10. Review regularly. Provider terms and features change, so your register needs to keep up.

Conclusion

GDPR-compliant AI use isn't rocket science — it's organizational work. The three levers with the biggest effect: use a business plan with a DPA, consistently minimize personal data, and put what's allowed in writing. Anyone who has these three points covered has eliminated most of the risk — and doesn't need to ban AI out of uncertainty, which in practice just pushes usage into the shadows on private accounts anyway.