Qué debe entregar una auditoría de RAG y agentes

El equipo quiere habilitar un asistente para más usuarios, pero una respuesta incorrecta sigue sin explicación. Cambiar el modelo podría mejorarla o esconder el problema. Antes de ampliar el despliegue, una auditoría debería localizar qué falla y dejar una decisión que pueda ejecutarse.

Acota la revisión a una pregunta de negocio: si se puede abrir el sistema a otro departamento, permitir una nueva herramienta o continuar con la arquitectura actual. El alcance será distinto en cada caso. Una revisión de recuperación documental no demuestra que sea seguro enviar órdenes a una API.

Acordar el resultado antes de dar acceso

La propuesta de auditoría debe identificar el sistema y su versión, los usuarios afectados y la decisión pendiente. Incluye las integraciones que se van a probar y las que quedan fuera. Define también quién puede autorizar pruebas con efectos externos.

Conviene empezar en un entorno de prueba con datos sintéticos o anonimizados. Si hace falta observar producción, acuerda qué se puede leer, durante cuánto tiempo y cómo se eliminará la copia de trabajo. Nunca hace falta entregar todos los permisos de administración para comenzar a dibujar la arquitectura.

El acceso disponible limita las conclusiones. Una revisión de capturas permite comentar el comportamiento visible. Para diagnosticar permisos o reintentos hacen falta código, configuración y pruebas del flujo. El informe debe dejar esas diferencias escritas.

Seguir un fallo desde la pregunta hasta la respuesta

Para cada caso, conserva la entrada y el resultado esperado. Añade la identidad de prueba, la versión del modelo y los documentos o herramientas implicados. Con esos datos se puede reconstruir lo que hizo la aplicación sin almacenar indiscriminadamente información del cliente.

En un RAG, separa el diagnóstico de búsqueda del de generación. Comprueba si el documento correcto entró en el índice, si conservó sus permisos y si apareció entre los resultados. Después revisa cómo se utilizó su contenido y si las citas respaldan cada afirmación.

Haz una prueba de actualización y otra de retirada. La documentación de recuperación de OpenAI describe operaciones asíncronas y borrado con consistencia eventual. El comportamiento concreto del proveedor debe formar parte de la prueba; una actualización del origen no acredita por sí sola que todas las respuestas se hayan actualizado.

Revisar el efecto de las herramientas

En agentes, sigue una operación que cambie datos. Identifica quién la pidió, qué permisos tenía y qué confirmó el servicio externo. Interrumpe una ejecución de prueba en un punto controlado y observa cómo continúa.

Un caso especialmente útil consiste en perder la respuesta de una escritura ya aceptada. ¿La aplicación repite la acción, consulta su estado o la deja pendiente? La guía de idempotencia de AWS explica por qué una intención necesita un identificador que sobreviva a sus reintentos. La auditoría debe comprobar el comportamiento del código que usa ese contrato.

Revisa también qué ocurre cuando el usuario pierde un permiso entre la propuesta y la ejecución. Para operaciones sensibles, aprobar una versión antigua de la acción no debería autorizar otra cuyo contenido haya cambiado.

Probar permisos con usuarios distintos

Una prueba con la cuenta de administrador puede ocultar el problema. Ejecuta la misma consulta con una identidad autorizada y otra que no deba acceder al documento. Incluye separación entre tenants, enlaces a fuentes y respuestas guardadas en caché.

OWASP recoge la filtración entre contextos y los controles de acceso insuficientes entre los riesgos de recuperación vectorial. Si el sistema utiliza PostgreSQL, revisa el rol efectivo de cada conexión: su documentación de seguridad por filas explica las excepciones para propietarios y roles que omiten RLS.

El entregable debe distinguir un acceso rechazado por el servidor de un documento que simplemente no apareció entre los primeros resultados de búsqueda.

Entregar hallazgos que puedan volver a probarse

Cada hallazgo debería incluir:

• La condición que lo activa y la versión examinada.
• Evidencia suficiente para reproducirlo, con los datos sensibles retirados.
• Consecuencia para el usuario o el negocio y alcance observado.
• Corrección propuesta y prueba de aceptación para verificarla.

Acompaña los hallazgos de un mapa de componentes y un registro de las pruebas ejecutadas. Separa errores del modelo, fallos de integración y problemas de datos. Mantén visibles los casos no comprobados por falta de acceso o por riesgo.

Las métricas de calidad necesitan un denominador y criterios explícitos. Una tasa global de respuestas aceptables puede ocultar una filtración grave en un grupo pequeño. Presenta los fallos por tipo de tarea y nivel de permiso. Para respuestas variables, usa evaluaciones repetidas y revisión humana de una muestra; conserva los tests deterministas de autorización y contratos.

Cerrar con una decisión acotada

El informe debe proponer qué mantener y qué corregir primero, además de señalar lo que impide recomendar el despliegue. Si una modificación se aplica durante la auditoría, repite su prueba de aceptación y registra la versión final. Los resultados de una muestra no certifican todo comportamiento futuro ni sustituyen una revisión legal o regulatoria cuando corresponda.

La consultoría técnica de IA permite delimitar esa intervención. Si el problema apunta al conocimiento disponible, revisa antes la comparación entre RAG y fine-tuning.

Envía el fallo que te preocupa y la decisión que necesitas tomar. La revisión se puede presupuestar sobre ese alcance, con entregables y límites de acceso acordados antes de empezar.