Módulo 6: Data Privacy & PII Protection

1. Introducción: Data Privacy & PII Protection

Descripción

En el Módulo 4 construiste un Sanitization Pipeline que limpia, valida y filtra todo lo que entra y sale de tu sistema AI. En el Módulo 5 aseguraste las credenciales con Secrets Management. Ahora enfrentas un problema que ni la sanitización más robusta ni las mejores prácticas de secrets management resuelven por sí solas: los datos personales de tus usuarios están pasando por tu sistema AI, y el modelo puede memorizarlos, filtrarlos, o exponerlos.

Un LLM no es una base de datos — pero se comporta como una. Cuando envías el historial médico de un paciente como contexto para generar un resumen, ese texto pasa por los servidores del proveedor de AI. Cuando un usuario escribe "mi número de seguro social es 123-45-6789" en un chatbot, ese dato queda en los logs. Cuando usas RAG y tus documentos contienen emails, teléfonos y direcciones de clientes, cada query potencialmente expone esa información en la respuesta del modelo.

Este módulo construye la capa de protección de datos personales — el PII Protection Layer — que se integra con tu Sanitization Pipeline del Módulo 4. Si el Módulo 4 fue "asegurar que los datos estén limpios y válidos", este módulo es "asegurar que los datos personales estén protegidos antes, durante y después del procesamiento AI." Es la diferencia entre limpiar una habitación (M4) y asegurar que no haya cámaras ocultas grabando lo que pasa dentro (M6).

El foco principal de este módulo es la mitigación de LLM02: Sensitive Information Disclosure del OWASP LLM Top 10 2025. LLM02 ocurre cuando un modelo revela información sensible — datos de entrenamiento memorizados, PII del contexto, secretos del system prompt, o datos de otros usuarios que se filtraron a través del context window. Es una de las vulnerabilidades con mayor impacto regulatorio porque las multas por violación de GDPR pueden llegar al 4% de la facturación global.

¿Por qué un módulo completo para protección de PII?

La decisión de dedicar un módulo a PII protection (separado de sanitización) es deliberada. Hay tres razones:

1. La sanitización no es suficiente para proteger datos personales

El Módulo 4 detecta PII de forma básica (regex para emails y teléfonos en el Content Filter). Pero la detección de PII en producción requiere herramientas especializadas: Named Entity Recognition (NER) con modelos de lenguaje, reconocedores de patrones para más de 30 tipos de PII, soporte multilingüe, y la capacidad de distinguir entre un email real y uno de ejemplo en documentación.

2. Detectar PII no es suficiente — necesitas redactarlo correctamente

Encontrar un email en el texto es solo el inicio. ¿Lo reemplazas con [EMAIL]? ¿Lo hasheas para poder auditar sin exponer? ¿Lo generalizas a solo el dominio? ¿La redacción es reversible o irreversible? ¿Redactas antes de enviar al LLM, después, o ambos? Cada estrategia tiene trade-offs de utilidad, privacidad y compliance que este módulo aborda.

3. La protección de PII tiene dimensiones que van más allá del código

Data minimization (enviar solo lo necesario al LLM), retention policies (cuánto tiempo guardas logs y outputs), encryption (cómo proteges datos en reposo y en tránsito), y compliance basics (GDPR, CCPA) son aspectos de la protección de datos que requieren decisiones de arquitectura, no solo código.

¿Qué aprenderás en este módulo?

Al terminar este módulo vas a poder:

Entender LLM02 en profundidad: cómo los LLMs memorizan y filtran datos sensibles, técnicas de extracción, escenarios reales de data leakage, e implicaciones regulatorias
Detectar PII con herramientas profesionales: Microsoft Presidio para detección multi-tipo, spaCy NER para nombres y organizaciones, regex para patrones estructurados (SSN, tarjetas de crédito), reconocedores custom para PII específico de tu dominio
Redactar PII con estrategias apropiadas: masking, replacement, hashing, generalización, redacción pre-LLM y post-LLM, redacción reversible vs irreversible, mantenimiento de contexto
Minimizar datos enviados al LLM: truncación inteligente, selective field inclusion, prompt engineering para privacidad, clasificación de datos por nivel de sensibilidad
Implementar retention policies y encryption: schedules de eliminación automática, encryption at rest y in transit, sanitización de logs, key management
Conocer frameworks de compliance relevantes: GDPR, CCPA, y cómo afectan a sistemas AI — sin pretender ser asesoría legal, sino awareness técnico
Construir un PII Protection Layer completo como proyecto: integrado con el Sanitization Pipeline del Módulo 4, con scanner, redactor, minimizer, retention scheduler, y audit logging

