ISO 42001: guía completa del sistema de gestión de IA

ISO/IEC 42001 es la norma certificable que fija los requisitos de un sistema de gestión de inteligencia artificial: obliga a la organización a decidir por escrito qué hace con la IA que desarrolla o que compra, quién responde de cada decisión y qué pruebas guarda de haberla tomado. En España la referencia que hay que citar desde el 8 de abril de 2026 es UNE-EN ISO/IEC 42001:2026, que anula la UNE-ISO/IEC 42001:2025 con el mismo contenido técnico. Esta guía recorre el ciclo completo, del alcance al certificado: las cláusulas 4 a 10, los nueve bloques y 38 controles del anexo A, la evaluación de impacto, las evidencias que pide el auditor y la integración con lo que ya tienes certificado. Y llega en una semana señalada: el Ómnibus digital sobre IA está en vigor desde el 27 de julio de 2026 y el 2 de agosto de 2026, fecha general de aplicación del AI Act, queda a tres días.

Qué es un sistema de gestión de IA y qué cambia respecto a 9001 o 27001

Un sistema de gestión de IA (SGIA) es la maquinaria que ya conoces aplicada a otro objeto: política aprobada por dirección, roles con nombre y apellidos, análisis de riesgos, controles, auditoría interna, revisión por la dirección y acciones correctivas. ISO/IEC 42001 no reinventa nada de eso. Lo que cambia, y cambia bastante, es sobre qué se aplica.

En ISO 9001 el objeto es la conformidad de un producto o un servicio con unos requisitos. En ISO/IEC 27001, la protección de la información de la organización. En ISO/IEC 42001 el objeto son los sistemas de IA que la organización desarrolla, proporciona o utiliza, y eso arrastra cuatro diferencias que se notan en la carpeta y en la auditoría.

La primera: el objeto no se queda quieto. Un proceso validado se comporta mañana como se comportó ayer si nadie lo toca. Un sistema que aprende de datos, no: su rendimiento se degrada cuando cambia la población sobre la que decide, cuando el proveedor actualiza el modelo por debajo o cuando los datos de entrada se alteran sin avisar. Así que la validación previa no basta. Hacen falta seguimiento en producción, umbrales para cuando el resultado se sale de lo aceptable y una decisión documentada sobre qué se hace entonces.

La segunda: el daño no lo sufre la organización, lo sufre un tercero. En seguridad de la información el riesgo se mide sobre los activos propios. En IA hay que evaluar además el efecto del sistema sobre las personas y los grupos que reciben sus decisiones. No es una variante del análisis de riesgos: es un segundo análisis, con otro sujeto, y ocupa un bloque entero de controles.

La tercera: el alcance se cuenta por sistemas. Un alcance de calidad se escribe por procesos y por centros; uno de SGIA se escribe por sistemas de IA, con lista. De ahí que el inventario sea la pieza que sostiene todo lo demás: si está mal, el alcance está mal, la evaluación de riesgos está mal y la declaración de aplicabilidad no significa nada.

La cuarta: parte del sistema es de otro. Cuando el modelo lo entrena un proveedor y la herramienta la sirve un tercero desde su nube, la organización gobierna el uso pero no el desarrollo. La norma lo resuelve por el lado del contrato y de la información que se exige, no fingiendo un control que no existe.

Conviene decir también qué no hace la norma. Un certificado de ISO/IEC 42001 no dice que un modelo sea preciso, ni justo, ni seguro: dice que la organización tiene un sistema para decidir sobre eso y para demostrar cómo lo decidió. No es una evaluación de conformidad de un producto ni sustituye a ninguna obligación legal. Adecuar técnicamente un sistema concreto va por otro camino, el de la adecuación técnica al AI Act.

Quién necesita esto: el que desarrolla, el que despliega y el que revende

Antes de mirar cláusulas, sitúate. El esfuerzo de implantación no se reparte igual según lo que hagas con la IA, y confundirse aquí es la forma más rápida de montar la carpeta equivocada.

Si desarrollas, es decir, si entrenas modelos, los ajustas o los integras en un producto que vendes, el peso cae en los bloques de ciclo de vida y de datos. Eres quien tiene que justificar de dónde salieron los datos, qué se probó antes de liberar, con qué criterio se aceptó el resultado y qué información entregas con el producto. Es el perfil que más registros produce.

Si compras y despliegas una herramienta de terceros que criba currículos, puntúa clientes o ayuda a decidir dentro de un proceso, tu SGIA no gira sobre el desarrollo del modelo. Gira sobre para qué autorizas ese sistema, qué exigiste por contrato, qué comprobaste antes de dejarle decidir, quién supervisa y qué pasa cuando el resultado deja de tener sentido. El error clásico aquí es pensar que la norma no aplica porque no se programa nada. Aplica, y la auditoría es igual de exigente; lo que cambia es de dónde salen las evidencias, que viven en contratos, autorizaciones y registros de supervisión.

