Cómo auditar una política de IA

Una organización puede tener una política de inteligencia artificial aprobada por la alta dirección, publicada en la intranet y aceptada por miles de empleados. Aun así, puede permitir que se cargue información confidencial en herramientas no autorizadas, que se adquieran funciones de IA sin evaluación de riesgos o que las excepciones se resuelvan de manera informal.

En ese escenario, la política existe, pero el control no necesariamente funciona.

Para auditoría interna, la pregunta útil no es “¿hay una política de IA?”, sino “¿la política dirige de forma efectiva las decisiones y comportamientos relacionados con la IA?”. Esa diferencia cambia el enfoque del trabajo: del documento a su diseño, comunicación, implementación, monitoreo y cumplimiento.

El error de auditar el documento y no el sistema

Una revisión superficial suele comprobar que la política existe, tiene propietario, fue aprobada y sigue vigente. Son verificaciones necesarias, pero insuficientes.

Una política es dirección de la administración. Para convertirse en control efectivo debe traducirse en responsabilidades, procedimientos, decisiones y controles observables. Si prohíbe introducir datos sensibles en determinados servicios de IA, el auditor debería poder seguir esa expectativa hasta herramientas autorizadas, formación, restricciones técnicas, excepciones y respuesta ante incumplimientos.

La tesis es sencilla: una política de IA debe auditarse como parte de un sistema de control, no como un documento aislado.

La IA puede entrar por desarrollo interno, servicios contratados, funciones incorporadas en aplicaciones existentes o uso directo por empleados. Una política que solo cubre “modelos desarrollados por TI” puede dejar fuera gran parte de la exposición real.

Qué exige ISO/IEC 42001 y qué aporta COSO

ISO/IEC 42001:2023 trata la política de IA dentro de un sistema de gestión, no como una declaración independiente. La cláusula 5.2 requiere que la alta dirección establezca una política apropiada al propósito de la organización, que sirva de marco para los objetivos de IA, incorpore compromisos aplicables y apoye la mejora continua. También exige que la política exista como información documentada, se comunique dentro de la organización, se relacione cuando corresponda con otras políticas y esté disponible para las partes interesadas pertinentes.

La norma conecta después esa política con otras piezas del sistema. La cláusula 7.3 exige conciencia sobre la política y sobre las consecuencias de no cumplir los requisitos del sistema de gestión de IA. La cláusula 7.4 exige definir las comunicaciones relevantes. La cláusula 8.1 lleva los requisitos a la operación mediante criterios y controles. La cláusula 9.1 exige determinar qué se monitorea y mide, y la cláusula 10.2 exige gestionar no conformidades, causas, acciones correctivas y evidencia de su resultado.

El Anexo A añade controles de referencia sobre políticas de IA, alineación con otras políticas y revisión periódica. Sin embargo, el propio estándar aclara que no todos los controles del Anexo A deben utilizarse automáticamente: su selección se vincula al tratamiento de riesgos y a la declaración de aplicabilidad. Auditar con ISO/IEC 42001 como criterio no convierte el trabajo de auditoría interna en una auditoría de certificación.

COSO aporta otra lente. Su Internal Control—Integrated Framework organiza el control interno en cinco componentes: entorno de control, evaluación de riesgos, actividades de control, información y comunicación, y actividades de monitoreo. La guía de COSO de 2026, Achieving Effective Internal Control Over Generative AI, aplica esa lógica a la IA generativa e insiste en que las políticas de uso aceptable deben estar acompañadas por responsabilidades, competencia, comunicación, mecanismos de rendición de cuentas y monitoreo.

La combinación es útil para el auditor: ISO/IEC 42001 ayuda a definir qué debe existir dentro del sistema de gestión; COSO ayuda a cuestionar si ese diseño está integrado en un sistema de control que funciona.

Cinco pruebas para auditar una política de IA

Un enfoque práctico consiste en evaluar cinco dimensiones conectadas.

Dimensión Pregunta de auditoría Evidencia útil Señales de alerta
Diseño ¿La política cubre las exposiciones reales de la organización y asigna responsabilidades claras? Política aprobada, alcance, matriz de roles, mapa de políticas relacionadas, actas de gobierno Alcance ambiguo, lenguaje aspiracional, ausencia de propietario, contradicciones con privacidad, seguridad o compras
Comunicación ¿Las personas entienden qué pueden hacer, qué no y cuándo deben escalar? Formación por rol, campañas, confirmaciones, guías de uso, preguntas frecuentes, canales de consulta Solo publicación en intranet, formación genérica, empleados que desconocen excepciones o usos prohibidos
Implementación ¿Las reglas se reflejan en procesos, decisiones y tecnología? Inventario de IA, aprobaciones de casos de uso, controles de acceso, configuraciones, due diligence de proveedores, registros de excepciones Herramientas no autorizadas, procesos manuales sin evidencia, controles que dependen solo de buena voluntad
Monitoreo ¿La organización sabe si la política se cumple y si sigue siendo adecuada? Métricas, incidentes, excepciones, pruebas de control, revisiones de gestión, tendencias y reportes No existen métricas, no se analizan violaciones, cambios de proveedores o modelos no disparan revisión
Cumplimiento y mejora ¿El incumplimiento genera una respuesta consistente y aprendizaje? Investigaciones, acciones correctivas, revocaciones de acceso, análisis de causa, actualizaciones de política Excepciones informales, reincidencia sin escalamiento, consecuencias inconsistentes, política nunca actualizada

