Auditoría ISO 42001 en 2026: qué evidencia exige un sistema de gestión de IA

Por qué la conversación sobre auditoría de IA cambió en 2026

Tres cosas ocurrieron en trece meses que reescribieron discretamente cómo se asegura un sistema de gestión de inteligencia artificial, y la mayoría de los programas de gobernanza no ha incorporado ninguna: ISO/IEC 42006 dotó a los organismos de certificación de su propio marco, ISO 19011 se revisó y se aplica desde su publicación sin ventana de transición, y el 27 de julio de 2026 la Unión Europea aplazó el grueso de sus obligaciones sobre IA de alto riesgo más de un año.

En conjunto, esos tres cambios desplazan el centro de gravedad, porque el plazo regulatorio hacia el que todos trabajaban se ha movido mientras la vía voluntaria de certificación se ha vuelto a la vez más rigurosa y, por primera vez, realmente comparable entre un certificado y otro. Así que si tu plan de 2026 se escribió en torno a un precipicio regulatorio en agosto de 2026, ahora apunta a algo que ya no está ahí.

Esta guía se dirige a quienes deben responder la pregunta en un informe de consejo o en una revisión de seguridad de un cliente: qué exige realmente una auditoría ISO/IEC 42001, qué evidencia la satisface y qué aporta un certificado bajo el Reglamento de IA ahora que el calendario ha cambiado. Es deliberadamente específica sobre la evidencia, porque ahí es donde fallan los programas de preparación. Las organizaciones llegan a la etapa 2 con un cuerpo de políticas y sin registro alguno de las decisiones que esas políticas debían gobernar.

Siempre me preguntan alguna versión de «¿estamos listos?», y es la pregunta equivocada, porque la preparación no es un estado al que se llega, es una propiedad de tus registros. Si tu evidencia solo existe porque alguien la reunió para la auditoría, nunca estuviste listo sino arreglado, y son cosas distintas que la edición de 2026 de ISO 19011 está diseñada precisamente para separar.

Las tres capas de aseguramiento que se confunden constantemente

Casi toda conversación confusa sobre aseguramiento de IA funde tres cosas distintas en una. No son equivalentes, no las emiten los mismos organismos y una de ellas no existe hoy en forma utilizable. Separarlas es lo más útil que puede hacer una función de cumplimiento este trimestre.

La primera capa es la certificación del sistema de gestión: un organismo acreditado audita tu sistema de gestión de IA frente a ISO/IEC 42001 y emite un certificado que cubre un alcance definido. La segunda es la evaluación regulatoria de la conformidad: para un sistema de IA de alto riesgo bajo el Reglamento de IA, el proveedor ejecuta un procedimiento de evaluación de la conformidad conforme al artículo 43, bien mediante control interno (anexo VI), bien mediante un organismo notificado que evalúa el sistema de gestión de la calidad y la documentación técnica (anexo VII). La tercera es la presunción de conformidad del artículo 40, que solo se concede cuando una norma armonizada ha sido citada en el Diario Oficial.

Esa tercera capa es la que hace tropezar. En agosto de 2026, ninguna norma armonizada del Reglamento de IA ha sido citada en el Diario Oficial. El pipeline del CEN-CENELEC JTC 21 ha empezado a entregar: EN 18286:2026 sobre sistemas de gestión de la calidad se aprobó el 12 de julio de 2026 y es la primera norma del Reglamento de IA realmente publicada. Pero publicación no es cita, y solo la cita desencadena el efecto jurídico. La consecuencia práctica es contundente: un certificado ISO/IEC 42001 no confiere hoy presunción legal de conformidad con el Reglamento de IA, y quien afirme lo contrario te está vendiendo algo.

Qué cambió realmente el ómnibus digital sobre IA

El Reglamento (UE) 2026/1744 modifica el Reglamento de IA en lugar de sustituirlo. El titular es el aplazamiento: las obligaciones completas para los sistemas de alto riesgo del anexo III pasan del 2 de agosto de 2026 al 2 de diciembre de 2027, y los sistemas integrados de alto riesgo del anexo I pasan del 2 de agosto de 2027 al 2 de agosto de 2028. El texto está disponible en EUR-Lex, y el Reglamento (UE) 2024/1689 subyacente sigue siendo el instrumento de base.

