Módulo 4: Input & Output Sanitization

1. Introducción: Input & Output Sanitization

Descripción

En el Módulo 3 construiste defensas contra prompt injection — ataques intencionales donde un usuario manipula al modelo para ejecutar instrucciones no autorizadas. Tu Injection Defense Pipeline detecta patrones maliciosos, bloquea intentos de override, y protege el system prompt. Esa es una capa crítica. Pero hay un problema: prompt injection es solo una de las formas en que los datos pueden causar daño en tu sistema AI.

Un input no necesita ser malicioso para ser peligroso. Un usuario que pega un texto con caracteres Unicode invisibles puede causar que tu modelo procese instrucciones ocultas. Un input con 50,000 caracteres puede agotar tu token budget en una sola request. Un output del modelo que contiene JSON malformado puede romper tu frontend. Un output con contenido tóxico puede destruir la reputación de tu empresa. Un output que incluye PII (información personal identificable) de otro usuario puede violar GDPR. Ninguno de estos problemas es prompt injection — pero todos requieren defensas.

Este módulo construye la capa de higiene de datos que complementa las defensas anti-injection del Módulo 3. Si el Módulo 3 fue "defender contra ataques intencionales", este módulo es "asegurar que todo lo que entra y sale de tu sistema AI es limpio, válido y seguro." Es la diferencia entre un guardia de seguridad (M3) y un inspector de calidad (M4) — necesitas ambos.

El foco principal de este módulo es la mitigación de LLM05: Improper Output Handling, una de las vulnerabilidades más subestimadas del OWASP LLM Top 10 2025. LLM05 ocurre cuando la aplicación confía ciegamente en el output del LLM y lo pasa directamente a otro sistema, UI, o base de datos sin validación. Es el equivalente AI de confiar en un campo de formulario web sin sanitizar — excepto que el "formulario" es un modelo que genera contenido impredecible.

¿Por qué un módulo completo para sanitización?

La decisión de dedicar un módulo a sanitización de inputs y outputs (separado de prompt injection) es deliberada. Hay tres razones:

1. Prompt injection es un ataque; la sanitización es higiene

El Módulo 3 defiende contra un adversario activo que intenta manipular tu sistema. Este módulo defiende contra datos que causan problemas simplemente por su naturaleza: mal formados, demasiado largos, con encoding inconsistente, con contenido inapropiado, o con estructura inesperada. No necesitas un atacante para tener un output tóxico — el modelo puede producirlo solo.

2. LLM05 (Improper Output Handling) requiere defensas propias

En el Módulo 2 (cápsula 05), viste que LLM05 ocurre cuando un output del modelo se ejecuta en un downstream system sin validación. El modelo genera JavaScript → tu frontend lo renderiza como HTML → XSS. El modelo genera SQL → tu backend lo ejecuta → data exfiltration. El modelo genera un URL → tu sistema lo sigue → SSRF. Estas no son vulnerabilidades del modelo — son vulnerabilidades de tu aplicación que confía en el modelo sin verificar.

3. La calidad de datos afecta la calidad del sistema

Un input con Unicode mixto produce embeddings inconsistentes. Un input sin normalizar genera resultados diferentes para la misma pregunta formulada con acentos distintos. Un output sin schema validation rompe integraciones downstream. La sanitización no es solo seguridad — es calidad de ingeniería.

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

Al terminar este módulo vas a poder:

Implementar input sanitization completa: normalización Unicode, character whitelisting, length limits por endpoint, encoding normalization, detección de inputs malformados
Validar outputs del LLM con Pydantic schemas: structured outputs con OpenAI, fallback strategies cuando la validación falla, retry con prompt ajustado, respuesta default
Filtrar contenido en outputs: detección de toxicidad con heurísticas y API de moderación, detección de off-topic responses, flags de posibles hallucinations
Construir guardrails profundos que van más allá de validación básica: guardrails-ai framework, NeMo Guardrails conceptos, guardrails custom encadenados
Diseñar el pipeline completo: Input → Sanitize → Validate → LLM → Validate Output → Filter → Sanitize Output → Respond, implementado como middleware FastAPI
Manejar edge cases de producción: streaming responses, multi-modal inputs, batch processing, rate limiting integrado, caching de inputs sanitizados
Implementar estrategias de fallback robustas: qué hacer cuando un input no pasa sanitization, qué hacer cuando un output no pasa validación, cuántos retries antes de fallback
Construir un Sanitization Pipeline completo como proyecto: middleware FastAPI reutilizable con input sanitizer, output validator, content filter, guardrails, y audit logging