Estas pruebas evitan exigir a la política detalle técnico que corresponde a procedimientos y, en el extremo contrario, aceptar lenguaje tan general que no pueda convertirse en criterios operativos.

La política no necesita describir cada configuración o umbral. Sí debe dar suficiente dirección para determinar quién decide, qué riesgos requieren tratamiento, qué usos son aceptables y cómo se gestionan las excepciones.

Del texto a la evidencia: cómo ejecutar el trabajo

El auditor puede empezar convirtiendo la política en criterios verificables. Cada obligación importante debería poder vincularse con al menos una evidencia de diseño y una evidencia de operación.

Por ejemplo, si la política establece que los casos de uso de mayor riesgo requieren aprobación antes del despliegue, la auditoría no debería terminar al encontrar un procedimiento de aprobación. Debe seleccionar casos de uso reales y comprobar si fueron evaluados, quién aprobó, qué información recibió, qué condiciones impuso y si esas condiciones fueron implementadas.

Un programa básico puede seguir esta secuencia:

  1. Definir el universo cubierto. Identificar funciones, geografías, tipos de IA y terceros a los que la política pretende aplicar.
  2. Hacer un recorrido de extremo a extremo. Seguir un caso de uso desde la idea o adquisición hasta aprobación, operación, monitoreo y eventual retiro.
  3. Seleccionar muestras con contraste. Incluir usos autorizados, usos de alto impacto, herramientas de terceros, casos con excepción y, cuando sea posible, usos detectados fuera del proceso formal.
  4. Probar controles habilitadores. Verificar formación, accesos, flujos de aprobación, configuraciones, registros, monitoreo y escalamiento.
  5. Buscar evidencia negativa. Comparar inventarios con compras, software corporativo, gastos, accesos o datos de seguridad para detectar IA fuera del marco de gobierno.
  6. Separar diseño de efectividad operativa. Una regla puede estar bien concebida y aun así no ejecutarse de forma consistente.

La evidencia más persuasiva suele aparecer en decisiones reales: solicitudes rechazadas, excepciones condicionadas, accesos bloqueados, incidentes investigados y revisiones motivadas por cambios tecnológicos o regulatorios.

Errores comunes que una auditoría debería revelar

El primer error es confundir comunicación con publicación. Una política disponible no demuestra que los usuarios entiendan sus responsabilidades. El segundo es diseñar una política que dependa exclusivamente del comportamiento humano cuando ciertos riesgos pueden reducirse mediante controles preventivos en herramientas, accesos o procesos de adquisición.

El tercero es no integrar la política con otras reglas corporativas. La IA cruza privacidad, seguridad de la información, propiedad intelectual, recursos humanos, compras, gestión de terceros, desarrollo de sistemas, registros y cumplimiento. Si cada política usa criterios incompatibles, los empleados reciben señales contradictorias.

El cuarto es medir únicamente la finalización de formación. El porcentaje de empleados capacitados puede ser útil, pero dice poco sobre cumplimiento real. Métricas más maduras incluyen excepciones, intentos de uso bloqueados, incidentes, reincidencia, tiempos de resolución, cobertura del inventario y controles vencidos.

El quinto es tratar el cumplimiento como castigo. La exigibilidad también incluye aclarar responsabilidades, corregir causas, mejorar controles y actualizar la política. La guía de COSO sobre IA sitúa la gobernanza y la supervisión dentro de una gestión de riesgos integrada con la estrategia y la ejecución; una política eficaz debe evolucionar cuando cambian el negocio, la tecnología y el riesgo.

Una política efectiva deja huellas

El mejor resultado de una auditoría de política de IA no es confirmar que el documento está bien escrito. Es poder demostrar una cadena coherente entre la intención de la alta dirección y el comportamiento de la organización.

La política debe dejar huellas: en quién puede aprobar, qué herramientas pueden utilizarse, qué datos están restringidos, cómo se revisan los casos de uso, qué se monitorea, cómo se gestionan excepciones y qué ocurre cuando algo falla.

Cuando esas huellas existen y son consistentes, la política funciona como parte del sistema de control. Cuando no existen, el documento puede ser correcto en papel y débil en la práctica.

Para auditoría interna, ese es el cambio de enfoque que importa: no auditar si la organización tiene una política de IA, sino si la política gobierna realmente la IA.

Fuentes