El razonamiento expuesto por la Comisión merece lectura atenta, porque es una admisión con consecuencias operativas. El aplazamiento se propuso en respuesta a dificultades de implementación: retrasos en la designación de autoridades nacionales competentes y de organismos de evaluación de la conformidad, y ausencia de normas armonizadas, orientaciones y herramientas de cumplimiento para la IA de alto riesgo. Dicho de otro modo, la maquinaria para evaluar la conformidad no estaba lista, así que la obligación de ser evaluado se movió.

Dos cosas no se movieron. Las obligaciones de transparencia se aplican desde el 2 de agosto de 2026 según lo previsto, con obligaciones de marcado de contenido generado por IA en sistemas ya introducidos en el mercado aplicables desde el 2 de diciembre de 2026, y las prácticas prohibidas, aplicables desde febrero de 2025, no se ven afectadas salvo por algunas adiciones. Un aplazamiento del régimen de alto riesgo no es una amnistía general.

Para una dirección de cumplimiento la lectura es directa: has ganado unos dieciséis meses en el frente más pesado y nada en transparencia, prácticas prohibidas o expectativas comerciales de tus clientes, porque los equipos de compras empresariales no aplazaron nada. Si acaso, la ausencia de un suelo regulatorio hace que un sistema de gestión auditado de forma independiente sea más diferenciador en lugar de menos.

ISO/IEC 42006:2025: por qué los certificados ya no son equivalentes

ISO/IEC 42006:2025 se publicó el 7 de julio de 2025 y establece los requisitos para los organismos que prestan auditoría y certificación de sistemas de gestión de IA, sobre la base de ISO/IEC 17021-1. Antes de su existencia, un organismo que auditaba un AIMS trabajaba a partir de una acreditación genérica de sistemas de gestión y de su propia lectura de qué significaba competencia en IA, algo que ya no es aceptable.

El efecto práctico es triple: los organismos de certificación deben demostrar ahora competencia específica en IA en sus equipos de auditoría en lugar de competencia genérica acompañada de una bibliografía sobre IA, la duración de la auditoría se calcula según criterios definidos en vez de negociarse a la baja, y los organismos de acreditación aplican un programa de transición, lo que significa que la población de organismos legítimamente capacitados para emitir un certificado ISO/IEC 42001 se está filtrando activamente.

Esto importa cuando compras aseguramiento y cuando lo recibes. Si estás seleccionando un organismo de certificación, pregunta directamente si está acreditado conforme a ISO/IEC 42006 y qué cubre el alcance de esa acreditación. Si evalúas a un proveedor que presenta un certificado ISO/IEC 42001, comprueba la marca de acreditación y el enunciado de alcance en el propio certificado. Un certificado emitido antes de la transición a ISO/IEC 42006, por un organismo sin acreditación específica en IA, no tiene el mismo peso que uno emitido después.

ISO 19011:2026: qué cambia en la conducción de la auditoría

ISO 19011:2026, cuarta edición de las directrices para la auditoría de sistemas de gestión, se publicó el 27 de mayo de 2026 y anula y sustituye a la edición de 2018. Es una norma de orientación: no tiene fecha de entrada en vigor separada ni periodo de transición, se aplica desde su publicación. Si tu programa de auditoría interna sigue redactado conforme a la edición de 2018, está desactualizado ahora, no el año que viene.

La revisión es técnica más que estructural. Leída junto a los comentarios publicados desde mayo por organismos de certificación y auditoría, destacan tres cambios para un AIMS. El primero es un desplazamiento del énfasis, que ya no recae en confirmar que un proceso existe formalmente sino en evaluar si logra los resultados previstos, lo que supone un endurecimiento significativo para la gobernanza de la IA. Un procedimiento de evaluación de impacto de IA que existe, está aprobado y nunca se ha aplicado a un modelo en producción se leerá de forma distinta bajo la orientación de 2026 que bajo la de 2018.

