Artículo 15 de la Ley de IA de la UE: exactitud, robustez y ciberseguridad de la IA de alto riesgo

El Artículo 15 del Reglamento (UE) 2024/1689 exige que los sistemas de IA de alto riesgo se diseñen, desarrollen y prueben para alcanzar niveles adecuados de exactitud, robustez y ciberseguridad — y que la conformidad se mantenga a lo largo de todo el ciclo de vida del sistema, no solo en el momento de entrada en el mercado. La obligación recae principalmente sobre los proveedores (quienes introducen IA de alto riesgo en el mercado de la UE bajo su propio nombre), y está respaldada por un techo sancionador de 15 millones de euros o el 3 % del volumen de negocios anual mundial, si esta última cifra es mayor, por el incumplimiento de los requisitos de alto riesgo.

Las obligaciones de alto riesgo para los sistemas autónomos del Anexo III se aplican a partir del 2 de diciembre de 2027 en virtud del acuerdo político del Ómnibus Digital de mayo de 2026 — aplazadas respecto de la fecha original del 2 de agosto de 2026. Esa prórroga es un respiro, no un indulto. El trabajo de pruebas, documentación y vigilancia que exige el Artículo 15 lleva más tiempo del que la mayoría de los equipos prevé, y los sistemas subyacentes a menudo necesitan cambios arquitectónicos antes de poder cumplir el planteamiento de ciclo de vida.

Esta guía abarca el texto legal que sustenta cada pilar del Artículo 15, qué deben hacer de forma diferente los proveedores y los responsables del despliegue, las categorías de ataque concretas que los reguladores esperan que aborde y las cinco lagunas de cumplimiento que aparecen con más frecuencia en la práctica.

---

Qué dice realmente el Artículo 15

Artículo 15, apartado 1: la línea de base del ciclo de vida

El Artículo 15, apartado 1, establece el requisito fundamental: los sistemas de IA de alto riesgo deben diseñarse y desarrollarse de modo que alcancen un nivel adecuado de exactitud, robustez y ciberseguridad, y rindan de forma constante en esos aspectos a lo largo de todo su ciclo de vida. El planteamiento de ciclo de vida no es decorativo. Significa que las pruebas previas a la comercialización son necesarias, pero no suficientes — la vigilancia posterior al despliegue, la respuesta a la deriva y la aplicación de parches de seguridad forman parte de lo que exige el Artículo 15, apartado 1.

El nivel adecuado se calibra en función de la finalidad prevista y el contexto de riesgo. La Ley no prescribe mínimos universales (en ninguna parte del Artículo 15 aparece una «exactitud mínima del 95 %»). Un sistema de alto riesgo que criba a candidatos a un empleo afronta exigencias de exactitud distintas de uno que puntúa la solvencia, y ambos afrontan exigencias distintas de las de una herramienta de evaluación de riesgos para la garantía del cumplimiento del Derecho.

Artículo 15, apartado 2: puntos de referencia y metodologías de medición

El Artículo 15, apartado 2, encomienda a la Comisión, en cooperación con la Oficina de IA y los organismos pertinentes, fomentar el desarrollo de puntos de referencia y metodologías de medición de la exactitud y la robustez de los sistemas de IA de alto riesgo. Se trata de un mandato institucional a la Comisión, no de una obligación directa para los proveedores. En la práctica, significa que es probable que surjan normas de prueba armonizadas para ámbitos concretos del Anexo III — calificación crediticia, imagen médica, cribado de candidatos, identificación biométrica — a medida que la Ley madure. Cuando ya existan puntos de referencia sectoriales reconocidos (ISO/IEC 29003 para biometría, métricas NIST AI 100-1 para reconocimiento facial), los proveedores deben utilizarlos y documentar la elección en el Anexo IV.

Artículo 15, apartado 3: los requisitos detallados

El Artículo 15, apartado 3, es donde residen las obligaciones sustantivas. Abarca tres áreas:

Robustez: el sistema debe ser resiliente frente a errores, fallos e incoherencias — incluidos los derivados de la interacción con personas físicas u otros sistemas de IA. Cuando sea técnicamente factible, los proveedores deben lograrlo mediante soluciones de redundancia técnica, incluidos planes de respaldo o a prueba de fallos.

Bucles de retroalimentación: los sistemas que siguen aprendiendo tras el despliegue deben desarrollarse para eliminar o reducir, en la medida de lo posible, el riesgo de que resultados posiblemente sesgados influyan en futuras entradas. Las medidas de mitigación de estos bucles deben documentarse.

Ciberseguridad: el sistema debe ser resiliente frente a los intentos de terceros no autorizados de alterar su uso, sus resultados o su rendimiento mediante la explotación de vulnerabilidades. Los proveedores deben implantar medidas para prevenir, detectar, responder, resolver y controlar los ataques. La Ley nombra categorías de ataque concretas: envenenamiento de datos, envenenamiento del modelo durante el entrenamiento, ejemplos adversarios / evasión del modelo dirigidos a las entradas, ataques a la confidencialidad y defectos del modelo. Las soluciones deben ser adecuadas a las circunstancias y los riesgos.

Los niveles de exactitud y las métricas de exactitud pertinentes deben declararse en las instrucciones de uso que acompañan al sistema en virtud del Artículo 13. Esta remisión cruzada es material — los responsables del despliegue se basan en esas métricas declaradas para fijar los umbrales de vigilancia en producción.

---

Exactitud: declarar y medir el rendimiento

La exactitud, con arreglo al Artículo 15, apartado 1, significa que el sistema realiza correctamente su finalidad declarada, de forma fiable y constante, en condiciones normales y razonablemente previsibles. La Ley exige que la exactitud sea adecuada a la finalidad prevista y se declare en las instrucciones de uso. Lo que eso significa en la práctica depende enteramente del caso de uso.

