ISO 42001: las evidencias que pide el auditor

Un auditor de certificación de ISO/IEC 42001 no audita la norma: audita la carpeta. Entra por el inventario de sistemas de IA, escoge una muestra y tira del hilo hasta el punto en que lo documentado deja de coincidir con lo que la empresa hace. Esta es la lista de lo que pide, qué tiene que contener cada evidencia y el defecto por el que cada una acaba en hallazgo.

Por qué la carpeta de 9001 no se copia y se pega

El control de la información documentada que ya tiene montado sirve tal cual. Lo que cambia es el objeto: un proceso de fabricación está quieto entre dos auditorías, y un sistema de IA cambia de versión cuando el proveedor actualiza el modelo, o de comportamiento cuando alguien activa una casilla nueva en una herramienta de siempre. De ahí la regla que ordena la carpeta: toda evidencia lleva fecha y versión, y toda decisión lleva nombre. La pregunta ya no es «¿existe el procedimiento?», sino «¿estaba vigente el día que el sistema cambió?».

Y un aviso: la mitad de estas evidencias no las produce calidad, sino quien opera el modelo; sin una vía acordada para pedirlas, la carpeta llega con los documentos de gobierno impecables y sin un registro de operación. El sistema entero, en la guía completa de ISO 42001.

La carpeta entera: evidencia, contenido mínimo y la pregunta que se oye en la sala

La columna de la derecha no es retórica: son las preguntas con las que arranca un auditor cuando ya tiene el documento delante.

Alcance: donde se decide qué se audita, y el caso incómodo

El alcance fija el perímetro de todo lo demás y es el primero que se lee. Necesita dos listas y una firma: qué sistemas entran, qué queda fuera con su motivo y la aprobación de quien responde por esa decisión. Los requisitos que obligan a delimitarlo están en las cláusulas 4 a 10 de ISO 42001.

El caso incómodo es siempre el mismo: la IA embebida en herramientas de terceros. El CRM que redacta la respuesta, el ERP con módulo de previsión, la herramienta de selección que ordena candidaturas. Nadie ha desarrollado nada y el reflejo es dejarlo fuera por eso, que es lo que el auditor pone a prueba: la propiedad del modelo no es un criterio de alcance, cuenta quién lo usa y para qué decisión.

Una exclusión aguanta cuando apunta a algo comprobable fuera del propio documento: la funcionalidad está desactivada, con la evidencia de configuración que lo demuestre, o el sistema pertenece a otra sociedad. Lo que no aguanta es «no aplica porque es de un tercero»: el uso de los sistemas de IA y las relaciones con terceros son dos de los nueve bloques del anexo A precisamente por esto.

Por dónde se cae: el alcance se escribe al principio y no se vuelve a tocar. El auditor compara su fecha con la del último cambio del inventario; si el inventario es más reciente y nadie reaprobó el alcance, el hallazgo se escribe solo. El reparto de papeles legales es otra discusión, la de cumplimiento del AI Act para empresas.

Inventario de sistemas de IA: los campos que lo separan de un Excel muerto

Del inventario cuelga todo: riesgos, impacto, declaración de aplicabilidad, formación, evaluaciones de proveedor. Si está mal, lo que se apoya en él está mal, y el auditor no necesita abrir nada más para saberlo. Se trata como un registro con propietario y fecha de revisión, no como un anexo.

Cada campo contesta una pregunta. El propietario es una persona, no un departamento: un departamento no explica por qué se decidió algo. La finalidad dice si el sistema decide o apoya una decisión, y quién revisa la salida: ese campo determina si hace falta evaluación de impacto. El origen del modelo va con versión y fecha del último cambio conocido, porque en un modelo de tercero la versión cambia sin que nadie de la casa firme nada. Y la fase del ciclo de vida lleva fecha: un sistema «en pruebas» desde hace demasiado suele estar en producción con otro nombre.

Por dónde se cae. El inventario no tiene dueño y nadie lo actualiza. Los pilotos no entran porque «son pruebas», y el que ya trata candidaturas reales está dentro quiera o no. Y hay una comprobación que un auditor hace sin avisar: preguntar a marketing qué herramientas usa. Si sale un nombre que no está en la lista, el agujero es de todo lo que cuelga del inventario.

Política, roles y la firma que autoriza la producción

