Ask a legal AI vendor how it handles matter isolation and you will usually be told about role-based permissions, encryption at rest and single sign-on. None of that is wrong. All of it answers a different question from the one being asked.

Two different questions

Access control asks whether a person can open a document they should not open. It is a question about identity and permission, and the industry has been answering it competently for thirty years.

Isolation asks whether information from one matter can reach another by any route at all — including routes that involve no person opening anything. It is a question about the shape of the system, and it is the question AI made urgent.

The pathways a model adds

Traditional software moves information along paths you can enumerate: a query, a report, an export. A model-based system adds several more, and each one has produced a real incident somewhere in enterprise software.

  • Context: whatever is assembled into the prompt, including material a retrieval step chose on the model's behalf
  • Retrieval indexes: embeddings and search structures built across a corpus, which do not respect a boundary they were not built to respect
  • Caches: prompt and response caching keyed on content rather than on matter
  • Training and fine-tuning: the pathway most vendors now contractually exclude, and the only one most buyers ask about
  • Operational data: logs, traces, error reports and evaluation samples, which routinely contain the prompt that caused them

A vendor can hold a defensible position on training and still be exposed on the other four. When a buyer's diligence covers only the pathway that appears in the marketing, the diligence is measuring the wrong thing.

What a conflicts wall means when a model is in the room

Firms already know how to build an ethical screen. Model Rule 1.9(c) prohibits using information relating to a former representation to that client's disadvantage; Rule 1.10 governs when a screen can cure imputed disqualification. Those rules assume the information moves through people, and a screen is built to stop people.

A retrieval layer is not a person. If the index it searches spans matters, the screen has a hole in it that no amount of user-level permission fixes — and the hole is worse than a leak, because the output is fluent, unattributed and arrives without any indication of where it came from. The practical test is simple: can the system explain, for any sentence it produced, which documents were in front of it? If it cannot, no one can audit the screen.

How to test the claim

Four questions separate an architectural answer from a policy one. Where is the boundary enforced — in application code, or beneath it? Is retrieval scoped per matter at index time, or filtered after the fact? What happens to a matter's context, cache and index at close? And can the firm produce the full context supplied to the model for a given output, without asking the vendor?

Matter isolation is not a feature you add to a legal AI platform. It is a constraint you design the entire architecture around.

Filtering after retrieval is the answer to listen for. It means the boundary lives in the same code path as the feature work, where a change made under deadline can quietly move it.

Why shared infrastructure struggles here

Multi-tenant economics depend on sharing: shared indexes, shared caches, shared model capacity, shared operational tooling. Every one of those is a place where a boundary has to be re-implemented and re-tested. It can be done, and some vendors do it well. It is simply a harder problem than the same guarantee on infrastructure where nothing is shared because there is no one to share it with.

That is the real argument for local deployment on this point. Not that a firm's engineers are better than a vendor's, but that the guarantee has fewer moving parts, and a guarantee with fewer moving parts is one a firm can actually verify.