ISO/IEC 42001: requisitos y controles

Qué exige la norma y qué queda fuera del alcance

ISO/IEC 42001 no evalúa la precisión de un modelo ni su rendimiento frente a un conjunto de prueba. Lo que audita es el sistema de gestión que rodea al modelo: políticas escritas, roles asignados, procesos documentados y registros generados de forma automática en cada iteración del ciclo de vida. La norma opera como una capa de control organizativo, no como una prueba de calidad algorítmica.

El alcance se define en la cláusula 4 y se convierte en el primer filtro de la auditoría: qué sistemas de IA entran, qué unidades de negocio quedan dentro, qué infraestructura se considera propia y qué se delega a proveedores. Un alcance redactado de forma genérica produce matrices de aplicabilidad infladas y controles sin evidencia asociada. Si necesitas el marco normativo completo, revisa la sección de estándares técnicos de IA.

Estructura de alto nivel (Annex SL)

La norma reutiliza el esqueleto de las normas de sistemas de gestión: contexto, liderazgo, planificación, soporte, operación, evaluación del desempeño y mejora. Ese diseño permite integrar el sistema de IA con el sistema de seguridad de la información ya implantado, compartiendo comité, registro documental y calendario de auditoría. La consecuencia práctica es directa: los artefactos de gestión se escriben una vez y se referencian desde ambos marcos.

Cláusulas 4 a 10: el ciclo de control

Cada cláusula produce un artefacto concreto y verificable. La auditoría no pregunta por intenciones: solicita el documento, el registro o la traza del sistema. El ciclo se repite con la misma secuencia en cada periodo de revisión y su salida alimenta la siguiente iteración.

1. Cláusula 4 — Contexto: alcance del sistema de gestión, partes interesadas y límites de la infraestructura declarada.
2. Cláusula 5 — Liderazgo: política de IA firmada, asignación de responsabilidades y autoridad de aprobación de despliegues.
3. Cláusula 6 — Planificación: evaluación de riesgos de IA, análisis de impacto y declaración de aplicabilidad de los controles del Anexo A.
4. Cláusula 7 — Soporte: competencias del personal, control documental, inventario de recursos computacionales y de datos.
5. Cláusula 8 — Operación: ejecución de los procesos planificados, control de cambios en modelos y gestión de proveedores.
6. Cláusula 9 — Evaluación del desempeño: métricas, auditoría interna y revisión por la dirección con periodicidad definida.
7. Cláusula 10 — Mejora: no conformidades, acciones correctivas y cierre verificado sobre el registro anterior.

La cláusula 6 es la que más carga de trabajo concentra: de ella salen la evaluación de riesgos y la declaración de aplicabilidad, que determina qué controles del Anexo A son exigibles y cuáles se justifican como no aplicables. Ese documento se cruza con los roles definidos en gobernanza algorítmica para evitar controles huérfanos sin responsable asignado.

Anexo A: 38 controles en 9 dominios

El Anexo A agrupa los controles por función operativa, no por tipo de modelo. Cada dominio produce documentación propia y un conjunto de registros que el auditor puede muestrear. Los nueve dominios son:

• A.2 Políticas de IA: directrices documentadas, revisadas y comunicadas.
• A.3 Roles internos: responsabilidades de desarrollo, operación y supervisión separadas.
• A.4 Recursos de los sistemas de IA: inventario de datos, herramientas, cómputo y personal habilitado.
• A.5 Evaluación de impacto: análisis de efectos sobre individuos, grupos y procesos antes del despliegue.
• A.6 Ciclo de vida del sistema: diseño, verificación, despliegue, operación y retirada con control de versiones.
• A.7 Datos: procedencia, calidad, preparación, linaje y trazabilidad del conjunto de entrenamiento.
• A.8 Información a partes interesadas: documentación de capacidades, límites y condiciones de uso del sistema.
• A.9 Uso del sistema de IA: objetivos previstos, uso indebido previsible y controles de supervisión humana.
• A.10 Relaciones con terceros: proveedores, modelos externos y contratos con obligaciones de evidencia.

Un control sin registro no existe para el auditor. Si el proceso de revisión de modelos se ejecuta pero no deja traza con fecha, responsable y resultado, el control se clasifica como no conforme.

Evidencia, registros y trazabilidad verificable

La auditoría de ISO/IEC 42001 trabaja por muestreo sobre registros. Para cada control declarado aplicable se solicita el artefacto que demuestra ejecución: acta de aprobación, log de despliegue, informe de validación o contrato con cláusula de notificación. El auditor verifica tres propiedades: que el registro exista, que corresponda al periodo auditado y que sea coherente con el resto del sistema documental.

El formato del registro importa menos que su consistencia. Un repositorio con versionado, marca temporal y autor identificable resuelve la mayor parte de los hallazgos de trazabilidad sin necesidad de documentación adicional. Los sistemas con registro automático de eventos reducen el esfuerzo de recolección de evidencia de forma medible frente a los que dependen de capturas manuales. El detalle del proceso de auditoría se desarrolla en auditoría y cumplimiento de sistemas de IA.

La evaluación de riesgos alimenta además los controles del dominio A.6 y las defensas frente a ataques al modelo, un punto donde la norma se cruza con la ciberseguridad en machine learning. Las no conformidades más frecuentes se concentran en tres zonas: evaluación de impacto ausente o genérica, inventario de modelos desactualizado y contratos con proveedores sin obligación de reporte de incidentes.