Red Teaming de IA explicado: qué prueba un equipo rojo y qué deja atrás

La mayoría de los ejercicios de red teaming de IA se juzgan por el artefacto equivocado. Una semana de trabajo produce una presentación de diapositivas, la presentación dice que se puede convencer al asistente de escribir un correo de phishing, y nadie puede decir después si el comportamiento era reproducible, cuán grave era o qué control lo habría detenido. La disciplina tiene un resultado real, y no es una presentación: es un conjunto de hallazgos que sobreviven a la reejecución, cada uno vinculado a un límite que se cruzó y a la evidencia que lo cruzó. Esa es también la forma del registro que the AI incident archive mantiene — 400 entradas que cubren de diciembre de 2024 a octubre de 2026, extraídas de 743 fuentes distintas, y un veredicto sobre cada una acerca de si alguien resultó realmente perjudicado.

La confusión es comprensible, porque el "red teaming" se usa para dos tareas que comparten vocabulario y poco más. Esta es una guía de ambas, de las evidencias que cada una debería producir y de los cuatro puntos en los que el red teaming de IA se aparta realmente de la versión para redes que la mayoría de los equipos de seguridad ya sabe ejecutar.

La cuestión del marco: ¿de quién es la prueba?

Antes del alcance, surge la cuestión de quién dirige el ejercicio y contra qué. Microsoft publica una de las posturas públicas más completas al respecto, y merece la pena leerla como un mapa y no como una página de producto. Su centro de AI Red Team separa el concepto de red teaming de IA de la guía práctica, y luego ordena la práctica en un orden que es en sí mismo un argumento: descripción general, después una guía para crear un equipo de red teaming de LLM, luego el material de referencia —un criterio de errores para clasificar ataques contra sistemas de aprendizaje automático, una taxonomía de fallos de aprendizaje automático, un modelo de responsabilidad compartida y una guía de modelado de amenazas para desarrolladores.

Lee la secuencia y la metodología se desprende por sí sola. Una taxonomía decide qué cuenta como fallo. Un umbral de errores decide cuáles de esos fallos merecen corregirse. Un modelo de responsabilidad compartida decide quién responde por ello una vez encontrado. El modelado de amenazas decide dónde buscar a continuación. Sin esos cuatro, un equipo rojo está generando anécdotas con una columna de gravedad añadida a la fuerza, y la columna de gravedad es lo que el probador sintió esa tarde.

El framework de automatización abierto de Microsoft, PyRIT, se archiva en el mismo estante, y esa ubicación es lo útil. Un kit de orquestación no es una metodología; es aquello hacia lo que apuntas a un objetivo una vez que existen la taxonomía y el umbral de errores. Los equipos que empiezan por el framework suelen terminar con un gran corpus de prompts y sin forma alguna de clasificar los resultados.

Dos equipos rojos, dos preguntas diferentes.

La distinción más útil en este campo es la que casi nadie deja por escrito: un red team que prueba un modelo y un red team que prueba un sistema están respondiendo a preguntas distintas, con unidades bajo prueba distintas, resultados distintos y responsables distintos. Mezclarlos es lo que hace que un jailbreak se reporte como un hallazgo de seguridad, y que un auténtico fallo de escalada de privilegios se registre como una queja sobre la calidad del modelo.

Evaluación de seguridad a nivel de modelo es un problema de medición. Se pregunta si un modelo producirá una categoría de contenido, y la forma honesta de responder es una muestra lo suficientemente grande como para decir algo sobre una tasa. La unidad sometida a prueba es el modelo que hay detrás de una API mínima, el método es el prompting adversarial —jailbreaks, ataques de personificación, presión multiturno— y lo que sale es una transcripción y una valoración de daño. Cuando cambian los pesos o se modifica la capa de seguridad del proveedor, todo el resultado queda obsoleto. Por eso este tipo de prueba suele realizarla el creador del modelo o un evaluador independiente, y por eso sus hallazgos rara vez se traducen en una corrección concreta en tu aplicación.

