RAG explicado para auditores internos

Auditoría interna crea un asistente para consultar su metodología. La herramienta responde en segundos, cita un procedimiento interno y parece mucho más fiable que un chatbot general. El problema aparece cuando el procedimiento citado fue sustituido seis meses antes.

La respuesta puede estar perfectamente “fundamentada” y, aun así, ser incorrecta.

Esa es la idea que un auditor necesita retener sobre retrieval-augmented generation (RAG): conectar un modelo de lenguaje con conocimiento empresarial puede reducir algunos problemas de los LLM, pero también desplaza parte del riesgo hacia las fuentes, los permisos, la recuperación y la atribución. RAG no convierte automáticamente una respuesta en evidencia confiable. Convierte la cadena de conocimiento que produce esa respuesta en algo que puede —y debe— gobernarse y probarse.

RAG no enseña nuevos hechos al modelo: le entrega contexto en el momento de responder

NIST define RAG como un tipo de sistema de IA generativa en el que el modelo se combina con un sistema separado de recuperación de información o base de conocimiento. Ante una consulta, el sistema identifica información relevante y la incorpora al contexto que recibe el modelo para formular la respuesta.

La diferencia frente a un LLM utilizado de forma aislada es importante. El modelo no necesita “memorizar” la política de gastos, el manual de auditoría o la norma interna. Puede recuperar el contenido aplicable cuando el usuario hace la pregunta.

En una arquitectura empresarial típica, el proceso se parece a esto:

Se incorporan fuentes como políticas, procedimientos, estándares, contratos, manuales o informes.
Los documentos se preparan y dividen en fragmentos que puedan recuperarse de manera útil.
Se crea un índice de búsqueda. Con frecuencia se utilizan embeddings y una base vectorial para buscar por similitud semántica, aunque RAG no exige una tecnología de búsqueda concreta.
El usuario formula una consulta.
El sistema recupera los fragmentos que considera más relevantes.
Esos fragmentos se agregan al contexto del LLM, junto con instrucciones sobre cómo responder.
El modelo genera la respuesta y la aplicación puede mostrar referencias o citas a las fuentes recuperadas.

La investigación que popularizó el término RAG, publicada por Lewis y otros en 2020, combinó memoria del modelo con memoria externa recuperable. La implicación práctica es clara: el conocimiento puede actualizarse fuera del modelo. Cambiar una política no exige necesariamente reentrenar el LLM, sino gobernar repositorio y recuperación.

El valor empresarial está en conectar el lenguaje con conocimiento controlado

Para auditoría interna, RAG es especialmente atractivo porque gran parte del trabajo depende de conocimiento disperso y cambiante. Una base aprobada podría incluir metodología de auditoría, políticas corporativas, requisitos regulatorios, catálogos de riesgos y controles, informes previos, guías internas o material de formación.

Esto habilita casos como comparar un control con la metodología vigente, localizar criterios para un programa de trabajo o responder preguntas sobre políticas con referencia al documento fuente. Pero existe una distinción crítica: RAG mejora el acceso al conocimiento; no garantiza su calidad ni la corrección de la respuesta.

Las Normas Globales de Auditoría Interna ofrecen una conexión útil. La Norma 14.1 exige que la información utilizada para análisis y evaluación sea relevante, fiable y suficiente. Si una herramienta RAG se usa para apoyar un trabajo, el auditor no puede sustituir esos atributos por una interfaz convincente. Debe comprender qué fuente fue recuperada, si estaba vigente, si era aplicable y si el sistema omitió información material.

Una cita demuestra de dónde tomó contexto el sistema. No demuestra, por sí sola, que recuperó la mejor fuente ni que interpretó correctamente lo recuperado.

RAG cambia la superficie de riesgo

Un LLM aislado concentra gran parte de la preocupación en la generación. En RAG, los puntos de fallo se distribuyen a lo largo de una cadena.

Etapa	Qué puede fallar	Pregunta de auditoría
Fuentes	Contenido obsoleto, no autorizado, incompleto o de baja calidad.	¿Quién puede incorporar documentos y cómo se controla su vigencia, procedencia y aprobación?
Recuperación	El sistema trae fragmentos irrelevantes o no recupera información crítica.	¿Se prueba la relevancia y cobertura con preguntas representativas y respuestas conocidas?
Acceso	Un usuario recupera contenido que no debería poder consultar.	¿Los permisos del repositorio se respetan también durante la búsqueda y generación?
Generación y citas	El modelo añade afirmaciones no sustentadas, mezcla fuentes o atribuye mal una cita.	¿La respuesta puede rastrearse hasta evidencia fuente y existe validación para usos sensibles?

