← Volver al blog Gobierno de TI

ISO 42001: requisitos, Anexo A y sus 38 controles [2026]

ISO/IEC 42001:2023 es la primera norma internacional certificable para un sistema de gestión de inteligencia artificial (SGIA). Define los requisitos para que una organización decida, documente y demuestre cómo desarrolla, provee o usa sistemas de IA: qué casos de uso existen, qué impacto pueden tener sobre las personas, qué controles se aplican y quién responde cuando algo sale mal. Su Anexo A trae 38 controles en 9 objetivos de control.

Esta guía va a lo específico: qué exige cláusula por cláusula, qué hay en cada uno de los nueve grupos del Anexo A, qué es la evaluación de impacto del sistema de IA —la pieza que no existe en ISO 27001—, qué documentos pide de verdad, y cuándo una empresa necesita la norma y cuándo le basta con una política de uso.

Qué es ISO 42001 y qué problema resuelve

El problema que resuelve no es técnico: es de responsabilidad. Cuando un modelo rechaza una solicitud de crédito, prioriza una vacante o redacta una respuesta a un cliente, alguien tiene que poder contestar tres preguntas: quién autorizó ese uso, con qué datos se alimentó y quién revisa las decisiones antes de que salgan. Una empresa sin sistema de gestión no puede contestarlas, y lo descubre el día que un cliente, un regulador o un abogado se las hace.

ISO/IEC 42001 es la norma que obliga a tener esas respuestas por escrito y a mantenerlas vivas. Comparte estructura con ISO 9001 y con ISO/IEC 27001 —cláusulas 4 a 10— y se certifica igual: la auditoría la realiza un organismo de certificación acreditado bajo ISO/IEC 17021-1, independiente de quien haya ayudado a implantarla.

Lo que la norma no hace: no certifica un modelo, no evalúa la exactitud de un algoritmo y no sustituye al cumplimiento legal. Certifica el sistema de gestión, igual que ISO 9001 no certifica tu producto sino cómo lo gestionas.

Cuándo necesitas la norma y cuándo te basta una política

La pregunta honesta antes de arrancar es si tu empresa necesita un sistema certificable o solo necesita gobernar lo que ya usa. Son inversiones de un orden de magnitud distinto.

Cinco señales de que sí necesitas la norma

1. Vendes un producto con IA dentro. En cuanto la IA está en lo que facturas, el riesgo deja de ser interno: es contractual, y tus clientes corporativos van a pedir cómo lo gobiernas.
2. Te lo empezaron a preguntar por escrito. Los cuestionarios de proveedor ya traen apartados de IA. Contestarlos con buenas intenciones deja de funcionar en cuanto el cliente pide evidencia.
3. La IA toca decisiones sobre personas. Contratación, evaluación de desempeño, crédito, precios diferenciados, acceso a un servicio. Aquí la evaluación de impacto deja de ser burocracia y pasa a ser protección.
4. Operas o vendes en mercados regulados. El reglamento europeo de IA —Reglamento (UE) 2024/1689— ya está en vigor y escalona obligaciones para sistemas de alto riesgo; un SGIA es la forma ordenada de demostrarlas. [DATO A CONFIRMAR CON FER] — si Softgrade acompaña o no cumplimiento del reglamento europeo, y en qué alcance.
5. Ya tienes un ISO 27001 vivo. Buena parte de la maquinaria —auditoría interna, revisión por la dirección, control documental, gestión de incidentes— ya está pagada y el costo marginal cae.

Tres señales de que todavía no

1. Tu uso de IA es asistencia interna. Si lo que hay son chatbots generales para redactar y resumir, lo que necesitas es una política de uso, una lista de herramientas aprobadas y formación. Montar un sistema certificable para eso es sobreingeniería.
2. Nadie sabe qué IA se usa en la empresa. No es que no la necesites: es que todavía no puedes empezar. Sin inventario de casos de uso no hay alcance, y sin alcance no hay sistema. Ese es el primer trabajo, y no requiere norma.
3. La dirección no va a decidir usos prohibidos. La norma obliga a definir qué no se hace. Si esa conversación no va a ocurrir, el sistema nace sin la única parte que tiene dientes.

Los cuatro papeles que puede tener tu empresa

Esta es la primera decisión del proyecto y la que más cambia el trabajo, porque la norma reconoce que las obligaciones no son iguales para quien construye y para quien solo usa. En la práctica, una empresa mexicana media juega dos o tres de estos papeles a la vez, y casi siempre se da cuenta tarde:

