Módulo 5: GDPR for AI Systems

Data Minimization aplicada a AI

Siguiente →

Descripción

GDPR Art. 5(1)(c): datos personales deben ser "adequate, relevant and limited to what is necessary". Es el principio de data minimization. Para AI, esto choca con la intuición ML de "más datos = mejor modelo".

Resolución: minimization no es "menos datos". Es "solo los datos necesarios para el propósito específico". Para AI, esto se aplica en dos contextos distintos: training data y inference data.

Al terminar vas a poder:

  • Distinguir data minimization en training vs inference
  • Aplicar técnicas: synthetic data, sampling, feature reduction, anonymization
  • Justificar qué datos son necesarios documentadamente

Training data vs Inference data: dos regímenes distintos

Training data

  • Procesado: gran volumen, único momento (training run)
  • Risk: datos personales pueden "leak" via memorization del modelo
  • Mitigation: anonymization, synthetic, federated learning, differential privacy

Inference data

  • Procesado: continuo, cada query
  • Risk: exposure activa de datos personales
  • Mitigation: minimal collection, anonymization en logs, retention strict

Técnicas para minimization en training

Técnica 1: Anonymization

Removés identifiers antes de training:

def anonymize_for_training(record):
    return {
        # Removidos: name, email, phone, address, SSN
        "age_bucket": bucket_age(record["age"]),       # 25 → "20-29"
        "zip_prefix": record["zip"][:3],                # 12345 → "123"
        "purchase_history": record["purchases"],         # OK (genérico)
        "preferences": record["preferences"],
    }

Caveat: anonymization es difícil. K-anonymity, l-diversity, differential privacy son técnicas más serias.

Técnica 2: Synthetic data

Generás data estadísticamente similar pero sin personas reales:

from sdv.lightweight_synthesizers import GaussianCopulaSynthesizer

synthesizer = GaussianCopulaSynthesizer(metadata)
synthesizer.fit(real_data)
synthetic_data = synthesizer.sample(num_rows=100000)

# Train con synthetic_data en lugar de real
model.train(synthetic_data)

Pros: zero GDPR risk para training. Cons: quality del modelo puede sufrir si la distribución sintética no captura patterns reales.

Técnica 3: Sampling

Si tenés 10M records, ¿realmente necesitás todos? Often, 100K es suficiente.

# Stratified sampling para preservar distributions
from sklearn.model_selection import train_test_split

_, training_subset = train_test_split(
    full_data,
    test_size=0.01,  # 1% = 100K si total es 10M
    stratify=full_data["target"]
)

Menos datos = menos exposure = menos GDPR risk.

Técnica 4: Federated Learning

Modelo se entrena en device (mobile, edge) sin centralizar los datos:

Cliente A: entrena local con datos A → manda gradients
Cliente B: entrena local con datos B → manda gradients
Server: agrega gradients, NO ve datos

Pros: datos personales nunca salen del device. Cons: complejidad técnica significativa.

Técnica 5: Differential Privacy

Agregás ruido controlado a los datos/gradients para que un individuo específico no sea identificable.

# Sketch — DP-SGD adds noise to gradients
import opacus
privacy_engine = opacus.PrivacyEngine()
model, optimizer, data_loader = privacy_engine.make_private(
    module=model,
    optimizer=optimizer,
    data_loader=data_loader,
    noise_multiplier=1.1,
    max_grad_norm=1.0,
)

Pros: mathematical guarantees. Cons: model accuracy puede caer significativamente.

Técnicas para minimization en inference

Técnica 1: Collect only what you need

Tu LLM no necesita el user_id, email, phone para responder una pregunta general. No los pases en el prompt.

# Mal
prompt = f"User {user.full_name} ({user.email}) is asking: {question}"

# Bien
prompt = f"User question: {question}"

Técnica 2: Strip personal info de logs

def sanitize_for_logging(input_text):
    # Remove emails, phones, SSNs from logs
    sanitized = re.sub(r'[\w.+-]+@[\w-]+\.[\w.-]+', '[EMAIL_REDACTED]', input_text)
    sanitized = re.sub(r'\b\d{3}-\d{2}-\d{4}\b', '[SSN_REDACTED]', sanitized)
    sanitized = re.sub(r'\b\d{3}-\d{3}-\d{4}\b', '[PHONE_REDACTED]', sanitized)
    return sanitized

log.info(sanitize_for_logging(user_input))

Técnica 3: Retention agresiva

Logs detallados con personal info: 30-90 días. Después, aggregate-only metrics.

@scheduled_task(every="daily")
def cleanup_old_logs():
    db.execute(
        "DELETE FROM detailed_logs WHERE created_at < NOW() - INTERVAL '90 days'"
    )

Técnica 4: Tokenization / pseudonymization

