1. Introducción: Proyecto Integrador — Secured AI System

Descripción

Has construido siete módulos de defensas: threat model, OWASP mapping, injection defense, sanitization pipeline, secrets management, PII protection, y security audit report. Cada pieza funciona individualmente. Pero un sistema seguro no es una colección de piezas — es una arquitectura integrada donde cada capa sabe de la existencia de las demás, donde el orden importa, y donde un fallo en una capa activa el plan B de la siguiente. Este módulo te enseña a conectar todo.

La diferencia entre "tengo 7 defensas" y "tengo un sistema seguro" es la integración. Un firewall que bloquea injection pero deja pasar PII es una defensa individual. Un pipeline donde el injection filter limpia el input, el PII scanner verifica que no haya datos sensibles, y el output validator confirma que la respuesta es segura — eso es un sistema. Vas a construir ese sistema en este módulo.

Este módulo es el proyecto final de la guía. No hay conceptos nuevos — hay arquitectura nueva. Vas a tomar cada artefacto que construiste en M1-M7, conectarlos en un pipeline coherente, resolver los conflictos entre capas, configurar el sistema para diferentes entornos, y producir un Secured AI System que es portfolio-worthy. Al final, tendrás un sistema que puedes mostrar en entrevistas, presentar en tu equipo, o desplegar como base para un producto real.

---

El problema que resuelve

Construir defensas individuales es necesario pero insuficiente. El problema real aparece cuando intentas hacerlas trabajar juntas. Piensa en lo que has construido hasta ahora:

• M1: Un threat model que identifica riesgos
• M2: Un mapping OWASP que categoriza vulnerabilidades
• M3: Un injection defense pipeline que detecta ataques
• M4: Un sanitization pipeline que limpia inputs/outputs
• M5: Un secrets manager que protege credenciales
• M6: Un PII protection layer que redacta datos sensibles
• M7: Un security audit report que valida todo

Siete artefactos. Siete carpetas. Cero integración. Eso es exactamente lo que pasa en la industria: equipos que tienen herramientas de seguridad pero no un sistema de seguridad. Un estudio de Gartner de 2024 encontró que el 65% de las organizaciones que sufrieron brechas de seguridad en sus sistemas AI tenían defensas individuales instaladas — el problema fue que esas defensas no estaban conectadas.

Los desafíos de integración son específicos y predecibles:

Conflictos de orden. ¿El injection detector va antes o después del PII scanner? Si va antes, puede alertar sobre tokens de PII redactados como [REDACTED_EMAIL] pensando que son injection markers. Si va después, puede que no detecte injections ocultas en datos PII. Hay un orden correcto, y encontrarlo requiere entender las dependencias entre capas.

Interferencia entre capas. La sanitization puede modificar el input de forma que el injection detector ya no reconozca patrones. El PII redactor puede crear placeholders que confundan al output validator. Cada capa transforma el dato, y la capa siguiente recibe un dato diferente al original. Gestionar estas transformaciones es el trabajo de integración.

Error propagation. Si el secrets manager falla al cargar una API key, ¿qué pasa con el injection detector que necesita llamar a un LLM evaluador? ¿Se detiene todo el pipeline? ¿Se continúa sin esa capa? Las decisiones de error handling entre capas son críticas y no tienen una respuesta obvia — dependen de tu tolerancia al riesgo.

Performance compuesta. Cada capa añade latencia. Si el injection detector toma 200ms, el sanitizer 100ms, el PII scanner 150ms, y el output validator 200ms, ya llevas 650ms solo en seguridad — sin contar la llamada al LLM. El presupuesto de performance necesita gestión activa.

Para dimensionar el problema, observa la diferencia entre un sistema con defensas individuales y un sistema integrado:

from dataclasses import dataclass, field