Para una herramienta de cribado de selección de personal en una empresa de tecnología de RR. HH. de 40 personas, la exactitud podría significar que no haya una diferencia de rendimiento estadísticamente significativa — pongamos que de más de cinco puntos porcentuales — entre grupos demográficos protegidos en una cohorte de prueba representativa. Para un modelo de calificación crediticia en una entidad de crédito regional, podría significar un error absoluto medio dentro de una banda monetaria definida, comunicado por separado para distintos segmentos de solicitantes. Para un clasificador de imagen médica, podría significar una sensibilidad del 95 % y una especificidad del 92 % en tomografías computarizadas extraídas del abanico demográfico que el sistema encontrará realmente. El proveedor define qué significa «adecuado», lo documenta y lo demuestra mediante pruebas.

Elegir y justificar las métricas

La exactitud global enmascara los modos de fallo. Un modelo de detección de fraude que comunica un 94 % de exactitud puede seguir marcando a un grupo demográfico minoritario a un ritmo tres veces superior al del grupo mayoritario — y esa asimetría es lo que preguntará un auditor. El Anexo IV, sección 5 (Métricas de rendimiento), exige a los proveedores que enumeren todas las métricas, los umbrales y la justificación de cada uno, incluidos los intervalos de confianza o los límites de error cuando proceda.

La selección de métricas depende de la tarea:

Una única métrica sin contexto — «92 % de exactitud» sin especificar el tipo de métrica, el conjunto de prueba o el desglose por subgrupos — no satisfará a un organismo notificado ni a una autoridad de vigilancia del mercado. El Anexo IV, sección 5, exige el panorama completo.

Conjuntos de datos representativos y estratificación

La prueba sobre un conjunto de datos depurado u homogéneo oculta el rendimiento en el mundo real. El Anexo IV, sección 6 (Procedimientos de prueba y validación), exige documentar el tamaño, la fuente y la representatividad del conjunto de datos de prueba, así como resultados estratificados por grupo demográfico, geografía u otras subpoblaciones pertinentes. Una IA de contratación de alto riesgo probada únicamente con candidatos de un Estado miembro de la UE no cumplirá este requisito cuando se despliegue en la diversidad lingüística y demográfica de toda la UE.

Los errores habituales aquí incluyen: extraer el conjunto de prueba de la misma fuente que el conjunto de entrenamiento (lo que introduce una fuga de distribución), no estratificar explícitamente por características protegidas y tratar los datos sintéticos como un sustituto de muestras representativas del mundo real sin documentar las limitaciones.

La deriva de la exactitud es una obligación de ciclo de vida

La exactitud declarada en la entrada al mercado puede deteriorarse en silencio. La deriva de datos se produce cuando la distribución de las entradas se aleja de los datos de entrenamiento — cambia la demografía de los solicitantes, las condiciones económicas alteran los patrones de fraude, las poblaciones de pacientes de una clínica se amplían. La deriva de concepto se produce cuando cambia la relación entre las entradas y el resultado objetivo: los criterios de contratación evolucionan, las definiciones reglamentarias varían, el significado de un «solicitante de alto riesgo» en la calificación crediticia cambia con las condiciones macroeconómicas.

Ambas son previsibles, y el requisito de ciclo de vida del Artículo 15, apartado 1, abarca ambas. Los responsables del despliegue deben establecer umbrales de vigilancia — por ejemplo, «la exactitud debe mantenerse por encima del 88 % en una ventana móvil de 30 días; si cae por debajo, se activa una revisión en un plazo de cinco días hábiles» — y documentar la cadencia y el rol responsable en el Anexo IV, sección 9. El Artículo 72, que rige la vigilancia poscomercialización por parte de los proveedores, y el Artículo 26, que establece las obligaciones del responsable del despliegue de seguir las instrucciones de uso, hacen conjuntamente obligatoria la supervisión continua del rendimiento. Una afirmación de exactitud estática de 2025 no satisface una auditoría de 2027.

---

Robustez: resiliencia a lo largo del ciclo de vida

La robustez es la capacidad de mantener el rendimiento cuando el sistema se expone a errores, fallos, incoherencias, entradas adversarias o cambios del entorno. El Artículo 15, apartado 3, identifica los requisitos concretos.

Resiliencia frente a errores, fallos e incoherencias

El sistema debe gestionar las entradas degradadas sin un fallo catastrófico. Campos ausentes, valores corruptos, lecturas de sensores fuera de rango, incoherencias derivadas de la interacción con personas físicas u otros sistemas de IA — todo esto es previsible en producción. Las soluciones técnicas incluyen la validación de entradas (cumplimiento de esquemas, comprobaciones de rango, verificación de tipos antes de que la entrada llegue al modelo), la detección de anomalías que deriva los casos inciertos a revisión humana y los mecanismos a prueba de fallos que detienen la inferencia y activan una alternativa segura cuando las entradas quedan fuera del entorno operativo.

Cuando una solución a prueba de fallos o de redundancia no sea técnicamente factible, el proveedor debe documentar por qué y compensarlo mediante otros controles. El Artículo 15, apartado 3, utiliza «cuando sea técnicamente factible» específicamente para el requisito de redundancia — no es una escapatoria general de la obligación de robustez.

Entradas adversarias y las categorías de ataque nombradas

El Artículo 15, apartado 3, abarca explícitamente los intentos de alterar los resultados del sistema mediante entradas manipuladas y la explotación de seguridad identificada. La Ley nombra categorías de ataque concretas:

