Módulo 5: GDPR for AI Systems
Introducción a GDPR for AI Systems
Descripción de la cápsula
GDPR no es nuevo — lleva en vigor desde 2018. Pero su aplicación a sistemas AI sigue siendo territorio mal entendido por la mayoría de engineers. La razón: GDPR fue diseñado antes del boom de AI generativa, y aplicar sus principios a LLMs, RAG systems y automated decision-making requiere interpretación específica que no viene en ningún tutorial estándar.
En el Módulo 4 viste el EU AI Act — la regulación específica de AI. GDPR es la otra ley que aplica simultáneamente en la UE para cualquier sistema que procese datos personales. Juntas, M4 y M5 dan el panorama regulatorio completo de la UE para AI.
El punto clave de este módulo es el Artículo 22: el derecho a no ser sujeto de decisiones puramente automatizadas que tengan efectos legales o significativos. Traducido a AI Engineering: si tu sistema toma decisiones que afectan personas (aprobar un préstamo, filtrar un CV, determinar un precio, priorizar un caso) sin intervención humana significativa, debés poder explicar la lógica, las consecuencias y dar opciones de oposición. "Right to explanation" no es un nice-to-have — es una obligación con multas de hasta el 4% del revenue global anual.
Al terminar el módulo vas a poder:
- Explicar Art. 22 GDPR y cuándo aplica a sistemas AI
- Definir qué debe explicar tu sistema bajo "right to explanation"
- Aplicar data minimization, consent, y retention al contexto AI
- Distinguir entre legitimate interest y consent como bases legales
- Producir una GDPR Compliance Checklist específica para AI
¿Dónde estamos?
Phase 1: Ethics Foundations ✅ (M1-M3)
Phase 2: Regulatory Compliance (M4-M6)
└── Módulo 4: EU AI Act ✅
└── Módulo 5: GDPR for AI ← ESTÁS AQUÍ
└── Módulo 6: Industry Standards (NIST, IEEE, ISO)
Phase 3: Practical Implementation (M7-M8)
GDPR + EU AI Act se superponen en sistemas high-risk. Comprenderlos juntos te permite arquitectar compliance desde el diseño.
El problema: GDPR vs AI generativa
GDPR fue redactado en 2016, vigente desde 2018. AI generativa explotó en 2022-2024. Aplicarlo a AI moderna tiene tensiones reales:
Tensión 1: LLMs vs "Right to explanation"
Art. 22 requiere explicar la lógica de decisiones automatizadas. Un random forest tiene feature importances; podés mostrar "decisión basada en credit history, ingresos, antigüedad". Un LLM es fundamentalmente menos interpretable: "¿por qué dijo X?" → no hay una respuesta clara.
Estrategias actuales:
- Documentar el proceso (no el "razonamiento" interno)
- Logging detallado de inputs, retrieved context, outputs
- Human-in-the-loop antes de decisiones significativas
- Reconocer las limitaciones honestamente
Tensión 2: Data deletion vs modelos entrenados
GDPR da el "right to be forgotten". Usuario pide que borres sus datos. Pero esos datos ya entrenaron tu modelo. ¿Suficiente borrar los datos originales si el modelo "aprendió" de ellos?
No hay respuesta definitiva todavía. Estrategias:
- Diseñar para evitarlo: usar synthetic data, federated learning
- Si entrenaste con personal data: documentar, prepararse para re-entrenar
- Para LLMs: retrieval-based en lugar de fine-tuning con datos personales
Tensión 3: Data minimization vs hambre de datos del ML
ML mejora con más datos. GDPR exige mínimo necesario. Conflicto direct.
Estrategias:
- Definir necesidad claramente: ¿este dato realmente mejora tu modelo?
- Diferenciar: datos para training (más relajado con anonymization) vs inferencia (estricto)
- Synthetic data para evitar datos personales reales en training
Mapa del módulo
| Cápsula | Tema | Output |
|---|---|---|
| 01 | Introducción (esta) | Modelo mental + tensiones GDPR vs AI |
| 02 | Art. 22 — Automated Decision-Making | Cuándo aplica, qué requiere |
| 03 | Right to Explanation para LLMs | Estrategias prácticas dada la opacidad |
| 04 | Data Minimization aplicada a AI training | Training vs inference, técnicas |
| 05 | Consent granular para AI processing | Diseño de UX + revocación |
| 06 | Legitimate Interest vs Consent | Cuándo cada uno aplica |
| 07 | Documentation y DPO en contextos AI | Qué documentar, rol DPO |
| 08 | Proyecto: GDPR Compliance Checklist for AI | Checklist específica AI |
El art. 22 en una página
Article 22 — Automated individual decision-making, including profiling
1. The data subject shall have the right not to be subject to a decision
based solely on automated processing, including profiling, which produces
legal effects concerning him or her or similarly significantly affects him or her.
2. Paragraph 1 shall not apply if the decision:
(a) is necessary for entering into, or performance of, a contract between the
data subject and a data controller;
(b) is authorised by Union or Member State law to which the controller is
subject and which also lays down suitable measures to safeguard the data
subject's rights and freedoms and legitimate interests; or
(c) is based on the data subject's explicit consent.
3. In the cases referred to in points (a) and (c) of paragraph 2, the data
controller shall implement suitable measures to safeguard the data subject's
rights and freedoms and legitimate interests, at least the right to obtain
human intervention on the part of the controller, to express his or her
point of view and to contest the decision.
Traducción para AI Engineers
Cuándo aplica: tu sistema toma decisiones automáticas que afectan personas (legal effect o impacto significativo).
Qué requiere:
- Información: el usuario debe saber que la decisión es automatizada
- Lógica: información significativa sobre la lógica involucrada
- Consecuencias: implicaciones previstas
- Right to challenge: el usuario puede pedir intervención humana, expresar su punto de vista, y contestar la decisión
Excepciones: contractual necessity, ley autorizada, consent explícito.
Casos reales: cuándo el Art. 22 aplica
| Sistema AI | ¿Aplica Art. 22? | Por qué |
|---|---|---|
| Credit scoring automático | ✅ Sí | Decisión sola y afecta significativamente |
| Filter automático de CVs | ✅ Sí | Affecta acceso a empleo |
| Chatbot que responde preguntas | ❌ No (típicamente) | No "decide" con effect legal |
| Pricing dinámico individual | ⚠️ Maybe | Depende de cuán "significativo" |
| Diagnóstico médico AI | ✅ Sí | Salud es effect significativo |
| Detección de fraude que bloquea cuenta | ✅ Sí | Affects acceso |
| Recomendaciones de productos | ❌ No | Sin effect significativo |
Regla práctica: si tu sistema toma una decisión que cambia el outcome de la vida del usuario (acceso a servicio, oportunidad, recurso), Art. 22 aplica.
Trampas comunes
Trampa 1 — Pensar "consent fixes everything." "Le pedimos consent y listo." No. Consent debe ser informed (sabe que es AI), granular (separado del consent base), y revocable.
Trampa 2 — Considerar que LLM responses no son decisiones. Si tu LLM responde "no podemos aprobar tu solicitud" y eso afecta al usuario, es una decisión automatizada. Frasearlo como "respuesta" no te exime.
Trampa 3 — Documentar solo para auditoría. La documentación debe ser accesible al sujeto que lo solicita. Tu DPA debe poder mostrar al usuario qué decisión se tomó y por qué.
Trampa 4 — Ignorar el conflicto con LLM opacity. "Mi LLM es black box, no puedo explicar." Eso no te exime — debés implementar estrategias alternativas de explainability (logging, human review, decisión templates).
Trampa 5 — Treating GDPR as EU-only. Si procesás datos de residentes EU desde fuera de la UE, GDPR aplica. Tu hosting in US no te exime.
Pregunta de auto-evaluación
Antes de pasar a M5-02:
- ¿Cuándo exactamente aplica Art. 22? Da 3 ejemplos clear-cut.
- Tu LLM responde a un usuario "no califica para nuestro programa premium". ¿Eso es una decisión automatizada bajo Art. 22?
- ¿Por qué consent como base legal puede ser más débil que legitimate interest en algunos casos?
Respuestas guía
- 3 ejemplos:
- Credit scoring que aprueba/rechaza préstamos automáticamente
- ATS que filtra CVs sin revisión humana antes de la decisión
- Sistema antifraude que bloquea transacciones sin intervención
- Sí, aplica Art. 22. "No califica para premium" afecta acceso a un servicio. Es decisión solo automatizada (LLM) con impacto significativo. Necesitás: notificar que es automatizada, explicar lógica, dar opción de review humana.
- Consent puede ser débil porque:
- Consent debe ser freely given — si el usuario "no tiene opción" (no puede usar servicio sin consent), no es freely given
- Consent es revocable en cualquier momento → si revoca, tenés que parar el processing
- Legitimate interest no es revocable de la misma forma, pero requiere balancing test documentado mostrando que tu interés legítimo no override los derechos del sujeto
Evidencia de éxito al terminar el módulo
Vas a saber que terminaste bien si:
- ✅ Podés explicar Art. 22 a un colega non-legal en 5 min
- ✅ Identificás cuándo aplica a un sistema AI específico
- ✅ Tu GDPR Compliance Checklist tiene ítems verificables (sí/no + evidencia)
- ✅ Sabés cómo manejar el conflicto LLM + explainability
- ✅ Distingues cuándo usás consent vs legitimate interest
Siguiente cápsula
02 — Art. 22: Automated Decision-Making. Profundizamos en el artículo más relevante para AI engineers, con cases reales de aplicación y excepciones.
Recursos
- GDPR — Article 22 official text — fuente oficial.
- WP29 Guidelines on Automated Decision-Making — interpretación oficial.
- ICO — AI and data protection — UK ICO guidance.
- GDPR Enforcement Tracker — multas en curso, para ver qué se sanciona.
- CNIL — IA et RGPD — French DPA guidance específica AI.