ISO 42001: cómo gobernar la IA con evidencia

ISO 42001 ofrece una forma estructurada de gobernar la inteligencia artificial cuando esta ya influye en decisiones, productos, procesos internos o relaciones con clientes. No se limita a revisar si un modelo funciona: exige que la organización pueda demostrar quién decide, qué riesgos ha evaluado, cómo controla cambios y qué evidencia conserva.

Índice de Contenidos

1. Claves Para Entender ISO 42001
2. Definir El Alcance Antes De Elegir Controles
3. Implantar El SGIA En El Ciclo De Vida Real
4. Evidencia, Integración Y Certificación
5. Preguntas Frecuentes Sobre ISO 42001
6. Fuentes

Claves para entender ISO 42001

Qué regula realmente la norma

ISO/IEC 42001:2023 establece requisitos para un sistema de gestión de inteligencia artificial, conocido como SGIA o AIMS por sus siglas en inglés. Su función es ordenar las políticas, responsabilidades, procesos y controles que permiten desarrollar, suministrar o utilizar IA de forma gestionada.

La norma no certifica un algoritmo concreto ni declara que una solución sea infalible, ética o libre de sesgos. Evalúa si la organización tiene un sistema capaz de identificar riesgos, tomar decisiones justificadas, aplicar controles y revisar sus resultados. Esa diferencia importa: un modelo puede alcanzar buenos resultados técnicos y, aun así, operar sin una gobernanza suficiente.

La IEC indica que la norma se aplica a organizaciones que proporcionan o utilizan productos o servicios que emplean sistemas de IA, tal como explica la descripción de aplicabilidad de ISO/IEC 42001 publicada por IEC. Por tanto, no solo afecta a empresas que entrenan modelos propios. También puede ser pertinente para una entidad que compra una herramienta de selección de personal, integra una API generativa o usa analítica predictiva para apoyar decisiones de crédito.

La pregunta útil no es “¿tenemos inteligencia artificial?”. Es “¿qué decisiones, servicios, datos y personas quedan afectados por los sistemas de IA que utilizamos o suministramos?”.

La lógica del sistema de gestión

ISO describe una estructura que abarca contexto de la organización, liderazgo, planificación, apoyo, operación, evaluación del desempeño y mejora continua. Puede consultarse esta arquitectura en la explicación de ISO sobre los elementos de ISO 42001. En la práctica, esto conecta la dirección con el uso operativo de la IA.

No basta con una política corporativa que afirme principios generales. El SGIA debe traducirse en decisiones auditables: qué usos están aprobados, qué criterios activan una revisión reforzada, quién autoriza el despliegue, cómo se evalúa un proveedor y cuándo se retira un sistema.

Yo recomendaría tratar el SGIA como una capa de gobierno. Debe relacionarse con seguridad, privacidad, continuidad, calidad, legal y negocio, pero sin diluir la responsabilidad sobre los riesgos específicos de IA. Por ejemplo, un control de acceso puede reducir el riesgo de uso no autorizado, pero no demuestra por sí solo que la salida de un modelo sea adecuada para una decisión que afecta a personas.

Cuándo tiene sentido implantarla

La implantación suele ser razonable cuando concurren una o varias de estas situaciones:

• La organización desarrolla, comercializa o integra sistemas de IA en servicios relevantes.

• La IA apoya decisiones con efectos financieros, laborales, sanitarios, comerciales, educativos o de seguridad.

• Clientes, bancos, matrices, licitaciones o contratos solicitan evidencia de gobernanza de IA.

• Existen varios equipos adquiriendo herramientas de IA sin un inventario, responsables o criterios comunes.

• La dirección necesita una visión consolidada de riesgos, dependencias de proveedores y controles.

No siempre conviene empezar por la certificación. Si solo existe un uso experimental aislado, sin datos sensibles ni impacto relevante, puede ser más sensato fijar primero reglas mínimas, inventario y criterios de aprobación. En cambio, si la IA ya forma parte de un servicio contractual o de una cadena de decisiones críticas, un SGIA formal puede evitar que la documentación llegue después del problema.

Definir el alcance antes de elegir controles

El alcance es una decisión de gobierno

Un alcance débil es una de las causas más comunes de implantaciones poco útiles. Decir “toda la inteligencia artificial de la empresa” puede sonar completo, pero resulta difícil de operar si nadie sabe qué se considera IA, qué unidad responde por cada uso o qué sistemas de terceros deben incluirse.

El alcance debe delimitar actividades, unidades, ubicaciones, productos, servicios, procesos y relaciones externas. También debe explicar exclusiones justificadas. Una exclusión no puede ser una forma de ocultar un riesgo importante. Si un proveedor opera un modelo que toma decisiones dentro de un servicio ofrecido por la organización, ese proveedor quizá no esté dentro del sistema de gestión como entidad, pero la dependencia y sus controles sí deben evaluarse.