El segundo es la ampliación de la orientación sobre métodos de auditoría remota y ubicaciones virtuales, apoyada en ISO/IEC TS 17012. Esto encaja bien con los sistemas de IA, donde la evidencia significativa reside en repositorios, registros de modelos, sistemas de tickets y paneles de monitorización, y no en un archivador de una sede física. Espera que los equipos de auditoría pidan acceso de lectura, sesiones compartidas de sistemas en producción y trazabilidad entre una versión de modelo y la aprobación que la autorizó.

El tercero es la mejora de la orientación sobre documentación de hallazgos, comunicación de resultados y registro de no conformidades para que sustenten la acción correctiva. En la práctica, los hallazgos vagos sobrevivirán menos. «Documentación insuficiente del rendimiento del modelo» se convierte en un hallazgo que nombra el modelo, el control, la evidencia esperada y la brecha.

Para las organizaciones que operan un programa de auditoría interna frente a ISO/IEC 42001, la secuencia es simple. Actualiza el programa de auditoría conforme a la orientación de 2026, revisa la competencia del equipo frente a esa orientación y frente al conocimiento específico de IA, y ejecuta la auditoría interna antes de que llegue el organismo de certificación en lugar de como formalidad tras declarar completada la preparación.

El expediente de evidencia: qué pide realmente una auditoría ISO/IEC 42001

ISO/IEC 42001:2023 combina cláusulas obligatorias con el anexo A, que contiene 38 controles distribuidos en nueve objetivos de control (A.2 a A.10). Los controles se aplican de forma selectiva y se justifican en una declaración de aplicabilidad. Lo que sigue se organiza por la evidencia que un equipo de auditoría pedirá efectivamente, área por área, partiendo de lo que suele faltar y no de lo que suele redactarse.

Inventario de sistemas de IA y alcance

El inventario es el primer documento solicitado y el más frecuentemente insuficiente. Un equipo de auditoría busca un registro mantenido que identifique cada sistema de IA dentro del alcance, su finalidad, su etapa de ciclo de vida, su responsable, su clasificación de riesgo, si se desarrolla internamente o se adquiere, y dónde residen el modelo y los datos. El modo de fallo típico es una hoja de cálculo que fue exacta el día en que se redactó el alcance.

Evidencia que satisface: un registro con historial de cambios, un proceso documentado para añadir sistemas y un vínculo demostrable con compras y gestión del cambio, de modo que una nueva capacidad de IA no pueda entrar en el parque sin registrarse. Evidencia que no satisface: una lista estática sin columna de responsable ni fecha de última revisión.

Evaluación de impacto de IA

La evaluación de impacto es donde el carácter específicamente de IA de la norma muerde con más fuerza, y donde los equipos con un programa ISO/IEC 27001 maduro suponen con más frecuencia, y erróneamente, estar cubiertos. Una apreciación de riesgos de seguridad de la información aborda confidencialidad, integridad y disponibilidad. Una evaluación de impacto de IA debe abordar además los efectos sobre personas y grupos, incluido el uso indebido previsible, y debe revisarse cuando el sistema cambia sustancialmente.

Evidencia que satisface: evaluaciones completas por cada sistema del alcance, con participantes nombrados, un método aplicado de forma coherente, impactos identificados sobre las personas afectadas y un disparador documentado de reevaluación ligado al reentrenamiento del modelo o al cambio de finalidad. Evidencia que no satisface: una única evaluación a nivel de organización que cubra «nuestro uso de la IA».

Gobernanza y procedencia de los datos

Los equipos de auditoría siguen el rastro de los datos hacia atrás. Para los datos de entrenamiento, validación y prueba preguntarán de dónde proceden, qué derechos posees para usarlos, cómo se valoró su pertinencia y representatividad, y cómo se trataron los problemas de calidad. Para los sistemas que usan modelos fundacionales de terceros, las mismas preguntas se aplican a los datos de ajuste fino y a lo que el proveedor acepte revelar sobre el modelo base.