Ejemplos adversarios / evasión del modelo: entradas manipuladas para provocar una clasificación errónea — perturbaciones a nivel de píxel en clasificadores de imágenes, sustituciones de sinónimos en modelos de texto, consultas límite diseñadas para desencadenar resultados incorrectos. El ataque no requiere acceso al modelo; los ataques de evasión de caja negra están bien documentados contra sistemas comerciales.

Envenenamiento de datos durante el entrenamiento: muestras maliciosas inyectadas en los datos de entrenamiento o de ajuste fino para degradar o sesgar los resultados del modelo. En una IA de selección de personal, esto significa ejemplos mal etiquetados que desplazan las recomendaciones de contratación del modelo; en un modelo de calificación crediticia, significa registros históricos falsificados que alteran las ponderaciones de riesgo. La procedencia y la integridad de los datos son la defensa principal.

Envenenamiento del modelo: manipulación directa de las ponderaciones o los parámetros del modelo — sustitución de archivos de punto de control, modificación de los artefactos del modelo desplegado. Los controles de acceso al almacenamiento del modelo y los artefactos de despliegue inmutables son las mitigaciones clave.

Ejemplos adversarios dirigidos a las entradas / evasión del modelo: se solapa con lo anterior, pero aborda específicamente la superficie de ataque en tiempo de inferencia, en la que un atacante envía consultas cuidadosamente manipuladas para hacer que el modelo clasifique mal o produzca decisiones incorrectas.

Ataques a la confidencialidad: inferencia de pertenencia (sondear si un individuo concreto figuraba en el conjunto de entrenamiento) y extracción del modelo (utilizar consultas de inferencia de alto volumen para reproducir el modelo). Estos atacan tanto la privacidad como la propiedad intelectual.

Defectos del modelo: errores sistemáticos en la lógica de decisión que pueden desencadenarse mediante patrones de entrada concretos — no adversarios en el sentido tradicional, pero explotables.

Las pruebas deben incluir campañas de perturbación adversaria, no solo puntos de referencia con datos limpios. Para una IA de selección de personal, esto significa ejecutar intentos de inyección de instrucciones contra los campos de texto libre y evaluar si el resultado clasificado se desplaza. Para un clasificador médico basado en imágenes, significa aplicar perturbaciones FGSM o PGD y documentar la curva de degradación. El alcance y la profundidad de las pruebas adversarias escalan con el nivel de riesgo y el contexto de despliegue — un sistema que procesa miles de decisiones de empleo al día afronta un modelo de amenazas adversarias mayor que uno utilizado en un flujo de trabajo interno de bajo volumen.

Redundancia técnica y planes a prueba de fallos

Cuando sea técnicamente factible, el Artículo 15, apartado 3, exige a los proveedores lograr la robustez mediante redundancia técnica: sistemas de respaldo, mecanismos a prueba de fallos que deriven los casos inciertos a un revisor humano o disyuntores que detengan la inferencia cuando la confianza caiga por debajo de un umbral definido. Estas soluciones deben documentarse en el Anexo IV y vincularse al plan de gestión de riesgos del Artículo 9 — los controles de robustez no son decisiones de ingeniería aisladas, son mitigaciones de riesgo que deben asignarse explícitamente a los riesgos detectados.

Bucles de retroalimentación en sistemas que siguen aprendiendo

Todo sistema de alto riesgo que siga aprendiendo tras el despliegue — un modelo que se reentrena con los resultados de producción, un motor de recomendación que actualiza ponderaciones en función de las interacciones de los usuarios — debe desarrollarse para eliminar o reducir, en la medida de lo posible, el riesgo de que los resultados sesgados influyan en futuras entradas. Esta es la disposición sobre bucles de retroalimentación del Artículo 15, apartado 3.

El riesgo es concreto. Un modelo de contratación que se reentrena con decisiones de contratación históricas amplificará cualquier patrón demográfico que exista en esas decisiones. Un modelo de calificación crediticia que se actualiza con los resultados de reembolso reforzará los patrones de concesión de crédito que ya reflejan una discriminación histórica. El bucle de retroalimentación no es hipotético; es el modo de fallo documentado de varios sistemas de aprendizaje automático desplegados.

Las medidas de mitigación incluyen: auditorías de sesgo periódicas ejecutadas antes de cualquier ciclo de reentrenamiento, controles de ponderación de entradas que limiten la influencia de los resultados generados por el modelo en el conjunto de datos de reentrenamiento, conjuntos de validación reservados extraídos con independencia de los resultados de producción recientes y compuertas de revisión humana antes de que los modelos reentrenados entren en funcionamiento. Estas medidas — y la prueba de que funcionan según lo previsto — pertenecen a las secciones 6 y 9 del Anexo IV.

---

Ciberseguridad: protección frente a la explotación específica de la IA

La ciberseguridad con arreglo al Artículo 15, apartado 3, no es la seguridad informática general aplicada a un sistema de IA. Trata específicamente de la resiliencia frente a los intentos de terceros no autorizados de alterar el uso, los resultados o el rendimiento del sistema mediante la explotación de vulnerabilidades del propio sistema de IA. La superficie de ataque es distinta de la del software convencional, y los controles deben abordarla explícitamente.

La superficie de ataque específica de la IA

Medidas técnicas fundamentales

Los proveedores deben documentar los controles en cuatro ámbitos en el Anexo IV, sección 8:

• Cifrado: datos en reposo (ponderaciones del modelo, conjuntos de datos de entrenamiento, registros de inferencia) y en tránsito; procedimientos de gestión de claves y cadencia de rotación de claves.
• Control de acceso: autenticación multifactor en todos los sistemas que tocan las ponderaciones del modelo y los datos de entrenamiento; acceso basado en roles con aplicación del mínimo privilegio; credenciales separadas para los entornos de entrenamiento, evaluación e inferencia.
• Registro de auditoría: registros inmutables de todos los accesos al modelo, los cambios de configuración y las consultas de datos; período de conservación definido; acceso a los registros restringido a roles autorizados.
• Gestión de vulnerabilidades: pruebas de penetración con una cadencia definida; plazos de aplicación de parches para vulnerabilidades críticas; análisis de dependencias para las bibliotecas aguas arriba y los modelos preentrenados utilizados como componentes.

En el Anexo IV, sección 8, también debe figurar un plan de respuesta a incidentes: a quién se notifica cuando se detecta un incidente de seguridad que afecta al sistema de IA, en qué plazos, quién toma la decisión de suspender el sistema y cómo notifica el proveedor a los responsables del despliegue y (cuando proceda) a las autoridades de vigilancia del mercado.

Medidas adecuadas a las circunstancias y los riesgos

El Artículo 15, apartado 3, matiza el requisito de ciberseguridad con «soluciones adecuadas a las circunstancias y los riesgos». Una pequeña empresa de tecnología de RR. HH. que comercializa una herramienta de cribado de currículos afronta un modelo de amenazas distinto del de una entidad financiera que ejecuta un modelo de calificación crediticia para préstamos minoristas. La primera necesita controles de acceso rigurosos y documentación de la procedencia de los datos; la segunda puede afrontar un interés adversario activo y necesita pruebas de penetración por un tercero cualificado, defensas documentadas contra la extracción del modelo y un procedimiento formal de respuesta a incidentes.

Para las empresas sin experiencia en seguridad interna, una prueba de penetración por un tercero cualificado suele costar entre 3000 y 8000 EUR para una aplicación SaaS de alto riesgo. Para los sistemas médicos o críticos para la seguridad que requieren la intervención de un organismo notificado en virtud del Artículo 43, la propia evaluación de la conformidad abarca la revisión de ciberseguridad.

Relación con NIS2 e ISO 27001

Los requisitos de ciberseguridad del Artículo 15 se solapan deliberadamente con la Directiva NIS2 (Directiva (UE) 2022/2555), que se aplica a los operadores de servicios esenciales y de infraestructura digital — varias categorías de alto riesgo del Anexo III entran en el ámbito de NIS2, incluidas las infraestructuras críticas (categoría 2) y los servicios esenciales como la sanidad y la banca (categoría 5). Si su organización ya está obligada por NIS2, su marco de gestión de seguridad existente aborda muchos de los requisitos del Anexo IV, sección 8. La certificación ISO 27001 proporciona una sólida línea de base.

Ni NIS2 ni ISO 27001, sin embargo, abarcan los vectores de ataque específicos de la IA: envenenamiento de datos, envenenamiento del modelo, extracción del modelo, ejemplos adversarios, inferencia de pertenencia. Esas lagunas deben abordarse explícitamente en su documentación del Artículo 15. No puede señalar un certificado ISO 27001 y declarar satisfecha la ciberseguridad del Artículo 15.

Integración con la gestión de riesgos del Artículo 9

Los controles de ciberseguridad deben integrarse en el sistema de gestión de riesgos del Artículo 9. El plan de gestión de riesgos debe identificar los riesgos de ciberseguridad específicos de la IA, evaluar su probabilidad y gravedad, documentar los controles adoptados para mitigarlos y definir desencadenantes de vigilancia y reevaluación — por ejemplo, una nueva clase de ataque adversario publicada en la literatura de investigación, o un informe de incidente poscomercialización de otro responsable del despliegue del mismo sistema. El Artículo 9 exige que este proceso sea iterativo y esté documentado a lo largo de todo el ciclo de vida, no que se complete una sola vez en el lanzamiento.

---

Responsabilidades del proveedor y del responsable del despliegue

El Artículo 15 sitúa las obligaciones de diseño y prueba previas a la comercialización sobre los proveedores. El Artículo 26 exige a los responsables del despliegue que utilicen los sistemas de alto riesgo de conformidad con las instrucciones de uso — lo que incluye la vigilancia frente a los niveles de exactitud y las métricas que los proveedores declaran en virtud de los Artículos 15 y 13.

Qué deben hacer los proveedores antes de la entrada en el mercado

• Diseñar y validar la exactitud, la robustez y la ciberseguridad adecuadas a la finalidad prevista.
• Declarar los niveles de exactitud y las métricas pertinentes en las instrucciones de uso (Artículos 13 y 15, apartado 3).
• Completar el Anexo IV, secciones 5 a 8: métricas de rendimiento, procedimientos de prueba y validación, plan de vigilancia poscomercialización y medidas de seguridad.
• Para los sistemas que siguen aprendiendo tras el despliegue: documentar las medidas de mitigación de los bucles de retroalimentación en el Anexo IV, secciones 6 y 9.
• Emitir la Declaración de conformidad del Artículo 47 (Anexo V) antes de introducir el sistema en el mercado.
• Conservar la documentación técnica durante al menos diez años desde la entrada en el mercado (Artículo 18).

Qué deben hacer los responsables del despliegue en producción

• Verificar antes del despliegue que las propiedades de rendimiento declaradas del sistema se mantienen en su contexto operativo específico, su entorno de datos y su población de usuarios. Un sistema exacto en el conjunto de prueba del proveedor puede derivar al desplegarse en una población geográfica o demográfica distinta.
• Establecer KPI de vigilancia con umbrales definidos y un rol responsable nombrado.
• Detectar e investigar la deriva de la exactitud o los incidentes de seguridad.
• Notificar los incidentes graves a la autoridad de vigilancia del mercado pertinente en virtud del Artículo 73, en un plazo de 15 días cuando se haya producido un daño o sea probable que se produzca.
• Conservar los registros de vigilancia durante al menos tres años en virtud del Artículo 72.

