Tu chatbot RAG indexa documentos internos y algunos usuarios empiezan a ver datos que no deberían. ¿Cuál es la causa y la solución?
Respuesta breve
Si la recuperación extrae cualquier documento indexado sin importar quién pregunta, el modelo expondrá fielmente datos que el usuario no debería ver — es un fallo de autorización, no una alucinación. Aplica los permisos del usuario a nivel de documento en el momento de la recuperación, para que solo los fragmentos autorizados entren en el contexto. Un prompt de sistema más largo es evitable y no implementa control de acceso, la temperatura no tiene relación, y otro modelo tiene la misma brecha.
Un usuario hace una pregunta al chatbot y recibe el contenido de un documento al que nunca debió tener acceso — una hoja de salarios, la hoja de ruta de otro equipo, un expediente de RR. HH. El instinto es culpar al modelo. Es el instinto equivocado.
Por qué esto es autorización, no alucinación
El modelo hace exactamente lo que se le pidió: recibió ese documento en su ventana de contexto y lo resumió con precisión. El fallo ocurrió antes de la generación, en el paso de recuperación. Si tu recuperador ejecuta una búsqueda por similitud sobre todo el índice y devuelve los top-k fragmentos sin importar quién pregunta, entonces cualquier documento secreto suficientemente relevante queda al alcance. El modelo no puede aplicar un permiso que nunca recibió.
Esto es el clásico control de acceso roto disfrazado de problema de IA. El RAG convierte silenciosamente todo tu corpus documental en una superficie consultable, y una interfaz que oculta el enlace a un archivo no sirve de nada si la recuperación sigue extrayendo su texto hacia el prompt.
La solución: autorizar en la recuperación
Aplica los permisos del usuario a nivel de documento, en el momento de la consulta, para que solo los fragmentos a los que tiene derecho entren en el contexto. En la práctica:
- Adjunta metadatos de propiedad/ACL a cada fragmento durante la ingesta.
- Pasa la identidad autenticada del usuario y sus pertenencias de grupo al recuperador y filtra antes de que la búsqueda por similitud devuelva resultados, no después.
- Vuelve a comprobar los permisos en el momento de la respuesta para todo lo sensible, y reindexa o invalida los documentos cuando cambian sus ACL.
Por qué los distractores son peligrosos
- Subir la temperatura / alucinación: la temperatura cambia la aleatoriedad, no qué datos se pueden recuperar. Los datos son reales y se recuperan correctamente — ese es el problema.
- Prompt de sistema más largo: un prompt que pide al modelo «tener cuidado» es una barrera blanda y evitable, colocada sobre un contexto ya filtrado. Una inyección de prompt o una pregunta ingeniosa la derrota. El control de acceso debe ser una comprobación estricta en el código.
- Cambiar de modelo: todo modelo expone lo que pones en su contexto. Otro modelo hereda exactamente la misma brecha de recuperación.
Qué quieren oír los entrevistadores
Que ubicas el fallo en la capa de recuperación/autorización, que aplicas mínimo privilegio por usuario, y que nunca confías en la prosa del modelo para sustituir una decisión de control de acceso que la aplicación debería tomar.
Posibles preguntas de seguimiento
- ¿Cómo implementarías un filtrado por usuario en una base de datos vectorial que solo hace búsqueda por similitud?
- ¿Por qué filtrar la respuesta tras la generación es peor que filtrar en la recuperación?
- ¿Cómo gestionas documentos cuyos permisos cambian después de haberlos indexado?