¿Qué evidencia debe solicitar un auditor de IA?

Un equipo de auditoría puede recibir una política de inteligencia artificial impecable, un inventario extenso y una presentación con métricas tranquilizadoras, y aun así no tener evidencia suficiente para concluir que los controles funcionan.

Ese es uno de los errores más comunes al auditar IA: confundir documentación disponible con evidencia de auditoría.

La evidencia útil debe permitir reconstruir una cadena: qué debía ocurrir, cómo se diseñó el control, qué ocurrió realmente y qué resultados produjo. Una política demuestra intención. Un procedimiento describe diseño. Un log puede demostrar operación. Una métrica, una incidencia o una acción correctiva puede mostrar si el control produjo el resultado esperado.

La pregunta correcta, por tanto, no es “¿qué documentos pedimos?”, sino “¿qué evidencia necesitamos para probar cada riesgo y cada control?”

La evidencia debe responder a una afirmación de auditoría

Las Normas Globales de Auditoría Interna ofrecen el punto de partida metodológico. La Norma 14.1 exige que la información utilizada por auditoría interna sea relevante, fiable y suficiente. La fiabilidad aumenta, entre otros factores, cuando la información se obtiene directamente, proviene de una fuente independiente, se corrobora o procede de un sistema con procesos eficaces de gobierno, gestión de riesgos y control.

La Norma 14.6 añade una prueba práctica especialmente útil: la documentación del trabajo debe permitir que una persona informada y competente pueda repetir el trabajo y llegar a los mismos resultados.

Aplicado a IA, esto cambia la forma de preparar la solicitud de información. No basta con pedir “política de IA”, “evaluación de riesgos” o “resultados de pruebas”. Para cada elemento conviene definir:

qué afirmación queremos probar;
qué población o periodo cubre la evidencia;
quién la generó y desde qué sistema;
qué versión del modelo, aplicación o configuración representa;
cómo la corroboraremos.

Los ejemplos de evidencia de conformidad incluidos en las Normas Globales ayudan a entender qué podría demostrar conformidad, pero no son requisitos obligatorios ni una lista cerrada. El auditor sigue siendo responsable de determinar qué evidencia es apropiada para el objetivo concreto del trabajo.

Primer bloque: gobierno, alcance y decisiones

Antes de entrar en modelos, prompts o métricas, el auditor necesita saber qué sistema está auditando y bajo qué decisiones de gobierno opera.

Una solicitud inicial suele incluir:

Evidencia	Qué debería permitir comprobar	Prueba de auditoría típica
Política de IA y normas relacionadas	Criterios, usos permitidos, responsabilidades y excepciones	Comparar requisitos con prácticas reales y revisar vigencia/aprobación
Inventario de sistemas y casos de uso	Población auditada, propietarios, estado y criticidad	Probar integridad mediante compras, SSO, nube, repositorios o gasto
Roles y decisiones de aprobación	Quién puede aprobar, cambiar, operar y detener el sistema	Rastrear una muestra de decisiones hasta la autoridad correspondiente
Evaluaciones de riesgos e impactos	Riesgos identificados, criterios, tratamiento y grupos afectados	Recalcular una muestra y revisar cambios significativos
Registro de excepciones	Desviaciones aceptadas y controles compensatorios	Verificar aprobación, vencimiento, seguimiento y cierre

ISO/IEC 42001:2023 refuerza esta lógica documental. El estándar exige, entre otros elementos, una política de IA documentada, responsabilidades asignadas y conservación de información documentada sobre evaluaciones de riesgos, tratamientos de riesgos y evaluaciones de impacto. También exige evidencia de resultados de monitoreo y medición dentro del sistema de gestión.

El punto no es convertir ISO/IEC 42001 en una lista automática para cualquier auditoría de IA. Su utilidad está en mostrar qué tipos de registros permiten demostrar que el sistema de gestión no existe solo en el papel.

Segundo bloque: diseño, datos y pruebas antes del despliegue

Una vez establecido el contexto, la siguiente pregunta es si el sistema fue diseñado y validado para el uso que realmente tendrá.

Según el riesgo y la tecnología, el auditor puede solicitar:

requisitos funcionales y criterios de aceptación;
diagramas de arquitectura y flujos de datos;
documentación del modelo, servicio o proveedor utilizado;
fuentes de datos, linaje, procedencia, derechos de uso y controles de calidad;
criterios de selección y preparación de datos;
resultados de entrenamiento, validación y pruebas, cuando corresponda;
pruebas de precisión, robustez, seguridad, sesgo, privacidad o desempeño relevantes al caso de uso;
límites conocidos, supuestos, usos no previstos y condiciones bajo las que el sistema no debe utilizarse;
evidencia de revisión y aprobación previa al despliegue;
evaluación de terceros, contratos, acuerdos de nivel de servicio y responsabilidades sobre cambios.