Roadmap del módulo

Este módulo tiene 8 cápsulas que construyen la capa de protección de datos capa por capa:

#	Cápsula	Qué aprenderás
01	Introducción: Data Privacy & PII Protection	Por qué este módulo, roadmap, conexión con el proyecto, setup
02	LLM02 en Detalle: Sensitive Information Disclosure	Cómo los LLMs filtran datos, técnicas de extracción, escenarios reales, implicaciones
03	PII Detection: Patrones, Regex y Presidio	Detección de PII con regex, Presidio, spaCy NER, reconocedores custom
04	PII Redaction: Antes y Después del LLM	Estrategias de redacción, pre/post-LLM, reversible vs irreversible
05	Data Minimization	Enviar solo lo necesario al LLM, clasificación de datos, prompt engineering para privacidad
06	Retention Policies y Encryption	Schedules de retención, encryption at rest/transit, log sanitization
07	Compliance Basics: GDPR, CCPA y AI	Frameworks de compliance, data subject rights, AI-specific considerations
08	Proyecto: PII Protection Layer	Capa completa de protección de PII integrada con el Sanitization Pipeline

La progresión es: contexto (01) → amenaza (02) → detección (03) → redacción (04) → minimización (05) → retención y encryption (06) → compliance (07) → proyecto (08).

Las cápsulas 02-04 forman el core técnico: entender la amenaza, detectar PII, y redactarlo. La cápsula 05 agrega la dimensión de minimización — reducir lo que envías al LLM. La cápsula 06 cubre qué pasa después del procesamiento (retención, encryption). La cápsula 07 contextualiza todo en frameworks legales. La cápsula 08 integra todo en el PII Protection Layer.

Contexto en la guía

Esta guía tiene 8 módulos organizados en 3 fases:

Phase 1: Security Foundations (Módulos 1-3)
├── Módulo 1: AI Security Landscape & Threat Model    ✅ COMPLETADO
├── Módulo 2: OWASP LLM Top 10 Deep Dive             ✅ COMPLETADO
└── Módulo 3: Prompt Injection — Attacks & Defenses   ✅ COMPLETADO

Phase 2: Defense Implementation (Módulos 4-6)
├── Módulo 4: Input & Output Sanitization             ✅ COMPLETADO
├── Módulo 5: Secrets Management                      ✅ COMPLETADO
└── Módulo 6: Data Privacy & PII Protection           ← ESTÁS AQUÍ

Phase 3: Production Security (Módulos 7-8)
├── Módulo 7: Security Testing & Auditing
└── Módulo 8: Proyecto Integrador — Secured AI System

El Módulo 4 te dio el pipeline de sanitización input/output. El Módulo 5 aseguró las credenciales y API keys. Ahora el Módulo 6 aborda la protección de los datos más sensibles que pasan por tu sistema: la información personal de tus usuarios.

La relación con módulos anteriores es de complemento:

Módulo 3 (Injection Defense)          Módulo 4 (Sanitization)
─────────────────────────             ─────────────────────────
Detecta ataques intencionales         Limpia datos mal formados
Bloquea prompt injection              Valida estructura outputs
Foco: LLM01                          Foco: LLM05

Módulo 5 (Secrets Management)         Módulo 6 (PII Protection)
─────────────────────────             ─────────────────────────
Protege credenciales del sistema      Protege datos de los usuarios
API keys, tokens, certificados        Emails, nombres, SSN, tarjetas
Foco: secretos del developer          Foco: datos del usuario final

Juntos, M3 + M4 + M5 + M6 forman las cuatro capas de defensa del sistema: anti-injection (M3) + sanitización (M4) + secrets (M5) + PII protection (M6).

Prerequisites

Para este módulo necesitas:

Módulos 1-5 completados: Threat Model, OWASP Mapping, Injection Defense, Sanitization Pipeline, Secrets Management Setup
Python 3.10+ instalado
Familiaridad con regex — patrones básicos de expresiones regulares
Familiaridad con FastAPI — middleware, dependencias

Setup técnico

Si ya tienes el entorno de los módulos anteriores, actívalo y agrega las dependencias nuevas:

source security-guide-env/bin/activate  # macOS/Linux
# security-guide-env\Scripts\activate   # Windows

