Cómo auditar un sistema RAG

Un asistente corporativo responde correctamente a una pregunta sobre una política y muestra una cita. La demostración parece convincente. Pero una auditoría de RAG no debería concluir que el sistema está controlado por ver una buena respuesta.

En un sistema de retrieval-augmented generation (RAG), la respuesta depende de una cadena: las fuentes que entran al corpus, cómo se fragmentan e indexan, qué puede recuperar cada usuario, qué documentos recupera realmente una consulta, qué contexto recibe el modelo y si la salida permanece fiel a evidencia autorizada y vigente.

La tesis para auditoría es simple: un RAG no está controlado porque cite fuentes; está controlado cuando la cadena completa de evidencia puede demostrar que recupera información correcta, autorizada, actual y trazable, y que el sistema responde de forma predecible cuando esa evidencia no existe.

RAG cambia el lugar donde ocurre el riesgo

Un modelo de lenguaje general genera una respuesta a partir de sus parámetros y del contexto que recibe. RAG añade una etapa previa: busca información en un repositorio y entrega al modelo fragmentos que deberían servir como base para responder.

Eso puede mejorar el grounding, pero también crea nuevas superficies de riesgo. Un documento obsoleto puede ser recuperado antes que la versión vigente. Un filtro de permisos mal aplicado puede exponer contenido restringido. Un fragmento mal construido puede eliminar el contexto necesario para interpretar una norma. Una cita puede apuntar a un documento real sin respaldar la afirmación realizada. Y un texto malicioso almacenado en una fuente puede intentar alterar las instrucciones del sistema mediante inyección indirecta de prompts.

Por eso el objeto de auditoría no es solo el LLM. Incluye, como mínimo, el corpus, el pipeline de ingestión e indexación, metadatos y permisos, embeddings o mecanismos de búsqueda, filtros, ranking o reranking, construcción del contexto, instrucciones del sistema, generación, citas, monitoreo y gestión de cambios.

Empiece por la cadena de evidencia, no por el modelo

Las Normas Globales de Auditoría Interna ofrecen un criterio útil para diseñar las pruebas. La Norma 14.1 exige recopilar información relevante, fiable y suficiente y evaluar si proporciona una base razonable para hallazgos y conclusiones. Sus consideraciones para la implementación también señalan la actualidad y la corroboración como factores que fortalecen la fiabilidad. La Norma 14.6 exige documentar el trabajo de manera que una persona informada y competente pueda repetirlo y obtener resultados equivalentes.

Aplicado a RAG, esto significa que el auditor debe poder reconstruir la ruta entre una consulta, los fragmentos recuperados y la respuesta. Un pantallazo de una conversación rara vez es evidencia suficiente.

ISO/IEC 42001:2023 aporta el marco de gestión: riesgos, tratamiento, controles, documentación, ciclo de vida, datos, proveedores, monitoreo y cambios. No prescribe una lista específica para RAG. Además, sus controles de referencia deben aplicarse mediante el proceso de tratamiento de riesgos y la declaración de aplicabilidad; no todos los controles del Anexo A son automáticamente obligatorios para todos los sistemas. El criterio de auditoría debe partir de los riesgos, requisitos externos y controles que la organización haya determinado como necesarios.

NIST complementa esta visión con medidas específicas para IA generativa. Su perfil NIST AI 600-1 incluye acciones sobre procedencia de datos, revisión de fuentes y citas, verificación del grounding, monitoreo continuo y riesgo de prompt injection. A septiembre de 2026, NIST indica que AI RMF 1.0 está en revisión, por lo que conviene registrar la versión exacta utilizada como criterio.

Siete superficies de control que debe probar

Superficie	Qué puede fallar	Evidencia útil	Procedimiento de auditoría
Fuentes y corpus	Fuentes no aprobadas, incompletas, duplicadas o de baja calidad	Inventario de fuentes, propietarios, procedencia, criterios de incorporación	Muestrear fuentes y rastrear su aprobación, origen, integridad y cobertura
Recuperación	El sistema recupera contenido irrelevante o pierde el fragmento correcto	Configuración de chunking, búsqueda, ranking, conjunto de pruebas y logs	Ejecutar consultas con respuesta conocida y comparar documentos esperados vs. recuperados
Permisos	Usuarios reciben fragmentos que no están autorizados a ver	Matriz de acceso, grupos, filtros de metadatos, logs de identidad	Repetir consultas con identidades y roles distintos y comprobar que el contenido restringido nunca entra al contexto
Citas y grounding	La cita existe, pero no sustenta la afirmación	Texto recuperado, respuesta, referencias y trazas	Verificar afirmación por afirmación si la cita corresponde y realmente soporta la salida
Prompt injection	Una instrucción incluida en una fuente altera el comportamiento del sistema	Controles de ingestión, separación de instrucciones y contenido, pruebas de seguridad	Usar casos adversariales controlados y confirmar que el contenido recuperado no puede redefinir instrucciones ni provocar divulgación indebida
Frescura	El índice conserva versiones antiguas o no refleja eliminaciones	Fechas de fuente, versionado, SLA de sincronización, historial de indexación	Actualizar, sustituir y retirar documentos de prueba y medir cuándo el cambio se refleja en la recuperación
Validación de salida	El sistema responde con confianza cuando no dispone de evidencia suficiente	Reglas de abstención, evaluaciones, feedback, incidentes y monitoreo	Probar preguntas con respuesta, sin respuesta, ambiguas y contradictorias; evaluar exactitud, abstención y escalamiento

