Red teaming de IA: del ejercicio técnico a la prueba

Lo esencial

• El red teaming dejó de ser opcional en Europa el 2 de agosto de 2025, cuando el artículo 55 del reglamento de IA empezó a aplicarse a los proveedores de modelos de uso general con riesgo sistémico.
• La aplicación ya es efectiva: la Oficina de IA dispone de sus potestades sancionadoras desde el 2 de agosto de 2026, con multas de hasta 15 millones de euros o el 3 por ciento de la facturación mundial anual.
• El régimen de alto riesgo se movió en sentido contrario. El ómnibus digital aprobado el 16 de junio de 2026 aplaza las obligaciones del anexo III al 2 de diciembre de 2027.
• La mayoría de las organizaciones no son proveedoras de esos modelos: su exposición llega por vía contractual, mediante la diligencia sobre proveedores y las peticiones de garantía de los clientes.
• Un ejercicio sin documentar no prueba nada. Lo que lee un evaluador es el expediente: alcance, modelo de amenazas, registro de pruebas, criticidad, responsables de la remediación y contraprueba.

Qué es realmente el red teaming, y qué no es

El red teaming consiste en someter un sistema de IA a un ataque estructurado, ejecutado por personas cuya misión, mientras dura el ejercicio, es hacerlo fallar. El equipo redacta instrucciones diseñadas para sortear las salvaguardas, contamina un índice documental, encadena llamadas a herramientas que el diseñador no había previsto, y registra el comportamiento obtenido. El objetivo no es una puntuación. El objetivo es la lista de comportamientos que nadie pretendía.

Quien lea la primera página de resultados sobre este asunto concluirá que se trata de una disciplina de seguridad y nada más. Cada página bien posicionada describe vectores de ataque, fases de método y herramientas. La descripción es correcta e incompleta, porque omite lo que hoy decide el presupuesto: en la Unión Europea esta actividad constituye una obligación jurídica documentada para una categoría de proveedores y una expectativa documentada para varias más.

Conviene fijar dos límites antes de seguir.

Red teaming, pruebas comparativas y evaluaciones son tres cosas distintas

Las pruebas comparativas miden capacidades conocidas sobre un conjunto fijo de preguntas. Las evaluaciones puntúan un sistema frente a criterios definidos de antemano. Ambas responden a la pregunta de si el sistema hace bien aquello que se le pidió. Ninguna responde a la pregunta de qué más hace.

El red teaming existe para esa segunda pregunta. La investigación de IBM lo formula sin rodeos: el ejercicio sirve para abordar aquello que no se sabe que se ignora. Una batería de pruebas comparativas no puede revelar un modo de fallo para el que nadie escribió una prueba, y es precisamente esa categoría la que produce incidentes.

Consecuencia práctica: los enfoques se complementan, no se sustituyen. Haber medido una capacidad no equivale a haber sondeado un daño.

Tampoco es una prueba de intrusión con otro nombre

Una prueba de intrusión ataca la infraestructura: la red, la pasarela de API, la capa de identidad. Ese trabajo sigue siendo necesario. El red teaming ataca el modelo y su comportamiento, que falla de otra manera. Para un modelo al que se logra convencer no existe un parche. La remediación adopta la forma de reentrenamiento, filtrado, políticas de rechazo, reducción de privilegios o supervisión, nunca de un salto de versión.

La obligación de la que no hablan los resultados de búsqueda

El artículo 55, apartado 1, letra a) del reglamento de IA obliga a los proveedores de modelos de IA de uso general con riesgo sistémico a realizar una evaluación del modelo con arreglo a protocolos y herramientas normalizados que reflejen el estado de la técnica, lo que incluye llevar a cabo y documentar pruebas adversarias dirigidas a detectar y mitigar los riesgos sistémicos. El texto añade que las pruebas deben ser proporcionadas al nivel de riesgo y al estado de la técnica, y que pueden contar con expertos externos independientes.

Tres términos soportan todo el peso. La realización convierte el ejercicio en obligatorio. La documentación convierte el rastro en obligatorio. La proporcionalidad significa que a un proveedor pequeño no se le medirá con el programa de un laboratorio de frontera y, simétricamente, que un laboratorio de frontera no cumple su obligación con un fin de semana de pruebas de instrucciones.

