ISO 42001: qué exige de verdad a quien usa IA

ISO/IEC 42001 no certifica un modelo: certifica que la organización gobierna su IA. Exige política aprobada, alcance definido, roles asignados, evaluación de riesgos e impacto, control del ciclo de vida de cada sistema, información a terceros y mejora continua, todo con evidencia documental recuperable.

Lo que sigue es el desglose operativo de cada uno de esos requisitos: qué documento hay que tener, qué decisión hay que haber tomado y qué es lo que un auditor va a pedir ver.

---

¿Qué es ISO/IEC 42001 y a quién aplica?

ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, es la primera norma internacional de sistema de gestión para inteligencia artificial. Sigue la misma lógica que ISO 9001 para la calidad o ISO/IEC 27001 para la seguridad de la información: un ciclo de planificar, hacer, verificar y actuar, aplicado esta vez al comportamiento de los sistemas de IA de la organización.

Aplica a quien desarrolla, proporciona o utiliza sistemas de IA, con independencia del tamaño y del sector. Esa amplitud tiene una consecuencia que sorprende a muchas organizaciones: no hace falta entrenar modelos para estar en alcance. Usar un modelo de terceros dentro de un proceso propio ya sitúa a la organización en el rol de usuario, con obligaciones propias sobre selección, configuración, límites y supervisión.

Lo que la norma no hace:

• No evalúa la exactitud de un modelo.
• No otorga un sello sobre un producto concreto.
• No exime de ninguna obligación legal.
• No garantiza que un sistema no cause daño. Garantiza que la organización haya evaluado ese riesgo, lo haya tratado y pueda demostrarlo.

¿Qué diferencia hay entre las cláusulas 4 a 10 y el Anexo A?

Es la primera confusión que hay que despejar, porque cambia por completo el trabajo.

	Cláusulas 4 a 10	Anexo A
Naturaleza	Requisitos del sistema de gestión	Catálogo de controles de referencia
Obligatoriedad	Obligatorias. Incumplir una es no conformidad	Se seleccionan los aplicables
Cómo se justifica	Cumpliendo	Con una Declaración de Aplicabilidad que motiva inclusiones y exclusiones
Qué mide	Si la organización gobierna	Si el gobierno se traduce en controles concretos

Dicho de otro modo: las cláusulas exigen que exista un sistema de gestión; el Anexo A ofrece el material con el que se construye. Una organización puede excluir controles del Anexo A si justifica por qué no aplican a su caso. No puede excluir una cláusula.

---

Las cláusulas, en lenguaje operativo

Cláusula 4 — Contexto de la organización

Qué pide. Determinar las cuestiones internas y externas relevantes, identificar las partes interesadas y sus requisitos, y fijar el alcance del sistema de gestión.

Qué hay que tener. Un documento de alcance que diga con precisión qué sistemas de IA entran y cuáles no, y por qué. Aquí es donde se juega el resto del proyecto: un alcance vago produce un sistema de gestión imposible de auditar, y un alcance demasiado ambicioso produce un proyecto que no se termina.

Error típico. Definir el alcance por departamento en lugar de por sistema. La IA no respeta organigramas.

Cláusula 5 — Liderazgo

Qué pide. Compromiso de la dirección, una política de IA aprobada y roles asignados con autoridad real.

Qué hay que tener. Política firmada por la dirección, no por el equipo técnico. Y un principio rector explícito, del tipo «ninguna decisión con efecto jurídico se automatiza sin intervención humana», que sirva de criterio cuando aparezca un caso que la política no previó.

Error típico. Una política que enumera principios éticos genéricos sin ninguna regla que alguien pueda incumplir. Si no se puede incumplir, no es una política.

Cláusula 6 — Planificación

Qué pide. Identificación y tratamiento de riesgos y oportunidades, objetivos de IA medibles y planificación de los cambios.

Qué hay que tener. Un registro de riesgos de IA propio, distinto del registro de riesgos de seguridad. Los riesgos son de otra naturaleza: comportamiento inesperado, atribución errónea entre humano y sistema, dependencia de un proveedor, deriva silenciosa del modelo, uso fuera de la finalidad prevista.

Error típico. Copiar el registro de riesgos del sistema de seguridad de la información y cambiarle el título.

