Cómo construir un programa de trabajo para auditar IA

Un programa de auditoría de inteligencia artificial puede parecer completo y, aun así, ser imposible de ejecutar. Basta con reunir decenas de preguntas sobre sesgo, privacidad, ciberseguridad, explicabilidad, terceros y supervisión humana para producir una lista extensa. El problema aparece al final: el equipo no puede demostrar qué riesgo cubría cada prueba, qué evidencia era necesaria ni cómo los resultados sostienen una conclusión.

La calidad de un programa de auditoría de IA no depende de cuántos temas contiene. Depende de su trazabilidad.

En este artículo, “programa de auditoría de IA” se refiere al programa de trabajo de un trabajo de auditoría interna, no al plan anual de auditoría. Esa distinción importa porque las Normas Globales de Auditoría Interna utilizan precisamente el término programa de trabajo en la Norma 13.6.

Un programa de IA no debe comenzar con una checklist

Las Normas Globales proporcionan la disciplina profesional. La Norma 13.2 exige comprender la actividad bajo revisión y evaluar los riesgos relevantes; la Norma 13.4 exige identificar criterios de evaluación apropiados; la Norma 13.5 exige considerar los recursos necesarios; y la Norma 13.6 exige desarrollar y documentar un programa de trabajo que permita alcanzar los objetivos del trabajo.

En sus requisitos, la Norma 13.6 establece que el programa debe basarse en la información obtenida durante la planificación e identificar los criterios, las tareas, las metodologías y herramientas, y los auditores asignados. También requiere su revisión y aprobación antes de la implementación. En las consideraciones para la implementación, el IIA explica que los riesgos y controles pueden vincularse con el enfoque de pruebas y, posteriormente, con los hallazgos y conclusiones. Esa diferencia entre requisito y orientación es importante: la trazabilidad es una forma práctica de construir un programa sólido, no una plantilla obligatoria impuesta por la Norma.

Para el contenido específico de IA, The IIA's Artificial Intelligence Auditing Framework, 2nd Edition aporta una segunda capa. El marco organiza la materia alrededor de gobierno, gestión y auditoría interna, y propone consideraciones sobre estrategia, responsabilidades, riesgo, datos, acceso, ciberseguridad, terceros, políticas, pruebas y monitoreo. El propio IIA presenta su guía práctica como un punto de partida que debe adaptarse al contexto de cada organización.

La combinación es útil: las Normas indican cómo debe planificarse y ejecutarse el trabajo; el marco de IA ayuda a decidir qué riesgos y controles vale la pena examinar.

Empieza por la pregunta de aseguramiento

Antes de redactar procedimientos, define qué decisión debe poder tomar el lector del informe.

Un objetivo débil sería: “revisar los controles de inteligencia artificial”. No especifica qué se quiere concluir.

Un objetivo más útil podría ser:

Evaluar si la organización identifica, aprueba, opera y monitorea los usos materiales de IA mediante responsabilidades, criterios de riesgo y controles que permitan mantener las exposiciones relevantes dentro de niveles aceptados.

Ese objetivo obliga a definir el alcance. ¿La auditoría cubre el gobierno de IA de toda la organización, un portafolio de casos de uso, un proceso que utiliza IA, una aplicación concreta o un proveedor? También obliga a decidir qué queda fuera. Una revisión de gobierno puede evaluar inventario, propiedad, políticas y escalamiento sin pretender validar matemáticamente un modelo.

La pregunta de aseguramiento determina después los riesgos prioritarios. Por ejemplo, para un sistema de IA utilizado en decisiones de clientes, podrían ser relevantes la clasificación incorrecta del caso de uso, datos inadecuados, acceso excesivo, decisiones no revisadas, cambios sin aprobación o monitoreo insuficiente. Para un asistente generativo interno, el foco podría desplazarse hacia confidencialidad, permisos, fuentes, exactitud, uso aceptable y validación humana.

Construye una cadena que pueda seguirse en ambos sentidos

Un programa práctico puede diseñarse con seis elementos enlazados:

Elemento	Pregunta de diseño	Ejemplo en una auditoría de IA	Si falta
Objetivo	¿Qué queremos concluir?	¿La organización controla los usos materiales de IA?	Las pruebas no convergen en una conclusión.
Riesgo	¿Qué podría impedir el objetivo?	Casos de uso no identificados o mal clasificados.	El programa se convierte en una lista genérica.
Control esperado	¿Qué debería ocurrir para reducir el riesgo?	Todo caso de uso tiene propietario, clasificación y aprobación.	No existe un estado esperado contra el cual evaluar.
Evidencia	¿Qué demostraría diseño y operación?	Inventario, aprobaciones, registros de cambios y excepciones.	La solicitud documental no prueba nada por sí sola.
Procedimiento	¿Cómo verificaremos la evidencia?	Reconciliar fuentes, muestrear casos y volver a ejecutar verificaciones.	El equipo confunde inspección con aseguramiento.
Conclusión	¿Qué resultado permite sostener la prueba?	El proceso identifica y aprueba de forma consistente los casos materiales.	El hallazgo queda desconectado del objetivo.

