Blue Teaming de IA explicado: las tres capas en las que un control realmente puede residir

Pregunte a un equipo de seguridad dónde viven sus barreras de seguridad de IA y la respuesta normalmente menciona un documento de políticas, un prompt del sistema o una función de un proveedor. Ninguno de esos es un control. Un control es algo que decide, en el momento de una acción, si la acción ocurre — y para un agente de IA solo hay tres lugares que pueden decidir: el modelo, la puerta de enlace frente a él y el entorno que lo rodea. Todo lo que un equipo azul puede prometer honestamente proviene del segundo y del tercero de esos. Esta es la cuestión de la capa, y es previa a toda otra decisión del equipo azul, incluido qué registrar y a quién llamar. También es por lo que importa la evidencia de campo: el archivo de incidentes de IA contiene 400 incidentes de agentes desde 2024-12 hasta 2026-10-17, y la mayoría no son historias sobre un modelo que se comporta mal. Son historias sobre un despliegue sin una capa que pudiera decir no.

El blue teaming en el sentido de la IA es el trabajo de implementar esas capas, ajustar lo que detectan y tener una respuesta ensayada para el día en que una de ellas se active. No es glamuroso, no produce una puntuación y es la única mitad del par red-team/blue-team que cambia el número de riesgo.

Lo que hereda un equipo azul y lo que no

El blue teaming tradicional se basa en una serie de supuestos que las implementaciones de IA rompen silenciosamente. Se suponía que los registros eran completos, porque la red veía cada paquete. Se suponía que los activos eran enumerables, porque alguien tenía que aprovisionarlos. Se suponía que el comportamiento era determinista, porque un programa hace lo mismo con la misma entrada. Ninguno de los tres sobrevive al contacto con un agente.

Lo que un equipo azul hereda, en cambio, es un sistema en el que las decisiones más trascendentales ocurren dentro de una solicitud que la capa de red trata como tráfico HTTPS ordinario hacia un solo nombre de host. El prompt, el contexto recuperado, las llamadas a herramientas, la respuesta generada: todo ello está dentro del cuerpo de una solicitud, y si nadie captura y analiza ese cuerpo, el despliegue queda funcionalmente sin monitoreo, por bueno que sea el perímetro. Por lo tanto, la primera tarea del equipo azul no es la detección; es establecer un sensor. Sin visibilidad a nivel de solicitud y a nivel de herramienta, no hay nada sobre lo que detectar, y todo control posterior es decorativo.

¿Quién puede realmente hacer cumplir el control?

Una vez que existe un sensor, la pregunta pasa a ser dónde se permite ubicar cada control. La forma útil de representar esto es por propiedad en lugar de por tecnología, porque la propiedad es lo que determina si un control sobrevive a la próxima versión.

La capa del modelo pertenece a quien lo entrenó. No la configuras, no puedes ver su interior y su comportamiento cambia cuando el proveedor lanza una nueva versión —que puede ser cualquier martes. Lo que sí puedes hacer es fijar una versión y tratar un cambio de versión como un cambio en tu postura de riesgo que exige una nueva prueba. Lo que no puedes hacer es atribuirte un control aquí. «El modelo rechaza las solicitudes dañinas» es una propiedad en la que confías, no un mecanismo que operas.

La capa de puerta de enlace es donde cada prompt y cada completion pasan por un componente propio. Aquí es donde residen los límites de presupuesto y de tasa, donde se aplican las listas de permitidos y los permisos de herramientas, donde el registro de solicitudes y respuestas es completo por construcción y donde una solicitud se puede reescribir, bloquear o redirigir antes de que se facture ningún token. Los controles de la puerta de enlace son también los únicos que siguen vinculados cuando cambias de modelo, lo que importa más de lo que parece: los equipos que ponen sus controles en los prompts los pierden por completo el día en que migran.