Roadmap del módulo

Este módulo tiene 8 cápsulas que construyen el pipeline de sanitización capa por capa:

#	Cápsula	Qué aprenderás
01	Introducción: Input & Output Sanitization	Por qué este módulo, roadmap, conexión con el proyecto, setup
02	Input Sanitization: Fundamentos	Limpieza de inputs, normalización Unicode, whitelisting, length limits, InputSanitizer class
03	Output Validation con Pydantic	Validación estructurada de outputs LLM, schemas, retry strategies, structured outputs de OpenAI
04	Content Filtering	Toxicidad, off-topic detection, moderation API, content policies, filtros custom
05	Guardrails Profundos	guardrails-ai, NeMo Guardrails, guardrails custom, chaining, performance
06	Pipeline Input → Output Completo	Flujo completo como middleware FastAPI, error handling por etapa, fallbacks
07	Edge Cases y Producción	Streaming, multi-modal, batch processing, caching, versionado de pipelines
08	Proyecto: Sanitization Pipeline	Pipeline completo reutilizable con todas las capas integradas

La progresión es: contexto (01) → input (02) → output (03-04) → guardrails (05) → integración (06) → producción (07) → proyecto (08).

Las cápsulas 02-04 construyen las piezas individuales del pipeline. La cápsula 05 agrega guardrails como capa de orquestación. La cápsula 06 integra todo en un flujo completo. La cápsula 07 aborda los edge cases que solo aparecen en producción. La cápsula 08 es el proyecto donde construyes el Sanitization Pipeline como artefacto reutilizable.

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             ← ESTÁS AQUÍ
├── Módulo 5: Secrets Management
└── Módulo 6: Data Privacy & PII Protection

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 1 te dio el mapa de amenazas. El Módulo 2 te dio el framework OWASP para clasificarlas. El Módulo 3 implementó la defensa contra la amenaza #1 (LLM01: Prompt Injection). Ahora el Módulo 4 aborda la siguiente capa: la higiene completa del flujo de datos, con foco en LLM05 (Improper Output Handling).

La relación con el Módulo 3 es de complemento, no de repetición:

Módulo 3 (Injection Defense)          Módulo 4 (Sanitization)
─────────────────────────             ─────────────────────────
Detecta ataques intencionales         Limpia datos mal formados
Bloquea prompt injection              Normaliza encoding
Protege el system prompt              Valida estructura de outputs
Previene instruction override         Filtra contenido tóxico
Foco: LLM01                          Foco: LLM05

Juntos, los pipelines del M3 y M4 forman el flujo de datos seguro del sistema: injection detection (M3) + input sanitization (M4) → LLM → output validation (M4) + output filtering (M4).

Prerequisites

Para este módulo necesitas:

Módulos 1-3 completados: Threat Model Document, OWASP Mapping Audit, Injection Defense Pipeline
Python 3.10+ instalado
Una API key de OpenAI (o proveedor compatible)
Familiaridad con Pydantic v2 — validators, BaseModel, Field
Familiaridad con FastAPI — middleware, dependencias, request/response lifecycle

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 openai pydantic fastapi uvicorn httpx bleach
pip install unicodedata2  # Para normalización Unicode avanzada (opcional)

Si estás empezando desde este módulo:

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

pip install openai pydantic fastapi uvicorn httpx bleach

export OPENAI_API_KEY="sk-..."

Verificación rápida:

import unicodedata
from pydantic import BaseModel, Field
from openai import OpenAI

text = "Héllo Wörld"
normalized = unicodedata.normalize("NFKC", text)
print(f"Original: {text!r}")
print(f"Normalized: {normalized!r}")

class TestOutput(BaseModel):
    answer: str = Field(min_length=1)
    confidence: float = Field(ge=0.0, le=1.0)

