Problema
Una organización puede preparar políticas, matrices y procedimientos para ISO/IEC 42001 y seguir sin poder explicar una decisión real tomada por un sistema de IA. Los documentos existen, pero no están conectados con la ejecución: nadie sabe qué control actuó, qué evidencia dejó ni qué cambió después de una revisión.
Ese desacople convierte el sistema de gestión en una biblioteca. La auditoría encuentra archivos; la operación sigue dependiendo de conocimiento informal, capturas aisladas y personas que recuerdan cómo debería funcionar el proceso.
Tesis
ISO/IEC 42001 se vuelve útil cuando cada intención de gobierno produce evidencia operativa. Política, control, ejecución, revisión y mejora deben formar una cadena que pueda reconstruirse sin pedir una explicación oral al owner.
La meta no es generar más documentación. Es conseguir que el sistema de gestión observe y modifique el trabajo real. Una evidencia es valiosa cuando demuestra que un control actuó sobre una decisión concreta, dentro de una versión y un contexto identificables.
Framework
Traduce el sistema de gestión a una cadena de evidencia.
| Capa | Pregunta operativa | Evidencia útil |
|---|---|---|
| Objetivo y política | ¿Qué resultado o riesgo queremos gobernar? | Política aprobada, alcance y criterio aplicable |
| Control | ¿Qué debe ocurrir antes, durante o después de usar IA? | Regla, owner, trigger, excepción y mecanismo de parada |
| Ejecución | ¿Qué ocurrió en un caso real? | Traza, versión, datos relevantes, aprobación y salida |
| Evaluación | ¿Funcionó el control en su contexto? | Prueba, muestra, incidente, desviación y riesgo residual |
| Decisión | ¿Qué se aceptó, corrigió o detuvo? | Acta o registro con responsable y fundamento |
| Mejora | ¿Qué cambió en el sistema? | Acción correctiva, nueva versión y verificación posterior |
La cadena evita dos confusiones. La primera es asumir que una política demuestra cumplimiento por existir. La segunda es creer que un log demuestra control porque registra actividad. Una política sin ejecución es intención. Un log sin criterio es ruido. La evidencia aparece cuando ambos se conectan y permiten emitir un veredicto.
Cada artefacto debe tener contexto suficiente para ser interpretable: sistema afectado, versión, periodo, responsable, control relacionado y estado. No hace falta capturarlo todo. Hace falta conservar lo que permite demostrar decisiones materiales y reconstruir excepciones.
Por qué importa ahora
ISO sitúa ISO/IEC 42001 dentro de sus normas de sistemas de gestión y describe estos sistemas como mecanismos importantes para gobernar el desarrollo y despliegue de IA. La lógica de un sistema de gestión exige conectar responsabilidades, controles y evaluación con la operación; sin evidencia, esa conexión solo puede afirmarse, no demostrarse.
El AI Risk Management Framework de NIST concreta qué aspecto tiene esa conexión. Su función de medición pide documentar métodos, métricas, conjuntos de prueba, resultados y limitaciones, además de revisar la eficacia de los controles y monitorizar el sistema en producción. La evidencia operativa es el puente entre el sistema de gestión y esas comprobaciones.
Preparar una revisión y construir un sistema que aprende no son objetivos opuestos, pero tampoco son equivalentes. El expediente demuestra una fotografía; la cadena de evidencia debe mostrar cómo la organización detecta una desviación, decide y actualiza el control.
Anti-ejemplo
El anti-ejemplo es crear una carpeta por control y llenarla antes de la auditoría. Hay una política de supervisión humana, un procedimiento de incidentes y una plantilla de evaluación de impacto. Cuando se selecciona una decisión real, nadie puede identificar qué versión del modelo intervino, qué persona revisó la salida ni si el incidente cambió el procedimiento.
El equipo corrige el expediente añadiendo capturas. El control sigue igual. En la siguiente revisión, la evidencia vuelve a reconstruirse manualmente. Esto no es mejora continua; es producción periódica de pruebas sin memoria operativa.
Protocolo (3 pasos)
- Elige una decisión material. Empieza por un workflow donde la IA afecte a clientes, empleados, dinero, seguridad o cumplimiento, y define qué control debería ser visible.
- Diseña el esquema de evidencia. Conecta objetivo, control, trigger, owner, versión, resultado, excepción y decisión de revisión. Automatiza la captura solo después de validar que esos campos sirven.
- Ensaya la reconstrucción. Selecciona un caso cerrado y pide a una persona independiente que explique qué ocurrió, qué control actuó y qué mejora se aplicó. Lo que no pueda reconstruir es deuda del sistema de gestión.
| Prueba | Si pasa | Si falla |
|---|---|---|
| La política apunta a un control observable | Hay intención ejecutable | La política es declarativa |
| La traza identifica versión y contexto | El caso puede reproducirse | El log solo registra actividad |
| La revisión produce una decisión | El sistema gobierna | El comité solo recibe información |
| La acción correctiva se verifica | Hay mejora continua | Hay cierre administrativo |
Relacionado
- Governance vs Compliance: por qué tu política no decide nada
- AI Traces: la capa que convierte agentes en sistemas auditables
- AI Decision Ledger: el registro que separa aprendizaje de opinión
Fuentes consultadas
- Management systems — ISO — página oficial revisada que sitúa ISO/IEC 42001 como norma de sistema de gestión de IA y resume su papel en el desarrollo y despliegue.
- NIST Artificial Intelligence Risk Management Framework 1.0 — publicación oficial revisada para documentación de métricas, pruebas, limitaciones, eficacia de controles y monitorización en producción.
Próximo paso
Escoge un control de tu sistema de gestión y sigue su rastro hasta una decisión real. Si solo encuentras política y procedimiento, falta instrumentación. Si solo encuentras logs, falta criterio. El objetivo es que una revisión pueda unir ambos y demostrar qué cambió en la operación.