pip install presidio-analyzer presidio-anonymizer spacy
python -m spacy download en_core_web_lg
python -m spacy download es_core_news_md

Si estás empezando desde este módulo:

python -m venv security-guide-env
source security-guide-env/bin/activate

pip install presidio-analyzer presidio-anonymizer spacy pydantic fastapi uvicorn
python -m spacy download en_core_web_lg

export OPENAI_API_KEY="sk-..."

Verificación rápida:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

text = "Mi nombre es Juan García y mi email es juan@ejemplo.com"

results = analyzer.analyze(
    text=text,
    language="en",
    entities=["PERSON", "EMAIL_ADDRESS"],
)

anonymized = anonymizer.anonymize(text=text, analyzer_results=results)

print(f"Original:   {text}")
print(f"Anonymized: {anonymized.text}")
print(f"Entities:   {[(r.entity_type, r.score) for r in results]}")

# Output esperado:
# Original:   Mi nombre es Juan García y mi email es juan@ejemplo.com
# Anonymized: Mi nombre es <PERSON> y mi email es <EMAIL_ADDRESS>
# Entities:   [('EMAIL_ADDRESS', 1.0), ('PERSON', 0.85)]

Si ves las tres salidas, tu setup está listo. Las dependencias clave de este módulo son:

Paquete	Para qué
`presidio-analyzer`	Detección de PII con NER y patterns
`presidio-anonymizer`	Redacción/anonimización de PII detectado
`spacy`	Modelos NER para detección de nombres, organizaciones
`pydantic`	Modelos de configuración y validación
`fastapi`	Integración del PII Protection Layer como middleware

Conexión con el proyecto del módulo

Este módulo cierra con el proyecto PII Protection Layer: una capa de protección de datos personales que se integra con tu Sanitization Pipeline del Módulo 4. Es el sexto artefacto de la guía.

El PII Protection Layer incluye:

PII Scanner — Detección con Presidio + reconocedores custom para tu dominio
Pre-LLM Redactor — Redacción de PII antes de enviar al modelo
Post-LLM Redactor — Detección y redacción de PII en outputs del modelo
Data Minimizer — Reducción de datos enviados al mínimo necesario
Retention Scheduler — Política de retención con eliminación automática
Audit Logger — Registro de cada detección y redacción de PII

El pipeline se integra con el Sanitization Pipeline del Módulo 4:

Request
  │
  ▼
┌──────────────────────────┐
│  Input Sanitizer (M4)    │ ← Normaliza, limpia
├──────────────────────────┤
│  PII Scanner (M6)        │ ← Detecta PII en input
├──────────────────────────┤
│  Pre-LLM Redactor (M6)  │ ← Redacta PII antes del LLM
├──────────────────────────┤
│  Data Minimizer (M6)    │ ← Envía solo lo necesario
├──────────────────────────┤
│  Injection Detector (M3) │ ← Verifica ataques
├──────────────────────────┤
│  LLM Processing          │ ← OpenAI API call
├──────────────────────────┤
│  Output Validator (M4)   │ ← Valida estructura
├──────────────────────────┤
│  Post-LLM Redactor (M6) │ ← Filtra PII en output
├──────────────────────────┤
│  Content Filter (M4)     │ ← Toxicidad, off-topic
├──────────────────────────┤
│  Audit Logger (M4+M6)   │ ← Registro completo
└──────────────────────────┘
  │
  ▼
Response

En el Módulo 8 (proyecto integrador), el PII Protection Layer se integra con todos los artefactos anteriores para formar el Secured AI System.

Módulo 1: Threat Model Document (base)
Módulo 2: + OWASP Mapping Audit (mapeo detallado)
Módulo 3: + Injection Defense Pipeline (defensa contra LLM01)
Módulo 4: + Sanitization Pipeline (input/output)
Módulo 5: + Secrets Management Setup (credenciales)
Módulo 6: + PII Protection Layer (datos sensibles)              ← LO PRODUCES AQUÍ
Módulo 7: + Security Audit Report (validación)
Módulo 8: → Secured AI System (integración total)

LLM02: Sensitive Information Disclosure — el foco de este módulo

Este módulo mitiga primariamente LLM02: Sensitive Information Disclosure. Entender esta vulnerabilidad es clave para todo lo que sigue.

Qué es LLM02

LLM02 ocurre cuando un LLM revela información sensible que no debería estar en su output. Esto puede suceder por:

