Los cuestionarios de seguridad de los clientes solían terminar en la ISO 27001. Ahora es habitual que incluyan un apartado sobre inteligencia artificial: qué sistemas de IA usa el producto, de dónde vienen los modelos, cómo se revisan los resultados y quién responde cuando algo falla. La ISO/IEC 42001, publicada en diciembre de 2023, es la norma internacional que responde a esas preguntas en forma de sistema de gestión certificable por una entidad acreditada.
Si tu empresa ya tiene la ISO 27001, parte con ventaja. Las dos normas comparten la misma arquitectura de sistema de gestión, así que buena parte de lo que construiste para tu SGSI se reutiliza. Lo que queda por hacer es propio de la IA, y es más fácil de planificar cuando sabes exactamente dónde está.
Qué es la ISO 42001 y cómo se relaciona con la ISO 27001
La ISO/IEC 42001:2023 establece los requisitos de un sistema de gestión de la inteligencia artificial (SGIA): las políticas, roles, procesos y controles con los que una organización desarrolla, ofrece o utiliza sistemas de IA de forma responsable. Como la ISO 27001, es voluntaria. Ninguna ley la exige, pero clientes, inversores y departamentos de compras piden cada vez más pruebas de gobierno de la IA, y un certificado emitido por una entidad acreditada es una forma reconocida de aportarlas.
Las cláusulas que comparten
Ambas normas siguen la estructura armonizada de ISO para sistemas de gestión. Las cláusulas 4 a 10 tratan lo mismo en las dos: contexto de la organización, liderazgo, planificación, apoyo, operación, evaluación del desempeño y mejora. Si tu SGSI funciona, ya tienes una metodología de riesgos, auditorías internas, revisiones por la dirección y un proceso de acciones correctivas. Esos mecanismos se amplían al SGIA en lugar de construirse de nuevo. Explicamos por qué esas cláusulas, y no una carpeta de políticas, son el verdadero sistema de gestión en SGSI frente a políticas de seguridad.
La diferencia dentro de las cláusulas está en el objeto. Donde la ISO 27001 trata los riesgos de seguridad de la información, la ISO 42001 trata los riesgos que generan los sistemas de IA y su impacto en las personas. La cláusula 6.1.4 añade un requisito que la ISO 27001 no tiene: la evaluación de impacto del sistema de IA, que después se lleva a cabo según la cláusula 8.4.
El Anexo A: 38 controles en nueve objetivos
La ISO 27001:2022 recoge 93 controles en su Anexo A. La ISO 42001 tiene su propio Anexo A, con 38 controles agrupados en nueve objetivos numerados del A.2 al A.10. Abarcan la política de IA, la organización interna, los recursos, la evaluación de impacto, el ciclo de vida del sistema de IA, los datos, la información a las partes interesadas, el uso responsable y las relaciones con terceros y clientes. El Anexo B ofrece orientación para aplicar cada uno.
Igual que en la ISO 27001, los controles no se aplican en bloque. Se seleccionan a partir del análisis de riesgos y de la evaluación de impacto de la IA, y cada inclusión y exclusión se justifica en la Declaración de Aplicabilidad. Esa justificación pesa más que en la ISO 27001, como verás en las secciones siguientes.
Primer paso: clasifica tu rol según la ISO 42001 y la Ley Europea de IA
Antes de redactar ningún documento, necesitas saber qué papel tiene tu organización respecto a cada sistema de IA. Tanto la ISO 42001 como la Ley Europea de IA (EU AI Act) dependen de ello, y usan vocabularios distintos para ideas parecidas.
Los roles en la ISO 42001
La ISO 42001 toma sus roles de la ISO/IEC 22989, la norma de conceptos y terminología de IA. Los que necesita la mayoría de empresas son tres: el proveedor de IA, que pone un producto o servicio de IA a disposición de otros; el productor de IA, que diseña, desarrolla o adapta sistemas de IA; y el cliente de IA, que utiliza un sistema de IA, incluido uno construido por otro. Hay más roles, como el socio de IA o el sujeto de IA, pero estos tres cubren la mayoría de situaciones.
Los roles en la Ley Europea de IA
El Reglamento (UE) 2024/1689, la Ley Europea de IA, concentra las obligaciones en dos operadores. El proveedor desarrolla un sistema de IA, o encarga su desarrollo, y lo introduce en el mercado con su propio nombre. El responsable del despliegue utiliza un sistema de IA bajo su propia autoridad en un contexto profesional. Importadores y distribuidores también tienen obligaciones, pero la mayoría de empresas que leen esto serán una de las dos primeras figuras, o ambas.
Por qué casi todas las empresas tienen más de un rol
Los roles no son excluyentes. Piensa en una empresa de software que añade un asistente a su producto con un modelo de un tercero consumido por API. Escribe los prompts, la capa de recuperación y la integración, así que desarrolla y adapta el sistema: es productora según la ISO 42001. Ofrece la funcionalidad a sus clientes: es proveedora en ambos marcos. Además consume un modelo y un servicio de embeddings de otro, y probablemente usa herramientas de IA internamente: es cliente según la ISO 42001 y responsable del despliegue según la Ley Europea de IA.
Resolver esto al principio condiciona todo lo demás. Una empresa que solo consume IA de terceros tiene menos obligaciones que una que la construye y la vende. Cuando tus proveedores ya publican sus propios certificados ISO 42001, declaraciones de cumplimiento de la Ley Europea de IA o evaluaciones de impacto, puedes apoyarte en esa evidencia y registrar esa responsabilidad como suya, que es lo que esperan los controles de terceros del Anexo A.
La evaluación de impacto del sistema de IA: lo que la ISO 27001 no pide
La evaluación de impacto es donde la ISO 42001 más se aleja de la seguridad de la información. Un análisis de riesgos pregunta qué puede salir mal para la organización. Una evaluación de impacto pregunta a quién puede afectar el sistema de IA, y cómo: a personas, a grupos y a la sociedad. Está más cerca de la ética que de la seguridad, y los auditores la tratan como la base del resto del SGIA. Hazla pronto, en cuanto tengas documentado qué hace cada sistema, porque la política, los procedimientos, el registro de riesgos y la Declaración de Aplicabilidad parten de ella.
Uso previsto y mal uso razonablemente previsible
Para cada sistema, describe para qué se construyó y cómo debe usarse. Después, describe el mal uso más probable en la práctica. A un asistente de cumplimiento pensado para responder preguntas sobre controles de seguridad también se le puede pedir la receta de un pastel. El impacto de ese mal uso es casi nulo: unos cuantos tokens y algo más de energía. Un sistema que filtra candidatos a un empleo, mal usado o simplemente equivocado, puede perjudicar el sustento de una persona. La evaluación no se mide en páginas. Se mide en si has pensado el uso previsto, el mal uso probable y las consecuencias de cada uno.
El nivel de riesgo de la Ley Europea de IA, en el mismo documento
La Ley Europea de IA clasifica los sistemas en cuatro grandes niveles, y la evaluación de impacto es el lugar natural para dejar constancia de en cuál está cada uno.
- Prácticas prohibidas, del artículo 5, vetadas desde el 2 de febrero de 2025. Entre ellas, la puntuación social, las técnicas manipuladoras que causan daño, la extracción no selectiva de imágenes faciales y el reconocimiento de emociones en el trabajo y en los centros educativos.
- Sistemas de alto riesgo, entre ellos los del anexo III: biometría, infraestructuras críticas, educación, empleo, acceso a servicios esenciales como el crédito y aplicación de la ley, entre otros. Tras el Ómnibus Digital sobre IA, el Reglamento (UE) 2026/1744, sus obligaciones se aplican desde el 2 de diciembre de 2027, y desde el 2 de agosto de 2028 para la IA integrada en productos regulados por el anexo I.
- Sistemas con obligaciones de transparencia del artículo 50, a menudo llamados de riesgo limitado, como los chatbots, que deben avisar de que el usuario interactúa con una IA. Estas obligaciones se aplican desde el 2 de agosto de 2026.
- Sistemas de riesgo mínimo, sin obligaciones específicas.
La mayoría de funcionalidades de IA en software que se vende a otras empresas están en los dos últimos niveles: sus usuarios son otras empresas o personas que han aceptado unos términos de servicio, y no toman decisiones sobre personas en los ámbitos del anexo III. Dejar ese razonamiento por escrito en la evaluación de impacto cumple dos funciones. Da al auditor de la ISO 42001 una base justificada para aplicar los controles con una profundidad proporcionada, y te da el material para una declaración de cumplimiento de la Ley Europea de IA cuando un cliente la pida. Para una primera idea de dónde encaja un sistema, nuestro EU AI Act Checker recorre las preguntas clave.
De la evaluación de impacto al registro de riesgos
La evaluación de impacto genera escenarios. Los más probables y los más graves van al registro de riesgos, con amenazas, vulnerabilidades y activos propios de la IA junto a tus riesgos de seguridad de la información. Los escenarios improbables y de bajo impacto pueden quedarse documentados en la evaluación sin convertirse en riesgos.
Algunos riesgos no se pueden eliminar, solo reducir con una salvaguarda. Un equipo que escribe buena parte de su código con un asistente de IA no puede eliminar la posibilidad de un resultado erróneo, pero sí puede hacer que un segundo modelo, distinto del primero, revise su trabajo, y mantener una aprobación humana antes de integrar o desplegar nada. La supervisión humana es la salvaguarda que más buscan los auditores, porque eliminarla aumenta tanto el impacto potencial como la probabilidad del daño.
Datos: procedencia, calidad y cómo evitar la caja negra
La ISO 42001 es exigente con los datos, a través de los controles del objetivo A.7. Tienes que poder describir el ciclo de vida completo de los datos que usan tus sistemas de IA.
De dónde vienen los datos
Empieza por la procedencia y la adquisición. ¿Recoges los datos de tus propios usuarios, los licencias o los obtienes de sitios web públicos? ¿Las fuentes son legítimas y fiables, y podrías defender cómo los has obtenido? Extraer contenido que no tienes derecho a usar es un problema legal y ético, y el auditor lo preguntará.
Si los datos sirven para el fin previsto
Que los datos sean legítimos no significa que sean utilizables. Piensa en un sistema que redacta documentación de cumplimiento a partir de transcripciones de entrevistas con clientes. Las transcripciones son reales, pero si el cliente respondió "no lo sé" o "eso no lo hacemos" a casi todo, el modelo tiene poco que aprovechar. Calidad significa adecuación al fin que le das al sistema, lo que incluye la actualidad de los datos y que las transformaciones que les aplicas tengan sentido.
Controles de calidad en la salida y revisión humana
La misma disciplina se aplica a lo que sale del sistema. Un patrón práctico es que el sistema puntúe su propia confianza y retenga para revisión todo lo que quede por debajo de un umbral, de modo que un borrador solo llegue al cliente después de que una persona lo haya revisado. Sea cual sea el mecanismo, mídelo: las entradas, las transformaciones y las salidas deben generar métricas que puedas enseñar. Una de las partes más costosas de la ISO 42001 en la práctica es montar esa monitorización, para que el sistema no sea una caja negra en la que entra algo, sale algo y nadie sabe explicar qué pasó en medio.
Transparencia: qué cuentas a clientes y usuarios
La transparencia en la ISO 42001 tiene dos capas, y las dos son más sencillas de lo que parecen.
La primera es para clientes y otras partes interesadas. Deben conocer tu política de IA y saber en qué partes de tu producto se usa. El lugar práctico para ello son los términos y condiciones y los contratos, que informan al cliente sin publicar cada detalle de cómo funciona el producto.
La segunda es para quien usa el sistema. Debe saber cuándo está interactuando con una IA o recibiendo un resultado generado por ella. El aviso habitual en la interfaz, que indica que el usuario habla con una IA que puede equivocarse y que conviene revisar sus respuestas, lo resuelve. Para los chatbots y sistemas similares, el artículo 50 de la Ley Europea de IA lo convierte además en una obligación legal.
Los incidentes de IA, dentro de tu proceso de incidentes
La gestión de incidentes en la ISO 42001 se parece mucho a la de la ISO 27001, con una diferencia: el auditor esperará escenarios propios de la IA. Tus procedimientos para ransomware, phishing o fugas de datos no bastan por sí solos. También tienes que mostrar cómo responderías al envenenamiento de datos, cuando alguien introduce datos malos en las fuentes de las que tu sistema aprende o recupera información, y a la inyección de prompts, cuando un usuario diseña una entrada para saltarse las salvaguardas del sistema.
No hace falta un proceso aparte. Amplía los documentos que ya tienes: la política de gestión de incidentes, el plan de respuesta y la política de seguridad de la información deben indicar que los incidentes de IA se comunican por el mismo canal, como tu buzón de seguridad. Abre ese canal también a terceros, para que un cliente o un investigador que detecte un comportamiento extraño de tu IA sepa dónde comunicarlo.
Orden de implantación si ya tienes la ISO 27001
Una secuencia que funciona en la práctica:
- Descubrimiento. Reúne lo que ya existe sobre tus sistemas de IA: qué hacen, qué modelos usan y si esos modelos se consumen por API de un tercero o están alojados en tu propia infraestructura.
- Clasificación de roles. Decide tus roles según la ISO 42001 y la Ley Europea de IA para cada sistema.
- Inventario. Registra cada sistema de IA con sus modelos, herramientas, lenguajes de programación, proveedores y la infraestructura en la que funciona.
- Evaluación de impacto. Evalúa cada sistema, incluido su nivel de riesgo según la Ley Europea de IA.
- Riesgos de IA. Lleva los escenarios resultantes al registro de riesgos y decide su tratamiento.
- Procedimientos del ciclo de vida. Documenta cómo se adquieren y preparan los datos, cómo se diseñan y desarrollan los sistemas y cómo se usan. En un sistema pequeño puede ser un solo documento; en uno mayor, procedimientos separados son más claros.
- Declaración de Aplicabilidad. Justifica cada control del Anexo A, sobre todo las exclusiones y la profundidad con la que aplicas cada control. Sin una justificación clara, el auditor puede pedir más de lo que corresponde a un sistema pequeño.
- Guías de uso. Redacta guías para usuarios técnicos, a partir de los procedimientos de desarrollo, y para personas sin perfil técnico, como los equipos comerciales o de atención al cliente, además de los usuarios externos a través de tu centro de ayuda o tus términos.
- Un único sistema de gestión integrado. Integra el SGIA con el SGSI en lugar de llevarlos en paralelo. Así la gestión de incidentes, el desarrollo seguro, los riesgos, la comunicación y la auditoría interna se apoyan en lo que ya estableció la ISO 27001. Es la misma lógica que permite llevar la ISO 27001 y el ENS como un único sistema.
¿Se puede certificar la ISO 42001 sin la ISO 27001?
Sí. La ISO 42001 es una norma independiente y no exige la ISO 27001 como requisito previo. En la práctica, sin embargo, la falta de un SGSI se nota pronto. La ISO 42001 no pide antivirus en los portátiles ni una configuración concreta de la nube, pero tendrás que decirle al auditor que los datos de tu IA están protegidos, y el auditor preguntará cómo. Si el acceso a tu infraestructura en la nube no está restringido, los privilegios no están segmentados por roles y los discos no están cifrados, esa afirmación es difícil de sostener.
Una empresa sin ISO 27001 puede certificarse en ISO 42001, pero acabará haciendo una parte importante del trabajo de seguridad igualmente para justificar sus respuestas. La ISO 42001 se centra en la ética, la transparencia, el gobierno y el impacto; la seguridad de la información la deja en gran parte a los controles que aportaría un SGSI.
Cómo acompaña Qalea en la ISO 42001
La plataforma de Qalea gestiona la ISO 42001 junto a la ISO 27001, el ENS, SOC 2, NIS2 y DORA en un único sistema, reutilizando controles y evidencias entre marcos, de modo que el SGIA se construye sobre el SGSI que ya tienes en lugar de abrir un segundo proyecto. El inventario de IA, las evaluaciones de impacto, el registro de riesgos, la Declaración de Aplicabilidad y los procedimientos del ciclo de vida viven en el mismo lugar que tu documentación actual, y la evidencia se recoge automáticamente de las herramientas que ya usas.
El equipo de Qalea te acompaña durante todo el proceso, y un vCISO aporta criterio sénior en las decisiones que más pesan en la auditoría: clasificar los roles, fijar la profundidad de cada control y redactar las justificaciones de la Declaración de Aplicabilidad. Por debajo, Qalea opera la capa de seguridad que respalda lo que la ISO 42001 da por hecho sobre tus datos y tu infraestructura, incluidas la monitorización, la protección de los equipos y la gestión de vulnerabilidades. Sobre la diferencia entre documentar controles y operarlos, lee qué no hace una plataforma de compliance.
Qalea prepara a las organizaciones para la auditoría y mantiene el sistema de gestión en marcha entre auditorías. El certificado lo emite una entidad de certificación acreditada.
