RAG para gestionar el conocimiento de auditoría interna

Un auditor pregunta a un asistente generativo qué criterios debería utilizar para revisar el proceso de compras. La respuesta parece convincente, pero mezcla una política ya sustituida, una práctica de otra unidad y una versión antigua de una guía profesional. El problema no es únicamente que el modelo pueda inventar información. Es que, por sí solo, no sabe qué conocimiento de auditoría está autorizado, vigente y aplicable.

Retrieval-Augmented Generation, o RAG, aborda precisamente esa brecha. En lugar de depender únicamente de lo que un modelo de lenguaje aprendió durante su entrenamiento, un sistema RAG recupera información de una base de conocimiento definida en el momento de la consulta y entrega esos fragmentos al modelo como contexto para generar la respuesta.

Para Auditoría Interna, esto abre una posibilidad especialmente relevante: conectar la IA con la metodología de la función, políticas corporativas, normas profesionales, informes anteriores y guía aprobada. Pero la ventaja no proviene de “conectar todos los documentos”. Proviene de crear una frontera de conocimiento gobernada, trazable y mantenida.

El problema no es solo la alucinación; es el conocimiento sin control

Los modelos generativos pueden producir contenido incorrecto con una apariencia de seguridad. El NIST AI RMF: Generative Artificial Intelligence Profile trata este riesgo como confabulation y también destaca riesgos de privacidad y exposición de información. RAG puede reducir parte de esa incertidumbre al aportar contexto seleccionado, pero no convierte automáticamente una respuesta en correcta.

En Auditoría Interna, la pregunta es más exigente que “¿la respuesta suena razonable?”. Debe incluir cuestiones como: ¿qué versión de la política fue recuperada?, ¿era aplicable al periodo auditado?, ¿el usuario tenía derecho a verla?, ¿la cita respalda realmente la afirmación?, ¿faltó una fuente más relevante?, ¿la respuesta distingue entre un requisito obligatorio y una buena práctica?

Estas preguntas encajan directamente con las Normas Globales de Auditoría Interna. La Norma 9.3 exige metodologías que guíen a la función de manera sistemática y disciplinada. Las Normas 5.1 y 5.2 establecen responsabilidades sobre uso y protección de la información. Las Normas 14.1 y 14.2 requieren trabajar con información relevante, fiable y suficiente, y la Norma 14.6 exige documentación que permita respaldar y reproducir los resultados del trabajo. RAG puede apoyar estos objetivos, pero no sustituirlos.

Qué hace RAG y por qué encaja con Auditoría Interna

Una arquitectura básica puede entenderse como una cadena sencilla:

pregunta del auditor → recuperación de fuentes aprobadas → fragmentos relevantes → modelo de lenguaje → respuesta con referencias.

La diferencia frente a un chatbot genérico es importante. El modelo ya no responde solamente desde su conocimiento paramétrico; recibe material seleccionado desde un repositorio controlado. Esto permite actualizar el contenido sin volver a entrenar el modelo y facilita vincular las respuestas con fuentes concretas.

También conviene distinguir RAG de fine-tuning. El fine-tuning modifica el comportamiento de un modelo mediante entrenamiento adicional. RAG, en cambio, suministra contexto externo en el momento de uso. Para una función de auditoría, donde las políticas cambian, las normas se actualizan y las versiones importan, esa separación suele ser especialmente útil. El fine-tuning puede ayudar a adaptar estilo o patrones de respuesta, pero no sustituye el gobierno documental ni la necesidad de recuperar la fuente vigente.

Una guía de 2026 de IIA Netherlands e ISACA Netherlands sobre IA generativa sitúa RAG como una capacidad para conectar la IA con conocimiento interno, incluyendo políticas e informes previos, y destaca la necesidad de controles de acceso, actualización y calidad. La idea es útil, siempre que se evite interpretar la madurez como una carrera hacia tecnologías más complejas: una solución sencilla, bien gobernada y fiable puede aportar más valor que una arquitectura sofisticada sin control.

Qué debe entrar en la base de conocimiento

No todos los documentos cumplen la misma función. Una base RAG de auditoría debería separar claramente las capas de conocimiento y su autoridad.

Capa de conocimiento	Ejemplos	Uso principal	Punto de gobierno
Metodología de Auditoría Interna	Manual, procedimientos, plantillas, escalas de rating	Guiar cómo se realiza y documenta el trabajo	Propietario, versión y fecha de vigencia
Criterios organizacionales	Políticas, procedimientos, marcos de control, normas internas	Evaluar la actividad bajo revisión	Aplicabilidad por entidad, proceso y periodo
Fuentes externas autorizadas	GIAS, requisitos regulatorios, marcos y guía oficial	Interpretar expectativas y construir criterios	Autoridad, jurisdicción y vigencia
Memoria de auditoría	Informes previos, hallazgos, planes de acción, lecciones aprendidas	Recuperar contexto y antecedentes	Acceso, retención y posible obsolescencia