Memorización de training data: El modelo memorizó emails, teléfonos o direcciones de su dataset de entrenamiento y los reproduce cuando un prompt lo activa
Context window leakage: El contexto de un usuario (RAG documents, chat history) se filtra en la respuesta a otro usuario
System prompt exposure: El system prompt contiene información sensible (API endpoints, lógica de negocio) que el modelo revela cuando se le presiona
Cross-conversation bleed: En sistemas con sesiones compartidas, datos de una conversación aparecen en otra

Por qué es especialmente peligroso en AI

En una aplicación web tradicional, un data leak requiere una vulnerabilidad técnica (SQL injection, IDOR, etc.). En un sistema AI, el modelo puede revelar datos sensibles simplemente porque un usuario hizo una pregunta que activa un patrón de memorización. No necesitas un atacante sofisticado — necesitas un usuario curioso.

El patrón del riesgo

# RIESGO: Enviar PII sin redactar al LLM
user_data = {
    "name": "María García López",
    "email": "maria@empresa.com",
    "ssn": "123-45-6789",
    "query": "¿Cuál es el estado de mi pedido?"
}

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": f"Datos del usuario: {user_data}"},
        {"role": "user", "content": user_data["query"]},
    ],
)
# El LLM ahora tiene acceso al SSN y puede incluirlo en la respuesta

# SEGURO: Redactar PII antes de enviar al LLM
from pii_scanner import scan_and_redact

safe_context = scan_and_redact(str(user_data))
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": f"Datos del usuario: {safe_context}"},
        {"role": "user", "content": user_data["query"]},
    ],
)
# El LLM nunca ve el SSN ni el email real

Cada cápsula de este módulo construye una pieza de esa cadena de protección.

Qué hace diferente a este módulo vs el Content Filter del Módulo 4

El Módulo 4 incluye un Content Filter con detección básica de PII (regex para email, teléfono, SSN, tarjeta de crédito). Este módulo no repite ese contenido — lo reemplaza con una solución enterprise-grade:

Concepto	Módulo 4 (Content Filter)	Este módulo (M6)
Detección de PII	Regex para 4 tipos	Presidio + spaCy NER para 30+ tipos
Redacción	No cubre	5 estrategias: masking, replacement, hashing, generalización, synthetic
Pre-LLM protection	No cubre	Redacción completa antes de enviar al LLM
Post-LLM protection	Flag básico	Detección y redacción en outputs del modelo
Data minimization	No cubre	Reducción de datos al mínimo necesario
Retention	No cubre	Policies de retención con eliminación automática
Compliance	Mención de GDPR	GDPR, CCPA, consideraciones AI-specific
Multi-language	Solo patrones en inglés	Soporte multilingüe con spaCy y Presidio

La regla es: el Content Filter del M4 es un "flag" de PII. El PII Protection Layer del M6 es la solución completa.

Lo que NO cubre este módulo

Para mantener el foco y evitar duplicar contenido:

Prompt injection defense: Eso fue el Módulo 3. La redacción de PII no protege contra injection — complementa.
Input/output sanitization general: Eso fue el Módulo 4. Aquí usas el pipeline de sanitización como base, no lo reconstruyes.
Secrets management: Las API keys de Presidio o servicios de moderación se protegen en el Módulo 5.
Security testing del PII layer: Aquí construyes la protección. El Módulo 7 la testea con adversarial inputs.
Asesoría legal de compliance: La cápsula 07 cubre awareness de GDPR/CCPA. No es — ni pretende ser — asesoría legal. Consulta con tu equipo legal para compliance formal.

La analogía: un hospital y los expedientes médicos

Imagina un hospital donde los doctores necesitan consultar expedientes médicos para diagnosticar pacientes:

Expediente completo → Doctor consulta → Diagnóstico → Se guarda resultado

El hospital tiene reglas estrictas sobre esos expedientes:

Detección: Cada documento se clasifica por nivel de sensibilidad (PII Scanner)
Redacción: Cuando un doctor comparte un caso en una conferencia, los datos del paciente se redactan (Pre-LLM Redactor)
Minimización: Un doctor de dermatología solo accede a la sección dermatológica del expediente, no al historial psiquiátrico (Data Minimizer)
Retención: Los expedientes se destruyen después del período legal de retención (Retention Policy)
Encryption: Los expedientes se guardan en un archivero con llave, no en la mesa del café (Encryption at Rest)
Compliance: El hospital cumple con regulaciones de protección de datos médicos (GDPR/HIPAA)

