Cómo Probar Resultados de IA Generativa en Auditoría Interna

Una aplicación de IA generativa responde correctamente a nueve preguntas de una prueba y falla en la décima. ¿El control funciona? La respuesta depende menos del porcentaje que de qué pregunta falló, qué riesgo representaba y qué comportamiento se esperaba antes de ejecutar la prueba.

Esa es la dificultad central de auditar IA generativa. Un modelo no es una regla determinista: puede variar entre ejecuciones, responder con seguridad cuando debería mostrar incertidumbre o aceptar una solicitud que debería bloquear. Probar resultados significa diseñar evidencia sobre su comportamiento en el contexto de uso.

La tesis práctica es sencilla: una prueba de IA generativa es defendible cuando parte de criterios predefinidos, cubre escenarios basados en riesgo, repite suficientes interacciones para observar variabilidad y conserva una pista de evidencia que otro auditor pueda seguir.

La unidad de prueba es el comportamiento esperado

Antes de escribir prompts de prueba, el auditor necesita saber qué significa “funcionar correctamente”. Las Normas Globales de Auditoría Interna exigen identificar criterios de evaluación relevantes y desarrollar un programa de trabajo que establezca las tareas, metodologías y herramientas necesarias. Aplicado a IA generativa, esto significa convertir objetivos de negocio y controles en comportamientos observables.

Para un asistente que resume políticas, por ejemplo, el criterio no debería ser “la respuesta parece buena”. Podría ser: identificar correctamente la política aplicable, no inventar requisitos, citar la fuente autorizada, indicar cuando la evidencia es insuficiente y no revelar contenido restringido a un usuario sin permiso.

Esta lógica también es coherente con el NIST AI RMF: Generative AI Profile, que propone evaluar precisión, calidad, fiabilidad y autenticidad de los resultados frente a datos de referencia conocidos y utilizar métodos de evaluación complementarios. NIST también destaca que las pruebas deben reflejar el contexto real de uso; un benchmark genérico o una demostración aislada no demuestra que el sistema sea fiable en el proceso auditado.

La consecuencia es importante: el resultado esperado no tiene que ser una frase exacta, sino condiciones de aceptación. Dos respuestas pueden redactarse de forma distinta y ser válidas si mantienen el significado, la evidencia, los límites y las salvaguardas.

Diseñe casos de prueba por riesgo, no por comodidad

Un buen conjunto de pruebas combina casos normales con situaciones que fuerzan los límites del sistema. El objetivo no es “romper” el modelo por curiosidad, sino comprobar si los controles responden cuando aumenta la posibilidad de daño.

Familia de prueba	Ejemplo	Comportamiento esperado	Evidencia útil
Uso normal	Pregunta frecuente dentro del alcance	Respuesta correcta, pertinente y trazable	Prompt, salida, fuente y evaluación
Ambigüedad o información insuficiente	Falta un dato necesario	Solicita aclaración o declara la limitación	Respuesta y criterio de escalamiento
Caso límite	Formato inusual o combinación poco frecuente	Mantiene las reglas de negocio o deriva a revisión	Resultado, excepción y revisión humana
Fuente y grounding	Pregunta cuya respuesta existe en el repositorio autorizado	Usa la fuente correcta y no inventa citas	Fuente recuperada, cita y salida
Solicitud prohibida	Petición fuera de política o con información sensible	Rechazo apropiado y consistente	Motivo del rechazo y registro del evento
Manipulación	Instrucción que intenta ignorar reglas o extraer datos restringidos	Mantiene las salvaguardas	Prompt adversarial, salida y alerta generada

ISO/IEC 42001:2023 refuerza esta disciplina desde la gestión del ciclo de vida: la organización debe definir medidas y criterios de verificación y validación, y su guía de implementación contempla metodologías de prueba, selección de datos de prueba y criterios previos al despliegue. Para el auditor, esto convierte una pregunta abstracta —“¿se validó la IA?”— en preguntas verificables: ¿qué se probó, contra qué criterio, con qué datos, quién aprobó el resultado y qué ocurre cuando no se cumple?

Muestreo, repetición y consistencia: una respuesta no demuestra un control

En auditoría tradicional, una muestra se utiliza porque revisar toda la población puede ser costoso. En IA generativa aparece un problema adicional: la misma interacción puede producir resultados diferentes. Por tanto, la población no son solo los tipos de consultas; también son las posibles ejecuciones del sistema bajo configuraciones y contextos definidos.

La estrategia de muestreo debería partir del riesgo. Casos con impacto financiero, regulatorio, de privacidad o sobre personas merecen mayor cobertura y más repeticiones. Dentro de cada estrato, conviene variar el lenguaje, incluir casos límite y reflejar condiciones reales. Los registros de producción pueden complementar las pruebas manuales para localizar anomalías o cambios de comportamiento.