Estos riesgos no son idénticos a la “alucinación” clásica. El sistema puede inventar incluso con fragmentos correctos, responder desde el fragmento equivocado o recuperar información confidencial fuera del alcance del usuario.

También aparece un riesgo adversarial. NIST AI 100-2e2025 describe la inyección indirecta de instrucciones en sistemas que interactúan con recursos externos, incluido RAG: contenido manipulado dentro de una fuente puede convertirse en una instrucción para el modelo cuando ese contenido es recuperado. Para el auditor, esto transforma el repositorio documental en parte de la superficie de seguridad, no solo en una biblioteca pasiva.

Las citas ayudan, pero deben auditarse como una función separada

Una interfaz con fuentes transmite confianza, pero “tener citas” puede significar desde mostrar documentos recuperados hasta enlazar afirmaciones con fragmentos concretos. La calidad de la atribución debe probarse.

El TREC 2025 Retrieval Augmented Generation Track de NIST es ilustrativo porque evalúa el sistema en varias dimensiones, entre ellas relevancia, completitud de la respuesta, verificación de atribuciones y acuerdo entre respuesta y evidencia. Para auditoría, esa separación es valiosa: una respuesta puede ser fluida y correcta en términos generales, pero incompleta; puede utilizar una fuente relevante sin que esa fuente respalde una afirmación específica; o puede citar correctamente un documento que ya no es el autorizado.

En un entorno corporativo conviene crear preguntas de prueba con resultados esperados, incluyendo versiones conflictivas, términos ambiguos, información ausente, permisos distintos y casos en los que la respuesta correcta sea “no hay evidencia suficiente”. Así se observa si recupera lo correcto, evita lo incorrecto, reconoce lo que falta y atribuye cada conclusión a una fuente que realmente la respalda.

Qué debería revisar auditoría interna

Cuando RAG forma parte de un proceso relevante, auditoría puede revisar la cadena de conocimiento mediante seis preguntas:

¿Qué fuentes están autorizadas? Debe existir propiedad clara, criterios de incorporación y reglas para excluir borradores, duplicados o documentos retirados.
¿Cómo se mantiene la vigencia? La fecha de actualización, la versión y la procedencia deberían ser trazables. La orientación de ISO/IEC 42001:2023 sobre recursos de datos, calidad y procedencia ofrece un marco útil para pensar estos controles sin convertir RAG en una lista separada de requisitos.
¿Quién puede recuperar qué? El diseño debe conservar restricciones de acceso y evitar que la capa de IA se convierta en una vía alternativa hacia información sensible.
¿Cómo se evalúa la recuperación? Un equipo debería medir el desempeño con consultas reales, incluyendo casos límite, y analizar fallos sistemáticos por fuente, idioma, formato o tipo de pregunta.
¿Cómo se valida la respuesta? Para usos de mayor impacto, las citas deben abrir la fuente aplicable, el usuario debe poder revisar el contexto y debe existir una expectativa clara de verificación humana.
¿Qué queda registrado? Consultas, documentos recuperados, versión del sistema, respuestas, retroalimentación y cambios relevantes permiten investigar incidentes y demostrar cómo funcionó la herramienta en un momento determinado.

Si la propia función de auditoría interna utiliza RAG, la Norma 10.3 de las Normas Globales también resulta pertinente: el Director de Auditoría Interna debe procurar tecnologías apropiadas para apoyar el proceso, evaluar regularmente su uso y coordinar su implementación con tecnología de la información y seguridad de la información. En otras palabras, usar una solución de conocimiento no elimina la responsabilidad profesional sobre la herramienta.

El control decisivo no está en el chatbot, sino en la cadena de conocimiento

RAG suele venderse como una respuesta a las limitaciones de los LLM: conocimiento privado, información actualizable, mejores respuestas y citas. Todo eso puede ser cierto. Pero para auditoría la pregunta más importante es otra: ¿podemos confiar en la cadena que conecta la fuente con la respuesta?

La cadena incluye qué entró al repositorio, qué versión era vigente, qué permisos se aplicaron, qué recuperó el sistema, qué quedó fuera y qué evidencia respalda la respuesta. Cuando está gobernada, RAG puede convertir conocimiento disperso en asistencia contextual y trazable. Cuando no, una cita elegante puede hacer que un error parezca más convincente.

La oportunidad para auditoría interna no consiste en aprender a construir una base vectorial. Consiste en reconocer que RAG convierte el conocimiento empresarial en una dependencia operativa del sistema de IA. Y una dependencia que afecta decisiones, controles o evidencia merece criterios, pruebas y responsabilidad claros.