📌 En resumen
Los permisos son la parte más crítica de un RAG empresarial: el asistente solo debe poder responder a cada usuario con los documentos que esa persona ya tiene autorizado ver. Para lograrlo hay que propagar los permisos del origen (SharePoint, drive) al sistema de recuperación y filtrar por usuario en cada consulta (security trimming). Sin esto, un chatbot interno puede convertirse en una fuga de información que expone documentos a quien no debe.
Un RAG que funciona técnicamente pero ignora los permisos es un problema de seguridad, no una solución. Si cualquiera puede "preguntarle" al chatbot algo que está en un documento al que no tiene acceso, has abierto una brecha. Por eso los permisos son el primer requisito de diseño de un copilot con RAG para empresa, no un añadido posterior.
¿Por qué los permisos son el punto crítico de un RAG?
Porque un RAG da acceso conversacional a tus documentos: si no respeta quién puede ver qué, expone información. El riesgo no es teórico: un usuario podría obtener datos de nóminas, contratos o proyectos confidenciales simplemente preguntando, aunque no tenga acceso al archivo. El asistente debe heredar exactamente los permisos que ya existen, ni más ni menos.
⚠️ Atención
Este riesgo no es exclusivo del RAG: en cualquier proyecto que combine CRM, ERP o bases de datos con herramientas externas hay que decidir de antemano qué información no debe salir de forma abierta hacia esas herramientas. La disciplina es la misma: primero mapear qué es sensible, después decidir qué se indexa y con qué permisos, y nunca al revés.
¿Cómo se respetan los permisos existentes (security trimming)?
La técnica se llama security trimming: en cada consulta, el sistema filtra los fragmentos recuperados según los permisos del usuario que pregunta, de modo que solo se usan documentos a los que tiene acceso. Para ello hay que llevar los permisos (ACL) del origen al índice de recuperación y comprobarlos en tiempo de consulta. Es clave cuando las fuentes son SharePoint, drive o Confluence, donde cada documento ya tiene sus accesos.
¿Qué enfoques de permisos hay?
| Enfoque | Cómo funciona | Cuándo encaja |
|---|---|---|
| Filtrado por usuario (ACL) | Hereda permisos del origen en cada consulta | Caso general; el más seguro |
| Por grupos/roles | Acceso según el rol del usuario | Estructuras de permisos simples |
| Índices separados | Un índice por nivel de confidencialidad | Pocos niveles, muy diferenciados |
¿Cómo encaja con el RGPD y el cumplimiento?
Más allá del acceso, hay que cumplir con la protección de datos: minimizar qué se indexa, controlar dónde se procesa y guardar trazas. Un RAG con datos personales entra en el ámbito del RGPD y, según el uso, del AI Act. Lo desarrollamos en RGPD en un copilot con RAG. Permisos y cumplimiento van de la mano.
¿Cómo se prueba que los permisos funcionan?
- 1Define casos de prueba con usuarios de distintos niveles de acceso.
- 2Comprueba que cada usuario solo obtiene respuestas de documentos a los que puede acceder.
- 3Prueba a "forzar" respuestas sobre documentos restringidos y verifica que no las da.
- 4Revisa que, al cambiar permisos en el origen, el RAG se actualiza.
- 5Registra y audita las consultas para detectar accesos indebidos.
¿Qué errores evitar con los permisos en un RAG?
- Indexar todo sin filtrar por usuario: la fuga está servida.
- Asumir permisos estáticos: cuando cambian en el origen, deben reflejarse en el RAG.
- Mezclar en un mismo índice documentos con niveles de acceso muy distintos sin control.
- No registrar las consultas: sin trazas no se puede auditar un acceso indebido.
Preguntas frecuentes
¿Por qué son tan importantes los permisos en un RAG empresarial?
Porque un RAG da acceso conversacional a tus documentos: si no respeta quién puede ver qué, expone información confidencial. Un usuario podría obtener datos de nóminas o contratos solo preguntando, aunque no tenga acceso al archivo. El asistente debe heredar exactamente los permisos existentes; por eso son el primer requisito de diseño, no un añadido.
¿Qué es el security trimming en un RAG?
Es la técnica que filtra, en cada consulta, los fragmentos recuperados según los permisos del usuario que pregunta, de forma que solo se usan documentos a los que tiene acceso. Requiere llevar los permisos (ACL) del origen al índice de recuperación y comprobarlos en tiempo de consulta. Es la forma estándar de que un RAG respete los accesos existentes.
¿El RAG respeta automáticamente los permisos de SharePoint?
No automáticamente: hay que diseñarlo para ello. Los permisos del origen (SharePoint, drive, Confluence) deben propagarse al sistema de recuperación y aplicarse por usuario en cada consulta. Además, cuando los permisos cambian en el origen, el RAG debe reflejar ese cambio. Sin ese trabajo, el RAG no hereda los accesos solo.
¿Un RAG con permisos cumple el RGPD?
Los permisos son necesarios pero no suficientes. Además hay que minimizar qué datos personales se indexan, controlar dónde se procesan, guardar trazas de las consultas y, según el uso, considerar el AI Act. Permisos y cumplimiento van juntos: un buen control de accesos es la base, pero el RGPD exige más medidas de gobierno del dato.
Siguiente paso recomendado
Copilot RAG empresarial
Asistente interno sobre documentos con permisos, trazabilidad y fuentes citadas.
Sin compromiso · Respuesta en < 24h
Autor
Fundador y Consultor de Datos e IA
David Aldomar es fundador y consultor principal de MERIDIAN Data & IA, consultora especializada en ayudar a pymes y empresas medianas en España a tomar mejores decisiones con sus datos. Su trabajo se centra en cuatro áreas: diseño e implantación de plataformas de datos (data warehouses, pipelines ETL con dbt, integración de ERPs y CRMs), reporting y dashboards ejecutivos en Power BI, automatización de procesos de negocio con herramientas como n8n, y desarrollo de soluciones de inteligencia artificial aplicada — desde modelos de forecasting de demanda hasta copilots internos basados en RAG con LangChain y FastAPI. Ha liderado proyectos en sectores como logística y transporte, retail y distribución, servicios financieros, manufacturing y construcción, siempre con un enfoque pragmático: diagnóstico corto, entregables concretos y transferencia de conocimiento al equipo del cliente para que sea autónomo desde el primer día. Antes de fundar MERIDIAN, trabajó como ingeniero de datos y BI en entornos empresariales reales: arquitecturas Data Warehouse por capas (Bronze/Silver/Gold), pipelines ETL/ELT en AWS (S3, Glue, Redshift Serverless, Athena) y stacks Microsoft (SQL Server, Power BI, Azure), integrando fuentes tan dispares como ERPs, CRMs y bases de datos operacionales — PostgreSQL, MariaDB — en una única fuente fiable para negocio, finanzas y reporting. Tiene un Máster en Ciencia de Datos e Ingeniería del Dato en la Nube. Su filosofía es que un buen proyecto de datos no se mide por la tecnología que usa, sino por las decisiones de negocio que permite tomar. Escribe regularmente en el blog de MERIDIAN sobre reporting, gobierno del dato, automatización e IA aplicada, con guías prácticas orientadas a responsables de negocio y equipos técnicos de empresas que quieren sacar partido real a sus datos sin depender de grandes consultoras.
Fuentes