Cláusula 7 — Soporte

Qué pide. Recursos, competencia, concienciación, comunicación e información documentada.

Qué hay que tener. Inventario de sistemas de IA, modelos, herramientas y dependencias. Y evidencia de competencia de quien supervisa: quien aprueba una salida tiene que entender qué afirma y qué no afirma esa salida. Es materia de formación, no un matiz.

Error típico. Dar por hecha la competencia porque la persona es senior en su función. La supervisión de IA es una competencia distinta.

Cláusula 8 — Operación

Qué pide. Control operacional, evaluación de impacto de los sistemas de IA y gestión de cambios.

Qué hay que tener. Una evaluación de impacto por sistema, hecha antes del despliegue, que analice el efecto sobre personas y grupos. Y una regla de entrada en producción: ningún sistema entra sin definición escrita de tarea, permisos asignados y punto de aprobación humana identificado.

Error típico. Tratar la evaluación de impacto como un documento de una sola vez. Cambia el modelo, cambia el impacto.

Cláusula 9 — Evaluación del desempeño

Qué pide. Seguimiento, medición, análisis, auditoría interna y revisión por la dirección.

Qué hay que tener. Indicadores que midan el gobierno, no solo el rendimiento técnico. Los dos más reveladores son la proporción de salidas del sistema que la revisión humana rechaza y el tiempo transcurrido entre la generación y la decisión humana. Un índice de rechazo que cae a cero no es señal de madurez: sugiere que la aprobación se ha vuelto automática de hecho. Cómo se instrumentan estas señales está desarrollado en observabilidad de agentes IA.

Error típico. Medir exactitud del modelo y llamarlo desempeño del sistema de gestión. Son cosas distintas.

Cláusula 10 — Mejora

Qué pide. Tratamiento de no conformidades, acción correctiva y mejora continua.

Qué hay que tener. Un circuito donde cada no conformidad se registra con causa raíz y acción correctiva verificada. Que un auditor encuentre no conformidades registradas y cerradas es buena señal; que no encuentre ninguna, mala.

---

¿Qué pide el Anexo A?

Los controles de referencia se agrupan en nueve objetivos, de A.2 a A.10. Este es su contenido en términos prácticos:

Objetivo	En una frase	Evidencia habitual
A.2 Políticas relativas a la IA	Existe política aprobada, alineada con las demás y revisada	Documento firmado y registro de revisiones
A.3 Organización interna	Hay roles con nombre y un canal para plantear inquietudes	Matriz de responsabilidades; canal de escalado
A.4 Recursos para sistemas de IA	Están inventariados los datos, herramientas, cómputo y personas	Inventario mantenido y fechado
A.5 Evaluación de impactos	Se evalúa el efecto sobre personas y sociedad antes de desplegar	Evaluación archivada por sistema
A.6 Ciclo de vida	Diseño, verificación, despliegue, operación y registro de eventos	Documentación técnica y registro de auditoría
A.7 Datos para sistemas de IA	Origen, calidad, preparación y procedencia de los datos	Política de datos y trazas de procedencia
A.8 Información para partes interesadas	Se comunica qué hace el sistema, qué no hace y cómo reclamar	Documentación pública y procedimiento de incidentes
A.9 Uso de sistemas de IA	El uso previsto está declarado y los usos excluidos también	Declaración de uso por sistema
A.10 Terceros y clientes	El reparto de responsabilidades con proveedores y clientes está escrito	Contratos, registro de proveedores y condiciones

La selección se documenta en la Declaración de Aplicabilidad. Un control excluido sin justificación escrita es un hallazgo; un control excluido con justificación razonada es una decisión de gestión perfectamente válida.

¿Qué documentos hay que tener sí o sí?

Reducido a lo mínimo defendible:

1. Alcance del sistema de gestión, con sistemas dentro y fuera.
2. Política de IA aprobada por la dirección.
3. Registro de riesgos de IA con tratamiento asignado.
4. Evaluación de impacto por cada sistema en alcance.
5. Declaración de Aplicabilidad del Anexo A.
6. Inventario de sistemas, modelos, datos y proveedores.
7. Registro de eventos de las acciones de los sistemas, con autoría e instante.
8. Actas de auditoría interna y de revisión por la dirección.
9. Registro de no conformidades y acciones correctivas.

Los ocho primeros se pueden preparar. El noveno solo aparece con el tiempo, y su ausencia es precisamente lo que delata a un sistema de gestión recién montado para pasar una auditoría.

¿Qué falla normalmente?

Por orden de frecuencia:

• El alcance se escribe al final, cuando ya se ha hecho el trabajo, y no encaja con lo que realmente se ha implantado.
• La supervisión humana existe en el papel y no en la arquitectura. Si el sistema puede ejecutar la acción irreversible por sí mismo, la supervisión es una costumbre, no un control. Cuando la operación irreversible sencillamente no está expuesta al sistema automático, es un hecho verificable.
• No hay evidencia recuperable. «Lo revisamos siempre» no es evidencia. Un registro con nombre, instante y veredicto sí lo es.
• Se declara de más. Marcar todo como implementado es la vía rápida al hallazgo. El sesgo correcto es declarar de menos y sostener lo declarado.

¿Cómo lo aplicamos nosotros?

El alcance de nuestro sistema de gestión de IA son los agentes de automatización en producción de nuestra plataforma de certificación probatoria y el conector que permite a sistemas externos interactuar con ella. El control de fondo es arquitectónico y se resume en una frase: un agente solo crea borradores; nada se sella sin aprobación humana. La operación irreversible —la que genera la huella criptográfica, el sello temporal y el certificado firmado— no está expuesta a ningún rol de agente. No es una política que alguien pueda saltarse con prisa: es que la ruta no existe.

Sobre esa base se apoyan el registro de auditoría inmutable de cada acción, la segmentación de permisos por rol y el tratamiento fail-closed de las entradas, en el que un archivo cuyo análisis no concluye se rechaza en lugar de procesarse.

El mapeo completo cláusula por cláusula y control por control está publicado en nuestro documento de ISO 42001. El estado de cada marco —incluidos aquellos en los que no tenemos certificación de un tercero, dicho con esas palabras— está en el centro de confianza. Publicar un estado más favorable que el real, en una firma que vende cumplimiento, es un daño que no se repara.

¿ISO 42001 me cubre frente al Reglamento europeo de IA?

No, y conviene no venderlo así. El Reglamento (UE) 2024/1689 impone obligaciones que dependen de la clasificación del caso de uso concreto; un sistema de gestión no cambia esa clasificación.

Lo que sí ocurre es que buena parte de la evidencia coincide: gestión de riesgos, gobierno de datos, documentación técnica, registro de eventos, supervisión humana y transparencia hacia el usuario aparecen en ambos marcos. Una organización con un sistema de gestión maduro llega a la evaluación regulatoria con el trabajo hecho en gran medida, no exenta de hacerla.

Algo parecido ocurre con el marco de gestión de riesgos de IA del NIST: es un marco voluntario y complementario, útil como estructura de análisis, que no sustituye a la norma ni a la ley.

Y la pregunta que siempre viene después —qué relación tiene todo esto con el sistema de seguridad de la información que quizá ya existe— la respondemos en ISO 42001 vs ISO 27001.

---

Qué hacer ahora

1. Escribe el alcance antes que nada. Una página que liste qué sistemas de IA entran, cuáles no y por qué. Si no puedes escribirla, es que falta el inventario.
2. Haz el inventario real. Incluye las herramientas con IA que usan los equipos sin haberlo consultado con nadie. Están ahí.
3. Revisa una sola cosa técnica: si alguno de tus sistemas automáticos puede ejecutar por sí mismo una acción irreversible. Si la respuesta es sí, ese es el primer control a implantar.
4. Empieza a registrar la decisión humana con nombre, instante y veredicto. Es la evidencia que más tarda en acumularse y la primera que se pide.
5. Decide qué vas a declarar y qué no. Y no publiques nunca un estado que no puedas sostener con un documento.

Si quieres una evaluación de distancia entre tu situación actual y los requisitos de la norma, con el inventario y el registro de riesgos incluidos, escríbenos desde contacto. Nuestra práctica de compliance trabaja con la de automatización en el mismo equipo, porque el control que importa casi siempre es de arquitectura.