Hospital                              Sistema AI
────────────────────                  ────────────────────────
Expediente médico                     User data / RAG documents
Doctor consultando                    LLM procesando contexto
Redacción para conferencia            Pre-LLM redaction
Solo sección relevante                Data minimization
Archivero con llave                   Encryption at rest
Destrucción tras periodo legal        Retention policy
Regulaciones de datos médicos         GDPR / CCPA compliance

Tu sistema AI es el hospital. Los datos de tus usuarios son los expedientes. El LLM es el doctor. Este módulo construye todas las reglas de protección alrededor de esos expedientes.

Errores comunes al abordar protección de PII

"Ya tengo HTTPS, mis datos están protegidos"

HTTPS protege datos en tránsito entre tu servidor y el usuario. Pero los datos que envías al LLM viajan a los servidores del proveedor de AI, se almacenan en tus logs, persisten en tu vector store, y existen en la memoria del modelo. HTTPS no protege contra ninguno de estos vectores de exposición.

"Si no guardo datos personales, no necesito protección de PII"

Tu sistema procesa datos personales aunque no los almacene permanentemente. Cuando un usuario escribe "mi email es maria@empresa.com" en tu chatbot, ese dato pasa por tu sistema, se envía al LLM, se registra en logs, y potencialmente se almacena en el chat history. "No guardar" y "no procesar" son cosas muy diferentes bajo GDPR.

"El modelo de OpenAI ya protege los datos"

OpenAI implementa medidas de seguridad en su plataforma, pero la responsabilidad de proteger los datos de tus usuarios es tuya. Si envías un SSN al modelo y el modelo lo incluye en una respuesta, la violación es de tu sistema, no de OpenAI. El principio de "data protection by design" (GDPR Art. 25) requiere que tú implementes las protecciones.

"La redacción de PII hace que mi sistema sea inútil"

La redacción completa (reemplazar todo con [REDACTED]) sí reduce la utilidad. Pero hay estrategias que mantienen el contexto: redacción con tipo de entidad (<PERSON> en lugar de [REDACTED]), generalización (fecha exacta → década), datos sintéticos (nombre ficticio en lugar de placeholder). La cápsula 04 cubre estas estrategias en detalle.

"Solo proceso datos de usuarios internos, no necesito compliance"

GDPR protege datos de cualquier persona, incluyendo empleados. Si tu sistema AI interno procesa datos de empleados (emails, nombres, organigramas), GDPR aplica. CCPA aplica a datos de residentes de California independientemente de si son clientes o empleados.

"Puedo implementar PII protection después del lanzamiento"

Retroadaptar protección de PII es significativamente más costoso que diseñarla desde el inicio. Necesitas re-indexar tu vector store con documentos redactados, sanitizar logs históricos, implementar mecanismos de eliminación por usuario, y potencialmente re-entrenar modelos fine-tuned. GDPR Art. 25 explícitamente requiere "data protection by design and by default" — desde el inicio, no como afterthought.

La importancia de PII Protection en la industria

Para que entiendas el peso de la protección de PII en el mundo profesional, estos son patrones de incidentes documentados:

Incidentes reales (patrones comunes)

Patrón	Qué pasó	Impacto
RAG con PII	Un chatbot de soporte recuperó un ticket de otro cliente con su email y teléfono como contexto, y los incluyó en la respuesta	Violación de GDPR, notificación a la autoridad de protección de datos
Fine-tuning con datos reales	Un modelo fine-tuned con emails de clientes empezó a generar nombres y emails reales cuando se le pedían "ejemplos"	Investigación regulatoria, re-entrenamiento del modelo
Logs con prompts completos	Los logs del sistema contenían los prompts completos de usuarios, incluyendo SSN y tarjetas de crédito. Un breach del sistema de logs expuso toda esa información	Breach notification, multa, daño reputacional
Chatbot que recuerda	Un chatbot multi-sesión guardaba el historial completo. Un usuario descubrió que podía preguntar sobre datos de sesiones anteriores de otros usuarios	Violación de confidencialidad, demanda colectiva
API sin PII filter	Una API de generación de texto devolvía outputs del modelo sin filtrar. El modelo incluía emails memorizados del training data	Data leak por memorización, exposición pública

Cada uno de estos incidentes hubiera sido prevenido con un PII Protection Layer como el que construyes en este módulo.

Regulaciones que requieren PII protection