@dataclass
class SecuritySystem:
    """Contraste entre defensas individuales y sistema integrado."""
    name: str
    layers: list[str]
    has_defined_order: bool
    has_error_handling: bool
    has_layer_contracts: bool
    has_performance_budget: bool
    has_env_config: bool

    @property
    def integration_score(self) -> int:
        checks = [
            self.has_defined_order,
            self.has_error_handling,
            self.has_layer_contracts,
            self.has_performance_budget,
            self.has_env_config,
        ]
        return sum(checks)

    @property
    def assessment(self) -> str:
        score = self.integration_score
        if score == 0:
            return "FRAGMENTADO — defensas aisladas sin coordinación"
        elif score <= 2:
            return "PARCIAL — algunas conexiones pero gaps significativos"
        elif score <= 4:
            return "SÓLIDO — integración buena con áreas de mejora"
        else:
            return "INTEGRADO — sistema coordinado con defensa en profundidad"


before = SecuritySystem(
    name="Pre-integración (M1-M7 individuales)",
    layers=["injection", "sanitization", "pii", "secrets", "audit"],
    has_defined_order=False,
    has_error_handling=False,
    has_layer_contracts=False,
    has_performance_budget=False,
    has_env_config=False,
)

after = SecuritySystem(
    name="Post-integración (Secured AI System)",
    layers=["injection", "sanitization", "pii", "secrets", "audit"],
    has_defined_order=True,
    has_error_handling=True,
    has_layer_contracts=True,
    has_performance_budget=True,
    has_env_config=True,
)

for system in [before, after]:
    print(f"{system.name}:")
    print(f"  Score: {system.integration_score}/5")
    print(f"  Estado: {system.assessment}")
    print()

# Output esperado:
# Pre-integración (M1-M7 individuales):
#   Score: 0/5
#   Estado: FRAGMENTADO — defensas aisladas sin coordinación
#
# Post-integración (Secured AI System):
#   Score: 5/5
#   Estado: INTEGRADO — sistema coordinado con defensa en profundidad

Al final de este módulo, tu sistema pasará de 0/5 a 5/5. Esa es la meta.

---

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

Al terminar este módulo vas a poder:

1. Integrar todas las capas de seguridad (M1-M7) en un pipeline unificado

   • Conectarás injection detection, sanitization, PII protection, y output validation en una secuencia coherente
   • Resolverás dependencias entre capas con un grafo de ejecución explícito
   • Producirás un SecuredAIPipeline que encapsula todo el flujo

2. Implementar el flujo completo de un request seguro de principio a fin

   • Trazarás un request desde su entrada hasta la respuesta final, pasando por cada capa
   • Instrumentarás timing y logging en cada paso del pipeline
   • Verificarás que cada transformación preserva la integridad semántica del input

3. Cerrar los gaps identificados en el Security Audit Report (M7)

   • Revisarás cada finding del audit y verificarás que el sistema integrado lo mitiga
   • Implementarás fixes para findings que las capas individuales no cubrían
   • Generarás un reporte de cierre que mapea findings → mitigaciones

4. Crear un deployment checklist que cubre seguridad pre-producción

   • Definirás gates de seguridad para cada etapa: development → staging → production
   • Incluirás verificaciones de secrets, permisos, configuración, y defensas activas
   • Automatizarás las verificaciones críticas con scripts ejecutables

5. Documentar las decisiones de seguridad con ADRs (Architecture Decision Records)

   • Registrarás cada decisión de diseño con contexto, opciones, y justificación
   • Crearás un documento vivo que explica el "por qué" detrás de cada elección
   • Facilitarás el onboarding de nuevos desarrolladores al sistema de seguridad

6. Crear un incident response runbook para escenarios de ataque

   • Definirás procedimientos para los 5 incidentes más probables según tu threat model
   • Incluirás pasos de detección, contención, erradicación, y recuperación
   • Crearás templates de comunicación para stakeholders

7. Actualizar el OWASP mapping con el estado final del sistema integrado

   • Revisarás las 10 categorías OWASP con las defensas integradas
   • Documentarás el estado final: mitigado, parcialmente mitigado, o no aplicable
   • Compararás la postura de seguridad pre-integración vs post-integración

