Cuando un sistema de IA es de alto riesgo, el AI Act no se conforma con que funcione bien: exige poder demostrarlo por escrito. Ese expediente se llama documentación técnica y su contenido mínimo está fijado, punto por punto, en el Anexo IV del Reglamento (UE) 2024/1689, al que remite el artículo 11.1. El artículo 113 fijaba originalmente el 2 de agosto de 2026 como fecha de aplicación plena para el resto del Capítulo III junto al Anexo III; el Digital Omnibus (acuerdo de 7-may-2026, aprobado por el Parlamento Europeo el 16-jun-2026 y el Consejo el 29-jun-2026, pendiente de publicación en el DOUE) aplaza esa exigibilidad al 2 de diciembre de 2027. Aun así, cualquier proveedor de un sistema de alto riesgo hace bien en tener este expediente cerrado con tiempo, no al límite: la buena noticia es que buena parte de ese trabajo ya se hace, con otro nombre, cada vez que alguien redacta un model card serio de su modelo.
Qué exige el artículo 11.1 sobre documentación técnica
El artículo 11.1 del Reglamento, verificado en su texto vigente, establece que la documentación técnica de un sistema de alto riesgo debe elaborarse antes de que el sistema se introduzca en el mercado o se ponga en servicio, y debe mantenerse actualizada. No es un informe que se escribe una vez y se archiva: cada cambio relevante en el modelo, los datos o el uso previsto obliga a revisarla. El Reglamento fija que debe contener, como mínimo, los elementos del Anexo IV, y contempla un formulario simplificado para pymes y startups que los organismos notificados deben aceptar en sus evaluaciones de conformidad.
Esta es la pieza que la clasificación legal de alto riesgo deja pendiente: una vez que consultoría determina que un sistema entra en el Anexo III, alguien tiene que redactar el expediente técnico que lo acredite. Eso es trabajo de implementación, no de interpretación normativa, y es el ángulo que cubrimos aquí junto con los requisitos técnicos de los arts. 8-15 (gestión de riesgos, logging, supervisión humana) que esta documentación tiene que evidenciar.
Los 9 puntos del Anexo IV, uno por uno
El Anexo IV no es una lista de buenas intenciones: son 9 puntos numerados, cada uno con su propio contenido exigido. Esta tabla los resume con el nivel de detalle necesario para empezar a redactar sin tener que ir artículo por artículo:
| Punto | Qué exige | Ejemplo de evidencia |
|---|---|---|
| 1. Descripción general | Finalidad prevista, proveedor, versión y relación con versiones anteriores | Ficha de producto, historial de versiones |
| 2. Elementos del sistema y desarrollo | Arquitectura, métodos de diseño, recursos de cómputo, requisitos de datos | Datasheet de datos, diagrama de arquitectura |
| 3. Supervisión, funcionamiento y control | Capacidades, límites de rendimiento y grados de exactitud por persona o grupo | Métricas desagregadas por subgrupo |
| 4. Idoneidad de las métricas | Por qué las métricas elegidas son adecuadas para ese sistema concreto | Justificación técnica de las métricas |
| 5. Gestión de riesgos | Descripción detallada del sistema de gestión de riesgos (art. 9) | Registro de riesgos y mitigaciones |
| 6. Cambios en el ciclo de vida | Modificaciones introducidas por el proveedor a lo largo del tiempo | Changelog técnico versionado |
| 7. Normas armonizadas | Normas UE aplicadas o soluciones alternativas para cumplir el Capítulo III | Listado de normas o especificaciones comunes |
| 8. Declaración UE de conformidad | Copia de la declaración prevista en el art. 47 | Documento de declaración firmado |
| 9. Vigilancia post-comercialización | Sistema y plan de seguimiento del rendimiento tras la puesta en servicio | Plan de monitorización post-mercado |
Los puntos 1 a 4 son, casi literalmente, las secciones que ya rellena cualquier equipo que documenta un modelo con rigor. Los puntos 5 a 9 son más específicos del AI Act y suelen faltar en la documentación técnica «genérica» que se hereda de un proyecto de machine learning convencional.
Qué es un model card y por qué cubre buena parte de la exigencia
El concepto de model card lo formalizó un equipo de Google en el paper «Model Cards for Model Reporting» (Mitchell et al., 2019): una ficha estandarizada que documenta, de forma breve y estructurada, el propósito de un modelo, sus datos de entrenamiento, su rendimiento medido y sus limitaciones conocidas. Hoy es la práctica de facto en la comunidad de IA (Hugging Face, la propia OpenAI o Google lo usan como formato por defecto al publicar modelos), y sus secciones habituales —detalles del modelo, uso previsto, datos de entrenamiento y evaluación, métricas de rendimiento, limitaciones y consideraciones éticas— se solapan de forma casi directa con los puntos 1 a 4 del Anexo IV.
Que se solape no significa que sea intercambiable. Un model card público suele omitir deliberadamente información sensible (arquitectura exacta, recursos de cómputo, detalles de seguridad) que el Anexo IV sí exige documentar de forma interna para la autoridad competente. La relación correcta es: el model card es la base reutilizable, el expediente técnico del Anexo IV es la versión completa y con los puntos 5 a 9 añadidos que no forma parte del estándar de model card pero que el Reglamento exige igualmente.
Plantilla mínima: qué añadir a un model card para llegar al Anexo IV completo
Si tu equipo ya redacta model cards, el trabajo pendiente para llegar al expediente técnico completo se concentra en cinco bloques que no forman parte del estándar de model card:
- Registro de riesgos del art. 9: no basta con mencionar limitaciones, hay que documentar el proceso continuo de identificación y mitigación.
- Historial de cambios versionado: cada actualización relevante del modelo, con fecha y motivo, no solo la versión vigente.
- Normas armonizadas o especificaciones comunes aplicadas: referencia explícita, no una mención genérica a «buenas prácticas».
- Declaración UE de conformidad: documento formal, no una nota interna.
- Plan de vigilancia post-mercado: quién revisa el rendimiento en producción, con qué periodicidad y qué dispara una revisión del expediente.
Las pruebas de validación y robustez que sustentan varios de estos puntos —sobre todo el 3 y el 4— se apoyan en gran medida en el trabajo de auditoría ofensiva de modelos (red teaming): sin esas pruebas documentadas, «los límites de rendimiento» del punto 3 quedan como una afirmación sin evidencia detrás.
Quién debe elaborarlo, cuándo y cómo mantenerlo vivo
La obligación recae sobre el proveedor del sistema de alto riesgo, no sobre quien simplemente lo usa bajo licencia. Si tu empresa integra un modelo de terceros dentro de un producto propio y lo comercializa bajo su marca, puede convertirse en proveedor a efectos del Reglamento y heredar esta obligación aunque no haya entrenado el modelo desde cero. El expediente debe estar listo antes de la puesta en el mercado o en servicio, disponible para la autoridad competente que lo solicite —en España, la AESIA— y actualizado cada vez que cambie el modelo, los datos, la finalidad o el entorno de despliegue. No existe una versión «definitiva»: es un documento vivo con dueño y calendario de revisión.
Documentar bien también reduce el riesgo económico
Un expediente técnico completo y actualizado no evita por sí solo una sanción, pero sí es la evidencia principal de diligencia que una autoridad revisa al valorar un incumplimiento. Si quieres dimensionar antes ese riesgo económico —qué tramo del art. 99 se aplicaría según el tipo de infracción y la facturación de tu empresa— la calculadora de sanciones del AI Act de Summum Consultoría da un rango orientativo en un minuto. Y si tu empresa ya certifica o está preparando un sistema de gestión de IA (ISO 42001), gran parte de esta documentación —gestión de riesgos, control de cambios, vigilancia continua— ya vive dentro de ese sistema de gestión: no hay que construirla dos veces, hay que enlazarla.
Preguntas frecuentes
¿Un model card publicado en Hugging Face vale como documentación técnica del Anexo IV?
No por sí solo. Cubre buena parte de los puntos 1 a 4 (descripción general, desarrollo, rendimiento, métricas), pero le faltan los puntos 5 a 9: gestión de riesgos, historial de cambios, normas armonizadas, declaración de conformidad y plan de vigilancia post-mercado. Sirve como base, no como expediente completo.
¿Hace falta un expediente distinto por cada versión del modelo?
No necesariamente un documento nuevo, pero sí una actualización que quede trazada: el art. 11.1 exige que la documentación se mantenga actualizada, con historial de qué cambió y cuándo, no que se reescriba desde cero cada vez.
¿Existe una versión simplificada para pymes?
Sí. El Reglamento prevé un formulario simplificado para pymes y startups que los organismos notificados deben aceptar en sus evaluaciones de conformidad, aunque debe seguir cubriendo los mismos 9 puntos del Anexo IV, con menor extensión por punto.
¿Quién revisa este expediente en España?
La autoridad de vigilancia del mercado es la AESIA (Agencia Española de Supervisión de Inteligencia Artificial). Es quien puede solicitar el expediente técnico completo en una inspección o tras un incidente notificado.
Summum IA acompaña la redacción del expediente técnico del Anexo IV dentro de un proyecto más amplio de adecuación técnica al AI Act (gestión de riesgos, logging, supervisión humana y evaluación de modelos). La interpretación jurídica de qué sistemas están obligados debe validarse con el equipo de cumplimiento legal correspondiente.