ISO/IEC 42001 explicada para quien no es auditor
Por qué escribo esto
La he mencionado de pasada en un par de posts anteriores (al hablar de Cassandra y del MCP de YoFacturo) dando por hecho que se sabía de qué hablaba. Pero la realidad es que, cuando pasamos de un script experimental a arquitecturas de agentes en producción, el “ya veremos” deja de ser una opción. Toca explicarla bien, sin dar nada por supuesto.
Qué es en realidad (y qué no es)
La ISO/IEC 42001 es la primera norma internacional para establecer un Sistema de Gestión de Inteligencia Artificial (AIMS).
Es importante la distinción: no es una ley, es un marco de procesos voluntario y certificable para cualquier organización que desarrolle, provea o utilice IA.
Eso la diferencia del AI Act europeo, que es una regulación obligatoria centrada en la conformidad del producto según su nivel de riesgo. Mientras el AI Act te dice qué está prohibido, la ISO 42001 te dice cómo organizar internamente la responsabilidad (accountability), el riesgo y la mejora continua de lo que sí estás construyendo.
Cómo se estructura
Sigue la Estructura de Alto Nivel (HLS) común a otras normas como la ISO/IEC 27001 (seguridad de la información). Si tu organización ya tiene un SGSI (Sistema de Gestión de Seguridad de la Información), ya tienes el 50% de la “columna vertebral” para la IA.
Sin embargo, lo específico de la 42001 está en su enfoque técnico-social. No se limita a proteger datos; exige:
- Evaluar riesgos específicos de la IA: sesgos, opacidad y el envenenamiento de modelos.
- Evaluar el impacto dual: no solo cómo afecta la IA al negocio, sino las consecuencias para los derechos fundamentales, la salud y el bienestar de los individuos y grupos afectados por sus decisiones.
Qué pide en la práctica
Si eliminamos la jerga de auditoría, la norma te pide evidencias reales en cuatro frentes:
- Inventario y responsabilidad (accountability): no puede haber Shadow AI. Exige un registro exhaustivo de cada sistema y la definición clara de quién es el responsable de cada uno (“owner”), especialmente para gestionar decisiones automatizadas.
- Evaluación continua de riesgos e impacto: a diferencia del software tradicional, la IA no se prueba una sola vez. La norma pide evaluar el impacto antes de desplegar y monitorizar después.
- Gestión del ciclo de vida y “drift”: los sistemas de IA se degradan. La norma exige procesos de validación continua para detectar desviaciones en los datos (data drift) o en el concepto (concept drift) que alteren el rendimiento satisfactorio del modelo en producción.
- Supervisión humana efectiva: no basta con una declaración en un PDF. Debes demostrar mecanismos técnicos de human-over-the-loop o human-in-the-loop donde las personas tengan la autoridad real para anular o ajustar acciones del agente en tiempo real.
Básicamente, es poner por escrito y de forma auditable lo que ya defendía en el post de Cassandra: el control tiene que seguir siendo humano y, bajo esta norma, el “botón de desconexión” debe ser una pieza de arquitectura, no un deseo.
No hace falta certificarse para que sea útil. Solo hace falta tomársela en serio antes de que un incidente de “agencia excesiva” en producción te obligue a improvisar un parche.