La tabla no es una checklist universal. Un RAG que apoya decisiones regulatorias necesita una profundidad distinta a un asistente interno de baja criticidad. El alcance debería reflejar el uso previsto, los usuarios, el impacto de un error, la sensibilidad de las fuentes y las dependencias de terceros.

Cómo probar un RAG sin convertir la auditoría en un laboratorio de IA

La prueba más útil suele empezar con un conjunto de referencia diseñado por riesgo, no con preguntas improvisadas durante una demo. Debe cubrir las decisiones y fallos que importan para el caso de uso.

Incluya consultas con respuesta conocida, preguntas para las que el corpus no contiene respuesta, documentos conflictivos, versiones antiguas y vigentes, contenido restringido a ciertos roles y casos en los que una fuente contenga instrucciones no confiables. Para cada caso, defina de antemano qué evidencia debería recuperar el sistema y qué comportamiento sería aceptable: responder, abstenerse, pedir aclaración o escalar.

Después, conserve la trazabilidad. Para cada ejecución registre versión del corpus o índice, identidad o rol del usuario, consulta, fragmentos recuperados, puntuaciones o ranking cuando estén disponibles, versión de configuración, respuesta, citas y resultado de la evaluación. Si el sistema cambia con frecuencia, la reproducibilidad absoluta puede no ser realista; lo que sí debe existir es evidencia suficiente para explicar qué se probó, bajo qué configuración y contra qué criterio.

Algunas pruebas requieren una extensión de capacidad tecnológica, pero no todas exigen un especialista. Un auditor interno con suficiente alfabetización en IA puede revisar gobierno del corpus, propiedad, permisos, cambios, logs y monitoreo. Un auditor con mayor profundidad técnica puede diseñar pruebas estructuradas de recuperación, citas y comportamiento adversarial. Pruebas de penetración, explotación avanzada o evaluación profunda de arquitectura de seguridad normalmente requieren apoyo especializado.

Métricas útiles, sin convertirlas en números mágicos

RAG permite medir partes de la cadena, pero una cifra aislada no demuestra control. Entre los indicadores útiles están la proporción de consultas en las que aparece el documento correcto dentro de los primeros resultados, la validez de las citas, la proporción de afirmaciones efectivamente respaldadas, el tiempo de propagación de cambios, la tasa de abstención cuando falta evidencia y la capacidad para contener casos de prompt injection.

Para permisos, el criterio suele ser más estricto: una tasa promedio favorable no compensa una filtración de contenido sensible. El auditor debe definir qué errores son tolerables, cuáles son críticos y qué umbral se relaciona con el riesgo y el uso previsto.

También conviene separar calidad de recuperación de calidad de respuesta. Una respuesta correcta obtenida a partir de documentos equivocados puede ser accidental. Una recuperación correcta seguida de una conclusión inventada es otro tipo de fallo. Medir ambas etapas evita que un buen resultado final oculte un control defectuoso.

La conclusión debe hablar de confianza, no de demostraciones

Un hallazgo útil sobre RAG conecta criterio, condición, causa, riesgo y acción. “La IA puede alucinar” es demasiado genérico. “El índice conserva políticas sustituidas durante varios días, lo que permite que el asistente cite versiones no vigentes en respuestas sobre gastos” identifica una condición auditable y un riesgo concreto.

La conclusión debería responder si el sistema puede demostrar, de forma repetible, que usa fuentes gobernadas, aplica permisos antes de exponer contenido al modelo, recupera evidencia relevante, mantiene la frescura, resiste manipulación razonablemente previsible, cita con fidelidad y valida la salida de acuerdo con el impacto del caso de uso.

RAG reduce algunos riesgos de un LLM aislado, pero no elimina la necesidad de escepticismo profesional. La mejor evidencia no es que el chatbot “parezca saber”. Es que la organización puede reconstruir y controlar por qué respondió así.