client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Di 'Sanitization check OK'."}],
    temperature=0,
)
print(response.choices[0].message.content)
# Output esperado:
# Original: 'Héllo Wörld'
# Normalized: 'Héllo Wörld'
# Sanitization check OK

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

Paquete	Para qué
`pydantic`	Validación de outputs con schemas
`fastapi`	Middleware pipeline
`bleach`	Sanitización HTML/markdown
`httpx`	Llamadas async a APIs de moderación
`unicodedata` (stdlib)	Normalización Unicode

Conexión con el proyecto del módulo

Este módulo cierra con el proyecto Sanitization Pipeline: un middleware FastAPI reutilizable que implementa el flujo completo de sanitización input → output. Es el cuarto artefacto de la guía y se integra directamente con el Injection Defense Pipeline del Módulo 3.

El Sanitization Pipeline incluye:

Input Sanitizer — Normalización Unicode, length limits, character whitelisting, encoding cleanup
Output Validator — Pydantic schemas para validar estructura de respuestas del LLM
Content Filter — Toxicidad, off-topic detection, content policy enforcement
Guardrails Integration — Orquestación de validaciones con fallback strategies
Audit Logger — Registro de cada activación del pipeline con métricas

El pipeline se monta como middleware FastAPI:

Request
  │
  ▼
┌──────────────────────────┐
│  Input Sanitizer         │ ← Normaliza, limpia, valida longitud
├──────────────────────────┤
│  Injection Detector (M3) │ ← Tu pipeline del Módulo 3
├──────────────────────────┤
│  LLM Processing          │ ← OpenAI API call
├──────────────────────────┤
│  Output Validator        │ ← Pydantic schema enforcement
├──────────────────────────┤
│  Content Filter          │ ← Toxicidad, off-topic, PII
├──────────────────────────┤
│  Output Sanitizer        │ ← HTML escape, encoding normalization
├──────────────────────────┤
│  Audit Logger            │ ← Métricas, flags, alertas
└──────────────────────────┘
  │
  ▼
Response

En el Módulo 8 (proyecto integrador), el Sanitization Pipeline se integra con el Injection Defense Pipeline (M3), el Secrets Management Setup (M5), y el PII Protection Layer (M6) para formar el sistema completo asegurado.

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)              ← LO PRODUCES AQUÍ
Módulo 5: + Secrets Management Setup (credenciales)
Módulo 6: + PII Protection Layer (datos sensibles)
Módulo 7: + Security Audit Report (validación)
Módulo 8: → Secured AI System (integración total)

LLM05: Improper Output Handling — el foco de este módulo

Este módulo mitiga primariamente LLM05: Improper Output Handling. Entender esta vulnerabilidad es clave para todo lo que sigue.

Qué es LLM05

LLM05 ocurre cuando la aplicación toma el output de un LLM y lo usa directamente — sin validar, sin sanitizar, sin verificar — en un downstream system. El output del LLM se trata como "confiable" simplemente porque viene del modelo.

Por qué es peligroso

El LLM no produce outputs determinísticos. Puede generar:

JavaScript en una respuesta de texto → Si tu frontend renderiza HTML sin escapar, tienes XSS
SQL en una respuesta de "análisis" → Si tu backend ejecuta queries generadas, tienes SQL injection vía LLM
URLs maliciosas → Si tu sistema sigue links generados, tienes SSRF
Datos de otros usuarios → Si el contexto se contamina, tienes data leakage
Contenido tóxico o ilegal → Si no filtras, tienes un problema de reputación y compliance

El patrón de ataque

# VULNERABLE: confiar en el output del LLM sin validar
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": user_input}],
)
output = response.choices[0].message.content

# El output se usa directamente en otro sistema
database.execute(output)        # SQL injection vía LLM output
template.render(content=output) # XSS vía LLM output
requests.get(output)            # SSRF vía LLM output

# SEGURO: validar y sanitizar antes de usar
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": user_input}],
)
output = response.choices[0].message.content

validated = validate_output(output)    # Schema check
filtered = filter_content(validated)   # Content policy
sanitized = sanitize_output(filtered)  # HTML escape, encoding

# Solo después de las tres capas se usa el output
return {"answer": sanitized}

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

