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
Los requisitos de un sistema de IA tienen que decir más que "debe funcionar bien": quién lo va a usar, qué no debe hacer, qué datos necesita, y qué tratamientos de riesgo (un paso de revisión humana, un umbral de confianza) se derivan de la evaluación de impacto. La documentación técnica del sistema de IA captura esto antes de empezar a construir o configurar. Los auditores buscan si un requisito es verificable, "el modelo debe marcar para revisión las respuestas de baja confianza" en lugar de "el modelo debería ser exacto", y si el modelado de amenazas consideró riesgos específicos de IA como la inyección de prompts, no solo las amenazas estándar de aplicación.
Brechas habituales
Los requisitos describen el uso previsto pero nunca traducen los riesgos identificados en la evaluación de impacto en restricciones verificables.
El modelado de amenazas cubre la capa de aplicación pero omite riesgos específicos de IA como la inyección de prompts o la fuga de datos a través del modelo.
Se adoptó una herramienta de IA de un proveedor con decisiones de configuración tomadas de forma improvisada, sin requisitos documentados contra los que verificarlas.
Preguntas que hará tu auditor
¿De dónde salen los requisitos declarados para un sistema de IA?
Del uso previsto, las necesidades de las partes interesadas y los tratamientos de riesgo de la evaluación de impacto, todo registrado en la documentación técnica del sistema de IA.
¿Los requisitos son verificables, o solo se enuncian como metas?
Cada requisito tiene una condición de cumplimiento, por ejemplo un umbral de confianza definido que dispara la revisión humana, no solo una aspiración general.
¿El modelado de amenazas cubre riesgos específicos de IA?
Sí, se consideran la inyección de prompts, la exposición de datos de entrenamiento o de entrada, y el mal uso del modelo, junto con las amenazas estándar de aplicación.
¿Cómo se aplican estos requisitos cuando la IA es una herramienta comprada en lugar de código propio?
El mismo proceso de requisitos aplica a las decisiones de configuración de herramientas de proveedores, documentadas antes de aprobar su uso.
Dónde lo exige la regulación
NIS2 art. 6.2 (Ciclo de vida de desarrollo seguro) cubre esto, que para un sistema de IA empieza en la etapa de requisitos y modelado de amenazas.
Controles relacionados
Vía el tema compartido del Sekit CSF, no el índice del propio marco.