El primer ejercicio de red teaming sobre un sistema de IA suele fracasar por una razón que no tiene nada que ver con la técnica: nadie definió qué se iba a hacer con los hallazgos. El equipo dedica dos semanas a romper el asistente, produce un documento con veinte problemas ordenados por gravedad, lo presenta en un comité que asiente, y seis meses después el sistema sigue exactamente igual. El ejercicio fue exitoso y no cambió nada.
Montar el primero bien no es difícil, pero exige decidir cinco cosas antes de empezar: qué entra en el alcance, quién participa, qué está permitido, cuánto dura y —la que más pesa— en qué formato se entregan los resultados. Lo que sigue es el orden con el que estructuramos estos ejercicios cuando una organización parte de cero.
Alcance: elige un sistema, no una tecnología
El error de partida es escribir "evaluar la seguridad de nuestra IA". El alcance tiene que ser un sistema concreto en un entorno concreto: el asistente de atención al cliente, en staging, con las mismas herramientas conectadas que en producción y con datos representativos. Dentro de ese sistema, define explícitamente qué componentes son objetivo y cuáles no.
Los que más importan no son el modelo en sí, sino el perímetro alrededor: las herramientas que el agente puede invocar, las fuentes de las que recupera contexto, los permisos con los que actúa y los puntos donde su salida se convierte en una acción con efecto. Si tu ejercicio solo intenta hacer que el modelo diga algo inapropiado, estás evaluando al proveedor, no a tu organización.
Declara también los objetivos del atacante en términos de negocio, no de prompt: exfiltrar datos de otro cliente, conseguir que el sistema ejecute una acción irreversible sin aprobación, obtener acceso a un sistema interno a través de una herramienta, provocar un gasto desproporcionado. Un hallazgo redactado como objetivo de negocio se prioriza solo.
Equipo y reglas de enfrentamiento
Quiénes deberían estar
Un ejercicio útil necesita al menos tres perfiles y no más de cinco o seis personas. Alguien de seguridad ofensiva, que aporta el instinto de buscar el camino lateral. Alguien que conozca el dominio del negocio, porque es quien distingue una respuesta rara de una respuesta peligrosa: en un sistema de salud o de crédito, el daño real lo reconoce quien trabaja ahí. Y alguien del equipo que construyó el sistema, presente pero en rol de observador, no de defensor, porque su función es entender el hallazgo mientras ocurre y no tres semanas después leyendo un informe.
Si además puedes sumar a una persona sin perfil técnico, hazlo. Muchos de los fallos más vergonzosos aparecen cuando alguien usa el sistema de forma ingenua y persistente, sin las suposiciones de quien sabe cómo está construido.
Qué se permite y qué no
Las reglas de enfrentamiento se escriben antes y se firman. Deben cubrir: qué entornos se pueden tocar y cuáles quedan prohibidos; si se permite atacar la infraestructura o solo el comportamiento del sistema; qué hacer si un ataque tiene éxito y da acceso a datos reales —detenerse, documentar y escalar, nunca profundizar—; a quién se avisa si aparece algo crítico antes de que termine el ejercicio; y qué canal se usa para esa comunicación.
Incluye una cláusula de detención explícita. En estos ejercicios es habitual encontrar, casi por accidente, algo que ya está siendo explotado o un dato personal que no debería estar ahí. Conviene tener decidido de antemano quién corta y a quién se llama.
Duración y ritmo
Para un primer ejercicio, entre tres y cinco días de trabajo concentrado dan más resultado que un mes de dedicación parcial. La razón es que este tipo de prueba avanza por encadenamiento: un hallazgo pequeño sugiere el siguiente, y esa cadena se pierde si el equipo se dispersa entre otras tareas.
Estructura el tiempo en tres bloques. Un día de reconocimiento, donde el equipo usa el sistema como usuario legítimo y mapea qué herramientas tiene, qué datos toca y dónde están las fronteras de confianza. Dos o tres días de ataque dirigido a los objetivos declarados. Y medio día de consolidación, con todo el equipo junto, para reproducir los hallazgos y escribir el entregable con el contexto fresco.
El entregable, que es lo que realmente importa
Aquí se decide si el ejercicio sirvió. Un informe narrativo de cuarenta páginas se archiva; lo que se convierte en cambios es un conjunto de artefactos accionables.
Un hallazgo que no viene con un caso de prueba reproducible es una anécdota con formato de informe.
Nosotros pedimos cuatro cosas por cada hallazgo, y ninguna es opcional. Primero, la reproducción exacta: la secuencia completa de entradas, el estado previo del sistema, la versión del modelo y del prompt, y la traza de lo que ocurrió por dentro. Segundo, el impacto en términos de negocio, escrito como lo que un atacante consigue, no como el comportamiento anómalo observado. Tercero, la causa raíz señalando el control ausente: casi siempre es un permiso demasiado amplio, una acción irreversible sin aprobación humana o una frontera de confianza que no existía, y rara vez es el modelo. Y cuarto, un caso de prueba automatizable, redactado para que pueda incorporarse tal cual a la suite de evaluaciones que se ejecuta en cada cambio.
Ese cuarto artefacto es el que rompe el ciclo del PDF archivado. Convierte cada hallazgo en una prueba de regresión permanente: si mañana alguien reintroduce el problema, falla la ejecución, no la auditoría del año siguiente. Y es el único mecanismo que hemos visto funcionar cuando el proveedor actualiza el modelo y los supuestos cambian solos.
Cierra el ejercicio con una reunión corta donde cada hallazgo sale con dueño, fecha y decisión explícita —se corrige, se mitiga con un control compensatorio, o se acepta el riesgo con firma de quien puede aceptarlo—. Si algún hallazgo termina sin ninguna de las tres, no lo dejes en el informe: no está pendiente, está descartado, y conviene que eso quede escrito con ese nombre. Para entender cómo se encadenan estos fallos en la práctica, revisa nuestra anatomía de un ataque a un sistema de IA.