• Desarrollador. Construyes o entrenas el sistema de IA. Te toca todo el ciclo de vida: diseño, datos, pruebas, documentación técnica y liberación.
• Proveedor. Lo entregas a un tercero, con o sin haberlo construido. Te toca la información a las partes interesadas, los términos de uso y el soporte.
• Usuario u operador. Lo usas en tu operación. Te toca el uso conforme, la supervisión humana, la formación de quien lo opera y el monitoreo del comportamiento.
• Sujeto afectado. Tus empleados, tus clientes o terceros sobre quienes recaen las decisiones. No es un papel que se elija: es el que obliga a evaluar impacto.

El error clásico: una empresa que integra un modelo de un tercero dentro de su producto se declara «solo usuaria». No lo es. Frente a su cliente es proveedora, y las obligaciones de información y de soporte son suyas aunque el modelo sea de otro.

Estructura: cláusulas 4 a 10

Los requisitos auditables van de la cláusula 4 a la 10, en la estructura de alto nivel común a las normas de sistemas de gestión. Aquí se citan por número y se parafrasean; el texto de la norma tiene derechos de autor y se adquiere a través de un organismo de normalización.

• 4. Contexto. Asuntos internos y externos, partes interesadas —incluidos los sujetos afectados por las decisiones de la IA—, el papel de la organización respecto de cada sistema de IA y la definición del alcance del SGIA.
• 5. Liderazgo. Compromiso de la dirección, la política de IA y la asignación de roles y responsabilidades. Aquí se nombra a quien responde por cada sistema.
• 6. Planificación. Riesgos y oportunidades, la apreciación de riesgos de IA, su tratamiento —con la declaración de aplicabilidad frente al Anexo A—, la evaluación de impacto de los sistemas de IA y los objetivos.
• 7. Apoyo. Recursos, competencia, toma de conciencia, comunicación e información documentada. La competencia es un punto sensible: quien supervisa un sistema de IA tiene que entender qué está supervisando.
• 8. Operación. Planificación y control operacional, ejecución de las apreciaciones de riesgo y de las evaluaciones de impacto cuando el sistema o su contexto cambian.
• 9. Evaluación del desempeño. Seguimiento y medición, auditoría interna y revisión por la dirección.
• 10. Mejora. Mejora continua, no conformidades y acciones correctivas.

Si vienes de ISO 9001 o de ISO 27001, reconoces siete de cada diez requisitos. Lo genuinamente nuevo es la cláusula 6 en dos puntos: la evaluación de impacto y la obligación de mirar el riesgo hacia fuera —hacia las personas y la sociedad—, no solo hacia la organización.

El Anexo A: 9 objetivos y 38 controles

El Anexo A de ISO/IEC 42001 trae 38 controles repartidos en 9 objetivos de control, y la guía de implantación de cada uno vive en el Anexo B de la misma norma. Igual que en ISO 27001, los controles salen del tratamiento del riesgo: no son una lista obligatoria, se incluyen o se excluyen con justificación por escrito en la declaración de aplicabilidad.

La norma trae además dos anexos de orientación que se usan más de lo que parece: uno con guía de implantación de cada control y otro que enumera preocupaciones organizacionales relacionadas con la IA —equidad, transparencia, seguridad, privacidad, robustez, explicabilidad, rendición de cuentas, impacto ambiental—, útil como lista de verificación al apreciar riesgos. Y otro más sobre cómo aplicar el sistema por dominio de uso: salud, empleo o servicios financieros no tienen el mismo perfil de riesgo.

Si necesitas profundizar en el cómo, el ecosistema de normas que acompaña a la 42001 es corto y vale la pena conocerlo: ISO/IEC 23894 para la gestión del riesgo de IA, ISO/IEC 22989 para la terminología, ISO/IEC 5338 para los procesos del ciclo de vida y ISO/IEC 38507 para lo que un consejo de administración debe saber sobre el uso de IA.

La evaluación de impacto del sistema de IA

Es la pieza que distingue a ISO/IEC 42001 de cualquier norma de seguridad que ya tengas, y la que más cuesta arrancar. Una apreciación de riesgos clásica pregunta qué le puede pasar a la organización. La evaluación de impacto de IA pregunta qué les puede pasar a las personas y a los grupos por culpa del sistema, incluso si a la empresa no le pasa nada.

Una evaluación de impacto útil responde, por cada sistema de IA:

