Legitimate Interest vs Consent

Descripción

En M5-05 tocamos brevemente la elección entre consent y legitimate interest. Esta cápsula profundiza: cuándo cada uno aplica, cómo hacer el balancing test (LIA — Legitimate Interest Assessment) defensible, y errores que sancionan.

Al terminar vas a poder:

• Realizar un balancing test para legitimate interest
• Decidir entre consent y LI para AI features específicas
• Documentar el LIA defendible en audit
• Identificar cuándo LI NO es apropiado (deber recurrir a consent)

El balancing test (LIA)

Legitimate interest requiere demostrar que tu interés legítimo no override los rights del data subject. Es un test de 3 pasos:

Step 1: Purpose Test

¿Tu purpose es legitimate?

• ✅ Legítimo: fraud prevention, security, internal analytics aggregated, R&D
• ⚠️ Borderline: marketing, ad personalization
• ❌ No legítimo: discriminación, manipulación, sale to third parties sin disclosure

Step 2: Necessity Test

¿Es necesario procesar para lograr ese purpose? ¿O hay manera less intrusive?

Pregunta clave: ¿podrías lograr el purpose con menos datos o sin processing? Si sí, NO es necesario, fail.

Step 3: Balancing Test

¿Tu interés legítimo es proporcional al impacto sobre el usuario?

Factores que pesan a favor del data subject:

• Datos sensibles (salud, religious, sexual orientation)
• Procesamiento que el sujeto no esperaba
• Impactos en derechos fundamentales
• Children o vulnerable groups

Factores que pesan a favor del controller (vos):

• Beneficios para el data subject
• Public interest
• Expectativas razonables del usuario
• Safeguards implementados (encryption, access controls)

El template del LIA

# Legitimate Interest Assessment — Fraud Detection AI

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

## Purpose

Detect fraudulent transactions automatically using 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 legitimate business interest
- 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 high false negative rate (35%)
- AI model achieves 90% detection with 5% false positive
- No less-intrusive alternative achieves required performance

## Step 3: Balancing Test

### Impact on 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 privacy policy
- Industry standard practice
- Reasonable expectation given service

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

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

Decision framework: consent vs LI

Sensitive data: special rules (Art. 9)

Datos "special category" requieren excepciones específicas del Art. 9:

• Health
• Religious beliefs
• Sexual orientation
• Political opinions
• Race/ethnicity
• Biometric (identification)
• Genetic

Para estos, legitimate interest NO basta. Necesitás:

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

AI implication: si tu modelo procesa o infiere sensitive data (e.g., facial recognition que infiere ethnicity, NLP que infiere political opinions), necesitás explicit consent o otra excepción específica del Art. 9.

Right to object — el límite del legitimate interest

Aunque uses LI, el data subject tiene right to object (Art. 21).

User: "Quiero que paren de procesar mis datos para fraud detection."

Tu respuesta:
- Si LI legitimate basis y no hay compelling override → debés parar
- "Compelling legitimate grounds" para continuar: legal obligations,
  security threat documented, etc.
- Para direct marketing, objection es absoluto (no podés override)

Para AI features bajo LI: tenés que implementar mechanism para procesar objection requests. SLA típico: 1 mes.

Cuando combinás bases legales

Un sistema AI a menudo tiene múltiples processing activities con bases legales distintas:

## Processing Activities — AI Customer Support Bot

| Activity | Lawful Basis | Notes |
|----------|--------------|-------|
| User authentication | Contract (Art. 6(1)(b)) | Necessary for service |
| Storing chat history | Contract + LI (analytics) | LI for aggregated analytics |
| Real-time RAG retrieval | Contract | Necessary for 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á cada activity con su basis. Diferentes activities pueden tener diferentes lawful bases.

Trampas comunes

Trampa 1 — LI por default sin LIA. Asumís "LI" porque parece más conveniente. Sin LIA documentado, regulador asume invalid.

Trampa 2 — Re-purposing data bajo nueva base. Collected con consent para marketing → ahora usás para AI training "bajo LI". Cambio de purpose requiere re-evaluation y posiblemente re-consent.

Trampa 3 — LI para sensitive data. Imposible. Sensitive data requiere Art. 9 specific basis.

Trampa 4 — Ignorar right to object. "Bajo LI, podés objetar" pero tu sistema no implementa mechanism. Violation.

Trampa 5 — LIA outdated. LIA hecho en 2018, sistema cambió mucho, LIA nunca actualizado. Required: revisión periódica (annual minimum).

Ejercicio

Para tu sistema de AI:

1. Identificá 5-7 processing activities distintas
2. Para cada una, decide consent vs LI vs otra base
3. Para las que elegís LI, write un LIA brief siguiendo el template
4. Para las de consent, especificá UX del consent flow

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

Resumen

Aprendiste:

• ✅ Los 3 pasos del balancing test (purpose, necessity, balancing)
• ✅ Template del LIA documentable
• ✅ Decision framework consent vs LI por situación
• ✅ Sensitive data requiere Art. 9 specific basis
• ✅ Right to object y mechanism para implementarlo
• ✅ Multi-activity systems: diferentes bases legales por activity

Checkpoint: si podés escribir un LIA defensible para cada activity de tu sistema, estás listo.

Siguiente cápsula

07 — Documentation y DPO en contextos AI. Qué documentar específicamente para AI compliance, y cuándo necesitás un Data Protection Officer.

Recursos

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