Useful access governance is designed by role, exception, and evidence, not by improvised folders nobody reviews afterward.
In this article +
Your lists
Start from access decisions, not from storage
The right question is not where the document lives, but who should see it, for what purpose, and under which condition. When design starts from inherited folders instead of usage rules, the result is bloated permissions that are hard to audit.
Map real roles, domains, and exceptions
Build a simple matrix between profiles, document types, and sensitivity level. Then add justified exceptions. If exceptions appear first, the scheme never stabilizes and the team starts asking for direct access as the default.
Define base access by role and business unit.
Mark critical documents by sensitivity or legal obligation.
Require reason and expiration for exceptional access.
Carry permissions into the retrieval layer
Restricting the source folder is not enough. The search or RAG system must enforce the same policy during indexing, ranking, and answer generation. A citation to an unauthorized document is just as serious even if the full PDF never opens.
Design joiner, mover, leaver, and review processes
Governance fails less because of the initial rule than because of later neglect. Every onboarding, role change, or exit should update permissions, and every sensitive domain needs recurring review to detect orphaned access.
Audit exceptions and hard decisions
You do not need to review every access every week. You do need to review exceptions, the most sensitive domains, and unusual query patterns. That is where the policy proves whether it works in practice or only exists in a slide deck.
We use necessary cookies for the site and, only with your permission, analytics (Google Analytics, Microsoft Clarity and PostHog when enabled) to improve the experience. Cookie policy · Privacy
Cookie settings
Use Activate all / Deactivate all per category. Expand for individual cookies.
kdx-cookie-consent
Kodex (first-party) · localStorage
Recordar categorías de cookies aceptadas o rechazadas (Aceptar / Rechazar / Ajustes).
kdx_session
Kodex (first-party) · cookie HTTP (HttpOnly, SameSite=Lax, Secure en producción)
Mantener la sesión autenticada de la comunidad Kodex (cuenta, listas guardadas, panel).
CDN / sesión de entrega
Infraestructura / CDN · cookie HTTP / sesión
Entrega segura del sitio, rendimiento y protección básica.
reCAPTCHA
Google · _GRECAPTCHA y relacionadas
Protección antispam en formularios públicos.
kdx-theme-override
Kodex (first-party) · localStorage
Recordar si el usuario forzó tema claro u oscuro.
_ga / _ga_*
Google Analytics 4 · cookie HTTP
Medición agregada de audiencia y uso del sitio (páginas, eventos).
Microsoft Clarity
Microsoft · cookies / almacenamiento de sesión
Mapas de calor, clics y reproducción de sesiones para mejorar UX.
PostHog
PostHog · cookie / localStorage
Analítica de producto y eventos de conversión (si está configurado).