Módulo 3: Privacy and Data Protection Fundamentals

1. Introducción al módulo: Privacy and Data Protection Fundamentals

Descripción de la cápsula

El Módulo 2 cubrió cómo tu sistema puede discriminar. Este módulo cubre cómo tu sistema puede violar la privacidad de las personas cuyos datos procesa.

Estas son las dos caras del impacto en personas en AI:

Bias afecta a grupos: discriminación sistemática.
Privacy afecta a individuos: datos personales mal manejados.

Ambos riesgos a menudo afectan a las mismas personas: los grupos discriminados también son frecuentemente los más vulnerables a malos manejos de privacidad.

Este módulo cierra la Phase 1 de la guía (Ethics Foundations). Cuando termines, vas a tener tres herramientas accionables:

Ethics Impact Analysis (M1).
Bias Audit Toolkit (M2).
Privacy Assessment (M3, este módulo).

Con ellas, estás preparado para Phase 2 (Regulatory Compliance: EU AI Act M4, GDPR M5, etc.) — porque la regulación formaliza estos principios en obligaciones legales. Sin entender los principios, la regulación es memorización vacía.

¿Por qué privacy en AI es distinto?

Privacy en software tradicional ya es complejo. Pero AI introduce riesgos únicos que los frameworks tradicionales no cubren bien.

Software tradicional vs AI

Software tradicional:

Almacena datos.
Los muestra cuando el usuario lo pide.
Riesgos de privacidad: leaks (databases comprometidas), acceso no autorizado, retention indebido.
Soluciones: encryption, access control, retention policies.

Sistemas AI:

Aprenden de los datos: los transforman, integran en modelos, usan para inferencia futura.
Datos individuales se vuelven parte del modelo.
Riesgos únicos:
- Model inversion: reconstruir datos de entrenamiento desde el modelo.
- Membership inference: determinar si un individuo estaba en el training set.
- Data leakage en prompts: información sensible expuesta vía LLMs.
- Memorization: el modelo "recuerda" verbatim datos de entrenamiento.

Estos riesgos no aparecen en tutoriales genéricos de privacy. Y son tu responsabilidad técnica como AI engineer.

Ejemplo concreto: model inversion

Imaginá un modelo de face recognition entrenado con 10,000 caras. Un atacante:

Obtiene acceso al modelo (download, API).
Genera caras aleatorias.
Para cada cara, mide qué tan "confidente" está el modelo.
Itera: modifica la cara hasta que el modelo le dé alta confidence en una identidad específica.
Resultado: una reconstrucción de cara similar a las del training set.

Esto no requiere acceso al training data. Solo al modelo.

Para un sistema de face recognition, esto significa: tu modelo deployed puede leak las caras de las personas en tu dataset.

Ejemplo concreto: data leakage en prompts

Construiste un RAG system para customer support. El system prompt incluye:

Eres un AI assistant. Información del cliente:
- Email: maria@empresa.com
- ID interno: 12345
- Subscription tier: Premium
- Last support ticket: complaint about billing

Responde la pregunta del cliente.

El usuario hace una pregunta. El LLM responde — pero también puede:

Mencionar el email del cliente en la respuesta (si el LLM "alucina" o si el usuario lo pide).
Loggear el prompt completo en sistemas de monitoring → email persiste en logs.
Si usás API externa (OpenAI), el prompt puede estar en sus logs (depende del contrato).

Cada uno es un privacy leak técnico que un sistema tradicional no tendría.

Lo que vas a aprender

8 cápsulas:

Introducción (esta cápsula) — por qué privacy en AI es distinto.
Data minimization — qué datos necesitás vs qué recolectás "por si acaso".
Anonymization vs pseudonymization — cuándo cada una aplica.
Consent en AI — informed consent, granularidad, revocación.
Retention y lifecycle — políticas de purga, requests de eliminación, problema con modelos ya entrenados.
AI-specific privacy risks — model inversion, membership inference, data leakage.
Privacy by Design — privacidad integrada en arquitectura.
Mini-proyecto — Privacy Assessment para un sistema real.

Al terminar:

Aplicás data minimization a sistemas concretos.
Distinguís y elegís entre anonymization y pseudonymization.
Diseñás consent flows apropiados para AI.
Definís políticas de retention que consideran modelos.
Identificás AI-specific privacy risks y aplicás mitigations.
Producís un Privacy Assessment para un sistema real.
Conectás todo con GDPR — preparado para el módulo regulatorio.

El cambio de mentalidad de este módulo

Antes:

"Privacidad = encriptar la base de datos."

Después:

"Privacidad en AI = data minimization + consent informado + anonymization + retention con consideración de modelos + mitigation de AI-specific attacks. Cada uno requires decisiones de arquitectura distintas."

Privacy en AI es multi-dimensional. Una sola técnica (encryption) no cubre los riesgos. Defense en profundidad, igual que con bias.