La emulación de adversarios a nivel de sistema es un problema de ingeniería. Se trata de preguntar si un atacante puede lograr que lo desplegado actúe: leer un archivo que no debería, llamar a una herramienta que no debería, gastar dinero que no debería. La unidad sometida a prueba es el agente con sus herramientas, su recuperación y sus credenciales conectadas. Los métodos son los habituales, reorientados: inyección a través de contenido recuperado en lugar de a través del turno del usuario, abuso de herramientas, cadenas de privilegios ensambladas a partir de permisos individualmente razonables, rutas de datos que filtran información a través de un límite de inquilino. El resultado es un hallazgo con una reproducción, un límite cruzado y un propietario que puede cambiar la configuración mañana.

Los dos producen artefactos incompatibles, y esa incompatibilidad es diagnóstica más que molesta. Un resultado a nivel de modelo no puede ser «corregido» por tu equipo salvo cambiando de modelo. Un resultado a nivel de sistema no puede ser corregido por el proveedor de ninguna manera. Si un informe no dice cuál de los dos es, no puedes asignar ninguno de sus elementos.

En qué se convierte la superficie de ataque una vez que el modelo dispone de herramientas

La superficie que la mayoría de los equipos sigue probando es el prompt. También es la menos interesante, porque es aquella en la que el proveedor del modelo ha invertido más esfuerzo en reforzar y sobre la que un atacante tiene menos influencia. Las superficies que realmente dan resultado son las que añadió la aplicación: las herramientas que el agente puede invocar, el índice de recuperación que lee, la memoria que conserva entre turnos y el propio canal de salida.

Herramientas son donde un modelo de lenguaje se convierte en actor, y la pregunta interesante nunca es «¿puede llamar a la herramienta?» sino «¿cuál es el mínimo privilegio que podría haber tenido esta herramienta?». A una herramienta de consulta de tickets que acepta una consulta de texto libre, normalmente se la puede convencer de que acepte el identificador de otro cliente. Recuperación es un canal de contenido hacia el contexto del modelo, lo que significa que cualquiera que pueda escribir en el corpus —un disco compartido, una macro de soporte, una página web a la que llegue el recuperador— está escribiendo en el prompt. Memoria convierte un solo turno en persistencia: una instrucción plantada en el turno dos sigue ahí en el turno cuarenta. Salida es donde el texto del modelo acaba en algún lugar que lo interpreta, y el renderizado, el markdown, las vistas previas de enlaces y las canalizaciones adyacentes al shell interpretan texto.

Un encargo que solo prueba el prompt reportará un resultado limpio y acertará en lo que no importa.

Por qué una transcripción no es un hallazgo

Un hallazgo necesita tres propiedades que una captura de pantalla de una ventana de chat no tiene. La primera es la reproducibilidad: ejecútalo de nuevo desde un estado limpio y vuelve a ocurrir. Los modelos no son deterministas, así que la reproducibilidad es una tasa y no un valor booleano: «nueve de cada diez intentos» es un hallazgo, «ocurrió una vez» es un rumor. La segunda es una frontera cruzada: nombra lo que no debería haber ocurrido en los términos de la propia aplicación, no en los del modelo. No «el modelo fue grosero», sino «el agente leyó un documento que pertenece al inquilino B». La tercera es una gravedad que se remonta al impacto en lugar de a la intuición del tester, que es precisamente para lo que sirve un umbral de errores.

Todo lo demás —la transcripción, el prompt, el razonamiento del modelo— es evidencia que respalda esos tres. No es el hallazgo en sí, y por eso un corpus de dos mil prompts de jailbreak vale menos que cinco hallazgos de sistema reproducibles con controles nombrados adjuntos.

Cuatro puntos en los que el red teaming de IA diverge del red teaming de redes

