En un sistema de recuperación de información basado en RAG (Retrieval-Augmented Generation), es fundamental que la autorización no se limite a la interpretación del texto del prompt, sino que se implemente directamente en el proceso de recuperación de datos. Esto significa que, antes de que un documento o fragmento de información sea incluido en la generación de una respuesta, se debe verificar que el usuario tenga los permisos necesarios para acceder a ese contenido. Si no es así, el sistema debe impedir que ese material se utilice, incluso en forma de fragmento o referencia.
Corrección del 8 de octubre de 2026: aclaramos la responsabilidad de autenticar al usuario y corregimos la prueba negativa: un intento denegado puede registrarse para auditoría, sin revelar contenido protegido.
La idea, paso a paso
La lógica de autorización debe aplicarse en el nivel del sistema de recuperación, es decir, en el momento en que se consulta una base de datos o un índice de documentos. Esto implica que, antes de que se realice la recuperación, se aplican filtros basados en la identidad del usuario y sus permisos. Por ejemplo, si un usuario no tiene autorización para acceder a documentos relacionados con nóminas, el sistema no debe recuperar esos documentos ni permitir que se mencionen en la respuesta. Además, es importante evitar que los resultados de búsqueda puedan cruzarse entre diferentes grupos de usuarios, lo que podría llevar a la exposición accidental de información sensible.
Un ejemplo para entenderlo
Dos equipos ficticios comparten una aplicación de búsqueda, pero uno no puede consultar documentos de nóminas. La recuperación debe comprobar su identidad y aplicar las restricciones antes de entregar fragmentos al modelo. La prueba no termina al revisar el texto final: también debe comprobar que las citas, cachés y registros no revelan información fuera de permiso.
Qué conviene comprobar
En la práctica, esto implica que los sistemas de recuperación deben integrar mecanismos de autorización que permitan aplicar filtros en base a la identidad del usuario, sus roles y permisos. Además, es importante que los registros de acceso y las trazabilidades de las consultas se conserven, para poder auditar posteriormente qué documentos se han recuperado y bajo qué condiciones.
Un filtro de permisos basado en metadatos puede ser válido si esos metadatos representan las autorizaciones reales y se mantienen al día. Una etiqueta genérica como «confidencial» no identifica por sí sola quién puede leer el documento. En Azure AI Search, el patrón de filtros compara cadenas de usuarios o grupos: la aplicación debe autenticar al solicitante y construir el filtro desde una identidad de confianza. No aceptes grupos enviados libremente por el cliente ni permitas consultas que omitan el control.
La prueba negativa debe comprobar que el contenido protegido no llega al contexto del modelo, a las citas ni a las respuestas de otro usuario a través de una caché. Un registro interno con acceso restringido puede conservar que hubo una denegación; no hace falta borrar esa evidencia de auditoría. Evita copiar en registros accesibles al usuario el texto, títulos u otros datos protegidos. Ante una consulta sin resultados autorizados, una respuesta genérica puede evitar confirmar la existencia de un documento restringido.
Requisitos y límites
Necesitas identidad autenticada, permisos fiables por documento o fragmento y una política para cambios de acceso. Como decisión de diseño, comprueba también una revocación después de llenar la caché: una respuesta antigua no debería seguir exponiendo el documento. Si faltan permisos o falla su comprobación, deniega la entrega de contexto hasta resolverlo.
Puedes usar filtros construidos en el servidor, un motor con autorización integrada o índices separados por organización; el aislamiento debe abarcar también consultas y cachés. Azure documenta varias opciones nativas en vista previa: revisa su soporte y condiciones antes de elegirlas. Este artículo introduce el diseño y una prueba conceptual; no acredita una implantación ejecutada ni garantiza la seguridad de un sistema completo.
La identidad y la autorización se comprueban antes de entregar contenido al modelo. Evita que una caché, una cita o un registro revele lo que el usuario no puede consultar. La prueba negativa debe comprobar tanto la respuesta visible como que no se haya recuperado contenido indebido.
Pruébalo con un caso pequeño
Diseña una prueba negativa: qué respuesta y qué registro esperarías sin permiso.
Para revisar tu ejercicio, distingue qué dato entra, qué resultado esperas y con qué evidencia lo comprobarías. Si aparece una duda, anótala como tal en lugar de completar el dato. El propósito es detectar una decisión concreta que puedas justificar, no obtener una respuesta que solo suene convincente.
Cómo leer el esquema
Proteger también citas, cachés y registros; no basta un filtro visual.
Fuentes
Documentación original utilizada para los conceptos de este artículo.