Aquí conviene evitar otra trampa: un informe de pruebas no demuestra por sí mismo que el sistema desplegado sea el sistema probado. El auditor debe enlazar resultados de validación con versión, configuración, datos, fecha de liberación y aprobación de despliegue.

El NIST AI RMF Playbook resulta útil como orientación no obligatoria. Sus prácticas de documentación incluyen propósito, riesgos, supuestos, datos, resultados de validación, dependencias y planes de monitoreo. En la función Measure, NIST también enfatiza documentar conjuntos de prueba, métricas y herramientas utilizadas en actividades de test, evaluación, verificación y validación.

Tercer bloque: evidencia de que el control operó

Los documentos de diseño dicen lo que debería suceder. La evidencia operativa muestra lo que sí sucedió.

Dependiendo del sistema, el auditor puede pedir:

registros de acceso y privilegios administrativos;
historial de versiones, despliegues y cambios de configuración;
tickets de cambio y aprobaciones;
logs de ejecución, llamadas a modelos, errores y eventos relevantes;
registros de prompts y respuestas cuando sean necesarios y legalmente apropiados;
evidencia de filtros, reglas, límites o guardrails activados;
revisiones humanas, anulaciones, escalaciones y decisiones de intervención;
registros de excepciones y uso fuera del proceso normal;
evidencias de respaldo, continuidad y recuperación cuando sean relevantes;
registros de actividad de proveedores o componentes externos.

La calidad de esta evidencia depende de su trazabilidad. Un archivo exportado manualmente por el propietario del proceso puede ser útil, pero es más persuasivo si auditoría puede reconciliarlo con la fuente, validar la población, conocer la lógica de extracción y comprobar que no se excluyeron eventos relevantes.

Para sistemas generativos, esto puede implicar muestrear sesiones o transacciones. Para modelos predictivos, puede significar reconciliar predicciones con decisiones posteriores. Para agentes, puede requerir reconstruir la secuencia de herramientas utilizadas, permisos, aprobaciones humanas y acciones ejecutadas.

Cuarto bloque: monitoreo, incidencias y resultados

Un sistema puede superar todas las pruebas previas al lanzamiento y degradarse después. Por eso, la evidencia de IA debe cubrir no solo el go-live, sino también el comportamiento posterior.

El auditor debería considerar:

métricas de desempeño y umbrales definidos;
resultados de monitoreo de deriva, calidad, sesgo, seguridad o confiabilidad según el riesgo;
alertas generadas y evidencia de su resolución;
incidentes, problemas, reclamaciones y retroalimentación de usuarios;
análisis de causa raíz;
decisiones de suspender, limitar, reentrenar o reconfigurar el sistema;
acciones correctivas y comprobación de su eficacia;
revisiones periódicas de riesgos e impactos;
informes de gestión y evidencia de seguimiento por los responsables.

COSO publicó en 2026 Achieving Effective Internal Control Over Generative AI, una guía que adapta los cinco componentes del Internal Control—Integrated Framework a GenAI. Su valor para auditoría es práctico: conecta controles, métricas y actividades de monitoreo con evidencia que puede probarse. No sustituye a COSO-ICIF ni pretende cubrir todas las formas de IA; es una aplicación específica a IA generativa.

Solicite paquetes de evidencia, no archivos aislados

Una solicitud madura suele agrupar evidencia que permita comprobar una misma afirmación desde varios ángulos. Por ejemplo, para probar que “solo se despliegan cambios de modelo aprobados” no pediríamos únicamente el procedimiento de gestión de cambios.

Pediríamos el procedimiento, la población de cambios del periodo, el historial técnico de versiones, las aprobaciones y una muestra de despliegues. Después compararíamos esas fuentes.

Ese enfoque también reduce solicitudes indiscriminadas de grandes volúmenes de datos. La auditoría no necesita copiar todos los prompts, todos los datos de entrenamiento o todos los logs “por si acaso”. Debe solicitar lo necesario para el objetivo del trabajo, considerando confidencialidad, privacidad, propiedad intelectual y seguridad de la información.

Una forma simple de revisar cada solicitud es aplicar cinco preguntas:

¿Qué riesgo o control estoy probando?
¿La evidencia cubre la población y el periodo correctos?
¿Puedo identificar fuente, fecha y versión?
¿Puedo corroborarla con otra evidencia o con acceso directo?
¿Sería suficiente para que otro auditor competente reprodujera mi conclusión?

La mejor lista de evidencia para una auditoría de IA no es la más larga. Es la que hace visible la cadena entre criterio, control, operación y resultado. Cuando esa cadena existe, los documentos dejan de ser un repositorio y se convierten en una base defendible para el juicio profesional.