La trampa de la modificación: cuándo los responsables del despliegue pasan a ser proveedores

Un responsable del despliegue que reentrena el modelo con nuevos datos, cambia el preprocesamiento de las entradas o altera el límite de decisión de un modo que afecta al rendimiento o a la finalidad prevista ha realizado una modificación sustancial en virtud del Artículo 3, apartado 23. Ese cambio activa las obligaciones plenas del proveedor: nueva documentación técnica, nuevas pruebas de robustez y ciberseguridad, una nueva evaluación de la conformidad en virtud del Artículo 43 cuando proceda y una nueva Declaración de conformidad. Esta es la trampa de cumplimiento del Artículo 15 más habitual en la práctica.

Los equipos reentrenan un modelo de alto riesgo para mejorar el rendimiento en su población de solicitantes específica y luego dan por hecho que la Declaración de conformidad del proveedor original sigue cubriéndolos. No lo hace. La modificación activa la condición de proveedor para la versión modificada en virtud del Artículo 25, con todas las obligaciones del Artículo 16 que de ello se derivan.

Matriz de responsabilidad

Ejemplo práctico: una empresa de tecnología de RR. HH. de 35 personas

Una pequeña empresa de tecnología de RR. HH. desarrolla una herramienta de cribado de currículos que clasifica a los candidatos por una puntuación de idoneidad para el puesto destinada a los flujos de trabajo de contratación de sus clientes. La herramienta es de alto riesgo con arreglo a la categoría 4 del Anexo III (empleo; gestión de los trabajadores; acceso al autoempleo).

Como proveedor, la empresa debe: seleccionar métricas de exactitud que capten el rendimiento por grupo demográfico (F1 equilibrado entre grupos de sexo, edad y origen étnico; sin ninguna brecha por subgrupo superior a cinco puntos porcentuales); ejecutar pruebas adversarias, incluidos intentos de inyección de instrucciones en los campos de texto libre de los currículos; documentar los controles de procedencia e integridad de los datos sobre su canalización de entrenamiento (defensa contra el envenenamiento de datos); especificar el comportamiento a prueba de fallos cuando la confianza esté por debajo del umbral (derivar a un revisor humano); declarar todo ello en las instrucciones de uso; y completar la documentación técnica del Anexo IV y la Declaración de conformidad antes de la entrada en el mercado.

Sus clientes responsables del despliegue — los departamentos de RR. HH. que integran la herramienta — deben vigilar la exactitud en su propio grupo de solicitantes, no solo frente a los puntos de referencia del proveedor. Si un responsable del despliegue observa que la exactitud en su población específica es de forma constante cinco puntos porcentuales inferior a la declarada, debe investigarlo y notificarlo al proveedor. Si el responsable del despliegue reentrena el modelo con sus propios datos históricos de contratación para intentar cerrar esa brecha, pasa a ser proveedor de esa versión reentrenada y debe elaborar su propia documentación técnica y su Declaración de conformidad.

---

Cómo construir el registro de pruebas del Artículo 15: qué va en el Anexo IV

El Artículo 15 no opera de forma aislada — su resultado es un conjunto de artefactos probatorios que deben figurar en la documentación técnica del Artículo 11 (estructurada según el Anexo IV) y que sustentan la Declaración de conformidad del Artículo 47. Acertar con la estructura importa: un organismo notificado o una autoridad de vigilancia del mercado cotejarán el Anexo IV, secciones 5 a 8, directamente con los requisitos del Artículo 15.

Anexo IV, sección 5: Métricas de rendimiento

Esta sección debe especificar:

• Cada métrica de exactitud utilizada, con la justificación de elegirla frente a las alternativas. Un modelo de clasificación binaria podría comunicar precisión, exhaustividad y F1 — pero la documentación debe explicar por qué se eligió F1 como métrica principal (equilibrio de clases, coste de los falsos negativos frente a los falsos positivos) en lugar de la exactitud por sí sola.
• Los umbrales objetivo de cada métrica, con intervalos de confianza cuando sea factible. «Exhaustividad ≥ 0,90 con un 95 % de confianza en un conjunto de prueba de 10 000 muestras» es conforme. «La exhaustividad es generalmente alta» no lo es.
• El rendimiento por subgrupo, desglosado al menos por las características protegidas pertinentes al contexto de despliegue. Para una IA de empleo, eso significa sexo, grupo de edad y cualquier desglose por origen étnico posible dados los datos de prueba. Para un modelo de calificación crediticia, significa tramo de ingresos, geografía y cualquier proxy demográfico utilizado en el modelo.
• Métricas de exactitud para la robustez: la curva de degradación bajo perturbación adversaria (p. ej., F1 con una intensidad de perturbación de 0,01, 0,05, 0,1), el rendimiento sobre muestras fuera de distribución y — para los sistemas que siguen aprendiendo — la métrica de sesgo antes y después del primer ciclo de reentrenamiento.

Anexo IV, sección 6: Procedimientos de prueba y validación

Esta sección documenta cómo se generaron las cifras de la sección 5. Debe incluir:

