Permission models: the part of enterprise RAG nobody budgets for
Retrieval quality is a solved-enough problem. Permissions are the reason enterprise RAG projects stop: not because they are hard, but because they arrive late and force a rewrite.
What happened
A RAG system is built on a document store, works well, and is about to roll out. Someone asks a reasonable question: can a user in procurement see a document meant for legal? The team adds a filter after retrieval, ships, and the project is quietly frozen three weeks later when an audit finds that ranking signals leaked even where content did not.
Why it matters for deployment teams
Post-filtering is the single most common mistake in enterprise RAG, and it is worse than it looks. Filtering results after the search returns means the search itself ran over documents the user cannot see; the ranking, the counts and the aggregate behaviour all reflect a corpus the user has no right to. Even when nothing is displayed, information has moved.
What to do about it
Store the access control list on every chunk and filter before retrieval, so documents the user cannot see never enter the candidate set. Keep the ACL in the index and treat permission changes as index writes, not as an overnight batch job — a contractor whose access was revoked this morning should not be answerable from the index this afternoon. Test it in CI with three accounts at different access levels asserting that every cited chunk satisfies the caller's ACL.
The organisational half
Someone has to own the mapping between the source system's permission model and yours, and that person is rarely on the engineering team. Identify them in week one. The technical work is a week; the organisational work is the part that takes a quarter, and it is the part that quietly kills projects that looked technically finished.