Si tu sistema de IA esta clasificado como de alto riesgo, el Articulo 11 de la Ley de IA de la UE te obliga a preparar documentacion tecnica que cumpla los requisitos del Anexo IV — antes de poner el sistema en el mercado o ponerlo en servicio. Esta documentacion debe mantenerse actualizada durante todo el ciclo de vida del sistema.

El Anexo IV no es una sugerencia. Es la columna vertebral de la evaluacion de conformidad. Ya sea que te autoevalues bajo el Anexo VI o pases por un organismo notificado, este es el paquete documental que prueba que tu sistema cumple. Las autoridades nacionales de vigilancia del mercado pueden solicitarlo en cualquier momento, y tienen potestad para acceder a tu documentacion, conjuntos de datos y codigo fuente.

Esto es lo que realmente exige el Anexo IV, seccion por seccion.

Las nueve secciones del Anexo IV

1. Descripcion general del sistema de IA

Este es tu resumen ejecutivo. Cubre:

  • El proposito previsto del sistema y la identidad del proveedor
  • Como interactua el sistema con hardware o software externo
  • Numeros de version de software y firmware y requisitos de actualizacion
  • Formato de distribucion — si esta integrado en hardware, se entrega como paquete descargable, se accede via API o se despliega como servicio
  • Requisitos de hardware para que el sistema funcione
  • La interfaz de usuario proporcionada a los operadores
  • Instrucciones de uso para el operador

Si tu sistema de IA es un componente de un producto mayor, incluye fotografias o ilustraciones que muestren las caracteristicas externas, marcados y disposicion interna.

Esta seccion es sencilla pero a menudo subestimada. Las instrucciones de uso deben ser lo suficientemente detalladas para que los operadores puedan cumplir sus propias obligaciones bajo el Articulo 26 — incluyendo entender las capacidades, limitaciones y requisitos de supervision humana del sistema.

2. Proceso y metodologia de desarrollo

Esta es la seccion mas detallada y tecnicamente exigente. Cubre:

Especificaciones de diseno — la logica general del sistema y sus algoritmos, decisiones clave de diseno con su justificacion, para que esta disenado el sistema para optimizar, la relevancia de diferentes parametros, opciones de clasificacion, formato de salida esperado y expectativas de calidad de la salida.

Arquitectura del sistema — como los componentes de software se construyen sobre o alimentan entre si y se integran en el pipeline de procesamiento general.

Recursos computacionales — que hardware y computacion se uso para el desarrollo, entrenamiento, pruebas y validacion.

Requisitos de datos — aqui es donde la mayoria de empresas tiene dificultades. Debes documentar:

  • Metodologias y tecnicas de entrenamiento utilizadas
  • Conjuntos de datos de entrenamiento incluyendo su procedencia, alcance y caracteristicas principales
  • Como se obtuvieron y seleccionaron los datos
  • Procedimientos de etiquetado (quien etiqueto, que directrices, que controles de calidad)
  • Metodologias de limpieza de datos aplicadas

Medidas de supervision humana — las medidas tecnicas implementadas para ayudar a los operadores a interpretar las salidas del sistema, de acuerdo con el Articulo 14.

Cambios predeterminados — cualquier cambio al sistema y su rendimiento que fue planificado o anticipado en el momento de la evaluacion de conformidad inicial.

Validacion y pruebas — los procedimientos utilizados, los conjuntos de datos de validacion y prueba y sus caracteristicas, las metricas usadas para medir precision, robustez, cumplimiento e impactos potencialmente discriminatorios. Todos los registros e informes de prueba deben estar fechados y firmados por las personas responsables.

Medidas de ciberseguridad — que protecciones existen contra ataques adversarios, envenenamiento de datos, extraccion de modelos y otras amenazas especificas de IA.

3. Monitorizacion, funcionamiento y control

Esta seccion aborda el comportamiento del sistema en produccion:

  • Capacidades y limitaciones de rendimiento — incluyendo grados de precision para personas o grupos especificos sobre los que el sistema esta destinado a usarse, y la precision general esperada en relacion con el proposito previsto
  • Resultados no deseados previsibles — fuentes de riesgo para la salud, seguridad, derechos fundamentales y potencial de discriminacion
  • Especificaciones de supervision humana — las medidas tecnicas que permiten a los operadores humanos entender e intervenir en la operacion del sistema
  • Especificaciones de datos de entrada — que datos espera el sistema y en que formato

El enfasis en la precision desglosada por grupos demograficos es intencional. Si tu sistema tiene diferente rendimiento segun poblaciones (como la mayoria), debes documentarlo explicitamente.

4. Justificacion de metricas de rendimiento

Una seccion breve pero importante: debes explicar por que las metricas de rendimiento que elegiste son apropiadas para este sistema de IA especifico y su proposito previsto.