• Descripción del conjunto de datos de prueba: tamaño, fuente, período de recopilación, cualquier limitación conocida. Un conjunto de prueba de menos de 500 muestras para un sistema que toma decisiones de empleo individuales suscitará escrutinio. Tamaños de muestra de más de 5000 para tareas de clasificación binaria, con al menos 200 muestras en cada subgrupo minoritario, son defendibles.
• Metodología de las pruebas adversarias: qué métodos de ataque se aplicaron (p. ej., FGSM con ε = 0,03 para perturbaciones de imágenes; inyección de instrucciones basada en plantillas para entradas de texto libre), los criterios de aprobado/suspenso y los resultados. Para una IA de selección de personal sin componente de imagen, el alcance de las pruebas adversarias podría limitarse a la inyección de instrucciones y al «fuzzing» del esquema de entrada — eso es aceptable si la limitación del alcance se documenta y justifica.
• Para los sistemas entrenados con datos personales: documentación de los controles contra el envenenamiento de datos en la canalización de entrenamiento — cómo se validaron los datos de entrenamiento, si se comprobó la procedencia de los datos y qué controles de acceso protegieron el conjunto de entrenamiento.
• Si se utilizaron datos sintéticos para aumentar el conjunto de prueba: la metodología de generación, sus diferencias distribucionales conocidas respecto de los datos del mundo real y qué significa esto para la interpretación de las métricas comunicadas.

Anexo IV, sección 7: Plan de vigilancia poscomercialización

La vigilancia poscomercialización se especifica en el Artículo 72, pero el plan en sí se documenta aquí. Debe identificar:

• Qué KPI de exactitud y robustez se controlarán en producción, con umbrales definidos que activen una revisión.
• La cadencia de vigilancia — semanal para sistemas de empleo o calificación crediticia de alto rendimiento; mensual para despliegues de menor volumen — y la herramienta o el proceso utilizado para recopilar las métricas de producción.
• El rol responsable y la vía de escalado. No «el equipo de operaciones» — un rol nombrado con un suplente nombrado.
• El desencadenante de reentrenamiento: qué combinación de magnitud de deriva y ventana temporal activa una propuesta de reentrenamiento, quién la aprueba y qué compuerta de validación debe superarse antes de que el modelo reentrenado sustituya a la versión en producción.
• El procedimiento de notificación de incidentes graves del Artículo 73: qué cuenta como incidente grave (daño inesperado, fallo significativo de exactitud que afecte a los derechos de una persona), quién presenta el informe y el plazo de notificación de 15 días.

Anexo IV, sección 8: Medidas de ciberseguridad

Esta sección es donde reside el modelo de amenazas específico de la IA. Debe documentar:

• El modelo de amenazas: cada vector de ataque evaluado, su probabilidad dado el contexto de despliegue, el impacto potencial y las medidas de control adoptadas. Una fila de plantilla: «Envenenamiento de datos — Probabilidad media (datos de entrenamiento procedentes de proveedores externos); Impacto alto (sesgo del modelo que afecta a las decisiones de contratación); Control: lista de comprobación de validación de datos de terceros + verificación de hash SHA-256 del conjunto de datos de entrenamiento antes de cada ciclo de entrenamiento».
• Los controles técnicos implantados, con suficiente especificidad para que un auditor verifique la implementación: normas de cifrado y gestión de claves, arquitectura de control de acceso con definiciones de roles, alcance y conservación del registro de auditoría, herramientas y cadencia de análisis de dependencias.
• Pruebas de penetración: quién las realizó (interno o tercero), la fecha, el alcance (API del modelo, infraestructura de entrenamiento, punto final de inferencia), los hallazgos y el estado de subsanación de cualquier hallazgo.
• El plan de respuesta a incidentes: detección (qué vigilancia alerta de un posible ataque), contención (quién está autorizado a suspender la inferencia), investigación (quién realiza la revisión posterior al incidente), notificación (a qué autoridades y responsables del despliegue se informa, en qué plazos) y recuperación (qué pruebas se conservan antes de restaurar los sistemas).

Mantener la documentación actualizada

El Anexo IV no es un artefacto puntual. Cada vez que el sistema se modifique de forma material — se reentrene, se redesplegue en un nuevo entorno, se actualice con una nueva versión del modelo —, la documentación debe revisarse. Las secciones que cambien deben actualizarse y marcarse con la versión. La Declaración de conformidad remite a la versión del Anexo IV; si el Anexo IV cambia sustancialmente sin reemitir la Declaración de conformidad, esta pasa a ser engañosa. Con arreglo al Artículo 3, apartado 23, todo cambio que afecte a la finalidad prevista, al rendimiento o al perfil de riesgo del sistema es una modificación sustancial — lo que significa una nueva evaluación de la conformidad y una nueva Declaración de conformidad, no solo una actualización de la documentación.

Para los sistemas que siguen aprendiendo, esto significa que la cadencia de actualización del Anexo IV debe vincularse al ciclo de reentrenamiento. Antes de cada ciclo de reentrenamiento: comprobar si las mitigaciones de los bucles de retroalimentación siguen funcionando correctamente. Después de cada ciclo de reentrenamiento: actualizar las métricas de rendimiento de las secciones 5 y 6 con los resultados de prueba del nuevo modelo, y revisar si algún control de ciberseguridad de la sección 8 necesita ajustarse para los datos de entrenamiento actualizados.

---

Cinco lagunas habituales de cumplimiento del Artículo 15

Laguna 1: probar solo con datos limpios

Los proveedores validan la exactitud sobre un conjunto de prueba reservado de alta calidad y declaran la conformidad. El despliegue en el mundo real introduce poblaciones minoritarias, entradas corruptas, ejemplos fuera de distribución y consultas adversarias que nunca aparecieron en el punto de referencia. El Artículo 15, apartado 3, exige resiliencia frente a errores, fallos e incoherencias. Un modelo que alcanza un 95 % de exactitud en un punto de referencia depurado puede fallar al 30 % con entradas límite que el punto de referencia excluyó.

