Anexo IV Ley de IA UE: la documentación técnica que exige

📋 Referencia rápida

Audiencia: CISOs, responsables de cumplimiento y directores de TI que gestionan despliegues de IA de alto riesgo en organizaciones de la UE
Tiempo de lectura: ~12 minutos
Qué obtendrás: Un desglose en lenguaje claro de las 7 secciones del Anexo IV: qué exige cada una, qué aporta Microsoft y qué debes producir tú

Tu equipo legal te acaba de entregar un informe sobre el cumplimiento de la Ley de IA de la UE. Lees el resumen ejecutivo. Tres viñetas. Ninguna te dice qué necesitas producir realmente antes del 2 de agosto.

Esto es lo que se les escapó: la documentación técnica del Anexo IV no es un documento de políticas. Es un registro técnico vivo. Y la brecha entre lo que la mayoría de las empresas tiene hoy y lo que los reguladores pedirán el 2 de agosto es más amplia de lo que la mayoría de los líderes de TI cree.

Por qué la documentación técnica es la obligación central de cumplimiento

La arquitectura de cumplimiento de la Ley de IA de la UE se centra en la documentación. A diferencia de marcos que se basan principalmente en auditorías o pruebas, la Ley de IA de la UE espera que las organizaciones mantengan documentación continua de sus sistemas de IA: documentación que las autoridades pueden revisar bajo petición, sin previo aviso.

Esta documentación cumple tres funciones que la mayoría de los líderes de TI subestima:

• Evidencia de cumplimiento: Demuestra que evaluaste los riesgos, implementaste la gobernanza y estableciste la supervisión humana antes de desplegar
• Pista de auditoría: Muestra cómo evolucionó el sistema de IA a lo largo del tiempo y qué cambios se revisaron
• Base para la conformidad: Para sistemas que requieren evaluación por terceros, la documentación es el punto de partida, no el resultado

La distinción crítica que nadie te cuenta: Una presentación titulada "Marco de gobernanza de IA" no es documentación del Anexo IV. El folleto de producto de un proveedor no es documentación del Anexo IV. Un resumen de riesgos de una página escrito por Legal no es documentación del Anexo IV. El Anexo IV es un registro técnico que requiere contenido específico en 7 secciones definidas, y debe mantenerse durante todo el ciclo de vida del sistema.

Las 7 secciones del Anexo IV: qué exige realmente cada una

Sección 1: Descripción general del sistema de IA

Es la sección más accesible y la que más a menudo se hace mal. Una "descripción general" según el Anexo IV no es un resumen de marketing. Debe incluir: la finalidad prevista (específica, no genérica), todos los componentes del sistema incluido el software y el hardware relevante, la versión y el producto asociado, cómo interactúa el sistema con otros sistemas, y las instrucciones de uso.

Para despliegues de Microsoft, las Notas de Transparencia de Azure AI aportan la descripción general a nivel de modelo. Lo que debes añadir tú: el servicio concreto, en qué configuración, conectado a qué fuentes de datos, para qué finalidad de negocio precisa en tu organización.

Una entrada conforme se ve así: "Azure OpenAI Service (GPT-4o vía Copilot Studio), desplegado como agente de FAQ de políticas de RR. HH., conectado a la base de conocimiento interna de SharePoint, accesible para todos los empleados vía Microsoft Teams. Finalidad prevista: responder a consultas de empleados sobre las políticas de RR. HH. de la empresa. No diseñado para tomar ni fundamentar decisiones de empleo."

Sección 2: Descripción detallada de la arquitectura técnica

Esta sección va más a fondo: especificaciones de diseño, lógica general del sistema, decisiones arquitectónicas clave, metodología de entrenamiento si aplica, y cómo interactúan los componentes de software. Para despliegues estándar de Copilot, buena parte de esto está cubierta por la documentación publicada de Microsoft sobre la arquitectura del modelo.

Tu documentación específica del despliegue debe centrarse en: qué plugins o extensiones están habilitados, qué conectores de datos están configurados, qué controles de acceso y permisos aplican, y cualquier personalización o ingeniería de prompts aplicada.

Para despliegues personalizados de Azure AI, consulta la documentación de Azure OpenAI Service como base técnica, y luego documenta tu configuración y tus decisiones de personalización específicas.

Sección 3: Monitorización, funcionamiento y control

Esta es la sección más directamente ligada al Artículo 14 (supervisión humana). Debe cubrir: qué métricas se monitorizan, quién revisa los resultados de la monitorización, qué desencadena una revisión o una acción de remediación, el período de retención de los registros de auditoría, y cómo pueden los humanos intervenir o anular el sistema.

Azure Monitor y Microsoft Purview aportan la infraestructura de monitorización. Tu documentación debe describir el proceso que usa esa infraestructura: quién vigila los paneles, qué desencadena una anomalía y con qué rapidez puede intervenir un humano.

Sección 4: Documentación del sistema de gestión de riesgos

Esta es la sección que no se puede tomar prestada de la documentación de Microsoft. La evaluación de riesgos de tu despliegue concreto —qué riesgos existen en tu contexto de negocio, para qué empleados o clientes, en qué condiciones— es tuya y la debes producir tú.