Un modelo entra en la categoría de riesgo sistémico cuando su potencia de cálculo acumulada de entrenamiento supera los 10^25 FLOPs, o cuando la Oficina de IA lo designa con arreglo a otros criterios. El umbral es deliberadamente alto: alcanza a los desarrolladores de modelos de frontera, no a la empresa mediana.

Los plazos son el elemento peor entendido. Las obligaciones sobre modelos de uso general se aplican desde el 2 de agosto de 2025 a los modelos introducidos en el mercado después de esa fecha. Los modelos ya presentes disponen de plazo hasta el 2 de agosto de 2027. Y desde el 2 de agosto de 2026 la Oficina de IA de la Comisión dispone de sus potestades de ejecución, con sanciones de hasta 15 millones de euros o el 3 por ciento de la facturación mundial anual, la cuantía que resulte mayor.

Entretanto, el régimen que todos preparaban desde hacía dos años retrocedió. El Parlamento Europeo aprobó el 16 de junio de 2026 las enmiendas del ómnibus digital, desplazando las obligaciones de los sistemas de alto riesgo autónomos del anexo III del 2 de agosto de 2026 al 2 de diciembre de 2027, y las de los sistemas integrados en productos al 2 de agosto de 2028. El ómnibus no tocó los plazos aplicables a los modelos de uso general.

La situación es, por tanto, la contraria de la que suponen la mayoría de los calendarios de cumplimiento. La obligación de prueba del reglamento que hoy resulta exigible es la que afecta a los modelos de uso general, y las pruebas adversarias son su núcleo.

La vía operativa pasa por el código de buenas prácticas para modelos de uso general. Su capítulo de seguridad y protección, publicado el 10 de julio de 2025, define el dispositivo esperado: evaluaciones de modelos, red teaming, vigilancia poscomercialización, medidas de ciberseguridad, notificación de incidentes y responsabilidad sobre el modelo. La firma sigue siendo voluntaria, pero la Oficina de IA ha señalado que a los firmantes se les considera actuando de buena fe y que sus compromisos pesan al calcular una sanción. Es lo más parecido a un puerto seguro que ofrece el reglamento, y se sostiene sobre pruebas de ensayo.

Quién tiene que hacer red teaming realmente

Para la mayoría de los lectores la respuesta honesta es: usted no, al menos no de forma directa. Conviene decirlo con claridad, porque el contenido que publican los fabricantes de seguridad sobre esta búsqueda da a entender una obligación universal.

Los proveedores de modelos de uso general con riesgo sistémico. Vinculados por el artículo 55, exigible ya, con sanción asociada. La lista es corta y los afectados lo saben.

Los proveedores de sistemas de alto riesgo. El artículo 9 exige un sistema de gestión de riesgos con pruebas a lo largo de todo el ciclo de vida, y el artículo 15 exige sistemas que funcionen de forma fiable y resistan errores, fallos y tentativas de alterar su uso o su rendimiento. Ninguno de los dos emplea la expresión red teaming. Ambos exigen pruebas en condiciones que tensionen el funcionamiento previsto, con método y resultados documentados. Aplicable desde el 2 de diciembre de 2027 para los sistemas autónomos del anexo III.

Los responsables del despliegue. Ninguna obligación legal directa de prueba. La obligación llega por contrato: cuestionarios de compra, anexos de garantía, derechos de auditoría, cláusulas de indemnidad. En la práctica es por esta vía como el red teaming alcanza a la mayoría de las organizaciones, y suele presentarse como una pregunta que hay que responder en treinta días. Estructurar esa respuesta es antes un asunto de gobernanza que técnico, como muestra nuestro análisis de los desafíos de la gobernanza de la IA.

Todos los demás. Voluntario, y cada vez más esperado. Las aseguradoras lo preguntan. Los grandes clientes también. Los consejos de administración se interesan tras el primer incidente público de su sector.

Merece mención un último grupo: las organizaciones cuyo parque de IA no se conoce por completo. No se hace red teaming sobre lo que no se ha inventariado, y los usos no declarados explican que muchos programas cubran solo una fracción de la superficie real. La selección de personal ofrece un ejemplo nítido, como muestra nuestro análisis sobre la inteligencia artificial en recursos humanos.