Separar sistemas, modelos Y procesos afectados

Para evitar confusiones, conviene crear tres registros conectados. No son lo mismo y mezclarlos deja huecos de control.

Este enfoque permite responder preguntas que una lista única no resuelve. ¿Qué aplicaciones dependen del mismo modelo fundacional? ¿Qué proveedor procesa información sensible? ¿Qué cambio de versión podría afectar a varios procesos a la vez? Sin estas relaciones, una actualización aparentemente menor puede generar un efecto difícil de rastrear.

Criterios prácticos para incluir O excluir

Yo usaría una matriz de decisión sencilla antes de seleccionar controles. Cada caso debe revisarse por su finalidad, impacto, autonomía, datos, dependencia y exposición externa.

Un chatbot interno que resume documentos no tiene el mismo perfil que un motor que prioriza candidatos. Ambos pueden estar dentro del alcance, pero no requieren idéntico nivel de análisis. La proporcionalidad no significa ausencia de control; significa que el control responde al riesgo real.

El caso de los proveedores externos

Los sistemas adquiridos presentan una dificultad concreta: la organización usuaria no controla el entrenamiento, la arquitectura ni las actualizaciones del proveedor. Aun así, conserva responsabilidad sobre cómo incorpora esa herramienta a sus procesos.

La documentación mínima debería relacionar el proveedor, el servicio adquirido, el uso autorizado, los datos introducidos, las limitaciones conocidas, las condiciones de soporte, la versión o configuración y el responsable interno. También conviene definir qué cambios requieren reevaluación. Puede ser una nueva versión del modelo, una modificación contractual, un cambio en la localización de datos o una ampliación de la finalidad de uso.

Implantar el SGIA en el ciclo de vida real

De la política A la operación

La política de IA fija una dirección, pero no sustituye a los procedimientos. Para que el SGIA funcione, cada fase del ciclo de vida necesita entradas, decisiones, responsables y resultados conservables.

La norma abarca contexto, liderazgo, planificación, apoyo, operación, evaluación y mejora, como recoge también la publicación de ISO sobre el marco de gestión de ISO/IEC 42001. La implicación práctica es clara: la gestión no acaba cuando un sistema se despliega. Un SGIA debe mantener control cuando cambian los datos, los proveedores, los prompts, las instrucciones de uso o el comportamiento observado.

Diferenciar riesgo organizativo Y riesgo técnico

Es útil separar dos planos, aunque deban conectarse. El riesgo organizativo se refiere a decisiones de gobierno: falta de responsable, alcance ambiguo, ausencia de criterios de compra, formación insuficiente o incumplimiento de una política. El riesgo técnico se relaciona con el comportamiento del sistema: errores, alucinaciones, degradación, ataques de entrada, sesgo medible o filtración de información.

Un ejemplo aclara la diferencia. Si un equipo usa un modelo generativo para redactar respuestas a clientes sin aprobación, existe un riesgo organizativo de uso no autorizado. Si el modelo genera una respuesta falsa y esta llega al cliente, aparece además un riesgo técnico y operativo. Resolver solo uno de los dos no basta. La organización necesita una regla de autorización y, al mismo tiempo, validaciones, límites de uso y supervisión humana donde correspondan.

Cambios frecuentes: el punto donde se rompe el control

Los cambios de modelos y proveedores pueden convertir un SGIA correcto en una fotografía antigua. Un registro de cambios debe indicar qué se modificó, por qué, quién aprobó el cambio, qué evaluación se repitió y cuál fue el resultado. Esto incluye ajustes de prompts cuando estos influyen de forma material en las salidas o en el comportamiento del servicio.

Fair warning: no existe una regla universal que obligue a repetir toda la evaluación por cualquier cambio menor. La decisión debe depender de la criticidad. Cambiar el texto de bienvenida de un asistente no equivale a cambiar el modelo subyacente, ampliar el acceso a datos de clientes o activar acciones automáticas. El criterio debe quedar documentado para que sea consistente y auditable.

Evidencia, integración Y certificación

Qué espera ver una auditoría

Una auditoría no debería limitarse a comprobar si existen documentos. Busca coherencia entre lo que la organización afirma, lo que ejecuta y lo que puede demostrar. Una política sin registros de aprobación, pruebas, revisiones o seguimiento tiene un valor limitado.

Una base de evidencia auditable puede incluir:

• Alcance del SGIA, partes interesadas y responsables asignados.

• Inventario de sistemas, modelos, proveedores y procesos afectados.

• Evaluaciones de riesgos, análisis de impacto y planes de tratamiento.

