Este es el post técnico, no el legal: si todavía no sabes si tu sistema de IA entra en la categoría de alto riesgo del anexo III, empieza por la clasificación de Summum Consultoría. Aquí se asume que la respuesta ya es «sí» y se explica qué construir en la práctica según los arts. 8-15 del Reglamento (UE) 2024/1689, verificados en vivo para esta guía —incluido el aplazamiento reciente de su calendario (ver más abajo).
Clasificar no es lo mismo que implementar
El AI Act dedica el Capítulo III, Sección 2 (arts. 8 a 15) a los requisitos técnicos que debe cumplir todo sistema de IA de alto riesgo antes de salir a producción. El artículo 113 fijaba originalmente el 2 de agosto de 2026 como fecha de aplicación plena para los sistemas del anexo III. El Digital Omnibus —acuerdo político del 7 de mayo de 2026 entre Comisión, Parlamento y Consejo— pospuso esa exigibilidad al 2 de diciembre de 2027. El contenido de los arts. 8-15 no cambia: cambia cuándo son exigibles y sancionables.
La confusión más frecuente en pymes que ya clasificaron su sistema es pensar que, sabiendo que «es de alto riesgo», el trabajo ya está hecho o que el plazo desapareció. Ninguna de las dos es cierta: clasificar responde a «¿me toca cumplir?»; este post responde a «¿qué construir, y para cuándo?». Con más margen, conviene empezar ahora y no esperar al último trimestre de 2027.
Los ocho artículos de un vistazo
| Artículo | Objeto | Aplicación (tras el Digital Omnibus) |
|---|---|---|
| Art. 8 | Cumplimiento general de los requisitos de la Sección 2 | 2-dic-2027 |
| Art. 9 | Sistema de gestión de riesgos durante todo el ciclo de vida | 2-dic-2027 |
| Art. 10 | Gobernanza de datos de entrenamiento, validación y prueba | 2-dic-2027 |
| Art. 11 | Documentación técnica (contenido mínimo en el anexo IV) | 2-dic-2027 |
| Art. 12 | Registro automático de eventos (logging) | 2-dic-2027 |
| Art. 13 | Transparencia e información al responsable del despliegue | 2-dic-2027 |
| Art. 14 | Supervisión humana efectiva | 2-dic-2027 |
| Art. 15 | Exactitud, solidez y ciberseguridad | 2-dic-2027 |
Se aplican en bloque desde la misma fecha pospuesta y se leen mejor como un sistema que como una lista: los datos del art. 10 alimentan la documentación del art. 11, el logging del art. 12 es la materia prima de la supervisión del art. 14, y la gestión de riesgos del art. 9 conecta a todos los demás. El resto del Reglamento —prohibiciones, alfabetización, gobernanza de modelos de propósito general— sigue el calendario ya vigente y no se ha visto afectado por este aplazamiento.
Artículo 9: sistema de gestión de riesgos
El art. 9 exige un proceso continuo e iterativo, planificado y ejecutado durante todo el ciclo de vida del sistema —no una evaluación que se hace una vez antes del lanzamiento y se archiva. Exige identificar y analizar riesgos conocidos y razonablemente previsibles antes de la puesta en servicio, y probar el sistema para encontrar las medidas de mitigación más adecuadas.
El criterio de cierre no es «riesgo cero»: el riesgo residual de cada peligro debe juzgarse aceptable, y hay que valorar expresamente el posible impacto adverso en menores de 18 años. En la práctica: un registro de riesgos vivo por sistema y versión, actualizado cada vez que cambia el modelo, los datos o el entorno de uso.
Artículo 10: gobernanza de datos
Los conjuntos de entrenamiento, validación y prueba deben ser «pertinentes, suficientemente representativos y, en la mayor medida posible, libres de errores y completos». La gobernanza exigida cubre origen de los datos, operaciones de preparación —anotación, etiquetado, limpieza—, supuestos sobre lo que representan y examen de sesgos que puedan afectar a salud, seguridad, derechos fundamentales o causar discriminación prohibida.
De forma excepcional, permite tratar categorías especiales de datos personales para corregir sesgos si no hay alternativa razonable, con seguridad reforzada, acceso restringido y borrado al terminar. Para una pyme que integra modelos de terceros con sus propios documentos (RAG), el art. 10 no desaparece: índices, permisos y fuentes recuperadas también son «datos» a gobernar.
Artículo 11: documentación técnica y anexo IV
El art. 11.1 obliga a elaborar la documentación técnica antes de la puesta en el mercado y a mantenerla actualizada, con el contenido mínimo que fija el anexo IV: descripción general del sistema, proceso de desarrollo, datos de entrenamiento, validación y prueba, supervisión post-comercialización y evaluación de conformidad, entre otros bloques. Las pymes y microempresas pueden presentarla en formato simplificado con la plantilla que publique la Comisión.
Aquí encajan los model cards como artefacto práctico: bien construidos, cubren buena parte del anexo IV, aunque no lo sustituyen por completo. Le dedicamos una guía específica al anexo IV y a los model cards porque el contenido es lo bastante extenso como para no resumirlo aquí sin perder detalle.
Artículo 12: registro automático de eventos (logging)
El sistema debe permitir técnicamente el registro automático de eventos (logs) durante toda su vida útil, para identificar situaciones de riesgo, dar soporte a la vigilancia post-comercialización y hacer trazable su funcionamiento. Para la identificación biométrica remota del anexo III, el Reglamento fija un mínimo explícito: periodo de uso, bases de datos contrastadas, datos que produjeron una coincidencia e identidad de quien verificó el resultado.
Fuera de ese caso, el criterio general es el mismo: un log útil reconstruye modelo, versión, entrada, salida y decisión humana, aplicando minimización —un prompt puede contener datos personales que no conviene conservar sin criterio.
Artículo 13: transparencia e información al responsable del despliegue
El sistema debe diseñarse para que su funcionamiento sea suficientemente transparente y permita interpretar correctamente sus resultados. Las instrucciones de uso deben ser concisas, completas, correctas y claras, e incluir identidad del proveedor, finalidad prevista, exactitud esperada, riesgos conocidos, especificaciones de los datos de entrada, orientación para interpretar la salida, medidas de supervisión humana y necesidades de mantenimiento.
Es, en la práctica, el contrato técnico entre quien construye el sistema y quien lo opera: sin esa información en formato utilizable, el responsable del despliegue no puede cumplir su parte del art. 26 y la cadena de responsabilidad se rompe.
Artículo 14: supervisión humana
El sistema debe diseñarse para poder ser supervisado eficazmente por personas físicas mientras está en uso, con medidas proporcionadas al riesgo, la autonomía y el contexto. Quien supervisa debe comprender capacidades y límites del sistema, ser consciente del sesgo de automatización, interpretar correctamente los resultados, poder anular la salida e intervenir o detener el sistema mediante un botón de parada.
Para determinados sistemas de identificación biométrica del anexo III, el Reglamento añade una doble verificación: ninguna decisión puede adoptarse sin que al menos dos personas con competencia y autoridad la confirmen por separado, con excepción para ciertos usos de aplicación de la ley, migración y control fronterizo cuando resulte desproporcionada. Una supervisión que se reduce a un botón que nadie pulsa —porque el volumen de alertas hace inviable revisarlas— no es supervisión eficaz, por muy bien documentada que esté.
Artículo 15: exactitud, solidez y ciberseguridad
El sistema debe alcanzar un nivel adecuado de exactitud, solidez y ciberseguridad, y mantenerlo de forma constante durante todo su ciclo de vida. Las métricas de exactitud deben declararse en las instrucciones de uso. La solidez exige resistir errores, fallos o incoherencias con soluciones técnicas —redundancia, planes de respaldo— y mitigar el riesgo de que una salida sesgada influya en operaciones futuras.
En ciberseguridad exige resiliencia frente a terceros no autorizados que intenten alterar el uso o el rendimiento explotando vulnerabilidades específicas: envenenamiento de datos o del modelo, entradas adversarias, ataques a la confidencialidad. Aquí es donde un ejercicio de red teaming ofensivo deja de ser opcional y pasa a ser la evidencia de que el art. 15 se cumple en la práctica, no solo en la documentación.
De la norma al control real: qué construir
Traducido a arquitectura técnica, los arts. 8-15 piden piezas familiares para un equipo de MLOps maduro, aunque rara vez estén todas presentes a la vez en una pyme: registro de riesgos vivo (art. 9), inventario y linaje de datos con examen de sesgos (art. 10), expediente técnico mapeado con el anexo IV (art. 11), logging estructurado con minimización (art. 12), instrucciones de uso completas para quien despliega (art. 13), interfaz de supervisión con botón de parada real (art. 14) y pruebas de exactitud y red teaming recurrentes, no solo previas al lanzamiento (art. 15).
Ninguna pieza se construye aislada sin coste: es el terreno común entre el AI Act y un sistema de gestión de IA certificado como ISO/IEC 42001, cuyo anexo A exige controles muy parecidos. Quien ya tiene el SGIA implantado parte con buena parte del trabajo técnico hecho.
Checklist técnico antes del 2 de diciembre de 2027
- Registro de riesgos por sistema, con riesgo residual aceptado y firmado.
- Datos de entrenamiento/validación/prueba con procedencia y sesgos documentados.
- Expediente técnico alineado con las secciones del anexo IV.
- Logging capaz de reconstruir entrada, salida y decisión humana.
- Instrucciones de uso completas entregadas al responsable del despliegue.
- Supervisión humana con capacidad real de anular o detener el sistema.
- Pruebas de exactitud, solidez y ciberseguridad con umbrales por caso de uso.
- Evidencia de red teaming o prueba adversarial reciente.
Preguntas frecuentes
¿Estos artículos aplican si compramos el sistema a un proveedor externo?
Obligan en primer término al proveedor que desarrolla o pone el sistema en el mercado. Pero quien lo despliega necesita la información del art. 13 y debe ejercer la supervisión del art. 14 con datos reales, no con una casilla marcada: contratar no traslada toda la responsabilidad.
¿En qué se diferencia esto del post de clasificación de alto riesgo?
Ese post responde si tu sistema cae en una categoría del anexo III y qué régimen legal le corresponde. Este responde qué construir técnicamente una vez la respuesta es afirmativa.
¿Qué relación tiene esto con ISO/IEC 42001?
El anexo A de la norma cubre, en gran medida, el mismo terreno que estos ocho artículos. Un SGIA certificado no sustituye la evaluación de conformidad del AI Act, pero adelanta gran parte del trabajo técnico.
¿Se ha aplazado de verdad el 2 de agosto de 2026 para estos sistemas, y se puede esperar?
Sí: para los sistemas de alto riesgo del anexo III, el Digital Omnibus (acuerdo político de 7 de mayo de 2026) pospuso la aplicación plena al 2 de diciembre de 2027 —el 2 de agosto de 2026 sigue siendo la fecha de aplicación general del resto del Reglamento, y las prohibiciones y la alfabetización del art. 4 llevan vigentes desde 2025—. Pero no conviene esperar: el registro de riesgos, la gobernanza de datos, el logging y la supervisión humana toman meses de maduración real, no de redacción de documentos. Verifica siempre el calendario contra el texto oficial en vigor al leer esto.
Summum IA acompaña la implementación técnica de estos controles —gestión de riesgos, logging, supervisión humana y red teaming— dentro de un programa de adecuación técnica al AI Act. La interpretación jurídica de qué régimen aplica a cada sistema debe validarse con el equipo de cumplimiento antes de tomar decisiones.