No se trata solo de reportar precision. Si usas F1 scores, AUC-ROC, compromisos precision-exhaustividad u otras metricas especificas del dominio, explica por que esas metricas capturan significativamente el rendimiento real del sistema y el cumplimiento de los requisitos de la Ley.

5. Sistema de gestion de riesgos

Una descripcion detallada del sistema de gestion de riesgos establecido bajo el Articulo 9. Esto no es un simple registro de riesgos — debe documentar:

  • Como se identificaron y analizaron los riesgos durante el ciclo de vida
  • Metodos de estimacion y evaluacion de riesgos
  • Medidas de mitigacion de riesgos y su efectividad
  • Riesgos residuales y si son aceptables
  • Como se integra el sistema de gestion de riesgos con el proceso general de desarrollo

El Articulo 9 requiere que el sistema de gestion de riesgos sea un proceso iterativo continuo planificado y ejecutado durante todo el ciclo de vida. Tu documentacion debe reflejar esto — no solo una evaluacion puntual.

6. Cambios durante el ciclo de vida

Un registro de todos los cambios relevantes realizados al sistema durante su ciclo de vida. Esto incluye cambios en:

  • Datos de entrenamiento o procesamiento de datos
  • Arquitectura del modelo o parametros
  • Comportamiento o caracteristicas de rendimiento del sistema
  • Proposito previsto o contexto de despliegue

Esta seccion convierte al Anexo IV de un entregable unico en un documento vivo. Necesitas un proceso para mantener registros de cambios, no solo un documento que escribes una vez y archivas.

7. Estandares armonizados aplicados

Aqui debes listar los estandares armonizados que aplicaste, referenciando su publicacion en el Diario Oficial de la UE.

El problema actual: a fecha de febrero de 2026, ningun estandar armonizado ha sido formalmente citado en el Diario Oficial. Siete estandares principales estan en desarrollo bajo CEN-CENELEC JTC 21, pero ninguno proporciona presuncion de conformidad todavia. El mas avanzado es prEN 18286 (Sistemas de Gestion de Calidad para cumplimiento de la Ley de IA), que entro en consulta publica en octubre de 2025. La entrega completa de estandares armonizados esta prevista para el Q4 de 2026 — despues del plazo de agosto.

Donde no se han aplicado estandares armonizados (que es la situacion de todos, ahora mismo), debes proporcionar descripciones detalladas de las soluciones alternativas que adoptaste para cumplir cada requisito, mas una lista de otros estandares y especificaciones tecnicas relevantes que seguiste.

En la practica, esto significa referenciar estandares como ISO/IEC 42001 (Sistemas de Gestion de IA), ISO/IEC 23894 (Gestion de Riesgos de IA) o las guias de la AESIA — reconociendo que estos no proporcionan presuncion formal de conformidad bajo la Ley de IA.

8. Declaracion de conformidad UE

Una copia de la declaracion de conformidad emitida bajo el Articulo 47. Este es un documento formal donde el proveedor declara que el sistema de IA cumple todos los requisitos aplicables del reglamento.

9. Sistema de monitorizacion post-mercado

Una descripcion detallada de como evaluaras el rendimiento del sistema despues del despliegue, incluyendo el plan de monitorizacion post-mercado requerido por el Articulo 72(3). Esto cubre:

  • Como recopilaras y analizaras datos sobre el rendimiento real del sistema
  • Que metricas monitorizaras post-despliegue
  • Como detectaras y responderas a la degradacion del rendimiento
  • Tus procedimientos de notificacion de incidentes
  • Como los hallazgos post-mercado retroalimentan el sistema de gestion de riesgos

Donde estan los estandares hoy

La situacion de los estandares crea incertidumbre real para las empresas que preparan documentacion ahora.

CEN-CENELEC JTC 21 esta desarrollando siete estandares armonizados principales que cubren gestion de riesgos, gobernanza de datos, transparencia, supervision humana, precision, robustez, ciberseguridad, gestion de sesgos y sistemas de gestion de calidad. Se esperaban originalmente para finales de 2025 pero ahora estan previstos para el Q4 de 2026. En octubre de 2025, CEN-CENELEC adopto medidas de aceleracion excepcionales — permitiendo que los estandares omitan la fase de votacion formal tras un voto de consulta positivo — para acelerar la entrega.

prEN 18286 es el estandar mas maduro. Su Anexo ZA mapea directamente los requisitos del SGC a los Articulos 11, 17 y 72 de la Ley de IA, convirtiendolo en lo mas cercano a un plan practico para el cumplimiento del Anexo IV.

ISO/IEC 42001, aunque reconocida internacionalmente, no forma parte del proceso de armonizacion de la UE. La Oficina de IA de la UE indico en 2024 que no se alinea completamente con el texto final de la Ley de IA. El JRC encontro que proporciona una cobertura limitada del registro y mantenimiento de registros. Es complementaria, no suficiente.

