En el módulo 11 montamos el red team ofensivo: aprendimos a atacar nuestro propio sistema de forma sistemática, a encadenar vectores y a convertir cada hallazgo en un caso reproducible. A esta altura del curso sabemos atacar y sabemos defender casos concretos: reconocemos una injection indirecta, endurecemos una tool, aislamos un sandbox. Pero un hallazgo de red team es una foto de un instante, y un sistema en producción es una película que dura años. Falta la última pieza, la que convierte todo lo anterior en algo que sobrevive al tiempo: operar la seguridad como un programa. Qué haces el día que un ataque igual pasa de verdad, cómo vigilas que la protección de ayer siga en pie hoy, y cómo escribes las reglas para que no dependan de que tú te acuerdes.

Este es el módulo final del curso, así que cierra dos cosas a la vez: te da el marco operativo y de gobernanza que faltaba, y recapitula el arco completo de los doce módulos. Como siempre en este curso, todo es defensivo: sirve para operar la seguridad de tus propios sistemas.

La tesis del módulo

La seguridad de IA no es un estado que se alcanza sino un programa que se mantiene. Sin respuesta a incidentes, sin monitoreo continuo y sin una política que sea artefacto vivo, la protección que auditaste hace tres meses ya no existe — cambió el prompt, cambió una tool, el proveedor actualizó el modelo — y nadie se enteró. Un pentest aprobado no es un certificado permanente: es la línea de partida de un programa que hay que correr todos los días.

Respuesta a incidentes con IA

Un incidente de seguridad (evento que compromete la confidencialidad, integridad o disponibilidad de un sistema, o que viola una política) en un sistema de IA tiene formas propias. No es solo “se cayó el servidor”. Es:

Una exfiltración: el agente sacó datos del perímetro — mandó un correo con PII, cargó una URL con datos en el query string, escribió en una base compartida.
Un jailbreak explotado: alguien logró que el agente dijera o hiciera lo que la política prohíbe, y lo usó (un descuento inventado que un cliente exigió, consejo regulado que generó un reclamo).
Una acción no autorizada de un agente: la tool destructiva se ejecutó cuando no correspondía — un reembolso emitido, un registro borrado, un commit hecho por una injection en un ticket.

El playbook clásico de respuesta a incidentes tiene cinco fases, y sirve igual acá — lo que cambia es cómo se ejecuta cada una en un sistema con LLM:

 DETECTAR ──► CONTENER ──► ERRADICAR ──► RECUPERAR ──► APRENDE
    ▲                                                      │
    │                                                      │
    └──────── nuevos evals + política actualizada ─────────┘

Detectar. No esperas que un cliente reclame. El monitoreo (la sección que viene) dispara: un pico de negativas, un tool call a un dominio no permitido, un egress inesperado. La detección tardía es la diferencia entre un susto y una filtración masiva.
Contener. Acá está la particularidad de IA: ¿cómo “apagas” un comportamiento? En software tradicional matas un proceso. Con un agente tienes palancas específicas:
- Kill switch de tools: una bandera que desactiva en caliente la tool que está causando el daño (la de correo, la de escritura) sin tumbar el agente entero. La tool consulta la bandera antes de ejecutar.
- Revocación en caliente de permisos: bajar el rol del agente o del tenant afectado para que las tools de escritura dejen de estar disponibles, aunque el modelo las pida.
- Rollback de prompt o de modelo: si el incidente empezó después de un cambio de system prompt o de una actualización del proveedor, volver a la versión anterior conocida como segura. Esto exige que el prompt esté versionado como código (ver el módulo de supply chain).
Erradicar. Encontrar la causa raíz: ¿qué cambio abrió la puerta? ¿un prompt editado un martes, una tool nueva sin allowlist, un documento envenenado en el corpus del RAG?
Recuperar. Restaurar el servicio con la puerta cerrada. Reactivar tools con el arreglo puesto, no antes.
Aprender. El post-mortem (análisis sin culpables de qué pasó y por qué). Y acá está el cierre del ciclo que hace único a un programa de IA: el post-mortem alimenta los evals. Cada incidente real se convierte en un caso adversarial nuevo en la suite, para que ese ataque exacto no vuelva a pasar sin que la CI lo atrape. Un incidente sin caso de eval nuevo es un incidente que no aprendiste.

