RAG interno con permisos antes de la búsqueda

El problema no consiste solo en encontrar un fragmento relevante

Un sistema de RAG interno combina la búsqueda de documentos con la generación de texto. La búsqueda semántica puede encontrar contenido relacionado aunque las palabras de la pregunta no aparezcan literalmente. En índices vectoriales, los archivos se dividen en fragmentos, se transforman en representaciones consultables y se asocian con metadatos que pueden utilizarse en filtros. Esto resuelve el descubrimiento, pero no la autorización.

El error arquitectónico más peligroso es buscar en todo el repositorio e intentar eliminar después los resultados prohibidos. La fuente citada no establece por sí sola los riesgos específicos para registros y respuestas intermedias que se describen aquí. Como recomendación de seguridad independiente, trata el permiso como una condición de la búsqueda, no como una limpieza posterior, porque la información restringida podría entrar en el contexto del modelo, los registros, las métricas o una respuesta intermedia.

• Identidad: quién hace la pregunta.
• Alcance: qué documentos puede consultar en ese momento.
• Evidencia: qué fragmentos respaldan la respuesta.
• Decisión: si existe base suficiente para responder o se debe rechazar la consulta.

Fuentes y referencias: [1]

Flujo propuesto: autorización antes de la recuperación

El flujo comienza fuera del modelo. El sistema de identidad proporciona un identificador, grupos, función, región y otros atributos necesarios. Como recomendación independiente de implementación, más allá de lo establecido por la fuente citada, un servicio de autorización puede convertir esos datos en un filtro de búsqueda. Por ejemplo, puede permitir documentos clasificados para uso interno, pertenecientes a Recursos Humanos y a la región Sur, si la persona pertenece al grupo correspondiente.

Cada documento debe incluir metadatos de control, como propietario, área, clasificación, región, vigencia e identificador de la política de acceso. El filtro debe aplicarse en el mecanismo de recuperación, antes de seleccionar los fragmentos que llegarán al contexto. Si el mecanismo no ofrece esa restricción, pueden separarse los índices por dominio de acceso o utilizar una capa confiable que entregue al buscador únicamente identificadores autorizados.

Después de la recuperación, la aplicación debe validar otra vez los resultados devueltos. Como recomendación independiente de implementación, más allá de lo establecido por la fuente citada, esta segunda comprobación puede detectar documentos mal clasificados, permisos modificados y errores de integración. Todo resultado cuya autorización no esté confirmada debe descartarse y el evento debe registrarse para su investigación técnica, sin enviar su contenido al modelo.

• Autenticar a la persona solicitante.
• Calcular los permisos mediante el servicio de autorización.
• Traducirlos en filtros de atributos o índices autorizados.
• Ejecutar la búsqueda semántica y, cuando sea necesario, combinarla con términos exactos.
• Validar cada resultado antes de construir el contexto.

Fuentes y referencias: [1]

La evidencia debe acompañar a la respuesta

El modelo no debería recibir solo texto aislado. Cada fragmento debe conservar su archivo de origen, identificador del documento, sección, versión, fecha de vigencia y atributos que justificaron su inclusión. La aplicación puede mostrar una referencia legible, como el nombre de la política, su versión y la sección correspondiente. El objetivo es permitir que la persona entienda el origen de la afirmación autorizada sin exponer el repositorio.

Conviene separar relevancia y suficiencia. Un fragmento puede parecer relacionado con la pregunta sin establecer la regla solicitada. El sistema debe exigir evidencia suficiente para cada afirmación importante, sobre todo cuando hay documentos en conflicto o versiones diferentes.

Una salida estructurada puede incluir respuesta, fuentes, lagunas, conflicto detectado y decisión de rechazo. Esto limita la posibilidad de inventar referencias o mezclar instrucciones encontradas en los documentos con las reglas del sistema.

• Mostrar solo fuentes utilizadas y autorizadas.
• Preferir la versión vigente cuando exista información sobre vigencia.
• Señalar conflictos entre políticas.
• No tratar el nombre de un archivo como prueba de su contenido.

Fuentes y referencias: [1][2]

Rechazar también es una salida normal

