Cuando una organización decide adoptar ISO/IEC 42001, lo primero que circula internamente es el índice de la norma. Y el índice engaña: leído rápido parece una lista de capítulos administrativos —contexto, liderazgo, planificación, soporte, operación, evaluación, mejora— que alguien podría cubrir escribiendo documentos. Esa lectura es la que hace fracasar la mitad de las implementaciones, porque termina produciendo una carpeta impecable que no describe cómo funciona la organización de verdad.
Un auditor no evalúa tu carpeta. Evalúa si existe un sistema de gestión que opera, deja rastro y corrige. La pregunta útil, entonces, no es qué dice la norma sino qué evidencia vas a poder mostrar dentro de doce meses, cuando alguien externo pida ver no lo que decidiste hacer, sino lo que efectivamente hiciste.
Qué evidencia hay que producir
La norma está construida sobre una lógica repetida: define un proceso, aplícalo, guarda el registro de haberlo aplicado y demuestra que corriges cuando falla. Traducido a entregables, eso significa producir y mantener un conjunto acotado de cosas.
- Un alcance defendible. Qué sistemas de IA quedan dentro y cuáles no, con el criterio explícito. La dificultad real no son los modelos que tu equipo construye, sino la IA que llegó embebida en software que ya comprabas. Necesitas una regla para decidir si una funcionalidad de un proveedor entra al alcance o no.
- Un inventario vivo de sistemas de IA. Con propósito, datos que toca, etapa del ciclo de vida y un dueño con nombre y apellido. Si el inventario se actualiza solo cuando se acerca la auditoría, el auditor lo va a notar en la primera entrevista. Cómo levantarlo la primera vez lo desarrollamos en nuestro artículo sobre inventario de Shadow AI.
- Un método de evaluación de riesgos, no una planilla. La norma exige demostrar que existe un proceso repetible: qué se evalúa, con qué criterios, quién lo hace y cada cuánto se repite. Y luego los registros de haberlo aplicado a sistemas concretos, con fechas.
- Evaluaciones de impacto sobre personas. Es el elemento que distingue a este sistema de gestión de cualquier otro y el que más equipos subestiman. Existe orientación específica en la familia de normas relacionadas —ISO/IEC 42005 aborda justamente la evaluación de impacto de sistemas de IA—, y el desarrollo práctico lo tratamos en este artículo.
- Una decisión razonada sobre controles. La norma trae un anexo de controles y la lógica es la misma que ya conoces de otros sistemas de gestión: justificar cuáles aplican, cuáles no y por qué. Un "no aplica" sin argumento es un hallazgo casi seguro.
- Registros del ciclo de vida. Qué se probó antes de pasar a producción, qué se monitorea después, con qué umbrales y bajo qué criterio se apaga un sistema. Esta última parte casi nunca está escrita.
- Auditoría interna y no conformidades cerradas. La evidencia más creíble que puedes mostrar es un hallazgo que encontraste tú, con la acción correctiva y la verificación de que funcionó.
Un sistema de gestión que nunca produjo una no conformidad no está funcionando: está siendo administrado.
Qué roles hay que nombrar
La norma no dicta un organigrama, pero sí exige que las responsabilidades estén asignadas y comunicadas. En la práctica hay cuatro figuras que, si no existen, hacen que todo lo demás se caiga.
La primera es un responsable del sistema de gestión con autoridad real sobre el proceso, no un coordinador que redacta actas y pide favores. La segunda es un dueño por cada sistema de IA: una persona, no un área, que responde por su comportamiento en producción. La tercera es un órgano de gobierno capaz de aprobar, condicionar o detener un despliegue; sin esa atribución el comité se vuelve un foro de presentaciones. La cuarta es una revisión independiente, alguien que no dependa de quien entrega el proyecto y pueda decir que algo no está listo.
Si tu organización ya tiene ISO 27001
Tienes ventaja, pero menos de la que te van a vender. Ambas normas comparten la estructura de alto nivel común a los sistemas de gestión, así que puedes reutilizar la maquinaria: análisis de contexto, gestión documental, competencias, auditoría interna, revisión por la dirección, tratamiento de no conformidades. También puedes integrar los ciclos de auditoría en lugar de correr dos programas paralelos.
Lo que no se puede reutilizar es el eje de impacto de la matriz de riesgos, y este es el error más frecuente que vemos. ISO 27001 pregunta cómo un evento afecta la información de la organización. ISO/IEC 42001 obliga a preguntar además cómo el sistema afecta a las personas sobre las que se aplica. Si copias la escala de impacto de tu SGSI, vas a terminar puntuando "daño reputacional" y "multa regulatoria" sin haber puntuado nunca a la persona a la que el modelo le negó algo. Formalmente cumples; sustantivamente no evaluaste nada.
Hay una segunda diferencia menos visible: el objeto de control cambia solo. Un servidor configurado sigue configurado; un modelo cambia de comportamiento cuando cambian los datos de entrada o cuando el proveedor actualiza la versión sin avisar. Eso empuja los controles hacia el monitoreo continuo.
Por dónde empezar de verdad
Recomendamos partir por lo que además sirve aunque nunca te certifiques. Primero, alcance e inventario: sin saber qué sistemas tienes, cualquier análisis de brechas es especulación. Segundo, el método de evaluación de riesgo e impacto, y aplicarlo a dos o tres casos reales —de preferencia uno incómodo— en lugar de escribir el procedimiento perfecto para casos hipotéticos. Tercero, cerrar las brechas de gobierno: quién decide qué, con qué acta. Recién después, la revisión formal de controles y un ensayo de auditoría interna.
Una advertencia sobre plazos. Los organismos certificadores esperan ver el sistema operando durante un período con evidencia acumulada, no solo documentado, de modo que prometer un certificado para el trimestre siguiente casi siempre significa que se está documentando algo que no ocurre. Si tu directorio necesita una señal antes, dásela con lo que el sistema ya produce: el inventario, las evaluaciones firmadas y el primer ciclo de hallazgos cerrados. Eso resiste preguntas; una carpeta, no.