Qué pide realmente cada marco de referencia

Los marcos coinciden en la actividad y divergen con claridad en su fuerza vinculante.

Marco	Qué exige	Término empleado	¿Vinculante?
Reglamento de IA art. 55.1.a)	Evaluación del modelo con pruebas adversarias documentadas y proporcionadas al riesgo	Pruebas adversarias	Sí, para modelos con riesgo sistémico, exigible desde el 2 de agosto de 2026
Reglamento de IA art. 9 y art. 15	Pruebas en el ciclo de vida bajo condiciones exigentes, método y resultados documentados	Pruebas	Sí, para alto riesgo, desde el 2 de diciembre de 2027
Código de buenas prácticas, capítulo de seguridad y protección	Evaluaciones de modelos, red teaming, vigilancia poscomercialización, notificación de incidentes	Red teaming	Voluntario, pero relevante en sede sancionadora
NIST AI RMF, Measure 1.1	Equipos adversarios y pruebas adversarias para revelar capacidades peligrosas y propiedades emergentes	Red teaming	Voluntario
NIST AI 600-1, perfil de IA generativa	Red teaming antes y después del despliegue, sobre doce categorías de riesgo	Red teaming	Voluntario
ISO/IEC 42001	Ninguna cláusula específica; los registros de prueba sostienen el sistema de gestión	Prueba y evaluación	Certificable
Guía OWASP GenAI Red Teaming	Pruebas por fases: modelo, implementación, sistema, ejecución	Red teaming	Estándar de práctica
Guía CSA y OWASP sobre IA agéntica	Doce categorías de amenazas agénticas sobre el modelo MAESTRO	Red teaming	Estándar de práctica

De la tabla se desprenden dos observaciones.

Primera, ISO/IEC 42001 nunca pronuncia el término, lo que sorprende a quien llega buscando una cláusula. La norma reclama la prueba de que los riesgos se identificaron, los tratamientos se ensayaron y los resultados se revisaron. Un informe de red teaming con rastro de remediación satisface ese requisito; una simple prueba comparativa de rendimiento no.

Segunda, los instrumentos estadounidenses y europeos describen la misma práctica con fuerza distinta. El perfil de Berkeley para modelos de uso general sitúa el red teaming bajo Measure 1.1 del NIST AI RMF, para revelar capacidades peligrosas, vulnerabilidades y propiedades emergentes, y lo repite como control de ciclo de vida bajo Manage 1.3, 2.3 y 2.4. NIST AI 600-1 recomienda practicarlo antes y después del despliegue sobre doce categorías de riesgo. Ninguno prevé multas. Ambos son lo que un evaluador europeo aceptará como estado de la técnica cuando el artículo 55 pregunte frente a qué estándar se ensayó.

En el plano nacional, la AESIA actúa como autoridad de supervisión de la IA y la AEPD conserva su competencia cuando hay tratamiento de datos personales de por medio. No crean una obligación nueva de red teaming, pero fijan el interlocutor ante el que habrá que acreditar la diligencia.

Delimitar el alcance para que los hallazgos se sostengan

La mayoría de los informes falla en el alcance, no en la prueba. El ejercicio localiza problemas reales y después nadie sabe decir a qué versión del sistema se referían.

Nombrar el objetivo con precisión. Modelo base, variante especializada, capa de recuperación documental, superficie de herramientas y agentes, aplicación desplegada. Indique qué entra en el alcance, qué queda fuera y por qué. Probar el modelo base no cubre el producto construido encima.

Fijar todas las versiones. Compilación del modelo, versión de la instrucción de sistema, instantánea del índice documental, configuración de salvaguardas, permisos de herramientas. Un hallazgo referido a una compilación sin nombre no puede contraprobarse, y un hallazgo no comprobable no es una prueba.

Definir los daños desde la taxonomía propia. Las listas genéricas producen hallazgos genéricos. Si el registro de riesgos señala el compromiso financiero no autorizado y la divulgación de datos de clientes como exposiciones principales, esas entran primero en el alcance, y el informe debe explicar por qué las demás se aplazaron. Ese razonamiento hace visible su apetito de riesgo ante un evaluador.

