Cómo mapear marcos de IA sin crear más complejidad

Una organización decide ordenar su gobernanza de inteligencia artificial y abre cinco frentes a la vez: cumplimiento de la Ley de IA de la Unión Europea, implantación de ISO/IEC 42001, alineación con NIST AI RMF, adaptación de controles COSO y preparación de Auditoría Interna. El resultado habitual no es más control, sino cinco hojas de cálculo que describen casi los mismos riesgos con palabras distintas.

Ese enfoque confunde fuentes de autoridad con diseño de control. La solución no consiste en escoger un único marco y descartar los demás. Consiste en asignar a cada fuente una función concreta y traducirlas hacia una arquitectura común de riesgos, objetivos de control, controles, evidencia y aseguramiento.

El objetivo no es construir un “supermarco” de IA. Es evitar que cada marco cree su propio sistema paralelo de gobierno y evidencia.

No todos los marcos responden a la misma pregunta

El primer paso para reducir complejidad es dejar de tratar regulación, normas, marcos de riesgo, control interno y guías de auditoría como si fueran equivalentes.

La Ley de IA de la Unión Europea establece obligaciones legales según el papel de la organización, el tipo de sistema y su nivel de riesgo. A septiembre de 2026, gran parte del Reglamento ya es aplicable y las autoridades han comenzado su fase de ejecución, mientras determinadas obligaciones para sistemas de alto riesgo mantienen fechas posteriores. Ese calendario ilustra por qué cualquier mapa de cumplimiento debe estar versionado.

ISO/IEC 42001:2023 cumple otra función: especifica requisitos para establecer, implementar, mantener y mejorar continuamente un sistema de gestión de inteligencia artificial. No sustituye una evaluación jurídica de la Ley de IA, pero proporciona una estructura organizativa para integrar política, responsabilidades, riesgos, operación, seguimiento y mejora.

El NIST AI Risk Management Framework es voluntario y orientado a la gestión de riesgos. Su lógica GOVERN, MAP, MEASURE y MANAGE ayuda a estructurar preguntas sobre contexto, riesgos, medición y respuesta. El perfil de NIST para IA generativa añade consideraciones específicas para GenAI. NIST señala además que AI RMF 1.0 está en revisión, otro recordatorio de que un crosswalk no puede tratarse como un documento estático.

COSO aporta la perspectiva de control interno. Su publicación de 2026, Achieving Effective Internal Control Over Generative AI, adapta los cinco componentes y los 17 principios del Internal Control—Integrated Framework a riesgos y capacidades de GenAI. Su valor no es crear otra capa de cumplimiento, sino conectar la gobernanza de IA con estructuras de control que muchas organizaciones ya utilizan.

Finalmente, el IIA ocupa la capa de aseguramiento profesional. Las Normas Globales de Auditoría Interna son obligatorias para la práctica profesional de auditoría interna dentro del IPPF; en cambio, The IIA's Artificial Intelligence Auditing Framework es orientación para comprender riesgos, gobierno, gestión y auditoría de IA. No son un sustituto de la responsabilidad de la dirección sobre los controles.

Fuente	Pregunta principal	Naturaleza	Uso más útil
Ley de IA de la UE	¿Qué debemos cumplir legalmente?	Regulación vinculante cuando aplica	Alcance, clasificación, roles y obligaciones
ISO/IEC 42001	¿Cómo gobernamos la IA como sistema de gestión?	Norma internacional de sistema de gestión	Política, responsabilidades, procesos y mejora
NIST AI RMF	¿Cómo estructuramos y tratamos el riesgo de IA?	Marco voluntario	Taxonomía, evaluación y priorización de riesgos
COSO	¿Cómo diseñamos un sistema de control confiable?	Marco de control interno	Objetivos de control, actividades y monitoreo
IIA	¿Cómo obtenemos aseguramiento independiente?	Normas profesionales y orientación	Alcance, criterios, evidencia y conclusión de auditoría

La complejidad aparece cuando cada una de esas preguntas genera su propia biblioteca de controles.

Utilizar una sola arquitectura de control

Una organización madura no necesita cinco controles distintos para demostrar que conoce qué sistemas de IA utiliza. Necesita un control de inventario y clasificación suficientemente sólido, y después una trazabilidad que muestre cómo ese control contribuye a distintas expectativas.

Tomemos un inventario de IA como ejemplo. Desde la perspectiva regulatoria, permite determinar aplicabilidad, rol y clasificación de riesgo. Para ISO/IEC 42001, ayuda a definir el alcance del sistema de gestión y a conectar activos de IA con evaluaciones de riesgo e impacto. Para NIST, aporta contexto para MAP y para priorizar medición y tratamiento. Para COSO, alimenta la identificación de riesgos y la información necesaria para que los controles funcionen. Para Auditoría Interna, se convierte en una fuente de población, criterio de cobertura y evidencia sobre la integridad del universo auditable.