La solución: ampliar la matriz de pruebas para abarcar subgrupos minoritarios, muestras fuera de distribución, al menos una categoría de perturbación adversaria pertinente al contexto de despliegue y cualquier escenario de interacción del sistema (p. ej., entradas generadas por otro sistema de IA aguas arriba). Documentar todo esto en el Anexo IV, sección 6, incluidos los tamaños de muestra, los criterios de aprobado/suspenso y las limitaciones.

Laguna 2: declaración de exactitud estática sin vigilancia posterior al despliegue

Los proveedores comunican una única métrica en la entrada al mercado y dan por hecho un cumplimiento continuo. El Artículo 15, apartado 1, exige rendimiento a lo largo del ciclo de vida; el Artículo 72 obliga a un sistema de vigilancia poscomercialización con recopilación activa de datos. Una afirmación de exactitud estática no satisface ninguno de los dos. La solución: establecer un panel de vigilancia con KPI definidos — exactitud, indicadores de deriva, tasa de detección de ataques adversarios, anomalías de seguridad —, una cadencia de revisión, un rol responsable nombrado y un desencadenante documentado de escalado. Registrar esto en el Anexo IV, sección 9.

Laguna 3: revisión de seguridad informática sin análisis de amenazas específico de la IA

Los proveedores delegan las pruebas de robustez y seguridad en el equipo de TI o de seguridad de la información. Los controles de infraestructura — cortafuegos, cifrado, gestión de accesos — quedan cubiertos. Los vectores específicos de la IA — envenenamiento de datos, envenenamiento del modelo, ejemplos adversarios, inferencia de pertenencia, extracción del modelo — no figuran en el registro de riesgos de TI estándar y se pasan por alto. El Anexo IV, sección 8, está incompleto sin ellos. La solución: ejecutar una evaluación de riesgos conjunta entre TI y el equipo de desarrollo de IA; asignar cada amenaza específica de la IA a su probabilidad, impacto y mitigación; documentar el modelo de amenazas completo en el Anexo IV, sección 8.

Laguna 4: plan de vigilancia poscomercialización sin un responsable nombrado

Los proveedores documentan una cadencia de vigilancia en el Anexo IV, sección 9, pero se la asignan a «el equipo de cumplimiento» en lugar de a un rol nombrado con responsabilidades explícitas. Cuando se produce una deriva o surge un incidente grave, nadie es responsable del escalado. El Artículo 73 exige la notificación en un plazo de 15 días desde el descubrimiento de un incidente grave. Sin un responsable nombrado y un procedimiento de escalado, ese plazo es imposible de cumplir. La solución: asignar un rol nombrado — un responsable de cumplimiento de la IA o equivalente — con responsabilidades documentadas para la revisión de KPI, la clasificación de incidentes y la notificación del Artículo 73.

Laguna 5: Declaración de conformidad no reemitida tras el reentrenamiento

Los proveedores emiten una Declaración de conformidad en la entrada al mercado, luego reentrenan el modelo o cambian el entorno de despliegue, pero no actualizan el Anexo IV ni reemiten la Declaración de conformidad. La Declaración original queda obsoleta y resulta engañosa. Una modificación sustancial con arreglo al Artículo 3, apartado 23, activa una nueva evaluación de la conformidad en virtud del Artículo 43, apartado 4, y una nueva Declaración de conformidad con un nuevo número de versión y fecha. La solución: implementar el control de versiones sobre el archivo del Anexo IV; establecer un desencadenante de reemisión para cualquier cambio que afecte materialmente a la exactitud, la robustez, la ciberseguridad o la finalidad prevista; archivar las versiones anteriores en el registro de auditoría.

---

Cómo respalda Confir el cumplimiento del Artículo 15

El Artículo 15 se sitúa dentro del área AITR de Confir (Datos y Robustez Técnica, que abarca los Artículos 10, 11 y 15). El control AITR-02 — Exactitud, Robustez y Ciberseguridad — guía a los proveedores y a los responsables del despliegue a través de una evaluación estructurada que aborda cada requisito del Artículo 15: la selección y declaración de métricas de exactitud, el inventario de amenazas adversarias que abarca las categorías de ataque nombradas por la Ley, el registro de mitigación de bucles de retroalimentación para los sistemas que siguen aprendiendo tras el despliegue y la lista de comprobación de controles de ciberseguridad asignada al Anexo IV, sección 8.

Completar la evaluación AITR-02 genera hallazgos que rellenan las secciones 5 a 8 del Anexo IV del Paquete de Conformidad — el mismo artefacto que subyace a la Declaración de conformidad del Artículo 47. La Puntuación de Salud del Cumplimiento marca las evaluaciones incompletas de robustez o ciberseguridad como hallazgos abiertos en el registro de riesgos. El motor de clasificación y delimitación del ámbito de Confir es basado en reglas y determinista: la misma admisión produce el mismo hallazgo del Artículo 15 siempre, lo cual importa cuando un auditor le pide que explique la lógica de cumplimiento que hay detrás de un hallazgo de control.

Para las empresas que son responsables del despliegue y no proveedores, la evaluación AITR-02 se delimita a las obligaciones de vigilancia y verificación — umbrales de KPI en producción, asignación del rol de respuesta a incidentes y el desencadenante de modificación sustancial que convierte a un responsable del despliegue en proveedor en virtud del Artículo 25.

---

Guías relacionadas

• requisitos de cumplimiento de la Ley de IA de la UE
• requisitos de los sistemas de IA de alto riesgo
• plataforma de cumplimiento de gobernanza de la IA
• documente sus sistemas de IA

