ISO 42001 vs ISO 27001: en qué se diferencian

ISO/IEC 27001 gobierna la seguridad de la información; ISO/IEC 42001 gobierna el comportamiento de los sistemas de IA. Comparten la estructura de sistema de gestión, así que un SGSI en marcha reduce el trabajo, pero no cubre riesgos de IA como el sesgo, la explicabilidad o la decisión autónoma.

A partir de aquí, la comparación en detalle: qué protege cada una, qué se solapa, qué se reutiliza y qué hay que construir desde cero.

---

¿Qué protege cada norma?

	ISO/IEC 27001	ISO/IEC 42001
Nombre	Sistema de gestión de seguridad de la información	Sistema de gestión de IA
Edición vigente	ISO/IEC 27001:2022	ISO/IEC 42001:2023
Objeto protegido	La información: confidencialidad, integridad y disponibilidad	El comportamiento de los sistemas de IA y su efecto sobre las personas
Pregunta que responde	¿Puede alguien acceder, alterar o destruir lo que no debe?	¿Hace el sistema lo que dijimos que haría, y podemos demostrarlo?
Sujeto del riesgo	La organización y sus activos	La organización, sus clientes y terceros afectados por una decisión
Anexo de controles	93 controles en cuatro temas: organizacional, personas, físico y tecnológico	Nueve objetivos de control, de A.2 a A.10
Certificación	Mercado maduro, con organismos acreditados y decenas de miles de certificados	Mercado en formación

La distinción práctica cabe en un ejemplo. Un sistema de puntuación crediticia puede estar cifrado en tránsito y en reposo, con acceso segmentado, registro completo y copias de seguridad probadas —impecable bajo ISO 27001— y aun así denegar sistemáticamente a un colectivo por una correlación espuria de sus datos de entrenamiento. Ninguno de los 93 controles del Anexo A de la norma de seguridad detecta eso, porque no es un problema de seguridad de la información. Es un problema de comportamiento del sistema, y ahí es donde entra ISO 42001.

Al revés también funciona. Un sistema de IA con evaluación de impacto ejemplar, supervisión humana efectiva y documentación de uso previsto no está por ello protegido frente a un acceso indebido a sus registros, una fuga de credenciales o la pérdida de sus datos. Eso lo cubre la norma de seguridad.

---

¿En qué se parecen?

Más de lo que parece, y ahí está la buena noticia si ya hay un SGSI.

Ambas siguen la estructura armonizada de las normas ISO de sistemas de gestión: las cláusulas 4 a 10 son las mismas en título y en lógica.

Cláusula	Contenido común
4. Contexto	Partes interesadas, cuestiones internas y externas, alcance
5. Liderazgo	Compromiso de la dirección, política, roles y responsabilidades
6. Planificación	Riesgos y oportunidades, objetivos, planificación de cambios
7. Soporte	Recursos, competencia, concienciación, comunicación, información documentada
8. Operación	Control operacional
9. Evaluación del desempeño	Seguimiento, medición, auditoría interna, revisión por la dirección
10. Mejora	No conformidades, acción correctiva, mejora continua

Ambas funcionan además sobre el mismo mecanismo: evaluación de riesgos → selección de controles → declaración de aplicabilidad → evidencia → auditoría → mejora. Quien haya pasado por una auditoría de seguridad reconoce el terreno de inmediato.

¿Qué riesgos cubre 42001 que 27001 no cubre?

Esta es la lista que justifica el proyecto por sí sola:

• Sesgo y trato desigual. Un resultado sistemáticamente peor para un grupo. No es un fallo de seguridad; es un fallo de diseño con consecuencias legales.
• Explicabilidad. Poder decir por qué el sistema resolvió lo que resolvió. La norma de seguridad no lo pide en ningún control.
• Uso fuera de la finalidad prevista. Un sistema construido para clasificar documentos que acaba usándose para evaluar personas.
• Supervisión humana efectiva. No que exista un revisor, sino que su revisión pueda cambiar el resultado y quede constancia de ella.
• Impacto sobre terceros que no son clientes. Alguien afectado por una decisión sin tener relación contractual con la organización.
• Deriva del comportamiento. El sistema cambia porque cambió el modelo del proveedor o el contexto de entrada, sin que nadie despliegue nada. Cómo se detecta con datos está en observabilidad de agentes IA.
• Procedencia y calidad de los datos desde la perspectiva del resultado, no de su protección.
• Reparto de responsabilidad con el proveedor del modelo, que rara vez encaja en un contrato estándar de proveedor de servicios.

¿Qué riesgos cubre 27001 que 42001 no cubre?

La simetría importa, porque hay quien concluye que 42001 sustituye a la norma de seguridad. No lo hace.

• Gestión de accesos e identidades en profundidad.
• Seguridad física y del entorno.
• Continuidad de negocio y recuperación ante desastre.
• Seguridad en el desarrollo, gestión de vulnerabilidades y de parches.
• Criptografía y gestión de claves.
• Seguridad del personal, desde la contratación hasta la salida.
• Gestión de incidentes de seguridad de la información.
• Seguridad de las comunicaciones y de la red.

Todo eso sigue siendo necesario para operar un sistema de IA. La norma de IA lo presupone; no lo desarrolla.