El kill switch no es un concepto abstracto: son pocas líneas que cada tool con efecto externo consulta antes de ejecutar. La bandera vive fuera del código del agente (una variable de entorno, una fila en Redis, un feature flag) para poder cambiarla en caliente sin desplegar:

"""Kill switch de tools: contención en caliente sin tumbar el agente.

La bandera vive en un almacén externo (aquí, un dict que en producción
sería Redis o un feature-flag) para poder desactivar una tool durante un
incidente SIN redeploy. Cada tool con efecto externo consulta el guard.
"""
import os
from functools import wraps

# En producción: lectura desde Redis / feature-flag, no un dict en memoria.
TOOLS_DESACTIVADAS: set[str] = set()  # se llena durante el incidente


class ToolDesactivada(Exception):
    """La tool está apagada por contención: no se ejecuta."""


def guard(nombre: str):
    """Decora una tool: aborta si está en la lista de contención."""
    def deco(fn):
        @wraps(fn)
        def wrapper(*args, **kwargs):
            if nombre in TOOLS_DESACTIVADAS or _flag_global_pausa():
                raise ToolDesactivada(f"tool '{nombre}' apagada (incidente)")
            return fn(*args, **kwargs)
        return wrapper
    return deco


def _flag_global_pausa() -> bool:
    # Interruptor maestro: apaga TODAS las tools de escritura de una vez.
    return os.getenv("AGENTE_PAUSA_ESCRITURA") == "1"


@guard("enviar_correo")
def enviar_correo(destinatario: str, cuerpo: str) -> dict:
    ...  # implementación real
    return {"ok": True}


# Durante el incidente, de guardia, sin desplegar nada:
TOOLS_DESACTIVADAS.add("enviar_correo")   # apaga solo esa tool
# o, para cortar todo egress de escritura de golpe:
# export AGENTE_PAUSA_ESCRITURA=1

Ojo: el kill switch de tools tiene que existir antes del incidente. El día que estás exfiltrando datos no es el día de escribir la bandera de desactivación. Diséñala fría, pruébala en un simulacro, y que cualquiera de guardia sepa dónde está el interruptor. Un plan de contención que hay que inventar en caliente es un plan que no tienes.

Monitoreo de seguridad en producción

La respuesta a incidentes empieza por detectar, y detectar empieza por vigilar las señales correctas. Estas son las que importan en un sistema con agentes:

Señal	Qué delata	De qué familia OWASP viene
Pico de negativas (“no puedo ayudarte”)	Ataque en curso o guardrail roto	Injection / jailbreak
Patrones de injection en el input	Alguien probando variantes	LLM01
Uso anómalo de tools (frecuencia, orden)	Agente manipulado hacia una acción	LLM06 (agencia excesiva)
Egress inesperado (destinos nuevos)	Exfiltración por canal de salida	LLM02
Costo / consumo fuera de rango	Abuso de recursos, bucle malicioso	LLM10 (consumo ilimitado)

Ese último merece su propio renglón: OWASP LLM10 — consumo ilimitado es la familia que casi nadie monitorea hasta que llega la factura. Un atacante que no puede exfiltrar nada todavía te puede hacer daño real forzando al agente a bucles caros o a generaciones gigantes. El gasto anómalo es una señal de seguridad, no solo de finanzas.

Sobre estas señales corren dos mecanismos:

Evals de seguridad online. No es la suite de CI (esa corre antes del deploy). Son sondas que corren en producción, contra tráfico real o sintético, muestreando: “¿el agente sigue resistiendo esta injection indirecta que ayer resistía?”. Detectan la degradación que introduce un cambio de modelo del proveedor que tú no pediste.
El audit log encadenado. Cada acción del agente — cada tool call con sus argumentos, cada decisión — se registra en un log donde cada entrada incluye el hash de la anterior (encadenado, tipo blockchain simple), de modo que nadie pueda borrar una línea sin romper la cadena. Sin este log, un post-mortem es adivinación: no puedes reconstruir qué hizo el agente ni cuándo. Esto conecta directamente con la gobernanza del harness: el registro inmutable de acciones es el mismo principio, aplicado a la seguridad.

        AGENTE                    AUDIT LOG ENCADENADO
          │
          │ tool_call            ┌─────────────────────┐
          ├────────────────────► │ n-1: hash(n-2)+datos│
          │                      └──────────┬──────────┘
          │ decisión                        │ hash
          ├────────────────────► ┌──────────▼──────────┐
          │                      │ n:   hash(n-1)+datos│
          │ respuesta            └──────────┬──────────┘
          └────────────────────► ┌──────────▼──────────┐
                                 │ n+1: hash(n)+datos  │
                                 └─────────────────────┘
                                  borrar una línea
                                  rompe la cadena