El control es uno. Las razones para exigirlo son varias.

Esta misma lógica puede aplicarse a un conjunto relativamente estable de dominios de control: inventario y clasificación; roles y rendición de cuentas; evaluación de riesgos e impactos; datos y ciclo de vida del modelo; supervisión humana; terceros; gestión de cambios; seguimiento del desempeño; incidentes; documentación y trazabilidad. Los marcos se mapean contra esos dominios en lugar de generar dominios nuevos cada vez que aparece una publicación.

Esto también evita un error frecuente: asumir que una correspondencia significa equivalencia. Un control que ayuda a satisfacer ISO/IEC 42001 puede aportar evidencia relevante para una obligación legal, pero no demuestra por sí solo cumplimiento de la Ley de IA. Del mismo modo, una certificación ISO no convierte automáticamente a una organización en conforme con todas las obligaciones regulatorias aplicables.

Del crosswalk a una trazabilidad auditable

Un crosswalk útil no debería terminar en una tabla de “cláusula A = cláusula B”. Esa comparación sirve para orientarse, pero rara vez explica qué debe hacer realmente la organización o qué debería probar un auditor.

Una secuencia más útil es:

obligación o expectativa → riesgo → objetivo de control → control esperado → evidencia → procedimiento de auditoría → conclusión

Por ejemplo, una expectativa sobre supervisión humana puede traducirse en el riesgo de decisiones automatizadas sin revisión suficiente; después, en un objetivo de control que exija intervención humana definida y efectiva; luego, en controles sobre umbrales, escalamiento y autoridad para anular una salida; y finalmente, en evidencia como configuraciones, registros de decisiones, excepciones y pruebas de funcionamiento.

La trazabilidad debe conservar tres atributos que suelen perderse en los mapas simplificados. Primero, autoridad: una obligación legal no tiene el mismo estatus que una recomendación. Segundo, aplicabilidad: una expectativa puede depender del rol de proveedor o responsable del despliegue, del tipo de sistema, de la jurisdicción o del caso de uso. Tercero, versión: la fuente puede cambiar aunque el control operativo siga siendo el mismo.

En la práctica, esto permite mantener una biblioteca de controles canónica y una capa separada de referencias. Cuando cambia una norma, se actualiza la relación con el control; no se reconstruye toda la arquitectura.

Tres errores que multiplican el trabajo

El primero es convertir orientación en obligación. NIST puede ser una referencia excelente para diseñar gestión de riesgos, pero su uso voluntario no debería presentarse como requisito jurídico salvo que una política, contrato o regulación lo incorpore expresamente.

El segundo es duplicar evidencia por marco. Si el mismo registro de aprobación, evaluación de impacto o monitoreo demuestra el funcionamiento de un control frente a varias fuentes, mantener cinco expedientes separados aumenta trabajo sin mejorar el aseguramiento. La evidencia debe conservar su procedencia, integridad y contexto, pero puede reutilizarse cuando la relación esté documentada.

El tercero es tratar el mapa como terminado. En 2026, la aplicación de la Ley de IA continúa evolucionando y NIST está revisando AI RMF 1.0. Un mapa sin propietario, fecha de revisión y fuente oficial enlazada envejece rápidamente. La gestión de cambios del propio crosswalk debe formar parte del sistema de gobernanza.

Qué debería pedir un líder de auditoría

Para Auditoría Interna, la meta no es convertirse en propietaria del mapa de cumplimiento. Su función es evaluar si la organización ha creado una arquitectura coherente y si puede demostrar que los controles funcionan. El IIA refuerza además, mediante la Norma 9.5 sobre coordinación y confianza, la necesidad de coordinarse con otros proveedores de aseguramiento, reducir duplicidades y detectar brechas de cobertura.

Un gerente de auditoría debería poder responder cinco preguntas: ¿existe una única biblioteca de controles de IA? ¿cada control tiene propietario, evidencia y criterio de desempeño? ¿las referencias indican autoridad, aplicabilidad y versión? ¿las funciones de Legal, Cumplimiento, Riesgos, Seguridad, Privacidad, Calidad y Auditoría comparten una vista coherente de cobertura? ¿puede trazarse una conclusión de auditoría desde la fuente original hasta la evidencia probada?

Si la respuesta requiere abrir cinco matrices incompatibles, el problema ya no es la falta de marcos. Es la arquitectura de gobierno.

La mejor práctica no consiste en reducir el número de fuentes relevantes. Consiste en dar a cada una el papel que le corresponde y hacer que todas converjan sobre un mismo lenguaje de riesgo, control y evidencia. Así, la regulación define obligaciones, ISO estructura el sistema de gestión, NIST organiza el riesgo, COSO fortalece el control interno e IIA convierte esa arquitectura en aseguramiento independiente. La complejidad permanece en el entorno; deja de multiplicarse dentro de la organización.