8. Producir un Secured AI System portfolio-worthy con documentación completa

   • Generarás un README de seguridad que explica la arquitectura a cualquier audiencia
   • Incluirás diagramas, métricas, y evidencia de testing
   • Crearás un repositorio presentable para entrevistas o demos

---

Roadmap del módulo

#	Cápsula	Qué aprenderás
01	Introducción: Proyecto Integrador	Por qué integrar, desafíos de integración, visión general
02	Integration Architecture	Flujo completo de un request, orden de capas, pipeline class
03	Closing Audit Gaps	Revisar findings M7, implementar fixes, reporte de cierre
04	Deployment Checklist	Gates de seguridad, verificaciones pre-prod, automatización
05	Security Documentation	ADRs, README de seguridad, diagramas de arquitectura
06	Incident Response Runbook	Procedimientos de respuesta, templates de comunicación
07	OWASP Final Assessment	Mapping final, comparación pre/post, métricas de cobertura
08	Proyecto: Secured AI System	Sistema completo integrado, documentado y testeado

Progresión: contexto (01) → arquitectura (02) → validación (03-04) → documentación (05-06) → evaluación (07) → entrega (08).

---

Contexto en la guía

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           ✅ Completado

Phase 3: Production Security (Módulos 7-8)
├── Módulo 7: Security Testing & Auditing             ✅ Completado
└── Módulo 8: Proyecto Integrador — Secured AI System ← ESTÁS AQUÍ

Este es el módulo final. Todo lo que construiste en M1-M7 converge aquí. No hay un "Módulo 9" — lo que produzcas en este módulo es el resultado final de la guía.

---

Prerequisites

Para este módulo necesitas:

• Módulos 1-7 completados — necesitas todos los artefactos construidos y validados
• Python 3.10+ con entorno virtual activo
• Security Audit Report (M7) — especialmente los findings y su severidad
• Artefactos previos listos para integración

Artefactos necesarios

from dataclasses import dataclass

@dataclass
class ModuleArtifact:
    """Artefacto producido por un módulo previo, necesario para integración."""
    module: str
    artifact_name: str
    artifact_type: str
    needed_for: str

artifacts = [
    ModuleArtifact("M1", "Threat Model Document", "documento",
                   "Referencia de riesgos, atacantes y activos críticos"),
    ModuleArtifact("M2", "OWASP Mapping Audit", "spreadsheet",
                   "Categorización de vulnerabilidades por OWASP Top 10"),
    ModuleArtifact("M3", "Injection Defense Pipeline", "código",
                   "Capa de detección de injection en el pipeline"),
    ModuleArtifact("M4", "Sanitization Pipeline", "código",
                   "Capa de limpieza de inputs/outputs en el pipeline"),
    ModuleArtifact("M5", "Secrets Management Setup", "configuración",
                   "Carga segura de API keys y credenciales del sistema"),
    ModuleArtifact("M6", "PII Protection Layer", "código",
                   "Capa de redacción de datos sensibles en el pipeline"),
    ModuleArtifact("M7", "Security Audit Report", "documento",
                   "Findings a cerrar y baseline de seguridad verificado"),
]

print("Artefactos necesarios para el Proyecto Integrador:")
print("=" * 60)
for a in artifacts:
    print(f"  [{a.module}] {a.artifact_name} ({a.artifact_type})")
    print(f"       → Uso: {a.needed_for}")

# Output esperado:
# Artefactos necesarios para el Proyecto Integrador:
# ============================================================
#   [M1] Threat Model Document (documento)
#        → Uso: Referencia de riesgos, atacantes y activos críticos
#   [M2] OWASP Mapping Audit (spreadsheet)
#        → Uso: Categorización de vulnerabilidades por OWASP Top 10
#   [M3] Injection Defense Pipeline (código)
#        → Uso: Capa de detección de injection en el pipeline
#   [M4] Sanitization Pipeline (código)
#        → Uso: Capa de limpieza de inputs/outputs en el pipeline
#   [M5] Secrets Management Setup (configuración)
#        → Uso: Carga segura de API keys y credenciales del sistema
#   [M6] PII Protection Layer (código)
#        → Uso: Capa de redacción de datos sensibles en el pipeline
#   [M7] Security Audit Report (documento)
#        → Uso: Findings a cerrar y baseline de seguridad verificado