La política de seguridad como artefacto

Un programa que vive en la cabeza de una persona no es un programa: es un punto único de falla con opinión. La política de seguridad tiene que ser un artefacto — un documento versionado, revisable, con dueños — no una cultura oral. Y en un sistema de IA la política concreta tiene componentes específicos:

Clasificación de acciones por riesgo. Cada tool y cada acción del agente cae en un nivel: leer datos públicos (bajo), leer datos de un usuario (medio), escribir o comunicar hacia afuera (alto), acción destructiva o irreversible (crítico). Sin esta clasificación no puedes decidir qué merece confirmación humana.
Quién aprueba qué. Las acciones críticas no las decide el modelo solo. La política dice qué nivel exige human-in-the-loop, qué exige un segundo agente validador, y qué puede ir directo.
RBAC por herramienta. RBAC (Role-Based Access Control, control de acceso basado en roles): la tool de reembolso no está disponible para el agente de consulta general, solo para el rol que la necesita. El permiso vive en la tool, no en el prompt — el principio de mínimo privilegio que cruza todo el curso.
Riesgo aceptado por escrito. Retomamos la idea del módulo de evals sobre red teaming: cuando un caso adversarial siempre falla y decides convivir con él, no se relaja el umbral en silencio. Se anota en una lista explícita de riesgo aceptado, con tres campos obligatorios: dueño (quién carga con la responsabilidad), fecha (cuándo caduca la aceptación y hay que revisarla) y justificación. Un riesgo aceptado por escrito es gobernanza; un umbral bajado en silencio es un incidente futuro con más pasos.

# politica-seguridad.yaml — artefacto versionado en el repo, no un wiki
version: 2026-08-24
clasificacion_acciones:
  leer_publico:      { nivel: bajo,     aprobacion: ninguna }
  leer_datos_user:   { nivel: medio,    aprobacion: ninguna }
  enviar_correo:     { nivel: alto,     aprobacion: hitl }      # human-in-the-loop
  emitir_reembolso:  { nivel: critico,  aprobacion: hitl_2fa }
  borrar_registro:   { nivel: critico,  aprobacion: hitl_2fa }

rbac:
  agente_consulta:   [leer_publico, leer_datos_user]
  agente_operaciones: [leer_publico, leer_datos_user, enviar_correo, emitir_reembolso]

riesgo_aceptado:
  - id: RA-014
    caso: "jailbreak-multiturno variante 7 falla 1/200"
    dueno: "felipe.b"
    caduca: 2026-11-24         # revisión obligatoria en esta fecha
    justificacion: "impacto limitado a texto, sin tool; costo de fix > riesgo"

Que la política sea un archivo YAML versionado no es cosmético: significa que un cambio de política es un commit revisable, que se puede auditar quién bajó una barrera y cuándo, y que la configuración del agente se lee de este artefacto en vez de estar dispersa en el código.

Marcos y regulación

Hasta acá el programa es técnico. Pero desde 2025 hay un marco regulatorio real que le pone obligaciones legales, y conviene ubicar los tres nombres que van a aparecer en cualquier conversación de gobernanza. A alto nivel:

Marco	Qué es	A quién aplica	Naturaleza
NIST AI RMF	Marco de gestión de riesgo de IA (EE. UU.)	Cualquiera, voluntario	Guía, no obligatorio
EU AI Act	Ley de IA de la UE	Quien opere IA en la UE	Ley con multas
ISO/IEC 42001	Sistema de gestión de IA	Quien busque certificarse	Estándar certificable
OWASP LLM Top 10	Catálogo técnico de riesgos	Referencia de ingeniería	Técnico, no legal