Preguntas frecuentes

¿Qué exige el Artículo 15 para la exactitud, en concreto?

El Artículo 15, apartado 1, exige que los sistemas de IA de alto riesgo alcancen un nivel adecuado de exactitud para su finalidad prevista y rindan de forma constante a lo largo de su ciclo de vida. El Artículo 15, apartado 3, exige que los niveles de exactitud y las métricas pertinentes se declaren en las instrucciones de uso en virtud del Artículo 13. La Ley no fija un umbral porcentual universal — el nivel adecuado depende del caso de uso, el riesgo y la población a la que sirve el sistema. Los proveedores deben definir las métricas, justificarlas en el Anexo IV, sección 5, y demostrar mediante pruebas que el sistema las cumple sobre datos representativos, incluidos resultados estratificados por subgrupos pertinentes.

¿Abarca el Artículo 15 los bucles de retroalimentación en los sistemas de IA que siguen aprendiendo?

Sí. El Artículo 15, apartado 3, exige específicamente que los sistemas que siguen aprendiendo tras el despliegue se desarrollen para eliminar o reducir, en la medida de lo posible, el riesgo de que los resultados sesgados influyan en futuras entradas — el problema del bucle de retroalimentación. Los proveedores deben documentar las medidas de mitigación: auditorías de sesgo periódicas, controles de ponderación de entradas, conjuntos de validación reservados extraídos antes de cualquier ciclo de reentrenamiento y compuertas de revisión humana antes de que los modelos reentrenados entren en funcionamiento. Estas medidas y las pruebas que las sustentan pertenecen al Anexo IV, secciones 6 y 9.

¿De qué trata el Artículo 15, apartado 2? ¿Impone obligaciones a los proveedores?

El Artículo 15, apartado 2, encomienda a la Comisión, en cooperación con la Oficina de IA y los organismos pertinentes, fomentar el desarrollo de puntos de referencia y metodologías de medición de la exactitud y la robustez de los sistemas de IA de alto riesgo. Es un mandato institucional a la Comisión, no una obligación directa para los proveedores. En la práctica, indica que se avecinan normas de prueba armonizadas para ámbitos concretos del Anexo III. Cuando ya existan puntos de referencia sectoriales reconocidos — ISO/IEC 29003 para biometría, NIST AI 100-1 para reconocimiento facial —, los proveedores deben utilizarlos y documentar la elección.

¿Quién es responsable del cumplimiento del Artículo 15 — el proveedor o el responsable del despliegue?

Los proveedores cargan con las obligaciones principales: diseñar, probar y documentar la exactitud, la robustez y la ciberseguridad antes de la entrada en el mercado; completar el Anexo IV, secciones 5 a 8; emitir la Declaración de conformidad. Los responsables del despliegue deben vigilar el rendimiento en su contexto de despliegue específico, verificar que las propiedades de exactitud declaradas se mantienen en su entorno, detectar la deriva y los incidentes de seguridad, y notificar los incidentes graves en virtud del Artículo 73. Un responsable del despliegue que modifique sustancialmente el sistema — reentrenándolo con nuevos datos, cambiando el preprocesamiento de las entradas, alterando el límite de decisión — pasa a ser proveedor de esa versión en virtud del Artículo 3, apartado 23, y del Artículo 25, y debe volver a probar y reemitir toda la documentación.

¿Qué amenazas de ciberseguridad específicas de la IA deben abordar los proveedores en virtud del Artículo 15?

El Artículo 15, apartado 3, nombra: el envenenamiento de datos (muestras maliciosas en los datos de entrenamiento), el envenenamiento del modelo (manipulación de las ponderaciones o los parámetros), los ejemplos adversarios / la evasión del modelo (entradas manipuladas que provocan una clasificación errónea) y los ataques a la confidencialidad (inferencia de pertenencia y extracción del modelo). Los proveedores también deben abordar los defectos del modelo que pueden desencadenarse sistemáticamente. Los controles — cifrado de los artefactos del modelo y los datos de entrenamiento, control de acceso a la canalización de entrenamiento, registro de auditoría, gestión de vulnerabilidades, respuesta a incidentes — deben documentarse en el Anexo IV, sección 8, e integrarse en el sistema de gestión de riesgos del Artículo 9.

¿Cómo se relaciona el Artículo 15 con NIS2 e ISO 27001?

Hay un solapamiento deliberado. NIS2 se aplica a los operadores de servicios esenciales e infraestructura digital, lo que abarca varios contextos de alto riesgo del Anexo III. ISO 27001 proporciona una línea de base general de seguridad de la información. Ninguno abarca los vectores de ataque específicos de la IA: envenenamiento de datos, envenenamiento del modelo, extracción del modelo, ejemplos adversarios, inferencia de pertenencia. Los proveedores deben complementar la documentación de seguridad existente con un análisis explícito de amenazas de IA en el Anexo IV, sección 8. Una atestación de NIS2 o un certificado ISO 27001 no sustituyen a esto.

¿Cuándo se aplica el Artículo 15 — cuál es el plazo?

El Artículo 15 forma parte de los requisitos de alto riesgo del capítulo III, sección 2, del Reglamento (UE) 2024/1689. Para los sistemas de IA de alto riesgo autónomos enumerados en el Anexo III — herramientas de selección de personal, modelos de calificación crediticia, sistemas biométricos y otros —, las obligaciones se aplican a partir del 2 de diciembre de 2027 en virtud del acuerdo político del Ómnibus Digital de mayo de 2026, que aplazó la fecha original del 2 de agosto de 2026. Para la IA de alto riesgo integrada como componente de seguridad de productos del Anexo I, la fecha es el 2 de agosto de 2028.