Decidir sobre la independencia de forma deliberada. El artículo 55 contempla expresamente el recurso a expertos externos independientes. Los equipos internos conocen mejor el sistema y cuestan menos. Los equipos externos son más difíciles de descartar y pesan más en el plano probatorio. La elección debe constar por escrito y motivada, porque se discutirá.

Extender el alcance a los sistemas agénticos. Las pruebas de un solo turno resultan insuficientes en cuanto un sistema dispone de autonomía, memoria y herramientas. La guía de la Cloud Security Alliance y de OWASP organiza este trabajo en torno al modelo de amenazas MAESTRO y a doce categorías, entre ellas el secuestro de autorizaciones y del control del agente, la elusión del punto de control humano, la manipulación de objetivos, la manipulación de memoria y contexto, la explotación multiagente, el radio de impacto y la trazabilidad del agente. Este último punto pesa más de lo que parece: si las acciones de un agente no pueden imputarse a posteriori, el fallo es antes un fallo de responsabilidad que un problema de seguridad.

Las pruebas que el red teaming debe dejar

Es la parte que los resultados de búsqueda ignoran por completo, y es la que decide si el gasto estuvo justificado. Imagine el expediente que un evaluador abrirá dentro de dieciocho meses.

La nota de alcance. Fechada, versionada, con las exclusiones y su justificación.

El modelo de amenazas. El referente adoptado nombrado de forma explícita: MITRE ATLAS, MAESTRO, la taxonomía OWASP GenAI, o el propio, mapeado sobre uno de ellos.

El registro de pruebas. Qué se intentó, quién lo hizo, con qué herramientas, en qué fecha, contra qué compilación. De las campañas automatizadas se registra la configuración, no solo el resultado.

Los hallazgos con criticidad y motivación. La motivación pesa más que la calificación. Un evaluador puede discutir un nivel alto y aceptar igualmente el expediente si el razonamiento es legible.

Las decisiones de remediación con responsable y plazo. Cada hallazgo recibe un estado: corregido, mitigado, aceptado, o aplazado con fecha de revisión.

El riesgo residual aceptado al nivel adecuado. Una persona con autoridad suficiente firma que la exposición restante es tolerable frente a un umbral escrito.

La prueba de la contraprueba. La demostración de que la corrección funciona, sobre la misma prueba, contra la compilación nombrada. Sin ella, la columna de remediación es una afirmación.

Conviene nombrar dos situaciones. Un red teaming sin documentar no prueba nada, por buenas que hayan sido las pruebas. Y un informe con hallazgos sin rastro de remediación es peor que ningún informe, porque acredita de forma duradera que usted lo sabía. Autoridades y demandantes lo leen igual.

Dónde encaja el red teaming en el resto del expediente de gobernanza

Un red teaming que termina en un PDF ha fracasado, sean cuales sean sus hallazgos. Cuatro conexiones lo vuelven operativo.

El registro de riesgos. Los hallazgos se convierten en entradas con responsable y fecha de revisión, en el mismo sistema que cualquier otro riesgo. Si viven en un seguimiento de seguridad aparte, el expediente de gobernanza presenta un hueco justo donde debería estar el enlace.

La notificación de incidentes. Un hallazgo que después se materializa en producción se convierte en una cuestión del artículo 73, y lo primero que se preguntará es si usted lo sabía.

La vigilancia poscomercialización. El red teaming es una sonda puntual. La vigilancia es la mitad continua, y el código de buenas prácticas nombra ambas. Un programa con una sola mitad es medio programa.

El reporte de transparencia. El perfil de Berkeley canaliza los resultados hacia las fichas de modelo y de sistema, omitiendo de forma responsable los detalles que aumentarían el potencial de abuso. Esa reserva no es opcional: publicar una elusión funcional es un fallo de divulgación, no transparencia.

Cinco defectos que anulan la prueba

Probar una compilación y desplegar otra. El defecto más común. El informe describe un sistema que ya no existe.