La tensión: privacidad vs utilidad

Importante reconocer desde el inicio: privacy y utility de modelos a menudo están en tensión.

Más data en training → modelo más accurate.
Pero: más data = más PII potencialmente expuesta.
Anonymization protege privacy.
Pero: puede destruir signal predictivo.
Data minimization reduce risk.
Pero: puede reducir features útiles.

Este módulo no pretende que no hay trade-off. Sí lo hay. Lo que enseña es cómo navegarlo informadamente:

¿Qué datos son truly necesarios vs nice-to-have?
¿Qué nivel de privacy preserving es apropiado para tu context?
¿Cómo combinar técnicas para best-of-both?

A veces la respuesta correcta es "menos data, modelo menos accurate, pero mucho más respetuoso de privacy". A veces es "más data con strong protections". El módulo te da el framework para decidir.

Privacidad como decisión de arquitectura

Punto crucial: privacy se implementa en arquitectura, no como parche.

Si tu sistema almacena PII innecesariamente, agregar encryption no resuelve el problema fundamental. La pregunta correcta es: ¿por qué almacenamos esto en primer lugar?

Privacy by Design (Cavoukian, 2009) postula 7 principios:

Proactive not Reactive: prevenir issues, no responder a ellos.
Privacy as Default: el sistema debe ser privado sin configuration.
Privacy Embedded: integrado en el diseño, no añadido.
Full Functionality: privacy + functionality, no zero-sum.
End-to-End Security: protección durante todo el lifecycle.
Visibility and Transparency: stakeholders entienden el sistema.
Respect for User Privacy: usuario al centro.

Cada decisión de diseño debe pasar por estos lentes. Cápsula 7 cubre esto en detalle.

Quiénes tienen que leer este módulo

Si tu sistema:

✅ Procesa datos de personas (incluso datos públicos pueden ser personal data según jurisdicción).
✅ Almacena conversations de chat (texto del usuario es PII si tiene nombre, email, address, etc.).
✅ Entrena modelos sobre data de usuarios.
✅ Usa APIs de LLMs externas con prompts conteniendo info de usuarios.
✅ Tiene logs que pueden contener inputs/outputs.

Entonces este módulo aplica.

Para sistemas que NO procesan personal data en absoluto (ej., model that classifies images of inanimate objects), el módulo es menos crítico — pero los principios de minimization y design siguen siendo valiosos.

Conexión con el resto de la guía

M1 Impact Analysis      ← stakeholders, riesgos
   ↓
M2 Bias Detection       ← fairness en outputs
   ↓
M3 Privacy (este)       ← protection de individuos
   ↓
M4 EU AI Act            ← regulación AI
   ↓
M5 GDPR                 ← regulación data protection (formaliza M3)
   ↓
M6 NIST AI RMF + others ← frameworks complementarios
   ↓
M7 Responsible AI Framework  ← integration
   ↓
M8 Final Audit          ← aplicación end-to-end

Este módulo es fundacional para Phase 2. Los principios que aprendés acá son lo que la regulación formaliza. GDPR no inventa data minimization — la formaliza como obligación legal. EU AI Act no inventa data quality — la formaliza para sistemas high-risk.

Sin entender los principios técnicos, la regulación se siente arbitraria. Con ellos, la regulación tiene sentido.

Trampas comunes en este tema

1. "Tenemos encryption, somos privados"

Encryption protege contra acceso no autorizado al storage. No previene model inversion, membership inference, o leakage en prompts. Privacy en AI requiere más que encryption.

2. "Anonymizamos los datos, no hay PII"

K-anonymity puede ser broken con auxiliary data. Anonymization perfecta es muy difícil cuando el dataset es rico. Asumí que re-identification es posible y diseñá defensa en profundidad.

3. "Es responsabilidad del usuario darnos consent"

Bajo regulation moderna (GDPR, CCPA), consent debe ser explícito, informado, granular, revocable. Un boilerplate "I agree to terms" no cumple. El engineer es responsable de implementar consent flows correctamente.

4. "Si el dato está public, podemos usar"

Falso. Data scraped de internet sin consent es problemática. GDPR explícitamente requires lawful basis for processing, even of public data. New AI-specific regulations también restrict scraping.

5. "Una vez entrenado, el modelo es safe"

Falso. El modelo contiene information de los training samples. Model inversion y membership inference attacks demonstrate this. "Right to be forgotten" requests are particularly hard for trained models.

Auto-verificación

1. ¿Por qué privacy en AI es distinto a privacy en software tradicional?

Tres razones:

El modelo aprende de los datos: datos individuales se "integran" en parámetros. No están almacenados explícitamente, pero pueden ser recovered vía model inversion attacks.
Inferencia es procesamiento de PII: cuando un user query interactúa con un modelo entrenado en data de otros users, hay propagación indirecta de PII.
LLM-specific risks: prompts pueden contener PII que se loggea, se transmite a APIs externas, o se filtra en outputs.

