Resumen en 40 palabras: el red teaming de IA consiste en atacar de forma controlada un sistema con inteligencia artificial para descubrir cómo puede fallar o ser manipulado antes de que ocurra en producción. Combina pruebas automatizadas a gran escala con el criterio de especialistas ofensivos.
Un chatbot que funciona bien en una demo puede comportarse de forma muy distinta cuando un usuario con malas intenciones lo presiona. El red teaming de IA existe para descubrir esa diferencia a tiempo. Esta guía explica qué es, en qué se diferencia de un pentest, cómo se organiza un ejercicio, qué herramientas se usan y cuándo conviene hacerlo, también por exigencia del AI Act.
Qué es el red teaming de IA
Es un ejercicio en el que un equipo adopta el papel de adversario y trata de conseguir que un sistema de IA haga algo que no debería: revelar información, saltarse sus restricciones, usar una herramienta de forma indebida, dar respuestas peligrosas o falsas, o caer ante un consumo abusivo. El objetivo no es demostrar que el sistema «es seguro», sino encontrar y priorizar sus formas de fallar.
El término viene del red team militar y de ciberseguridad, pero en IA tiene dos lecturas que conviene separar:
- Red teaming de seguridad: ataques que comprometen la confidencialidad, integridad o disponibilidad (inyección de instrucciones, fuga de datos, abuso de herramientas).
- Red teaming de seguridad del contenido (safety): respuestas dañinas, sesgadas o ilegales que el sistema no debería producir.
Para una empresa que integra un modelo de terceros, lo prioritario suele ser lo primero: qué puede hacer un atacante con tu integración, tus datos y tus permisos.
Red teaming de IA, pentest de IA y evaluaciones: diferencias
| Pentest de IA | Red teaming de IA | Evaluaciones (evals) | |
|---|---|---|---|
| Pregunta | ¿Qué vulnerabilidades tiene este sistema? | ¿Puede un adversario lograr este objetivo concreto? | ¿El modelo responde bien a este conjunto de casos? |
| Enfoque | Cobertura de una lista de riesgos (OWASP) | Objetivos y escenarios de ataque realistas | Métricas repetibles de calidad y seguridad |
| Duración | Acotada | Acotada o continua | Continua, en cada versión |
| Resultado | Lista de hallazgos con gravedad | Rutas de ataque demostradas e impacto | Puntuaciones y regresiones |
En la práctica se combinan: el pentest da cobertura, el red teaming da realismo y las evaluaciones evitan que un fallo corregido vuelva en la siguiente versión. En BCNSoluciona los integramos en el servicio de pentesting de IA.
Las cuatro áreas que propone OWASP
La GenAI Red Teaming Guide de OWASP (enero de 2025) organiza el trabajo en cuatro áreas. Es útil para no quedarse solo en «probar frases en el chat»:
- Evaluación del modelo: cómo se comporta el modelo por sí mismo ante entradas adversarias.
- Pruebas de la implementación: el prompt del sistema, los filtros, el RAG y la lógica que la empresa ha construido alrededor.
- Evaluación de la infraestructura: APIs, almacenamiento, bases vectoriales, identidades y conectores.
- Análisis del comportamiento en ejecución: cómo actúa el sistema completo con usuarios, datos reales y herramientas, incluidos los agentes.
Metodología paso a paso
1. Alcance y reglas
Qué sistema, qué versión del modelo, qué entorno (mejor preproducción con datos realistas), qué usuarios de prueba, qué está fuera de alcance y qué se hace si se encuentra un fallo crítico durante el ejercicio.
2. Modelo de amenazas
Quién podría atacar (cliente, empleado, tercero que envía un correo, proveedor) y qué querría conseguir. MITRE ATLAS ayuda a describir tácticas y técnicas reales contra sistemas de IA. De aquí salen los objetivos del ejercicio, por ejemplo: «obtener el historial de otro cliente» o «conseguir que el agente cree un pedido sin confirmación».
3. Diseño de las pruebas
Para cada objetivo se preparan escenarios: inyección directa e indirecta, conversaciones de varios turnos, contenido envenenado en las fuentes, abuso de herramientas, extracción del prompt, consumo abusivo y salidas peligrosas. El OWASP Top 10 para LLM y agentes sirve como lista de control para no dejar huecos.
4. Ejecución automatizada y manual
La automatización lanza miles de variantes y mide cuántas tienen éxito. La parte manual encadena hallazgos pequeños hasta convertirlos en un impacto real, que es lo que hacen los atacantes. Los modelos no son deterministas: una prueba que falla nueve veces puede funcionar a la décima, así que cada escenario se repite.
5. Informe con impacto de negocio
Cada hallazgo con su ruta de ataque, cómo reproducirlo, su tasa de éxito, su impacto y una corrección concreta, más un resumen para dirección.
6. Corrección y repetición
Se vuelve a probar lo corregido y se convierten los ataques que funcionaron en pruebas automáticas que se ejecuten en cada versión.
Herramientas habituales
- PyRIT (Microsoft, licencia MIT): marco en Python para orquestar campañas de ataque, incluidas conversaciones de varios turnos.
- garak (Apache 2.0): escáner de vulnerabilidades de LLM desde la línea de comandos, con muchas sondas predefinidas.
- promptfoo: herramienta de evaluación y red teaming con versión de comunidad que se ejecuta en local.
Las herramientas encuentran mucho, pero no deciden qué importa para tu negocio. Ese criterio, y la explotación final, siguen siendo trabajo de especialistas.
Qué medir
- Tasa de éxito por escenario: de cada 100 intentos, cuántos logran el objetivo.
- Gravedad e impacto: qué dato, acción o coste está en juego.
- Esfuerzo del atacante: si basta un mensaje o hace falta una cadena compleja.
- Regresiones: si un fallo corregido reaparece al cambiar de modelo o de prompt.
Red teaming de IA y AI Act
El AI Act no usa la expresión «red teaming» para todos los casos, pero lo hace necesario en la práctica:
- Sistemas de alto riesgo (artículo 15): deben ser precisos, robustos y ciberseguros, también frente a envenenamiento, ejemplos adversarios y ataques a la confidencialidad. Tras el Reglamento Ómnibus Digital sobre IA (Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026), estas obligaciones se aplican desde el 2 de diciembre de 2027 para los sistemas del anexo III.
- Modelos de IA de uso general con riesgo sistémico (artículo 55): sus proveedores deben hacer pruebas adversarias. Afecta a los grandes fabricantes, no a la empresa que integra el modelo, pero marca el estándar de lo que se considera diligente.
Para el resto de sistemas, un red teaming documentado es una de las mejores evidencias dentro de un modelo de gobierno de la IA o de una certificación ISO/IEC 42001.
Cuándo hacerlo
- Antes de abrir un sistema de IA a clientes o a toda la plantilla.
- Al conectar el modelo a una herramienta nueva o a una fuente de datos sensible.
- Al cambiar de modelo o de proveedor.
- Al menos una vez al año en sistemas en producción, y de forma continua si son críticos.
Errores frecuentes
- Probar solo el chat y olvidar las entradas indirectas (correos, documentos, webs).
- Medir si el modelo «dice cosas feas» y no si se puede robar un dato o ejecutar una acción.
- Hacer una prueba única y no repetirla cuando cambia el modelo.
- No guardar los ataques que funcionaron como pruebas automáticas.
Preguntas frecuentes sobre red teaming de IA
¿Qué es el red teaming de IA?
Un ejercicio de ataque controlado contra un sistema de inteligencia artificial para descubrir cómo puede ser manipulado o fallar, y corregirlo antes de que lo aproveche un atacante.
¿En qué se diferencia de un pentest de IA?
El pentest busca cubrir una lista de vulnerabilidades. El red teaming persigue objetivos concretos de un adversario, como robar un dato o provocar una acción, y encadena fallos para demostrar el impacto real.
¿Es obligatorio por el AI Act?
Las pruebas adversarias son obligatorias para los proveedores de modelos de uso general con riesgo sistémico. Para los sistemas de alto riesgo, el artículo 15 exige robustez y ciberseguridad, y el red teaming es la forma más directa de demostrarlas.
¿Qué herramientas se usan?
Herramientas de código abierto como PyRIT, garak o promptfoo para automatizar miles de pruebas, combinadas con trabajo manual de especialistas para encadenar hallazgos y medir el impacto.
¿Cada cuánto hay que repetirlo?
Antes de cada lanzamiento, con cada cambio de modelo, herramienta o fuente de datos, y al menos una vez al año en sistemas en producción.
Contenido revisado por el equipo de consultoría de BCNSoluciona · octubre de 2026. Fuentes: OWASP GenAI Red Teaming Guide (enero de 2025), MITRE ATLAS, NIST AI 100-2 E2025 y Reglamento (UE) 2026/1744.