La política del SGIA se comprueba en tres cosas: quién firma, con qué fecha y si dice algo que se pueda incumplir. La firma es de quien puede asignar recursos, no del responsable de calidad. Lo que hace útil el documento es concretar los usos vetados: qué decisiones no se automatizan sin revisión humana, qué datos no entran en un modelo. Integrada con la política de calidad y seguridad de la información, vale; diluida en ella, no.

De los roles, el que casi nadie tiene documentado es el que más se pregunta: quién autoriza que un sistema de IA pase a producción. En 9001 la liberación del producto tiene una autoridad definida; aquí el equivalente es la autorización para trabajar con datos reales, y tiene que constar que fue anterior a la puesta en marcha. Su reverso vale igual: quién puede pararlo, y si puede hacerlo sin pedir permiso a quien lo aprobó.

Por dónde se cae: la matriz donde todas las celdas dicen «Responsable de Calidad», y la autorización suelta en un mensaje o un ticket. El formato no es el problema —un ticket fechado y trazable que identifique a quien aprobó vale—; el problema es no poder decir quién decidió.

Riesgo y evaluación de impacto: dos evidencias, no una

La evaluación de riesgos mira el efecto sobre los objetivos de la organización: el modelo falla y para una línea, la salida filtra información. La evaluación de impacto mira el efecto sobre las personas alcanzadas por el sistema, que pueden no ser clientes ni empleados y a menudo no sabrán que hubo un modelo por medio. Un registro de riesgos con sus columnas de probabilidad y consecuencia contesta la primera pregunta; la segunda no cabe ahí, y forzarla lleva a un hallazgo en el bloque de evaluación de impactos del anexo A.

La guía de referencia para la segunda es ISO/IEC 42005:2025, publicada el 28 de mayo de 2025. Es guía, no norma certificable: el auditor no le audita 42005, comprueba que su evaluación hace lo que el sistema de gestión necesita. El método, en la pieza sobre la evaluación de impacto con ISO 42005.

Un encaje documental que ahorra trabajo: el Ómnibus digital sobre IA, Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026, modificó el artículo 27 del AI Act para que la evaluación de impacto relativa a los derechos fundamentales pueda «incluir referencias cruzadas a las secciones pertinentes de dicha evaluación de impacto relativa a la protección de datos», la del artículo 35 del RGPD. Se citan entre sí en vez de repetirse, siempre que cada una conserve su objeto. A quién obliga cada una es materia legal.

Por dónde se cae: una sola evaluación de impacto para toda la empresa, cuando el objeto es el sistema y su contexto de uso; y otra que enumera efectos posibles y no termina en medidas, así que no engancha con ningún control.

Declaración de aplicabilidad: el índice con el que el auditor elige

La declaración de aplicabilidad es el mapa de muestreo. Para cada uno de los 38 controles del anexo A —nueve objetivos, numerados de A.2 a A.10— hay una decisión, una justificación y una referencia a la evidencia. El auditor lee la referencia y pide el documento; si dentro no hay nada de IA, la referencia era un adorno. Cómo se justifica una exclusión, en la pieza del anexo A de ISO 42001.

Es también el documento donde se nota un cambio reciente: la referencia española vigente es UNE-EN ISO/IEC 42001:2026, en vigor desde el 8 de abril de 2026, que sustituye a la UNE-ISO/IEC 42001:2025, anulada ese mismo día. El contenido es idéntico —AENOR declara la equivalencia con ISO/IEC 42001:2023—, así que no hay nada que rehacer: lo que se actualiza es la cita, y vive en la política, el alcance, esta declaración y los informes de auditoría. El detalle, en la referencia española que cambió.

Competencia: documentar la alfabetización en IA sin inflarla

La evidencia de competencia son cuatro piezas encadenadas: el perfil del rol, lo que la persona aporta frente a ese perfil, la formación recibida con su fecha y la comprobación de que sirvió de algo. Se documenta por rol y luego se asigna.

La parte específica de IA tiene un matiz que conviene aprovechar. El artículo 4 del AI Act, aplicable desde el 2 de febrero de 2025, obliga a proveedores y responsables del despliegue a adoptar medidas de alfabetización en IA de su personal, según sus conocimientos, su experiencia y el contexto de uso previsto. El Ómnibus lo reescribió y añadió una frase que cambia la exigencia:

«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.»

