Access control and data governance for enterprise AI.

An enterprise that lets an AI system retrieve or synthesize knowledge across teams isn't really solving a search problem. It's extending every source system's authorization, confidentiality, privacy, retention, and evidence obligations into a new probabilistic execution layer. The relevant bar isn't "does RAG work" — it's "can the AI only retrieve, transform, retain, and disclose what this user is allowed to know, for the allowed purpose, with auditable evidence."

That bar follows directly from frameworks most enterprises already have to satisfy: SOC 2 and ISO/IEC 27001 require a documented, risk-based access-governance control environment; NIST SP 800-53 and FedRAMP give the most explicit control catalog for access, audit, cryptography, and information flow; GDPR and HIPAA add purpose limitation, minimum-necessary use, and deletion obligations that apply directly to AI retrieval and memory. None of these were written with RAG in mind — but none of them stop applying just because the retrieval layer got smarter.

Department access isn't the same as AI-processing consent

The single most common design mistake: treating "the user can see this file in the source app" as equivalent to "the AI may summarize, transform, retain, or pass it to a third-party model." Those are different questions. GDPR's purpose limitation and HIPAA's minimum-necessary standard both say so explicitly — and almost no vector database enforces that distinction natively.

Need-to-know access, RBAC, and ABAC aren't competing models — they're layers. RBAC handles stable departmental entitlement (Finance, HR, Legal); ABAC handles the runtime narrowing AI retrieval actually needs (region, matter number, clearance label, purpose, time). The practical answer for cross-team AI is RBAC for baseline entitlement plus ABAC for retrieval-time evaluation — re-checked at prompt-assembly time, not only at indexing time.

Where current products actually stand

Enterprise-search platforms (Glean, Azure AI Search, Google Agent Search, Amazon Bedrock Knowledge Bases) have gotten genuinely good at permission-aware retrieval, citations, and audit logging. Vector databases (Pinecone, OpenSearch, Weaviate, Qdrant, Milvus) are strong on storage security but generally leave source-ACL mirroring, purpose/consent enforcement, and training-data separation to the application layer above them.

The gap that shows up across almost every product, regardless of category, is the same one auditors care about most: purpose-aware governed disclosure. Systems can mirror ACLs and isolate tenants. Far fewer of them decide whether someone who can see a document is also allowed to have it summarized, stored in conversation memory, or reused in training. That decision still has to be architected on top.

A staged hardening sequence, not a big-bang rollout

The practical risk tradeoff is blunt: optimize purely for speed and you ship an AI that's useful but over-entitled, weakly auditable, and painful to clean up later. Optimize purely for airtight compliance up front and you risk shipping nothing. The lowest-risk sequence:

1. Identity-bound retrieval first — SSO/MFA and query-time policy evaluation before retrieval, not UI hiding or post-hoc redaction.
2. Portable governance metadata second — classification, source ACLs, retention, and consent basis travel with every chunk, not just the source system.
3. Training/inference separation third — default to no training on enterprise content unless a specific dataset and purpose are explicitly approved.
4. Provenance and audit as first-class outputs — every answer carries source evidence and a policy trace, not just a citation link.