c3.3 Aplica control de acceso a la recuperación con filtrado por metadatos

La capa de recuperación es un límite de control de acceso

En una aplicación de RAG, el modelo responde usando lo que el recuperador extrae del knowledge base. Si la recuperación devuelve un documento que el usuario no debería ver, el modelo lo resumirá con gusto en la respuesta: una fuga de datos sin rastro obvio. Así que la recuperación no es solo un problema de relevancia; es un límite de autorización. El filtrado por metadatos es la forma de imponerlo: adjunta atributos (departamento, clasificación, tenant, fechas de vigencia) a cada vector y luego filtra cada consulta por los permisos del usuario que la solicita.

Adjunta metadatos en la ingesta

Cada documento fuente lleva un archivo lateral de metadatos (por ejemplo, document.pdf.metadata.json) con los atributos por los que filtrarás:

{
  "metadataAttributes": {
    "department": "finance",
    "classification": "confidential",
    "tenant_id": "acme-123"
  }
}

Estos se convierten en campos filtrables en cada vector derivado de ese documento.

Filtra cada consulta por los permisos del llamador

En Retrieve / RetrieveAndGenerate, pasa una retrievalConfiguration cuyo filtro se construya a partir de los atributos del usuario autenticado, nunca de entradas proporcionadas por el usuario. Combina condiciones con andAll para que todas deban cumplirse:

{
  "retrievalConfiguration": {
    "vectorSearchConfiguration": {
      "filter": {
        "andAll": [
          { "equals": { "key": "tenant_id",     "value": "acme-123" } },
          { "equals": { "key": "department",     "value": "finance" } },
          { "notEquals": { "key": "classification", "value": "restricted" } }
        ]
      }
    }
  }
}

Bedrock admite operadores como equals, notEquals, in, greaterThanOrEquals y los combinadores booleanos andAll / orAll.

Construye el filtro del lado del servidor a partir de una identidad de confianza

La seguridad de este control descansa por completo en de dónde vienen los valores del filtro. Resuelve tenant_id, department y el nivel de acceso a partir de la identidad verificada del llamador (los claims del JWT / la sesión), en tu backend, nunca dejes que el cliente envíe el filtro. Si un usuario pudiera fijar su propio tenant_id, el límite desaparece.

Nota de nomenclatura: mantén las claves de metadatos consistentes en todos los documentos; un error tipográfico (dept vs department) excluye o filtra documentos en silencio. Valida el esquema de metadatos en la ingesta.