Análisis jurídico completo para empresas y administraciones públicas. La guía oficial de la AESIA más el criterio de iusia para el asesoramiento práctico.
El artículo 11 del AI Act obliga a los proveedores de sistemas de alto riesgo a elaborar la documentación técnica antes de la comercialización del sistema y a mantenerla actualizada durante toda su vida útil y durante diez años después de que el sistema haya sido retirado del mercado. El contenido mínimo de esta documentación está establecido en el Anexo IV del Reglamento. La Guía 15 de la AESIA, con 55 páginas, es el manual práctico para construir este expediente técnico.
La documentación técnica es el documento que centraliza toda la evidencia de que el sistema cumple los requisitos del AI Act. No es un documento que se elabora para cumplir una formalidad — es el expediente que las autoridades supervisoras pedirán en cualquier inspección, que los organismos notificados revisarán en la evaluación de conformidad, y que los desplegadores sofisticados exigirán revisar antes de poner en servicio el sistema. Su calidad y completitud reflejan directamente la madurez del proceso de cumplimiento del proveedor.
La guía distingue la documentación técnica del Anexo IV de otros documentos obligatorios del AI Act. La documentación técnica es el expediente integral del sistema — contiene o referencia todos los demás documentos. La declaración UE de conformidad del art. 47 es un documento más breve que resume el resultado de la evaluación de conformidad. Las instrucciones de uso del art. 13 son el documento dirigido al desplegador. El plan de vigilancia poscomercialización del art. 72 puede ser un anexo a la documentación técnica o un documento separado referenciado en ella. El registro en la base de datos de la UE es un extracto público de los datos más relevantes de la documentación técnica.
El Anexo IV del AI Act establece nueve secciones que la documentación técnica debe incluir. La guía analiza en detalle el contenido de cada sección con orientaciones sobre cómo elaborarlas y qué nivel de detalle se requiere.
La primera sección es la descripción general del sistema de IA. Debe incluir la finalidad prevista del sistema, el nombre del proveedor y los datos de contacto del representante autorizado cuando proceda, el período de vida útil esperado del sistema, las versiones de software o firmware y cualquier requisito en materia de actualización, la descripción de todos los tipos de hardware en los que el sistema de IA está destinado a funcionar, y el texto de las instrucciones de uso y, cuando proceda, las instrucciones de instalación.
La segunda sección es la descripción de los elementos del sistema de IA y del proceso de desarrollo. Esta es la sección técnicamente más compleja porque debe describir con suficiente detalle el proceso de desarrollo del sistema: los métodos y pasos utilizados para el desarrollo (incluyendo el uso de sistemas o herramientas de IA de terceros), las especificaciones de diseño del sistema, los criterios de evaluación del diseño, y la descripción de todas las medidas adoptadas para lograr el nivel de precisión, solidez y ciberseguridad requerido.
La tercera sección es la información sobre la monitorización, el funcionamiento y el control del sistema de IA. Describe los mecanismos de supervisión humana del art. 14, los logs automáticos del art. 12, los mecanismos de interpretabilidad y explicabilidad, y los procedimientos de mantenimiento y actualización del sistema.
La cuarta sección es la información sobre los datos utilizados para el entrenamiento, la validación y las pruebas. Esta sección implementa los requisitos del art. 10 en la documentación: describe los conjuntos de datos, su origen, sus características estadísticas principales, los procedimientos de selección y limpieza de datos, y los resultados de las evaluaciones de calidad y representatividad.
La quinta sección es la evaluación de riesgos y las medidas adoptadas para mitigar los riesgos. Esta sección resume el proceso de gestión de riesgos del art. 9: los riesgos identificados, su evaluación, las medidas de mitigación adoptadas, y los riesgos residuales aceptados.
La sexta sección es la descripción de las pruebas realizadas para verificar que el sistema cumple los requisitos del Reglamento. Incluye los resultados de las pruebas de precisión, solidez y ciberseguridad, con los protocolos de prueba utilizados, las métricas evaluadas, y los resultados obtenidos.
La séptima sección es la descripción del sistema de vigilancia poscomercialización del art. 72, incluyendo los indicadores de rendimiento monitorizados, la frecuencia de monitorización, los umbrales de acción, y los canales de retroalimentación de los desplegadores.
La octava sección es una copia de la declaración UE de conformidad del art. 47.
La novena sección es cualquier otra información técnica adicional que permita a las autoridades supervisoras evaluar el cumplimiento del sistema con los requisitos del Reglamento, incluyendo el resultado de cualquier evaluación de conformidad realizada por un organismo notificado cuando sea aplicable.
La documentación técnica no puede ser un documento estático. El art. 11 exige que se mantenga actualizada durante toda la vida del sistema. La guía establece los eventos que requieren una actualización de la documentación técnica: cualquier modificación sustancial del sistema que requiera una nueva evaluación de conformidad, la detección de nuevos riesgos no identificados en la evaluación inicial, cambios en la normativa aplicable que afecten a los requisitos del sistema, y cualquier actualización significativa de los datos de entrenamiento o del modelo.
El control de versiones de la documentación técnica es un aspecto que la guía trata con especial detalle. Cada actualización de la documentación debe estar fechada, firmada por el responsable técnico del proveedor, y debe indicar claramente qué secciones han sido modificadas y por qué. El historial de versiones de la documentación permite a las autoridades supervisoras reconstruir la evolución del sistema y verificar que los cambios han sido evaluados adecuadamente.
Para los juristas que asesoran en adquisiciones de software con funcionalidades de IA, la documentación técnica del Anexo IV es un elemento crítico del due diligence de AI compliance. El adquirente de un sistema de IA de alto riesgo debe verificar no solo que el sistema tiene la documentación técnica, sino que esa documentación es completa, actualizada y coherente con el funcionamiento real del sistema.
La brecha más frecuente que se detecta en los procesos de due diligence es que la documentación técnica existe como documento formal pero no refleja fielmente el sistema real: fue elaborada cuando se diseñó el sistema pero no se ha actualizado para reflejar las modificaciones introducidas posteriormente. Una documentación técnica desactualizada es una infracción del art. 11 del AI Act y, además, no proporciona la protección jurídica que el proveedor busca al elaborarla.
La guía recomienda un proceso iterativo de elaboración de la documentación técnica que comienza en las primeras fases del desarrollo del sistema y se completa gradualmente. Esperar a que el sistema esté completamente desarrollado para empezar a elaborar la documentación es el error más frecuente y el que genera más retrasos en el proceso de comercialización.
El proceso recomendado es: empezar con las secciones descriptivas (sección 1 y partes de la sección 2) en la fase de diseño del sistema; completar la sección de datos (sección 4) cuando los datos de entrenamiento estén definidos; elaborar la sección de riesgos (sección 5) durante el proceso de gestión de riesgos del art. 9; completar las secciones de pruebas (sección 6) cuando las pruebas de validación estén completadas; y redactar el sistema de vigilancia poscomercialización (sección 7) en la fase final antes de la comercialización. Este enfoque iterativo reduce el riesgo de que la documentación sea incompleta o incoherente.
Más allá de su función regulatoria, la documentación técnica del Anexo IV puede convertirse en una ventaja competitiva para los proveedores que la desarrollan con rigor. Los clientes empresariales y las administraciones públicas que adquieren sistemas de IA de alto riesgo son cada vez más exigentes respecto al cumplimiento del AI Act de sus proveedores, y la disponibilidad de una documentación técnica completa y bien estructurada es una señal de madurez regulatoria que diferencia a los proveedores conformes de los que no lo son.
En las licitaciones públicas de sistemas de IA, los pliegos de condiciones están incorporando progresivamente la exigencia de que el proveedor acredite el cumplimiento del AI Act mediante la presentación de la documentación técnica y la declaración UE de conformidad. Los proveedores que tienen esta documentación lista pueden responder a estas licitaciones; los que no la tienen, quedan excluidos del proceso con independencia de la calidad técnica de su solución.
La documentación técnica también facilita las revisiones de seguridad y cumplimiento que los clientes institucionales realizan antes de contratar un sistema de IA. Un cliente que puede revisar la documentación técnica completa de un sistema de IA antes de contratarlo tiene mucha más información para tomar una decisión fundamentada que uno que debe confiar únicamente en las afirmaciones del proveedor. La transparencia que la documentación técnica proporciona puede convertirse en un argumento de venta relevante en un mercado donde la confianza en los sistemas de IA es aún limitada.
La obligación de mantener la documentación técnica actualizada durante la vida del sistema y diez años después de su retirada del mercado convierte la documentación técnica en un activo corporativo de largo plazo que debe gestionarse con los mismos criterios que otros activos corporativos críticos. Esto implica establecer procesos de gestión documental específicos: control de versiones riguroso, archivo seguro, acceso controlado, y procesos de actualización documentados.
La guía recomienda integrar la gestión de la documentación técnica del AI Act en el sistema de gestión de documentos corporativo (Document Management System, DMS) de la organización, con categorías específicas de documentos de IA que reflejen la estructura del Anexo IV. Esta integración permite que la documentación técnica sea accesible para todos los equipos que la necesitan — ingeniería, cumplimiento, jurídico, auditoría interna — mientras se mantiene el control de acceso apropiado para la información sensible que puede contener.
La guía identifica varios errores frecuentes en la elaboración de la documentación técnica que conviene conocer para evitarlos. El primero es la documentación aspiracional: describir el sistema tal como debería funcionar en las condiciones ideales de uso, en lugar de cómo funciona realmente en producción con los datos y las condiciones reales. Este error, frecuente cuando la documentación es elaborada por el equipo de marketing o de producto en lugar del equipo técnico y jurídico, genera una documentación que no refleja fielmente el sistema y que puede ser contraproducente en un procedimiento sancionador.
El segundo error frecuente es la documentación genérica: usar plantillas de documentación técnica sin adaptarlas al sistema específico, de forma que la documentación es correcta en su estructura pero vacía en su contenido. Una documentación genérica que podría aplicarse a cualquier sistema de IA no proporciona la información específica que el Anexo IV exige y que las autoridades supervisoras buscan.
El tercer error frecuente es la falta de actualización: elaborar la documentación técnica una vez, antes del lanzamiento del sistema, y no actualizarla cuando el sistema evoluciona. Este error es especialmente peligroso porque la documentación técnica desactualizada puede crear la falsa apariencia de cumplimiento mientras el sistema real ha evolucionado fuera de los parámetros documentados.
Más allá de su función regulatoria, la documentación técnica del Anexo IV puede convertirse en una ventaja competitiva para los proveedores que la desarrollan con rigor. Los clientes empresariales y las administraciones públicas que adquieren sistemas de IA de alto riesgo son cada vez más exigentes respecto al cumplimiento del AI Act de sus proveedores, y la disponibilidad de una documentación técnica completa y bien estructurada es una señal de madurez regulatoria que diferencia a los proveedores conformes de los que no lo son.
En las licitaciones públicas de sistemas de IA, los pliegos de condiciones están incorporando progresivamente la exigencia de que el proveedor acredite el cumplimiento del AI Act mediante la presentación de la documentación técnica y la declaración UE de conformidad. Los proveedores que tienen esta documentación lista pueden responder a estas licitaciones; los que no la tienen, quedan excluidos del proceso con independencia de la calidad técnica de su solución.
La documentación técnica también facilita las revisiones de seguridad y cumplimiento que los clientes institucionales realizan antes de contratar un sistema de IA. Un cliente que puede revisar la documentación técnica completa de un sistema de IA antes de contratarlo tiene mucha más información para tomar una decisión fundamentada que uno que debe confiar únicamente en las afirmaciones del proveedor. La transparencia que la documentación técnica proporciona puede convertirse en un argumento de venta relevante en un mercado donde la confianza en los sistemas de IA es aún limitada.
La obligación de mantener la documentación técnica actualizada durante la vida del sistema y diez años después de su retirada del mercado convierte la documentación técnica en un activo corporativo de largo plazo que debe gestionarse con los mismos criterios que otros activos corporativos críticos. Esto implica establecer procesos de gestión documental específicos: control de versiones riguroso, archivo seguro, acceso controlado, y procesos de actualización documentados.
La guía recomienda integrar la gestión de la documentación técnica del AI Act en el sistema de gestión de documentos corporativo (Document Management System, DMS) de la organización, con categorías específicas de documentos de IA que reflejen la estructura del Anexo IV. Esta integración permite que la documentación técnica sea accesible para todos los equipos que la necesitan — ingeniería, cumplimiento, jurídico, auditoría interna — mientras se mantiene el control de acceso apropiado para la información sensible que puede contener.
La guía identifica varios errores frecuentes en la elaboración de la documentación técnica que conviene conocer para evitarlos. El primero es la documentación aspiracional: describir el sistema tal como debería funcionar en las condiciones ideales de uso, en lugar de cómo funciona realmente en producción con los datos y las condiciones reales. Este error, frecuente cuando la documentación es elaborada por el equipo de marketing o de producto en lugar del equipo técnico y jurídico, genera una documentación que no refleja fielmente el sistema y que puede ser contraproducente en un procedimiento sancionador.
El segundo error frecuente es la documentación genérica: usar plantillas de documentación técnica sin adaptarlas al sistema específico, de forma que la documentación es correcta en su estructura pero vacía en su contenido. Una documentación genérica que podría aplicarse a cualquier sistema de IA no proporciona la información específica que el Anexo IV exige y que las autoridades supervisoras buscan.
El tercer error frecuente es la falta de actualización: elaborar la documentación técnica una vez, antes del lanzamiento del sistema, y no actualizarla cuando el sistema evoluciona. Este error es especialmente peligroso porque la documentación técnica desactualizada puede crear la falsa apariencia de cumplimiento mientras el sistema real ha evolucionado fuera de los parámetros documentados.
Más recursos: calendario del AI Act tras el Ómnibus Digital · análisis del AI Act en 2026 · servicios para administraciones públicas (LexQuark).
Newsletter gratuita · Empresas y administraciones públicas · En español