Resultado: técnicas tradicionales (encryption, access control) son necesarias pero no suficientes. Privacy en AI requiere mitigations específicas para cada risk.

GDPR y otras regulations están actualizándose para reflejar esto. EU AI Act tiene provisions específicas para AI privacy. NIST AI RMF incluye privacy considerations explícitas.

2. ¿Por qué "tenemos encryption" no es respuesta suficiente para privacy en AI?

Encryption protege contra unauthorized access al storage. Pero no previene:

Model inversion: atacante con acceso legítimo al modelo (API, downloaded) reconstruye training data.
Membership inference: atacante determina si un specific individual estaba en training set.
Memorization: modelo "recuerda" verbatim training samples y los reproduce con prompts específicos.
Prompt leakage: PII en prompts se loggea, transmite a APIs, aparece en outputs.
Inference attacks: atributos sensibles del usuario inferidos de queries.

Encryption es una capa. Defense en profundidad require:

Data minimization (no collect lo innecesario).
Anonymization en training data donde posible.
Differential privacy o federated learning para training.
Output filtering.
Logging policies estrictos.
Retention policies que consideran modelos.

Encryption sola es como decir "tenemos firewall" como toda tu security strategy.

3. ¿Cuál es la tensión central entre privacy y AI utility?

Más data y más detalle = mejor modelo. Pero también = más PII exposure.

Specifically:

Training data size: más samples = mejor generalization. Pero cada sample is a person whose data está exposed.
Feature richness: más features per sample = más signal predictive. Pero más PII per individual.
Anonymization: protege privacy pero destroys signal.
Differential privacy: añade noise = mejor privacy = peor accuracy.

Cómo navegar:

Data minimization: collect lo realmente necesario, no "por si acaso".
Aggregation cuando posible: usar stats de cohort en lugar de individual.
Federated learning: train sin centralizar data.
Differential privacy: noise calibrado para privacy budget.
Anonymization sophisticated (k-anonymity, l-diversity, t-closeness).

Cada uno tiene cost. Trade-off explicit, no escondido.

Lo que NO funciona: pretender que no hay trade-off ("aplicamos best practices y todo está bien").

4. ¿Cómo conecta este módulo con GDPR (M5)?

GDPR formaliza los principios de este módulo en obligaciones legales:

Principio (M3)	GDPR Article
Data minimization	Art 5(1)(c) — "adequate, relevant, and limited to what is necessary"
Anonymization vs pseudonymization	Recital 26, Art 4(5)
Consent	Art 6, 7 — lawful basis y conditions for consent
Retention	Art 5(1)(e) — "kept for no longer than necessary"
Right to erasure	Art 17
Privacy by Design	Art 25

Sin entender los principios técnicos, GDPR es lista de articles to memorize. Con ellos, GDPR es framework legal que formaliza tu thinking de ingeniería.

Resultado: M5 va a sentirse natural si M3 está internalizado. "Esta obligación legal es exactly el principio de data minimization" en lugar de "qué quiere decir este artículo".

Esa es razón por la cual M3 viene antes de M5: fundamentos técnicos primero, regulation que los formaliza después.

Resumen y siguiente paso

Privacy en AI tiene riesgos únicos que software tradicional no tiene: model inversion, membership inference, prompt leakage, memorization.
Privacy se implementa en arquitectura, no se parcha. Privacy by Design.
Hay tensión real entre privacy y utility. El módulo enseña a navegarla informadamente.
Connection con GDPR: este módulo establece principios técnicos. GDPR (M5) los formaliza como obligaciones legales.
Defense en profundidad: encryption es una capa, no toda la solución.

Checkpoint: deberías poder articular por qué privacy en AI requiere mitigations específicas más allá de techniques de software tradicional.

Puente a la siguiente cápsula: la cápsula 02 cubre data minimization — el primer principio práctico. Vas a aprender a distinguir entre "datos que necesitamos" y "datos que recolectamos por si acaso", y cómo aplicar minimization concretamente a sistemas AI (qué features, qué retention, qué granularity).

Recursos

Privacy by Design (Cavoukian, 2009) — paper foundational.
GDPR — Recital 26 (anonymization) — definición legal.
Membership Inference Attacks (Shokri et al., 2017) — paper técnico.
Model Inversion (Fredrikson et al., 2015) — paper técnico.
Confidentiality of LLM-based Systems (OpenAI policy) — política de proveedor.

Siguiente: 02-data-minimization.md — Data minimization aplicada a sistemas AI.

Cápsula 01 de 08 — Módulo 3 — AI Ethics & Compliance Guide

← Anterior8. Mini-proyecto: Bias Audit Toolkit Siguiente →2. Data Minimization en Sistemas AI