El término “red teaming” viene de ejercicios militares de la Guerra Fría donde un equipo adversario designado (rojo) atacaba los planes del equipo defensor (azul). En ciberseguridad, evolucionó hacia la práctica de contratar hackers éticos para encontrar vulnerabilidades antes de que lo hagan los maliciosos. El red teaming de IA aplica la misma filosofía: asumir que el modelo tiene debilidades, luego encontrarlas sistemáticamente. La diferencia clave con el pen testing tradicional es que los modelos de IA fallan de maneras difusas y probabilísticas — no hay un solo exploit que “rootee” un modelo de lenguaje, sino más bien un paisaje de prompts y contextos donde el modelo se comporta de manera inesperada o dañina.
El red teaming moderno de IA típicamente cubre varias categorías de fallo. Las pruebas de seguridad sondean la generación de contenido dañino — ¿puedes hacer que el modelo produzca instrucciones para armas, contenido detallado de autolesiones o material de explotación infantil? Las pruebas de sesgo y equidad verifican si el modelo trata a los grupos demográficos de manera diferente o refuerza estereotipos. Las pruebas de facticidad buscan alucinaciones seguras, especialmente en dominios de alto riesgo como medicina y derecho. Las pruebas de privacidad verifican si el modelo regurgita información personal de sus datos de entrenamiento (investigadores han extraído datos de entrenamiento textuales de GPT-3, incluyendo números de teléfono y direcciones de email). Y las evaluaciones de capacidad evalúan si el modelo podría asistir con tareas genuinamente peligrosas como diseño de bioarmas o ciberataques — estas son las evaluaciones que informan si un modelo es seguro para desplegar.
La práctica se ha profesionalizado rápidamente. Anthropic, OpenAI, Google DeepMind y Meta todos dirigen red teams internos antes de lanzamientos importantes, y cada vez más traen especialistas externos. Anthropic se asoció con expertos en dominio de bioseguridad y ciberseguridad para las evaluaciones pre-lanzamiento de Claude. OpenAI realizó un ejercicio de red teaming externo a gran escala para GPT-4 con más de 50 expertos. Startups como HackerOne y Scale AI han construido plataformas de red-teaming-as-a-service. También hay una comunidad creciente de red teamers de IA independientes — el evento de Red Teaming de IA Generativa de DEF CON en 2023 tuvo miles de participantes probando modelos de múltiples proveedores simultáneamente, y sacó a la luz vulnerabilidades reales que las empresas posteriormente parchearon.
El red teaming automatizado es un complemento cada vez más importante de las pruebas humanas. La idea es usar un modelo de IA para generar prompts adversarios que prueben las defensas de otro modelo. Las técnicas incluyen ataques basados en gradientes (Greedy Coordinate Gradient, o GCG, que encuentra sufijos adversarios sin sentido pero efectivos), enfoques de LLM-como-atacante (donde un modelo “rojo” refina iterativamente prompts de jailbreak basados en las respuestas del objetivo), y fuzzing (mutando sistemáticamente ataques exitosos conocidos para encontrar nuevas variantes). Anthropic y otros laboratorios usan estos métodos automatizados para probar a escala — un red teamer humano podría intentar cientos de ataques en una sesión, mientras un sistema automatizado puede intentar millones. La trampa es que los métodos automatizados tienden a encontrar fallos “raros” (respuestas a tokens sin sentido) mientras los humanos son mejores encontrando vectores de ataque socialmente realistas (del tipo que usuarios reales intentarían).
Una trampa práctica para cualquiera haciendo red teaming: los resultados son altamente sensibles a cómo enmarques el ejercicio. Si solo pruebas los fallos que esperas, solo encontrarás esos. El red teaming más valioso a menudo viene de personas con experiencia en dominios no relacionados con la IA — un trabajador social podría detectar patrones de manipulación que un investigador de seguridad no pensaría en probar, mientras un químico sabría qué instrucciones de síntesis son realmente peligrosas versus cuáles son conocimiento de libro de texto. Por eso los red teams diversos consistentemente encuentran más y diferentes vulnerabilidades que los homogéneos. También es por qué el red teaming nunca está “terminado” — cada nuevo caso de uso, cada nueva integración, cada actualización de modelo potencialmente introduce modos de fallo que las pruebas anteriores no cubrieron.