No rebaja la obligación de tomar medidas; rebaja la de certificar a cada individuo. Para la carpeta, el examen genérico para toda la plantilla está mal colocado: la evidencia se sostiene en contenidos distintos por rol, en el registro de quién recibió qué y cuándo, y en demostrar que llegó a quien toca esos sistemas. La proporcionalidad tiene un límite, y lo marca el propio Reglamento al tratar el sistema de gestión de la calidad de los proveedores de alto riesgo: «los proveedores respetarán, en todo caso, el grado de rigor y el nivel de protección requerido».

Por dónde se cae: la hoja de firmas de asistencia como evidencia de competencia. La asistencia prueba presencia. El auditor pregunta algo sobre el sistema a quien lo opera y, si la respuesta no cuadra con el registro, el hallazgo lo produce el registro. El otro defecto es de reparto: la formación fue al equipo técnico y quien revisa las salidas no tiene nada a su nombre.

Proveedores: qué queda por escrito de quien te vende el modelo

Cuando el modelo es de un tercero, la evidencia se parte en dos: lo que se exige por contrato y lo que queda de haberlo evaluado. Del contrato, un auditor busca cláusulas concretas: información sobre el modelo y sus límites conocidos; aviso previo de cambios de versión o reentrenamiento; qué hace el proveedor con los datos que se le envían y si los usa para entrenar; derecho a recibir evidencia o a auditar.

De la evaluación queda un registro fechado: criterios aplicados, documentación recibida, quién decidió y qué se aceptó pese a no cumplirse. Eso último distingue una evaluación de un formulario: casi ningún proveedor cumple todo, y contratarlo igualmente es la decisión que hay que poder explicar.

Por dónde se cae. Contratos firmados antes de que existiera el sistema de gestión, sin cláusula de IA y sin plan de renegociación: un auditor acepta un plan con fechas, no acepta el silencio. Y el certificado del proveedor cuyo alcance no cubre el servicio que usted compra, la trampa de los certificados de seguridad que solo amparaban el centro de datos.

Registros de operación: cambios, pruebas y deriva

Estos tres son los que faltan cuando llega el auditor, y no se pueden escribir la semana anterior. El control de cambios del sistema de IA registra qué cambió —versión del modelo, instrucciones, datos de entrenamiento, integraciones—, quién lo aprobó, cuándo pasó a producción y qué se comprobó después. El que casi nunca está anotado es el cambio que no decide nadie de la casa: el proveedor actualiza su modelo y el comportamiento cambia sin que se haya movido una línea.

Las pruebas anteriores a producción valen si el criterio de aceptación se fijó antes de probar. «Funciona bien» no es un criterio. Y el expediente incluye las pruebas que salieron mal: un archivo donde todo salió bien a la primera está peinado.

El seguimiento del rendimiento necesita cuatro datos: el indicador, cada cuánto se mide, el umbral que obliga a actuar y quién lo lee. La degradación de un modelo no salta como un error: es una deriva lenta, y sin umbral escrito nadie la detecta hasta que la reclama un cliente. Cómo se implementa el registro de eventos dentro del sistema es otro terreno, el de la adecuación técnica al AI Act.

Por dónde se cae: el indicador vive en un panel técnico que nadie mira desde el sistema de gestión, así que no llega a la revisión por la dirección. La evidencia de seguimiento no es el panel: es el registro de que alguien lo leyó y decidió algo.

Auditoría interna, revisión por la dirección y no conformidades

De la auditoría interna se piden cuatro cosas: el programa del ciclo, el plan de cada auditoría, el informe con hallazgos y evidencia examinada, y la competencia del auditor. La cuarta es la que falla. Quien se sabe 9001 y 27001 de memoria audita las cláusulas sin problema y no sabe qué preguntar sobre datos de entrenamiento, deriva del modelo o revisión de salidas. La salida es un equipo mixto o apoyo externo, con el registro de competencia diciendo de dónde sale ese conocimiento; si el ciclo lo lleva un tercero, la auditoría interna de sistemas de gestión se contrata con esa condición.

El acta de revisión por la dirección delata si el sistema es real: la mayoría son el acta de 9001 con «IA» sustituido en tres párrafos. Las entradas propias de un SGIA: estado del inventario y sistemas que han entrado o salido; resultados de las evaluaciones de impacto y colectivos afectados nuevos; desempeño de los sistemas en producción, con sus desviaciones; incidentes y reclamaciones por salidas de IA; cambios del contexto legal y normativo; y necesidades de recursos y competencia. Como salida, decisiones con responsable y fecha: un acta que enumera temas tratados y no decisiones es una lista de asistencia con orden del día.