La implicacion practica: no puedes confiar en ningun estandar unico para presuncion de conformidad hoy. Debes documentar tu propio enfoque para cumplir cada requisito y estar preparado para explicarlo a los reguladores.

El factor Digital Omnibus

La propuesta Digital Omnibus (noviembre de 2025) podria aplazar el plazo de cumplimiento de alto riesgo hasta el 2 de diciembre de 2027 para sistemas del Anexo III, condicionado a que los estandares armonizados no esten listos. Tambien ampliaria los requisitos de documentacion simplificada de microempresas a todas las PYMEs e introduciria expectativas proporcionadas para empresas medianas-pequenas.

Pero el Omnibus sigue siendo una propuesta. Debe pasar por el Parlamento y el Consejo. Y aunque se adopte, las empresas todavia necesitaran demostrar esfuerzo de cumplimiento de "buena fe". Los requisitos de documentacion del Anexo IV no cambian — solo cuando deben estar listos.

La mejor orientacion disponible: AESIA

La Agencia Espanola de Supervision de la Inteligencia Artificial (AESIA) publico 16 documentos de orientacion practica en diciembre de 2025, desarrollados a traves de su sandbox regulatorio de IA donde se probaron 12 sistemas de IA reales en seis sectores.

La Guia 15 es un documento de 62 paginas centrado especificamente en documentacion tecnica. Cubre el contenido requerido, el formato preferido y las mejores practicas para estructurar y almacenar la documentacion del Anexo IV. Son los recursos de cumplimiento mas detallados disponibles publicamente para el Anexo IV, desarrollados por el primer organismo nacional de supervision de IA operativo de la UE.

Las guias no son vinculantes y se describen como "recursos vivos", pero ofrecen lo mas cercano a una referencia practica para la preparacion del Anexo IV. Puedes acceder a ellas en aesia.digital.gob.es.

Errores comunes

  1. Tratarlo como un documento unico. Las secciones 5, 6 y 9 exigen explicitamente mantenimiento continuo. Si tu documentacion es un PDF estatico de hace seis meses, ya no cumple.

  2. Generar documentos sin evidencia. Los reguladores buscan artefactos verificables — resultados de pruebas reales que influyeron en decisiones de diseno, evaluaciones de riesgo genuinas, registros de auditoria reales. Las afirmaciones sin evidencia no pasaran la evaluacion de conformidad.

  3. Ignorar la procedencia de los datos. La seccion 2 requiere documentacion detallada del origen de los datos de entrenamiento, criterios de seleccion, procedimientos de etiquetado y metodos de limpieza. Esto es casi imposible de reconstruir despues si no lo registraste durante el desarrollo.

  4. Omitir la justificacion de metricas. La seccion 4 es breve pero importante. "Usamos precision" no es una justificacion. Necesitas explicar por que tus metricas elegidas capturan significativamente el rendimiento real para tu caso de uso especifico.

  5. Esperar a los estandares armonizados. Los estandares llegan tarde. El plazo puede o no moverse. Empezar ahora con la orientacion disponible (AESIA, marcos ISO, el propio texto del reglamento) es mucho mejor que esperar una claridad perfecta.

Que hacer ahora

  1. Audita lo que ya tienes. La mayoria de equipos tienen fragmentos dispersos de documentacion del Anexo IV en documentos de diseno, notebooks de Jupyter, model cards y wikis internas. Haz un inventario de lo que existe e identifica las lagunas sistematicamente.

  2. Empieza por las secciones mas dificiles. Las secciones 2 (proceso de desarrollo) y 5 (gestion de riesgos) son las mas exigentes y las que mas probabilidades tienen de tener lagunas. Empieza por ahi mientras el conocimiento institucional esta fresco.

  3. Implementa procesos de documentacion. El cumplimiento del Anexo IV no es un documento — es un proceso. Establece documentacion con control de versiones, rastreo de linaje de datos y registros de cambios ahora. Cada semana que retrases hace que la documentacion retrospectiva sea mas dificil.

  4. Usa las guias de la AESIA como referencia. Los 16 documentos de orientacion practica de Espana son el recurso publico mas detallado disponible. La Guia 15 sobre documentacion tecnica es un punto de partida practico.

  5. Genera un primer borrador. Annexa puede analizar tu codigo (Python, YAML, JSON) y generar un primer borrador del dossier del Anexo IV, identificando lagunas y senalando secciones que necesitan revision legal. No sustituira el criterio de tu equipo de ingenieria, pero te da un punto de partida concreto en lugar de una pagina en blanco.

El plazo de agosto de 2026 puede o no moverse. Los requisitos de documentacion no cambiaran. Empieza ahora.