Qué hace diferente a este módulo vs Production Best Practices (#13)

Si completaste Production Best Practices (#13), ya tienes guardrails básicos. Este módulo no repite ese contenido — lo profundiza significativamente:

Concepto	Production Best Practices (#13)	Este módulo (M4)
Input validation	"Valida longitud y tipo"	Normalización Unicode, encoding attacks, character whitelisting, InputSanitizer class completa
Output validation	"Usa Pydantic"	Structured outputs con OpenAI, retry strategies, fallback chains, nested validation, custom validators
Content filtering	Mención básica	Moderation API, toxicity scoring, off-topic detection, custom filters, language-specific
Guardrails	"Qué es un guardrail"	guardrails-ai framework, NeMo Guardrails, custom guardrails, chaining, performance
Pipeline	Concepto general	Middleware FastAPI completo con error handling por etapa, audit logging, métricas
Edge cases	No cubierto	Streaming, multi-modal, batch, caching, versionado

La regla es: si algo te suena familiar de #13, aquí vas a ver la versión profunda, con código completo y consideraciones de producción que #13 no cubrió.

Lo que NO cubre este módulo

Para mantener el foco y evitar duplicar contenido:

Prompt injection defense: Eso fue el Módulo 3. Aquí complementas con sanitización, no reemplazas la detección de injection.
PII protection en profundidad: Aquí detectas PII como parte del content filter (flag básico). El Módulo 6 implementa la protección completa con Presidio.
Secrets management: Las API keys que usas para los servicios de moderación se protegen en el Módulo 5.
Security testing del pipeline: Aquí construyes el pipeline. El Módulo 7 lo testea con adversarial inputs y pen testing.
Compliance legal: Mencionamos GDPR como motivación para filtrar PII en outputs, no como guía de compliance.

Errores comunes al abordar sanitización

"Ya tengo input validation, no necesito sanitización"

Input validation (Pydantic en tu endpoint FastAPI) verifica tipos y campos — que message es un string, que user_id tiene formato correcto. La sanitización opera sobre el contenido del string: encoding, caracteres ocultos, HTML embebido, longitud. Un input puede pasar validación Pydantic con nota perfecta y aún necesitar sanitización.

"Si el modelo es bueno, el output será bueno"

GPT-4o es impresionante, pero no garantiza outputs seguros. Puede producir JSON malformado si se queda sin tokens, incluir PII que encontró en el contexto, generar contenido tóxico en edge cases, o fabricar URLs que parecen legítimas. La calidad del modelo no elimina la necesidad de validación de outputs.

"Sanitizar outputs es innecesario — solo muestro texto"

Incluso si tu sistema solo muestra texto al usuario (no ejecuta el output en código), un output tóxico, con PII de otro usuario, o con información incorrecta presentada como factual puede causar daño de reputación, violaciones de privacidad, o liability legal. La sanitización de outputs no es solo técnica — es protección del negocio.

"Los guardrails agregan demasiada complejidad"

Sin guardrails, cada developer implementa sus propias verificaciones de forma ad-hoc. Con guardrails como framework, las verificaciones son consistentes, configurables, y testeables. La complejidad inicial se paga con mantenibilidad a largo plazo.

"Puedo confiar en el modelo para moderarse a sí mismo"

Las instrucciones en el system prompt como "nunca generes contenido ofensivo" son una defensa débil. El modelo intenta seguirlas, pero puede ser convencido de ignorarlas con prompts creativos, o puede producir contenido problemático sin intención. La moderación del modelo es una capa, no la defensa completa.

Tipos de sanitización: input vs output

Este módulo cubre ambos lados del pipeline: inputs y outputs. Es importante entender que son problemas diferentes:

Input sanitization (cápsulas 02)

Operaciones que aplicas al input del usuario antes de que llegue al LLM:

Input del usuario: "Ｈｅｌｌｏ\u200b <b>world</b>"
                         │
                    ┌────▼─────┐
                    │ Unicode  │ → "Hello\u200b <b>world</b>"
                    │ NFKC     │
                    ├──────────┤
                    │ Zero-    │ → "Hello <b>world</b>"
                    │ width    │
                    ├──────────┤
                    │ HTML     │ → "Hello world"
                    │ strip    │
                    ├──────────┤
                    │ Length   │ → "Hello world" (dentro del límite)
                    │ check    │
                    └────┬─────┘
                         │
                    Input limpio al LLM

Output sanitization (cápsulas 03-04)

Operaciones que aplicas al output del LLM antes de que llegue al usuario:

Output del LLM: "{'answer': 'Contact john@email.com for info on <script>...'}"
                         │
                    ┌────▼─────┐
                    │ Schema   │ → Validar JSON, tipos, rangos
                    │ validate │
                    ├──────────┤
                    │ Content  │ → Detectar PII (john@email.com)
                    │ filter   │   Detectar code injection (<script>)
                    ├──────────┤
                    │ Guard-   │ → Verificar políticas de negocio
                    │ rails    │
                    ├──────────┤
                    │ Sanitize │ → Escapar HTML, normalizar encoding
                    │ output   │
                    └────┬─────┘
                         │
                    Output limpio al usuario

La separación es clara: input sanitization protege al LLM de datos mal formados; output sanitization protege al usuario (y a downstream systems) de outputs problemáticos.

La analogía: inspección de calidad en una fábrica

Imagina una fábrica que produce componentes electrónicos:

Materia prima → Inspección entrada → Producción → Inspección salida → Empaque → Cliente

El guardia de seguridad en la puerta (Módulo 3) verifica que nadie entre con intenciones maliciosas. Pero el inspector de calidad en la línea de producción (este módulo) verifica algo diferente:

Inspección de entrada (Input Sanitization): ¿La materia prima tiene las especificaciones correctas? ¿No está contaminada? ¿Tiene las dimensiones esperadas?
Control de proceso (Guardrails): ¿La máquina de producción opera dentro de parámetros seguros?
Inspección de salida (Output Validation): ¿El componente producido cumple con el schema de calidad? ¿Tiene defectos visibles? ¿Pasa las pruebas funcionales?
Filtro final (Content Filtering): ¿El componente es seguro para el cliente? ¿No tiene bordes afilados (contenido tóxico)? ¿Está correctamente etiquetado (no contiene PII)?

Seguridad de fábrica                  Seguridad AI
────────────────────                  ────────────────────────
Guardia en la puerta                  Injection Detector (M3)
Inspector de materia prima            Input Sanitizer (M4)
Control de proceso                    Guardrails (M4)
Inspector de producto terminado       Output Validator (M4)
Filtro de seguridad del producto      Content Filter (M4)
Registro de calidad                   Audit Logger (M4)

El guardia y el inspector no se reemplazan — se complementan. Un componente puede pasar el control de seguridad (no fue saboteado) pero fallar la inspección de calidad (está fuera de especificación). Igualmente, un input puede pasar el injection detector (no es un ataque) pero fallar la sanitización (tiene encoding inconsistente).

El pipeline completo como arquitectura

Antes de profundizar en cada componente (cápsulas 02-07), necesitas ver el flujo completo. Este diagrama es la referencia para todo el módulo:

┌──────────────────────────────────────────────────────────────────┐
│                    SANITIZATION PIPELINE                          │
│                                                                  │
│  INPUT PHASE                                                     │
│  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐     │
│  │ 1. Normalize   │→ │ 2. Sanitize    │→ │ 3. Validate    │     │
│  │    Unicode     │  │    HTML/chars   │  │    Length/type  │     │
│  └────────────────┘  └────────────────┘  └────────────────┘     │
│           │                   │                   │              │
│           │          Input Sanitizer (Cap 02)     │              │
│           ├───────────────────┴───────────────────┤              │
│           │                                       │              │
│           ▼                                       │              │
│  ┌────────────────┐                               │              │
│  │ 4. Injection   │ ← Módulo 3 Pipeline           │              │
│  │    Detection   │                               │              │
│  └────────────────┘                               │              │
│           │                                       │              │
│           ▼                                       │              │
│  ┌────────────────┐                               │              │
│  │ 5. LLM Call    │ ← Tu modelo (GPT-4o, etc.)    │              │
│  └────────────────┘                               │              │
│           │                                       │              │
│  OUTPUT PHASE                                     │              │
│  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐     │
│  │ 6. Validate    │→ │ 7. Filter      │→ │ 8. Sanitize    │     │
│  │    Schema      │  │    Content     │  │    Output      │     │
│  └────────────────┘  └────────────────┘  └────────────────┘     │
│  Output Validator     Content Filter      Output Sanitizer      │
│  (Cap 03)             (Cap 04)            (Cap 02)              │
│           │                                       │              │
│           ├───────────────────────────────────────┤              │
│           │                                       │              │
│           ▼                                       │              │
│  ┌────────────────┐                                              │
│  │ 9. Audit Log   │ ← Registro de cada paso                     │
│  └────────────────┘                                              │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Cada cápsula construye un bloque de este diagrama. La cápsula 06 los integra en un middleware FastAPI. La cápsula 08 es el proyecto donde lo implementas completo.

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 Sanitization Pipeline
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 es fundamento puro (input sanitization). Las cápsulas 03 y 04 cubren el lado output. La cápsula 05 introduce guardrails como capa de orquestación. La cápsula 06 integra todo. La cápsula 07 aborda lo que solo ves en producción.

Trade-offs: sanitización vs experiencia de usuario

Un tema que atraviesa todo el módulo es el trade-off entre seguridad y usabilidad. Más sanitización = más seguridad, pero también:

❌ Más inputs legítimos rechazados (falsos positivos)
❌ Más latencia por request (cada capa agrega ~5-50ms)
❌ Más complejidad en debugging (¿en qué capa falló?)
❌ Más outputs modificados que pierden naturalidad

El objetivo no es maximizar defensas — es calibrar cada capa para tu contexto:

Tu sistema	Sanitización recomendada
Chatbot público	Agresiva: length limits estrictos, content filter alto, retry on failure
Herramienta interna	Moderada: normalización, schema validation, content filter medio
Pipeline batch	Mínima: encoding normalization, schema validation, logging
Sistema de salud	Máxima: todo lo anterior + PII filter + hallucination check + audit trail

En cada cápsula, vas a ver los trade-offs específicos de cada técnica con datos concretos de performance y false positive rates.

La importancia de LLM05 en la industria

Para que entiendas el peso de la sanitización en el mundo profesional, LLM05 (Improper Output Handling) no es una vulnerabilidad teórica. Hay razones concretas por las que la industria la prioriza:

Incidentes reales (patrones comunes)

Sin revelar nombres específicos por razones de confidencialidad, estos son patrones de incidentes documentados en la industria:

Patrón	Qué pasó	Impacto
XSS via LLM	Un chatbot generó HTML que el frontend renderizó sin escapar. El modelo incluyó un tag `<img onerror>` en su respuesta.	Session hijacking de usuarios
SQL via LLM	Un sistema de "natural language to SQL" ejecutó queries generadas por el modelo sin validación. Un prompt creativo generó un `DROP TABLE`.	Pérdida de datos
PII leakage	Un modelo con context window compartido incluyó datos de un usuario anterior en la respuesta al siguiente usuario.	Violación de GDPR, multa
Toxic output	Un chatbot de servicio al cliente, bajo presión de un usuario insistente, generó insultos. Screenshots viralizados en redes sociales.	Daño reputacional masivo
SSRF via LLM	Un modelo generó URLs que el sistema backend siguió automáticamente. Un atacante hizo que el modelo generara URLs apuntando a servicios internos.	Acceso a infraestructura interna

Cada uno de estos incidentes hubiera sido prevenido con un pipeline de sanitización como el que construyes en este módulo.

Regulaciones que requieren output validation

Regulación	Requisito relevante
EU AI Act (2024)	Sistemas AI de alto riesgo deben implementar "appropriate data governance" incluyendo validación de outputs
GDPR	Los datos personales no pueden revelarse sin consentimiento — el pipeline debe filtrar PII en outputs
CCPA	Similar a GDPR para California — requiere control sobre datos personales en outputs
SOC 2	"Processing Integrity" requiere que los outputs sean completos, precisos, y autorizados
HIPAA	Información médica en outputs de sistemas de salud debe estar protegida

No necesitas ser una empresa regulada para beneficiarte de estas prácticas. Pero si lo eres, el Sanitization Pipeline no es opcional — es requisito.

El costo de no sanitizar: un ejercicio mental

Piensa en tu sistema AI actual y responde estas preguntas:

Si tu modelo genera JavaScript en una respuesta, ¿tu frontend lo ejecuta? Si no estás seguro, probablemente sí.
Si tu modelo incluye un email de usuario en su respuesta, ¿lo detectas antes de mostrarlo? Si no, estás exponiendo PII.
Si tu modelo genera una respuesta de 50,000 tokens, ¿tu sistema lo maneja? Si no, tu frontend podría crashear o tu factura de tokens explotar.
Si tu modelo dice algo ofensivo, ¿lo filtras antes de que el usuario lo vea? Si no, un screenshot en Twitter puede volverse viral.
Si tu modelo genera JSON malformado, ¿tu integración downstream lo maneja? Si no, tienes errores 500 en producción.

Si respondiste "no" a alguna, este módulo te resuelve esos problemas. No son hipotéticos — son los bugs de producción más comunes en sistemas AI.

Tu sistema: ejercicio de pre-evaluación

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

¿Normalizas encoding de inputs? → Si no, la cápsula 02 es prioritaria
¿Validas la estructura de outputs del LLM con schemas? → Si no, la cápsula 03 es prioritaria
¿Filtras contenido tóxico o inapropiado en outputs? → Si no, la cápsula 04 es prioritaria
¿Tienes guardrails más allá de validación básica? → Si no, la cápsula 05 es prioritaria
¿Tu pipeline de sanitización está integrado como middleware? → Si no, la cápsula 06 es prioritaria
¿Manejas streaming responses con validación? → Si no, la cápsula 07 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.

Resumen

Este módulo construye la capa de higiene de datos que complementa las defensas anti-injection del Módulo 3 — sanitización es diferente a detección de ataques
El foco principal es LLM05: Improper Output Handling, la vulnerabilidad que ocurre cuando confías ciegamente en el output del LLM sin validar
El pipeline completo cubre 9 etapas: normalización → sanitización → validación de input → injection detection → LLM → validación de output → content filter → sanitización de output → audit log
Cada cápsula construye un bloque del pipeline: input sanitizer (02), output validator (03), content filter (04), guardrails (05), pipeline integrado (06), edge cases (07)
Este módulo profundiza Production Best Practices (#13) — no repite. Si algo te suena familiar, aquí ves la versión de producción con edge cases y performance
El trade-off central es sanitización vs experiencia de usuario: más defensas = más seguridad pero más falsos positivos y más latencia
El Sanitization Pipeline es el cuarto artefacto de la guía y se integra con el Injection Defense Pipeline (M3) para formar el flujo de datos seguro
En el Módulo 8, este pipeline se combina con secrets management (M5) y PII protection (M6) para el sistema completo asegurado

Próxima cápsula: En la cápsula 02 vas a construir el Input Sanitizer — la primera línea de defensa que normaliza, limpia y valida todo lo que entra a tu sistema antes de que toque el LLM. Verás ataques de encoding Unicode, character injection, y construirás una clase InputSanitizer completa y reutilizable.

Recursos adicionales

OWASP LLM05: Improper Output Handling — Documentación oficial de la vulnerabilidad principal que mitiga este módulo, con escenarios de ataque y mitigaciones
OWASP Top 10 for LLM Applications 2025 — Framework completo con las 10 vulnerabilidades, referencia para todo el módulo
Pydantic V2 Documentation — Validators — Referencia oficial de Pydantic para validación avanzada de outputs
OpenAI Structured Outputs — Guía oficial para obtener outputs estructurados del modelo, complemento a Pydantic validation
OpenAI Moderation API — Endpoint de moderación para content filtering, cubierto en la cápsula 04
Unicode Security Considerations (Unicode.org) — Reporte técnico sobre ataques basados en Unicode, base para la cápsula 02
Guardrails AI Documentation — Framework de guardrails para validación de outputs LLM, cubierto en la cápsula 05
OWASP Input Validation Cheat Sheet — Guía de validación de inputs con principios transferibles a AI

Creado: Marzo 2026 Versión: 1.0

← Anterior8. Proyecto: Injection Defense Pipeline Siguiente →2. Input Sanitization: Fundamentos