• Aprobaciones de uso, pruebas, criterios de aceptación y resultados.

• Registros de cambios, incidencias, quejas, acciones correctivas y revisiones.

• Indicadores de desempeño y actas de revisión por la dirección.

La evidencia debe poder seguir una cadena lógica. Si se declara que un sistema requiere supervisión humana, el auditor podrá pedir que se muestre dónde se estableció, cómo se aplicó y cómo se verifica. Por eso, un repositorio con control de versiones y responsables definidos suele ser más valioso que un conjunto de archivos dispersos.

Integrar sin duplicar controles

ISO/IEC 42001 puede convivir con otros sistemas de gestión. ISO 27001 aporta una base útil para riesgos de seguridad de la información, accesos, activos, incidentes y proveedores. ISO/IEC 27701 puede ayudar cuando el tratamiento incluye datos personales, mientras que ISO/IEC 23894 ofrece orientación específica para riesgos de IA.

La integración no consiste en copiar documentos. Consiste en reutilizar procesos cuando cubren el requisito y añadir lo que falta. Por ejemplo, una evaluación de proveedores de seguridad puede incorporar preguntas sobre cambios de modelo, transparencia, límites de uso, retención de datos y notificación de modificaciones. Así se evita que el mismo proveedor sea evaluado tres veces por equipos distintos con criterios incompatibles.

Para organizaciones que ya gestionan seguridad en la región, revisar cómo se aplica ISO 27001 en Latinoamérica puede ayudar a identificar estructuras existentes de responsables, riesgos y evidencias que el SGIA puede aprovechar.

Implantar O certificarse: cómo decidir

La certificación es voluntaria y la emiten organismos de certificación independientes, no ISO. Decidir certificarse depende de la necesidad de aseguramiento externo, no de una supuesta obligación universal.

No hay datos públicos sólidos y comparables que permitan afirmar un coste o plazo medio de implantación aplicable a todas las organizaciones. Una empresa con un solo caso de uso y procesos maduros puede requerir un esfuerzo muy distinto al de un grupo con múltiples productos, modelos de terceros y operaciones en varios países. La forma responsable de estimarlo es diagnosticar el alcance, la evidencia existente, las brechas y los recursos disponibles. Un Método de diagnóstico basado en evidencia puede convertir esa estimación en un plan priorizado antes de iniciar una auditoría de certificación.

Preguntas frecuentes sobre ISO 42001

¿Qué es exactamente ISO 42001?

Es una norma internacional para establecer, implantar, mantener y mejorar un sistema de gestión de inteligencia artificial. Su foco es la gobernanza organizativa de los sistemas de IA y sus riesgos, no la certificación de un modelo individual.

¿A qué organizaciones se aplica?

Puede aplicarse a organizaciones que desarrollan, proporcionan, integran o utilizan productos y servicios con IA. El tamaño no es el criterio decisivo; importan el uso, el impacto y la necesidad de control.

¿Es obligatoria la certificación ISO 42001?

No. La certificación es voluntaria. Puede ser útil cuando una organización necesita demostrar conformidad ante clientes, contratos, licitaciones o grupos corporativos, pero primero debe existir un SGIA que opere de forma consistente.

¿Qué documentos Y registros son necesarios?

Se necesitan documentos de dirección, como alcance, política, objetivos y responsabilidades, junto con registros operativos. Entre ellos están inventarios, evaluaciones de riesgos, aprobaciones, pruebas, cambios, incidentes, revisiones y acciones correctivas.

¿Cómo se gestiona un modelo comprado A un tercero?

La organización debe documentar el uso autorizado, datos tratados, configuraciones, límites, responsable interno, condiciones del proveedor y criterios para reevaluar cambios. No controlar el modelo no elimina la necesidad de controlar su uso.

¿Cómo se relaciona ISO 42001 con ISO 27001?

ISO 27001 se centra en el sistema de gestión de seguridad de la información. ISO 42001 aborda la gestión de IA. Comparten elementos de gestión y pueden integrarse, pero la segunda añade cuestiones como impactos de IA, ciclo de vida, transparencia y comportamiento del sistema.

¿Qué errores suelen debilitar una auditoría?

Son frecuentes los alcances vagos, inventarios incompletos, políticas sin evidencias operativas, responsables no definidos y cambios de proveedores o modelos sin reevaluación. La corrección empieza por relacionar cada requisito con una evidencia concreta y vigente.

Fuentes

• iso.org: https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html

• iso.org: https://www.iso.org/publication/PUB200420.html

• webstore.iec.ch: https://webstore.iec.ch/en/iec_catalog/product/preview/?id=cHViL3BkZi9wcmV2aWV3L2luZm9faXNvaWVjNDIwMDF7ZWQxLjB9ZW4ucGRm