Un RAG mal montado es la forma más rápida de filtrar datos que jamás deberían salir. El patrón clásico: indexas «toda la documentación», un usuario pregunta algo inocente y el sistema le devuelve un fragmento de un documento al que esa persona no debería tener acceso. No es un bug exótico — es la arquitectura por defecto de casi todos los RAG de demo.
Permisos antes que embeddings
El control de acceso no es un filtro que se añade al final: vive en la capa de recuperación. Antes de que el modelo vea nada, el sistema ya ha restringido qué fragmentos puede recuperar este usuario concreto. La identidad manda; el embedding viene después.
Particiona el índice por permiso
No metemos todo en un único índice y rezamos. Segmentamos por nivel de acceso y adjuntamos metadatos de permiso a cada fragmento, de modo que la consulta solo puede tocar lo que corresponde a quien pregunta.
- Filtrado por identidad en la recuperación, no en la respuesta.
- Índices o particiones segmentados por nivel de acceso.
- Metadatos de permiso en cada fragmento indexado.
- Auditoría de consultas: quién preguntó qué y qué se le devolvió.
Citación o no sirve
Cada respuesta enlaza su fuente. Sin cita no hay confianza ni trazabilidad: el usuario no puede verificar, y tú no puedes auditar. En enterprise, una respuesta sin fuente es una respuesta que no puedes defender.
Qué medimos
- Precisión de recuperación (¿trae lo relevante?).
- Fugas de acceso: el objetivo es cero, y se audita.
- Cobertura de citación: % de respuestas con fuente verificable.
- Uptime y latencia del pipeline.
Esto es lo que hace un Senior AI Infrastructure Implementer: no «conecta un RAG», despliega un sistema de conocimiento que escala, cita y respeta los permisos — porque en enterprise un dato filtrado no es un incidente técnico, es una crisis.