Evidencia que satisface: decisiones documentadas de obtención de datos, registros de licencias y derechos, una evaluación de calidad de datos referida al uso previsto y un registro de qué se excluyó y por qué. Evidencia que no satisface: un catálogo de datos sin campo de procedencia.

Documentación de transparencia y explicabilidad

Los datos de búsqueda muestran un claro núcleo de interés empresarial sobre qué evidencia de explicabilidad exige realmente una auditoría, y la respuesta honesta es que depende del público al que sirva la transparencia. La norma espera que hayas determinado quién necesita entender qué sobre el sistema y que hayas producido información apropiada para cada grupo: usuarios, personas afectadas, funciones internas de supervisión y, cuando proceda, reguladores.

Evidencia que satisface: una determinación documentada de las necesidades de información por público, los artefactos en sí (fichas de modelo, información dirigida a usuarios, documentación técnica interna) y un historial de versiones que vincule cada artefacto a una versión de modelo. Evidencia que no satisface: una ficha técnica de modelo redactada por el equipo de ciencia de datos sin rastro de que se considerara a nadie más.

Equidad y pruebas de sesgo

Esta es el área de control con la mayor brecha entre lo que las organizaciones dicen y lo que pueden mostrar. El requisito no es que tu sistema salga perfectamente equitativo, algo que ni es alcanzable ni es lo que pide la norma, sino que hayas definido qué significa equidad para este sistema en este contexto, hayas probado frente a esa definición, hayas registrado el resultado y hayas tomado una decisión documentada sobre lo que quedaba.

Evidencia que satisface: un objetivo de equidad declarado por sistema, la métrica elegida y su justificación, resultados de pruebas sobre las cohortes pertinentes, el umbral de aceptabilidad y la aprobación de la disparidad residual, incluido quién la aceptó. Evidencia que no satisface: una declaración en la política de IA afirmando que la organización está comprometida con la equidad.

Supervisión humana

La supervisión humana es fácil de afirmar y difícil de evidenciar. La pregunta de auditoría no es si hay un humano nominalmente en el bucle, sino si esa persona dispone de la información, la autoridad y la capacidad práctica de intervenir, y si las intervenciones ocurren realmente.

Evidencia que satisface: roles de supervisión definidos con competencia documentada, la interfaz o el proceso mediante el cual se ejerce la supervisión y registros que muestren intervenciones genuinas, incluidas anulaciones y escalados. Evidencia que no satisface: un diagrama de proceso con una caja etiquetada «revisión humana» y ningún registro de que un humano haya revisado nunca nada.

Gestión de incidentes y monitorización posterior al despliegue

Los incidentes de IA no se parecen a los incidentes de seguridad. La deriva del modelo, el rendimiento degradado en un subgrupo, un patrón de salida inesperado y una alucinación que llega a un cliente son todos incidentes en términos de gobernanza de IA, y la mayoría de las organizaciones no tiene vía para ninguno de ellos porque su proceso de incidentes se construyó para caídas y brechas.

Evidencia que satisface: una definición de incidente de IA que cubra rendimiento y comportamiento además de disponibilidad, monitorización con umbrales definidos por sistema, registros de triaje y al menos un caso trabajado que recorra el proceso hasta una resolución documentada. Evidencia que no satisface: el procedimiento general de incidentes de TI con la palabra «IA» añadida al párrafo de alcance.

IA de terceros y de proveedores

El anexo A.10 rige las relaciones con terceros, y ahí es donde el parque suele ser mayor y la gobernanza más delgada. Cada funcionalidad de IA integrada en un producto SaaS adquirido es IA de terceros. También lo es cada llamada a una API de modelo fundacional, cada capacidad de IA activada por un proveedor en una actualización de producto y cada modelo en una cadena de subencargados.

