Control de acceso granular y arquitectura multi-tenant
Por qué el filtrado va dentro de la recuperación y no después, y cómo aislar varios clientes en un mismo índice.
Un RAG sin control de acceso no es un buscador incompleto: es un mecanismo excepcionalmente eficaz para que cualquier empleado descubra lo que no debía ver, formulado además en lenguaje natural y con la fuente citada. Esta entrega trata de dónde va exactamente el filtro y de cómo se separan varios clientes que comparten infraestructura.
El filtro va dentro de la recuperación
Hay tres sitios donde se puede aplicar el control de acceso, y sólo uno vale.
Después de generar la respuesta es la peor opción posible y, aun así, se ve. Consiste en recuperar sin filtrar, generar, y luego comprobar si el usuario tenía permiso sobre los documentos citados para decidir si se muestra la respuesta o un mensaje de error. Falla por una razón elemental: el modelo ya ha leído el documento y su contenido ya está dentro del texto generado. Aunque ocultes las citas, la respuesta sigue conteniendo la información. Y si el sistema responde «no tienes acceso a esta información» sólo cuando el documento existe, acabas de construir un oráculo que confirma la existencia de documentos confidenciales, que es una filtración por sí sola.
Después de recuperar y antes de generar —recuperar veinte fragmentos y descartar los prohibidos antes de montar el prompt— es defendible en cuanto a confidencialidad, pero rompe la calidad de forma silenciosa. Pides veinte candidatos, se caen doce por permisos, y le entregas al modelo ocho que quizá no eran los ocho mejores de los que el usuario sí puede ver. El sistema responde peor cuanto más restringido está el usuario, y nadie sabe por qué. Además, en el caso extremo, el contexto se queda vacío.
Dentro de la recuperación es la única opción correcta: los permisos son parte de la consulta al almacén vectorial, no un paso posterior. El motor busca los k mejores fragmentos entre los que este usuario puede ver. La respuesta es la mejor posible dentro del subconjunto autorizado, el contexto nunca contiene nada prohibido, y no hay canal lateral que revele la existencia de lo que no se puede ver.
Esto convierte una característica del motor en un requisito de seguridad. El filtrado previo eficiente —que el índice ANN sepa restringirse a un subconjunto sin degradarse ni recorrer la colección entera— deja de ser una preferencia de rendimiento y pasa a ser criterio de eliminación al elegir base vectorial, como ya se apuntó en la entrega 28.
Modelos de permisos
Por documento
Cada fragmento lleva en sus metadatos la lista de identificadores —usuarios, grupos o roles— con acceso al documento del que procede. La consulta filtra por intersección entre esa lista y los grupos del usuario que pregunta. Es el modelo más fiel a sistemas como un gestor documental o una unidad compartida, y el más caro de mantener: cada cambio de permiso en el origen obliga a actualizar metadatos en el índice.
Con listas largas conviene guardar identificadores de grupo, nunca de usuario individual. Una lista con cinco mil usuarios en los metadatos de cada fragmento es inmanejable; una con seis grupos es trivial.
Por colección o espacio
Los permisos se conceden sobre agrupaciones —un espacio de Confluence, un departamento, un proyecto— y el fragmento hereda el de su contenedor. Muchísimo más barato de sincronizar y suficiente para la mayoría de organizaciones, porque la granularidad real de sus permisos es esa aunque el sistema de origen permita más. El inconveniente es que no representa las excepciones: el documento concreto que sólo ve dirección dentro de un espacio compartido.
Por atributos
El acceso se decide evaluando atributos del usuario contra atributos del documento: país, unidad de negocio, nivel de clasificación, vigencia. En el índice se traduce a filtros compuestos sobre metadatos. Es el modelo más expresivo y el más difícil de auditar, porque nadie puede responder de memoria a «quién ve este documento» sin evaluar la política. Encaja bien en organizaciones grandes con clasificación formal de la información.
En la práctica lo habitual es una mezcla: colección como base, con lista de grupos por documento para las excepciones y un par de atributos globales como el nivel de confidencialidad.
Sincronización: el punto que se rompe
Los permisos del índice son una copia de los del sistema de origen, y las copias se desfasan. Cuando alguien deja un proyecto, sus permisos se revocan en el gestor documental de inmediato y en tu índice cuando pase el siguiente ciclo de sincronización. Esa ventana es una brecha real.
Tres decisiones que la reducen. Primera: sincronizar permisos en un ciclo independiente y mucho más frecuente que el de contenido, porque actualizar una lista de grupos es barato y reindexar un documento no. Segunda: resolver la pertenencia a grupos en tiempo de consulta contra el proveedor de identidad, y guardar en el índice sólo los grupos autorizados por documento; así los cambios de plantilla surten efecto de inmediato y sólo los cambios de permiso sobre documentos dependen del ciclo. Tercera: revocación explícita e inmediata como operación de primera clase, sin esperar al ciclo, porque las bajas urgentes existen.
Las tres estrategias multi-tenant
Cuando el sistema sirve a varios clientes distintos, la pregunta cambia: ya no es qué puede ver cada usuario dentro de una organización, sino cómo se garantiza que los datos de un cliente no aparezcan jamás en la respuesta de otro. Hay tres arquitecturas, y la elección condiciona coste y operación durante años.
| Criterio | Índice por cliente | Espacio de nombres por cliente | Filtro por metadatos |
|---|---|---|---|
| Aislamiento | Físico. Un fallo de código no puede cruzar datos | Lógico fuerte, garantizado por el motor | Lógico débil: depende de que tu código no olvide el filtro |
| Coste por cliente | Alto y con suelo fijo. Malo para clientes pequeños | Medio; sobrecarga por espacio, pero recursos compartidos | Mínimo. Marginal por cliente nuevo |
| Escala en número de clientes | Decenas, con suerte cientos | Cientos o miles, según motor | Sin límite práctico |
| Vecino ruidoso | Imposible | Posible; se mitiga con cuotas | Probable: un cliente enorme degrada al resto |
| Operación | Pesada: N índices que desplegar y migrar | Media | Ligera: un solo índice |
| Baja de cliente | Borrar el índice. Demostrable | Borrar el espacio. Demostrable | Borrado por filtro, más difícil de acreditar |
| Encaja con | Pocos clientes grandes, exigencias regulatorias o residencia de datos | Producto B2B con clientes medianos | Autoservicio, muchos clientes pequeños |
Tres observaciones sobre la tabla. La primera es que el aislamiento por filtro de metadatos es el único donde un olvido en una línea de código produce una fuga entre clientes. Si eliges esa vía, el identificador de tenant no puede ser un parámetro opcional que cada llamada añade: tiene que estar en una capa de acceso a datos que sea imposible de esquivar, y debe haber pruebas automatizadas que verifiquen que una consulta sin tenant falla en lugar de devolver todo.
La segunda es que la caché hereda el problema. Cualquier clave de caché —exacta, semántica o de embeddings— debe incluir el tenant. Una caché compartida entre clientes anula el aislamiento que hayas construido en el índice.
La tercera es que estas estrategias se combinan por niveles: espacio de nombres por cliente y, dentro, filtro por metadatos para los permisos de sus usuarios. Es la configuración más habitual en producto B2B y suele ser el punto de equilibrio razonable.
Límites y avisos
El filtrado en recuperación protege el contenido de los fragmentos, no todo lo demás. Los metadatos agregados siguen siendo un canal: un sistema que responde «he encontrado 47 documentos, pero no tienes acceso» está informando. Lo correcto es responder igual haya cero o cuarenta y siete.
Tampoco protege de la inferencia por agregación. Un usuario con acceso legítimo a muchos fragmentos parciales puede, mediante preguntas sucesivas, reconstruir información que ningún documento contiene explícitamente. Es un riesgo conocido en bases de datos estadísticas y en RAG se agrava porque el sistema hace el trabajo de síntesis. No hay defensa limpia; hay límites de tasa, registro y revisión de patrones de consulta anómalos.
Y conviene recordar de dónde salen los permisos: si el sistema de origen los tiene mal, el RAG los replicará con obediencia perfecta. Un despliegue de RAG sobre una unidad compartida corporativa suele ser lo que descubre que media empresa tenía acceso a media empresa. Eso no es un fallo del RAG, es un hallazgo, y conviene planificar el proyecto sabiendo que va a producirlo.
Qué viene ahora
La siguiente entrega cierra la parte operativa: qué se monitoriza en un RAG que ya está en marcha. La traza completa por consulta y sus campos, las métricas agregadas que importan, cómo se detectan las preguntas que el sistema no está respondiendo bien, cómo se vigila la deriva del corpus y de las preguntas, y cuál es el panel mínimo que conviene tener desde el primer día en producción.
Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).
Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.