El rechazo corresponde cuando no existe evidencia autorizada, los fragmentos son insuficientes, la pregunta exige una interpretación que los documentos no ofrecen o hay versiones incompatibles sin un criterio claro de precedencia. Una respuesta breve y específica es preferible a una formulación plausible sin fundamento. Puede indicar que no se encontró una política autorizada suficiente y señalar qué datos faltan, sin revelar documentos bloqueados.

Los documentos recuperados deben tratarse como datos, no como instrucciones operativas. Un documento interno puede contener frases que intenten cambiar el comportamiento del sistema, solicitar datos de otros empleados o activar llamadas a herramientas. Las reglas de autorización deben permanecer fuera del control del modelo. Las entradas no confiables deben pasarse como datos y los formatos estructurados deben limitar lo que puede salir de cada etapa. Estas medidas reducen el riesgo de inyección indirecta, pero no eliminan la necesidad de limitar el acceso y probar casos adversarios. No uses el rechazo para ocultar un fallo silencioso. Distingue entre documentos ausentes, falta de permiso, baja relevancia, conflictos entre versiones y errores técnicos. Estas categorías orientan el mensaje al usuario y aceleran la corrección del catálogo.

• Sin un fragmento autorizado, no afirmar cuál es la regla.
• Sin cobertura suficiente, explicar la laguna.
• Si hay conflicto, presentarlo sin elegir por cuenta propia.
• Ante un fallo técnico, informar que la consulta no pudo completarse.

Fuentes y referencias: [2]

Ejemplo hipotético: una política interna

Imagina una empresa con políticas de viajes separadas por país y nivel de puesto. Una persona pregunta si puede solicitar el reembolso del alojamiento para un viaje a Chile el próximo mes. El sistema identifica a la persona, consulta sus grupos y confirma que puede acceder a las políticas de viajes de Brasil y Chile, pero no a los documentos de dirección. El servicio de autorización genera un filtro para viajes, Chile, la clasificación permitida y los documentos vigentes en la fecha del viaje.

La búsqueda encuentra la política de alojamiento de Chile y un procedimiento general de rendición de gastos. La aplicación envía al modelo solo los fragmentos autorizados, con sus identificadores y fechas de vigencia. La respuesta puede explicar el límite descrito y señalar las políticas utilizadas. No debe concluir que un gasto está permitido solo porque una política menciona el alojamiento.

Si la política cubre el alojamiento, pero no aclara si el viaje necesita aprobación previa, la respuesta debe declarar esa laguna. Si hay una política antigua y otra actual con reglas distintas, el sistema debe señalar el conflicto o aplicar una regla de precedencia definida previamente. Este ejemplo es un diseño hipotético, no una orientación jurídica ni una interpretación normativa.

• Una pregunta autorizada no significa que la respuesta esté autorizada automáticamente.
• La fuente debe respaldar la afirmación concreta, no solo el tema general.
• La respuesta debe separar la regla, la laguna y el conflicto.

Cómo decidir si el diseño está listo

Antes de habilitar el sistema, construye pruebas con preguntas habituales, documentos similares, permisos cruzados, usuarios sin acceso, versiones antiguas, preguntas ambiguas e intentos de introducir instrucciones dentro de los archivos. Mide por separado recuperación, control de acceso, fidelidad a las fuentes y rechazo. Una sola puntuación puede ocultar una filtración o una respuesta sin evidencia.

Repite las pruebas después de cambios en particiones, metadatos, ordenamiento, prompt o modelo. Como recomendación de diseño independiente, registra la identidad utilizada, los filtros, los identificadores de documentos, la decisión de rechazo y las fuentes presentadas. Evita registrar más contenido restringido del necesario. La evaluación debe incluir errores tipográficos, múltiples intenciones e intentos de obtener información de otro grupo.

• Prueba con usuarios con permisos diferentes ante la misma pregunta.
• Comprueba que los documentos revocados dejen de aparecer.
• Verifica que cada afirmación importante tenga una fuente autorizada.
• Cuenta por separado rechazos correctos y errores técnicos.
• Incluye inyección dentro de documentos y preguntas.

Fuentes y referencias: [3]