NIST AI Risk Management Framework (marco voluntario publicado en 2023, EE. UU.). Organiza el trabajo en cuatro funciones: Govern (la gobernanza que sostiene todo — políticas, responsabilidades, cultura), y un bucle de Map (identificar el contexto y los riesgos), Measure (medirlos, aquí es donde entran tus evals de seguridad) y Manage (tratarlos y priorizar). En julio de 2024 se le sumó el Generative AI Profile (NIST AI 600-1), que baja el marco a los riesgos específicos de los LLM. Es la mejor estructura mental para ordenar tu programa aunque no operes en EE. UU.
EU AI Act (Reglamento (UE) 2024/1689). Ley real, con multas reales. Su enfoque es por niveles de riesgo: prohíbe ciertas prácticas (vigentes desde febrero de 2025), impone obligaciones fuertes a los sistemas de alto riesgo (documentación, supervisión humana, monitoreo post-mercado; el Digital Omnibus de julio de 2026 —Reglamento (UE) 2026/1744— corrió su exigibilidad al 2 de diciembre de 2027 para los sistemas del Anexo III y al 2 de agosto de 2028 para la IA embebida en productos regulados), y tiene un capítulo propio para GPAI (General-Purpose AI, modelos de propósito general como los LLM grandes): documentación técnica, transparencia y cumplimiento de copyright, en vigor desde agosto de 2025, con multas de hasta 15 M € o 3% de la facturación global. Si tu producto toca usuarios en la UE, esto no es opcional.
ISO/IEC 42001:2023 (primer estándar internacional certificable de sistemas de gestión de IA, AIMS). Usa la misma arquitectura de cláusulas de las normas ISO (contexto, liderazgo, planificación, operación, evaluación, mejora), con contenido específico de IA: gobernanza de datos y modelos, evaluación de impacto, gestión del ciclo de vida y supervisión de terceros. Es el marco que te audita un tercero y te da un certificado que puedes mostrarle a un cliente.
OWASP LLM Top 10. No es regulación: es la referencia técnica que ya usamos todo el curso. Es el lenguaje común de ingeniería para nombrar los riesgos (LLM01 injection, LLM02 exfiltración, LLM10 consumo). Los tres marcos de arriba te dicen qué gobernar; OWASP te dice cómo se ve el riesgo en el código.

Cuidado: un certificado ISO 42001 o una casilla marcada de “cumplimiento EU AI Act” no es seguridad. Es evidencia de que tienes un proceso, no de que el proceso funciona. Se puede estar certificado y ser vulnerable a una injection indirecta trivial. El marco regulatorio te obliga a tener el programa; que el programa sirva depende de los evals, el red team y el monitoreo de los módulos anteriores. La conformidad es el piso, no el techo.

Modelo de madurez

Con todo lo anterior sobre la mesa, la pregunta honesta es: ¿en qué nivel está tu programa hoy? Esta tabla te deja autoevaluarte. No es para presumir el nivel 3: es para saber cuál es tu siguiente paso concreto.

Nivel	Nombre	Cómo se ve	Riesgo
0	Sin controles	El prompt es la única defensa. “Nunca reveles X” escrito en el system prompt y nada más. Sin evals, sin monitoreo, sin log.	Crítico
1	Reactivo	Hay allowlists en algunas tools y confirmación humana en lo destructivo. Se arregla cuando algo explota. Evals de seguridad ad-hoc, corridos a mano.	Alto
2	Sistemático	Suite de evals de seguridad en CI que corre en cada PR que toca prompt o tools. Monitoreo de las señales clave. Política escrita. Se atrapan las regresiones antes del deploy.	Medio
3	Gobernado	Todo lo del nivel 2 más: red team periódico, evals de seguridad online en producción, respuesta a incidentes con playbook y kill switch probados, post-mortems que alimentan los evals, política como artefacto versionado con riesgo aceptado por escrito.	Bajo residual

La mayoría de los equipos que “usan IA en producción” están en nivel 0 o 1 y creen estar en 2. El salto que más importa es el de 1 a 2: pasar de arreglar cuando duele a atrapar antes de desplegar. Es el salto que convierte la seguridad de un evento en un programa. El nivel 3 no es para todos — un juguete interno no necesita red team periódico — pero un agente que mueve dinero o datos de clientes sí.

El ciclo de vida completo

