Artículo 11 de la Ley de IA de la UE: documentación técnica para los sistemas de IA de alto riesgo
El Artículo 11 exige que los proveedores elaboren un expediente técnico del Anexo IV antes de desplegar IA de alto riesgo. Nueve secciones, conservación de 10 años. Plazo: 2 dic 2027.
Antes de que un sistema de IA de alto riesgo llegue al mercado — o se ponga en servicio —, su proveedor debe disponer de un expediente técnico completo. Esa obligación proviene del Artículo 11 del Reglamento (UE) 2024/1689. La documentación debe demostrar que el sistema satisface todos los requisitos del Capítulo III, Sección 2 (Artículos 9 a 15), y debe dar a las autoridades nacionales competentes detalle suficiente para evaluar el cumplimiento sin conjeturas. El contenido se especifica en el Anexo IV.
Esto no es una ocurrencia burocrática de última hora. El expediente técnico es la base probatoria principal de la evaluación de la conformidad con arreglo al Artículo 43, el documento que un organismo notificado revisa cuando evalúa si su sistema puede entrar legalmente en el mercado de la UE. Si está incompleto, la evaluación de la conformidad fracasa. Si falta, no puede desplegar legalmente. Si es engañoso, el techo sancionador del Artículo 99 es de 15 000 000 EUR o el 3 % del volumen de negocios anual mundial — la cifra que sea mayor.
En virtud del Ómnibus Digital acordado en mayo de 2026, el plazo para los sistemas de IA de alto riesgo autónomos (Anexo III) es el 2 de diciembre de 2027. Para la IA de alto riesgo integrada como componente de seguridad en productos regulados (Anexo I), es el 2 de agosto de 2028. La fecha original de agosto de 2026 se ha aplazado. Ese tiempo adicional no hace más pequeña la tarea de documentación — el Anexo IV es específico, y montar un expediente completo para un sistema no trivial suele llevar varios meses.
Quién debe elaborar la documentación del Artículo 11
La obligación recae sobre el proveedor — la entidad que desarrolla un sistema de IA de alto riesgo y lo introduce en el mercado o lo pone en servicio con su propio nombre o marca (Artículo 3, apartado 3). Una empresa de SaaS que construye y vende una herramienta de cribado de selección de personal, una fintech que despliega su propio modelo de calificación crediticia, una empresa emergente de tecnología sanitaria que comercializa un sistema de triaje médico: cada una es un proveedor y debe elaborar el expediente del Anexo IV.
Los responsables del despliegue — organizaciones que utilizan un sistema de alto riesgo construido por otra persona — no soportan directamente la obligación del Artículo 11. Pero el Artículo 25 crea una trampa: si un responsable del despliegue modifica sustancialmente un sistema de alto riesgo, o amplía su finalidad prevista más allá del alcance original, se convierte en proveedor y la obligación de documentación se transfiere.
La documentación debe elaborarse antes de que el sistema se introduzca en el mercado o se ponga en servicio, no a posteriori. Esa cronología importa: los equipos que tratan la documentación de cumplimiento como una tarea posterior al lanzamiento se encuentran incapaces de superar la evaluación de la conformidad del Artículo 43 y bloqueados legalmente para desplegar.
Qué exige el Anexo IV: nueve secciones de documentación
El Anexo IV especifica nueve categorías de contenido. La Ley da a las pymes (incluidas las empresas emergentes) la opción de aportar estos elementos de forma simplificada; la Comisión está facultada para adoptar el modelo simplificado. Aun así, el fondo debe abarcar las nueve secciones — simplificado significa una presentación condensada, no menos elementos.
1. Descripción general del sistema
La primera sección establece qué es el sistema y qué se supone que hace. Los elementos exigidos incluyen:
- La finalidad prevista, expresada con suficiente precisión para que una autoridad no familiarizada con su negocio pueda evaluar el alcance del despliegue (p. ej., «puntúa la solvencia para préstamos personales sin garantía de 5 000 a 50 000 EUR a consumidores particulares en Alemania y Austria»).
- La identidad del proveedor, incluidos el nombre, el domicilio social y cualquier representante autorizado (Artículo 22) si el proveedor está establecido fuera de la UE.
- El identificador de versión y una descripción de en qué se diferencia el sistema de versiones anteriores — cambios de algoritmo, reentrenamiento con datos nuevos, umbrales de decisión revisados.
- Cómo interactúa el sistema con el hardware y el software con los que está previsto que se utilice, incluidas cualesquiera dependencias de API o infraestructuras de terceros.
- Las formas en que se introduce en el mercado o se pone en servicio — despliegue en las instalaciones, SaaS en la nube, API, módulo integrado.
- Cualquier hardware en el que esté previsto que el sistema funcione, incluidas las especificaciones mínimas.
- Fotografías o ilustraciones cuando ayuden a comprender la arquitectura del sistema o el despliegue físico.
- Instrucciones de uso para los responsables del despliegue, que cubran la finalidad prevista del sistema, las contraindicaciones (casos de uso para los que el sistema no está diseñado) y el nivel de exactitud que los usuarios deben esperar.
2. Descripción detallada del proceso de desarrollo
Esta es la sección más extensa y la que con más frecuencia presenta carencias. Cubre cómo se construyó el sistema.
Especificaciones de diseño y arquitectura: documente la arquitectura del sistema — si utiliza árboles de decisión, métodos de conjunto, redes neuronales o lógica basada en reglas — y la justificación de las decisiones de diseño que afectan a la exactitud, la equidad o los modos de fallo. Un diagrama de arquitectura de alto nivel es lo habitual.
Gobernanza de datos y fichas técnicas (datasheets): para cada conjunto de datos utilizado en el entrenamiento, la validación y la prueba, el Anexo IV exige una ficha técnica: origen de los datos, metodología de recopilación, composición demográfica (edad, sexo, geografía, otras características pertinentes), pasos de preprocesamiento, procedimientos de aseguramiento de la calidad y limitaciones conocidas. El Artículo 10 establece las obligaciones de gobernanza de datos que sustentan esta documentación; lo que exige la sección 2 del Anexo IV es el registro probatorio de que se siguió el Artículo 10.
Evaluación de la supervisión humana conforme al Artículo 14: la sección de desarrollo debe mostrar cómo el diseño respalda los mecanismos de supervisión humana exigidos por el Artículo 14. Eso significa documentar qué puede observar un operador humano, sobre qué puede intervenir, qué significan en la práctica los resultados del sistema y cómo la interfaz hace visibles las limitaciones. No se trata de una nota de procedimiento operativo (eso va en la sección 3); se trata de una evaluación en fase de diseño de si la arquitectura permite una supervisión significativa.
Cambios predeterminados y aprendizaje continuo: si el sistema está diseñado para actualizar sus parámetros automáticamente tras el despliegue — un modelo de aprendizaje continuo —, la documentación debe describir los límites de ese aprendizaje, las condiciones que desencadenan las actualizaciones y cómo controla el proveedor la deriva del modelo. Los sistemas con parámetros fijos tras el despliegue son más sencillos de documentar aquí, pero la sección debe igualmente confirmar que los parámetros están congelados y explicar la gobernanza en torno a los ciclos de reentrenamiento.
Procedimientos de validación y prueba: documente el programa de pruebas completo: metodología de validación cruzada, composición del conjunto de prueba reservado (incluidos los desgloses demográficos), validación temporal frente a datos que reflejen las condiciones actuales, pruebas adversarias y cobertura de casos límite. Para cada métrica notificada — exactitud, precisión, exhaustividad (recall), F1, AUC-ROC —, la documentación debe mostrar cómo se calculó y con qué datos. El análisis por subgrupos es obligatorio: el rendimiento desglosado por características protegidas (sexo, edad, etnia, discapacidad) es lo que exige el Artículo 10, apartado 3, y la sección 2 del Anexo IV es donde se registran los resultados.
Registros (logs): documente la arquitectura de registro — qué registra el sistema en el momento de la inferencia, cuánto tiempo se conservan los registros, quién puede acceder a ellos y cómo respaldan los registros la revisión posterior a un incidente. El Artículo 12 aborda por separado las obligaciones de conservación de registros; la sección 2 del Anexo IV documenta el diseño técnico que hace posible el cumplimiento del Artículo 12.
Ejemplo práctico de pyme: una empresa de tecnología de RR. HH. de 35 personas en los Países Bajos proporciona una herramienta de cribado de currículos a empleadores del mercado medio de toda la UE. Con arreglo a la categoría 4 del Anexo III (empleo y gestión de los trabajadores), es un proveedor de alto riesgo. Para la sección 2, la empresa debe documentar que su conjunto de entrenamiento comprende 1,2 millones de solicitudes de empleo recopiladas entre 2019 y 2024, con desgloses demográficos por sexo (54 % de solicitantes hombres, 46 % mujeres), franja de edad y país de origen. Debe registrar que realizó pruebas de equidad utilizando las métricas de paridad demográfica y de igualdad de probabilidades (equalized odds), identificando una disparidad de 4,2 puntos porcentuales para los solicitantes mayores de 55 años, y documentando el ajuste de umbral que aplicó para llevar la disparidad a límites aceptables.
3. Información detallada sobre la vigilancia, el funcionamiento y el control
La sección 3 pasa del momento de construcción al de ejecución. Cubre cómo opera el sistema una vez desplegado: la arquitectura de vigilancia, las condiciones en las que el sistema debe y no debe utilizarse, los controles existentes cuando produce resultados inesperados y los procedimientos para una desconexión o suspensión segura.
Esta sección debe leerse junto con las obligaciones de supervisión humana del Artículo 14. La documentación debe mostrar que un operador humano — no solo técnicamente capaz, sino dotado de las herramientas y la información — puede comprender los resultados del sistema e intervenir de forma significativa. Elementos concretos: la interfaz que utiliza el operador, la información mostrada en el momento de la inferencia, la vía de anulación, qué le ocurre a una decisión cuando un humano la anula, y si las anulaciones se registran y cómo.
4. Adecuación de las métricas de rendimiento
La sección 4 pide a los proveedores que justifiquen la elección de las métricas de rendimiento, no que se limiten a notificarlas. Si seleccionó el AUC-ROC como su métrica principal para un sistema de calificación crediticia, necesita explicar por qué esa métrica es adecuada para una decisión crediticia binaria — y reconocer que una métrica que capta la discriminación agregada no capta automáticamente el impacto dispar sobre un subgrupo demográfico concreto.
Esta es la sección donde las autoridades buscan ver si los proveedores comprenden su sistema o si están repitiendo de forma acrítica la evaluación estándar del aprendizaje automático. Una sección 4 bien redactada muestra que el proveedor consideró el perjuicio posterior que el sistema podría causar, eligió métricas sensibles a esos perjuicios y aceptó explícitamente los compromisos.
5. El sistema de gestión de riesgos
El Artículo 9 exige que los proveedores establezcan y mantengan un sistema de gestión de riesgos que cubra todo el ciclo de vida del sistema de IA de alto riesgo. La sección 5 del Anexo IV es el registro documental de ese sistema. Debe describir la metodología de identificación de riesgos, la evaluación de la probabilidad y la gravedad de cada riesgo identificado, las mitigaciones aplicadas, el riesgo residual aceptado y los procedimientos de vigilancia que detectarán los riesgos emergentes tras el despliegue.
Los riesgos que el Artículo 9 tiene en mente son riesgos para la salud, la seguridad y los derechos fundamentales — no el riesgo empresarial genérico. Para una herramienta de cribado de selección de personal, eso significa documentar el riesgo de una preselección discriminatoria para los grupos protegidos, la probabilidad de que ese perjuicio se produzca dados los datos de entrenamiento, las mitigaciones aplicadas (pruebas de equidad, ajuste de umbral, revisión humana obligatoria para las puntuaciones límite) y la disparidad residual que aún persiste. Para un modelo de calificación crediticia, significa documentar el riesgo de denegar sistemáticamente el crédito a determinados grupos demográficos y la cadena de mitigaciones que mantiene ese riesgo dentro de la tolerancia declarada del proveedor.
6. Cambios a lo largo del ciclo de vida
La sección 6 es el registro de cambios. Toda modificación que pudiera afectar al cumplimiento del sistema — reentrenamiento del modelo con datos nuevos, revisión de los umbrales de decisión, extensión a un nuevo caso de uso, cambios en el hardware en el que funciona — debe registrarse aquí, con la fecha, la naturaleza del cambio y la evaluación de cumplimiento que determinó si el cambio activó una nueva evaluación de la conformidad con arreglo al Artículo 43.
No todo cambio requiere una nueva evaluación del Artículo 43. Pero los proveedores deben tener un proceso documentado para tomar esa decisión, y la sección 6 es donde residen los resultados de ese proceso.
7. Normas aplicadas
Enumere todas las normas armonizadas, especificaciones técnicas o especificaciones comunes aplicadas durante el desarrollo y las pruebas. Cuando se haya utilizado una norma armonizada con arreglo al Artículo 40, anote la presunción de conformidad que confiere para los requisitos que cubre. Cuando no existiera una norma armonizada para un requisito concreto, documente el método alternativo utilizado para demostrar la conformidad y por qué es adecuado.
En el momento de redactar esto, las normas armonizadas de la Ley de IA de la UE aún están siendo ultimadas por CEN-CENELEC. Los proveedores que desarrollen antes del 2 de diciembre de 2027 deben documentar cualquier norma ISO/IEC aplicable que hayan aplicado — ISO/IEC 42001 (sistemas de gestión de IA), ISO/IEC 23894 (gestión de riesgos de la IA), ISO/IEC 25059 (calidad del software para la IA) — junto con cualquier alineación con el NIST AI RMF, señalando que estas aún no conllevan una presunción formal de conformidad con arreglo a la Ley.
8. Declaración UE de conformidad
La sección 8 del Anexo IV exige que el expediente técnico incluya una copia de la declaración UE de conformidad elaborada con arreglo al Artículo 47. La declaración confirma que el proveedor ha completado la evaluación de la conformidad con arreglo al Artículo 43, que el sistema cumple los requisitos del Capítulo III, Sección 2, y que el proveedor asume la responsabilidad de esa conformidad. Debe ir firmada por una persona autorizada para representar al proveedor y debe contener los datos especificados en el Anexo V.
Un error habitual: los proveedores tratan la declaración como un documento independiente y omiten incluirla en el expediente técnico. Pertenece a ambos lugares.
9. Plan de vigilancia poscomercialización
La sección 9 del Anexo IV exige una descripción del sistema de vigilancia poscomercialización que el proveedor está obligado a establecer con arreglo al Artículo 72. El plan de vigilancia debe especificar cómo recopilará el proveedor activamente datos sobre el rendimiento del sistema en el despliegue en condiciones reales, las métricas que rastreará, los umbrales que desencadenarán medidas correctoras y los procedimientos para notificar incidentes graves con arreglo al Artículo 73.
Para la mayoría de los sistemas de alto riesgo autónomos, el plan de vigilancia debe abordar: cómo se recopilan y agregan los registros de inferencia, cómo se rastrean a lo largo del tiempo las métricas de exactitud y de equidad, qué nivel de degradación del rendimiento desencadena una revisión, cómo detectará el proveedor el desplazamiento de la distribución (datos de entrenamiento que ya no reflejan a los usuarios actuales) y cómo retroalimentan el ciclo de revisión los comentarios de los clientes o los informes de incidentes.
Conservación: 10 años con arreglo al Artículo 18
El Artículo 18 exige que los proveedores mantengan la documentación técnica a disposición de las autoridades nacionales competentes durante 10 años desde que el sistema se introduce en el mercado o se pone en servicio. Para la IA de alto riesgo integrada en productos cubiertos por la legislación de armonización (Anexo I), la obligación de conservación refleja el reglamento de seguridad de los productos pertinente, que puede especificar un período distinto.
Diez años es mucho tiempo en software. Los proveedores deben pensar ya en la gestión de la documentación: almacenamiento con control de versiones, controles de acceso, una política de conservación que sobreviva a la rotación de personal y un proceso para mantener el expediente actualizado a medida que el sistema evoluciona. Las autoridades competentes pueden solicitar el expediente técnico en cualquier momento durante el período de conservación.
La conexión con la evaluación de la conformidad
El expediente técnico es el dato de entrada de la evaluación de la conformidad con arreglo al Artículo 43. Para la mayoría de los sistemas de alto riesgo del Anexo III, el Artículo 43, apartado 2, permite la autoevaluación por parte del proveedor — el proveedor revisa su propia documentación, concluye que demuestra el cumplimiento, elabora la declaración UE de conformidad con arreglo al Artículo 47 y coloca el marcado CE con arreglo al Artículo 48. A continuación se realiza el registro en la base de datos de la UE con arreglo al Artículo 49.
Para un conjunto más estrecho de sistemas — determinados sistemas de identificación biométrica y sistemas en ámbitos sensibles en los que se aplica el Anexo VII —, la evaluación de la conformidad requiere un organismo notificado. El organismo notificado revisa el expediente técnico con arreglo a los procedimientos del Anexo VI o VII. Sin un expediente del Anexo IV completo, el organismo notificado no puede proceder.
En cualquier caso, el expediente técnico es lo que la evaluación de la conformidad revisa. Las carencias del expediente son carencias de la evaluación. Los proveedores que retrasen la documentación hasta después del desarrollo se encontrarán reconstruyendo grandes secciones de memoria, lo que es a la vez lento y menos creíble que los registros coetáneos.
Disposiciones para pymes y empresas emergentes
El Artículo 11, apartado 3, dispone que las pymes, incluidas las empresas emergentes, pueden aportar los elementos del Anexo IV de forma simplificada. La Comisión debe establecer el formato del modelo simplificado. Esta es una medida de proporcionalidad genuina: una empresa de 12 personas que construye su primer sistema de alto riesgo no debería necesitar un expediente de 200 páginas en el mismo formato que una gran empresa.
Lo que simplificado significa en la práctica es presentación, no fondo. El modelo simplificado seguirá teniendo que cubrir las nueve secciones del Anexo IV; estará estructurado para guiar a los proveedores más pequeños a través de ellas de forma eficiente. Los proveedores que quieran utilizar el modelo simplificado deben vigilar los actos de ejecución de la Comisión a medida que se adopten antes del 2 de diciembre de 2027.
Un punto sobre las sanciones que importa para las pymes: con arreglo al Artículo 99, apartado 6, las multas para las pymes y las empresas emergentes se limitan al menor del importe fijo y la cifra porcentual del volumen de negocios. Una empresa emergente con 2 millones de euros de ingresos anuales afronta un techo muy por debajo de los 15 millones de euros por un incumplimiento del Artículo 11 — pero el límite del porcentaje del volumen de negocios (3 %) puede seguir siendo material, y las consecuencias operativas de una orden de cumplimiento o una suspensión de mercado son graves con independencia del tamaño de la empresa.
Un ejemplo trabajado: proveedor de tecnología de RR. HH. del mercado medio
Considere una empresa de 40 personas en Viena que ofrece una API de clasificación de currículos a departamentos de RR. HH. corporativos de toda la región DACH. El sistema puntúa las solicitudes de empleo y clasifica a los candidatos para su revisión humana. Entra en la categoría 4 del Anexo III y la empresa es el proveedor con arreglo al Artículo 3, apartado 3.
Su evaluación de la conformidad del Artículo 43 es la autoevaluación — no se requiere organismo notificado para esta categoría. Pero el expediente técnico debe igualmente cubrir las nueve secciones del Anexo IV, validado antes de que la API se ponga a disposición de los clientes.
Para la sección 1, documentan la finalidad prevista (clasificar, no seleccionar — los resultados son clasificaciones para revisores humanos, no decisiones de contratación autónomas), la arquitectura de despliegue de la API y las instrucciones de uso que proporcionan a los clientes responsables del despliegue, incluidas contraindicaciones explícitas (la API no debe utilizarse como único determinante de ninguna decisión de contratación).
Para la sección 2, elaboran fichas técnicas para tres conjuntos de datos utilizados en el entrenamiento y la validación, incluyen los resultados de las pruebas de equidad y documentan el diseño del algoritmo de clasificación y el razonamiento que respalda las métricas de rendimiento seleccionadas. La supervisión humana a nivel del responsable del despliegue se respalda mediante una puntuación de confianza mostrada con cada clasificación y una restricción de diseño que impide que cualquier candidato sea descartado sin que la clasificación sea visible para el revisor humano.
Para la sección 5, el registro de riesgos cubre la clasificación discriminatoria de los candidatos mayores de 55 años (identificada en las pruebas), la calibración de umbral aplicada para reducir la disparidad por debajo de 2 puntos porcentuales y el riesgo residual aceptado.
Para la sección 9, el plan de vigilancia poscomercialización exige comprobaciones mensuales de la exactitud frente a un conjunto reservado rotatorio y una revisión trimestral de la equidad por subgrupos, con un canal de notificación de incidentes para clientes que retroalimenta el ciclo de revisión.
El expediente completo abarca aproximadamente 80 páginas. Está sometido a control de versiones en su repositorio de cumplimiento y se mantiene a disposición de la autoridad austriaca de vigilancia del mercado durante 10 años desde la fecha en que la API se puso en marcha por primera vez.
Cómo ayuda Confir
El área de cumplimiento AITR de Confir (Datos y Robustez Técnica, que cubre los Artículos 10, 11 y 15) genera el paquete de documentación técnica del Anexo IV a través de un proceso de admisión estructurado. Los proveedores recorren las nueve secciones del Anexo IV mediante preguntas en lenguaje sencillo; el motor basado en reglas deriva el resultado exigido — un Paquete de Conformidad listo para imprimir — sin requerir que los proveedores interpreten el Anexo directamente.
El flujo de trabajo de AITR también se conecta con la declaración UE de conformidad del Artículo 47 generada en el área AIRC, de modo que la declaración está disponible desde el principio para incluirla en el expediente técnico (sección 8). El paquete de documentación se conserva en el sistema de registro de auditoría de Confir y puede exportarse íntegramente para su presentación a las autoridades competentes o a los organismos notificados.
Qué aspecto tienen los fallos de documentación en la práctica
Tres patrones aparecen repetidamente en contextos de ejecución.
Finalidad prevista imprecisa. «El sistema evalúa la idoneidad del candidato» es insuficiente. Las autoridades competentes necesitan comprender qué decisiones alimenta el sistema, qué aspecto tiene el resultado, qué significan los umbrales de puntuación y si esos umbrales se han calibrado. Una declaración imprecisa impide tanto la evaluación de la conformidad como una revisión significativa de la supervisión humana.
Ausencia de pruebas por subgrupos. Las cifras de exactitud globales que enmascaran disparidades demográficas son una carencia habitual y grave. El Artículo 10, apartado 3, exige pruebas de sesgo; la sección 2 del Anexo IV es donde residen los resultados. Un proveedor que no puede aportar métricas de rendimiento por subgrupos probablemente no haya realizado las pruebas.
Documentación obsoleta. Un sistema reentrenado con datos nuevos sin la correspondiente actualización del expediente técnico es no conforme. La sección 6 debe registrar todo cambio material y la sección 2 debe estar actualizada. Las autoridades competentes que inspeccionen dos años después del lanzamiento al mercado esperan ver un expediente que refleje el sistema tal como se despliega hoy, no tal como se diseñó en 2024.
Qué hacer ahora
El plazo del 2 de diciembre de 2027 crea una ventana de planificación, no un vacío que ignorar. Montar un expediente del Anexo IV completo para un sistema no trivial suele llevar entre tres y cinco meses la primera vez: los procedimientos de gobernanza de datos deben documentarse de forma coetánea, las pruebas de equidad deben diseñarse y ejecutarse, el sistema de gestión de riesgos debe producir registros y el diseño de la supervisión humana debe evaluarse antes de que la arquitectura quede fijada.
Los proveedores que empiecen a documentar a mediados de 2027 encontrarán el plazo incómodamente cerca. Los que empiecen ahora — incorporando la práctica de documentación a su flujo de trabajo de desarrollo — tendrán un expediente que será a la vez más completo y más creíble cuando las autoridades competentes lo pidan.
Guías relacionadas
- herramientas de gestión de inventario de sistemas de IA
- resumen del cumplimiento de la Ley de IA de la UE
- soluciones de software de cumplimiento de la Ley de IA de la UE
- plataforma de gobernanza de la IA para el cumplimiento
- requisitos de clasificación de la IA de alto riesgo
- soluciones de software de gobernanza
Gestiona el cumplimiento de la Ley de IA de la UE en un solo lugar
Confir automatiza la clasificación de riesgo, la documentación técnica y los registros de auditoría para cualquier empresa. Sin consultores. Sin proyectos de seis meses. Prueba gratuita de 7 días.
Empieza la prueba gratuita →