Los sistemas de IA de alto riesgo deben mantener un expediente técnico completo antes de su comercialización en el mercado de la UE. El Art. 11 y el Anexo IV definen exactamente qué debe incluir — desde la arquitectura del sistema hasta la gobernanza de los datos de entrenamiento y los planes de vigilancia poscomercialización.
¿Qué Es el Expediente Técnico?
La documentación técnica — comúnmente llamada «expediente técnico» — es el paquete de evidencias maestro que demuestra que un sistema de IA de alto riesgo cumple todos los requisitos del Reglamento de IA de la UE. Mandado por el Art. 11 y estructurado por el Anexo IV, debe elaborarse antes de que el sistema sea comercializado en el mercado de la UE y mantenerse actualizado durante todo el ciclo de vida del sistema.
El expediente técnico no se presenta centralmente. El proveedor lo conserva y lo presenta a petición de las autoridades de vigilancia del mercado y los organismos notificados. Es un modelo pull: las autoridades vienen a usted; debe estar listo para entregar un paquete completo y coherente, no una pila de archivos improvisada bajo presión.
El Art. 11 impone tres deberes a los proveedores:
- Elaborarlo antes de la comercialización o la puesta en servicio.
- Mantenerlo actualizado — cualquier cambio sustancial en el sistema requiere actualizar el expediente y reevaluar la conformidad.
- Ponerlo a disposición de las autoridades competentes y los organismos notificados a petición, dentro de un plazo definido (normalmente 10 días hábiles en virtud de las normas nacionales de vigilancia del mercado).
El estándar de «actualizado» es funcional: el expediente técnico debe reflejar el sistema tal como está efectivamente desplegado, no el sistema tal como fue diseñado originalmente. Si una actualización del modelo cambia las características de rendimiento, los umbrales de exactitud o los datos de entrenamiento, el expediente debe revisarse en consecuencia.
¿Quién Necesita Documentación Técnica?
La documentación técnica en virtud del Art. 11 y el Anexo IV es obligatoria para los proveedores de:
- Sistemas de IA de alto riesgo enumerados en el Anexo III — sistemas independientes en áreas como la categorización biométrica, la contratación, la puntuación crediticia, la gestión de infraestructuras críticas, la educación, la aplicación de la ley, la migración y el control fronterizo, y la administración de justicia (sujeto al filtro de riesgo significativo del Art. 6(3))
- Sistemas de IA que funcionan como componentes de seguridad en productos regulados del Anexo I — IA integrada en dispositivos médicos, maquinaria, vehículos, equipos de aviación y productos similares regulados por la legislación de seguridad de productos de la UE existente
La documentación técnica no es obligatoria para:
- Sistemas de IA de riesgo mínimo (chatbots, filtros de spam, motores de recomendación fuera de las categorías de alto riesgo)
- Sistemas de IA sujetos solo a obligaciones de transparencia en virtud del Art. 50 (p. ej., divulgaciones de deepfakes, divulgaciones de reconocimiento de emociones cuando no son de alto riesgo)
- Proveedores de modelos de IA de uso general (GPAI) — tienen obligaciones de documentación separadas en virtud del Art. 53, incluida documentación técnica para el propio modelo, pero no el formato del Anexo IV diseñado para los sistemas de alto riesgo desplegados
Si usted es un operador (no un proveedor), no está obligado a preparar el expediente técnico. Sin embargo, los operadores deben mantener registros del uso del sistema (Art. 26(5)), y los proveedores tienen derecho a basarse en estos registros al actualizar la documentación técnica o gestionar los informes de incidentes.
Los 14 Elementos del Anexo IV
El Anexo IV especifica el contenido mínimo del expediente técnico. No hay un formato rígido — los proveedores pueden organizar la documentación como consideren oportuno — pero todos los 14 elementos deben estar presentes y ser sustantivos. Las entradas tipo lista de verificación sin evidencia de apoyo no satisfacen el Anexo IV.
| # | Elemento del Anexo IV | Lo que debe contener |
|---|---|---|
| 1 | Descripción general | Nombre del sistema, identificador de versión, fin previsto, usuarios previstos, mercados geográficos, nombre y dirección del proveedor, cualquier representante autorizado |
| 2 | Componentes del sistema | Requisitos de hardware, componentes de software, modelos o bibliotecas de terceros utilizados, descripción general de la metodología de entrenamiento, enfoque algorítmico (p. ej., aprendizaje supervisado, aprendizaje por refuerzo, arquitectura transformer) |
| 3 | Especificaciones de diseño | Arquitectura del sistema, diagramas de flujo de datos, decisiones de diseño clave y su justificación, compensaciones realizadas (p. ej., exactitud vs. explicabilidad), formato de salida y cómo las salidas alimentan las decisiones posteriores |
| 4 | Datos de entrenamiento, validación y prueba | Conjuntos de datos utilizados en cada etapa, fuentes de datos, procedimientos de gobernanza de datos, propiedades estadísticas de los conjuntos de datos (tamaño, distribución, cobertura), protocolos de procesamiento y preprocesamiento de datos, medidas adoptadas para detectar y abordar los sesgos de los conjuntos de datos |
| 5 | Documentación de gestión de riesgos | El sistema completo de gestión de riesgos del Art. 9: riesgos identificados para la salud, la seguridad y los derechos fundamentales; estimación y evaluación de riesgos; medidas de mitigación de riesgos adoptadas; riesgos residuales aceptados; base para aceptar los riesgos residuales |
| 6 | Cambios en el ciclo de vida | Descripción de todas las modificaciones sustanciales realizadas tras el despliegue inicial, su naturaleza y alcance, cómo se reevaluó la conformidad tras cada cambio, historial de versiones con fechas |
| 7 | Medidas de supervisión humana | Cómo se implementan los requisitos del Art. 14: mecanismos de anulación y detención, interfaces que permiten a los operadores humanos supervisar las salidas, requisitos de formación o calificación para los operadores, procedimientos documentados para la intervención humana |
| 8 | Procedimientos de validación y prueba | Métricas de rendimiento utilizadas (exactitud, precisión, recall, F1, AUC, métricas de equidad), descripciones de los conjuntos de datos de prueba, condiciones y entorno de prueba, metodología y resultados de las pruebas de sesgo, pruebas de robustez y estrés, rendimiento fuera de la distribución |
| 9 | Medidas de ciberseguridad | Medidas técnicas contra el robo de modelos, el envenenamiento de datos, los ataques adversariales, la inyección de prompts (para sistemas basados en LLM), controles de acceso, cifrado en tránsito y en reposo, procedimientos de gestión de vulnerabilidades |
| 10 | Supervisión de sesgos y exactitud | Procedimientos de supervisión continua post-despliegue, umbrales de exactitud por debajo de los cuales el sistema activa una revisión, benchmarks de rendimiento desagregados por grupos demográficos donde sea pertinente, procedimientos para actuar sobre la desviación o el sesgo detectados |
| 11 | Instrucciones de uso | El documento orientado al operador del Art. 13: fin previsto y casos de uso, características y limitaciones de rendimiento, restricciones conocidas, requisitos de mantenimiento y actualización, obligaciones de registro para los operadores, punto de contacto para notificar incidentes |
| 12 | Plan de vigilancia poscomercialización | El diseño del sistema de supervisión del Art. 72: datos recopilados de los operadores, frecuencia de los ciclos de supervisión, umbrales que desencadenan una revisión o actualización, procedimiento de notificación de incidentes graves (Art. 73), procedimiento para retroalimentar los datos de supervisión en la gestión de riesgos |
| 13 | Descripción de interfaces | APIs y puntos de integración, formatos y restricciones de datos de entrada, formatos de salida y su semántica, integración con otros sistemas o componentes, compatibilidad de versiones |
| 14 | Normas armonizadas y especificaciones comunes | Lista de normas armonizadas aplicadas (p. ej., ISO/IEC 42001:2023, normas EN en virtud del programa de normalización del Reglamento de IA), especificaciones comunes adoptadas en virtud del Art. 41, el grado en que se aplicó cada norma, cualquier desviación y su justificación |
Nota práctica sobre el elemento 4 (datos de entrenamiento): El Anexo IV no le obliga a divulgar los conjuntos de datos públicamente ni a las autoridades por defecto. Requiere que la documentación exista y pueda producirse. Para los conjuntos de datos propietarios, una descripción de los procedimientos de gobernanza de datos, los resúmenes estadísticos y los resultados de las pruebas de sesgo generalmente satisfarán el requisito sin divulgar datos comercialmente sensibles.
Nota práctica sobre el elemento 14 (normas): A mediados de 2026, el programa de normalización del Reglamento de IA sigue en curso. ISO/IEC 42001 (sistemas de gestión de IA) está disponible y se referencia ampliamente. Los proveedores deben seguir el trabajo de normalización europeo en virtud del JTC 21 de CEN/CENELEC y actualizar esta sección a medida que se publiquen las normas armonizadas en el Diario Oficial.
Declaración UE de Conformidad (Art. 47)
La Declaración UE de Conformidad (DoC UE) es un documento obligatorio separado — no forma parte del expediente técnico, pero lo referencia. La DoC UE es la declaración formal del proveedor de que el sistema de IA cumple todos los requisitos aplicables del Reglamento de IA de la UE.
Una DoC UE válida debe incluir:
- El nombre y la dirección del proveedor (y del representante autorizado si procede)
- El nombre del sistema de IA, la versión, el número de serie o lote si procede
- Una declaración de que el sistema cumple con el Reglamento de IA de la UE
- El procedimiento de evaluación de la conformidad utilizado: Anexo VI (control interno / autoevaluación) para la mayoría de los sistemas del Anexo III, o Anexo VII (evaluación por terceros por un organismo notificado) para la IA de categorización biométrica y la IA utilizada en infraestructuras críticas que requiere participación de terceros
- Una lista de las normas armonizadas o especificaciones comunes en las que se basa
- La firma del representante autorizado del proveedor con fecha y lugar
La DoC UE debe conservarse durante 10 años tras la comercialización y producirse a petición. Acompaña al marcado CE (véase más abajo).
Para los sistemas de IA integrados en productos del Anexo I, la DoC UE puede fusionarse con la declaración de conformidad requerida en virtud de la legislación sectorial pertinente, siempre que contenga todos los elementos requeridos por ambos instrumentos jurídicos.
Marcado CE (Art. 48)
Los sistemas de IA de alto riesgo comercializados en el mercado de la UE deben llevar el marcado CE, que señala la conformidad con el Reglamento de IA de la UE y cualquier otra legislación de armonización de la Unión aplicable que cubra el mismo producto.
Excepciones: Los sistemas de IA en categorías del Anexo III desplegados por autoridades públicas para su uso interno propio están exentos de los requisitos de marcado CE. Siguen sujetos a todas las demás obligaciones — documentación técnica, gestión de riesgos, supervisión humana, registro — pero no necesitan colocar el marcado CE.
El marcado CE debe colocarse antes de que el sistema sea comercializado en el mercado de la UE. Debe ser visible, legible e indeleble. Cuando la naturaleza física del sistema no permite colocar la marca directamente, puede aparecer en el embalaje o en las instrucciones de uso.
Cuando un sistema de IA de alto riesgo es un componente de un producto del Anexo I que ya requiere el marcado CE en virtud de la legislación sectorial específica (p. ej., dispositivos médicos, maquinaria), el marcado CE cubre la conformidad tanto con la legislación sectorial como con el Reglamento de IA. Los proveedores deben documentar claramente qué procedimientos de evaluación de la conformidad sustentan el marcado CE.
Lista de Verificación Práctica: Expediente Técnico Mínimo Viable
Antes de comercializar cualquier sistema de IA de alto riesgo en el mercado de la UE, verifique que estos 10 elementos están completos y evidenciados:
- [ ] Descripción del sistema y control de versiones — nombre, versión, fin previsto documentado; existe un registro de cambios
- [ ] Diagrama de arquitectura — diagrama de flujo de datos y componentes que muestra todos los elementos de hardware, software y terceros
- [ ] Inventario de datos de entrenamiento y registro de gobernanza — conjuntos de datos catalogados con fuente, tamaño, divisiones y procedimientos de calidad de datos documentados
- [ ] Evaluación de riesgos (según el Art. 9) — riesgos identificados, medidas de mitigación y riesgos residuales aceptados documentados y aprobados
- [ ] Resultados de pruebas de sesgo — metodología de prueba documentada; resultados desagregados por grupos demográficos pertinentes cuando proceda
- [ ] Métricas de exactitud en un conjunto de prueba representativo — métricas de rendimiento documentadas con condiciones de prueba; umbrales definidos
- [ ] Documento de procedimiento de supervisión humana — mecanismos de anulación descritos; requisitos del operador (formación, calificación) documentados
- [ ] Evaluación de ciberseguridad — vectores de ataque conocidos evaluados; contramedidas técnicas documentadas
- [ ] Instrucciones de uso (orientadas al operador) — documento del Art. 13 completo, incluidas limitaciones, obligaciones de registro y contacto para notificación de incidentes
- [ ] Plan de vigilancia poscomercialización — ámbito de recopilación de datos, frecuencia de supervisión, desencadenantes de revisión y procedimiento de notificación de incidentes documentados
Esta lista de verificación cubre el mínimo. Un expediente técnico bien preparado irá más allá — particularmente en la metodología de prueba de sesgos, las tarjetas de modelos para los modelos de componentes y la evidencia de que el proceso de gestión de riesgos es iterativo en lugar de un ejercicio puntual.
Cómo Se Vincula con la Academia del Reglamento de IA de la UE
El nivel Pro de la Academia del Reglamento de IA de la UE incluye plantillas de documentación técnica listas para usar que cubren los 14 elementos del Anexo IV, incluyendo:
- Un libro de trabajo XLSX estructurado con una pestaña por elemento del Anexo IV, prepoblado con indicaciones y entradas de ejemplo
- Un esqueleto de expediente técnico en DOCX listo para editar
- Una hoja de trabajo de evaluación de riesgos siguiendo el proceso iterativo del Art. 9
- Una plantilla de registro de gobernanza de datos que cubre los conjuntos de datos de entrenamiento, validación y prueba
- Una plantilla de plan de vigilancia poscomercialización alineada con el Art. 72
Estas plantillas están diseñadas para adaptarse a su sistema específico — son puntos de partida con contenido sustantivo, no formularios en blanco.
Páginas relacionadas:
- Anexo III — Categorías y obligaciones de IA de alto riesgo
- Procedimientos de evaluación de la conformidad (Anexo VI y VII)
- Academia del Reglamento de IA de la UE — plantillas y formación
- Herramientas — Selector de evaluación de la conformidad
Official AI Act Compliance Deadline Calendar
Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.
| Obligation | Applies to | Original date | New date | Status | Countdown | Legal basis |
|---|---|---|---|---|---|---|
| Prohibited Practices (Art. 5) | All providers and deployers | active | — | AI Act Art. 5 | ||
| GPAI Rules (Chapter 5) | GPAI model providers | active | — | AI Act Art. 51-56 | ||
| High-risk AI — Annex III (standalone) | Providers of standalone Annex III systems | deferred | — | AI Omnibus 2026 Art. 6(2) | ||
| High-risk AI — Annex I (embedded) | AI embedded in Annex I regulated products | deferred | — | AI Omnibus 2026 Art. 6(1) | ||
| AI-Generated Content Marking | Providers of generative GPAI systems | active | — | AI Act Art. 50(2) | ||
| Regulatory Sandboxes | National competent authorities | active | — | AI Act Art. 57 |
⬇ Download JSON · CC BY 4.0
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth.
Explore regulation-dora.eu ↗Frequently Asked Questions
El proveedor del sistema de IA de alto riesgo es el único responsable de preparar y mantener la documentación técnica. Los operadores no están obligados a prepararla, pero deben mantener registros de acceso y pueden necesitar proporcionarlos a los proveedores con fines de notificación.
La documentación técnica debe conservarse durante 10 años después de que el sistema de IA sea comercializado en el mercado de la UE o puesto en servicio (Art. 18). Para los sistemas de IA integrados en productos sujetos a la legislación del Anexo I, se aplica el período de retención de la legislación de productos si es más largo.
No: la documentación técnica no se presenta centralmente. Debe conservarla el proveedor y ponerla a disposición de las autoridades de vigilancia del mercado y los organismos notificados a petición. El registro en la base de datos de IA de la UE (Art. 71) es obligatorio, pero el expediente técnico completo permanece con el proveedor.
Un documento formal firmado por el proveedor que declara que el sistema de IA cumple con los requisitos del Reglamento de IA de la UE. Debe incluir el nombre del sistema, la versión, la identidad del proveedor, una lista de los requisitos aplicables cumplidos, el procedimiento de evaluación de la conformidad utilizado y una referencia a las normas armonizadas pertinentes. Acompaña al marcado CE.
Stay ahead of AI Act changes
Get compliance alerts when deadlines or obligations change.
No spam. One-click unsubscribe.