La distinción importa. Un informe anterior puede aportar contexto, pero no necesariamente constituye un criterio vigente. Una política puede servir como criterio solo si era aplicable al proceso y periodo revisados. Una guía profesional puede representar buena práctica sin convertirse por ello en un requisito obligatorio.

Por eso, el repositorio necesita metadatos operativos, no solo archivos: propietario, versión, fecha efectiva, estado vigente o sustituido, clasificación de información, ámbito de aplicación y reglas de acceso. Sin esa capa, el sistema puede recuperar el documento “más parecido” semánticamente, aunque no sea el correcto desde el punto de vista de auditoría.

RAG no convierte una respuesta en evidencia de auditoría

Este es el límite más importante. Una respuesta generada puede ayudar a localizar información, comparar documentos, proponer hipótesis o resumir criterios. No debe tratarse automáticamente como evidencia.

La evidencia sigue dependiendo de su procedencia, relevancia, fiabilidad y suficiencia. Si RAG recupera una política oficial, la política puede ser una fuente relevante para el trabajo; la síntesis creada por el modelo es una interpretación secundaria que el auditor debe validar. Si el sistema encuentra un informe previo, ese informe puede aportar antecedentes, pero no demuestra por sí mismo la condición actual.

Además, RAG introduce riesgos propios:

Corpus incompleto o desactualizado. La fuente correcta puede no estar indexada o una versión sustituida puede seguir disponible.
Recuperación deficiente. Un mal chunking, metadatos pobres o una consulta ambigua pueden traer fragmentos irrelevantes.
Filtración por permisos. El sistema puede revelar hallazgos, información personal o documentos confidenciales a usuarios no autorizados.
Citas aparentes. Una referencia puede existir y, aun así, no respaldar la afirmación generada.
Prompt injection en documentos. Contenido ingerido puede contener instrucciones maliciosas o manipuladoras que afecten el comportamiento del sistema.

El proyecto experimental descrito en el NIST IR 8579, Initial Public Draft, sobre un chatbot RAG interno, es útil como estudio de caso precisamente porque aborda riesgos como alucinaciones, exposición de datos, accesos no autorizados y prompt injection. Debe leerse como un borrador técnico de NIST y no como una norma obligatoria.

Un patrón mínimo de control para implementar RAG

Antes de ampliar RAG a toda la función, conviene definir controles que hagan el sistema auditable.

Pregunta de control	Práctica mínima	Evidencia que conviene conservar
¿Las fuentes son aprobadas y vigentes?	Propietario, versión, fecha efectiva y retirada de documentos sustituidos	Inventario, historial de cambios y aprobaciones
¿La recuperación respeta permisos?	Aplicar controles de acceso desde el repositorio y probarlos	Matriz de accesos y resultados de pruebas
¿La respuesta es trazable?	Mostrar fuente, sección o ubicación recuperada	Registro de consulta, fragmentos y referencias
¿La recuperación funciona?	Probar preguntas conocidas, casos límite y fuentes similares	Conjunto de pruebas, resultados y defectos
¿Existe validación humana?	Revisión independiente antes de incorporar resultados a papeles de trabajo o informes	Evidencia de revisión y correcciones
¿Puede reconstruirse el uso?	Registrar consulta, fuentes recuperadas, versión del sistema y revisor	Logs y documentación del caso de uso

Un buen piloto no necesita empezar por decisiones complejas. Dos casos suelen ser más útiles: consulta controlada de metodología y búsqueda de antecedentes en informes previos. Ambos permiten medir si el sistema encuentra la fuente correcta, respeta permisos, conserva la trazabilidad y realmente ahorra tiempo.

Las métricas tampoco deberían limitarse a adopción o número de consultas. Conviene observar precisión de recuperación, validez de citas, porcentaje de respuestas que requieren corrección humana, incidentes de acceso indebido, vigencia de las fuentes y tiempo ahorrado. La Norma 10.3 de las GIAS también refuerza la responsabilidad del Director de Auditoría Interna de evaluar la tecnología, formar a los auditores y colaborar con Tecnología de la Información y Seguridad de la Información cuando se implantan nuevos recursos tecnológicos.

RAG puede convertirse en una memoria operativa de Auditoría Interna, pero la madurez no consiste en “chatear con todos los archivos”. Consiste en poder explicar qué fuentes estaban disponibles, por qué eran aplicables, qué versión se recuperó, qué permisos se respetaron y cómo se validó el resultado.

Si la función no puede responder esas preguntas, tiene una herramienta cómoda. Todavía no tiene una capacidad de conocimiento preparada para auditoría.