Un agente de cribado de CV en una empresa de logística tiene riesgos distintos de la misma tecnología en una organización sanitaria. La documentación de gestión de riesgos debe reflejar tu contexto de despliegue. La Guía de Evaluación de Impacto de IA Responsable de Microsoft ofrece un marco metodológico; la evaluación en sí es tu trabajo.

Sección 5: Registro de cambios

Un registro de cambios que documente las modificaciones significativas a lo largo del ciclo de vida del sistema de IA, incluyendo si se requiere una nueva evaluación de conformidad tras cada cambio. Para servicios gestionados por Microsoft, las actualizaciones del modelo las despliega Microsoft; tu registro de cambios debería capturarlas junto con tus propios cambios de configuración.

Establece un proceso para revisar regularmente las notas de versión de los servicios de Azure AI y evaluar si las actualizaciones afectan a tu documentación de cumplimiento. Esta es una brecha de proceso en casi todas las empresas con las que he trabajado.

Sección 6: Normas y especificaciones aplicadas

Una lista de normas armonizadas de la UE, especificaciones comunes u otras normas técnicas aplicadas al sistema de IA. Para los servicios de IA de Microsoft, las normas relevantes están documentadas en la documentación de cumplimiento de Microsoft. Las referencias relevantes incluyen ISO/IEC 42001 (Sistemas de Gestión de IA) y el Marco de Gestión de Riesgos de IA del NIST.

Sección 7: Declaración UE de conformidad

Para los sistemas sujetos a evaluación de conformidad, una copia de la Declaración UE de Conformidad firmada por el proveedor. Para la mayoría de los servicios de IA de Microsoft, Microsoft como proveedor la facilitará. Tu tarea: obtenerla, archivarla en tu repositorio de gobernanza y verificar que cubre el servicio y la versión concretos que estás desplegando.

Tres fallos de documentación que evitar

• Depender solo de la documentación del proveedor. Las Notas de Transparencia de Microsoft documentan el modelo, no tu despliegue. Archívalas como anexos; produce tu documentación de despliegue como registro principal.
• Documentación estática que no refleja el estado actual. Asigna el mantenimiento de la documentación a un responsable con nombre y una cadencia de revisión trimestral. Documentación producida en 2025 que no refleja un cambio de configuración de 2026 es una brecha de cumplimiento.
• Sin proceso para revisar las actualizaciones de Microsoft. Microsoft actualiza los modelos de Azure AI regularmente. Algunas actualizaciones cambian materialmente el comportamiento del modelo. Sin un proceso definido para revisar las notas de versión y evaluar su impacto en la documentación, tu registro del Anexo IV se quedará desactualizado en silencio.

Una estructura práctica de plantilla del Anexo IV

Usa esta estructura para cada despliegue de IA de alto riesgo de tu organización:

Por dónde empezar si hoy no tienes documentación:
1. Completa la Sección 1 (Descripción general) de cada sistema de alto riesgo: la sección más rápida, establece el alcance
2. Descarga las Notas de Transparencia de Microsoft de los servicios relevantes y archívalas como anexos
3. Asigna la Sección 4 (Gestión de riesgos) a un flujo de trabajo conjunto de TI/Legal: la más intensiva en tiempo y la más específica de la organización
4. Establece el proceso del registro de cambios antes que nada: es la única sección que requiere disciplina continua desde el primer día

Preguntas frecuentes

¿Microsoft me proporciona la documentación técnica del Anexo IV?

Parcialmente. Microsoft aporta material a nivel de proveedor —notas de transparencia, fichas de modelo, documentación de seguridad y privacidad— que tú citas como evidencia. Pero el Anexo IV describe tu despliegue: tus casos de uso, tu evaluación de riesgos, tu supervisión humana. La capa del proveedor es una entrada, no el entregable terminado.

¿Qué extensión debe tener la documentación del Anexo IV?

No hay un número de páginas. La prueba es la suficiencia: ¿puede un regulador reconstruir cómo funciona tu sistema, qué riesgos evaluaste y cómo los controlas? Un registro enfocado y preciso de diez páginas vale más que cincuenta de relleno. Escribe para un auditor que no sabe nada de tu entorno.

Tenemos buena gobernanza pero poco por escrito. ¿Cumplimos?

No. Bajo un marco basado en la evidencia, la gobernanza no documentada es gobernanza no demostrable, y lo no demostrable es incumplimiento. Lo contrario es peor: documentación que describe controles que en realidad no ejecutas es engañosa. La documentación y la práctica del día a día tienen que coincidir.

¿Con qué frecuencia hay que actualizar la documentación técnica?

Trátala como un documento vivo. Los cambios materiales —un nuevo caso de uso, una actualización del modelo, una evaluación de riesgos revisada— deberían desencadenar una actualización, registrando el cambio y la fecha. La disciplina de versionado desde el primer día es mucho más barata que reconstruir un año de cambios la semana antes de una auditoría.

La documentación es la prueba de que tu gobernanza es real

La documentación técnica es necesaria pero no suficiente para el cumplimiento de la Ley de IA de la UE. Las organizaciones que tienen documentación pero ningún proceso real de gestión de riesgos siguen incumpliendo. Pero las organizaciones con una gobernanza excelente y sin documentación también incumplen, porque no pueden demostrar su cumplimiento a los reguladores.

En un marco regulatorio construido en torno a la evidencia, la documentación no es burocracia. Es la prueba de que tu programa de gobernanza existe.