Your organization has spent years justifying why it collects, uses, and retains personal data under the General Data Protection Regulation (GDPR). Now, a business unit adopts an AI tool that performs better with more data, more history, and more granularity. This pattern may put organizations in breach of EU and UK data privacy rules, especially when AI tools demand ever-larger datasets and individuals aren't informed about what data is used or why.
You're faced with a practical question: on what basis can this processing continue? The answer determines your consent mechanics, retention design, and audit exposure. This guide walks through the decision process as a series of if/then paths.
The Decision You Are Facing
For each AI use case involving personal data, you must select and document a lawful basis under Article 6 before processing begins. You must also show the processing satisfies Article 5(1)(c) (data minimization), Article 5(1)(b) (purpose limitation), and Article 5(1)(e) (storage limitation). Three paths are realistic: consent, legitimate interests, or redesigning the data inputs to minimize personal data. Your choice depends on the factors below.
Key Factors That Affect Your Choice
Answer these before picking a path.
1. Is the purpose specified and stable? Purpose limitation requires a defined purpose at the point of collection. "Improve our services with AI" rarely meets that bar. If the purpose will drift as the model evolves, consent and legitimate interests both become fragile.
2. Does the data include special category data? If so, Article 9 applies on top of Article 6. You need a separate Article 9 condition, and explicit consent is often the only workable one for commercial AI.
3. Is there a real relationship with the individual? Consent requires a free choice. In employment contexts, imbalance of power undermines it.
4. Are decisions solely automated with significant effects? Article 22 restricts these, and Article 35 will likely require a Data Protection Impact Assessment (DPIA).
5. Can you withdraw and delete? Consent must be as easy to withdraw as to give (Article 7(3)). If personal data is baked into trained model weights or derived datasets, ask whether you can actually honor withdrawal and erasure under Article 17.
6. Can you describe what data the model needs? If your team can't articulate why each data field is necessary, minimization fails regardless of lawful basis.
Path A: Choose Consent When...
Consent fits when you have a direct relationship with individuals, the AI purpose is specific and explainable, and you can build real withdrawal into the architecture.
If you're processing special category data for AI features the individual chose to use, then pursue explicit consent under Article 9(2)(a).
If you're repurposing existing data for a new AI use that is incompatible with the original purpose (Article 6(4)), then fresh consent is usually the cleanest route.
What Article 7 and Recital 32 demand in practice:
- Granular, unbundled consent. AI training should not be hidden inside general terms.
- Plain-language notice of what data is used and for what purpose (Articles 13 and 14).
- A consent record: who, when, what wording, which version.
- A working withdrawal workflow that reaches training sets, feature stores, and derived data.
Consent's weakness is operational. Every consent record becomes a record in its own right, which means it needs a Records Control Schedule entry and a defined cutoff. If you can't prove consent years later, you effectively didn't have it.
Path B: Choose Legitimate Interests When...
Legitimate interests (Article 6(1)(f)) suits cases where consent is impractical but the processing is reasonably expected by individuals and the privacy impact is modest.
If the AI use is low-risk, such as fraud detection, network security, or internal process analytics, then legitimate interests may be defensible.
If consent wouldn't be freely given (for example, in employment), then this path is often stronger than a consent that regulators would reject.
You must complete and keep a three-part Legitimate Interests Assessment: purpose, necessity, and balancing. The necessity step is where the minimization conflict surfaces. "More data improves accuracy" is a benefit argument, not a necessity argument. You need to show that a less data-intensive approach wouldn't achieve the purpose.
Avoid this path where the processing involves children's data, special category data without an Article 9 condition, or intrusive profiling that individuals wouldn't anticipate. Also, remember individuals keep a right to object under Article 21.
Path C: Redesign the Inputs Before Choosing a Basis
Sometimes the correct answer is that neither basis survives scrutiny on the current design. This path applies when your team cannot justify the volume, retention period, or granularity of the data.
If the model can perform adequately on pseudonymized or aggregated data, then reduce identifiability at ingestion and document the reasoning.
If training data is retained indefinitely "in case it's useful," then set retention by purpose and apply Event-Based Retention tied to model lifecycle events, such as model retirement or purpose completion.
If you cannot map which records feed which model, then stop and build that lineage first. You can't honor erasure, retention, or Legal Hold obligations on data you can't locate.
Practical steps:
- Maintain a data inventory linking source systems to AI training and inference datasets.
- Apply your Business Classification Scheme to AI datasets so they inherit retention and disposition rules.
- Require Records Disposition Authority before training corpora are deleted, and suspend disposition under a Legal Hold when litigation is reasonably anticipated.
- Run a DPIA before deployment, and revisit it when the model's data inputs change.
This path also serves your governance posture. The Generally Accepted Recordkeeping Principles of Accountability, Integrity, Retention, and Disposition map directly onto what a regulator will ask you to demonstrate.
Summary Matrix
| Factor | Path A: Consent | Path B: Legitimate Interests | Path C: Redesign Inputs |
|---|---|---|---|
| Best when | Direct relationship; specific purpose | Low-risk, expected processing | Necessity can't be shown |
| Key provisions | Arts. 6(1)(a), 7, 9(2)(a), 13-14 | Art. 6(1)(f), Art. 21 | Arts. 5(1)(b), (c), (e), 25, 35 |
| Special category data | Workable with explicit consent | Not sufficient alone | Reduce or exclude |
| Main risk | Withdrawal and erasure from trained models | Failing the necessity test | Slower delivery, internal pushback |
| Records burden | Consent logs, versioned notices | Documented LIA, DPIA | Data lineage, retention by purpose |
The Practical Test
Whichever path you take, the standard question is the same: can you show, on request, what personal data feeds each AI system, why each element is necessary, on what basis you hold it, and when it will be disposed of? If any of those answers is missing, you have a minimization problem, not an innovation problem. Fix the records first, and the lawful basis argument becomes far easier to defend.
