GDPR was written before this generation of AI tools existed and applies to them without difficulty, because it regulates what happens to personal data rather than which software does it. Most of the analysis is unremarkable third-party processing. One part is genuinely unresolved, and it is worth knowing which is which.
⚠️ This is general information, not legal advice
Compliance depends on your specific circumstances, jurisdiction and the terms you have agreed. Regulatory guidance in this area is also still developing.
Use this to understand the shape of the questions and to have a better-informed conversation with someone qualified — not as a substitute for that conversation.
The short version
Sending personal data to an AI service is processing by a third party. You need a lawful basis, a processor agreement, a transfer mechanism if data leaves the region, and you must minimise what you send.
The unresolved part: Article 17 gives a right to erasure, and trained weights cannot be un-trained.
Controller or processor
Everything else follows from this, and it is the question most often skipped.
| Scenario | You | The provider |
|---|---|---|
| API, no training on your data | Controller | Processor |
| Provider trains on your data | Controller | Also a controller |
| Employee uses a personal account | Murky — often nobody has done the analysis | |
The middle row is the important one. A processor acts only on your documented instructions. A provider using your data to improve its own models is pursuing its own purpose, which is characteristic of a controller rather than a processor — and that changes the obligations, the necessary transparency to data subjects, and arguably whether the arrangement works at all for personal data.
This is why the enterprise or API tier is not merely a commercial preference. Terms that exclude training keep the provider in the processor role, which is the relationship the rest of your compliance position assumes.
Lawful basis
Article 6 requires one before any processing of personal data. The realistic candidates for business use:
- Legitimate interests — the common choice, requiring a documented balancing test weighing your interest against the individual's rights. Not available to public authorities for their tasks.
- Contract — where processing is genuinely necessary to perform a contract with the individual. "Necessary" is read narrowly.
- Consent — freely given, specific, informed, withdrawable. Rarely appropriate in an employment context, where the power imbalance undermines "freely given".
- Legal obligation — where a law requires the processing.
Two further points that catch people. Special category data — health, biometrics, race, religion, sex life, political or philosophical views, trade union membership — needs an Article 9 condition as well as an Article 6 basis, and the available conditions are narrow. And purpose limitation means data collected for one purpose cannot simply be repurposed: feeding a customer database into an AI analysis is a new purpose that needs its own assessment.
Minimisation is the practical lever
Article 5(1)(c) requires personal data to be adequate, relevant and limited to what is necessary. Applied to prompts, this is the most actionable obligation in the whole framework.
This is the rare compliance requirement that costs nothing and improves the result — fewer tokens, less noise, better model output. It is also easy to evidence, which matters because accountability under Article 5(2) requires you to demonstrate compliance rather than merely achieve it. The mechanics are in redacting a document before sending it to an AI, and the reason metadata deserves separate attention is in metadata is a bigger privacy risk than your content.
💡 Pseudonymisation is explicitly recognised
GDPR names pseudonymisation as an appropriate safeguard. Replacing names and identifiers with tokens before sending, and mapping back locally afterwards, keeps the analytical value while materially reducing what the provider receives.
It does not take the data outside GDPR — pseudonymised data is still personal data, because you hold the key. Anonymous data is outside scope, and true anonymisation is a much higher bar than most people assume.
The processor agreement
Article 28 requires a written contract with specific terms whenever a processor handles personal data on your behalf. Providers publish these as a DPA — the practical step is to actually execute it, because many are opt-in rather than automatic.
The terms to check: purpose and duration, confidentiality obligations, security measures, rules on engaging sub-processors, assistance with data subject requests, deletion or return at the end, and audit rights. And critically — does the agreement you signed match the tier you are using? A DPA executed for an enterprise account does not cover an employee's personal free-tier usage.
International transfers
Most major AI providers are US-based, so transfers out of the EEA or UK are the norm rather than the exception. Chapter V requires a mechanism — an adequacy decision covering the destination, standard contractual clauses with a transfer risk assessment, or binding corporate rules.
The detail worth knowing: the analysis has to cover sub-processors, not just the provider. Hosting, inference infrastructure and moderation services may sit in different jurisdictions again, and the provider's published sub-processor list is where that question gets answered. If you have a data residency requirement, that list — not the marketing page — is the document to read, and regional processing options where offered are the cleanest way to avoid the question.
The part that is not resolved
Everything above is ordinary third-party processing analysis. This is not.
Machine unlearning is an active research area and does not currently offer a reliable, verifiable answer at scale. So a system that has trained on personal data cannot straightforwardly honour an erasure request in respect of the model itself — and rectification under Article 16 has the same problem.
The practical conclusion is not that AI is unusable. It is that the training question is the one to get right, because it is the only irreversible step:
- Use tiers that exclude training on your data. This keeps the provider a processor and avoids the erasure problem entirely.
- Never train on personal data without a genuinely considered position on how you would honour erasure and rectification.
- Minimise and pseudonymise, so that even in a mishap the exposure is small.
- Document the reasoning. Accountability means being able to show the decision was thought about.
DPIAs and automated decisions
A DPIA is required where processing is likely to result in a high risk to individuals. Large-scale processing, special category data, systematic monitoring, and the use of novel technology all push toward one — and several regulators have listed AI processing among the categories that warrant assessment.
Separately, Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects. If a model output drives an outcome about a person — hiring, credit, benefits, access — with no meaningful human involvement, that is a distinct obligation and a rubber-stamp review is unlikely to count as meaningful.
🚨 The realistic exposure is unsanctioned use
Most organisational breaches here are not a flawed enterprise agreement. They are an employee pasting customer data into a personal free-tier account under consumer terms, outside any DPA, with no record that it happened.
No amount of contractual diligence addresses that. Providing a sanctioned tool with acceptable terms — and making it the easy path — does more than a policy telling people not to, because the policy competes with a deadline and loses.
Minimising before you send?
Extract pages and strip metadata entirely in your browser — the file never leaves your device.
Open PDF Splitter →Summary
- Establish the roles first. Training on your data can make the provider a controller.
- You need an Article 6 basis, plus an Article 9 condition for special category data.
- Purpose limitation applies — repurposing existing data is a new decision.
- Minimisation is the practical lever, and it costs nothing.
- Execute the DPA, and check it covers the tier actually in use.
- Transfer analysis must include sub-processors.
- Erasure and trained weights are unresolved — so avoid training on personal data.
- Unsanctioned personal-account use is the real exposure.
Frequently Asked Questions
Is my company the controller or the processor when using an AI API?
Usually you are the controller, since you decide the purposes and means of the processing, and the AI provider acts as a processor on your instructions. That flips where a provider uses your data for its own purposes such as training its models, at which point it may be acting as a controller in its own right and the analysis changes.
Do I need a lawful basis to send personal data to an AI tool?
Yes. Processing personal data requires a lawful basis under Article 6 regardless of which technology performs it, and sending data to a third-party service is processing. Legitimate interests and contract are the usual candidates for business use, each with its own conditions and documentation expectations.
Does data minimisation apply to AI prompts?
Directly. Article 5(1)(c) requires personal data to be adequate, relevant and limited to what is necessary, so pasting an entire document when the task needs two fields is a minimisation problem, not merely an inefficiency. It is also one of the easiest issues to fix and to evidence.
Can personal data be erased from a trained model?
Not by any available technical means. Training distributes influence across billions of parameters with no index back to source records, so there is no operation that removes one person's data. This creates a real tension with the right to erasure and is a strong argument against allowing training on personal data at all.
Do I need a DPIA before using an AI tool?
If the processing is likely to result in a high risk to individuals, yes. Large-scale processing of personal data, special category data, systematic monitoring and automated decisions with significant effects all point toward requiring one, and novel technology is itself a factor regulators weigh.