Todo lo del módulo (y en el fondo, todo el curso) se ordena en un ciclo que no termina nunca:

  ┌───────────────┐           ┌────────────────┐
  │ diseño seguro │           │  nuevos evals  │
  └───────┬───────┘           └────────────────┘
          │                           ▲
          ▼                           │
  ┌───────────────┐           ┌───────┴────────┐
  │    deploy     │           │  post-mortem   │
  └───────┬───────┘           └───────▲────────┘
          │                           │
          ▼                           │
  ┌───────────────┐  señal    ┌───────┴────────┐
  │  monitoreo    │ ────────► │   incidente    │
  └───────────────┘           └────────────────┘

  el ciclo cierra: nuevos evals ► diseño seguro

El diseño seguro nace de las lecciones de los incidentes pasados. Cada vuelta del ciclo endurece la siguiente. Un programa maduro no es el que no tiene incidentes: es el que convierte cada incidente en un eval que impide su repetición.

Errores comunes

Tratar la seguridad como un proyecto con fecha de término. “Ya hicimos el pentest” es el mensaje de un programa que va a estar comprometido en tres meses. La seguridad no se termina; se opera.
No tener kill switch hasta que hace falta. El plan de contención se diseña frío. Inventarlo mientras exfiltras datos es no tener plan.
Post-mortem sin eval nuevo. Si el incidente no dejó un caso adversarial en la suite, el mismo ataque va a volver y la CI no lo va a ver venir. El aprendizaje que no se codifica no ocurrió.
Monitorear todo menos el costo. LLM10 (consumo ilimitado) es la señal que casi nadie mira. El gasto anómalo es seguridad, no solo finanzas.
Relajar el umbral en silencio. Bajar la injection indirecta de 1.00 a 0.98 “porque siempre falla un caso” sin anotarlo es convertir la seguridad en decoración. La alternativa es el riesgo aceptado con dueño y fecha.
Confundir conformidad con seguridad. Un certificado ISO o una casilla del EU AI Act prueban que tienes un proceso, no que funciona. La conformidad es el piso.
Política oral. Si las reglas viven en la cabeza de alguien, se van con esa persona. La política es un artefacto versionado o no es política.

La frase para llevarse

“La seguridad de IA no es un estado que alcanzas: es un programa que mantienes. El pentest aprobado no es el certificado — es la línea de partida. Un programa maduro no es el que no tiene incidentes, es el que convierte cada incidente en un eval que impide su repetición.”

Qué viene

Nada viene después: este es el final del curso. Recorrimos el arco completo de la seguridad de IA, y vale la pena verlo entero de una vez, porque cada módulo era una capa del mismo problema:

Empezamos por la raíz — el LLM no separa datos de instrucciones (módulo 1), la falla fundacional de la que sale todo lo demás. Le pusimos nombre a los riesgos con el catálogo OWASP (módulo 2). Bajamos a los ataques concretos: prompt injection (módulo 3) y jailbreaks y evasión (módulo 4). Subimos la apuesta a agentes con tools (módulo 5), donde un ataque deja de ser texto feo y pasa a ser una acción real. Construimos las defensas: guardrails de entrada y salida, seguridad de datos y PII, y el RAG como superficie de ataque envenenable. Cerramos la cadena de suministro con supply chain (modelos y dependencias), aislamos la ejecución con sandboxing, y aprendimos a atacarnos a nosotros mismos con el red team ofensivo (módulo 11). Y hoy, en el módulo 12, pusimos todo eso a correr en el tiempo: gobernanza.

Si te llevas una sola idea de estos doce módulos, que sea esta, porque se repitió en cada capítulo: la defensa vive en la arquitectura, no en el prompt. Un prompt que dice “nunca hagas X” es una sugerencia estadística. La garantía está en la tool que no existe, el permiso que no se otorgó, el filtro que corre fuera del modelo, el sandbox que aísla, el eval que corre en cada PR y el kill switch probado en frío. El modelo es poderoso y manipulable a la vez; tu trabajo es construir la caja que lo contiene.

Felicitaciones por completar el Curso de Seguridad de IA. Sabes modelar amenazas, atacar tu propio sistema y defenderlo por capas, y ahora también operarlo como programa. Eso ya no es saber “usar IA”: es saber ponerla en producción sin que te haga daño. Ahora ve a auditar tu propio sistema — probablemente está en nivel 1 y cree que está en 2.

Seguridad de IA — Módulo 12: del incidente a la gobernanza