Regulación	Requisito relevante	Multa máxima
GDPR	Art. 25: Data protection by design	€20M o 4% de facturación global
CCPA	§1798.150: Private right of action por data breaches	$7,500 por violación + demandas individuales
EU AI Act	Art. 10: Data governance para AI de alto riesgo	€35M o 7% de facturación global
HIPAA	§164.312: Safeguards para datos de salud	$1.5M por categoría de violación/año
SOC 2	Processing Integrity: datos completos y precisos	Pérdida de certificación

No necesitas ser una empresa regulada para beneficiarte de estas prácticas. Pero si procesas datos personales con AI — y la gran mayoría de sistemas AI lo hacen — la protección de PII no es opcional.

El costo de no proteger PII: un ejercicio mental

Piensa en tu sistema AI actual y responde estas preguntas:

Si un usuario escribe su SSN en el chat, ¿tu sistema lo detecta y redacta antes de enviarlo al LLM? Si no, estás enviando datos críticos a servidores de terceros.
Si tu pipeline RAG recupera un documento que contiene emails de clientes, ¿los redactas antes de inyectarlos en el prompt? Si no, estás exponiendo datos de terceros al modelo.
Tus logs registran los prompts completos incluyendo datos del usuario? Si sí, cualquier breach de tu sistema de logs expone todo el PII.
¿Cuánto tiempo guardas los logs de tu sistema AI? Si la respuesta es "indefinidamente" o "no sé", probablemente estás violando el principio de storage limitation.
Si un usuario te pide que elimines todos sus datos, ¿puedes hacerlo? Si no, no cumples con el derecho de eliminación (GDPR Art. 17).
¿Filtras el output del LLM para detectar PII antes de enviarlo al usuario? Si no, el modelo puede revelar datos memorizados o del contexto.

Si respondiste "no" a alguna, este módulo te resuelve esos problemas.

Tu sistema: ejercicio de pre-evaluación

Antes de empezar con las cápsulas técnicas, toma 5 minutos para evaluar tu sistema actual:

¿Detectas PII en inputs del usuario? → Si no, la cápsula 03 es prioritaria
¿Redactas PII antes de enviar al LLM? → Si no, la cápsula 04 es prioritaria
¿Envías solo datos necesarios al LLM? → Si no, la cápsula 05 es prioritaria
¿Tienes políticas de retención para logs? → Si no, la cápsula 06 es prioritaria
¿Conoces qué regulaciones aplican a tu sistema? → Si no, la cápsula 07 es prioritaria
¿Filtras PII en outputs del LLM? → Si no, la cápsula 04 es prioritaria

Si respondiste "no" a las primeras cuatro preguntas, sigue el módulo en orden completo. Si algunas ya las tienes resueltas, puedes enfocarte en las cápsulas específicas — pero aun así lee las demás por las técnicas avanzadas que probablemente no estés usando.

Glosario del módulo

Estos son los términos clave que vas a encontrar a lo largo de las cápsulas. Tenerlos claros desde el inicio te evita detener la lectura para buscar definiciones:

Término	Definición	Ejemplo
PII (Personally Identifiable Information)	Cualquier dato que identifique o pueda identificar a una persona específica	Nombre, email, SSN, dirección, teléfono
PII directo	PII que identifica a una persona por sí solo, sin necesidad de combinación	Número de seguro social, pasaporte, CURP
PII indirecto (quasi-identifier)	Datos que combinados pueden identificar a una persona	Código postal + fecha de nacimiento + género
Redacción	Proceso de ocultar o reemplazar PII en un texto	`"Juan García"` → `<PERSON>`
Masking	Estrategia de redacción que reemplaza caracteres con asteriscos	`juan@mail.com` → `j*@**.com`
Hashing	Estrategia de redacción que produce un valor único no reversible	`"Juan García"` → `a1b2c3d4...`
Generalización	Estrategia de redacción que reduce la especificidad del dato	`"Calle Reforma 123"` → `"Ciudad de México"`
NER (Named Entity Recognition)	Técnica de NLP que identifica entidades (personas, lugares, organizaciones) en texto	spaCy detecta "Juan García" como `PERSON`
Presidio	Librería open-source de Microsoft para detección y anonimización de PII	`AnalyzerEngine`, `AnonymizerEngine`
Pre-LLM redaction	Redacción de PII antes de enviar datos al modelo de lenguaje	Eliminar SSN del prompt
Post-LLM redaction	Detección y redacción de PII en la respuesta del modelo	Filtrar emails memorizados del output
Data minimization	Principio de enviar solo los datos estrictamente necesarios	Enviar solo el nombre, no el SSN completo
Retention policy	Regla que define cuánto tiempo se conservan datos y qué pasa al expirar	Logs de chat: 30 días → eliminar
Encryption at rest	Cifrado de datos almacenados (bases de datos, archivos, vector stores)	AES-256 para logs de conversaciones
Encryption in transit	Cifrado de datos en movimiento entre sistemas	HTTPS/TLS para llamadas a OpenAI API
GDPR	General Data Protection Regulation — regulación de protección de datos de la UE	Aplica si procesas datos de residentes UE
CCPA	California Consumer Privacy Act — ley de privacidad de datos de California	Aplica si procesas datos de residentes CA
DPIA	Data Protection Impact Assessment — evaluación de impacto obligatoria para procesamiento de alto riesgo	Requerido para AI que procesa PII masivamente
Data subject	La persona a la que pertenecen los datos personales	Tu usuario final
Reversible redaction	Redacción que permite recuperar el dato original con una clave	Para restaurar contexto post-LLM
Irreversible redaction	Redacción permanente que no permite recuperar el dato original	Para logs y datos que no necesitan restauración