1. Qué decide o influye, con qué grado de automatización y sobre quién recae.
2. Qué podría salir mal: error, sesgo sistemático contra un grupo, resultado no explicable, uso fuera del propósito previsto, fuga de información en las entradas.
3. Qué consecuencia tendría para la persona afectada, no para la empresa: perder una vacante, un crédito, un servicio, la privacidad.
4. Qué lo contiene: revisión humana, umbral de confianza, doble control, derecho a segunda opinión, canal de reclamación.
5. Qué se monitorea después del despliegue y con qué frecuencia se reevalúa.

Dos advertencias. La primera: la evaluación de impacto no es la evaluación de impacto de protección de datos que ya conoces; se parecen en la forma y se complementan, pero una mira el tratamiento de datos personales y la otra el efecto de la decisión automatizada. La segunda: no es un documento que se firma una vez. Cuando cambia el modelo, el proveedor, el conjunto de datos o el uso, se rehace.

Qué información documentada exige

Como toda norma de sistemas de gestión, ISO/IEC 42001 exige mantener una lista concreta de información documentada. En la práctica, el paquete mínimo de un SGIA es este:

Y el documento que la norma no exige pero que resuelve la mitad del sistema: el inventario de casos de uso de IA. No aparece con ese nombre en la lista de información documentada, pero sin él no puedes definir alcance, ni apreciar riesgos, ni evaluar impacto, ni declarar aplicabilidad. Es el primer entregable de cualquier proyecto serio.

Cómo se monta sobre un ISO 27001 o un 9001 existente

Aquí está el argumento económico del proyecto. Si ya tienes un sistema de gestión operando, una parte del SGIA está construida:

• Se reutiliza tal cual: el procedimiento de control de información documentada, el de auditoría interna, el de revisión por la dirección, el de no conformidades y acciones correctivas, y el esquema de competencia y formación.
• Se amplía: el inventario de activos pasa a incluir modelos, conjuntos de datos y proveedores de IA; la gestión de proveedores incorpora el reparto de responsabilidades del objetivo A.10; la gestión de incidentes añade el incidente de IA, que no siempre es un incidente de seguridad.
• Se construye desde cero: la política de IA, el inventario de casos de uso, la clasificación por riesgo, la evaluación de impacto, los controles del ciclo de vida y el gobierno de los datos de entrenamiento.

Para dimensionarlo con un punto de comparación verificable: el SGSI ISO/IEC 27001:2022 completo que implantamos en una empresa de software quedó en 34 políticas, 25 procedimientos y 46 formatos. Sobre una base así, un SGIA no vuelve a escribir la mitad del aparato de gestión: añade el cuerpo específico de IA. Sobre una empresa sin ningún sistema de gestión, en cambio, el proyecto incluye construir también esa base, y el calendario que te propongan tiene que decirlo.

Lo que se vende como obligatorio y no lo es

Cuatro afirmaciones que circulan y cuestan dinero:

1. «Hay que certificar cada modelo.» Falso. Se certifica el sistema de gestión, no el modelo ni el algoritmo. No existe un certificado ISO 42001 de un modelo.
2. «Hay que implantar los 38 controles del Anexo A.» Falso. Los controles aplicables salen del tratamiento del riesgo; los no aplicables se excluyen con justificación escrita. Marcar los 38 como aplicables «por si acaso» te obliga a evidenciarlos todos.
3. «Necesitas un comité de ética de IA.» La norma exige roles, responsabilidades y un mecanismo para reportar preocupaciones. Cómo se llame el órgano y cuánta gente lo forme lo decides tú; en una empresa de cincuenta personas, un comité de tres que se reúne cada mes cumple mejor que uno de doce que no se reúne.
4. «Si tienes ISO 27001, ya cumples 42001.» Falso, y es el más caro. La seguridad de la información es una de las preocupaciones que la 42001 mira, no todas: equidad, transparencia, explicabilidad e impacto sobre las personas no están en el Anexo A de la 27001.

Implantación en 6 fases

Fase 1 — Inventario de casos de uso y papel de la organización

Qué IA se usa hoy, quién la usa, con qué datos, sobre qué decisiones y bajo qué contrato. Incluye la IA que nadie autorizó, que es la mitad de la lista en casi todas las empresas. Sin este inventario no hay proyecto: hay una intención.

Fase 2 — Alcance, política y gobierno

Qué sistemas, procesos y unidades entran. Se aprueba la política de IA y se nombra a los responsables, incluido el dueño de cada sistema. Acotar bien el alcance es la decisión que más costo ahorra en la auditoría.