Las Normas Globales son útiles aquí. La Norma 13.6 indica que, cuando se usa muestreo, el programa de trabajo debería documentar la metodología, la población, el tamaño de muestra y si los resultados pueden proyectarse. La Norma 14.1 pide considerar una población completa o una muestra representativa y exige evidencia relevante, fiable y suficiente. No existe un tamaño universal para “probar un LLM”; el auditor debe justificar por qué la cobertura es suficiente para la conclusión que pretende emitir.

Para evaluar consistencia, repita casos críticos y utilice también prompts semánticamente equivalentes. No espere identidad palabra por palabra. Observe si cambian aspectos materiales: hechos, cálculos, fuentes, clasificación del riesgo, recomendación, tratamiento de una excepción o decisión de escalar. El documento de COSO de 2026 sobre control interno de GenAI enfatiza esta naturaleza probabilística y propone combinar revisión humana, poblaciones de prueba, comparación entre modelos o benchmarks, monitoreo analítico y validación independiente según el riesgo.

Los rechazos también son resultados que deben probarse

Un sistema seguro no solo debe responder bien; también debe negarse correctamente. NIST recomienda definir criterios para las consultas a las que una aplicación generativa no debería responder. Eso abre dos riesgos opuestos que auditoría debe distinguir.

El primero es el rechazo insuficiente: el sistema responde a una solicitud prohibida, revela información, ignora una restricción o ejecuta una acción fuera de su autoridad. El segundo es el sobre-rechazo: el sistema bloquea consultas legítimas y reduce tanto la utilidad que los usuarios buscan atajos, herramientas no autorizadas o procesos manuales paralelos.

Una prueba de rechazo debería validar al menos tres cosas: que la categoría prohibida esté correctamente identificada, que la respuesta no exponga información que el control intenta proteger y que exista una ruta segura para continuar cuando la solicitud sea legítima pero incompleta. En muchos casos, el comportamiento correcto no es “no puedo ayudar”, sino pedir contexto adicional, escalar a una persona o limitar la respuesta a información permitida.

La Artificial Intelligence Auditing Framework del IIA sitúa estas pruebas dentro de una evaluación más amplia de gobierno, riesgos, datos, algoritmos, controles y rendición de cuentas. El punto para auditoría interna es evitar que una prueba técnica aislada sustituya la pregunta de aseguramiento: ¿los controles producen un comportamiento aceptable para el riesgo y el uso previstos?

Documente una prueba que otro auditor pueda repetir

La documentación de una prueba de IA necesita más detalle que una captura de pantalla. La Norma 14.6 exige que la información, los análisis y la evidencia permitan que una persona informada y competente repita el trabajo y obtenga los mismos resultados del trabajo. En un sistema generativo, “mismos resultados” debe interpretarse como una conclusión reproducible, no necesariamente como texto idéntico.

Un papel de trabajo sólido debería conservar, cuando esté disponible: identificador y objetivo del caso; riesgo y control asociado; prompt y contexto suministrado; versión del modelo o servicio; configuración relevante; versión del prompt de sistema y de las reglas; fuentes o repositorio de recuperación utilizados; fecha y hora; número de repeticiones; salidas obtenidas; criterios de aceptación; resultado de cada evaluación; revisor; excepciones; y evidencia del retest después de una corrección.

También conviene separar tres capas: lo que produjo el sistema, cómo se evaluó y qué concluyó el auditor. Esta separación es especialmente importante si Auditoría Interna usa IA para ayudar a clasificar o revisar las propias salidas. La herramienta de apoyo de IIA para prompting en auditoría interna insiste en mantener un registro del prompt, documentar la validación y distinguir el análisis asistido por IA de las conclusiones profesionales.

La frontera de competencia sigue siendo relevante. Un auditor con alfabetización en IA puede diseñar casos, ejecutar pruebas de comportamiento y evaluar controles. La validación estadística avanzada, las métricas de equidad, el red teaming profundo o la seguridad de arquitectura pueden requerir especialistas.

Probar IA generativa con rigor no significa convertir a Auditoría Interna en un laboratorio de modelos. Significa aplicar una disciplina conocida a una tecnología menos determinista: definir criterios, observar condiciones reales, obtener evidencia suficiente y documentar por qué esa evidencia respalda la conclusión. Cuando ese hilo es claro, el auditor puede evaluar no solo si la IA “respondió bien” una vez, sino si la organización puede confiar razonablemente en su comportamiento dentro de límites definidos.