Si revendes o integras lo de otro bajo tu marca, heredas las dos caras: respondes ante tu cliente de lo que prometes y dependes de un proveedor que no controlas. El sistema te pide coherencia entre ambas, que lo que pasas al cliente final se corresponda con lo que tienes firmado aguas arriba.

Y hay un caso que conviene decir en voz alta: hay organizaciones que no necesitan certificar. Si nadie decide nada con ayuda de un sistema de IA y no se vende nada que la incorpore, montar un SGIA certificable es desproporcionado; con una política de uso y un inventario vivo se cubre el riesgo real. El problema es que casi ninguna empresa sigue en ese caso: la IA entró dentro de herramientas compradas por otro motivo, con funciones activadas por defecto, y eso mete a la organización en el alcance sin que nadie lo haya decidido. Para una empresa pequeña que sí quiere certificar están ISO 42001 para pymes y cómo certificar ISO 42001 en una pyme.

La referencia correcta hoy: UNE-EN ISO/IEC 42001:2026

Casi todo lo que se ha escrito en castellano sobre esta norma cita una referencia anulada. La versión española vigente es UNE-EN ISO/IEC 42001:2026, en vigor desde el 8 de abril de 2026, y anula la UNE-ISO/IEC 42001:2025 desde esa misma fecha. La ficha de la norma retirada en la tienda de AENOR lo dice sin rodeos: fecha de anulación 2026-04-08, «es anulada por UNE-EN ISO/IEC 42001:2026».

El contenido técnico no cambia. AENOR declara la equivalencia internacional como idéntica a ISO/IEC 42001:2023, y el comité responsable sigue siendo el CTN 71/SC 42, de inteligencia artificial y big data. Lo que cambia es el estatus: se pasa de una adopción nacional, con prefijo UNE-, a una adopción europea, con prefijo UNE-EN.

Aquí hay que ser preciso, porque el salto de «norma europea» a «norma armonizada del AI Act» se está dando por hecho y no procede. Que una norma sea EN no la convierte en norma armonizada a efectos del artículo 40 del Reglamento (UE) 2024/1689: para eso su referencia tiene que publicarse en el Diario Oficial a petición de la Comisión. Lo que sí está en el texto es que el artículo 40, apartado 2, tal como lo modifica el Ómnibus digital sobre IA, prevé que la Comisión solicite normas a los organismos europeos de normalización. Hasta ahí llega lo verificable.

La consecuencia práctica es tranquilizadora y aburrida: un sistema implantado contra la UNE de 2025 no hay que rehacerlo, porque el contenido es el mismo. Hay que actualizar la referencia documental, y son más sitios de los que parece: la política de IA, el documento de alcance, el manual si lo hay, la declaración de aplicabilidad, el programa y los planes de auditoría, los informes de auditoría interna, el acta de la última revisión por la dirección y la lista de documentos de origen externo. La cláusula 7 pide control de la información documentada; dejar ahí una norma anulada es un hallazgo evitable. Qué se cambia y en qué orden está en la referencia española de ISO 42001 cambió en abril de 2026.

La estructura de la norma: cláusulas 4 a 10

ISO/IEC 42001 usa la estructura armonizada de las normas de sistemas de gestión, la misma de ISO 9001, ISO 14001, ISO 45001 e ISO/IEC 27001. Si ya tienes un sistema certificado, el trabajo de arquitectura está medio hecho. La tabla resume qué pide cada cláusula cuando el objeto son sistemas de IA y qué acaba, en la práctica, dentro de la carpeta.

Ninguna de esas evidencias es opcional. Lo que varía es la profundidad, y ahí sí tiene sentido la proporcionalidad: una empresa con dos sistemas y quince personas no necesita el mismo aparato que un proveedor con una cartera de modelos en producción. Cada cláusula, con lo que pide y lo que suele quedarse a medias, la desarrollamos en las cláusulas 4 a 10 de ISO 42001.

Contexto, liderazgo y planificación: donde se decide el tamaño del proyecto

Las tres primeras cláusulas deciden cuánto va a costar todo lo demás, y se resuelven en reuniones, no en plantillas.

La cláusula 4 trae una pregunta que no aparece en calidad: cuál es el papel de la organización respecto a cada sistema, porque de eso depende qué controles aplican. La misma empresa puede desarrollar un modelo propio, desplegar una herramienta comprada y revender la de un socio, y las tres cosas conviven en el mismo sistema de gestión con exigencias distintas. El alcance se escribe con lista: qué sistemas entran, cuáles quedan fuera y por qué. Las exclusiones sin motivo escrito son el primer sitio por donde tira un auditor.

La cláusula 5 pide que la dirección se moje. No firmando una política genérica, sino decidiendo qué usos autoriza la organización, cuáles no y quién puede aprobar una excepción. Una política de IA que solo dice que la organización usará la inteligencia artificial de forma responsable no sirve para decidir nada, y se cae con dos preguntas: quién autorizó este sistema y contra qué criterio.

La cláusula 6 es la que más trabajo real tiene. Hay que fijar cómo se identifica y evalúa el riesgo, hacerlo, decidir el tratamiento y además evaluar el impacto de los sistemas sobre las personas afectadas. De ahí sale la declaración de aplicabilidad. Y hay que poner objetivos que se puedan medir: no «mejorar la gobernanza de la IA», sino algo con indicador, valor de partida, responsable y fecha de revisión.

Apoyo, operación, evaluación y mejora: donde el sistema se sostiene o se cae

De la cláusula 7, la parte que se subestima es la competencia: hay que justificar que quien supervisa un sistema de IA entiende lo suficiente para detectar cuándo el resultado no tiene sentido. Un certificado de asistencia a una charla no lo justifica. Lo que funciona es un perfil por puesto con lo que hay que saber y evidencia de que la persona lo sabe.

La cláusula 8 es la operación, y es donde el SGIA se separa de un sistema de calidad clásico. Aquí vive el ciclo de vida completo de cada sistema: qué requisitos se le pusieron, cómo se seleccionó al proveedor o cómo se desarrolló, qué se validó antes de ponerlo a trabajar, quién autorizó el despliegue, qué se vigila en producción, qué se hace con los cambios y cómo se retira. Una carpeta que documenta la política y los controles pero no tiene registros de operación no es un sistema de gestión: es un juego de plantillas.

La cláusula 9 no trae sorpresas de forma. Trae una de fondo: la auditoría interna de un SGIA exige competencia en IA por parte del auditor, y ahí muchas organizaciones descubren que su auditor interno de siempre no cubre este alcance. Se resuelve con formación, con apoyo externo o con un equipo mixto, pero antes de programar la auditoría, no cuando ya está convocada.

En la cláusula 10 el trabajo es de disciplina: que las incidencias de los sistemas de IA entren por el mismo cauce que las demás, con análisis de causa de verdad y verificación de eficacia. Un sistema sin ninguna no conformidad registrada en su primer ciclo no es un sistema maduro; es un sistema que no está mirando.

El anexo A: nueve bloques y 38 controles

El anexo A de ISO/IEC 42001 organiza 38 controles en nueve objetivos de control, numerados de A.2 a A.10. El total está contrastado. El reparto por bloque solo lo da el texto de la norma: las listas que circulan por internet no coinciden entre sí, así que no vamos a repetir un recuento que no podemos sostener. Lo útil tampoco es el número, es saber qué ámbito cubre cada bloque y qué evidencia deja.

Dos avisos. El primero: A.7 es el bloque que más duele cuando el modelo es de un tercero, porque la procedencia de los datos de entrenamiento no la tienes. La salida honesta no es inventar una ficha de procedencia, es documentar qué información pediste al proveedor, qué te entregó, qué no, y qué límite le pone eso al uso que autorizas. Un auditor acepta un límite documentado; no acepta un hueco.

El segundo: A.9 y A.10 concentran casi todo el sistema de quien solo despliega herramientas compradas. Si es tu caso y estás echando el esfuerzo en A.6, lo pones en el sitio equivocado.

La declaración de aplicabilidad y los anexos informativos

La declaración de aplicabilidad recorre los 38 controles y dice, para cada uno, si aplica, por qué sí o por qué no, cómo está implantado y dónde está la evidencia. Es el documento que el auditor usa como índice: entra por ahí y va tirando de las referencias. De modo que las dos columnas que de verdad importan son la justificación de las exclusiones y el enlace a la evidencia. Una declaración con los 38 controles marcados como aplicables y ninguna referencia a un documento real es una declaración de intenciones.

La firma también cuenta. La declaración la propone quien lleva el sistema y la aprueba la dirección, con fecha, porque es una decisión sobre qué riesgos se aceptan. Si cambia el alcance, si entra un sistema nuevo o si un proveedor cambia de modelo, se revisa. Cómo se redacta control a control lo desarrollamos en el anexo A de ISO 42001 y la declaración de aplicabilidad.