Setup técnico

source security-guide-env/bin/activate

# Todas las dependencias acumuladas de la guía
pip install openai pydantic python-dotenv cryptography presidio-analyzer \
  presidio-anonymizer pytest pytest-asyncio httpx

# Verificación rápida
python -c "
from pydantic import BaseModel
from openai import OpenAI
print('Dependencias del proyecto integrador: OK')
"

---

Conexión con el proyecto

Este módulo es el proyecto final. No hay una separación entre "aprender" y "construir" — cada cápsula produce una pieza del sistema final. La cápsula 08 es el ensamblaje y entrega.

╔═══════════════════════════════════════════════════════════════════════╗
║            CONVERGENCIA DE ARTEFACTOS → SECURED AI SYSTEM            ║
╠═══════════════════════════════════════════════════════════════════════╣
║                                                                       ║
║  M1: Threat Model ──────────────┐                                     ║
║  M2: OWASP Mapping ────────────┤                                     ║
║  M3: Injection Pipeline ───────┤                                     ║
║  M4: Sanitization Pipeline ────┼───→ Secured AI System (M8)          ║
║  M5: Secrets Management ───────┤    ┌─────────────────────────┐      ║
║  M6: PII Protection ──────────┤    │ ✅ Pipeline integrado    │      ║
║  M7: Audit Report ─────────────┘    │ ✅ Gaps cerrados         │      ║
║                                      │ ✅ Deployment checklist  │      ║
║                                      │ ✅ Documentación         │      ║
║                                      │ ✅ Incident runbook      │      ║
║                                      │ ✅ OWASP final           │      ║
║                                      │ ✅ Portfolio-ready       │      ║
║                                      └─────────────────────────┘      ║
║                                                                       ║
╚═══════════════════════════════════════════════════════════════════════╝

Cada cápsula de este módulo toma uno o más artefactos previos y los transforma:

Cápsula M8	Artefactos de entrada	Producto
02	M3 + M4 + M6	Pipeline integrado con orden definido
03	M7 findings	Gaps cerrados con evidencia
04	M5 + pipeline	Checklist de deployment verificado
05	Todos	Documentación de arquitectura
06	M1 (threat model)	Runbook de incident response
07	M2 + sistema integrado	OWASP assessment final
08	Todo lo anterior	Secured AI System completo

---

Lo que NO cubre este módulo

• Cloud deployment (AWS/GCP/Azure) — la arquitectura es local/Docker. Despliegue cloud es un tema aparte con sus propias guías de seguridad.
• Kubernetes y orquestación — el sistema corre en un proceso. Escalado horizontal queda fuera del scope de esta guía.
• Compliance y certificaciones — no vas a obtener SOC2 o ISO 27001 con este módulo. Las bases están, pero la certificación formal es un proceso organizacional que involucra auditorías externas.
• Gestión de equipos de seguridad — este es un proyecto individual. Coordinar un equipo de seguridad requiere procesos de governance, rotación de roles, y communication frameworks que van más allá del código.
• Seguridad del entrenamiento de modelos — no cubrimos model poisoning, backdoor attacks, o data poisoning del training set. El foco es exclusivamente la capa de aplicación, donde tú como desarrollador tienes control directo.

---

La analogía: construir una casa

Has pasado 7 módulos construyendo los componentes de una casa: las paredes (injection defense), el techo (secrets management), la fontanería (PII protection), la instalación eléctrica (sanitization), los cimientos (threat model), el sistema de alarma (OWASP mapping), y la inspección de seguridad (audit report). Cada componente fue construido por separado, probado por separado, y funciona por separado.

Pero una casa no es una colección de componentes — es un sistema integrado. La fontanería necesita pasar por las paredes sin debilitarlas. La electricidad necesita evitar la fontanería. Los detectores de humo necesitan estar conectados al sistema eléctrico. Y todo necesita funcionar cuando alguien abre el grifo y enciende la luz al mismo tiempo.

