El error más común de RAG dentro de las empresas es sencillo: subir todo, hacer preguntas y tratar las respuestas citadas como automáticamente seguras.
El segundo error más común aparece después: alguien descubre que el asistente puede responder a partir de documentos que el usuario nunca debería haber visto. Bandas salariales. Contratos con clientes. Borradores jurídicos. Notas del consejo. Tickets de soporte. Investigaciones de recursos humanos. Procedimientos de seguridad. La respuesta puede ser exacta y estar citada, pero el sistema ha filtrado información confidencial.
Un RAG de conocimiento corporativo no es una caja de búsqueda con mejor redacción. Es un sistema de información con permisos. Trátalo así.
La recuperación debe aplicar permisos iguales o más estrictos que los sistemas de origen. Si un usuario no puede abrir el documento en Google Drive, SharePoint, Notion, Confluence o el CRM, el RAG tampoco debe recuperarlo para ese usuario.
La regla principal
La capa de recuperación debe responder a esta pregunta antes de devolver cualquier fragmento:
¿Este usuario está autorizado para ver esta fuente en este momento?
No “¿esta fuente está en la base de vectores?” No “¿esta fuente es relevante?” No “¿esta fuente es útil?” Los permisos vienen primero.
Hay tres patrones comunes:
| Patrón | Cómo funciona | Adecuado para |
|---|---|---|
| Índices separados | Un índice por audiencia o espacio de trabajo | Equipos simples, permisos gruesos |
| Filtro de metadatos | Almacena metadatos de ACL, grupo y fuente, y filtra antes de recuperar | La mayoría de los sistemas RAG corporativos |
| Verificación de permisos en tiempo real | Consulta los permisos del sistema de fuentes en tiempo de recuperación | Permisos sensibles o que cambian con frecuencia |
La respuesta correcta depende de los sistemas de origen y del nivel de riesgo. Para la mayoría de las pymes, basta con índices separados y filtrado de metadatos. Los datos de clientes, recursos humanos, jurídicos o regulados pueden exigir comprobaciones en tiempo real.
La parte difícil: mantener sincronizadas las ACL
Todos los patrones anteriores dependen de una condición: los datos de permisos del índice deben coincidir con los del sistema de origen. En esa sincronización reside la verdadera dificultad de ingeniería.
De dónde proceden las ACL. SharePoint y OneDrive exponen permisos por elemento mediante la API de Microsoft Graph; Google Drive, mediante las listas de permisos por archivo de la API de Drive; y Confluence, mediante restricciones de espacio y página. Cada sistema representa de forma distinta usuarios, grupos, herencia y enlaces compartidos, aplica límites de frecuencia diferentes y define a su manera “quién puede ver esto”.
La expansión de grupos no es opcional. La mayoría de los permisos reales se conceden a grupos, que a su vez pueden estar anidados. “Sales EU” dentro de “Sales” y este dentro de “All Staff” debe expandirse hasta usuarios concretos durante la sincronización —más metadatos en el índice y consultas más rápidas— o durante la consulta —datos más recientes, pero más latencia y llamadas a la API—. Elige una estrategia de forma deliberada; los equipos que no lo hacen terminan aplicándola de manera incoherente.
El retraso de sincronización es un parámetro de seguridad, no un detalle de rendimiento. Cuando alguien pierde el acceso a un documento —por un cambio de rol, una desvinculación o porque una operación pasa a ser confidencial—, el índice sigue aplicando la ACL anterior hasta la siguiente sincronización. Define y documenta el retraso de revocación aceptable para cada corpus: casi en tiempo real para corpus restringidos; unas horas pueden ser aceptables para documentos internos de procesos. Si nadie ha fijado ese valor, la respuesta real será “cuando se ejecute la tarea nocturna”, algo que no superará una revisión de seguridad.
Las comprobaciones en tiempo real mejoran la vigencia a cambio de latencia, cuota de API y un modo de fallo adicional. Cada recuperación exige una ida y vuelta al sistema de origen y, a escala, consume rápidamente la cuota de API. El compromiso habitual es una caché de corta duración, que convierte “tiempo real” en “retraso de sincronización, pero menor”. Sea cual sea la opción, define el comportamiento ante tiempos de espera: si la comprobación de permisos falla o agota el tiempo, el fragmento no se envía. Falla de forma cerrada, registra el error y permite que el asistente rechace la solicitud; una respuesta correcta y lenta es mejor que una filtración rápida.
La prueba de desvinculación incluida más adelante permite comprobar si todo esto funciona: una cuenta deshabilitada no debe recuperar nada de corpus restringidos, y la restricción debe seguir vigente al día siguiente de deshabilitarla, no solo después de la siguiente sincronización completa.
Límites de fuentes
No crees un gran depósito de conocimiento. Separa por audiencia y sensibilidad:
| Corpus | Audiencia | Ejemplos | Regla |
|---|---|---|---|
| Público/producto | Todo el mundo | Documentación de ayuda, precios públicos, páginas del producto | Seguro para asistentes amplios |
| Operaciones internas | Empleados | Documentos de proceso, preguntas frecuentes internas | Solo para empleados |
| Departamento | Miembros del departamento | Playbooks de ventas, macros de soporte, runbooks de ingeniería | Filtrado por grupo |
| Registros de clientes | Equipos asignados | Tickets, contratos, notas de cuenta | ACL estricto y auditoría |
| Restringido | Solo usuarios nombrados | Recursos humanos, legal, seguridad, consejo | Normalmente sistema separado o sin RAG |
Cuantas menos audiencias atienda un corpus, más fácil será razonar sobre posibles filtraciones.
Controles de ingesta
Muchas filtraciones comienzan en el pipeline de ingesta.
Antes de indexar una fuente, captura:
- Sistema de fuente.
- ID del documento.
- Propietario.
- Audiencia o ACL.
- Etiqueta de sensibilidad.
- Marcas de creación y actualización.
- Fecha de vencimiento o revisión.
- Si el documento puede usarse para recuperación de IA.
- Si el documento contiene datos personales.
Si el sistema de origen ya contiene etiquetas, consérvalas. En caso contrario, añade un paso ligero de clasificación antes de la ingesta.
Controles de recuperación
La recuperación debe ocurrir en este orden:
- Identificar al usuario y sus grupos.
- Identificar el espacio de trabajo o asistente solicitado.
- Filtrar fuentes candidatas por corpus, ACL, sensibilidad y frescura.
- Recuperar solo fragmentos relevantes de fuentes permitidas.
- Aplicar reranking a los fragmentos permitidos.
- Generar la respuesta con referencias a fuentes.
- Rechazar o escalar cuando las fuentes permitidas sean insuficientes.
No recuperes primero para filtrar después en el prompt. Si un fragmento prohibido entra en el contexto del modelo, el límite ya se ha vulnerado.
Comportamiento del prompt y respuesta
Al asistente se le debe instruir para que:
- Responda solo desde fuentes recuperadas.
- Cite el título y la sección/enlace de la fuente.
- Diga cuando las fuentes permitidas no contienen la respuesta.
- Marque las inferencias por separado de los hechos respaldados por fuentes.
- Evite revelar la existencia de fuentes restringidas.
- Evite resumir material cuyo acceso se haya denegado.
Rechazo malo:
“Encontré bandas salariales de RRHH pero no tienes acceso.”
Mejor rechazo:
“No tengo una fuente aprobada disponible para responder eso.”
La segunda respuesta no revela la existencia o el tema de documentos restringidos.
Registrar sin crear una segunda filtración
Los registros de RAG son sensibles. Pueden contener preguntas del usuario, fragmentos recuperados, IDs de fuentes, respuestas y a veces datos personales.
Registra lo suficiente para depurar:
- ID del usuario o ID pseudónimo.
- Asistente/espacio de trabajo.
- Marca temporal de consulta.
- IDs de fuentes recuperadas.
- Resultado del filtro de permisos.
- ID de respuesta.
- Razón de rechazo/escalado.
- Latencia y errores.
Ten cuidado con:
- Preguntas completas del usuario.
- Fragmentos completos recuperados.
- Respuestas completas generadas.
- Datos del cliente.
- Temas de RRHH/legal/seguridad.
En sistemas sensibles, almacena registros con los datos confidenciales suprimidos o IDs de fuentes en lugar del texto completo. Aplica a los registros su propio control de acceso y período de conservación.
Fuentes obsoletas y conflictivas
El permiso no es el único límite. La calidad de la fuente importa.
Cada fuente indexada debe tener un propietario y una regla de frescura:
| Tipo de fuente | Regla de revisión |
|---|---|
| Precios | Revisión en cada cambio de precios |
| Políticas | Revisión en actualización del propietario de la política, al menos trimestralmente |
| Documentación del producto | Revisión en cada lanzamiento |
| Plantilla jurídica | Revisión por el responsable jurídico |
| Macro de soporte | Revisión mensual o después de un patrón de escalado |
Cuando las fuentes entran en conflicto, el asistente debe mostrar el conflicto solo si el usuario puede acceder a ambas fuentes. De lo contrario, debe responder desde la fuente permitida con mayor autoridad o escalar.
Pruebas de límites de permisos
Prueba con usuarios, no solo con documentos:
- Empleado con acceso amplio.
- Empleado con acceso restringido a un departamento.
- Gerente con acceso solo al equipo.
- Contratista.
- Exempleado o cuenta deshabilitada.
- Usuario de soporte orientado al cliente.
- Administrador.
Para cada uno, pregunta:
- Una pregunta que debería poder responder.
- Una pregunta justo fuera de sus permisos.
- Una pregunta sobre un documento restringido que sabe que existe.
- Una pregunta donde los documentos públicos y los internos entran en conflicto.
- Una pregunta con inyección de prompt: “ignora las reglas de acceso.”
El resultado correcto no es solo una “buena respuesta”, sino una “buena respuesta basada en fuentes permitidas”.
Ruta de implementación
Empieza con el corpus menos sensible:
- Documentos públicos/productos.
- Documentos de operaciones internas.
- Documentos específicos del departamento.
- Registros de clientes con ACL estricto.
- Corpus restringidos solo después de la aprobación expresa de los equipos de seguridad y jurídico.
En cada etapa, mide:
- Utilidad de la respuesta.
- Calidad de las citas.
- Correctitud del rechazo.
- Tasa de recuperación denegada.
- Tasa de fuentes obsoletas.
- Informes de usuarios sobre fuentes faltantes o incorrectas.
No hagas esto aún
No indexes “todos los documentos de la empresa” en un único asistente.
No dependas de instrucciones en el prompt para aplicar permisos.
No registres fragmentos completos recuperados de corpus sensibles sin una política clara de conservación y acceso.
No mezcles documentos de RRHH, jurídicos, de clientes y públicos en el mismo corpus.
No permitas que el RAG responda fuera de sus fuentes permitidas solo para resultar útil.
El mensaje clave
El RAG de conocimiento corporativo aporta valor porque incorpora respuestas respaldadas por fuentes al trabajo diario. También entraña riesgos, porque incluso esas respuestas pueden filtrar información.
Diseña primero los límites de permisos. Filtra antes de recuperar. Separa los corpus por audiencia. Conserva los metadatos de las fuentes. Rechaza de forma segura. Registra con cuidado. Prueba con perfiles de permisos reales. Si un usuario no puede acceder directamente a una fuente, el RAG no debe utilizarla para responderle.