La norma trae además tres anexos informativos, y saber para qué sirven ahorra trabajo. Uno ofrece orientación de implantación para los controles del anexo A: es el que se lee cuando no está claro qué se espera de un control. Otro recoge un repertorio de posibles objetivos y fuentes de riesgo relacionados con la IA, útil como punto de partida al fijar objetivos y evaluar riesgos. El tercero trata el uso del sistema de gestión en distintos sectores y la correspondencia con otras normas de sistemas de gestión, que es justo lo que necesita quien ya tiene un sistema integrado. Al ser informativos no se auditan como requisitos, pero se citan bien en la metodología y evitan discusiones sobre cada control.

Cómo se implanta: las fases reales

El orden de las fases no es una preferencia metodológica: cada una necesita el resultado de la anterior. Saltarse la segunda para llegar antes a la cuarta es la causa más común de que un proyecto tenga que volver atrás.

Decisión de dirección y alcance. Antes de tocar un documento hay que saber para qué se hace esto: certificar, prepararse para una exigencia de cliente u ordenar la casa. La respuesta determina el alcance y el alcance determina el resto. Aquí se decide también quién lleva el sistema y con cuánta dedicación, y eso se escribe en un acta con nombres.

Inventario y clasificación. La fase que todo el mundo subestima. No consiste en preguntar a sistemas qué modelos hay, sino en recorrer las áreas preguntando qué decisiones se toman con ayuda de una herramienta, y revisar el gasto en software para localizar las funciones de IA que llegaron dentro de otra cosa.

Riesgos e impacto. Con el inventario cerrado ya se puede evaluar. Riesgo e impacto son dos ejercicios distintos que se alimentan: el primero mira a la organización, el segundo a las personas afectadas. Salen de aquí el plan de tratamiento y la lista de controles que van a aplicarse.

Diseño documental y declaración de aplicabilidad. Ahora se escribe: política, los procedimientos que falten, criterios, plantillas y la declaración. Es la fase que de verdad se acelera si ya hay un sistema certificado, porque buena parte se resuelve ampliando lo que existe.

Operación real. Esta no se comprime. El sistema tiene que funcionar y dejar rastro: autorizaciones firmadas, registros de supervisión, incidencias tratadas, algún cambio de versión gestionado. Sin ese rastro no hay auditoría de certificación que salga bien, porque lo que se audita no es que los documentos existan, es que se usen.

Auditoría interna, revisión y certificación. Auditoría interna con hallazgos y acciones, revisión por la dirección con decisiones, y solo entonces la entidad certificadora, que revisa primero el sistema documentado y después si de verdad se aplica sobre el terreno. El certificado tampoco es el final: hay auditorías de seguimiento y una renovación al cerrarse el ciclo. El detalle está en el cronograma de implantación de ISO 42001.

La carpeta que queda: documentos y registros

Conviene separar dos cosas que se mezclan siempre. Los documentos dicen lo que la organización ha decidido hacer: política de IA, alcance, metodología de riesgos, criterios de aceptación, declaración de aplicabilidad, procedimientos. Se pueden escribir en poco tiempo. Los registros prueban que eso se hizo: llevan fecha, nombre y consecuencia, y no se fabrican sin que se note.

Los registros que sostienen un SGIA, por orden de lo que más se pide en auditoría:

• Inventario de sistemas de IA con histórico: cuándo entró cada uno, quién lo aprobó, si se retiró.
• Informes de evaluación de impacto por sistema, con fecha y con quién los revisó.
• Registros de validación previos al despliegue: qué se probó, con qué datos, contra qué criterio y con qué resultado.
• Autorizaciones de puesta en marcha firmadas por quien tiene autoridad para asumir el riesgo, no por quien instala.
• Registros de supervisión en producción: quién revisa qué, con qué frecuencia y qué encontró.
• Incidencias y reclamaciones sobre los sistemas de IA, con su tratamiento y su cierre.
• Control de cambios y versiones, incluidos los cambios del proveedor de los que te enteras tarde.
• Evidencia de competencia de quien usa el sistema y de quien lo supervisa.
• Evaluación y contratos de proveedores, con las cláusulas relativas a IA.
• Auditoría interna, revisión por la dirección y no conformidades del ciclo, con las acciones verificadas.

Esa lista es también la respuesta a cuánto trabajo es esto. No cansa la cantidad de documentos, cansa mantener los registros al día durante todo el ciclo. Qué formato tiene cada uno y qué se pide exactamente está en las evidencias que pide el auditor de ISO 42001.

Qué mira un auditor, y en qué orden

Un auditor con oficio no empieza por el primer control. Empieza cruzando dos documentos: el alcance y el inventario. Si el alcance dice «todos los sistemas de inteligencia artificial de la organización» y el inventario tiene tres entradas, la siguiente pregunta es por el CRM que puntúa oportunidades, por la herramienta que ordena candidaturas y por el asistente con el que soporte redacta respuestas. Ese cruce marca el tono de todo lo demás.