---

¿Qué se reutiliza si ya hay un SGSI?

Aquí está el ahorro real. Reutilizable casi tal cual:

Elemento del SGSI	Reutilización en el sistema de gestión de IA
Análisis de contexto y partes interesadas	Alta: se amplía con los afectados por decisiones automatizadas
Estructura de política y aprobación por la dirección	Alta: mismo circuito documental, contenido distinto
Metodología de evaluación de riesgos	Alta: misma metodología, catálogo de riesgos nuevo
Gestión de información documentada y control de versiones	Total
Programa de auditoría interna y revisión por la dirección	Total: se amplía el alcance
Circuito de no conformidades y acciones correctivas	Total
Gestión de proveedores	Media: se añaden proveedores de modelos y cláusulas específicas
Control de accesos y registro de eventos	Media: la infraestructura existe; hay que registrar además la autoría de cada acción, humana o automática
Gestión de cambios	Media: se añade el cambio de versión de modelo como cambio sujeto a control
Concienciación y formación	Media: contenidos nuevos sobre límites de la IA y supervisión

Y lo que no se reutiliza, porque simplemente no existe en un SGSI:

• La evaluación de impacto del sistema de IA sobre individuos, grupos y sociedad. Es específica y no equivale a una evaluación de impacto de protección de datos, aunque se solapen en parte.
• El inventario de sistemas de IA, modelos y su procedencia.
• La declaración de uso previsto y de usos excluidos por sistema.
• Los puntos de aprobación humana y su evidencia.
• Los indicadores de gobierno, como la proporción de salidas rechazadas en la revisión humana.

Regla práctica: la estructura se hereda; el contenido se construye. Quien intenta el atajo de renombrar documentos del sistema de seguridad llega a la auditoría con un sistema de gestión que no describe lo que la organización hace de verdad, y eso se detecta en la primera entrevista.

¿Cuál implantar primero?

No hay requisito formal de orden. La decisión práctica depende de dos preguntas:

¿Qué te está pidiendo el mercado? Si los clientes o las licitaciones piden evidencia de seguridad, la norma de seguridad va primero: es el marco reconocido y con mercado de certificación maduro. Si lo que se pide es gobernanza de IA —cada vez más frecuente en contratación pública y en due diligence de inversión— entonces 42001.

¿Dónde está tu riesgo real? Si el sistema de IA toma o prepara decisiones que afectan a personas, el riesgo de gobierno es mayor que el de confidencialidad, y el orden se invierte.

Un camino intermedio funciona bien: implantar los controles de seguridad y documentar su estado con honestidad, y simultáneamente construir el sistema de gestión de IA sobre esa base. Es exactamente lo que hemos hecho nosotros.

¿Se pueden auditar juntas?

Sí, y suele salir mejor. La estructura armonizada permite una auditoría integrada: cláusulas 4 a 10 comunes, documentación de gestión compartida, y anexos de controles y evaluaciones específicas por norma. Reduce esfuerzo, evita duplicar reuniones y —lo más importante— impide que los dos sistemas se contradigan entre sí, que es lo que ocurre cuando los mantienen equipos distintos sin hablarse.

Nuestro estado real en ambos marcos

Lo decimos con la misma precisión con la que lo pedimos a un proveedor:

Marco	Estado publicado
ISO/IEC 42001 (sistema de gestión de IA)	Sistema implantado sobre los agentes en producción de nuestra plataforma probatoria, con el mapeo de cláusulas y controles publicado
ISO/IEC 27001	Controles del Anexo A implementados — sin certificación de tercero
SOC 2 Tipo II	Criterios aplicados — sin informe de auditor

La segunda fila está en negrita a propósito. Implementar controles y estar certificado son cosas distintas, y confundirlas deliberadamente es la clase de atajo que destruye la credibilidad de una firma que vende cumplimiento. El estado control por control está publicado en el registro del Anexo A, el mapeo de IA en nuestro documento de ISO 42001, y la lectura exacta de cada etiqueta en el centro de confianza.

Si lo que buscas es el desglose de qué exige la norma de IA cláusula por cláusula, sin comparación, está en ISO 42001: qué exige de verdad a quien usa IA.

---

Qué hacer ahora

1. Localiza tu inventario de sistemas de IA. Si ya tienes un SGSI, probablemente tengas inventario de activos y no de modelos. Son listas distintas.
2. Coge tu evaluación de riesgos actual y comprueba cuántos de los ocho riesgos de la sección de arriba aparecen en ella. La respuesta habitual es ninguno.
3. Decide el alcance del sistema de gestión de IA por sistema, no por departamento, y escríbelo en una página.
4. Reutiliza la estructura documental que ya tienes. Circuito de aprobación, control de versiones, auditoría interna y no conformidades funcionan igual.
5. Publica el estado de cada marco con honestidad. Un badge que insinúe una certificación inexistente es un riesgo legal, además de un problema reputacional cuando alguien pida el informe.

Si necesitas una evaluación de distancia frente a uno de los dos marcos, o una hoja de ruta integrada para ambos, escríbenos desde contacto. Nuestra práctica de compliance trabaja junto a la de protección, porque un sistema de gestión que no se apoya en controles técnicos reales no sobrevive a la primera auditoría seria.