Los requisitos técnicos del AI Act: Arts. 15 y 17, explicados
El Art. 15 se cita constantemente como si fuera un requisito. En realidad son tres cosas distintas —precisión, solidez y ciberseguridad— que se demuestran de formas diferentes. Y el Art. 17 es el sistema que las conecta. Esto es lo que exige cada uno y cómo se documenta.
El error de tratar el Art. 15 como un solo requisito
«Cumplimos el Art. 15» es una frase que no significa nada por sí sola, porque el artículo impone tres obligaciones técnicas que se miden, se prueban y se documentan de manera distinta:
| Requisito | Qué demuestra | Cómo se prueba |
|---|---|---|
| Precisión | Que el sistema acierta, y cuánto | Métricas justificadas, separación estricta de conjuntos, desglose por subgrupo |
| Solidez | Que sigue acertando con el tiempo y ante fallos | Resistencia a errores, redundancia, control de la degradación |
| Ciberseguridad | Que nadie externo puede alterar su uso o sus salidas | Medidas contra envenenamiento de datos y modelo, ejemplos adversarios y fugas de confidencialidad |
Los tres detalles del Art. 15 que casi nadie documenta
1. La precisión hay que declararla, no solo medirla
El Art. 15(3) exige que el nivel de precisión y las métricas relevantes se declaren en las instrucciones de uso que acompañan al sistema. No basta con tenerlo en un informe interno: quien despliega el sistema tiene que poder leerlo. Es una obligación de transparencia hacia el siguiente eslabón de la cadena, no solo hacia la autoridad.
2. Los bucles de retroalimentación en sistemas que siguen aprendiendo
El Art. 15(4) contiene una exigencia muy concreta y poco citada: los sistemas que continúan aprendiendo tras su puesta en el mercado deben desarrollarse de forma que se elimine o reduzca al máximo el riesgo de que salidas sesgadas influyan en las entradas de operaciones futuras — los llamados bucles de retroalimentación — y que estos se traten con medidas de mitigación adecuadas.
En la práctica esto significa que si tu sistema se reentrena con sus propios resultados, necesitas un control explícito y documentado de esa deriva. Es el punto donde más sistemas fallan en silencio.
3. La ciberseguridad del Art. 15 no es la ciberseguridad general
El Art. 15(5) habla de amenazas específicas de la IA: envenenamiento de datos de entrenamiento y de modelo, ejemplos adversarios diseñados para engañar al sistema, y ataques a la confidencialidad del modelo. Tu política de seguridad corporativa (o tu cumplimiento de NIS2) cubre la infraestructura, pero no necesariamente estos vectores.
El Art. 17: el sistema que lo sostiene todo
El Art. 17 exige a los proveedores de sistemas de alto riesgo un sistema de gestión de la calidad documentado con al menos 13 elementos. La clave para no duplicar trabajo: la mayoría de esos elementos ya deberían existir en otras piezas de tu documentación — gestión de riesgos (Art. 9), gobernanza de datos (Art. 10), vigilancia poscomercialización (Art. 72), notificación de incidentes (Art. 73). El Art. 17 no pide rehacerlos: pide conectarlos en un marco único y coherente, y añadir lo que falte.
Tres elementos suelen estar sin cubrir en casi todas las organizaciones: el control y verificación del diseño, el aseguramiento de calidad durante el desarrollo, y la gestión de recursos y seguridad del suministro (qué pasa si tu proveedor de modelo o de cómputo deja de estar disponible).
El Art. 17 no obliga a certificarse en ISO/IEC 42001. Esa norma es una vía razonable para estructurar el sistema, pero no es un requisito legal — aquí comparamos ISO 42001 con ISO 27001 y aquí con ISO 23894.
Cuándo hay que tenerlo listo
Ambos artículos aplican a los sistemas de alto riesgo. Tras el Digital Omnibus (Reglamento UE 2026/1744, en vigor desde el 27 de julio de 2026), las obligaciones de alto riesgo del Anexo III se aplazaron a diciembre de 2027. Es tiempo suficiente para hacerlo bien, y demasiado poco para empezar el último trimestre.
Fuentes
Reglamento (UE) 2024/1689, Arts. 13, 15 y 17 · EUR-Lex · Guías 4, 9 y 10 de AESIA (Sistema de gestión de la calidad, Precisión y Solidez).
Los checklists de cada requisito
Un documento por requisito, alineado con las guías de AESIA — con las tablas de registro que pide un auditor.