Hay una pregunta que conviene hacer en cualquier revisión de un asistente con recuperación de documentos, y que casi nunca aparece en la documentación técnica del proyecto: si dos personas con permisos distintos hacen exactamente la misma pregunta, ¿reciben la misma respuesta? Cuando la respuesta es "sí", el sistema tiene un problema de control de acceso, no de calidad de las respuestas.
El patrón que produce ese resultado es tan común que se ha vuelto invisible. Alguien apunta un proceso de ingesta al repositorio documental de la organización, lo trocea, lo convierte en vectores y lo deja todo en una única colección. Funciona bien en la demostración, porque quien la ejecuta suele ser el administrador. El problema aparece cuando el asistente se abre a toda la empresa y esa colección se convierte en una copia paralela del repositorio a la que ya no se aplican sus permisos.
Por qué la base vectorial rompe el modelo de permisos
Un repositorio documental maduro tiene años de reglas acumuladas: carpetas restringidas, herencia de permisos, excepciones por proyecto. Ese modelo, con todos sus defectos, es la fuente de verdad sobre quién puede leer qué, y la ingesta lo descarta por completo. Al trocear un documento y guardarlo como vectores, lo único que sobrevive por defecto es el texto y su representación numérica. La procedencia, el propietario y la lista de control de acceso se quedan fuera salvo que alguien las escriba explícitamente como metadatos.
A partir de ahí, la exposición no requiere un ataque: basta una pregunta razonable formulada de buena fe. El motor busca por similitud semántica, no por autorización. Si el fragmento más parecido a lo que preguntó el usuario está en un documento restringido, ese fragmento entra al contexto y el modelo lo redacta con naturalidad. Nadie ve un error. Se ve una respuesta útil.
Una base vectorial sin control de acceso no es un índice de tus documentos: es una copia desprotegida de ellos con un buscador en lenguaje natural encima.
El filtrado posterior no es un control
La respuesta intuitiva es recuperar primero y filtrar después: se traen los fragmentos más relevantes, se comprueba cuáles puede ver el usuario y se descartan el resto. Es mejor que nada y sigue siendo insuficiente por tres razones.
- Degrada la calidad de forma silenciosa. Si pides diez fragmentos y siete se descartan por permisos, el modelo responde con tres. El usuario no recibe un aviso de acceso denegado, recibe una respuesta incompleta que parece completa. Eso erosiona la confianza en el sistema por un motivo que nadie puede diagnosticar desde fuera.
- Deja rastro del contenido restringido. El número de resultados y las diferencias entre lo que ve un usuario y otro permiten inferir la existencia de documentos que no deberían ser visibles. Es una fuga menor, pero real, y especialmente incómoda en procesos de reestructuración o investigaciones internas.
- Confía en que el filtro esté siempre en el camino. El filtro posterior vive en el código de la aplicación. Cualquier ruta que llegue a la base vectorial sin pasar por esa capa —un cuaderno de análisis, un trabajo por lotes, una nueva integración, un agente que consulta directamente— lo esquiva sin que se dispare ninguna alerta.
Cómo se hace bien
Filtrado en la consulta, no después
La restricción tiene que formar parte de la búsqueda vectorial, no ejecutarse sobre su resultado. Esto exige que cada fragmento lleve, como metadato indexado, la identidad de los grupos que pueden leerlo, y que la consulta se construya con el contexto de autorización del usuario que la origina. El motor devuelve entonces los fragmentos más relevantes entre los que esa persona puede ver, que es una operación distinta. El control deja de depender de que el desarrollador se acuerde de aplicarlo.
Esto obliga a resolver un asunto que muchos proyectos posponen: la propagación de identidad. Si el servicio de recuperación consulta la base con una credencial de servicio única, no hay filtrado posible. La identidad del usuario final debe llegar hasta la consulta, con el mismo cuidado con el que se propagan los permisos en cualquier arquitectura de agentes con herramientas.
Particionamiento por audiencia
Cuando los niveles de sensibilidad son claramente distintos, conviene separar índices en lugar de mezclar todo con etiquetas: uno para documentación de uso general, otro para información interna y otro para material regulado. El costo es más infraestructura y algo de duplicación; el beneficio es que un error de configuración en el filtrado no expone lo más sensible, porque ese contenido está en un almacén al que la aplicación general ni siquiera tiene conexión.
Documentos de permisos mixtos
El caso incómodo es el archivo cuyo acceso no es uniforme: un informe con anexos confidenciales, una minuta de directorio con una sección reservada, una planilla con hojas de distinto nivel. Trocear ese documento y heredar el permiso del contenedor produce uno de dos errores: o expone la parte restringida, o esconde la parte que todos deberían poder consultar.
No hay una solución elegante, hay tres decisiones defendibles. La primera es aplicar el permiso más restrictivo a todo el documento, lo que sacrifica utilidad pero nunca expone. La segunda es clasificar por sección durante la ingesta y aceptar el costo de mantener esa clasificación. La tercera, la más honesta cuando el volumen es alto, es excluir de la indexación las fuentes con permisos mixtos hasta poder tratarlas bien: excluir un repositorio es una decisión visible y reversible, indexarlo mal es un problema que se descubre tarde.
Qué revisar en tu implementación
Tres comprobaciones resuelven la mayor parte de la duda. Toma dos usuarios con permisos distintos y ejecuta la misma consulta sensible: si el resultado es idéntico, ya tienes el diagnóstico. Revisa si existe alguna ruta de acceso a la base vectorial que no pase por la capa de aplicación, porque esa ruta es el control real de tu sistema. Y comprueba qué ocurre cuando a alguien se le revoca un acceso en el repositorio de origen: si el índice no refleja el cambio en un plazo acordado, tu control de acceso es una fotografía antigua.
El punto de fondo es que la recuperación no es una función de búsqueda, es una función de autorización que además busca. Tratarla como lo primero produce sistemas que funcionan bien hasta que alguien pregunta lo que no debía, y entonces funcionan igual de bien.