Después tira de un sistema concreto de punta a punta. Elige el que más impacto tiene sobre personas y recorre la cadena: evaluación de impacto, decisión de seguir adelante, requisitos, validación, autorización, supervisión, incidencias, cambios. Si la cadena se rompe en algún eslabón ahí hay un hallazgo, y suele romperse en el mismo eslabón para todos los sistemas.

Luego mira el cierre del ciclo: no conformidades detectadas, acciones tomadas, verificación de eficacia. Y mira las fechas. Un juego de documentos aprobados todos el mismo día, dos semanas antes de la auditoría, cuenta una historia que el auditor ya ha oído.

La pregunta que más descoloca, y que casi nadie prepara, es sencilla: «enséñame la última vez que este sistema dio un resultado que no os cuadró y qué hicisteis». Si no hay respuesta con registro, lo que falla no es la documentación, es la supervisión. Encontrar eso antes de que lo encuentre el certificador es para lo que sirve una auditoría interna bien hecha.

La evaluación de impacto y el papel de ISO/IEC 42005

ISO/IEC 42005:2025, en vigor desde el 28 de mayo de 2025, es la guía de evaluación de impacto de sistemas de IA. Dos cosas que conviene tener claras antes de encargarla: no se certifica, porque es una guía y no una norma de requisitos, y no tiene versión española, ya que AENOR la vende con el código internacional, sin prefijo UNE-.

Qué aporta entonces. ISO/IEC 42001 exige evaluar el impacto de los sistemas de IA, pero el requisito no viene con un método. 42005 es el método: cómo se delimita qué se evalúa, qué información hay que reunir, qué se documenta, quién revisa el resultado y cuándo hay que repetir la evaluación. Para un responsable de calidad es la diferencia entre un requisito y un procedimiento auditable.

La confusión más habitual es tratar riesgo e impacto como el mismo ejercicio. El análisis de riesgos mira hacia dentro: qué puede ir mal para la organización y sus objetivos. La evaluación de impacto mira hacia fuera: qué le pasa a la persona a la que el sistema deniega algo, clasifica o pone en una cola. Se alimentan, pero un informe no sustituye al otro, y presentar el registro de riesgos como evaluación de impacto es una no conformidad limpia.

Para la gestión del riesgo hay además una guía específica, ISO/IEC 23894:2023, con adopción europea EN ISO/IEC 23894:2024. Su versión española sigue en estado de proyecto, como PNE-EN ISO/IEC 23894, así que a 30 de julio de 2026 no hay traducción UNE publicada. Si tu sistema documental exige citar versiones en español, tenlo en cuenta al redactar la metodología.

Hay un punto de encaje con la ley que merece mencionarse sin entrar en él. El AI Act, tras la modificación del Ómnibus, permite al responsable del despliegue apoyarse en la evaluación de impacto de protección de datos que ya tenga hecha e «incluir referencias cruzadas a las secciones pertinentes de dicha evaluación de impacto relativa a la protección de datos», y anuncia un modelo de cuestionario de la Oficina de IA. Cómo se cumple esa obligación legal es asunto jurídico y está tratado en el cumplimiento del AI Act para empresas. Lo que nos toca desde calidad es que la evaluación de impacto del sistema de gestión y la del RGPD se hablen entre ellas en vez de vivir en carpetas separadas. El procedimiento completo está en la evaluación de impacto con ISO 42005, paso a paso, y el planteamiento en nuestro servicio de ISO 42005.

Integrarlo con 9001, 27001 y 27701: el mapa de documentos

El porqué de integrar en vez de montar un sistema paralelo ya está argumentado en integrar ISO 42001 con ISO 9001 y 27001. Lo que falta, y es lo primero que se pide en cuanto arranca el proyecto, es el mapa: coger la carpeta de ISO 9001 o de ISO/IEC 27001 documento por documento y decidir qué vale tal cual, qué se amplía y qué hay que crear. Sin porcentajes de ahorro, que no significan nada: con nombres de documento.

Lo que no se reutiliza merece párrafo aparte, porque es donde se pierde el tiempo intentándolo. La declaración de aplicabilidad de 27001 no vale: los controles son otros y la lógica es otra. El inventario de activos tampoco: registra activos, no sistemas que deciden. Y los criterios de aceptación de un proceso no valen para un modelo cuyo rendimiento se degrada, porque una comprobación puntual no cubre un comportamiento que cambia.

