El red-teaming de IA y la Ley de IA de la UE: qué es y dónde encaja
El red-teaming respalda la gestión de riesgos del Art. 9, la robustez del Art. 15 y las pruebas adversariales del Art. 55 para los proveedores de GPAI con riesgo sistémico. No es un mandato autónomo.
El red-teaming es la práctica de intentar sistemáticamente encontrar fallos en un sistema de IA simulando un comportamiento adversarial — sondeando resultados inesperados, eludiendo los controles de seguridad, provocando contenido perjudicial o explotando la fragilidad en los márgenes de los datos de entrenamiento. Un equipo rojo (red team) para un sistema de IA hace lo que un pentester hace para una red: asumir la mentalidad del adversario, buscar qué salió mal que el constructor no anticipó y documentar los resultados para que puedan corregirse.
La Ley de IA de la UE de 2024 (Reglamento (UE) 2024/1689) no emplea el término «red-teaming». Es una práctica, no un requisito legal — y esa distinción importa para el encuadre del cumplimiento. Lo que sí exige el Reglamento es un sistema de gestión de riesgos (Artículo 9), pruebas de exactitud y robustez (Artículo 15) y — para los proveedores de modelos GPAI con riesgo sistémico — la evaluación del modelo frente a condiciones adversariales (Artículo 55). El red-teaming es una técnica que sirve a los tres. Si es obligatorio depende de qué sea el sistema y de quién lo construya.
Dónde conecta el red-teaming con el Reglamento
Artículo 9: sistema de gestión de riesgos
El Artículo 9 exige a los proveedores de IA de alto riesgo establecer, implantar, documentar y mantener un sistema de gestión de riesgos a lo largo de todo el ciclo de vida del sistema de IA. El SGR debe identificar y analizar los riesgos conocidos y razonablemente previsibles para la salud, la seguridad y los derechos fundamentales; estimar y evaluar esos riesgos; y adoptar medidas adecuadas de mitigación de riesgos.
«Riesgos conocidos y razonablemente previsibles» es la frase clave. Un sistema de gestión de riesgos que solo identifica los riesgos en los que pensó el equipo de desarrollo sin presión adversarial es probablemente incompleto. El sesgo en casos límite, la inyección de instrucciones (prompt injection) en los componentes de modelos de lenguaje, los fallos por desplazamiento de la distribución y la manipulación sistémica de los resultados son categorías de riesgo que las pruebas internas — que tienden a confirmar el comportamiento esperado — pasan por alto de forma sistemática. El red-teaming es una de las herramientas más eficaces para sacar a la luz esta clase de riesgo antes del despliegue.
El requisito del Artículo 9 no se satisface con una lista de riesgos estática ensamblada en la fase de diseño. El Reglamento exige que el SGR se actualice a partir de la nueva información que surja de la vigilancia poscomercialización (Artículo 72) y del proceso de evaluación de la conformidad. Un ejercicio de red team realizado antes del lanzamiento alimenta directamente la evaluación del riesgo residual del SGR y la documentación técnica del Artículo 11 (Anexo IV).
Artículo 15: exactitud, robustez y ciberseguridad
El Artículo 15 exige que los sistemas de IA de alto riesgo alcancen un nivel adecuado de exactitud y sean resilientes frente a errores, fallos, incoherencias y — críticamente — frente a ataques adversariales que pudieran alterar los resultados o explotar el sistema. Los proveedores deben declarar las métricas de rendimiento y sus límites.
El red-teaming evidencia directamente el cumplimiento del elemento de robustez adversarial del Artículo 15. Un proveedor que puede mostrar resultados documentados de red team — los tipos de ataque intentados, las condiciones en las que el sistema falló, las mitigaciones implementadas y la evaluación del riesgo residual — está en una posición más sólida que quien se apoya únicamente en el rendimiento de los benchmarks. Los benchmarks miden el comportamiento promedio; el red-teaming sondea los modos de fallo que más importan para la seguridad.
El elemento de ciberseguridad del Artículo 15 se solapa con el requisito de robustez adversarial del Artículo 55 para los modelos GPAI con riesgo sistémico (véase más abajo). Para los sistemas de IA de alto riesgo que no se basan en GPAI, el requisito de ciberseguridad del Artículo 15 no impone el red-teaming por su nombre, pero sí exige pruebas de que el sistema ha sido evaluado frente a entradas adversariales realistas pertinentes para su contexto de despliegue.
Artículo 55: proveedores de GPAI con riesgo sistémico
El Artículo 55 impone obligaciones específicas a los proveedores de modelos GPAI clasificados como de riesgo sistémico con arreglo al Artículo 51 — los entrenados por encima del umbral de 10²⁵ FLOP (o designados por la Oficina de IA). Entre esas obligaciones: realizar evaluaciones del modelo, incluidas pruebas adversariales, para identificar y mitigar los riesgos sistémicos; evaluar y mitigar los posibles riesgos sistémicos a escala de la Unión; y mantener protecciones de ciberseguridad para el modelo.
Para los proveedores de GPAI con riesgo sistémico, las pruebas adversariales son lo más cercano a un requisito obligatorio de red-teaming que llega a establecer el Reglamento. Los códigos de buenas prácticas que se están elaborando con arreglo al Artículo 56 darán contenido operativo a las «pruebas adversariales» para los modelos GPAI — pero, incluso antes de su finalización, el Artículo 55 obliga a los proveedores de GPAI con riesgo sistémico a realizar una evaluación estructurada frente a condiciones adversariales. Estas obligaciones se aplican desde el 2 de agosto de 2025.
El requisito del Artículo 55 es expresamente para el proveedor del modelo — la entidad que entrena e introduce el modelo GPAI en el mercado. No se extiende como obligación del Artículo 55 a las organizaciones que construyen aplicaciones sobre modelos GPAI. Esas organizaciones pueden, no obstante, realizar red-teaming como práctica con arreglo a su propio SGR del Artículo 9 o a sus obligaciones de robustez del Artículo 15, pero no están sujetas al Artículo 55.
Qué cubre el red-teaming en la práctica
Un ejercicio de red team bien delimitado para un sistema de IA suele cubrir varias categorías diferenciadas de modos de fallo.
Seguridad y provocación de perjuicios. Intentar que el sistema produzca resultados que está diseñado para no producir — instrucciones perjudiciales, contenido discriminatorio, asesoramiento médico o jurídico engañoso. Para los sistemas de cara al público, esta es con frecuencia la categoría de máxima prioridad.
Inyección de instrucciones y seguimiento de instrucciones. Para los sistemas que aceptan entradas de texto no estructurado (componentes de modelos de lenguaje, chatbots, herramientas de procesamiento de documentos), la inyección de instrucciones intenta anular las instrucciones del sistema mediante texto suministrado por el usuario. Un agente que pueda ser manipulado para ignorar sus instrucciones de seguridad a través de un documento manipulado que lea es un riesgo significativo en los despliegues profesionales.
Sesgo y fallos distribucionales. Sondear el rendimiento en subgrupos de población, entradas en casos límite y entradas que difieren de la distribución de entrenamiento. Para los sistemas de IA de alto riesgo en contextos de empleo, crédito o garantía del cumplimiento del Derecho, el rendimiento diferencial entre grupos protegidos es una exposición jurídica tanto con arreglo a la Ley de IA de la UE (condiciones de clasificación del Anexo III) como al Derecho antidiscriminatorio de la UE.
Robustez adversarial. Probar si los resultados del sistema pueden manipularse mediante perturbaciones pequeñas y deliberadas de los datos de entrada — pertinente principalmente para los sistemas de visión por computador y de procesamiento de audio, pero cada vez más pertinente también para los componentes de modelos de lenguaje.
Fuga de datos y ataques a la privacidad. Sondear si el sistema revela inadvertidamente datos de entrenamiento, datos de usuario de otras sesiones o información protegida en sus resultados. Esto se solapa con las obligaciones del RGPD para los sistemas que tratan datos personales.
Deriva del comportamiento bajo desplazamiento de la distribución. Probar el comportamiento del sistema con entradas que son plausibles en el despliegue pero están infrarrepresentadas en el conjunto de evaluación. Un modelo de calificación crediticia evaluado sobre un conjunto de datos histórico puede comportarse de forma inesperada con poblaciones cuyos perfiles financieros difieren de la población de entrenamiento.
Quién debe realizar el red-teaming
La credibilidad de un ejercicio de red team depende en parte de quién lo realiza. Los equipos internos se benefician del conocimiento del dominio pero están sujetos al sesgo de confirmación y pueden evitar inconscientemente escenarios que pongan en cuestión las hipótesis de diseño. Los equipos rojos externos — empresas de seguridad especializadas, investigadores académicos, expertos en el dominio no familiarizados con las interioridades del sistema — sacan a la luz modos de fallo que los equipos internos pasan por alto precisamente porque no comparten el mismo modelo mental de lo que se supone que debe hacer el sistema.
Para los sistemas de alto riesgo sujetos a la evaluación de la conformidad del Artículo 43, la documentación de robustez y exactitud (Artículo 11 / Anexo IV, sección que cubre el Artículo 15) será examinada por la autoridad de vigilancia del mercado o, para los sistemas biométricos del Anexo III, punto 1, por un organismo notificado. Un informe de red team externo proporciona pruebas independientes de las pruebas adversariales que una autoevaluación interna autogenerada no puede aportar.
Para los proveedores de GPAI con riesgo sistémico sujetos al Artículo 55, la Oficina de IA puede solicitar acceso a los resultados de la evaluación del modelo. Se espera que el código de buenas prácticas para GPAI que se está elaborando con arreglo al Artículo 56 especifique las metodologías de pruebas adversariales y las normas de documentación.
Una estructura práctica para la mayoría de las organizaciones:
- Ejercicios de red team internos en un ciclo continuo para la concienciación operativa y la retroalimentación de la iteración.
- Contratación de un red team externo antes de los lanzamientos importantes, de los despliegues de nuevos casos de uso o en la fase de evaluación de la conformidad.
- Un programa estructurado de recompensas por errores (bug bounty) o de divulgación por investigadores para los sistemas desplegados de cara al público, que proporciona una cobertura externa continua a un coste menor que las contrataciones periódicas.
Documentar los resultados del red team a efectos de cumplimiento
Un ejercicio de red team que no se documenta no existe a efectos de cumplimiento. La documentación técnica del Artículo 11 / Anexo IV exige a los proveedores describir las medidas adoptadas para identificar y mitigar los riesgos previsibles — lo que incluye los resultados de las pruebas adversariales y las mitigaciones que motivaron.
La documentación debe recoger:
- Alcance y metodología. Qué categorías de fallo se probaron, qué entradas se utilizaron y cómo se estructuró el ejercicio. Detalle suficiente para que un auditor pueda evaluar la cobertura del ejercicio.
- Hallazgos. Los modos de fallo identificados, clasificados por gravedad y probabilidad. Incluir las entradas o condiciones concretas que activaron cada hallazgo — depuradas cuando sea necesario para evitar el uso indebido, pero suficientemente específicas para demostrar que hubo pruebas reales.
- Mitigaciones. Lo que se hizo en respuesta a cada hallazgo: actualización del modelo, adición de una barrera de protección, filtro de salida, restricción operativa, o una aceptación documentada del riesgo residual con su justificación.
- Riesgos residuales. Los riesgos que persisten tras la mitigación, evaluados según el marco del SGR del Artículo 9. El proveedor debe valorar si los riesgos residuales son aceptables a la luz de la finalidad prevista y de los beneficios del sistema.
- Registro de iteraciones. Si el ejercicio motivó una actualización del modelo o un cambio de arquitectura, la documentación debe vincular el hallazgo con el cambio y con cualquier nueva prueba realizada.
Un proveedor que puede presentar esta documentación en una evaluación de la conformidad o en una inspección de vigilancia del mercado está demostrando un SGR del Artículo 9 funcional, no meramente uno de casillas marcadas.
El red-teaming no es una puerta de una sola vez
El malentendido más habitual sobre el red-teaming en contextos de cumplimiento de IA es tratarlo como una puerta previa al despliegue — algo que se hace una vez, se documenta y se cierra. Ese encuadre no se ajusta a los requisitos del Reglamento.
El Artículo 9 exige que el sistema de gestión de riesgos se actualice a la luz de la nueva información a lo largo de todo el ciclo de vida del sistema de IA. El Artículo 72 exige a los proveedores recopilar activamente datos de rendimiento poscomercialización y utilizarlos para actualizar las evaluaciones de riesgos. El Artículo 73 exige la notificación cuando surgen incidentes que alcanzan el umbral de incidente grave del Artículo 3, apartado 49.
Un ejercicio de red team realizado una sola vez en el lanzamiento y nunca repetido pasará por alto los modos de fallo que emergen a medida que: el uso del modelo se amplía a nuevas poblaciones o casos de uso; los actores adversariales desarrollan nuevos patrones de ataque; el proveedor del modelo GPAI subyacente lo actualiza; o el contexto de despliegue cambia de maneras que alteran el perfil de riesgo.
Para los sistemas de IA de alto riesgo, la cadencia adecuada es, como mínimo: un ejercicio acotado antes de cada actualización importante o despliegue de un nuevo caso de uso; un ejercicio más amplio con periodicidad anual; y ejercicios activados cuando la vigilancia poscomercialización o los datos de incidentes revelan un patrón de fallo inesperado.
Preguntas frecuentes
¿Es obligatorio el red-teaming conforme a la Ley de IA de la UE?
No por su nombre para la mayoría de los sistemas. El red-teaming es una práctica, no un término legal. No obstante, el requisito de gestión de riesgos del Artículo 9 para los proveedores de IA de alto riesgo exige de hecho pruebas adversariales como parte de un SGR creíble — el mandato de identificación de riesgos no puede satisfacerse con pruebas que solo confirman el comportamiento esperado. Para los proveedores de GPAI con riesgo sistémico, el Artículo 55 exige explícitamente pruebas adversariales como parte de la evaluación del modelo. La distinción: los proveedores de IA de alto riesgo tienen una obligación implícita de probar de forma adversarial; los proveedores de GPAI con riesgo sistémico tienen una explícita.
¿Cuál es la diferencia entre el Artículo 9 y el Artículo 15 a efectos del red-teaming?
El Artículo 9 exige que el sistema de gestión de riesgos identifique los riesgos previsibles — el red-teaming es una herramienta para esa identificación. El Artículo 15 exige que el sistema alcance robustez frente a los ataques adversariales y que declare sus límites de rendimiento — los resultados del red team evidencian directamente ese requisito. Ambos artículos respaldan los argumentos a favor del red-teaming; el Artículo 15 es donde el hallazgo de robustez adversarial aterriza en la documentación de cumplimiento.
¿Hace el Artículo 55 que el red-teaming sea obligatorio para todas las empresas de IA?
No. El Artículo 55 se aplica únicamente a los proveedores de modelos GPAI clasificados como de riesgo sistémico con arreglo al Artículo 51 — los entrenados por encima del umbral de 10²⁵ FLOP o designados por la Oficina de IA. No se aplica a las organizaciones que utilizan modelos GPAI para construir aplicaciones, ni a los proveedores de sistemas de IA que no son modelos GPAI. Esas organizaciones pueden realizar red-teaming con arreglo a sus obligaciones de los Artículos 9 y 15, pero no están sujetas al Artículo 55.
¿Cuándo empezaron a aplicarse las obligaciones del Artículo 55?
Las obligaciones de GPAI del Capítulo V, incluido el Artículo 55, se aplican desde el 2 de agosto de 2025. Los proveedores de modelos GPAI cuyos modelos ya estaban en el mercado antes de esa fecha tienen hasta el 2 de agosto de 2027 para lograr el cumplimiento.
¿Cómo deben documentarse los resultados del red team a efectos del Artículo 11?
La documentación técnica del Anexo IV debe describir las medidas adoptadas para identificar y mitigar los riesgos previsibles. Un informe de red team debe registrar el alcance y la metodología, los hallazgos concretos con su evaluación de gravedad, las mitigaciones implementadas en respuesta, cualquier riesgo residual aceptado y el registro de iteraciones que vincula los hallazgos con los cambios. Esta documentación es la base probatoria del SGR del Artículo 9 y de la declaración de exactitud y robustez del Artículo 15.
¿Qué sanciones se aplican por una gestión de riesgos inadecuada con arreglo al Artículo 9?
El incumplimiento del Artículo 9 entra en el Artículo 99, apartado 4: hasta 15 000 000 EUR o el 3 % del volumen de negocios anual mundial total, si esta última cifra es mayor. Para las pymes y las empresas emergentes, el Artículo 99, apartado 6, limita la multa al menor de los dos importes, el porcentaje o la cantidad fija. Las obligaciones de alto riesgo — incluido el Artículo 9 — se aplican a los sistemas autónomos del Anexo III a partir del 2 de diciembre de 2027 (en virtud del Ómnibus Digital acordado en mayo de 2026).
Guías relacionadas
- Artículo 9 de la Ley de IA de la UE: sistema de gestión de riesgos
- Artículo 15 de la Ley de IA de la UE: exactitud, robustez y ciberseguridad
- obligaciones de riesgo sistémico de la GPAI con arreglo al Artículo 55
- evaluación de riesgos de IA conforme a la Ley de IA de la UE
- estrategias de mitigación de riesgos de IA
- Artículo 11 de la Ley de IA de la UE: documentación técnica
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →