EU AI Act e ISO/IEC 42001: qué cubre cada uno y dónde se solapan

El EU AI Act y la ISO/IEC 42001 operan en planos distintos y se usan juntos.

El reglamento es derecho europeo directamente aplicable: agrupa los sistemas de IA en categorías según el uso que se les da, impone obligaciones a cada categoría y sanciona el incumplimiento con hasta 35 millones de euros o el 7% del volumen de negocio mundial.

La norma es un estándar de gestión voluntario y certificable, publicado en diciembre de 2023, que describe el AIMS (el sistema de gestión de IA) con el que una organización sostiene esas obligaciones mientras pasa el tiempo y cambian los sistemas.

La relación entre ambos cabe en una línea: el reglamento fija qué tienes que poder demostrar y la norma organiza cómo sigues demostrándolo. El solapamiento operativo es alto y se concentra en seis piezas: inventario, gestión de riesgos, evaluación de impacto, roles con dueño, trazabilidad y sistema de gestión de calidad. Todas ellas construibles una sola vez para servir a los dos frentes. Y hay una frontera nítida donde la norma deja de ayudar: ninguna certificación privada sustituye los actos jurídicos que el reglamento exige, ni otorga presunción de conformidad.

Llevo cinco años operando gobierno de IA dentro de una aseguradora, y la pregunta por la relación entre ambos llega siempre en el mismo momento: cuando alguien acaba de leer el reglamento, ha calculado el tamaño del trabajo y busca un marco que le dé estructura antes de empezar. La respuesta corta que circula, “sirven para cosas distintas y se complementan”, deja al que pregunta exactamente donde estaba. Lo que resuelve la duda es el mapa pieza a pieza: qué obligación concreta se cubre con qué parte del sistema de gestión, qué queda fuera del mapa por mucho que te certifiques, y en qué orden conviene montarlo para evitar retrabajos.

A qué te obliga el EU AI Act

El reglamento reparte los sistemas de IA en categorías según el uso, y de la categoría cuelga todo lo demás. Uso categorización con intención: hablar de clasificar el riesgo arrastra el marco mental del análisis de riesgos clásico, donde aplicas mitigaciones y bajas de nivel, y aquí ninguna mitigación mueve un sistema de alto riesgo a la casilla de al lado. El argumento completo está en la pieza sobre cómo se operacionaliza el reglamento; lo que importa para esta comparación es la consecuencia: la categoría la decide el reglamento a partir del uso, y tu sistema de gestión no la negocia.

Para un sistema de alto riesgo, el capítulo III abre una lista de obligaciones sustantivas: sistema de gestión de riesgos que vive mientras viva el sistema, gobierno de los datos de entrenamiento y prueba, documentación técnica, registro automático de eventos, transparencia hacia quien lo despliega, supervisión humana efectiva, y niveles adecuados de precisión, robustez y ciberseguridad. A los proveedores les añade un sistema de gestión de calidad documentado por escrito, en el artículo 17, y a quien despliega le asigna obligaciones propias por el hecho de usar el sistema bajo su autoridad.

Encima de esa capa sustantiva hay una capa de actos jurídicos que conviene separar mentalmente, porque es la que más gente pasa por alto: la evaluación de conformidad antes de poner el sistema en el mercado, la declaración UE de conformidad, el marcado CE y el registro del sistema en la base de datos de la Unión.

A eso se suman las obligaciones de transparencia para ciertos sistemas al margen de su categoría: avisar de que se interactúa con una IA y marcar el contenido sintético. Y dos obligaciones más que operan ya con el sistema en el mercado: la vigilancia poscomercialización y la notificación de incidentes graves a las autoridades dentro de plazos concretos.

Esa arquitectura tiene una implicación práctica que ordena el resto del artículo: la conformidad con el reglamento se demuestra sistema a sistema, con un expediente por cada uno.

Dónde entra la ISO/IEC 42001

La norma se ocupa de otra cosa: de la organización que sostiene todo lo anterior. Sigue la estructura armonizada de ISO, la misma de ISO 27001 y de ISO 9001: contexto, liderazgo, planificación, soporte, operación, evaluación del desempeño y mejora, y añade un Anexo A con 38 controles específicos de IA agrupados en nueve objetivos, más una Declaración de Aplicabilidad donde justificas cuáles aplicas y por qué excluyes el resto. El detalle de qué se monta al implantarla está en la pieza sobre el AIMS.

Su aportación al frente regulatorio es la cadencia. El reglamento te dice qué debe ser cierto; la norma instala los mecanismos que hacen que siga siendo cierto dentro de dieciocho meses: auditoría interna, revisión por la dirección, gestión de no conformidades y un ciclo de mejora que obliga a volver sobre lo aprobado. Un programa de EU AI Act sin esos mecanismos degrada solo, en silencio, a la velocidad a la que la organización despliega sistemas nuevos.

La segunda aportación es comercial y conviene nombrarla sin rodeos, porque suele ser la que mueve el presupuesto: el certificado es una prueba de madurez transferible que ahorra repetir la misma conversación en cada proceso de compra, cada licitación y cada cuestionario de proveedor.

El solapamiento cabe en seis piezas

Aquí está el mapa. Cada pieza se construye una vez y responde en los dos frentes:

• Inventario de sistemas de IA. El reglamento lo necesita de forma implícita, porque no puedes categorizar lo que no sabes que tienes, ni registrar en la base de datos de la UE lo que no has inventariado. La norma lo empuja desde el contexto y el alcance del sistema de gestión, y desde los controles de ciclo de vida del Anexo A. Es la pieza que más veces bloquea a los dos a la vez.
• Sistema de gestión de riesgos. El artículo 9 lo exige para el alto riesgo como proceso continuo a lo largo de toda la vida del sistema. La cláusula 6.1 de la norma pide determinar riesgos y oportunidades y fijar objetivos medibles; la ISO/IEC 23894 desarrolla la gestión de riesgos de IA con la que se articula. El mismo proceso, con la misma metodología, alimenta los dos.
• Evaluación de impacto. El control A.5 y la cláusula 6.1.4 introducen la evaluación de impacto de los sistemas de IA sobre personas y grupos, con la ISO/IEC 42005 como desarrollo detallado. Ese ejercicio produce buena parte del material de la evaluación de impacto sobre derechos fundamentales del artículo 27, que el reglamento exige a determinados responsables del despliegue, entre ellos los de sistemas de evaluación de solvencia y los de tarificación y evaluación de riesgo en seguros de vida y salud.
• Roles, competencia y supervisión humana. La supervisión humana del artículo 14 vale lo que valga la persona que la ejerce: necesita formación, tiempo y autoridad real para parar el sistema. La cláusula 7 de la norma, con los controles de roles y responsabilidades del Anexo A, es donde eso se convierte en una asignación nominal con competencia acreditada en lugar de una casilla marcada.
• Trazabilidad e información documentada. Documentación técnica, registro automático de eventos y conservación de la documentación son obligaciones del reglamento con plazo. La cláusula 7.5 gobierna la información documentada y la cláusula 9 obliga a medir y auditar. La coincidencia útil es que ambos quieren lo mismo: evidencia generada como subproducto de operar, no reconstruida el día que alguien pregunta.
• Sistema de gestión de calidad del proveedor. Es la correspondencia más directa de todas, y la que menos se menciona. El artículo 17 obliga a los proveedores de sistemas de alto riesgo a tener un sistema de gestión de calidad documentado, con políticas y procedimientos escritos. El reglamento exige por ley un sistema de gestión; la norma describe con detalle cómo se monta uno.

Leídas juntas, esas seis piezas son el argumento a favor de tratar el conjunto como un solo producto interno con dos clientes. Construirlas por duplicado, una vez para el regulador y otra para el auditor, cuesta el doble y produce dos versiones de la verdad que divergen a los pocos meses.

Lo que la certificación deja fuera del reglamento

Aquí es donde conviene ser preciso, porque es la afirmación que más se estira en material comercial.

Certificarse en ISO/IEC 42001 no otorga presunción de conformidad con el EU AI Act. Ese efecto jurídico lo produce solo el cumplimiento de las normas armonizadas del artículo 40: las que la Comisión encarga al comité europeo de normalización CEN-CENELEC JTC 21 y después cita en el Diario Oficial de la Unión Europea.

Julio de 2026 puso la primera pieza de ese tablero sobre la mesa, y resultó ser justo esta. CEN-CENELEC aprobó EN 18286:2026, la norma europea que desarrolla el sistema de gestión de calidad del artículo 17. Lo revelador es cómo se hizo: existiendo ya ISO/IEC 42001, se optó por redactar una norma europea propia con una arquitectura deliberadamente distinta, porque los objetivos y las definiciones de la internacional se consideraron desalineados con ese artículo. Quien tenga un AIMS en marcha llega con buena parte del terreno andado y con el vocabulario compartido, y aun así tendrá que leer EN 18286 con el reglamento delante. El resto del paquete sigue en tramitación (gestión de riesgos, registro de eventos, ciberseguridad, gobierno de datos, evaluación de conformidad), y conviene retener que publicar una norma y citarla en el Diario Oficial son pasos distintos: la presunción de conformidad la da el segundo. El estado del paquete cambia de mes en mes, y lo voy siguiendo en la newsletter.

De ahí cuelgan cuatro cosas que ningún certificado te resuelve. La categorización de tus sistemas, que la decide el reglamento a partir del uso y no el alcance que tú elijas para el AIMS. Los actos jurídicos del alto riesgo: evaluación de conformidad, declaración UE, marcado CE, registro en la base de datos de la Unión, que son trámites regulados con forma tasada. Las obligaciones de transparencia hacia las personas, que aplican por el tipo de sistema con independencia de tu madurez de gestión. Y la notificación de incidentes graves a las autoridades, con sus plazos, que sigue siendo tuya el día que ocurra.

La formulación que uso cuando surgen este tipo de conversaciones es esta: el certificado acredita que tienes un sistema de gestión que funciona, y la conformidad con el reglamento se acredita con el expediente de cada sistema de alto riesgo. Son dos pruebas distintas ante dos audiencias distintas. Tener la primera hace mucho más barata la segunda, y no la sustituye.

El orden de implantación que ahorra la mitad del trabajo

Cuando los dos frentes están abiertos a la vez, la secuencia importa más que el esfuerzo total.

Empieza por el inventario. Sirve a los dos, condiciona a los dos y es el que más tarda, porque implica hablar con equipos que desplegaron cosas que nadie registró como IA. Después categoriza contra el Anexo III, antes de decidir el alcance del sistema de gestión: el alcance sensato es el que cubre tus sistemas de alto riesgo, y eso solo se sabe una vez categorizado. Hacerlo al revés produce un certificado que el primer cliente que lo lea descartará por irrelevante, porque el sistema por el que pregunta se quedó fuera.

Con eso hecho, monta un único proceso de evaluación de riesgo e impacto con dos salidas: la que alimenta el expediente del artículo 9 y la que alimenta el control A.5 y la evaluación de derechos fundamentales cuando aplique. Y un solo repositorio de evidencia, indexado por sistema, que es la estructura que ambos auditores acaban recorriendo. La decisión de certificar llega al final, cuando el sistema ya produce evidencia por sí solo; certificar sobre una operación que aún no ha cambiado produce un sello caro que no mejora nada por dentro.

El error caro es el contrario: abrir dos programas en paralelo con dos gobiernos, dos calendarios y dos inventarios, con un final conocido: alguien dedicando el trimestre a reconciliar dos listas de sistemas que deberían haber sido una.

Una sola maquinaria para dos exigencias

Lo que queda cuando se retira la comparación es una idea bastante simple. Las obligaciones cambian, el reglamento se aplica por fases, la norma se revisa, han empezado a llegar las armonizadas del artículo 40 y con ellas otra capa de trabajo, y lo que permanece es la maquinaria: saber qué sistemas tienes, en qué categoría cae cada uno, quién responde de cada obligación y dónde está la prueba.

Por eso trato el conjunto como un sistema adaptativo en lugar de como proyectos con fecha de fin. Un programa montado contra el texto de una versión concreta del reglamento envejece con esa versión. Uno montado como producto interno absorbe la siguiente exigencia como un requisito más, porque las piezas ya existen y solo hay que conectarlas. La diferencia se nota el día que llega una obligación nueva y la pregunta es si hay que empezar algo o basta con extender lo que ya existe.

Y queda la parte que ningún marco resuelve: decidir qué nivel de riesgo acepta la organización, qué se hace cuando una evaluación sale mal y hay un área de negocio esperando el despliegue, quién tiene autoridad para parar. Eso se decide en órganos que deciden de verdad, y es donde se ve si el gobierno de IA de una organización pesa algo. El reglamento y la norma te dan el perímetro y el esqueleto. El criterio lo pones tú.

---

Preguntas frecuentes

¿Qué relación hay entre el EU AI Act y la ISO/IEC 42001? Operan en planos distintos y se usan juntos. El EU AI Act es derecho europeo directamente aplicable: agrupa los sistemas de IA en categorías según su uso, impone obligaciones a cada categoría y sanciona el incumplimiento. ISO/IEC 42001 es una norma de gestión voluntaria y certificable que describe el sistema de gestión de IA con el que una organización sostiene esas obligaciones en el tiempo. El reglamento fija qué tienes que poder demostrar; la norma organiza cómo sigues demostrándolo cuando la organización cambia.

¿Es ISO/IEC 42001 una norma armonizada del EU AI Act? No lo es, y en julio de 2026 quedó claro por qué. Las normas armonizadas del artículo 40 son las que la Comisión encarga al comité europeo de normalización CEN-CENELEC JTC 21 y después cita en el Diario Oficial de la Unión Europea, que es el paso que otorga la presunción de conformidad. La primera del paquete ya existe: EN 18286:2026, sobre el sistema de gestión de calidad que el artículo 17 exige a los proveedores de alto riesgo, aprobada el 12 de julio de 2026. Se redactó como norma europea propia en lugar de adoptar ISO/IEC 42001, porque los objetivos y las definiciones de la norma internacional se consideraron desalineados con lo que el reglamento pide en ese artículo. ISO/IEC 42001 llega por otra vía y hace otro trabajo, así que certificarse en ella no otorga presunción de conformidad.

¿Me sirve ISO/IEC 42001 para el sistema de gestión de calidad del artículo 17? Te sirve como base, con un matiz que conviene conocer. En julio de 2026 se aprobó EN 18286:2026, la norma europea que desarrolla ese artículo, y se redactó como norma propia en lugar de adoptar ISO/IEC 42001: los objetivos y las definiciones de la internacional se consideraron desalineados con lo que el reglamento pide ahí. Ambas comparten la estructura de las cláusulas 4 a 10, el enfoque de riesgo y el ciclo de mejora, así que un AIMS en marcha cubre buena parte del camino y el trabajo restante es de alineación, no de construcción. La lectura práctica es integrarlas en un único sistema de gestión en lugar de apilar dos certificados.

¿Certificarme en ISO/IEC 42001 me hace cumplir el EU AI Act? No de forma automática, y conviene entender por qué. La certificación acredita que tienes un sistema de gestión de IA que funciona; la conformidad con el reglamento se acredita sistema a sistema, con el expediente de cada uno. Un certificado te deja hecha buena parte de la maquinaria transversal: inventario, gestión de riesgos, evaluación de impacto, roles y trazabilidad. Lo que no cubre son los actos jurídicos que el reglamento exige para el alto riesgo: evaluación de conformidad, declaración UE de conformidad, marcado CE y registro en la base de datos de la UE.

¿Puedo cumplir el EU AI Act sin certificarme en ISO/IEC 42001? Sí. El reglamento no exige ninguna certificación de sistema de gestión, y hay organizaciones que cumplen sin acercarse a la norma. Lo que necesitas en cualquier caso es la maquinaria: inventario de sistemas, categorización con criterio, obligaciones con dueño y trazabilidad. ISO/IEC 42001 es una forma reconocible y auditable de organizar esa maquinaria, con vocabulario compartido con auditores y clientes. Si prefieres montarla con tu propia estructura, el reglamento lo admite; lo que no admite es no tenerla.

¿Qué obligaciones del EU AI Act cubre un sistema de gestión ISO/IEC 42001? El solapamiento se concentra en seis piezas: el inventario de sistemas de IA; el sistema de gestión de riesgos del artículo 9; la evaluación de impacto, que alimenta la evaluación de impacto sobre derechos fundamentales del artículo 27; los roles y la competencia de quien ejerce supervisión humana; la trazabilidad y la información documentada; y el sistema de gestión de calidad que el artículo 17 exige a los proveedores de alto riesgo. Esta última es la correspondencia más directa: el reglamento pide por ley un sistema de gestión que la norma describe con detalle.

¿Por dónde empiezo si tengo que cumplir el reglamento y quiero certificarme? Por el inventario de sistemas de IA, que sirve a los dos frentes y condiciona todo lo demás. Después categoriza contra el Anexo III, porque el alcance razonable del sistema de gestión se decide sabiendo dónde está tu alto riesgo. Con eso montas un único proceso de evaluación de riesgo e impacto con dos salidas y un solo repositorio de evidencia indexado por sistema. La decisión de certificar llega al final, cuando el sistema ya existe y produce evidencia por sí solo.

¿Sale más caro llevar los dos frentes a la vez? Sale más barato que llevarlos por separado, siempre que compartan las piezas. El sobrecoste aparece cuando se abren dos programas en paralelo, con dos inventarios, dos procesos de riesgo y dos repositorios de evidencia que describen la misma realidad y divergen a los pocos meses. El coste de mantener dos versiones de la verdad supera al de cualquiera de los dos programas, y además obliga a decidir cuál de las dos enseñas cuando alguien pregunta.