Casa ANTES de integración:          Casa DESPUÉS de integración:
┌──────────────────────┐            ┌──────────────────────┐
│ Paredes ✅            │            │ ┌──── Techo ────────┐│
│ Techo ✅              │            │ │ Electricidad ←→   ││
│ Fontanería ✅         │            │ │ Fontanería  ←→    ││
│ Electricidad ✅       │            │ │ Paredes           ││
│ Cimientos ✅          │            │ │ Cimientos         ││
│ Alarma ✅             │            │ │ Alarma ←→ Todo    ││
│ Inspección ✅         │            │ │ Inspección        ││
│                      │            │ │ = Sistema vivo    ││
│ ❌ Nada conectado     │            │ └────────────────────┘│
└──────────────────────┘            └──────────────────────┘
  "Tengo piezas"                      "Tengo una casa"

El problema donde las casas fallan no es en los componentes individuales — es en las conexiones. Un electricista que no se coordina con el fontanero causa un cortocircuito. Un techo que no se sella contra las paredes genera filtraciones. Las fallas de integración son las más costosas porque afectan múltiples sistemas simultáneamente y son las más difíciles de diagnosticar.

Tu Secured AI System tiene el mismo reto. El injection detector que no se coordina con el PII redactor genera falsos positivos. El sanitizer que modifica el input antes de que el injection detector lo analice puede enmascarar ataques. El secrets manager que falla silenciosamente deja al pipeline sin acceso al LLM. Cada conexión entre capas es un punto potencial de fallo que necesita diseño explícito.

La buena noticia: a diferencia de una casa real, puedes iterar rápidamente. Si la conexión entre dos capas no funciona, ajustas el código, ejecutas los tests del M7, y verificas en minutos. El ciclo de feedback es rápido — aprovéchalo para experimentar con diferentes configuraciones.

Otra lección de la construcción: las casas más resistentes no son las que tienen los materiales más caros, sino las que tienen las uniones mejor diseñadas. Un muro de concreto armado con juntas mal selladas es menos seguro que un muro de ladrillo con juntas perfectas. En tu sistema, la calidad de la integración (contratos entre capas, error handling, logging) importa más que la sofisticación de cada capa individual.

---

Mindset de integración

Para integrar defensas de seguridad necesitas pensar en sistemas, no en componentes. Esto es un cambio de perspectiva respecto a los módulos anteriores, donde cada pieza vivía en aislamiento.

Piensa en flujos, no en funciones. Cuando construiste el injection detector en M3, pensaste en "¿esta función detecta injection?". Ahora necesitas pensar en "¿qué le pasa a un request que entra por el endpoint, pasa por el injection detector, luego por el sanitizer, luego por el PII scanner, llega al LLM, y vuelve?". El foco se mueve de la función individual al flujo completo del dato a través del sistema. Cada transformación intermedia afecta a todas las capas downstream.

Piensa en contratos entre capas. Cada capa tiene un contrato implícito: recibe un input de cierta forma y produce un output de cierta forma. El injection detector recibe texto plano y produce un veredicto + el texto (posiblemente limpio). El PII scanner recibe texto y produce texto con tokens redactados. Si una capa cambia su contrato (por ejemplo, el sanitizer empieza a retornar un objeto en vez de un string), todas las capas downstream se rompen. Definir contratos explícitos entre capas evita este tipo de fallas.

from pydantic import BaseModel
from typing import Optional
from enum import Enum

class LayerStatus(str, Enum):
    PASSED = "passed"
    FLAGGED = "flagged"
    ERROR = "error"
    SKIPPED = "skipped"

class LayerResult(BaseModel):
    """Contrato estándar entre capas del pipeline de seguridad.
    Cada capa recibe texto y devuelve un LayerResult uniforme."""
    layer_name: str
    status: LayerStatus
    output_text: str
    metadata: dict = {}
    execution_time_ms: float = 0.0
    should_continue: bool = True

    def summary(self) -> str:
        return (f"[{self.layer_name}] {self.status.value} "
                f"({self.execution_time_ms:.0f}ms)")