Si el sistema de IA trata datos personales, ISO/IEC 27701 es la vecina natural, y la conexión pasa por el registro de tratamientos y por la evaluación de impacto de protección de datos. Y si todavía no hay un sistema integrado montado, conviene ver antes cómo se estructura uno en sistema de gestión integrado: integrar sobre un sistema desordenado multiplica el desorden.

El AI Act visto desde el sistema de gestión

Esto se cuenta mal en las dos direcciones: hay quien vende el certificado como si eximiera de la ley y hay quien dice que no sirve de nada. Empecemos por el calendario, que condiciona el orden de trabajo de cualquier proyecto.

El 2 de agosto de 2026 es la fecha general de aplicación del Reglamento (UE) 2024/1689 y se mantiene: el Ómnibus digital sobre IA no la ha movido. Lo que sí ha movido es el capítulo III. Los requisitos de los sistemas de alto riesgo del artículo 6, apartado 2, y del anexo III pasan al 2 de diciembre de 2027, y los del artículo 6, apartado 1, y del anexo I, al 2 de agosto de 2028. El artículo 6, apartado 5, queda expresamente exceptuado de ese aplazamiento. Los capítulos I y II, con la alfabetización en IA y las prácticas prohibidas, se aplican desde el 2 de febrero de 2025; las nuevas letras que el Ómnibus inserta en el artículo 5 llegan el 2 de diciembre de 2026; y los artículos 102 a 110 se aplican desde el 27 de julio de 2026.

Dos fechas más que afectan a la planificación. Los proveedores de sistemas que generan contenido sintético y estaban ya en el mercado antes del 2 de agosto de 2026 tienen hasta el 2 de diciembre de 2026 para cumplir el marcado del artículo 50, apartado 2: el propio reglamento lo llama «un período transitorio de cuatro meses». Y los sistemas de alto riesgo destinados a autoridades públicas ya en servicio tienen plazo hasta el 2 de agosto de 2030. El aplazamiento del alto riesgo no es una excusa para parar: el inventario y las evaluaciones de impacto tardan lo que tardan, y la ventana que se ha abierto es la que hace falta para montar el sistema de gestión sin prisas.

La pregunta útil es entonces qué evidencia del SGIA sirve para acreditar diligencia. Sirve el inventario, porque demuestra que la organización sabe qué sistemas tiene y para qué. Sirven las evaluaciones de impacto fechadas y revisadas. Sirven los registros de validación y de supervisión, porque muestran control efectivo y no declarado. Sirve la gestión de proveedores, si los contratos dicen algo. Y sirve la evidencia de competencia, que conecta con el artículo 4, reescrito por el Ómnibus para dejar claro que «esta obligación no exige que los proveedores o los responsables del despliegue garanticen un nivel específico de alfabetización en materia de IA de ninguna persona en particular». Se piden medidas, no un resultado garantizado por persona.

Y qué no cubre. El certificado se emite sobre la organización y su sistema de gestión, no sobre un sistema de IA concreto, así que no acredita la conformidad de un producto ni sustituye a ninguna obligación que la ley imponga según el papel que juegues. Tampoco genera presunción de conformidad: para eso haría falta una norma armonizada con su referencia publicada en el Diario Oficial, y eso hoy no consta. El reparto pieza por pieza entre los controles del anexo A y los artículos del reglamento ya lo publicamos en ISO 42001 y AI Act: mapeo de controles; las obligaciones legales por rol son terreno de Summum Consultoría. Qué cambia el Ómnibus para quien ya tiene el sistema montado está en el Ómnibus de IA y el sistema de gestión.

El artículo 17 y el artículo 63: el sistema de gestión de la calidad que pide la ley

Para un responsable de calidad, los dos artículos del AI Act que hay que leer no son los de riesgos: son los que hablan de sistema de gestión de la calidad. El artículo 17 lo exige a los proveedores de alto riesgo, y el Ómnibus digital sobre IA, el Reglamento (UE) 2026/1744, le ha añadido un apartado que cambia el tono:

«La aplicación de los aspectos mencionados en el apartado 1 será proporcional al tamaño de la organización del proveedor, en particular si el proveedor es una pyme, incluidas las empresas emergentes o las pequeñas empresas de mediana capitalización. Los proveedores respetarán, en todo caso, el grado de rigor y el nivel de protección requerido para garantizar la conformidad de sus sistemas de IA de alto riesgo con el presente Reglamento.»

Proporcionalidad, sí; rebaja del nivel de protección, no. Es el mismo criterio con el que se audita cualquier norma de sistemas de gestión.

El artículo 63 va un paso más allá con las pequeñas:

«Las pymes, incluidas las empresas emergentes, podrán cumplir determinados elementos del sistema de gestión de la calidad exigido por el artículo 17 del presente Reglamento de manera simplificada, siempre que no tengan empresas asociadas o empresas vinculadas en el sentido de la Recomendación 2003/361/CE. A tal fin, la Comisión elaborará directrices sobre los elementos del sistema de gestión de la calidad que puedan cumplirse de manera simplificada teniendo en cuenta las necesidades de las pymes sin que ello afecte al nivel de protección ni a la necesidad de cumplir los requisitos relativos a los sistemas de IA de alto riesgo.»

Hay dos cosas prácticas ahí. La condición: la simplificación se pierde si hay empresas asociadas o vinculadas, cosa que en grupos con varias sociedades pasa más de lo que parece. Y el plazo: las directrices todavía tienen que llegar, y hasta que lleguen no se sabe qué elementos van a poder simplificarse. Diseñar hoy el sistema contando con una simplificación que aún no está definida es una apuesta, no una decisión.

En la misma línea, el Ómnibus permite a las pymes presentar los elementos de la documentación técnica del anexo IV «de manera simplificada», mediante un formulario que establecerá la Comisión y y que «los organismos notificados aceptarán dicho formulario a efectos de la evaluación de la conformidad». Es un alivio de forma, no de fondo: el contenido hay que tenerlo igual, y sale del mismo sitio que la documentación del SGIA.

La lectura de conjunto: el AI Act no pide ISO/IEC 42001 en ningún sitio. Pide un sistema de gestión de la calidad a los proveedores de alto riesgo, y quien tenga un SGIA en marcha llega a esa exigencia con la mayor parte de la maquinaria montada, control documental, gestión de cambios, competencia, proveedores, vigilancia posterior a la puesta en el mercado y tratamiento de incidencias incluidos. No es una equivalencia y no se puede vender como tal, pero es el camino más corto que hay.

Elegir certificadora: ISO/IEC 42006 y el alcance acreditado

ISO/IEC 42006:2025, publicada el 7 de julio de 2025, fija los requisitos que deben cumplir los organismos que auditan y certifican un sistema de gestión de IA, adicionales a los de ISO/IEC 17021-1. Es la referencia contra la que se acredita un certificador, y lo que hace que un certificado signifique lo mismo emitido por una entidad que por otra. Al comprador le importa por una razón: un certificado emitido fuera de un esquema acreditado no pesa igual ante un cliente grande ni en una licitación.

Y aquí toca ser exacto, porque hay bastante ruido comercial. A 30 de julio de 2026 no consta públicamente un esquema de acreditación de ENAC para ISO/IEC 42001: la búsqueda en su web no devuelve ningún criterio con esa referencia, y alguna entidad que opera en España declara en la suya estar en proceso de acreditación, es decir, en trámite. No se puede afirmar que ya haya entidades acreditadas, ni lo contrario en tono rotundo. Lo que sí se puede hacer, y es lo que recomendamos, es comprobar el alcance concreto de la entidad en el Buscador de acreditados de ENAC antes de firmar.

Preguntas que conviene hacer antes de contratar:

• Contra qué referencia audita. Si responde UNE-ISO/IEC 42001:2025, está citando una norma anulada.
• Qué alcance figura exactamente en su acreditación y para qué actividades, comprobado en el buscador de ENAC y no en su folleto.
• Quién audita y con qué competencia en IA, no solo en sistemas de gestión.
• Cómo se organiza el ciclo: etapas de la auditoría inicial, seguimientos y renovación.
• Si el certificado va a cubrir todos los sistemas del alcance que has definido o solo una parte.

La familia crece y se confunde con facilidad. Qué norma es de requisitos, cuál es guía y cuál va dirigida a los certificadores lo repasamos en la familia de normas ISO de inteligencia artificial.

Los errores que hunden un proyecto de SGIA

Escribir un alcance para quedar bien. «Todos los sistemas de inteligencia artificial de la organización» suena serio y es una promesa que la auditoría comprueba una por una. Un alcance estrecho, defendible y ampliable en el siguiente ciclo vale más que uno amplio que no se sostiene.

Un inventario con solo lo que se desarrolló en casa. Falta lo que llegó dentro de otra compra: la función de IA activada por defecto en el CRM, el módulo que ordena candidaturas, el asistente que un equipo empezó a usar sin pasar por nadie. Se cierra preguntando por decisiones y revisando el gasto en software, no preguntando por tecnología.

Confundir el sistema con una carpeta. Treinta y ocho controles con su documento y ni un registro de operación. Es lo primero que se detecta, y no se arregla en la semana previa a la auditoría porque lo que falta lleva fecha.

