2. Data Minimization en Sistemas AI

Descripción de la cápsula

Data minimization es el primer principio práctico de privacy. La idea es simple, la aplicación es revolucionaria:

Recopilar y procesar solo los datos estrictamente necesarios para el propósito específico declarado. Nada más.

En software tradicional, "más data es mejor" es default. En AI especificamente, hay un sesgo de "vamos a guardar todo, podemos necesitarlo después". Este principio invierte la lógica: tenés que justificar cada dato que recolectás, no asumir que tiene valor.

Esta cápsula cubre:

1. El test de necesidad: cómo distinguir "necesario" vs "nice-to-have".
2. Aplicación a stages del AI lifecycle: training, fine-tuning, inference, logging.
3. Reducir granularidad: cuándo agregaciones y buckets son suficientes vs raw data.
4. Caso real: cómo aplicar minimization a un sistema con LLMs y RAG.
5. Trade-offs honestos: cuando minimization reduce model utility.

Al terminar, vas a poder revisar tu sistema actual y reducir surface area de privacy risk significativamente, sin perder capability.

---

El test de necesidad

Para cada dato que recolectás o procesás, tres preguntas:

1. ¿Es necesario para el propósito declarado?

"Necesario" no es "útil". Necesario significa no podés cumplir el purpose sin este dato.

Ejemplo:

• Sistema de hiring AI:
  • Necesario: skills, experience, education.
  • Nice-to-have: hobbies, religion, marital status.
  • Innecesario: raza (excepto para bias auditing internal, no for decisions).

2. ¿Lo podríamos lograr con menos data o data agregada?

A veces no necesitás raw data, sino estadísticas o categorías:

• En lugar de fecha de nacimiento exacta → bracket de edad.
• En lugar de address → postal code.
• En lugar de income exacto → income bracket.

3. ¿Cuál es el threshold mínimo de data útil?

A veces es un mind shift:

• "¿Cuántos training samples necesitamos REALMENTE?"
• "¿Cuántos features?"
• "¿Cuánto retention?"

Si no podés justificar el número, probablemente es overcollection.

---

Aplicación al AI lifecycle

Data minimization aplica a múltiples stages:

Training data

Pregunta: ¿qué samples y qué features son truly necesarios para el modelo?

Aplicación:

• Samples: ¿necesitás 1M training samples o 100K alcanzan? Modelos pequeños raramente necesitan más de 100K bien curados.
• Features: drop features que no contributan signal. Use feature importance analysis.
• Time range: ¿necesitás 10 años de history o 2 años son suficientes?

Beneficio dual: menos data = menos privacy exposure + menor compute cost.

Inference / API requests

Pregunta: ¿qué inputs realmente necesitamos para responder a la query?

Aplicación:

# Antes (overcollection)
@app.post("/recommend")
async def recommend(user_id: str):
    user = await fetch_user_full_profile(user_id)  # ❌ todo: name, email, phone, address, history
    recommendations = model.predict(user)
    return recommendations

# Después (minimization)
@app.post("/recommend")
async def recommend(user_id: str):
    # Solo features que el modelo realmente usa
    user_features = await fetch_user_features(user_id, fields=['interests', 'past_views'])
    recommendations = model.predict(user_features)
    return recommendations

Si el modelo solo usa interests y past_views, no fetchear name/email/phone.

Logging

Pregunta: ¿qué información en logs es necesaria para debugging vs nice-to-have?

Aplicación:

# ❌ Sobre-logging
logger.info(f"User {user.full_name} ({user.email}) requested recommendation for {user.full_address}")

# ✅ Minimal logging
logger.info(f"User {anonymize(user.id)} requested recommendation, features: {feature_names}")

Logs son persistent — frecuentemente más persistent que tu database. Minimization de logs es crítico.

Conversation history (LLMs)

Pregunta: ¿necesitás conservar full conversation history?

Aplicación:

• Active session: full history para coherence durante session.
• Persisted long-term: tal vez summary, no full history.
• Used for fine-tuning: anonymize PII first, o no usar.

Conversations frecuentemente contain PII. Persistence sin necessity es classic minimization violation.

---

Reducir granularidad

Many privacy issues vienen de granularidad innecesaria. Reducir granularity reduces risk.

Tabla: alta granularidad → low granularity

High	Low	Apropiado cuándo
Birth date (1985-03-14)	Age bracket (30-40)	Recommendation, not medical
GPS coordinates	Postal code	Location features for recommendation
Exact salary ($87,500)	Income bracket ($75K-100K)	Risk scoring
Full IP address	Country + ISP	Geo content delivery
Browsing URL	Domain	Behavioral features
Exact timestamp	Hour bucket	Temporal patterns

Cada reducción de granularity:

• Pierde signal predictive marginal en muchos casos.
• Reduce dramáticamente privacy risk.
• Mejora compliance con GDPR data minimization.

Cuándo NO reducir granularity

