Capítulo 7 — Implementar el control de acceso
Séptima entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. Los modelos de permisos diseñados para bases de datos relacionales y sistemas de ficheros no encajan del todo en la recuperación. La unidad de acceso ya no es una fila ni un fichero, sino un embedding — y un embedding puede filtrar el original vía similitud incluso cuando el propio documento está restringido.
Por qué existe este capítulo
El Capítulo 6 produjo el modelo de amenazas. El control más importante que de él se deduce — y el que la mayoría de los sistemas tempranos en producción hace mal — es el control de acceso en la capa de recuperación, para que el LLM nunca vea contenido que el usuario no pueda ver. La alternativa ingenua, "filtrar en tiempo de generación", construye un confused deputy: el modelo ya ha leído los documentos restringidos y filtrará su sustancia vía paráfrasis.
Este capítulo recorre los cuatro mecanismos que componen una pila funcional de control de acceso — ACLs a nivel de documento como cimiento, RBAC integrado con las etiquetas de sensibilidad ya existentes de la empresa, ReBAC para la realidad de forma relacional del conocimiento empresarial, y la disciplina pre-filter frente a post-filter que corre por debajo de todos ellos.
7.1 ACLs a nivel de documento y filtrado por metadatos
Cada chunk sabe quién está autorizado a verlo. La implementación es directa de describir; los modos de fallo son lo bastante sutiles como para que casi cualquier sistema temprano en producción se equivoque al menos una vez. Tres detalles importan más. Granularidad: un informe largo puede tener un resumen público y un apéndice confidencial, y un único ACL a nivel de documento copiado uniformemente hacia abajo a los chunks o bien comparte de más el apéndice o bien comparte de menos el resumen. El patrón que escala es llevar permisos a nivel de sección a través del parsing consciente del layout.
Frescura: los permisos cambian. Cocer el ACL en el chunk en tiempo de indexación y no reevaluarlo nunca produce un sistema que miente. Guarda un identificador estable en los metadatos del chunk y resuelve el ACL vivo contra el sistema fuente en tiempo de consulta, detrás de una caché de TTL corto. Espacio negativo: si la respuesta vive en un documento restringido, el sistema no debería alucinar ni decir con confianza "no lo sé" — debería decir "hay material sobre este tema que no estás autorizado a ver". Eso requiere o bien una segunda llamada sin filtrar o bien una base de datos vectorial que distinga "sin coincidencia" de "coincidió pero filtrado", y la mayoría de las implementaciones lo aparcan.
7.2 RBAC y las etiquetas de sensibilidad de Microsoft Purview
RBAC comprime el espacio de permisos — en lugar de millones de aristas usuario-a-documento, la política se reduce a unas cuantas centenas de aristas rol-a-clasificación, lo que es a la vez auditable y mantenible. Encaja limpiamente con RAG cuando la empresa ya corre sobre ello. En entornos Microsoft eso significa grupos de Entra ID y etiquetas de sensibilidad de Purview: Public, General, Confidential, Highly Confidential, con sub-etiquetas opcionales. La etiqueta se mueve con el documento; el parser la lee en tiempo de indexación y escribe el ID estable de etiqueta en los metadatos del chunk.
La integración es directa, la deriva no. Si el indexador corre como cuenta de servicio que puede descifrar todo, pero el sistema de recuperación hace cumplir un filtro basado en rol sobre el índice, un documento reetiquetado de General a Confidential no verá sus chunks ya indexados reetiquetados a menos que el indexador note el cambio. Los sistemas que hacen esto bien corren una reconciliación continua contra la fuente. Los sistemas que lo hacen mal descubren la deriva durante una auditoría, y el hallazgo es severo.
7.3 ReBAC con Zanzibar y SpiceDB
RBAC no puede expresar "cualquiera de Ventas que esté también asignado al deal de Acme Corp". Eso requiere razonar sobre una relación entre el usuario y el recurso, no sólo sobre un rol. El control de acceso basado en relaciones, formalizado en el paper de Zanzibar de Google y disponible como open-source en SpiceDB y OpenFGA, guarda un grafo: "Alicia es miembro de Ingeniería", "Ingeniería es visualizadora de la carpeta Specs", "Spec-101 está en Specs". Las comprobaciones de permiso se vuelven recorridos del grafo.
El patrón de integración con RAG es limpio. SpiceDB recibe la pregunta ¿qué documentos puede ver este usuario? y devuelve una lista de IDs de documento; el sistema de recuperación pasa esa lista como filtro de metadatos a la búsqueda vectorial. Los zookies de Zanzibar permiten que la llamada de recuperación insista en una consistencia al menos tan reciente como un acceso recién concedido — un usuario añadido a un proyecto a las 10:00 y preguntando a las 10:01 verá los nuevos documentos. El coste operativo es que SpiceDB se vuelve una dependencia crítica del camino de consulta que necesita HA y caché agresiva de TTL corto de las listas de documentos por usuario. Los sistemas maduros suelen usar a la vez RBAC y ReBAC — RBAC para la política amplia de sensibilidad, ReBAC para la política fina de relación, combinados como intersección de los conjuntos permitidos.
7.4 Pre-filter, post-filter y la disciplina que corre debajo de los dos
El pre-filtering aplica el predicado de autorización antes de la búsqueda vectorial — el índice restringe primero el conjunto candidato, luego corre la similitud sobre la restricción. Es conceptualmente limpio y el valor por defecto más seguro, pero su rendimiento depende de la estructura del índice. HNSW con un filtro muy selectivo puede degradarse abruptamente a medida que el recorrido del grafo pasa por muchos nodos no coincidentes; las variantes filterable-HNSW de Weaviate y Qdrant y los namespaces por inquilino de Pinecone y Milvus mitigan pero no eliminan el coste.
El post-filtering invierte el orden. Velocidad plena de HNSW, seguridad más débil: la fuga del top-K, la fuga de información por timing, y la fuga de corrección cuando todo el top-K se filtra por completo. La respuesta pragmática en producción es estratificar ambos — pre-filter sobre el predicado más grueso y rápido (inquilino, rol amplio), post-filter sobre los predicados precisos costosos (listas de SpiceDB, etiquetas de Purview), y over-fetch el top-50 en vez del top-10 para que el post-filter aún deje un conjunto ordenado completo. Dos sitios más filtran: la plantilla de prompt que cita el título de un documento confidencial, y la caché de respuesta indexada sólo por la cadena de la consulta. Ambos tienen que ser parte de la superficie de autorización.
Lo que prepara el Capítulo 7
El control de acceso responde a quién puede ver qué. Asume que hay algo que restringir. No pregunta si el chunk debería haberse embebido en la forma en que lo fue — si los nombres de cliente, los números de la seguridad social, las rutas de código propietario deberían estar sentados en el almacén vectorial siquiera, esperando a que la autorización correcta los saque a la luz. Esa es la pregunta de la anonimización, y es el tema del próximo capítulo.
Próximamente — Capítulo 8: Anonimización de datos en la pipeline RAG. Pre-generación frente a post-generación, enmascaramiento frente a reemplazo sintético frente a privacidad diferencial, y la disyuntiva utilidad-privacidad que cada elección tiene que navegar.
