RAG sobre SharePoint, Confluence y Google Drive: arquitectura permissions-first

El problema difícil del RAG empresarial son los permisos: el asistente nunca debe mostrar un documento a quien no pueda verlo. Un embedding no conserva ni aplica por sí solo la autorización de la fuente. Aplique el acceso antes de generar: adjunte a cada chunk el contexto de acceso nativo, o mantenga una consulta autoritativa, y autorice cada resultado antes de que llegue al modelo. No reduzca usuarios directos, grupos, dominios, enlaces, herencia y protección a una regla universal basada solo en grupos o en deny.

Este es el complemento de implementación de nuestra checklist de production-readiness para RAG, que señala los permisos por usuario como el problema de seguridad difícil. Esta entrada explica cómo resolverlo de verdad. Las funciones específicas de proveedor y las de preview cambian rápido; vuelva a revisar la documentación enlazada antes de construir.

Por qué los permisos son la parte difícil

El modo de fallo en una frase: el modelo compone una respuesta fluida basada en un documento que el usuario que pregunta nunca tuvo permiso para ver, porque el retrieval hizo match por similitud semántica, no por autorización. Una vez que un documento se trocea en chunks y se embebe en un índice compartido, los propietarios, niveles de acceso y etiquetas de sensibilidad del sistema fuente no viajan con el vector a menos que usted los lleve deliberadamente. Un vector store no tiene noción de quién pregunta.

Microsoft documenta que Microsoft 365 Copilot solo usa datos a los que puede acceder el usuario autenticado y respeta controles de SharePoint y cifrado por etiquetas. Aun así puede facilitar el hallazgo de contenido ya sobrecompartido. Restricted Content Discovery es un control temporal de SharePoint con límites documentados, y Data Access Governance ayuda a analizar permisos. Ninguno sustituye permisos correctos en la fuente. (1, 2)

Decirle al modelo que no revele un documento no es control de acceso. OWASP mantiene prompt injection como LLM01 y NIST documenta la inyección indirecta mediante contenido recuperado. La lógica fiable de aplicación o datos debe autorizar antes de que el contenido llegue al modelo. (3)

El principio: aplicar en la capa de retrieval

El vector store nunca debe devolver un documento no autorizado en primer lugar, y el modelo nunca debe procesarlo. Eso se logra etiquetando cada chunk con metadatos ACL normalizados y versionados en el momento del indexado e incluyendo un filtro de permisos en la consulta en el momento del retrieval. Filtrar después del retrieval, en la capa de aplicación o en el prompt, falla de dos formas: desperdicia la ventana de contexto trayendo documentos solo para descartarlos, y si la lógica de la app tiene un bug o se elude con una injection, los documentos pasan igual. El post-filtrado además rompe silenciosamente el recall, porque quitar los chunks no autorizados de un conjunto top-k puede dejar al modelo sin nada cuando los resultados autorizados quedaban justo fuera de k. Pre-filtre en la búsqueda, o sobre-recupere varias veces k y luego filtre.

Modelos de permisos por fuente

Cada fuente tiene sus propios principals, herencia, enlaces y controles de protección. Use una identidad de conector dedicada con el mínimo privilegio y alcance necesarios. Normalice para buscar con eficiencia, pero conserve suficientes hechos nativos para reproducir la autorización efectiva.

En Microsoft Graph use grantedToV2 y grantedToIdentitiesV2; los campos antiguos están deprecados. Elija los permisos delegados o de aplicación menos privilegiados y, cuando sea posible, acceso Selected por recurso en vez de lectura de todo el tenant. (4)

Patrones de implementación que aguantan