La capa de entorno es la que es enteramente tuya: las credenciales y sus ámbitos, la salida de red, el acceso a archivos, los límites del sandbox en tiempo de reloj y gasto. También es donde una ejecución comprometida hace su daño. Un agente al que se ha convencido de actuar maliciosamente es peligroso en proporción exacta a aquello que el entorno permitió alcanzar a esa acción, y el entorno es el único lugar donde el "privilegio mínimo" es un cambio de configuración en lugar de un problema de investigación.

La prueba práctica para cualquier control de IA propuesto se reduce a una pregunta: ¿cuál de estas tres capas lo aplica? Si la respuesta es la capa del modelo, el control es una esperanza. Si la respuesta es «el prompt del sistema», es una sugerencia dentro de la capa del modelo, lo cual es peor que una esperanza porque viene acompañada de documentación que afirma lo contrario.

Detectar: lo que un agente realmente emite

La detección para agentes se basa en un conjunto de señales diferente del que se usa para la detección para personas. No hay ninguna anomalía de inicio de sesión que correlacionar. Lo que sí hay es un flujo de solicitudes con una estructura inusualmente rica, y cuatro familias de señales sobre las que merece la pena alertar.

• Volumen y forma de las llamadas a herramientas. Un agente que de repente llama a una herramienta de lectura de archivos cuarenta veces en una sola tarea, o cuya secuencia de herramientas pasa de tres pasos a treinta, merece una revisión — no porque sea malicioso, sino porque la distribución se desplazó.

• Procedencia del contenido en el límite. Qué texto del prompt provino del usuario, cuál de la recuperación, cuál del resultado de una herramienta y cuál de la memoria. La mayoría de la detección de inyección de prompt se reduce a «texto instruccional apareció en un canal que solo debería transportar datos», y no puedes calcularlo a menos que la puerta de enlace etiquete la procedencia en la entrada.

• Límites de salida y de alcance. Solicitudes a destinos fuera de la lista de permitidos, lecturas de rutas fuera del alcance, intentos de usar credenciales fuera del servicio previsto. Son señales de alta precisión y resultan económicas, porque el entorno ya sabe qué estaba permitido.

• Gasto y latencia como indicador indirecto. Un bucle descontrolado y una brecha de seguridad se parecen ambos a una curva de costes que cambia de pendiente. Las alertas de presupuesto son la detección menos glamurosa del stack y de las que más rápido se amortizan.

Lo que está deliberadamente ausente de esa lista es un clasificador al que se le pide juzgar si una finalización era dañina. Es la idea de detección a la que los equipos recurren primero y la que peor envejece: se desvía con el modelo, tiene una tasa de falsos positivos que entrena a tus analistas a ignorarla, y no te da nada que poner en un runbook.

Contener: los tres controles que detienen una mala racha

La contención de un agente es más sencilla de lo que parece, porque tres controles cubren casi todo. El presupuesto limita lo que una ejecución puede gastar, lo que acota tanto el daño financiero como el radio de impacto de un bucle. El alcance limita aquello que una ejecución puede tocar: las herramientas habilitadas para esa tarea, las rutas y los inquilinos. El sandbox limita cuánto tiempo puede ejecutarse y a qué puede acceder mientras se ejecuta. Los tres son ajustes de pasarela o del entorno, lo que equivale a decir que se pueden hacer cumplir.

El principio de diseño que importa es el alcance por tarea en lugar del alcance por agente. Un agente con un conjunto de permisos permanentes es un agente cuyos permisos se acumularán hasta que alguien los audite; un agente que recibe una credencial con alcance de tarea durante la duración de una tarea tiene un límite que expira por sí solo. El segundo requiere más trabajo de construcción y es mucho más barato de defender.

También es donde una puerta de enlace hace honor a su nombre. Los controles que se sitúan delante de cada llamada al modelo —las llamadas a herramientas y a MCP evaluadas antes de ejecutarse, la política de contenido y el enmascaramiento de datos personales aplicados antes de que se facture la solicitud— son los mismos controles tanto si el modelo que tienen detrás es el que usaste el trimestre pasado como si es el que se lanzó la semana pasada. Esa continuidad es el producto en sí: no un filtro mejor, sino un lugar donde el filtro viva que no se mueva cuando el modelo lo haga.

