Permisos RAG para chatbots de sitios web: cómo controlar el acceso a los documentos de forma segura

Un chatbot para sitio web puede consolidar respuestas procedentes de páginas de preguntas frecuentes, documentos de productos y fuentes de conocimiento internas. Esto resulta útil... hasta que esa misma base de conocimiento contiene contenidos que no están destinados a todo el mundo. En ese punto, la seguridad de una respuesta no depende únicamente de la calidad del modelo de lenguaje, sino del paso de recuperación (retrieval) previo: ¿qué documentos tiene permitido ver esta consulta concreta?

Los permisos RAG vinculan identidades, roles o grupos verificados con metadatos en los documentos. El chatbot solo recibe fuentes que ya han sido filtradas. El objetivo es deliberadamente estricto: no se trata de que un modelo decida a partir del prompt si algo es confidencial. La aplicación limita el contexto permitido, documenta esta decisión y elige una alternativa segura en caso de incertidumbre.

Por qué las reglas del prompt no sustituyen al control de acceso

Una instrucción del sistema como «No facilites información interna» es útil, pero no constituye una capa de permisos. Si un documento no autorizado llega al contexto, la respuesta puede resumirlo, revelarlo de forma indirecta o reconstruirlo si se le pregunta. Asimismo, la verificación posterior del texto llega demasiado tarde y es propensa a errores. Por tanto, la seguridad empieza antes de la generación e, idealmente, antes de la ordenación por relevancia de los resultados.

Azure AI Search describe el recortes de seguridad (Security Trimming) como un patrón de filtrado: los documentos llevan valores de identidad o grupo; la consulta solo contiene los elementos principales (principals) de la persona que realiza la solicitud. De manera similar, Amazon Bedrock señala que los filtros de recuperación compatibles con ACL no sustituyen a la autenticación. Su aplicación debe verificar primero la identidad por sí misma de forma fiable y transmitir únicamente un contexto verificado.

Los cuatro pilares de una solución sólida

1. Verificar la identidad y la sesión en el lado del servidor

Una ventana de chat pública normalmente no tiene derechos sobre documentos. Solo debe acceder a fuentes públicas. En cambio, para un portal de clientes o una zona de empleados, la persona se identifica a través de su inicio de sesión existente. Extraiga el rol, la organización y los grupos relevantes en el lado del servidor a partir de la sesión o de un token firmado. Nunca confíe en un campo enviado libremente por el navegador como role=admin ni en un mensaje de chat que afirme una pertenencia.

2. Mantener metadatos de permisos con cada fuente

Cada fragmento (chunk) necesita, además del texto, la URL y la fecha de actualización, información de acceso transparente: por ejemplo, audience=public, un ID de inquilino (tenant ID), una lista de grupos permitidos o una clasificación. Estos metadatos deben proceder de la misma fuente funcional que los permisos del documento. Una hoja de cálculo independiente que solo se actualice de vez en cuando genera desviaciones peligrosas. Por lo tanto, al añadir nuevos documentos o modificar derechos de grupo, la sincronización de metadatos debe formar parte del flujo de trabajo de publicación o rastreo (crawl).

3. Filtrar antes de la clasificación (ranking)

La consulta construye un filtro a partir del contexto verificado. Solo después se evalúan las coincidencias semánticas o híbridas. De este modo, un manual confidencial no puede destacar como el resultado más relevante para ser eliminado posteriormente. En entornos con múltiples inquilinos, el ID de inquilino es un filtro obligatorio, no una mera señal de clasificación. Para datos personales o de especial protección, también se recomienda disponer de un área de datos dedicada en lugar de una colección compartida y filtrada solo de forma lógica.

4. Registrar las fuentes y las decisiones

Para la asistencia técnica y el análisis de incidentes, las transcripciones de chat por sí solas resultan insuficientes. Para cada consulta, se debe poder rastrear qué atributos de identidad no sensibles se utilizaron para crear el filtro, qué clase de filtro se aplicó, cuántos resultados quedaron tras el filtrado y qué fuentes llegaron realmente al prompt. No almacene contenido completo ni tokens innecesarios. Un evento de auditoría con minimización de datos permite detectar errores sin convertir la monitorización en un segundo punto de fuga de información.

Un procedimiento práctico para equipos web

1. Asigne cada fuente de conocimiento a un público objetivo claro: público general, clientes, socios, equipo interno o un inquilino concreto.
2. Defina qué atributos de sesión (claims) demuestran la pertenencia a ese público objetivo. Los grupos procedentes del sistema de identidad son más sólidos que las entradas de formulario de libre elección.
3. Incorpore estos atributos en el lado del servidor dentro del filtro de recuperación y admita solo un conjunto reducido y conocido de campos de filtrado.
4. Realice una conciliación en cada rastreo: los documentos nuevos, modificados o eliminados también necesitan que se actualicen sus metadatos de permisos.
5. Proporcione al modelo únicamente los resultados filtrados, junto con una instrucción clara de no adivinar la información que falte.
6. Si no hay coincidencias, si las fuentes son contradictorias o si los permisos no están claros, redirija a un canal de contacto seguro.

Este flujo complementa la estructuración descrita en nuestro artículo sobre fragmentación (chunking) en RAG: una buena división de contenidos mejora los resultados, pero no sustituye al control de acceso. Del mismo modo, disponer de fuentes actualizadas sigue siendo fundamental; un estado de permisos desfasado representa un problema de calidad y de seguridad al mismo tiempo.