# Cada capa devuelve un LayerResult — el contrato es uniforme
example_result = LayerResult(
    layer_name="injection_detector",
    status=LayerStatus.PASSED,
    output_text="¿Cuál es el horario de atención?",
    metadata={"risk_score": 0.05, "patterns_checked": 12},
    execution_time_ms=45.2,
    should_continue=True
)

print(example_result.summary())
print(f"  Continuar pipeline: {example_result.should_continue}")
print(f"  Risk score: {example_result.metadata.get('risk_score')}")

# Output esperado:
# [injection_detector] passed (45ms)
#   Continuar pipeline: True
#   Risk score: 0.05

Piensa en degradación graceful. En un sistema de componentes, si uno falla, simplemente no funciona. En un sistema integrado, si uno falla, necesitas decidir qué pasa con el resto. ¿El pipeline se detiene? ¿Continúa sin esa capa? ¿Usa un fallback? La respuesta depende de la criticidad de la capa: si el secrets manager falla, no puedes continuar (no tienes API key). Si el PII scanner de output falla, podrías continuar con un warning y logging extra porque la redacción de input ya cubrió la primera línea de defensa. Estas decisiones deben estar codificadas en la configuración, no improvisadas en el momento del fallo.

Piensa en observabilidad. Cuando tienes 7+ capas, debuggear un problema requiere saber exactamente qué pasó en cada una. ¿El injection detector dejó pasar algo? ¿El sanitizer lo modificó inadvertidamente? ¿El PII scanner lo redactó incorrectamente? Sin logging estructurado en cada capa, diagnosticar problemas en producción se vuelve casi imposible. Cada capa debe emitir un LayerResult que cuente la historia completa de lo que hizo con el dato. El request_id que conecta todos los logs de un mismo request es tu herramienta principal de debugging.

---

Pre-evaluación

Antes de empezar el módulo, evalúa tu preparación. Estas preguntas cubren los conceptos de integración que vas a necesitar:

Pregunta 1

"Tener cada defensa individual testeada con tests unitarios garantiza que el sistema integrado es seguro."

Ver respuesta

Falso. Los tests unitarios verifican cada pieza en aislamiento. Los problemas de integración — conflictos de orden, interferencia entre transformaciones, error propagation — solo aparecen cuando las capas trabajan juntas. Necesitas tests de integración específicos que ejecuten el pipeline completo.

Pregunta 2

"El orden en que se ejecutan las capas de seguridad no afecta el resultado."

Ver respuesta

Falso. El orden es crítico. Si el PII redactor corre antes del injection detector, el detector puede interpretar tokens como [REDACTED_EMAIL] como injection markers. Si el sanitizer corre antes del detector, puede eliminar evidencia de un ataque. El orden correcto se deriva de las dependencias entre capas.

Pregunta 3

"Si una capa del pipeline falla, lo más seguro es siempre detener todo el pipeline (fail-closed)."

Ver respuesta

Depende. Fail-closed es más seguro pero sacrifica disponibilidad. Para capas que son la única línea de defensa (injection detector, PII input redactor), fail-closed es obligatorio. Para capas que son defensa en profundidad (PII output check, content filter), fail-open con logging puede ser aceptable porque otras capas ya cubren parcialmente esa función.

Pregunta 4

"Un pipeline de seguridad con 8 capas será inevitablemente lento (>5 segundos)."

Ver respuesta

Falso. La mayoría de las capas de seguridad (regex, keyword matching, sanitización) operan en <50ms. La capa más costosa es la llamada al LLM (~500-1000ms). Con un performance budget bien gestionado, el pipeline completo puede mantenerse por debajo de 2 segundos. Además, algunas capas independientes pueden ejecutarse en paralelo.

Pregunta 5

"La documentación de decisiones de seguridad puede hacerse al final del proyecto."

Ver respuesta

Falso. Documentar al final produce documentación incompleta porque olvidas el contexto y las alternativas que consideraste. Las mejores decisiones de arquitectura se documentan en el momento con ADRs (Architecture Decision Records) que capturan el contexto, las opciones evaluadas, y la justificación de la elección.

