Documentación técnica no es lo mismo que documentación de producto
La confusión más habitual es tratar el Anexo IV como una versión regulatoria del manual de usuario. No lo es. El manual de usuario explica cómo operar el sistema; la documentación técnica del Anexo IV explica cómo se construyó, con qué datos, bajo qué supuestos, con qué limitaciones conocidas y con qué resultados de prueba — y tiene que sostenerse ante un organismo notificado o una autoridad de vigilancia del mercado que puede pedir explicaciones sobre cualquier decisión de diseño.
Esa diferencia importa porque cambia quién debe escribirla. No es un documento que pueda redactar solo el equipo de producto o de marketing técnico: necesita input directo del equipo de ML/ingeniería (arquitectura, datos, métricas), de quien gestiona los datos de entrenamiento (procedencia, sesgos conocidos) y de quien diseñó las medidas de supervisión humana. Tratarlo como una tarea de una sola persona es la causa más común de documentación incompleta.
Las secciones que exige el Anexo IV
El Anexo IV enumera el contenido mínimo obligatorio. En la práctica, se agrupa en seis bloques:
| Bloque | Qué debe incluir |
|---|---|
| Descripción general | Finalidad prevista, versión, proveedor, interacción con hardware/software, formas de comercialización. |
| Elementos de diseño | Arquitectura del sistema, algoritmos y modelos clave, decisiones de diseño y sus justificaciones, elección de arquitectura frente a alternativas descartadas. |
| Datos de entrenamiento | Procedencia, alcance, características principales, criterios de selección, y cómo se abordaron sesgos conocidos en los datos. |
| Supervisión humana | Medidas técnicas y organizativas de supervisión, incluida la capacidad técnica de interpretar los resultados del sistema. |
| Métricas y pruebas | Niveles de precisión, robustez y ciberseguridad, con los procedimientos de prueba usados para validarlos. |
| Sistema de gestión de riesgos | Referencia al proceso del artículo 9 y cómo se relaciona con las decisiones documentadas en los bloques anteriores. |
El error que más se repite: escribirla una vez y olvidarla
El Anexo IV no es un documento estático. El artículo 11 exige mantenerlo actualizado "a lo largo de todo el ciclo de vida" del sistema. Eso significa que cada reentrenamiento significativo, cada cambio de arquitectura o cada ampliación del alcance de uso debería generar una revisión — no una sustitución completa, sino un control de versiones real, con fecha, motivo del cambio y quién lo aprobó.
En la práctica, la mayoría de equipos que fallan una auditoría no fallan por no tener documentación: fallan porque la que tienen describe una versión del modelo de hace ocho meses, y nadie puede explicar qué cambió desde entonces ni por qué. Un control de versiones simple —aunque sea una tabla con fecha, versión de modelo y resumen del cambio— resuelve la mayor parte de ese riesgo.
Cómo estructurarla para no partir de cero cada vez
La forma más eficiente de gestionar el Anexo IV no es un documento largo en prosa, sino una plantilla modular donde cada bloque se actualiza de forma independiente cuando cambia lo que describe. Los datos de entrenamiento cambian con frecuencia distinta a la arquitectura; las métricas de prueba se actualizan cada vez que hay una nueva versión; la descripción general apenas cambia. Separar estos bloques evita reescribir el documento entero por cada actualización menor, y facilita que cada equipo (datos, ML, producto) mantenga su parte sin depender de los demás.
Qué revisar esta semana
- Inventario de sistemas de alto riesgo (reales o previstos) que tu empresa desarrolla, modifica sustancialmente o para los que actúa como proveedor.
- Localizar quién tiene cada pieza de información: arquitectura y decisiones de diseño (ML/ingeniería), procedencia y sesgos de los datos (data team), medidas de supervisión humana (producto/compliance), métricas de prueba (QA/ML).
- Comprobar si existe control de versiones de la documentación, o si la última versión describe un modelo que ya no está en producción.
- Definir quién aprueba cada actualización del Anexo IV cuando el modelo cambia — no debería ser una única persona sin revisión.
El Anexo IV no es una casilla que marcar una vez. Es la evidencia que tu empresa necesitará mostrar si algo falla y una autoridad pregunta por qué se diseñó así el sistema. Cuanto antes exista una estructura modular y actualizable, menos trabajo de última hora habrá cuando llegue esa pregunta.