El registro de no conformidades necesita el hecho y la causa separados, la acción inmediata separada de la correctiva, responsable, plazo y verificación de la eficacia con su fecha. Se cae por dos sitios: la causa escrita como «falta de formación» o «error humano», que son categorías y no causas, y el cierre sin verificar, que se ve comparando la fecha de la acción con la del cierre. El repertorio está en las no conformidades típicas de ISO 42001.

Cómo se presenta la carpeta y qué comprobar antes de firmar con la certificadora

Como criterio general, la auditoría de certificación revisa el sistema documentado y después si se aplica sobre el terreno; los tiempos están en el cronograma de implantación de ISO 42001. Ayudan dos cosas: un índice único que lleve de cada requisito y cada control al documento y su versión, y una regla de conservación que sea la que su propio control de la información documentada tenga definida. Los años no los trae el auditor de fuera: comprueba la coherencia con la regla que usted escribió.

Queda una comprobación que no está en la carpeta y decide cuánto vale el sello. ISO/IEC 42006:2025, publicada el 7 de julio de 2025, fija los requisitos adicionales a ISO/IEC 17021-1 para los organismos que certifican un sistema de gestión de IA. A 30 de julio de 2026 no consta públicamente un esquema abierto de acreditación en España para ISO/IEC 42001, así que antes de firmar conviene mirar el alcance de la entidad en el Buscador de acreditados de ENAC: un certificado cuyo alcance no está acreditado no pesa lo mismo ante un cliente grande.

Si hay que empezar por un documento, es el inventario. Los demás se escriben contra él.

Preguntas frecuentes

¿Qué documentos pide un auditor de ISO 42001?

Son catorce: alcance del sistema de gestión de IA, inventario de sistemas, política, roles y responsabilidades, evaluación de riesgos, evaluación de impacto, declaración de aplicabilidad de los controles del anexo A, competencia y formación por rol, evaluación de proveedores, control de cambios del sistema, seguimiento del rendimiento del modelo, auditoría interna, revisión por la dirección y el registro de no conformidades y acciones correctivas. El que se lee primero es el inventario, porque los demás se escriben contra él.

¿Es lo mismo la evaluación de riesgos que la evaluación de impacto en ISO 42001?

No, y confundirlas es una de las causas frecuentes de hallazgo. La evaluación de riesgos mira el efecto sobre los objetivos de la organización; la evaluación de impacto mira el efecto sobre las personas y los colectivos alcanzados por el sistema, que pueden no ser clientes ni empleados. Son dos documentos con objetos distintos, y para el segundo la guía de referencia es ISO/IEC 42005:2025, publicada el 28 de mayo de 2025, que es guía y no norma certificable.

¿Cuánto tiempo hay que guardar los registros de un sistema de gestión de IA?

El plazo que vale es el que su propio control de la información documentada tenga definido, junto con los requisitos legales o contractuales que le afecten. No damos un número de años porque no sale de la norma: sale de su sistema. Lo que comprueba el auditor es la coherencia entre la regla que usted escribió y lo que de verdad conserva.

¿Hay que meter en el alcance la IA que viene dentro de herramientas de terceros?

Si la organización la usa y esa funcionalidad interviene en una decisión de los procesos incluidos, sí: la propiedad del modelo no es un criterio de alcance. Se puede excluir cuando la funcionalidad está desactivada y hay evidencia de configuración que lo demuestre, cuando no interviene en ninguna decisión del alcance o cuando el sistema pertenece a otra sociedad. La exclusión tiene que apuntar a algo comprobable fuera del propio documento de alcance.

¿Vale un curso general de IA para acreditar la competencia en una auditoría?

Vale como parte, no como prueba. La competencia se documenta por rol: qué tiene que saber quien hace ese trabajo, qué aporta la persona frente a ese perfil y cómo se comprobó que la formación sirvió. El artículo 4 del AI Act, reescrito por el Reglamento (UE) 2026/1744, precisa además que la obligación de alfabetización en IA «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», así que el esfuerzo rinde más en contenidos diferenciados por rol que en un examen para toda la plantilla.