Qué es la documentación técnica del AI Act
Es el conjunto estructurado de información que describe un sistema de IA de alto riesgo y permite demostrar cómo cumple los requisitos aplicables.
No es un único documento ni un simple manual. Puede incluir especificaciones, registros, informes, diagramas, evaluaciones, pruebas, documentación de datos, controles, procedimientos y cambios.
El conjunto debe ser claro, trazable, coherente, actualizado y suficientemente detallado para evaluar la conformidad.
Para qué sirve
Demostrar conformidad
Debe mostrar cómo el sistema cumple los requisitos.
Facilitar la evaluación
Debe proporcionar información clara y completa a autoridades competentes, organismos notificados, auditores y responsables internos.
Mantener trazabilidad
Permite entender cómo evolucionó el sistema.
Conectar requisitos y evidencias
Por ejemplo: requisito → control → prueba → resultado → evidencia. La documentación técnica forma parte del mecanismo de aseguramiento.
Cuándo debe elaborarse y actualizarse
El artículo 11 exige que exista antes de introducir el sistema en el mercado o ponerlo en servicio, y que se mantenga actualizada.
No debería construirse al final como recopilación retrospectiva. Debe acompañar el desarrollo y actualizarse cuando cambian versión, modelo, datos, finalidad, proveedor, arquitectura o controles mediante la gestión del cambio.
Descripción general del sistema
El Anexo IV comienza con una descripción que puede incluir finalidad prevista, proveedor, versión, versiones anteriores, forma de comercialización, interfaces, hardware, software y dependencias.
Debe responder: ¿qué sistema estamos evaluando exactamente? Esto requiere delimitar modelos, APIs, componentes, proveedores y versiones.
Finalidad prevista y alcance
Debe documentarse qué hace el sistema, para quién, en qué contexto, con qué propósito y con qué límites.
La finalidad condiciona riesgo, clasificación, rendimiento, supervisión y obligaciones. La misma tecnología puede tener implicaciones distintas según su uso.
Arquitectura, software, hardware e integraciones
La documentación puede describir arquitectura, componentes, software, firmware, hardware, APIs, integraciones, interfaces y sistemas externos.
No debe copiar todo el repositorio de código, pero sí explicar con claridad el funcionamiento, dependencias externas, servicios de terceros, componentes reutilizados y modelos base.
Desarrollo, datos y entrenamiento
Cuando existe entrenamiento, debe explicarse el origen, preparación, limpieza, etiquetado, selección, calidad, representatividad, entrenamiento, validación y prueba de los datos.
También conviene documentar limitaciones, sesgos conocidos, hipótesis y exclusiones. El expediente debe permitir entender cómo los datos afectan al comportamiento.
Riesgos y medidas de mitigación
Debe conectarse con la gestión de riesgos de IA: riesgos, probabilidad, impacto, tratamiento, controles, riesgo residual y aceptación.
También puede abordar uso indebido razonablemente previsible, derechos fundamentales, seguridad y salud. El objetivo es demostrar que los riesgos se tradujeron en medidas.
Pruebas, métricas y validación
Debe incluir pruebas, validación, métricas, criterios de aceptación y resultados. Según el sistema pueden ser relevantes precisión, robustez, seguridad, estabilidad, sesgo, rendimiento y resiliencia.
Debe quedar claro qué se probó, cómo, con qué criterios y qué resultado se obtuvo.
Supervisión humana
Cuando corresponda, debe describirse la supervisión humana: rol, responsabilidades, información, intervención, override, escalado, parada y formación.
No basta afirmar que una persona revisa; debe explicarse qué puede hacer y con qué autoridad.
Logs, trazabilidad y monitorización
Los sistemas de alto riesgo deben permitir técnicamente el registro automático de eventos. La documentación puede describir eventos, timestamps, decisiones, versiones, usuarios, errores, intervenciones e incidencias.
Los logs apoyan monitorización, auditoría e investigación. Logs y documentación técnica están relacionados, pero no son lo mismo; tampoco sustituyen las instrucciones de uso.
Qué debe contener la documentación técnica
El Anexo IV fija elementos mínimos que, de forma práctica, pueden estructurarse en:
1. Descripción general
Finalidad, proveedor, versión, interfaces, hardware y software.
2. Desarrollo y arquitectura
Metodología, diseño, componentes y dependencias.
3. Datos
Origen, calidad, preparación, validación y representatividad.
4. Riesgos y mitigación
Riesgos identificados, medidas y riesgo residual.
5. Pruebas y validación
Métricas, criterios y resultados.
6. Supervisión humana
Medidas, roles y capacidad de intervención.
7. Seguridad y robustez
Controles, pruebas y resultados.
8. Logs y trazabilidad
Eventos, registros y monitorización.
9. Ciclo de vida
Cambios, versiones, incidentes y actualizaciones.
10. Evidencias de conformidad
Evaluaciones, declaraciones, resultados y documentación de soporte.
Esta estructura debe adaptarse al sistema real. El Anexo IV no es una checklist cerrada e idéntica para todos.
Cómo organizar el expediente técnico
Puede combinar un documento principal, anexos de arquitectura, datos, pruebas, riesgos y controles, referencias hacia evidencias, versionado y responsables claros.
El objetivo es evitar un único documento imposible de mantener y también cientos de archivos sin estructura. Una certificación o ficha de producto no sustituye el expediente técnico.
Qué cambia durante el ciclo de vida
La documentación no termina en producción. Debe revisarse cuando cambien modelo, datos, finalidad, proveedor, versión, integración, control, rendimiento o riesgo.
Una modificación sustancial puede exigir revisar clasificación, riesgos, conformidad y evaluación de conformidad. La gestión de proveedores también debe aportar información sobre cambios de terceros.
Errores habituales
Crear la documentación al final
Se pierde trazabilidad.
Confundirla con el manual de usuario
Son piezas relacionadas, pero distintas.
Documentar solo el modelo
El sistema incluye datos, arquitectura, personas, controles e integraciones.
No mantener versiones o copiar plantillas genéricas
Impide reconstruir cambios y reflejar el sistema real.
No conectar riesgos, controles y evidencias
El expediente queda fragmentado y no demuestra efectividad dentro del framework de gobierno.
No actualizar
Un expediente desactualizado pierde rápidamente su valor.
La documentación técnica convierte el sistema en algo evaluable
Un sistema de alto riesgo no debería ser una caja negra documental. Debe poder explicarse, revisarse, auditarse y demostrar cómo llegó desde diseño → datos → riesgos → pruebas → controles → decisión.
La documentación conecta esas piezas, no para crear burocracia, sino para demostrar que la organización entiende y controla el sistema.
Referencias
- Regulation (EU) 2024/1689 — Artificial Intelligence Act.
- Article 11 — Technical documentation.
- Annex IV — Technical documentation.
- Article 12 — Record-keeping.
- Article 13 — Transparency and provision of information to deployers.
- Article 15 — Accuracy, robustness and cybersecurity.
- Article 43 — Conformity assessment.
¿Podrías demostrar hoy cómo funciona tu sistema de IA de alto riesgo?
La documentación técnica debe conectar diseño, datos, riesgos, pruebas, controles y evidencias de forma coherente y actualizada.
Realizar diagnóstico →
El diagnóstico de Céntrika puede ayudarte a identificar qué elementos ya existen y dónde siguen existiendo brechas.