Pregunta 6

"Un pipeline con 7 capas de seguridad es siempre más seguro que uno con 3 capas."

Ver respuesta

No necesariamente. Más capas no significan más seguridad si no están integradas correctamente. Un pipeline con 3 capas bien conectadas, con contratos claros, error handling definido, y tests de integración es más seguro que uno con 7 capas que interfieren entre sí, tienen configuración inconsistente, y fallos silenciosos. La calidad de la integración importa más que la cantidad de capas.

Pregunta 7

"En un sistema integrado, cada capa debe funcionar de forma completamente independiente."

Ver respuesta

Parcialmente cierto. Cada capa debe ser testeable de forma independiente (tests unitarios), pero en el pipeline integrado las capas son interdependientes: comparten un contrato de datos (LayerResult), respetan un orden de ejecución, y sus decisiones afectan a las capas downstream. La independencia es para testing; la coordinación es para producción.

---

Glosario rápido

Término	Definición
Pipeline de seguridad	Secuencia ordenada de capas de defensa que procesan un request de principio a fin.
LayerResult	Contrato estándar entre capas: incluye status, texto procesado, metadata, y decisión de continuación.
Fail-closed	Estrategia donde el pipeline se detiene si una capa falla. Maximiza seguridad, reduce disponibilidad.
Fail-open	Estrategia donde el pipeline continúa si una capa no crítica falla. Mantiene disponibilidad con logging.
Circuit breaker	Patrón que desactiva temporalmente una capa inestable tras fallos repetidos, evitando cascadas.
Performance budget	Presupuesto de tiempo asignado a cada capa del pipeline. Total objetivo: < 2 segundos.
Defense in depth	Estrategia de múltiples capas donde cada una cubre gaps de las anteriores.
ADR	Architecture Decision Record — documento que captura el contexto, opciones y justificación de una decisión de diseño.
Degradación graceful	Capacidad del sistema de seguir funcionando con funcionalidad reducida cuando un componente falla.
Contrato entre capas	Acuerdo sobre el formato de input/output entre dos capas consecutivas del pipeline.
Hot-reload	Capacidad de cambiar la configuración del pipeline sin reiniciar el servicio.
Correlation ID	Identificador único (request_id) que conecta todos los logs de un mismo request a través de las capas.
Integration test	Test que verifica el comportamiento del pipeline completo, no de capas individuales.

---

¿Cómo se estructura este módulo?

A diferencia de los módulos anteriores donde cada cápsula enseñaba un concepto nuevo, este módulo sigue un flujo de construcción progresiva. Cada cápsula produce un artefacto que se integra en el sistema final:

Día 1: Contexto y arquitectura (Cápsulas 01-02)
├── Entender los desafíos de integración
├── Diseñar el flujo completo del request
├── Implementar SecuredAIPipeline
└── Resolver conflictos de orden entre capas

Día 2: Validación y preparación (Cápsulas 03-04)
├── Cerrar gaps del Security Audit Report (M7)
├── Verificar cada mitigación con evidencia
├── Crear deployment checklist
└── Automatizar verificaciones pre-producción

Día 3: Documentación y procedimientos (Cápsulas 05-06)
├── Escribir ADRs de las decisiones de arquitectura
├── Generar README de seguridad
├── Crear incident response runbook
└── Definir procedimientos de escalación

Día 4: Evaluación y entrega (Cápsulas 07-08)
├── Actualizar OWASP mapping con estado final
├── Comparar postura pre/post integración
├── Ensamblar el Secured AI System completo
└── Verificar que el sistema es portfolio-ready

No necesitas seguir exactamente este calendario. Lo importante es que cada cápsula construye sobre la anterior: no puedes cerrar audit gaps (día 2) sin el pipeline integrado (día 1), y no puedes documentar decisiones (día 3) sin haberlas tomado (días 1-2).

---

Errores comunes

"Ya tengo todas las piezas, la integración es trivial"