Evidencia que satisface: la IA de proveedores identificada en el inventario, cláusulas contractuales que cubran obligaciones específicas de IA, diligencia debida proporcionada al riesgo y un proceso para detectar capacidades de IA introducidas por proveedores después de la firma. Evidencia que no satisface: un registro de proveedores con una columna Sí o No titulada «usa IA».

La procedencia se está convirtiendo en la evidencia

El giro más interesante en el aseguramiento de la IA está ocurriendo hoy en la procedencia y no en las cláusulas del sistema de gestión. Reguladores, organismos de normalización y los propios laboratorios de frontera han llegado a la misma idea desde tres direcciones distintas: si una máquina produjo este artefacto, ese hecho debería viajar con el artefacto. Para un programa de auditoría, eso convierte un debate filosófico sobre atribución en un control con una salida verificable.

El motor regulatorio es el artículo 50 del Reglamento de IA, que el ómnibus no aplazó. Las obligaciones de transparencia se aplican desde el 2 de agosto de 2026. El artículo 50 divide el requisito en dos capas que suelen colapsarse en una: una divulgación visible para la persona y un marcado legible por máquina incrustado en el propio contenido, de modo que un sistema, y no una persona, pueda detectar que la salida fue generada artificialmente. Los sistemas generativos ya introducidos en el mercado antes del 2 de agosto de 2026 disponen hasta el 2 de diciembre de 2026 para cumplir el requisito de marcado legible por máquina. Las sanciones de este nivel alcanzan 15 millones de euros o el 3 por ciento del volumen de negocios anual mundial, la cifra que sea mayor, con un matiz útil: para pymes y empresas emergentes el tope es la menor de las dos cifras, no la mayor.

La respuesta de facto a la mitad legible por máquina son las Content Credentials de C2PA, respaldadas por una membresía de miles de organizaciones, entre ellas Adobe, Microsoft, Google, Intel, la BBC y AP. Sé preciso sobre su estatus, porque la especificación solo está en vía acelerada hacia una norma ISO, ISO 22144 sobre content credentials, todavía en fase de proyecto en agosto de 2026. Trata C2PA como la convención del mercado y no como una norma internacional consolidada, y desconfía de los proveedores que la describen como ya publicada. Una Content Credential vincula la marca temporal de creación, el modelo y su versión, y las ediciones humanas posteriores, en una firma criptográfica que viaja dentro del archivo, lo que la hace auditable: un equipo de auditoría puede abrir una salida y comprobar si la credencial está presente, íntegra y es coherente con lo que tu inventario declara que la produjo.

Fíjate en lo que eso le hace al área de control de transparencia. La evidencia de transparencia era hasta ahora documental, es decir fichas de modelo, divulgaciones y políticas, mientras que el marcado de procedencia convierte parte de ella en forense, de modo que puedes tomar una muestra de salidas y verificarla de verdad, que es justo el tipo de evidencia hacia el que ISO 19011:2026 empuja a los equipos de auditoría porque demuestra eficacia y no mera existencia.

El caso que nadie incluyó en el alcance: el código escrito por IA

La procedencia de contenidos recibe atención porque la norma la nombra, pero la exposición mayor y sin alcance en la mayoría de las organizaciones sigue siendo el código. Los asistentes de programación ya escriben software de producción dentro de empresas cuyo inventario de IA enumera tres modelos de cara al cliente y nada más. Pregunta a una función de gobernanza si el código generado por IA está dentro del alcance del AIMS y sueles obtener una pausa, luego un no, y después una pausa mucho más larga.

Las herramientas ya resolvieron la parte difícil en silencio. Claude Code, de Anthropic, escribe una línea Co-Authored-By con el identificador del modelo en cada commit en el que participa, de modo que una sola consulta git log devuelve todos los commits asistidos por IA del historial. Están surgiendo convenciones más amplias que añaden gradación, con Assisted-by para una sugerencia ligera, Co-authored-by para una contribución sustancial y Generated-by para código predominantemente escrito por la máquina, cada una acompañada de un Signed-off-by que mantiene responsable a una persona con nombre. Nada de esto exige comprar una plataforma, puesto que son metadatos que tu sistema de control de versiones ya transporta.