Recuperar: reproducir, aplicar parche, volver a probar

La recuperación de incidentes de IA tiene una ventaja sobre la recuperación de incidentes de red: por lo general, toda la ejecución queda registrada. Prompt, contexto, llamadas a herramientas, completaciones, tiempos — si la puerta de enlace los registró, el incidente se puede reproducir, lo que constituye un punto de partida más sólido del que suele tener la mayoría de los análisis forenses.

El replay cumple tres propósitos en secuencia. Establece lo que realmente ocurrió, en lugar de lo que la transcripción sugiere que ocurrió después de que varias personas la resumieran. Identifica el control que debería haberse disparado, que es la diferencia entre corregir un síntoma y corregir un límite. Y produce el caso de regresión: una entrada registrada que ahora debe bloquearse, ejecutada contra la nueva configuración para demostrar que efectivamente se bloquea.

El paso de aplicación de parches es donde los equipos azules suelen apuntar mal con más frecuencia. Si el hallazgo era un comportamiento del modelo, todas las mitigaciones disponibles están fuera del modelo: una reducción del alcance, un filtro en la pasarela, un permiso eliminado del entorno. Si el hallazgo era un comportamiento del sistema, la corrección está en la configuración y la prueba de regresión es barata. En cualquier caso, volver a probar no es opcional, porque tanto la corrección como la versión del modelo cambian, y un control que se verificó con la compilación del mes pasado es una afirmación sobre el mes pasado.

Ensayando el día en que se dispara

Un runbook que nunca se ha leído bajo presión es un documento, no una capacidad. El simulacro que vale la pena es acotado y específico: tomar un incidente plausible de un agente, recorrerlo de principio a fin y cronometrar cada paso. ¿Quién se da cuenta? ¿Cuánto tarda hasta que una persona está mirando la línea correcta del registro? ¿Quién puede detener la ejecución: una persona con nombre y apellido, o un comité? ¿Quién puede revocar la credencial y cuánto tarda la revocación en propagarse? ¿Quién decide si se avisa a alguien fuera de la empresa?

Dos de esas preguntas suelen pillar a los equipos. «¿Quién puede detener la ejecución?» falla cuando detenerla requiere a alguien que está dormido, así que la respuesta debe ser un mecanismo y no una persona: un límite de presupuesto o un interruptor de emergencia que un ingeniero de guardia pueda accionar por sí solo. «¿Cuánto tarda la revocación?» falla porque las credenciales suelen estar en caché en componentes que no aparecían en el diagrama.

Leer el archivo es la forma más económica de ensayo de la que dispones, porque te permite heredar la estructura de incidentes de otras personas en lugar de inventar la tuya. Toma un puñado de entradas que se parezcan a tu despliegue y, para cada una, plantéate las tres preguntas anteriores. Las entradas en las que no puedas responderlas son los huecos de tu runbook, y los has encontrado antes del incidente en lugar de después.

La asimetría que vale la pena señalar sin rodeos

Las actividades de red teaming y blue teaming no son simétricas y no deberían presupuestarse como si lo fueran. Una ejecución de red team está acotada por un calendario y produce un conjunto de hallazgos que se degradan a medida que el objetivo cambia. Los controles de un blue team persisten, se acumulan y son lo único que realmente se interpone entre una entrada maliciosa y un resultado desastroso. Un engagement puede encontrar un límite; solo el otro puede mantenerlo.

Lo que hace que el estándar honesto para un equipo azul sea poco glamuroso y verificable. Por cada control que afirmes, deberías poder nombrar la capa que lo aplica, la línea de registro que demuestra que se activó, la alerta que te avisa cuando no lo hizo, y la persona que puede desactivar la ejecución. Cuatro frases. Si falta una de ellas, el control es un documento de políticas, y los documentos de políticas no leen cuerpos de solicitud.