La integración es donde aparecen los problemas más sutiles. Cada pieza funciona en aislamiento, pero al conectarlas descubres conflictos de orden, interferencias entre transformaciones, y edge cases que ninguna pieza individual contemplaba. Reserva el mismo tiempo para integración que el que dedicaste a construir las piezas — no menos.

"Voy a integrar todo de golpe"

Integrar 7 capas simultáneamente hace imposible diagnosticar problemas. Si algo falla, ¿cuál de las 7 capas causó el fallo? Integra incrementalmente: empieza con 2 capas, verifica que funcionan, agrega una tercera, verifica de nuevo. Este enfoque te da un sistema funcional en cada paso y hace que los problemas sean fáciles de localizar.

"El orden de las capas no importa"

El orden importa enormemente. Un PII scanner que corre antes del injection detector puede redactar tokens que el detector necesitaba ver para identificar un ataque. Un sanitizer que corre después del detector puede limpiar evidencia de un ataque detectado. El orden correcto se deriva de las dependencias entre capas — la cápsula 02 te enseña exactamente cuál es y por qué.

"No necesito tests de integración, ya testeé cada capa"

Los tests unitarios de cada capa verifican que la capa funciona en aislamiento. Los tests de integración verifican que las capas funcionan juntas. Un test unitario del injection detector verifica que detecta "ignora instrucciones". Un test de integración verifica que un prompt malicioso es detectado, sanitizado, procesado por el LLM, y la respuesta es validada — todo en secuencia, sin datos filtrados ni falsos positivos.

"La documentación la hago al final"

Documentar al final significa documentar de memoria, lo cual produce documentación incompleta e inexacta. Documenta cada decisión cuando la tomas: por qué elegiste ese orden de capas, por qué una capa puede fallar gracefully y otra no, qué alternativas consideraste y descartaste. La documentación simultánea es más precisa y requiere menos esfuerzo total que reconstruir el razonamiento semanas después.

---

Resumen

• 🔗 La integración de defensas individuales en un sistema coherente es el desafío final y el más complejo de la guía
• ⚡ Los problemas de integración (conflictos de orden, interferencia entre capas, error propagation) no existen cuando las piezas están aisladas — solo aparecen al conectarlas
• 📐 Cada capa necesita un contrato explícito (input esperado, output producido, comportamiento ante errores) usando un modelo como LayerResult
• 🏗️ La integración debe ser incremental: 2 capas primero, luego 3, verificando en cada paso con tests de integración
• 🔄 La degradación graceful (qué pasa cuando una capa falla) debe estar diseñada y codificada, no improvisada en el momento del fallo
• 📊 El performance budget total del pipeline debe ser < 2 segundos incluyendo todas las capas de seguridad y la llamada al LLM
• 📝 Este módulo toma los 7 artefactos previos (M1-M7) y los transforma en un Secured AI System portfolio-worthy
• 🎯 Al terminar, tendrás un sistema completo, documentado, testeado, y listo para presentar en entrevistas o demos

Próxima cápsula: En la cápsula 02 vas a diseñar la Integration Architecture — el flujo completo de un request seguro, el orden de ejecución de las capas, y la clase SecuredAIPipeline que lo orquesta todo.

---

Recursos adicionales

1. OWASP Application Security Verification Standard — Estándar de verificación de seguridad para aplicaciones
2. Building Secure AI Systems (Microsoft) — Guía de Microsoft para construir sistemas AI seguros
3. NIST AI Risk Management Framework — Framework de gestión de riesgos AI de NIST
4. Architecture Decision Records (ADR) — Referencia para documentar decisiones de arquitectura
5. Incident Response Planning (SANS) — Handbook de SANS para respuesta a incidentes
6. Defense in Depth Strategy (CISA) — Estrategia de defensa en profundidad de CISA
7. LLM Security Best Practices (OWASP) — Mejores prácticas de seguridad para LLMs
8. Secure Software Development Framework (NIST) — Framework de desarrollo de software seguro

---

Creado: Marzo 2026 Versión: 1.0