Lo que pide un auditor, o el motor de evidencias de Sekit.
Documentación técnica del sistema de IA
El paquete de documentación versionado de un sistema de IA concreto: los requisitos que debe cumplir, cómo está diseñado o configurado (modelo, arquitectura o proveedor, datos usados, decisiones tomadas), y el detalle técnico necesario para operarlo, evaluarlo, modificarlo y retirarlo con seguridad.
Del catálogo de evidencias de Sekit
En la práctica
La documentación técnica del sistema de IA tiene que explicar, con suficiente detalle para que un nuevo integrante del equipo o un auditor puedan seguirla, qué modelo o proveedor se eligió, con qué datos se entrenó o configuró, y por qué. Un vacío común es documentación que describe el sistema tal como se construyó originalmente pero nunca se actualizó tras un cambio de versión del modelo o la incorporación de una nueva fuente de datos. Los auditores piden ver la documentación de un sistema en producción y comparan las fuentes de datos y la versión del modelo declaradas contra lo que corre actualmente.
Brechas habituales
La documentación técnica describe la configuración original del sistema de IA pero nunca se actualizó tras una actualización del modelo del proveedor.
Decisiones de diseño, como por qué se eligió un modelo o una fuente de datos en particular, se tomaron de forma verbal y nunca quedaron por escrito.
Existe documentación general del sistema en su conjunto, pero no registra qué cambió en cada versión.
Preguntas que hará tu auditor
¿La documentación refleja el sistema de IA tal como funciona hoy?
Sí, la documentación técnica se actualiza en cada cambio relevante, con el modelo, el proveedor y las fuentes de datos actuales nombrados.
¿Por qué se eligió este modelo o proveedor en particular?
La justificación de diseño queda registrada en la documentación técnica junto con las alternativas consideradas, si las hubo.
¿Cómo haces seguimiento a los cambios de documentación en el tiempo?
A través del mismo proceso de gestión de cambios usado para los cambios en producción, de modo que cada actualización de documentación está vinculada a un cambio aprobado.
¿Dónde está la evidencia de que esta documentación se mantiene al día y no solo se escribió una vez?
El historial de versiones y los registros de cambio se conservan como evidencia de control, fechados y atribuibles a una actualización específica.
Dónde lo exige la regulación
NIS2 art. 7.1 (Evaluación de la implantación y el mantenimiento) exige esto, que depende de documentación que refleje el estado actual del sistema.
Controles relacionados
Vía el tema compartido del Sekit CSF, no el índice del propio marco.