Error común: filtrar después de la recuperación

Un diseño erróneo muy frecuente consiste en que el sistema recupera los diez mejores resultados, comprueba sus etiquetas a continuación y elimina los documentos problemáticos. Esto puede parecer suficiente a primera vista, pero falla debido a efectos secundarios. El resultado no autorizado puede haber quedado registrado en logs, memorias caché o en salidas de depuración (debug). Además, su puntuación de relevancia altera la selección de los demás resultados. La alternativa adecuada es aplicar un filtro en la propia solicitud de recuperación que solo admita como candidatos los documentos para los que se tenga permiso.

Otro error común es confiar ciegamente en la función ACL de un proveedor. La documentación del fabricante puede indicar claramente que un servicio tiene en cuenta las ACL durante la búsqueda, pero no que verifique por sí mismo la autenticidad del contexto de usuario transmitido. Por lo tanto, compruebe con precisión: ¿Quién autentica a la persona? ¿De dónde proceden los grupos? ¿Cuándo se sincronizan los permisos con el sistema de recuperación? ¿Qué ocurre si faltan metadatos?

Acción segura por defecto (fail-closed): qué hacer ante la duda

Si falta un atributo (claim), si hay una fuente no sincronizada o se produce un error de recuperación, el chatbot no debería intentar una búsqueda más amplia. Utilice una respuesta neutral: el contenido solicitado no está disponible en el contexto de acceso actual; un agente humano puede verificar el acceso. Esto no es una deficiencia en la experiencia de usuario conversacional (Conversational UX), sino un límite honesto. El artículo sobre la transferencia a un agente humano (Human Handoff) muestra cómo estructurar dicha derivación de forma concreta y sin callejones sin salida.

Para los contenidos públicos se aplica la misma idea a menor escala: si las fuentes disponibles no son suficientes, el bot debe indicar la incertidumbre, ofrecer enlaces verificados o proporcionar una vía de contacto, en lugar de inventar detalles plausibles. Esto reduce las alucinaciones y evita que una respuesta supuestamente útil sugiera una autorización incorrecta.

Casos de prueba imprescindibles antes del despliegue

Una prueba de permisos no es una comprobación puntual por parte del administrador. Cree un conjunto de prueba de referencia (Golden Set) con preguntas idénticas para varios roles: visitante no registrado, cliente registrado, socio autorizado, usuario bloqueado y administrador. Defina para cada combinación las fuentes esperadas, no solo el texto de respuesta previsto. Pruebe también los cambios de grupo, las sesiones expiradas, los documentos eliminados, la ausencia de metadatos ACL y la caída del servicio de recuperación.

Verifique al menos cuatro aspectos en los resultados: que no llegue ninguna URL o ID de documento no autorizado al contexto; que las fuentes permitidas sigan estando accesibles; que la respuesta no mencione contenidos de documentos filtrados; y que la respuesta alternativa siga siendo clara. Incorpore estas comprobaciones a sus pruebas de calidad de respuesta para medir conjuntamente la seguridad y la calidad técnica.

Aplicar la protección de datos y la transparencia de forma pragmática

Los datos de permisos son, en sí mismos, información protegida. En la medida de lo posible, utilice identificadores técnicos estables en lugar de nombres en texto claro dentro de los metadatos de recuperación. Limite los registros de auditoría al propósito, el periodo de tiempo y los atributos estrictamente necesarios. Informe a los usuarios de manera transparente cuando un chatbot acceda a su área privada y proporcione una vía humana para resolver dudas sobre accesos. Este artículo no sustituye a un asesoramiento legal personalizado; los plazos concretos de conservación de datos y las bases jurídicas dependerán de cada contexto de uso.

Desde el punto de vista técnico, es conveniente delimitar claramente las responsabilidades: los responsables del contenido gestionan los públicos objetivos, el equipo de identidad se encarga de las afirmaciones y la verificación de sesiones, y el equipo de producto mantiene probados los filtros y las respuestas alternativas. De este modo, la base de conocimiento no se convierte en un pozo de datos incontrolado, sino en una fuente cuyo alcance es siempre transparente y auditable.

Lista de comprobación antes del lanzamiento

• ¿Está cada fuente no pública asignada a un rol, grupo o ID de inquilino?
• ¿Procede el contexto de la consulta de una identidad verificada en el lado del servidor?
• ¿Se aplica el filtro antes de la recuperación y la clasificación?
• ¿Se sincronizan de forma conjunta las modificaciones de derechos y los rastreos?
• ¿Existen pruebas de regresión basadas en roles con las fuentes esperadas?
• ¿Cualquier estado desconocido o erróneo deriva en una transferencia segura a un agente humano?
• ¿Son los registros respetuosos con la minimización de datos y suficientes para el análisis de errores?

Conclusión

Un buen chatbot para sitios web no responde a todas las preguntas de cualquier persona. Solo muestra las fuentes que se corresponden con el contexto de acceso verificado y se mantiene deliberadamente cauto en caso de duda. Comience con una matriz de fuentes reducida, un filtro en el lado del servidor y unos pocos roles de prueba bien definidos. Posteriormente, podrá ampliar gradualmente los metadatos de permisos, las auditorías y la sincronización, sin delegar la seguridad en la redacción de los prompts.

Fuentes

• Microsoft Learn: Security Filter Pattern in Azure AI Search
• Microsoft Learn: Document-level access control in Azure AI Search
• Amazon Bedrock: ACL awareness enablement
• Amazon Bedrock: Document-level access controls