Fase 3 — Riesgos, impacto y declaración de aplicabilidad

Se aprecian riesgos hacia la organización y se evalúa impacto hacia las personas, se decide tratamiento y se escribe la declaración de aplicabilidad frente a los 38 controles, con evidencia apuntada. De aquí sale el plan real del proyecto.

Fase 4 — Controles y documentación

Se escriben las políticas y procedimientos que los controles exigen y se implantan los controles del ciclo de vida y de datos. Orden recomendado: primero lo que genera registros recurrentes —aprobación de casos de uso, revisión humana, incidentes—, porque necesita tiempo acumulado antes de auditar.

Fase 5 — Operación, formación y evidencia

El sistema tiene que haber operado para poder auditarse: casos de uso aprobados por el mecanismo real, evaluaciones de impacto firmadas, incidentes tratados, formación registrada, indicadores medidos. Esta fase es tiempo de calendario, no de esfuerzo.

Fase 6 — Auditoría interna, revisión por la dirección y certificación

Se audita contra la norma, se corrigen hallazgos, la dirección revisa y decide. La auditoría de certificación se realiza en dos etapas y la emite un organismo de certificación acreditado bajo ISO/IEC 17021-1, independiente de quien implantó. Los plazos dependen del alcance y de la madurez previa: [DATO A CONFIRMAR CON FER] — duración típica de un proyecto 42001 acompañado por Softgrade.

7 errores que hacen fracasar un SGIA

1. Empezar por la política y no por el inventario. Una política escrita sin saber qué IA se usa regula una empresa imaginaria. El inventario siempre destapa usos que la política no contemplaba.
2. Declararse «solo usuario» cuando se es proveedor. Si la IA está dentro de lo que vendes, tus obligaciones de información y soporte son tuyas aunque el modelo sea de un tercero.
3. Copiar la apreciación de riesgos del SGSI. Mira hacia dentro y se pierde lo que la norma exige mirar: el efecto sobre las personas afectadas por la decisión.
4. Supervisión humana de adorno. Poner a una persona a aprobar cien salidas al día sin tiempo ni criterio no es control: es una firma. El auditor pregunta cuántas se rechazaron, y la respuesta «ninguna» habla sola.
5. No gobernar los datos de entrenamiento. Procedencia, permisos de uso y calidad. Es el objetivo A.7 y el hueco más frecuente en empresas que afinan modelos con información propia.
6. Dejar fuera a compras y a jurídico. El reparto de responsabilidades con proveedores de IA se pelea en el contrato, no en el documento de política.
7. Un sistema para el certificado, no para operar. Un SGIA que no cambia ninguna decisión del mes siguiente es un archivero, y se nota en la primera auditoría de seguimiento.

Ejemplo: el alcance de un SGIA en una empresa de software

Así se ve el alcance de un sistema en una empresa de software de tamaño medio que ya tiene un SGSI operando y que usa IA en tres frentes distintos. No es una lista de productos: es una lista de decisiones.

Cuatro líneas de inventario ordenan el proyecto entero: el alcance del SGIA cubre los tres primeros, la evaluación de impacto se hace a fondo en el tercero, la declaración de aplicabilidad justifica qué controles del Anexo A quedan fuera, y la cuarta línea —el uso prohibido— es la que un auditor valora más, porque demuestra que la dirección decidió algo incómodo por escrito.

Si tu punto de partida es más temprano —ni inventario, ni política, ni idea de por dónde empezar—, conviene leer antes el panorama de inteligencia artificial en empresas mexicanas, que ordena el primer caso de uso, y la guía de gestión de riesgos tecnológicos, que da el método de valoración que la fase 3 necesita.

Preguntas frecuentes

Conclusión

ISO/IEC 42001 sirve cuando la IA ya toca decisiones que afectan a alguien y la empresa no puede explicar quién las autorizó ni quién las revisa. Si tu uso es asistencia interna y general, lo que necesitas hoy es una política de uso y una lista de herramientas aprobadas, no un sistema certificable.

Si vas a arrancar, tres decisiones ordenan el resto: levanta el inventario de casos de uso antes de escribir nada, decide con honestidad qué papel juega tu empresa —desarrollador, proveedor, usuario— frente a cada sistema, y escribe al menos un uso prohibido. Las tres se toman en las primeras semanas y determinan si el sistema gobierna algo o solo lo documenta.