Copiar la declaración de aplicabilidad de 27001. Se ve enseguida, porque las justificaciones hablan de confidencialidad y disponibilidad donde tenían que hablar de impacto en las personas y de calidad de los datos.

Dejarlo en manos del departamento de sistemas. Para qué se autoriza un sistema, qué resultado se acepta y quién asume el riesgo de ponerlo a decidir son decisiones de negocio. Sistemas puede sostener la evidencia técnica; no puede firmar eso.

Una evaluación de impacto sin fecha de caducidad. Si no está escrito qué dispara una nueva evaluación, sea un cambio de modelo, de proveedor, de finalidad o de población afectada, el informe envejece y el auditor lo nota por la fecha antes que por el contenido.

Contratos firmados antes del proyecto y nunca revisados. El bloque de terceros pide cláusulas que en los contratos antiguos no están, y renegociar con un proveedor grande no se hace en una semana: conviene abrir la lista de proveedores críticos al principio. Cada uno de estos fallos, con la no conformidad que genera y cómo se cierra, está en las no conformidades típicas de ISO 42001.

Los tres primeros movimientos

Si esto va a pasar de lectura a proyecto, hay tres cosas que se pueden hacer sin decidir todavía si se certifica.

Uno: el inventario en una hoja. Una fila por sistema y seis columnas: para qué se usa, quién decide con él, qué datos consume, de quién es, si afecta a personas y qué pasa si falla. Con eso se puede estimar el esfuerzo; sin eso, cualquier plan es ficción.

Dos: actualizar la referencia. Buscar en la documentación toda mención a UNE-ISO/IEC 42001:2025 y sustituirla por UNE-EN ISO/IEC 42001:2026. Es la corrección más barata del proyecto y evita un hallazgo tonto.

Tres: llevar una decisión concreta a la próxima revisión por la dirección. No «estamos estudiando el tema de la IA», sino: este es el alcance propuesto, estos sistemas entran y estos quedan fuera, esto pedimos en horas y en apoyo externo, y esta es la fecha objetivo. Un SGIA que no arranca con una decisión de dirección se queda en un cajón.

El orden de todo lo demás está en el cronograma de implantación y el planteamiento del proyecto en nuestro servicio de ISO 42001. Si necesitas que alguien mire tu caso y te diga por dónde empezar, puedes ponerte en contacto con Summum Calidad.

Preguntas frecuentes

¿Es obligatorio certificar ISO 42001 para cumplir el AI Act?

No. El AI Act no exige en ningún artículo la certificación de ISO/IEC 42001. A los proveedores de sistemas de alto riesgo les exige un sistema de gestión de la calidad (artículo 17), que el Ómnibus digital sobre IA permite aplicar de forma proporcional al tamaño de la organización, y que las pymes sin empresas asociadas ni vinculadas podrán cumplir de manera simplificada (artículo 63). Un sistema de gestión de IA certificado aporta buena parte de esa maquinaria, pero no sustituye a las obligaciones legales.

¿Qué referencia de ISO 42001 tengo que citar, la de 2025 o la de 2026?

UNE-EN ISO/IEC 42001:2026, en vigor desde el 8 de abril de 2026. La UNE-ISO/IEC 42001:2025 está anulada desde esa misma fecha. El contenido técnico es idéntico al de ISO/IEC 42001:2023, así que no hay que rehacer el sistema: hay que actualizar la referencia en la política, el alcance, la declaración de aplicabilidad y los informes de auditoría.

¿Cuántos controles tiene el anexo A de ISO 42001?

Tiene 38 controles agrupados en nueve objetivos de control, numerados de A.2 a A.10, que van de las políticas de IA a las relaciones con terceros y clientes. El reparto de controles dentro de cada bloque solo lo da el texto de la norma: las listas que circulan por internet no coinciden entre sí.

¿Puedo aprovechar mi ISO 9001 o mi ISO 27001 para montar el sistema de gestión de IA?

Sí en la parte de sistema, porque comparten la estructura de cláusulas 4 a 10: auditoría interna, revisión por la dirección, control documental, competencia y no conformidades se integran sin rehacerlos. Lo que no se reutiliza es la declaración de aplicabilidad, porque los controles son otros, el inventario de sistemas de IA y la evaluación de impacto sobre las personas afectadas.

¿Hay entidades acreditadas en España para certificar ISO 42001?

A 30 de julio de 2026 no consta públicamente un esquema de acreditación de ENAC para ISO/IEC 42001. ISO/IEC 42006:2025 fija los requisitos que deben cumplir los organismos que certifican un sistema de gestión de IA, adicionales a ISO/IEC 17021-1. Antes de firmar con una certificadora conviene comprobar su alcance concreto en el Buscador de acreditados de ENAC.