Para una organización de ingeniería regulada este es el control de gobernanza de IA más barato que existe, y el que más a menudo se desactiva. Los equipos apagan la atribución por razones cosméticas, porque ensucia el log o porque a alguien no le gusta cómo se ve, y esa decisión borra en silencio el rastro de auditoría. Cuando una revisión de incidente, un cuestionario de seguridad de un cliente o un regulador pregunte algún día qué partes de un sistema fueron escritas por una máquina y quién las aceptó, conviene que la respuesta sea una consulta y no un proyecto de arqueología. Conviene saber también que la línea puede desactivarse, así que una búsqueda con git log es una señal positiva y no una prueba de ausencia.

Etapa 1, etapa 2 y seguimiento: el ciclo en la práctica

La certificación sigue el modelo clásico en dos etapas heredado de ISO/IEC 17021-1, afinado para IA por ISO/IEC 42006. La etapa 1 es una revisión de preparación y documentación, que suele incluir el enunciado de alcance, la declaración de aplicabilidad, el método de apreciación de riesgos e impactos, el informe de auditoría interna y la revisión por la dirección. Sirve para determinar si la etapa 2 es viable, y una etapa 1 que termina en aplazamiento es un resultado normal y a menudo correcto.

La etapa 2 prueba la implementación y la eficacia. Bajo ISO 19011:2026 el énfasis en la eficacia es más marcado: el equipo muestrea casos reales y pregunta si el sistema logró aquello para lo que fue diseñado. Los hallazgos se gradúan, con no conformidades mayores que bloquean la certificación hasta su corrección y menores que exigen un plan de acción correctiva.

Tras la certificación, el ciclo encadena auditorías de seguimiento, normalmente anuales, con una recertificación completa el tercer año. El seguimiento no es una versión ligera de la misma auditoría sino una revisión de lo que ha cambiado desde la visita anterior, y en un parque de IA el cambio es constante: nuevos modelos, modelos reentrenados, nuevos proveedores, nuevos casos de uso. Las organizaciones que lo tratan como una formalidad acumulan hallazgos precisamente porque su control de cambios nunca mantuvo el AIMS al día.

Qué cuesta esto en esfuerzo, con honestidad

El esfuerzo lo domina la reconstrucción de evidencia, no la documentación. Las organizaciones que ya operan un sistema de gestión ISO/IEC 27001 certificado suelen encontrar familiar la estructura de cláusulas y ajeno el contenido del anexo A: el esqueleto de gobernanza se transfiere, los controles específicos de IA no. El grueso del trabajo está en la completitud del inventario, las evaluaciones de impacto por sistema y la construcción de la cadena de trazabilidad desde la versión de modelo hasta la aprobación.

Dos partidas de coste se subestiman sistemáticamente. Las auditorías de seguimiento se repiten cada año y escalan con el tamaño y la volatilidad del parque de IA, que en la mayoría de las organizaciones está creciendo. Y la competencia de auditoría interna tiene ahora una dimensión de IA que una experiencia genérica en sistemas de gestión no aporta automáticamente, lo que obliga a formar al equipo existente o a adquirir la capacidad.

Dónde no ayuda ISO/IEC 42001

La certificación es un aseguramiento sobre el sistema de gestión, y hay tres cosas que la gente espera de ella y que no hará. No evalúa si un sistema de IA concreto es seguro o exacto, porque esa es una pregunta de nivel de producto que pertenece a la documentación técnica y no al certificado. Una organización certificada puede desplegar un mal modelo, y la auditoría solo lo detectará si el proceso de gobernanza que debía detectarlo también falló.

No sustituye a la evaluación de la conformidad del Reglamento de IA. Si eres proveedor de un sistema de IA de alto riesgo, el artículo 43 se te aplica en el calendario aplazado y un certificado de sistema de gestión no es una evaluación de la conformidad. Es un trabajo preparatorio realmente útil, en particular para los requisitos de sistema de gestión de la calidad del artículo 17, pero son dos objetos jurídicos distintos.

