Legitimate Interest vs Consent

Description

In M5-05 we briefly touched on the choice between consent and legitimate interest. This capsule goes deeper: when each one applies, how to run a defensible balancing test (LIA — Legitimate Interest Assessment), and the mistakes that get sanctioned.

By the end you'll be able to:

• Run a balancing test for legitimate interest
• Decide between consent and LI for specific AI features
• Document an LIA that's defensible in an audit
• Identify when LI is NOT appropriate (and you must fall back to consent)

The balancing test (LIA)

Legitimate interest requires demonstrating that your legitimate interest doesn't override the data subject's rights. It's a 3-step test:

Step 1: Purpose Test

Is your purpose legitimate?

• ✅ Legitimate: fraud prevention, security, aggregated internal analytics, R&D
• ⚠️ Borderline: marketing, ad personalization
• ❌ Not legitimate: discrimination, manipulation, selling to third parties without disclosure

Step 2: Necessity Test

Is the processing necessary to achieve that purpose? Or is there a less intrusive way?

The key question: could you achieve the purpose with less data or with no processing? If yes, it isn't necessary — you fail.

Step 3: Balancing Test

Is your legitimate interest proportionate to the impact on the user?

Factors that weigh in the data subject's favor:

• Sensitive data (health, religion, sexual orientation)
• Processing the subject didn't expect
• Impacts on fundamental rights
• Children or vulnerable groups

Factors that weigh in the controller's (your) favor:

• Benefits to the data subject
• Public interest
• The user's reasonable expectations
• Safeguards implemented (encryption, access controls)

The LIA template

# Legitimate Interest Assessment — Fraud Detection AI

**Date**: 2026-05-11
**Reviewer**: [Tech Lead + DPO]

## Purpose

Detect fraudulent transactions automatically using an ML model trained on
historical transaction data + current transaction features.

## Lawful basis claim: Legitimate Interest (Art. 6(1)(f) GDPR)

## Step 1: Purpose Test
✅ LEGITIMATE
- Fraud prevention is a legitimate business interest
- It protects both us (financial loss) and users (account safety)
- Common industry practice; users expect this

## Step 2: Necessity Test
✅ NECESSARY
- Manual review would be impossibly slow at our scale (50K txns/day)
- Rule-based detection has a high false negative rate (35%)
- The AI model achieves 90% detection with a 5% false positive rate
- No less-intrusive alternative achieves the required performance

## Step 3: Balancing Test

### Impact on the data subject:
- Transactions reviewed automatically (low impact, no decision yet)
- High-risk transactions flagged for human review
- Account holds applied only after human approval

### Safeguards implemented:
- Model trained on anonymized data
- Decisions logged with explainability features
- Right to challenge: manual review within 24h
- No sale or sharing with third parties

### Expectations:
- Users informed in the privacy policy
- Industry standard practice
- A reasonable expectation given the service

### Conclusion:
Legitimate interest CAN be claimed. The impact on the data subject is
proportionate and balanced by the safeguards. The user retains the right to
object via [process link].

## Documentation
- Privacy policy updated 2025-01-15 with the fraud AI disclosure
- Internal procedure for handling Art. 21 objection requests
- DPIA conducted (M7) and approved
- Annual review scheduled for 2027-01-15

The decision framework: consent vs. LI

Sensitive data: special rules (Art. 9)

"Special category" data requires specific exceptions under Art. 9:

• Health
• Religious beliefs
• Sexual orientation
• Political opinions
• Race/ethnicity
• Biometrics (for identification)
• Genetics

For these, legitimate interest is NOT enough. You need:

• Explicit consent
• Necessity for employment/social security obligations
• Necessity for vital interests
• Necessity for public interest
• Etc.

The AI implication: if your model processes or infers sensitive data (e.g., facial recognition that infers ethnicity, NLP that infers political opinions), you need explicit consent or another specific Art. 9 exception.

The right to object — the limit of legitimate interest

Even if you use LI, the data subject has the right to object (Art. 21).

User: "I want you to stop processing my data for fraud detection."

Your response:
- If LI is the legitimate basis and there's no compelling override → you must stop
- "Compelling legitimate grounds" to continue: legal obligations,
  a documented security threat, etc.
- For direct marketing, the objection is absolute (you can't override it)

For AI features under LI: you have to implement a mechanism for processing objection requests. The typical SLA: 1 month.

When you combine legal bases

An AI system often has multiple processing activities with different legal bases:

## Processing Activities — AI Customer Support Bot

| Activity | Lawful Basis | Notes |
|----------|--------------|-------|
| User authentication | Contract (Art. 6(1)(b)) | Necessary for the service |
| Storing chat history | Contract + LI (analytics) | LI for aggregated analytics |
| Real-time RAG retrieval | Contract | Necessary for the service |
| Model improvement training | Consent (Art. 6(1)(a)) | Opt-in checkbox in settings |
| Fraud detection on misuse | Legitimate Interest | LIA documented |
| Profile inference for marketing | Consent | Separate granular consent |

Document each activity with its basis. Different activities can have different lawful bases.

Common traps

Trap 1 — LI by default with no LIA. You assume "LI" because it seems more convenient. Without a documented LIA, the regulator assumes it's invalid.

Trap 2 — Re-purposing data under a new basis. Collected with consent for marketing → now you use it for AI training "under LI." A change of purpose requires re-evaluation and possibly re-consent.

Trap 3 — LI for sensitive data. Impossible. Sensitive data requires a specific Art. 9 basis.

Trap 4 — Ignoring the right to object. "Under LI, you can object," but your system implements no mechanism for it. A violation.

Trap 5 — An outdated LIA. The LIA was done in 2018, the system changed a lot, and the LIA was never updated. Required: a periodic review (annual at minimum).

Exercise

For your AI system:

1. Identify 5-7 distinct processing activities
2. For each one, decide consent vs. LI vs. another basis
3. For the ones where you choose LI, write a brief LIA following the template
4. For the consent ones, specify the consent flow's UX

Purpose Test: ✅ (fraud prevention is legitimate)
Necessity: ✅ (the volume requires automation)
Balancing: ✅ (low individual impact, strong safeguards)
- Decisions logged
- Right to object honored within 30 days
- Annual review scheduled

Summary

You learned:

• ✅ The 3 steps of the balancing test (purpose, necessity, balancing)
• ✅ A documentable LIA template
• ✅ The decision framework for consent vs. LI by situation
• ✅ Sensitive data requires a specific Art. 9 basis
• ✅ The right to object and the mechanism to implement it
• ✅ Multi-activity systems: different legal bases per activity

Checkpoint: if you can write a defensible LIA for each activity in your system, you're ready.

Next capsule

07 — Documentation and the DPO in AI contexts. What to document specifically for AI compliance, and when you need a Data Protection Officer.

Resources

1. ICO — Legitimate Interest Assessment.
2. EDPB Guidelines on consent vs LI.
3. GDPR Article 6 and Article 9.
4. LIA template generator (ICO).