Lista de comprobación de documentación técnica

Una documentación técnica eficaz cubre la Ley de IA de la UE y permite rastrear cada afirmación hasta la versión del sistema y la prueba que la respalda. El proveedor de un sistema de IA de alto riesgo debe prepararla antes de introducirlo en el mercado o ponerlo en servicio, mantenerla actualizada y presentarla con claridad suficiente para que autoridades y organismos notificados evalúen la conformidad.

El artículo 11 y el anexo IV establecen la estructura básica. El Reglamento (UE) 2026/1744 mantiene el anexo IV como mínimo, aunque permite a pymes —incluidas empresas emergentes— y pequeñas empresas de mediana capitalización utilizar un formulario simplificado de la Comisión cuando esté disponible. Se simplifica la presentación, no la necesidad de demostrar el cumplimiento. Esta lista está pensada para proveedores; confirme primero los límites del sistema, la función de la empresa y la clasificación.

Alcance y control

• [ ] Asignar un identificador estable, identificar al proveedor y fijar la versión de producción cubierta.
• [ ] Describir finalidad, usuarios, personas afectadas, contexto y usos excluidos.
• [ ] Justificar la función y la clasificación de alto riesgo con referencia al anexo I o III.
• [ ] Nombrar un responsable general y un propietario factual para cada prueba.
• [ ] Crear un índice con requisito, fuente, versión, estado, revisor y desencadenante de actualización.

Empiece por el índice, no por una plantilla narrativa. Así se ven las carencias y se evita que el documento se separe del producto.

Sistema, desarrollo y arquitectura

• [ ] Registrar finalidad, proveedor, versiones, modalidades de distribución y condiciones de uso.
• [ ] Identificar hardware, software, firmware, interfaces, dependencias y componentes externos de IA.
• [ ] Conservar con versión la arquitectura, los métodos de desarrollo, decisiones de diseño y trabajos de terceros.
• [ ] Explicar adquisición, preparación, etiquetado, calidad y gobernanza de datos cuando corresponda.
• [ ] Definir resultados, limitaciones, calidad esperada e influencia en decisiones.
• [ ] Documentar cambios durante el desarrollo y el proceso controlado para cambios posteriores.

Los diagramas necesitan fecha y versión. La documentación de un proveedor externo no prueba cómo funciona la configuración propia.

Rendimiento, riesgos y controles

• [ ] Describir capacidades, límites, precisión, solidez y ciberseguridad.
• [ ] Conservar métricas, umbrales, datos y condiciones de prueba, resultados y exclusiones conocidas.
• [ ] Evaluar riesgos previsibles para salud, seguridad y derechos fundamentales.
• [ ] Registrar controles, riesgo residual, responsables y autoridad que acepta el riesgo.
• [ ] Explicar supervisión humana, avisos, intervención y escalado.
• [ ] Definir registros, conservación, acceso y trazabilidad.
• [ ] Vincular los artículos 8 a 15 con controles y pruebas.

Una cifra de precisión sin tarea, población, versión del conjunto de datos, métrica y fecha es incompleta. El registro de riesgos explica la decisión; las pruebas, aprobaciones, instrucciones y logs demuestran la ejecución.

Conformidad y ciclo de vida

• [ ] Identificar normas armonizadas u otras especificaciones aplicadas, con edición y alcance.
• [ ] Justificar desviaciones y pruebas alternativas.
• [ ] Conservar la evaluación de conformidad, la declaración UE y los datos del organismo notificado, si existe.
• [ ] Mantener un historial de cambios y confirmar en cada versión que el expediente coincide con producción.
• [ ] Registrar seguimiento poscomercialización, quejas, incidentes, deriva y medidas correctoras.
• [ ] Tratar cambios de proveedores, retirada, reversión y conservación como desencadenantes de revisión.

Cada cambio material debe preguntar si afecta a finalidad, clasificación, datos, arquitectura, rendimiento, riesgos, controles, instrucciones, supervisión o seguimiento. Si afecta, actualice los elementos correspondientes antes de publicar la versión.

Control final de calidad

• [ ] Cada afirmación tiene una fuente controlada o está marcada como análisis.
• [ ] Las versiones coinciden entre arquitectura, pruebas, riesgos, instrucciones y entrega.
• [ ] Cada carencia tiene responsable, control provisional, decisión de riesgo y plazo.
• [ ] Los enlaces funcionan y los revisores tienen acceso adecuado.
• [ ] Una persona independiente puede reproducir las conclusiones principales desde el índice.

La obligación se refiere al sistema completo en su contexto, no solo al modelo. Una política no es prueba de ejecución y el expediente no termina con el lanzamiento: debe seguir los cambios y las señales poscomercialización.

Preguntas frecuentes

¿Cuándo se aplica a equipos SaaS?

El artículo 11 se aplica a proveedores de sistemas de IA de alto riesgo. Una empresa SaaS puede ser responsable del despliegue o usar IA que no sea de alto riesgo. La documentación voluntaria puede apoyar la gobernanza y las revisiones de clientes, pero no debe presentarse como obligación legal.

¿Cuándo se aplican las reglas de alto riesgo?

Tras el Reglamento (UE) 2026/1744, las reglas pertinentes para sistemas autónomos del anexo III se aplican desde el 2 de diciembre de 2027 y para sistemas integrados en productos del anexo I desde el 2 de agosto de 2028. Confirme las normas transitorias de su sistema concreto.

Fuentes

• Reglamento (UE) 2024/1689, artículos 9, 11, 16–18 y 72, y anexo IV.
• Reglamento (UE) 2026/1744, en especial la modificación del artículo 11 y el calendario.
• Comisión Europea, «Navigating the AI Act».