La prueba de calidad es sencilla: desde una conclusión debería ser posible retroceder hasta la evidencia, el procedimiento, el control, el riesgo y el objetivo. Y desde cada objetivo debería poder avanzarse hasta pruebas concretas.

Seis módulos que cubren gran parte del riesgo de IA

No existe un programa universal, pero seis módulos ofrecen una base razonable para muchas auditorías de IA. Deben ajustarse al tipo de sistema, impacto, jurisdicción, etapa del ciclo de vida y madurez organizacional.

Área	Riesgo principal	Control esperado	Evidencia inicial
Gobierno y responsabilidad	Decisiones de IA sin dueño ni supervisión.	Roles, foros de decisión y escalamiento definidos.	Mandatos, RACI, actas, políticas, reportes al consejo.
Inventario y clasificación	Usos de IA fuera del proceso de gobierno.	Inventario completo y clasificación basada en riesgo.	Inventario, compras, SaaS, arquitectura, evaluaciones de riesgo.
Ciclo de vida y cambios	Despliegues o modificaciones sin revisión adecuada.	Aprobaciones y controles de cambio proporcionales al riesgo.	Gates, expedientes de aprobación, pruebas, versiones, cambios.
Datos, acceso y terceros	Datos inapropiados, acceso excesivo o dependencia no controlada.	Requisitos de datos, acceso y terceros definidos y monitoreados.	Linaje, permisos, contratos, evaluaciones de proveedor, registros.
Desempeño y supervisión humana	Resultados erróneos o decisiones automatizadas sin desafío efectivo.	Métricas, límites, revisión humana y manejo de excepciones.	Resultados de pruebas, métricas, revisiones, override, casos escalados.
Monitoreo e incidentes	Deterioro, incidentes o riesgos emergentes no detectados.	Monitoreo, alertas, respuesta y reevaluación periódica.	Dashboards, logs, incidentes, acciones correctivas, revisiones.

El marco del IIA ayuda a poblar estos módulos, pero no sustituye el juicio del auditor. Una organización que compra un modelo de un tercero, por ejemplo, no necesita el mismo programa que otra que entrena modelos internamente. Un agente con capacidad de ejecutar transacciones exige pruebas distintas de un chatbot informativo.

Diseña la evidencia antes de empezar el trabajo de campo

Una solicitud de evidencia eficaz no es “envíe toda la documentación de IA”. Debe anticipar qué prueba se realizará.

Para comprobar la completitud del inventario, por ejemplo, puede solicitarse el inventario oficial, la lista de aplicaciones SaaS, compras de tecnología, registros de proveedores y determinadas categorías de gasto. El procedimiento no consiste en leer esos documentos por separado, sino en reconciliar poblaciones y analizar excepciones.

Para comprobar la aprobación de casos de uso, puede seleccionarse una muestra desde el inventario y rastrear cada elemento hasta su propietario, evaluación de riesgo, aprobación y condiciones impuestas. Después puede hacerse la prueba inversa: seleccionar soluciones desde compras o arquitectura y verificar que aparezcan en el inventario.

Para comprobar monitoreo, las presentaciones de un comité son evidencia débil si no se conectan con datos operativos. Conviene rastrear métricas, alertas o incidentes hasta decisiones, responsables y acciones posteriores.

La Norma 14.1 refuerza este enfoque al exigir que la información empleada para el análisis y la evaluación sea relevante, fiable y suficiente. En IA, esto vuelve especialmente importante corroborar afirmaciones de la dirección con registros del sistema, datos, configuraciones o evidencia independiente cuando sea posible.

No escribas pruebas que tu equipo no puede ejecutar

Un programa de trabajo también es una decisión de recursos. La Norma 13.5 exige considerar si los recursos humanos, financieros y tecnológicos son apropiados y suficientes para lograr los objetivos.

Esto evita un error frecuente: incluir procedimientos como “validar la ausencia de sesgo”, “confirmar la robustez del modelo” o “realizar pruebas adversariales” sin definir método, criterio, datos, competencia ni especialista responsable. Esas frases parecen técnicas, pero no son procedimientos auditables.

El auditor generalista puede evaluar gobierno, responsabilidades, inventario, aprobaciones, políticas, evidencia de validación, monitoreo y la forma en que la organización gestiona excepciones. Pruebas profundas de desempeño del modelo, equidad estadística, seguridad adversarial o arquitectura especializada pueden requerir apoyo de ciencia de datos, ciberseguridad, privacidad o asesoría jurídica.

Involucrar especialistas no debilita la auditoría. Lo importante es que el equipo de auditoría conserve la pregunta de aseguramiento, defina qué evidencia necesita del especialista y explique cómo esa evidencia afecta la conclusión.

El mejor programa termina donde empezó

Un programa de auditoría de IA está bien diseñado cuando el equipo puede responder tres preguntas al cierre: qué quería concluir, qué evidencia obtuvo y por qué esa evidencia es suficiente para sostener la conclusión.

La tecnología cambiará. También cambiarán los riesgos, los proveedores y las regulaciones. La estructura profesional es más estable: objetivo, riesgo, criterio, control, evidencia, procedimiento y conclusión.

Por eso, el programa más útil no es el que contiene más controles de IA. Es el que convierte un tema complejo en una cadena de aseguramiento clara, ejecutable y revisable.