01En qué se diferencia el AI Red Teaming del Red Teaming clásico
El Red Teaming clásico simula atacantes contra redes, sistemas e identidades; los hallazgos suelen ser vulnerabilidades técnicas claramente reproducibles. El AI Red Teaming, en cambio, se centra en el comportamiento del propio sistema de IA: los modelos de lenguaje responden de forma probabilística, un mismo ataque puede tener éxito recién en el décimo intento, y un hallazgo a menudo no es un error de programación, sino un comportamiento indeseado del modelo. Además de los objetivos de seguridad clásicos, se evalúan también los daños relacionados con el contenido, como la generación de contenidos dañinos o falsos. Igual de importante es la distinción respecto a los benchmarks: los conjuntos de prueba estáticos miden capacidades conocidas, mientras que el Red Teaming busca deliberadamente modos de fallo novedosos y específicos del contexto, una de las lecciones centrales del Microsoft AI Red Team tras más de 100 productos de GenAI evaluados.
02Ataques a nivel de modelo y de aplicación
En el centro están cuatro familias de técnicas. Los jailbreaks anulan las directrices de seguridad de un modelo para desbloquear contenidos o funciones restringidos. En la prompt injection directa, el atacante coloca instrucciones manipuladoras en su propia entrada; en la prompt injection indirecta las oculta en contenidos que el sistema procesa, como páginas web, documentos o correos electrónicos. La extracción de datos apunta a los prompts de sistema, los datos de entrenamiento o las fuentes de conocimiento conectadas, recogida en el OWASP Top 10 for LLM Applications 2025 como Sensitive Information Disclosure (LLM02) y System Prompt Leakage (LLM07), mientras que la Prompt Injection encabeza la lista como LLM01. Especialmente crítico es el uso inseguro de herramientas (Excessive Agency, LLM06): si un modelo puede enviar correos electrónicos, consultar bases de datos o ejecutar código, una instrucción inyectada se convierte en una acción ejecutada.
03Anclajes metodológicos: OWASP GenAI Red Teaming Guide y NIST
Con la GenAI Red Teaming Guide (versión 1.0, enero de 2025), el OWASP GenAI Security Project ha publicado una metodología estructurada y neutral respecto a fabricantes. La guía contempla cuatro niveles de prueba: la evaluación del propio modelo, la implementación (incluidos guardrails y prompts de sistema), la infraestructura circundante y el comportamiento en tiempo de ejecución en interacción con usuarios y procesos. De forma complementaria, NIST AI 100-2 E2025 (marzo de 2025) aporta una taxonomía y terminología para adversarial machine learning que clasifica los ataques contra sistemas de IA predictivos y generativos según los objetivos, las capacidades y la fase del ciclo de vida del atacante. Juntos, ambos documentos constituyen el vocabulario con el que definir de forma trazable el alcance de las pruebas y la matriz de evaluación.
04Desarrollo: escenarios, matriz de evaluación, reporting
Un AI Red Teaming comienza con el scoping: ¿qué caso de uso, qué clases de datos, qué herramientas conectadas, qué potencial de daño? De ahí surge un modelado de amenazas con escenarios de ataque concretos, priorizados según el daño realista y no según la mera viabilidad. Las pruebas se realizan de forma combinada: automatizadas con frameworks como PyRIT, la herramienta de código abierto de Microsoft, para lograr cobertura en amplitud, y manuales para cadenas de ataque específicas del contexto; según la experiencia del Microsoft AI Red Team, la automatización amplía la cobertura, pero no sustituye la pericia humana. Una matriz de evaluación clasifica los hallazgos según gravedad, reproducibilidad y objetivos de seguridad afectados. El reporting documenta cada hallazgo con evidencias trazables (prompts y respuestas del modelo) y deriva medidas de refuerzo, como permisos de herramientas más restrictivos, filtros de entrada y salida o prompts de sistema revisados.
05Anclaje regulatorio: el Reglamento de IA
El Reglamento de IA (Reglamento (UE) 2024/1689) convierte por primera vez el adversarial testing en una obligación legal explícita: según el art. 55(1)(a), los proveedores de modelos de IA de uso general con riesgo sistémico deben realizar evaluaciones de modelos conforme a protocolos e instrumentos normalizados y acordes con el estado de la técnica, incluida la realización y documentación de adversarial testing para identificar y mitigar riesgos sistémicos. Estas obligaciones se aplican desde el 2 de agosto de 2025. Afectan directamente solo a unos pocos proveedores de modelos, pero marcan la pauta para toda la cadena de suministro. Para los sistemas de IA de alto riesgo, el art. 15(5) exige además resiliencia frente a ataques específicos de la IA; se mencionan, entre otros, data poisoning, model poisoning, adversarial examples o model evasion y ataques contra la confidencialidad. El AI Red Teaming es una vía natural para demostrar la eficacia de tales medidas.
06¿Puntual o continuo?
Una evaluación puntual —por ejemplo, antes de la puesta en producción o como base de una decisión de aprobación— proporciona una instantánea fiable. Solo sigue siendo válida mientras el sistema no cambie: las actualizaciones del modelo por parte del proveedor, los prompts de sistema ajustados, las nuevas herramientas y fuentes de datos o las nuevas técnicas de ataque desplazan continuamente el nivel de riesgo. El Microsoft AI Red Team extrae de ello la lección de que la protección de los sistemas de IA nunca está terminada. Para aplicaciones de IA productivas y en constante evolución conviene, por tanto, un enfoque continuo: con pruebas de regresión automatizadas en cada cambio relevante, pruebas manuales en profundidad periódicas y un anclaje firme en el proceso de gobernanza y desarrollo de la IA.
