An information barrier is a control that has to hold when somebody tests it, whether they meant to or not. Put an AI system across a document estate and you’ve introduced a new way of testing it, one that reaches every document at once and answers in prose instead of handing back a file.
Most vendor conversations deal with this in a single sentence about permissions being respected. The trouble is that the sentence is true of at least three quite different architectures, and they don’t offer you the same protection.
Three places access can be enforced
The strongest arrangement is separate indexes, where each matter or client is indexed on its own and a query only ever reaches the indexes that user can get to. It’s also the most operationally awkward: every new matter means a new partition, and questions that span two matters become impossible. Depending on the firm, that’s either the point or a serious limitation.
The usual answer is enforcement at retrieval. One index, but the retrieval step filters by the user’s entitlements before it selects anything, so the model only ever receives material that user could have opened themselves. That’s a real control, provided the entitlements it’s checking are actually current.
The one to watch for is filtering after the fact, where retrieval runs unrestricted and the results the user shouldn’t see get stripped out of what’s displayed. The model has already read the restricted passages by then, and a generated answer can carry their substance without citing them. The citation list looks clean; the answer isn’t.
That third pattern doesn’t always get described as what it is, and you can’t tell which one you’re looking at from the interface. You have to ask.
The test that settles it
Take a document only one person can access. Ask a question whose answer appears in that document and nowhere else. Then ask it as somebody who doesn’t have access.
What should come back is a straightforward inability to answer. If the substance turns up, cited or not, the barrier isn’t holding, whatever the architecture diagram says.
Then run the harder version, which is the one that catches most systems: revoke access to a document somebody previously had, and immediately ask again. Anything checking entitlements at index time rather than query time will carry on answering from it, sometimes right up until the next re-index runs.
Entitlements go stale, and that’s the real failure
In practice most barrier failures aren’t architectural at all. They’re a permission that was perfectly correct when the index was built and isn’t correct now, because somebody changed teams, a matter closed, a secondee left, or a document got reclassified.
So ask when entitlements are read. Reading them at query time from the system of record is a materially different thing from copying them into the index overnight. Ask what happens in the window between a change and the next index run. And ask whether anything is logged when a restricted passage gets filtered out, because a filter that fires silently gives you no way of noticing that it’s firing constantly.
Privilege isn’t the same question as access
A document being privileged and a document being restricted are two different things, and access control on its own doesn’t preserve privilege.
The first is what happens to output derived from privileged material. Does it inherit that character, and how is it labelled if somebody saves it? An answer drafted from privileged sources and dropped into a shared workspace has moved that material somewhere new. The second is what leaves the environment at all: prompts, retrieved passages and outputs may pass to a model provider, and that path needs stating for the specific configuration you’re deploying rather than in general terms.
Those are questions for your own counsel rather than for a vendor’s website. What the vendor owes you is a precise account of where the data goes in each configuration, so that the question can be answered at all.
Worth writing down before you deploy
Where enforcement happens, and evidence that somebody tested it by revoking access rather than just describing it. Where entitlements are read from and how current they are. What happens to output derived from restricted or privileged sources. Which parties process prompts, passages and outputs, and where those parties sit. And who reviews an answer before it informs a decision.
All of it is answerable, and it’s fair to ask. It just rarely gets asked in that form. A vendor who can’t answer precisely has told you something.
The data-flow checklist covers the processing side properly, and the legal document work guide has the wider evaluation approach.