Vas a ver estos términos en cada cápsula. Si en algún momento dudas del significado, regresa a esta tabla.

Herramientas y librerías del módulo

Estas son las herramientas principales que vas a utilizar y el papel que juega cada una:

Microsoft Presidio

Presidio es una librería open-source de Microsoft diseñada específicamente para detección y anonimización de PII. Tiene dos componentes principales:

presidio-analyzer: Detecta PII en texto usando una combinación de reconocedores basados en regex, NER models, y checksums. Soporta más de 30 tipos de entidades PII.
presidio-anonymizer: Aplica estrategias de redacción al PII detectado. Soporta masking, replacement, hashing, y operadores custom.

La ventaja de Presidio sobre regex manual es que combina múltiples estrategias de detección con confidence scores, maneja falsos positivos con contexto, y es extensible con reconocedores custom para tu dominio.

spaCy NER

spaCy es una librería de NLP que incluye modelos pre-entrenados para Named Entity Recognition. En este módulo se usa para detectar entidades contextuales que regex no puede capturar: nombres de personas, organizaciones, y ubicaciones que no siguen un patrón fijo.

Los modelos que usarás:

en_core_web_lg: Modelo grande en inglés, mejor accuracy para NER
es_core_news_md: Modelo mediano en español, para detección multilingüe

Python cryptography

La librería cryptography de Python proporciona primitivas criptográficas para encryption at rest. Usarás Fernet (symmetric encryption) para cifrar datos almacenados y derivar claves desde passwords.

Pydantic + FastAPI

Pydantic modela las configuraciones del PII Protection Layer con validación de tipos. FastAPI integra el layer como middleware que intercepta requests y responses automáticamente.

Cómo usar cada cápsula

Cada cápsula técnica (02-07) sigue esta estructura:

Contexto — Por qué esta pieza existe en el pipeline y qué problema resuelve
Concepto — La teoría necesaria (40% del contenido)
Implementación — Código Python completo y ejecutable (60% del contenido)
Conexión con el proyecto — Cómo encaja en el PII Protection Layer
Troubleshooting — 3-5 problemas comunes con soluciones
Ejercicios — 4-6 ejercicios prácticos con soluciones en <details>
Resumen — Puntos clave del tema
Recursos — 6-8 referencias para profundizar

Te recomiendo seguir las cápsulas en orden (02 → 07) porque cada una construye sobre la anterior. La cápsula 02 establece el contexto de la amenaza. Las cápsulas 03 y 04 cubren detección y redacción. Las cápsulas 05-07 abordan dimensiones adicionales de la protección de datos.

Trade-offs: privacidad vs utilidad

Un tema que atraviesa todo el módulo es el trade-off entre privacidad y utilidad del sistema AI. Más protección de PII = más privacidad, pero también:

❌ Menos contexto para el LLM → respuestas de menor calidad
❌ Más falsos positivos en detección → datos legítimos redactados
❌ Más latencia por request → cada scan de PII agrega ~50-200ms
❌ Más complejidad operacional → retention policies, encryption keys, audit logs

El objetivo no es maximizar privacidad a costa de la utilidad — es calibrar cada capa para tu contexto:

Tu sistema	Protección recomendada
Chatbot público	Agresiva: redactar todo PII pre-LLM, no guardar logs con datos
Herramienta interna	Moderada: redactar SSN/tarjetas, permitir nombres con consentimiento
Sistema de salud	Máxima: redactar todo, encryption at rest/transit, audit trail completo
Pipeline batch sin usuarios	Mínima: scan de PII en datos fuente, retention policy para outputs

En cada cápsula, vas a ver los trade-offs específicos de cada técnica con datos concretos de precision, recall y latencia.

Ejemplo concreto del trade-off

Para que lo veas con código real:

# Caso 1: Sin PII protection (máxima utilidad, cero privacidad)
prompt = f"""
Contexto del cliente:
- Nombre: María García López
- Email: maria.garcia@empresa.com
- SSN: 078-05-1120
- Dirección: Av. Insurgentes Sur 1602, CDMX
- Consulta: ¿Cuándo se envía mi pedido #4521?

Responde la consulta del cliente.
"""

# Caso 2: Redacción agresiva (máxima privacidad, menor utilidad)
prompt_redacted = f"""
Contexto del cliente:
- Nombre: <PERSON>
- Email: <EMAIL>
- SSN: <REDACTED>
- Dirección: <LOCATION>
- Consulta: ¿Cuándo se envía mi pedido #4521?

Responde la consulta del cliente.
"""

# Caso 3: Redacción calibrada (balance privacidad/utilidad)
prompt_balanced = f"""
Contexto del cliente:
- Nombre: Cliente #7a3f
- Email: ***@empresa.com
- Consulta: ¿Cuándo se envía mi pedido #4521?

Responde la consulta del cliente.
"""

En el Caso 1, el LLM tiene toda la información pero un leak expone SSN, email y dirección reales. En el Caso 2, el LLM no puede personalizar la respuesta (no sabe el nombre ni el dominio del email). En el Caso 3, el LLM sabe que hay un nombre (referencia anonimizada), el dominio del email (útil para contexto corporativo), y no tiene acceso al SSN ni la dirección (datos que no necesita para responder sobre un pedido).

El Caso 3 es lo que construyes en este módulo: protección calibrada por el tipo de dato y el tipo de tarea.

Resumen

Este módulo construye la capa de protección de datos personales que complementa el Sanitization Pipeline del Módulo 4 — PII protection es diferente a sanitización general
El foco principal es LLM02: Sensitive Information Disclosure, la vulnerabilidad que ocurre cuando un LLM revela datos sensibles por memorización, context leakage, o cross-conversation bleed
El pipeline completo cubre: PII scanning → pre-LLM redaction → data minimization → LLM → post-LLM redaction → retention policies → audit logging
Cada cápsula construye un bloque del pipeline: amenaza LLM02 (02), PII detection (03), PII redaction (04), data minimization (05), retention/encryption (06), compliance (07)
El trade-off central es privacidad vs utilidad: redactar PII protege a tus usuarios pero reduce el contexto disponible para el LLM
El PII Protection Layer es el sexto artefacto de la guía y se integra con todos los artefactos anteriores en el Módulo 8
Herramientas clave: Presidio para detección enterprise-grade, spaCy para NER, regex para patrones estructurados

Próxima cápsula: En la cápsula 02 vas a entender LLM02 en profundidad — cómo los LLMs memorizan datos de entrenamiento, técnicas específicas de extracción de datos sensibles, escenarios reales de data leakage, y las implicaciones regulatorias de cada tipo de fuga. Es la base para entender por qué cada técnica de protección de las cápsulas 03-07 es necesaria.

Recursos adicionales

OWASP LLM02: Sensitive Information Disclosure — Documentación oficial de la vulnerabilidad principal que mitiga este módulo
Microsoft Presidio Documentation — Herramienta de detección y anonimización de PII, core de este módulo
OWASP Top 10 for LLM Applications 2025 — Framework completo de vulnerabilidades LLM
spaCy NER Models — Modelos de Named Entity Recognition para detección de PII
GDPR Official Text — Texto oficial del Reglamento General de Protección de Datos
CCPA Official Text — California Consumer Privacy Act para referencia de compliance
NIST Privacy Framework — Framework de privacidad del NIST, complemento a OWASP
EU AI Act — Regulación de la UE sobre AI, relevante para compliance de sistemas AI

Creado: Marzo 2026 Versión: 1.0

← Anterior8. Proyecto: Secrets Management Setup Siguiente →2. LLM02 en Detalle: Sensitive Information Disclosure