Limitar el alcance a la inyección de instrucciones. La inyección de instrucciones es el modo de fallo famoso, no el más caro. Son los permisos sobre herramientas y la autonomía de los agentes los que producen los incidentes con consecuencias financieras.

No tener escala de criticidad. Cuando todo es medio, nada se prioriza, y la motivación que un evaluador quiere leer no existe.

Hallazgos sin responsable. Un hallazgo sin asignar es una nota. Seguirá abierto en la revisión siguiente, y las fechas lo demostrarán.

Ninguna contraprueba. La corrección se afirma en lugar de demostrarse. Es la laguna más frecuente en programas de red teaming por lo demás serios, y la más barata de cerrar.

Preguntas frecuentes

¿El red teaming es obligatorio por ley?

En la Unión Europea sí, para un grupo concreto. El artículo 55, apartado 1, letra a) del reglamento de IA obliga a los proveedores de modelos de uso general con riesgo sistémico a realizar y documentar pruebas adversarias, obligaciones exigibles desde el 2 de agosto de 2026. Para los proveedores de sistemas de alto riesgo, los artículos 9 y 15 exigen pruebas documentadas en condiciones exigentes desde el 2 de diciembre de 2027, sin emplear el término. Para el resto, la obligación es contractual antes que legal.

¿A quién obliga el reglamento de IA?

A los proveedores de modelos de uso general cuya potencia de cálculo acumulada de entrenamiento supere los 10^25 FLOPs, o a los que la Oficina de IA designe como portadores de riesgo sistémico. Es una población reducida de desarrolladores de modelos de frontera. Quienes despliegan esos modelos heredan las expectativas por contrato, y así es como el requisito alcanza a la mayoría de las organizaciones.

¿Qué diferencia hay con una prueba de intrusión?

Una prueba de intrusión ataca la infraestructura y produce vulnerabilidades con su parche. El red teaming ataca el comportamiento del modelo y produce modos de fallo sin parche. La remediación consiste en reentrenamiento, filtrado, política de rechazo, reducción de privilegios o supervisión. Ambas cosas son necesarias y ninguna sustituye a la otra.

¿Con qué frecuencia hay que hacerlo?

Ate la cadencia al cambio y no al calendario. Un nuevo modelo base, una especialización, una herramienta o integración nueva, una modificación sustancial de la instrucción de sistema o un nuevo contexto de despliegue justifican cada uno un ejercicio. Añada una línea de referencia periódica, anual para la mayoría de los sistemas, y trate las pruebas posteriores al despliegue por separado de las anteriores.

¿Se puede automatizar el red teaming?

En parte, y el reparto importa para la prueba. Las sondas automatizadas aportan amplitud, repetibilidad y el mecanismo de contraprueba, justo lo que la documentación necesita. Los operadores humanos encuentran el camino inédito que ninguna biblioteca de sondas contiene. Un programa íntegramente automatizado producirá un expediente pulcro con un punto ciego previsible.

¿Qué pide un auditor después del ejercicio?

La nota de alcance con las versiones, el modelo de amenazas y su referente, el registro de pruebas, los hallazgos con criticidad y motivación, responsables y plazos de remediación, la aceptación del riesgo residual y su firma, y la prueba de la contraprueba. El auditor evalúa la cadena documental, no el ejercicio, porque es la única parte que sobrevive.

Conclusión

Los resultados de búsqueda tratan el red teaming como un servicio de seguridad; en esa lectura la decisión se reduce a una línea de presupuesto de un equipo técnico. La posición regulatoria dice otra cosa. Las pruebas adversarias son la obligación del reglamento de IA exigible hoy, mientras que el régimen de alto riesgo que todos preparaban queda a más de un año, y lo que cumple la obligación no es el ejercicio sino el rastro que deja.

Ese desplazamiento cambia de dueño el asunto. Las pruebas siguen en manos de quienes saben romper sistemas. La nota de alcance, la motivación de las criticidades, el registro de remediación y la firma del riesgo residual pertenecen a la gobernanza, porque son los únicos documentos que alguien leerá. Empiece por el expediente que tendría que presentar y encargue después el red teaming que lo rellena. Nuestra plataforma de gobernanza de la IA muestra cómo estas piezas quedan en el mismo sitio.