Errores comunes de documentación técnica

Los fallos habituales no son de formato, sino de alcance, evidencia, responsabilidad y control de cambios. Un expediente puede parecer completo y ser imposible de verificar. El artículo 11 de la Ley de IA exige a los proveedores de sistemas de alto riesgo preparar la documentación antes de comercializarlos o ponerlos en servicio y mantenerla actualizada. El anexo IV fija el contenido mínimo. El Reglamento (UE) 2026/1744 simplifica la presentación para determinadas organizaciones pequeñas, pero no convierte afirmaciones sin prueba en evidencia.

No toda empresa SaaS es proveedora de un sistema de alto riesgo. Primero hay que confirmar los límites del sistema, la función de la empresa y la clasificación.

1. Documentar el modelo y no el sistema

Una ficha del modelo o del proveedor no describe el producto con sus prompts, flujos de datos, interfaces, supervisión humana, registros y acciones posteriores. Defina el límite y registre componentes, actores, entradas, salidas y controles. Distinga los datos del proveedor de los verificados internamente. La guía de la Ley de IA para proveedores SaaS ayuda a establecer función y alcance.

2. Empezar con una plantilla narrativa

Las plantillas extensas fomentan textos plausibles sobre pruebas o supervisión antes de disponer de evidencias. Empiece por un índice de cobertura: requisito, artefacto fuente, versión, propietario, revisor, estado y evento de actualización. Redacte la explicación después de controlar las fuentes.

3. Confundir políticas con pruebas

Una política indica lo que debería ocurrir; la evidencia muestra lo ocurrido en una versión concreta. Sirven requisitos aprobados, decisiones de arquitectura, registros de datos, evaluaciones, modelos de amenazas, aprobaciones de publicación y revisiones de seguimiento. Cada prueba debe indicar afirmación, fuente, fecha, versión y responsable.

4. Perder la trazabilidad de versiones

Los diagramas sobrescritos, pruebas sin versión de modelo o datos y paneles cambiantes rompen la trazabilidad. Asigne un identificador estable y relacione cada artefacto con versión, modelo, configuración y fecha. Desde la versión productiva debe poder llegarse a requisitos, arquitectura, pruebas, riesgos, controles, instrucciones y aprobación.

5. Encargar todo a cumplimiento

Cumplimiento coordina el estándar y cuestiona afirmaciones débiles, pero no debe redactar hechos técnicos de segunda mano. Producto responde del propósito; ingeniería, de arquitectura y cambios; datos o ML, de evaluaciones; seguridad, de controles; y gestión de versiones, de lo publicado. Un responsable central mantiene la cobertura sin escribir todas las pruebas.

6. Tratarlo como una entrega única

Modelos, datos, proveedores y riesgos cambian. Incluya una comprobación de impacto cuando cambien propósito, límites, modelo, datos relevantes, rendimiento, supervisión, seguridad, instrucciones o seguimiento. La revisión periódica es un respaldo; el control principal debe activarse por eventos e integrarse en el flujo habitual. Una buena estructura también permite acelerar las auditorías.

7. Medir actividad y no calidad

El número de documentos o tareas cerradas no demuestra que las afirmaciones estén respaldadas. Mida integridad inicial, brechas importantes, excepciones vencidas, enlaces rotos, diferencias de versión y tiempo de actualización. Si un revisor necesita entrevistar al autor para reproducir una conclusión, la evidencia no es autosuficiente.

8. Aceptar sin más las afirmaciones del proveedor

Certificados y fichas pueden cubrir otra versión, idioma, población o entorno. Registre el documento exacto, evalúe la diferencia con su uso y pruebe el comportamiento relevante. La falta de información es un riesgo o una brecha, no una base para suponer.

9. Ocultar brechas tras excepciones vagas

“Completar más adelante” no es una decisión controlada. Registre brecha, motivo, control provisional, propietario del riesgo, aprobación, corrección y caducidad. No todo defecto bloquea una publicación, pero una evaluación ausente no equivale a un detalle editorial. Un modelo claro de responsables de cumplimiento evita excepciones permanentes.

Flujo de revisión enfocado

1. Confirmar límites, función, clasificación, propósito y versión vigente.
2. Crear el índice del anexo IV y enlazar fuentes controladas.
3. Muestrear una afirmación de arquitectura, rendimiento, riesgo, supervisión y cambio.
4. Verificar identificadores coherentes y resultados reproducibles.
5. Asignar a cada brecha responsable, importancia, acción y fecha.
6. Integrar eventos de actualización en producto, proveedores, seguridad y publicación.

Preguntas frecuentes

¿Cuál es la finalidad práctica?

Explicar de forma trazable qué es el sistema, cómo se desarrolló y evaluó, qué riesgos y controles existen y por qué se consideran cumplidos los requisitos.

¿Cuándo se aplica a SaaS?

El artículo 11 se aplica a proveedores de sistemas de alto riesgo. Antes de tratar el anexo IV como obligación directa, confirme límites, función y clasificación.

¿Qué debe corregirse primero?

Propósito, versión, arquitectura, evaluación, riesgos materiales, supervisión humana, instrucciones y aprobación. Corrija contradicciones y afirmaciones importantes sin respaldo antes que la presentación.

Fuentes

• Reglamento (UE) 2024/1689, en particular el artículo 11 y el anexo IV.
• Reglamento (UE) 2026/1744, incluidas las simplificaciones de documentación técnica.