• Sistema requires exact value (medical dosing requires exact age, not bracket).
• Legal requirement (some financial transactions require exact timestamp).
• Use case is precisamente that granularity (scientific research).

En todos estos casos, justificar y documentar.

---

Caso real: aplicar minimization a un RAG system

Sistema: Customer support RAG. Retrieves relevant docs y responde queries.

Antes de minimization

# System prompt (peligroso)
system_prompt = f"""
You are a customer support assistant.
Customer information:
- Name: {customer.full_name}
- Email: {customer.email}
- Phone: {customer.phone}
- Address: {customer.full_address}
- Account ID: {customer.account_id}
- Subscription: {customer.subscription}
- Last 10 tickets: {customer.recent_tickets}
- Last 100 conversations: {customer.recent_conversations}
- Payment methods: {customer.payment_methods}

Answer the customer's question.
"""

# Logging
logger.info(f"Query: {query}, prompt: {system_prompt}, response: {response}")

Problemas:

• Email, phone, address en prompt → potencial leak en respuesta.
• Sent to OpenAI API → en sus logs.
• Logged locally → email persiste en logs.
• Payment methods → completely irrelevant para support, pero exposed.

Después de minimization

# System prompt minimal
system_prompt = f"""
You are a customer support assistant.
Customer context (minimal):
- Subscription tier: {customer.subscription_tier}
- Account age: {customer.account_age_in_months}
- Topic of last ticket: {customer.last_ticket_topic}

Answer the customer's question. Do not mention specific personal details
unless directly relevant to the question.
"""

# Logging anonymized
logger.info(
    f"Query type: {classify_query(query)}, "
    f"customer_tier: {customer.subscription_tier}, "
    f"response_length: {len(response)}"
)
# No raw query, no raw response, no email/phone.

Improvements:

• No email/phone/address en prompt.
• Payment methods removed.
• Logging anonymized.
• LLM no exposed a PII innecesario.

Trade-offs aceptados:

• LLM no puede personalizar response usando nombre del cliente.
• Logs no permiten reproducir bugs exact (mitigated con structured logging diferente).
• Some queries pueden requerir más back-and-forth.

Net result: drastically reduced privacy surface area, modest reduction in personalization. Net win por orden de magnitud.

---

Trade-offs reales

Trade-off 1: model accuracy vs data volume

Más data = mejor modelo (en general). Minimization can reduce data.

Cuando es real el trade-off: modelos que necesitan billions of samples para foundation training.

Cuando NO es real: para fine-tuning y small models, 100K curated > 1M dirty. Minimization actually improves quality.

Trade-off 2: features removidas reducen signal

Eliminar features puede reducir accuracy.

Cuando es real: features que truly contributan unique signal.

Cuando NO es real: features que correlate con otras (multicolinearity). Removerlas no pierde signal — solo redundancia.

Test concreto: re-train sin la feature, medir accuracy delta. Si delta < 1%, la feature era redundante.

Trade-off 3: granularidad reducida pierde precision

Buckets en lugar de raw values → menos precision.

Cuando es real: sistemas que dependen de precision exact (medical, legal).

Cuando NO es real: sistemas behavioral/recommendation, donde buckets son sufficient.

El framework para decidir

1. Identificar candidato a minimization (data, feature, granularity).
2. Hypothesizar impact: ¿cuánto pierdo si lo elimino/reduzco?
3. A/B test offline: comparar modelo con vs sin.
4. Decidir based on data: si delta es small, minimizar. Si delta es significativo, justificar y documentar.

---

Implementación: data minimization checklist

## Data Minimization Checklist

For each data type collected/processed:

### Necessity
- [ ] Justified specific business purpose
- [ ] Cannot achieve purpose without this data
- [ ] Reviewed within last 6 months

### Granularity
- [ ] Minimum granularity acceptable for purpose
- [ ] Aggregations used where possible
- [ ] Buckets/categories instead of raw values where applicable

### Lifecycle
- [ ] Retention period defined and enforced
- [ ] Auto-purge mechanism in place
- [ ] Process for "right to deletion" requests

### Access
- [ ] Access limited to those who need it
- [ ] Logged when accessed
- [ ] Encrypted at rest and in transit

### Logging
- [ ] Logs do not contain unnecessary PII
- [ ] Logs are anonymized where possible
- [ ] Log retention defined

### LLM-specific (if applicable)
- [ ] PII not in system prompts
- [ ] PII not in user context unless necessary
- [ ] LLM API contract reviewed for data handling
- [ ] Conversations not used for training without consent

Aplica este checklist antes de deploy y cada 6 meses.

---

Trampas comunes

1. "Por si acaso"

"Vamos a guardar X por si lo necesitamos después" — clásica violación. Si no podés justify uso específico ahora, no lo recolectes.

2. Logs con PII completo

Easy de hacer (print(user) loggea todo el user object), difícil de auditar después. Implement structured logging desde day 1.

3. Confundir "anonymized" con "minimized"

