Cuándo se aplica la documentación técnica y qué hacer después

La documentación técnica es una obligación concreta de la Ley de IA cuando una empresa es proveedora de un sistema de alto riesgo. El artículo 11 exige prepararla antes de la comercialización o puesta en servicio, mantenerla actualizada y hacerla suficientemente clara para que autoridades y organismos notificados evalúen la conformidad. El anexo IV fija el contenido mínimo.

Esto no significa que toda empresa SaaS que use una API de IA necesite un expediente completo. La respuesta depende del límite del sistema, la función de la empresa y la clasificación de alto riesgo. Aun sin obligación directa, un registro proporcionado puede apoyar gobernanza, evaluación de proveedores, clientes, incidentes y futuras reevaluaciones.

Confirmar sistema, función y clasificación

Describa el sistema completo: finalidad prevista, usuarios, personas afectadas, entradas, salidas, integraciones, contexto y efecto de los resultados. Un modelo externo puede ser solo un componente del producto SaaS.

Determine después la función. Quien desarrolla y comercializa un sistema de alto riesgo con su nombre suele ser proveedor; un cliente puede ser responsable del despliegue. El cambio de marca, una modificación sustancial o un nuevo propósito pueden trasladar responsabilidades. Por último, evalúe las dos vías principales del artículo 6: sistemas vinculados a productos regulados del anexo I y casos de uso del anexo III. Consulte la guía para proveedores SaaS.

Cuándo se aplica el artículo 11

El artículo 11 y el anexo IV regulan la documentación de sistemas de alto riesgo y sitúan la obligación principal en el proveedor. Tras el Reglamento (UE) 2026/1744, las reglas para sistemas 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.

No conviene esperar. La normativa sectorial, protección de datos, contratos, seguridad y revisiones de clientes ya pueden exigir pruebas similares. Empezar pronto evita reconstruir versiones, datos, pruebas y decisiones.

Si el sistema no es de alto riesgo o la empresa solo lo despliega, quizá no corresponda un expediente completo. Registre aun así la decisión, hechos, revisor y eventos de reevaluación. Un nuevo propósito sensible, cambios materiales de modelo o datos, otros mercados o mayor impacto sobre personas requieren una revisión.

Qué debe cubrir el expediente

El anexo IV exige, como mínimo:

1. Identidad, propósito, versiones, usuarios y condiciones de uso.
2. Desarrollo, arquitectura, componentes y decisiones de diseño.
3. Procedencia de datos, validación, pruebas y límites de rendimiento.
4. Riesgos, controles, supervisión humana, registros y escalado.
5. Robustez, ciberseguridad y resultados no deseados previsibles.
6. Cambios, incidentes y seguimiento poscomercialización.
7. Normas, evaluación de conformidad y aprobaciones.
8. Trazabilidad de cada afirmación a una fuente controlada.

El expediente puede ser un índice que enlace registros controlados; no debe duplicarlo todo. Enlaces estables, permisos, versiones y conservación importan más que el número de páginas.

Flujo práctico

1. Aprobar el alcance: registrar identificador, propósito, límite, función, clasificación y supuestos.
2. Crear el índice del anexo IV: incluir fuente, propietario, versión, estado, revisor y evento de actualización.
3. Mantener la evidencia con su propietario real: producto responde del propósito; ingeniería, de arquitectura; datos o ML, de evaluaciones; seguridad, de controles; cumplimiento, del mapeo.
4. Cerrar primero las brechas críticas: clasificación, rendimiento, riesgos, supervisión y aprobación de versión.
5. Vincular cambios: propósito, modelos, datos, umbrales, usuarios, integraciones o controles deben activar actualizaciones y, cuando proceda, nuevas pruebas.
6. Probar la recuperación: un revisor independiente debe seguir una afirmación de rendimiento, un control, una vía de supervisión y una versión hasta sus pruebas.

La lista de comprobación de documentación técnica ofrece una revisión detallada. Las respuestas comerciales también deben coincidir con los controles de IA que piden los compradores.

Errores comunes

• Empezar por una plantilla antes de fijar alcance y pruebas.
• Documentar el modelo y no el sistema completo.
• Tratar la documentación del proveedor como prueba de la configuración propia.
• No reevaluar una conclusión de riesgo bajo.
• Mantener un expediente de auditoría separado de versiones y cambios.

Ejemplo: selección asistida de candidatos

En una función que ordena candidaturas, el equipo debe definir propósito, proveedor, límite y clasificación del anexo III. Si es proveedor de un sistema de alto riesgo, el expediente incluirá versiones productivas, datos, flujo del cliente, evaluaciones por grupos, métricas, límites, revisión humana, registros, seguridad y seguimiento. Un cambio de modelo o umbral debe reabrir los registros relacionados.

FAQ

¿Cuándo se aplica a equipos SaaS?

El artículo 11 se aplica a proveedores de sistemas de alto riesgo. Confirme límite, función y clasificación antes de considerar legalmente obligatorio el expediente completo.

¿Qué debe documentarse primero?

Propósito, límite, función, clasificación, versión productiva, arquitectura, riesgos, evaluaciones, controles, instrucciones y propietarios.

¿Se pueden reutilizar registros de ingeniería?

Sí. Enlace fuentes actuales y controladas y muestre en el índice qué requisito y versión cubren.

Fuentes

• Reglamento (UE) 2024/1689, artículos 6 y 11 y anexos I, III y IV.
• Reglamento (UE) 2026/1744 sobre documentación y fechas de aplicación.
• Comisión Europea, “Ley de IA”, calendario de implementación vigente.