Y no confiere hoy presunción de conformidad. Eso seguirá siendo cierto hasta que una norma armonizada sea citada en el Diario Oficial. Vigila el pipeline del JTC 21, pero léelo con precisión: EN 18286:2026 sobre sistemas de gestión de la calidad ya está publicada, lo que supone un avance real, y sigue sin estar citada. Ten en cuenta además que los requisitos de sistema de gestión de la calidad del artículo 17 quedan fuera de las disposiciones del capítulo III sección 2 a las que se vincula la presunción del artículo 40: ni siquiera una cita en ese punto produciría una presunción limpia para todo el régimen de alto riesgo. No construyas un argumento de cumplimiento sobre una cita que no ha ocurrido.

Tres patrones de certificación, y qué enseña cada uno

La orientación sobre evidencia solo resulta útil cuando ves la forma que toma en una organización real. Tres situaciones se repiten lo bastante como para merecer un nombre. La primera es pública y verificable. Las otras dos se deducen de lo que ocurre cuando la norma se encuentra con un parque corporativo corriente, así que trátalas como aritmética y no como anécdotas.

Patrón uno: el laboratorio de frontera, donde la gobernanza vino primero

Anthropic obtuvo la certificación acreditada ISO/IEC 42001 para su sistema de gestión de IA, entre los primeros laboratorios de IA de frontera en lograrlo, con el certificado emitido por Schellman Compliance, LLC, organismo acreditado por el ANSI National Accreditation Board, y con efecto desde enero de 2025. Lee después la línea de alcance en lugar del titular, porque cubre la investigación y el desarrollo en IA y los servicios de IA en vez de la organización entera, que es exactamente la distinción en la que este artículo insiste, visible aquí en uno de los certificados más escrutados del sector.

El detalle instructivo es la secuencia, porque la certificación se construyó sobre una gobernanza que ya existía y ya era pública: un marco de escalado responsable publicado, trabajo deliberado sobre el comportamiento y la alineación de los modelos, e investigación continua en seguridad. En lugar de crear la gobernanza, la auditoría hizo legible ante un tercero una gobernanza existente, que es el orden correcto y el que la mayoría de los programas empresariales invierte. Encargan un cuerpo de políticas para certificarse y luego descubren en la etapa 2 que unas políticas sin registros de operación no prueban nada.

Hay una segunda lección escondida en el organismo de certificación. Los datos de búsqueda muestran que la gente consulta activamente si una firma concreta es proveedor de auditoría ISO 42001. Los compradores ya están haciendo exactamente la diligencia que ISO/IEC 42006 fue escrita para habilitar: no solo comprobar que existe un certificado, sino comprobar quién lo emitió y bajo qué acreditación. Si tu cuestionario de compras pide a los proveedores un certificado ISO 42001 pero no pide la marca de acreditación y el enunciado de alcance, estás coleccionando un logotipo.

Patrón dos: el shock del inventario

Toma una organización convencida de operar un puñado de sistemas de IA: un asistente de cara al cliente, un modelo de previsión, un clasificador de documentos. Haz ahora la aritmética que impone el ejercicio de alcance. Cuenta las funciones de IA ya activadas dentro de la plataforma de soporte, la puntuación dentro de la herramienta de selección, el asistente incrustado en el CRM, los asistentes de programación por toda la ingeniería, la traducción y la redacción dentro de la suite de productividad. Casi ninguna la construyó nadie de los presentes, y todas son un sistema de IA según la definición de la norma.

Esa brecha no es un fallo de documentación, es un fallo de alcance con causa raíz de gobernanza, porque nada en compras ni en la gestión del cambio exigió nunca declarar una capacidad de IA. La corrección es poco vistosa: añade una puerta de declaración de IA al alta de proveedores y a la aceptación de cambios de producto, y luego barre una vez los contratos existentes y las consolas de administración. Hacerlo antes de redactar políticas es lo que ahorra el retrabajo, porque el inventario fija el alcance, el alcance fija la declaración de aplicabilidad, y la declaración de aplicabilidad fija todo lo que tendrás que evidenciar.

