Red teaming de IA, desde cero.
Antes de que un modelo se lance, alguien cuyo trabajo es romperlo tiene su turno. Esto es lo que implica ese trabajo — y lo que lo separa de atacar un sistema que no es tuyo.
El red teaming es una idea antigua tomada del ámbito militar y adoptada por los equipos de seguridad hace décadas: pagas a alguien para que ataque tu propio sistema, en condiciones controladas, de modo que encuentres las debilidades antes de que lo haga un adversario. El red teaming de IA (equipo rojo de IA) aplica esa misma disciplina a los modelos de aprendizaje automático — y en especial a los grandes modelos de lenguaje — donde los modos de fallo no se parecen en nada a un fallo de software clásico.
Cuando haces red teaming de una aplicación web, normalmente buscas defectos en el código: un fallo de inyección, un control de acceso roto, un servidor mal configurado. Cuando haces red teaming de un LLM, la «vulnerabilidad» suele ser el modelo comportándose exactamente como fue diseñado — siguiendo instrucciones — pero haciéndolo con una entrada que nunca debería haber contado como instrucción. Ese cambio es la razón por la que el red teaming de IA se ha convertido en su propio subcampo en lugar de en una nota al pie de un informe de pentest.
Qué buscan realmente los red teamers
El Top 10 de OWASP para aplicaciones LLM es lo más parecido a una lista de comprobación compartida que tiene el campo. Un ejercicio de red team contra un modelo o un producto basado en LLM suele sondear en busca de:
| Riesgo | Cómo se ve |
|---|---|
| Inyección de prompts | Tanto directa («ignora tus instrucciones y…») como indirecta, donde la instrucción maliciosa está oculta en contenido que el modelo lee, como una página web o un documento. |
| Jailbreaks | Inducir al modelo a saltarse su entrenamiento de seguridad para que produzca una salida que fue afinado para rechazar. |
| Divulgación de información sensible | Conseguir que el modelo revele system prompts, datos de entrenamiento, claves de API pegadas en el contexto o datos de otro usuario. |
| Manejo inseguro de la salida | Cuando la aplicación confía en la salida del modelo y la introduce directamente en una shell, una consulta a base de datos o un navegador, convirtiendo un truco de texto en ejecución de código. |
| Exceso de autonomía | Un agente con herramientas (correo, pagos, acceso a archivos) que puede ser dirigido a realizar acciones dañinas para las que técnicamente tenía permiso. |
Lo tratamos en profundidad en Inyección de prompts, explicada. Un jailbreak apunta al alineamiento del modelo; la inyección de prompts apunta a la aplicación que lo envuelve. Se solapan, pero no son lo mismo.
Jailbreaks frente a inyección de prompts
Estos dos se confunden constantemente, así que merece la pena ser preciso. Un jailbreak ataca al propio modelo: el objetivo es vencer el entrenamiento de seguridad para que el modelo diga algo que fue construido para rechazar. La inyección de prompts ataca a la aplicación: el objetivo es lograr que el modelo trate el contenido aportado por el atacante como instrucciones de confianza, secuestrando aquello que se suponía que la aplicación debía hacer. Un bot de soporte que filtra su system prompt porque un usuario pegó un mensaje ingenioso ha sufrido una inyección de prompts. Un modelo que produce contenido no permitido tras un elaborado montaje de juego de rol ha sido víctima de un jailbreak. Un red team serio prueba ambos, porque un producto real falla de las dos maneras.
Cómo se evalúa un modelo
Hacer red teaming de un LLM es en parte oficio manual y en parte automatización. Un red teamer humano aporta una creatividad que las pruebas guionizadas pasan por alto — pero los humanos no escalan, así que los equipos los combinan con arneses automatizados que lanzan miles de prompts adversariales y puntúan las respuestas. Un ciclo típico se parece a esto:
- Define la taxonomía de daños. Decide, antes de probar, qué significa «salida mala» para este sistema: fuga de datos, instrucciones peligrosas, decisiones sesgadas, uso indebido de herramientas. Los objetivos vagos producen hallazgos vagos.
- Genera entradas adversariales. Parte de patrones de ataque conocidos y luego mútalos — reformulaciones, codificaciones, cambios de idioma, encuadres de juego de rol — para sondear los límites de los rechazos del modelo.
- Puntúa las respuestas. A menudo otro modelo actúa como juez automatizado en la primera pasada, con humanos revisando los casos límite. Calibrar ese juez es la mitad del trabajo.
- Informa con reproducciones. Un hallazgo solo es útil si un ingeniero puede reproducirlo. «El modelo a veces se comporta mal» no es un informe de error; un prompt y una transcripción guardados sí lo son.
- Vuelve a probar tras cada cambio. Una defensa afinada contra una versión del modelo rara vez se traslada limpiamente a la siguiente. El red teaming es continuo, no una barrera de una sola vez.
Anthropic, OpenAI, Google y otros publican system cards e informes de seguridad que describen los resultados de sus red teams antes de los lanzamientos importantes; el NIST de EE. UU. también ha publicado guías sobre pruebas adversariales de sistemas de IA. Leerlas es la forma más rápida de ver cómo es una evaluación madura en la práctica.
Dónde están los límites
Esta es la parte que más importa para quien está aprendiendo el campo. El red teaming está autorizado por definición — estás probando un sistema que es tuyo, o uno para el que tienes permiso explícito y por escrito para probarlo, dentro de un alcance acordado. En el momento en que envías entradas manipuladas al modelo en producción de otra persona para ver qué se rompe, ya no estás haciendo red teaming; estás atacando un sistema sin autorización, lo cual va tanto contra los términos de servicio de cualquier proveedor como, dependiendo de dónde vivas, contra la ley.
Si quieres práctica de verdad, el camino seguro es tu propio laboratorio: ejecuta un modelo local, levanta una aplicación LLM deliberadamente vulnerable o usa uno de los retos públicos estilo capture-the-flag creados exactamente para esto. Empieza por ejecutar un LLM local para que cada experimento se quede en hardware que controlas.
El resumen en una línea: el red teaming de IA es la disciplina de romper tus propios modelos a propósito, de forma controlada, para que los fallos aparezcan en un informe en lugar de en las noticias. Las técnicas se pueden aprender, las herramientas maduran rápido y la única regla dura — probar solo aquello que estás autorizado a probar — es lo que separa a un red teamer de un atacante.