Replace personal identifiers con tokens reversibles:

# user_id → token via lookup
def tokenize(user_id):
    return f"USR-{hashlib.sha256(user_id.encode() + SECRET).hexdigest()[:16]}"

# En logs, prompts, analytics
log_entry["user"] = tokenize(real_user_id)

Si necesitás "des-tokenizar" para support, tenés mapeo en lookup table separada con stricter access controls.

El conflicto fundamental: más datos vs minimum

Cuándo más datos ES necesario

  • Domain específico raro (medicina específica) → necesitás coverage amplio
  • Performance crítico para safety (autonomous vehicles) → más datos = mejor
  • Long-tail outcomes importantes → más samples requeridos

Cuándo más datos NO es necesario

  • Tu modelo ya plateauó en performance
  • Estás añadiendo datos similares (no nueva información)
  • Datos adicionales no mejoran metrics de eval

Test práctico: si quitar el 50% de tus training data degrada significativamente performance, son necesarios. Si no, no lo son.

Documentación de necesidad

Para defender minimization en audit, documentá:

## Data Necessity Justification — Customer Churn Model

### Data fields used in training:
- account_tenure: necesario porque churn correlated con tenure
- usage_frequency: necesario porque baja frequency predicts churn
- support_tickets_count: necesario porque high count predicts churn
- last_login_date: necesario para recency metric

### Data fields NOT used (available pero excluidos):
- name: NO necesario para predicción
- email: NO necesario
- phone: NO necesario
- exact_birthdate: NO necesario; usamos age_bucket en su lugar

### Anonymization applied:
- email replaced con hashed_user_id
- exact_dates con month_year
- specific zipcodes con city_region

### Retention:
- Training data refreshed quarterly
- Old training datasets purged after 1 year

Si un auditor pregunta "¿por qué tienen estos datos?", tenés respuesta documentada.

Trampas comunes

Trampa 1 — "Anonymization" superficial. Removés name pero mantenés zip + age + gender → re-identificable. K-anonymity decente requiere al menos k=5.

Trampa 2 — "More data is always better" mentality. Tu equipo ML quiere todo. Resistí — requiere justificación cada dato.

Trampa 3 — Inference data treated like training. Logs detallados que crecen sin retention. Misma posición que training in terms of GDPR exposure.

Trampa 4 — Synthetic data sin validation. Generás synthetic, asumís quality. Resultado: modelo malo. Validá con eval set real.

Trampa 5 — Federated learning como silver bullet. "Datos no salen del device" suena bien pero gradients aún pueden leak info. Necesita DP additionally para garantías reales.

Ejercicio

Tu producto: recommendation system para e-commerce. Actualmente collectás:

  • user_id, name, email, phone
  • birthday (exact date), gender, address (full)
  • purchase history (all items, dates, amounts)
  • browsing history (every page view, every click)
  • demographic inferred (income bracket, family status)

Aplica data minimization:

  1. ¿Qué datos eliminás del training?
  2. ¿Qué datos mantenés pero anonymizás/aggregás?
  3. ¿Retention strategy?
Ver solución

Eliminados del training:

  • name: no necesario para recomendar
  • email: no necesario
  • phone: no necesario
  • address (full): no necesario; usamos zip_prefix o city

Mantenidos pero modificados:

  • birthday → age_bucket (10-year buckets)
  • gender → mantenido (puede ser relevant para apparel)
  • purchase_history → mantenido (item IDs, fechas mes/año, amounts bucketeados)
  • browsing_history → aggregar a "categorías visitadas" en lugar de cada página
  • demographic inferred → mantenido pero documentado consent

Retention:

  • Training datasets: 1 año, después refresh
  • Logs detallados de browsing: 30 días
  • Aggregated patterns: indefinido (no identificable)
  • Personal info en active user: hasta closure de cuenta + 6 meses

Resumen

Aprendiste:

  • ✅ Data minimization: training vs inference (regímenes distintos)
  • ✅ 5 técnicas training: anonymization, synthetic, sampling, federated, DP
  • ✅ 4 técnicas inference: collect minimum, sanitize logs, retention, tokenization
  • ✅ Documentación de necesidad para audit
  • ✅ Trampas: anonymization superficial, more-is-better mentality

Checkpoint: si podés justificar cada dato que collectás con necesidad documentada, estás listo.

Siguiente cápsula

05 — Consent granular para AI processing. Consent es el área donde más sites fallan en GDPR. Para AI, los requirements son aún más específicos.

Recursos

  1. GDPR Art. 5(1)(c) — minimization principle.
  2. Differential Privacy library (Opacus) — PyTorch + DP.
  3. Synthetic Data Vault — generation library.
  4. Federated learning frameworks — overview.
← AnteriorRight to Explanation para LLMsSiguiente →Consent granular para AI processing