Los equipos que llegan desde la seguridad de redes o de aplicaciones aportan buenos instintos y cuatro suposiciones erróneas.

• No hay perímetro que mantener. Una intervención sobre una red tiene una lista de objetivos; una intervención con un agente tiene una ventana de contexto que se ensambla en el momento de la solicitud a partir de fuentes que puede que no hayas inventariado. El alcance debe expresarse como fuentes de datos y permisos de herramientas, no como nombres de host.

• El objetivo no es determinista. La misma entrada puede funcionar el martes y fallar el miércoles. Esto rompe el estándar de evidencia de "una reproducción limpia" y te obliga a reportar tasas.

• El exploit es el lenguaje, y el lenguaje no tiene parche. Se puede corregir una comprobación de autorización ausente. No se puede parchear "al modelo se le puede persuadir". La mitigación de una debilidad a nivel del lenguaje es un control en otro lugar —un filtro, un límite de alcance, una frontera de permisos—, y por eso los hallazgos deben nombrar el control, no solo el comportamiento.

• El proveedor está al tanto. Tu objetivo cambia cuando alguien más publica una versión. Un resultado a nivel de modelo solo es válido para la compilación que probaste, y si no registraste la versión y la fecha, no tienes un resultado.

Cómo definir el alcance de un primer encargo

Los proyectos que salen mal casi siempre se definen como «probar la IA». Un alcance que sobrevive al contacto con un cronograma se parece más bien a esto: un agente, en un entorno de staging, con datos con forma de producción y permisos con forma de producción; una lista de los cinco límites que importan (aislamiento de inquilinos, acceso a credenciales, gasto, salida de datos, alcance de herramientas); reglas de actuación que especifiquen qué queda fuera de los límites; condiciones de parada que indiquen quién puede detener la ejecución; y un formato de evidencia definido, acordado antes de el primer intento, de modo que el informe se ensamble a partir de artefactos en lugar de reconstruirse de memoria.

La autorización merece su propia frase, porque es el elemento que los equipos omiten cuando el objetivo es su propio producto y las herramientas son de otro. Probar un modelo que no operas, en una infraestructura que no posees, con prompts diseñados para burlar una capa de seguridad, es una actividad distinta de probar tu propio despliegue — y el alcance escrito es lo que separa a ambas. La puerta de verificación sobre la que opera nuestro propio nivel de ciberseguridad existe por la misma razón: el trabajo de seguridad autorizado a nivel de modelo necesita una parte nombrada y responsable en ambos lados.

Lo que añade el registro del incidente

Un ejercicio de red team te dice qué hace tu objetivo. No puede decirte qué ocurre en el terreno, y es en el terreno donde realmente se construye la justificación de un control. Ese es el vacío que llena un registro de incidentes —y la disciplina que impone es la parte útil: un registro sin al menos una fuente no existe, y un registro sin un veredicto de daño no es un incidente.

Lee los dos artefactos juntos y el ciclo se cierra. El equipo rojo produce un hallazgo reproducible y nombra el control que lo habría bloqueado. El registro te indica si alguien en campo ya ha chocado con ese límite, cuál fue el daño y si el control se mantuvo en algún otro lugar. Un hallazgo sin precedente en campo es una hipótesis que vale la pena corregir; un incidente en campo sin un hallazgo reproducible es un error que aún no puedes cerrar. Los equipos que aciertan dejan de tratar «hicimos red teaming al modelo» como un entregable y empiezan a tratarlo como una entrada de un registro propio.

Lo que queda es la conclusión honesta. El red teaming de IA no produce una garantía de seguridad, y cualquier servicio que se venda como tal está vendiendo lo que no es. Produce un conjunto de límites que ahora sabes que se cruzan, con evidencia que puedes volver a ejecutar, ordenados según lo que ocurre cuando se cruzan. Eso basta para tomar decisiones, y es bastante más que una presentación.