La SoA no es un formulario.
Es la columna vertebral que conecta riesgos, controles y decisiones.
Conecta este módulo con el anterior y busca qué evidencia cambiaría tu conclusión.
| 📋 | Contenido mínimo de la SoA · Lista de controles seleccionados del Anexo A (u otros controles adicionales), justificación de inclusión, justificación de exclusión, referencia al riesgo asociado, estado de implementación. |
| 🎯 | Propósito: Demostrar que la organización ha considerado todos los controles del Anexo A y ha decidido cuáles son aplicables basándose en su contexto, riesgos y requisitos. |
| ✅ | Controles incluidos · ¿Están justificados por un riesgo identificado? ¿La justificación es sólida (no "porque sí")? ¿El control está implementado? |
| ❌ | Controles excluidos: ¿La exclusión está justificada por contexto o por ausencia del riesgo? ¿No es una exclusión "cómoda" para evitar implementar controles difíciles? |
| 🔄 | Estado de implementación · ¿La SoA refleja el estado real (implementado, en progreso, planificado, no implementado)? ¿Hay fechas y responsables? |
| ✅ | Justificación aceptable · "El control A.5.4 (evaluación de impacto en individuos) no es aplicable porque nuestro sistema IA no toma decisiones que afecten derechos de personas, según análisis de contexto." |
| ❌ | Justificación inaceptable: "No implementamos monitoreo de sesgo porque es muy caro." (El costo no es justificación si el riesgo existe y es significativo). |
| 📋 | Criterios de aplicabilidad · ¿El sistema IA trata datos sensibles? ¿Afecta derechos de personas? ¿Existe requisito regulatorio aplicable? ¿El riesgo lo justifica? |
| ⚠️ | Error típico: Excluir controles de supervisión humana en sistemas de alto impacto porque "el proveedor lo garantiza". La responsabilidad es de la organización. |
| 📐 | Preguntas clave · ¿El control, en teoría, puede reducir el riesgo identificado? ¿Está documentado? ¿Tiene objetivos claros? ¿Los responsables están definidos? |
| ❌ | Falla de diseño: Un procedimiento de "monitoreo de sesgo" que no define qué métricas usar, con qué frecuencia ni qué umbrales activan acciones. |
| ⚙️ | Preguntas clave · ¿El control se ejecuta según lo diseñado? ¿Hay registros de su operación? ¿Se realiza con la frecuencia planificada? |
| ❌ | Falla de implementación: El procedimiento de monitoreo de sesgo existe, pero no hay registros de su ejecución en los últimos 6 meses. |
| 📊 | Preguntas clave · ¿El riesgo se ha reducido al nivel aceptable? ¿Las métricas lo confirman? ¿Ha habido recurrencia de incidentes? |
| ❌ | Falla de resultado: El monitoreo de sesgo se ejecuta mensualmente, pero se siguen detectando sesgos significativos y no se toman acciones correctivas. |
| 1 | La SoA debe incluir: controles seleccionados, justificación de inclusión/exclusión, referencia al riesgo, estado de implementación. |
| 2 | Las exclusiones deben justificarse por contexto o ausencia de riesgo. "Es muy caro" no es una justificación válida. |
| 3 | La evaluación de eficacia tiene tres niveles: diseño, implementación y resultado. Cada uno requiere evidencia diferente. |
| 4 | Una SoA desactualizada es una debilidad crítica. El auditor debe verificar su vigencia. |
Este módulo debe utilizarse dentro de auditoría del sistema de gestión de IA, riesgos, impactos, ciclo de vida y supervisión. Su valor no está en repetir definiciones, sino en decidir qué debe ocurrir, quién participa y cómo se demuestra.
Para trabajar «Declaración de Aplicabilidad y Evaluación de Eficacia», comienza delimitando finalidad, origen de datos, versión, pruebas, supervisión y cambio. Después conecta el requisito o principio con los procesos, sistemas, terceros y decisiones que realmente existen en la organización.
Los actores habituales serán Equipo auditor, Dirección, responsables de IA, Datos, Producto, Riesgos, Legal y Seguridad. No todos ejecutan el control, pero cada uno puede aportar una parte del contexto, la evidencia o la decisión.
La documentación no debería ser una colección de archivos aislados. Debe permitir seguir una relación lógica entre criterio, decisión, actividad y resultado.
Cada evidencia necesita contexto: sistema o proceso al que pertenece, periodo cubierto, fuente, responsable y estado. Sin esos datos, una captura o un documento pueden ser auténticos pero insuficientes.
Escenario: un sistema de IA cambia de modelo y datos, pero la organización mantiene la evaluación y documentación de la versión anterior. El objetivo no es memorizar una respuesta, sino reconstruir qué debería verificarse y con qué evidencia.
Define el alcance y concreta finalidad, origen de datos, versión, pruebas, supervisión y cambio.
Contrasta entrevistas con documentos, registros y observación de la operación.
Separa hechos, criterio aplicable, impacto y acción necesaria.
El contrato del proveedor no obliga a avisar de cambios de modelo.
SaaS de IA, contrato, versiones y API.
¿Qué riesgo operativo aparece?
Respuesta orientativa: Cambios no evaluados en producción.
el proveedor publica el changelog con semanas de retraso?
Revisa cómo cambian alcance, riesgo, responsabilidad, evidencia y decisión.
Identifica entidad, actividad, sistema, rol y criterio que cambia el alcance.
Esto no desbloquea el módulo siguiente ni modifica tu progreso. Es una autocomprobación antes de pulsar Continuar.
La Declaración de Aplicabilidad (SoA)
Auditoría de la SoA: qué verificar
Exclusiones injustificadas