Anonymization es diferente. Minimization se trata de no recolectar en primer lugar. Anonymization es second best (recolectaste y luego ofuscaste).

4. Olvidar caches y backups

Datos en cache, en backups, en archives — son data igual. Aplican mismas reglas. Si purgás de DB primary pero cache mantiene 30 días, no minimizaste.

5. PII en prompts de LLMs

Especialmente común. PMs piden "personalize the response" → terminás passing entire customer profile to LLM. Cuestionar siempre.

---

Auto-verificación

1. ¿Cómo distinguís "necesario" vs "nice-to-have" para data?

Test concreto: ¿podés cumplir el propósito específico declarado SIN este dato?

Si la respuesta es sí → no necesario, eliminar.

Si la respuesta es no → es necesario (o al menos justified).

Edge case: "podríamos mejorar el resultado con este dato pero no es estrictamente requerido". Esto es nice-to-have. Bajo data minimization principle: NO recolectar a menos que el improvement es significativo y stakeholders lo aprueban con full understanding del privacy cost.

Documentation: para cada data field collected, escribir 1-2 líneas justifying necesidad. Si no podés escribirlo en pocas líneas, probablemente no es necesario.

2. ¿Por qué reducir granularity es a menudo mejor que eliminar features?

Eliminar feature pierde toda la signal de esa dimensión.

Reducir granularity preserva la signal dimension-wise mientras reduce specificity individual.

Ejemplo: location.

• Eliminar location feature: modelo no sabe nada de geography. Si geography matters para la prediction, accuracy drops significativamente.
• Reducir a country: modelo aún sabe geography general. Pierde solo distinction within-country. Para muchos use cases, sufficient.

Privacy benefit:

• Country level: prácticamente impossible to re-identify individual.
• GPS level: trivial to re-identify (combinado con timestamp y otros features, GPS solo casi siempre identifica unique person).

Trade-off: marginal accuracy loss vs major privacy improvement. Frecuentemente, reducir granularity es la opción correcta.

3. ¿Cuáles son los riesgos específicos de PII en system prompts de LLMs?

Cuatro:

1. Leakage en outputs: LLM puede mencionar el PII en su response, exposing al usuario o a otros que vean conversation.

2. Logging del prompt: typically system logs incluyen el full prompt sent. PII persistente en logs.

3. API provider logs: si usás OpenAI/Anthropic API, prompts pueden estar en sus servers. Depende del contrato (algunos planes garantizan no logging, others not).

4. Training data future: algunos providers pueden usar conversations para training future models. Si tu PII fue parte del prompt, podría estar en future model parameters.

Mitigations:

• Minimize PII en prompts: solo include lo necesario para la query.
• Use opaque IDs en lugar de PII: customer_id en lugar de email.
• Verify provider terms: que prompts no se usen para training.
• Self-hosted models cuando privacy es crítica.
• Logging policies: filter PII de logs antes de persistir.

4. ¿Cuándo es legítimo NO aplicar minimization?

Casos donde minimization no aplica o es contraproducente:

1. Regulatory requires precision: ej., medical systems requieren full historial para safety. Minimization habría riesgo de safety.

2. Forensic/audit purposes: detalle puede ser legalmente requerido por compliance.

3. Research con explicit consent: si users consent específicamente a data collection comprehensiva for research benefit, minimization can be relaxed.

4. Aggregations donde minorities serían identifiable: paradójicamente, minimization extrema (k=1 anonymization) puede destacar individuos en small groups. Hay que balance.

5. Critical errors prevention: a veces necesitás detail para prevent system errors that would cause harm.

En todos estos casos: document the justification. "We retain this level of detail because [specific reason]". Sin justification documentada, default es minimize.

Y siempre: aún cuando no minimizás un type específico, minimizar otros. No es all-or-nothing.

---

Resumen y siguiente paso

• Data minimization: solo recopilar/procesar lo necesario para el propósito específico.
• Test de necesidad para cada dato: ¿podés cumplir purpose sin él?
• Aplicación al AI lifecycle: training, inference, logging, conversations.
• Reducir granularity es a menudo mejor que eliminar features.
• Trade-offs honestos: a veces minimization reduce model accuracy. Decidir informadamente.
• Caso RAG: dramatic improvement de privacy con minor reduction de personalization.

Checkpoint: deberías poder revisar un sistema y identificar al menos 3 oportunidades de minimization.

Puente a la siguiente cápsula: la cápsula 03 cubre anonymization vs pseudonymization — las dos técnicas principales para procesar PII reduciendo risk. Vas a aprender cuándo cada una aplica, sus limitations (re-identification attacks), y técnicas como k-anonymity, l-diversity, y differential privacy a nivel conceptual.

---

Recursos

1. GDPR Art 5(1)(c) — Data Minimisation — referencia legal.
2. Privacy by Design — Principle 2 (Default) — context.
3. Data Minimization in ML (Microsoft Research) — research papers.

---

Siguiente: 03-anonymization-pseudonymization.md — Anonymization vs Pseudonymization.

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