• Almacene principals nativos estables. Los grupos reducen cardinalidad, pero también pueden decidir el acceso usuarios directos, enlaces de dominio o anyone, restricciones heredadas y estado de protección.
• Vincule cada consulta al usuario autenticado. Use IDs inmutables de sujeto y tenant y resuelva derechos efectivos o consulte la fuente. El flujo On-Behalf-Of de Microsoft transporta permisos delegados de usuario, no application roles; Google y Atlassian requieren diseños propios. (8)
• Haga obligatoria la autorización en retrieval. Use filtros de conjunto para reglas aditivas y comprobaciones explícitas para ancestros, acceso limitado, enlaces y cifrado. No existe una regla universal segura de deny sobre grant.
• Maneje el groups-overage de Entra. Microsoft documenta 200 grupos para claims JWT y 150 para SAML. Superado el límite, el token omite la lista y emite un indicador; obtenga la pertenencia completa antes de autorizar. (7)
• Postgres RLS puede aplicar el predicado cerca de pgvector, pero no es imposible eludirlo. Superusers, roles BYPASSRLS y normalmente propietarios de tabla lo omiten. Use roles de aplicación sin privilegios, policies probadas e identidad local a la transacción. (9)

Hay una bifurcación genuina en las recomendaciones que conviene nombrar. Un bando (incluido AWS) sostiene que el filtrado de metadatos en tiempo de consulta por sí solo no basta y que debería volver a verificar la autorización contra la fuente en el retrieval, porque los metadatos sincronizados se quedan obsoletos. El otro (incluidos los patrones de referencia de Microsoft) sincroniza las ACL al índice y las aplica con el token del usuario en tiempo de consulta, por throughput. Es un trade-off real: frescura frente a latencia. Elija según lo sensibles que sean los datos.

El problema de frescura que nadie presupuesta

Los permisos materializados no reflejan automáticamente una revocación de la fuente. Los change feeds son señales, no prueba de que se recalculó el acceso efectivo de todos los descendientes. Google documenta cambios de ACL en el log del usuario solo para propietarios, cuentas de servicio incluidas en la ACL o usuarios directamente afectados; para shared drives use el log correspondiente. Combine eventos incrementales, reconciliación periódica y un umbral de frescura fail-closed. (10)

El borrado es la otra mitad. Cuando exista una obligación de supresión conforme al GDPR y los chunks, embeddings, cachés o logs derivados sigan siendo datos personales, elimínelos o anonimícelos respetando los motivos y excepciones legales. Los embeddings no son datos personales de forma categórica. Un ataque publicado recuperó exactamente el 92 por ciento de entradas de 32 tokens en una configuración white-box específica con dos modelos. Demuestra un riesgo real, no una tasa universal. (11, 12)

GDPR y residencia

La minimización y limitación del almacenamiento favorecen un corpus acotado y retención breve de artefactos derivados. Los logs de retrieval ayudan a rendir cuentas, pero pueden contener datos personales y deben minimizarse, protegerse y expirar. Si el proveedor actúa como encargado, el artículo 28 exige términos contractuales adecuados; el capítulo V rige transferencias internacionales. Un endpoint de inferencia en la UE no demuestra por sí solo residencia integral. Verifique flujo, almacenamiento, soporte y subencargados. Véase residencia de datos en la UE para apps de IA en 2026. (11)

La arquitectura de referencia, y los anti-patrones

De extremo a extremo: haga la ingesta de cada fuente con una identidad que pueda leer todo el contenido y las ACL; extraiga la ACL efectiva por elemento (respetando la herencia rota, recorriendo los ancestros de Confluence, leyendo la herencia de Drive); trocee, embeba y adjunte la ACL normalizada y versionada como metadato filtrable en cada chunk; recupere con la identidad del usuario final y un filtro de permisos obligatorio; genere solo a partir de chunks autorizados; registre cada decisión; y ejecute un bucle de frescura a partir de los change feeds de la fuente con resync explícito para los cambios heredados y borrados en cascada hasta chunks y embeddings.

Son anti-patrones: un índice compartido sin autorización obligatoria; filtrar solo en el prompt; consultar como una cuenta de servicio ampliamente autorizada; guardar grupos y descartar usuarios directos o enlaces; reducir todos los productos a una regla deny o grant; tratar una restricción directa de Confluence como acceso efectivo; asumir que Drive solo amplía acceso; ignorar el cifrado por etiqueta de SharePoint; aceptar autorización obsoleta sin límite; y conservar derivados personales sin base jurídica.

"El modelo no es tu control de acceso, y el prompt no es tu frontera de seguridad. Si un usuario no tiene permiso para leer un documento, el vector store nunca debe devolverlo. Todo lo demás, las etiquetas, la frescura, el log de auditoría, está al servicio de esa única regla."