Patrón tres: la organización ya certificada en ISO 27001

Una organización con un sistema de gestión de seguridad de la información maduro y certificado aborda ISO/IEC 42001 como un ejercicio de delta. En un sentido tiene razón: la estructura de cláusulas, el ritmo de revisión por la dirección, la maquinaria de auditoría interna y el proceso de acción correctiva se transfieren intactos. Eso es genuinamente una ventaja de salida y suele acortar el calendario del programa de forma apreciable.

Donde se tuerce es en suponer que el trabajo de riesgos también se transfiere, cuando no lo hace. Una apreciación de riesgos de seguridad razona sobre amenaza, vulnerabilidad e impacto en la organización, mientras que una evaluación de impacto de IA razona sobre efectos en personas y grupos, incluido el uso indebido previsible, que es un objeto analítico distinto y exige participantes distintos. Los equipos que entregan la evaluación de impacto de IA solo a la función de seguridad producen documentos competentes, bien estructurados y que omiten sistemáticamente la dimensión de personas afectadas que la norma pregunta en realidad. Incorporar a legal, a la función de protección de datos y a un responsable de negocio a la misma evaluación es la única corrección que lo resuelve.

Qué hacer ahora, por rol

La gobernanza de la IA falla en las costuras entre funciones con más frecuencia que dentro de cualquiera de ellas. El aplazamiento del régimen de alto riesgo ha eliminado el plazo artificial que obligaba a esas funciones a sentarse juntas, lo que hace que la asignación explícita de roles sea más importante, no menos. La tabla siguiente es el reparto que funciona en la práctica.

Un punto de coordinación une a los seis. Alguien tiene que ser dueño del registro de decisiones, y no debería ser quien dirija el proyecto de certificación. Registrar decisiones es un hábito operativo permanente y, si lo posee un programa temporal, muere la semana en que llega el certificado, que es exactamente cuando la primera auditoría de seguimiento empieza a acumular hallazgos.

Lista de comprobación de preparación

Úsala como autoevaluación antes de la etapa 1. Si no puedes responder sí con la evidencia adjunta, esa es tu lista de brechas.

Qué hacer en los próximos 90 días

Primero, recalibra el plan sobre el calendario modificado. Si tu programa se dimensionó para un plazo del Reglamento de IA en agosto de 2026, redimensiónalo, porque las obligaciones de alto riesgo del anexo III muerden ahora el 2 de diciembre de 2027 y las del anexo I el 2 de agosto de 2028, mientras que las obligaciones de transparencia ya se aplican. Lo que tienes es una reasignación del esfuerzo más que una pausa.

Segundo, cierra la brecha de evidencia antes que la de políticas. Toma tres sistemas de IA al azar del inventario e intenta la prueba de trazabilidad: evaluación de impacto, decisiones sobre datos, resultados de pruebas, aprobación, monitorización, en menos de una hora cada uno. Lo que se rompa constituye tu programa de preparación.

Tercero, arregla la función de auditoría antes de arreglar la documentación. Actualiza el programa de auditoría interna a ISO 19011:2026, verifica que quien lo ejecuta posee competencia específica en IA y no solo competencia en sistemas de gestión, y ejecuta una auditoría interna real. Los hallazgos serán más útiles que cualquier análisis de brechas que produzca una consultora, porque provienen de tu propia evidencia.

Siguiente paso

Si tu función consiste en dirigir o encargar auditorías de AIMS, la formación certificada ISO 42001 Lead Auditor cubre el proceso de auditoría de principio a fin frente a ISO 19011:2026 y al contexto de ISO/IEC 42006. Si construyes el sistema de gestión en lugar de auditarlo, el programa ISO 42001 Lead Implementer es el punto de entrada adecuado, y los equipos centrados en la capa de riesgo subyacente suelen empezar por Lead AI Risk Manager. Los tres figuran en nuestro hub de formación en gobernanza de la IA, junto al playbook de implementación y la guía de cumplimiento del Reglamento de IA.