Private Cloud or Multi-Tenant: What Legal AI Data Isolation Actually Protects

The legal AI isolation models, defined

Four models cover most legal AI: multi-tenant, where many customers share infrastructure separated by software; logical single-tenant, a dedicated database or namespace on shared compute; dedicated single-tenant, a full instance running only your data; and private cloud or on-premises, infrastructure you control. Isolation strength rises across that list, and so does cost. Ask which one a vendor means ^[1].

The models sit on a spectrum from most shared to most dedicated, and the words vendors use rarely map cleanly onto it, which is why you should ask for the specifics rather than the label.

Where multi-tenant creates privilege risk

Multi-tenant risk is not that sharing is inherently improper; it is that isolation depends entirely on the vendor's software controls being correct and staying correct. A bug, a misconfiguration, or a flawed access check can let one customer's prompt or retrieval surface another's data. For most business software that is an acceptable risk; for privileged client material, it raises the bar on the proof you should demand ^[1].

Multi-tenant architectures are the default for cloud software because they are efficient, and for most data they are perfectly appropriate. The privilege question is narrower: what happens when the software separation fails, and how likely is that.

In a shared system, the wall between customers is code and configuration, not physical or instance-level separation. History across the cloud industry shows those walls occasionally fail through access-control bugs or misconfiguration, and when they do, the exposure is cross-customer by definition. For privileged material, that shifts the analysis: you are relying on the vendor's engineering discipline to protect a duty you cannot delegate.

That does not disqualify multi-tenant tools. It means the confidentiality reasonableness analysis under Rule 1.6 has to account for the model, and the more sensitive the matter, the more you should either demand evidence the controls are sound or move to a more isolated model. Our guide on using AI without waiving privilege covers that broader duty.

What single-tenant and private cloud actually protect

Single-tenant and private-cloud models protect by removing neighbors and, in private cloud, by giving you control of the environment and data residency. A dedicated instance means a cross-customer software bug has no other customer to expose. Private cloud or on-premises adds control over where data physically sits and who can touch it, which matters when a client or regulator requires data to stay in a jurisdiction.

The protection from dedicated models is structural rather than promissory. In a dedicated single-tenant instance, the entire application runs only your data, so the most common multi-tenant failure mode, one customer's data surfacing in another's session, has no pathway because there is no other customer in the instance.

Private cloud and on-premises go further by handing you control of the infrastructure and, critically, of data residency. If a client's outside-counsel guidelines or a regulator require that privileged data never leave a jurisdiction, a model where you control the region and the access is often the only way to make that guarantee real rather than contractual. The trade-off is operational burden: you or the vendor now run more of the stack.

Strong isolation is not automatically the right choice; it is the right choice for sensitive matters and for constraints you cannot meet any other way. The point is to know what each model buys so you are paying for protection you actually need.

How to verify an isolation claim rather than accept it

Verify isolation by asking the vendor to describe the model precisely, name how separation is enforced, and provide evidence it holds. A current SOC 2 Type II or ISO/IEC 27001 report scoped to the product tells you the controls were tested; an architecture description tells you which model you are actually buying. A vendor that cannot do either is asking you to take "isolated" on faith ^[2][3].

Verification turns a marketing word into an assessable fact. Start by asking which of the four models applies to your data specifically, because a vendor may offer several tiers and quote the strongest while selling you the cheapest.

Then ask how the separation is enforced and how it is tested. A current SOC 2 Type II report scoped to the product shows the security controls operated over a period, and an ISO/IEC 27001 certification shows a managed security program; read the scope so it actually covers the service you are buying ^[2][3]. The companion guide on reading a SOC 2 report covers how to check that the controls are real. The strongest posture is one where isolation is not just asserted but attested, with a record you can verify rather than a claim you accept.

Matching the isolation model to your matters

Match the model to sensitivity and constraints, not to habit. Use multi-tenant for low-sensitivity, non-privileged work where cost and speed matter. Step up to dedicated single-tenant or private cloud for privileged, high-stakes, or residency-constrained matters. The decision is per use case, and the same firm can reasonably run different models for different work rather than forcing one choice on everything.

There is no single correct model, only a fit between the matter and the protection. Sort your work by sensitivity and by any hard constraints, then map each band to a model.

Use decision triggers to make the calls consistent. If a matter must be provably walled off from every other client, require single-tenant or dedicated infrastructure rather than logical isolation in a shared instance. If a vendor cannot describe how its isolation is enforced, treat "isolated" as marketing and require the architecture in writing before you rely on it. If a client or regulator requires that data stay in a specific jurisdiction, require private cloud or a region-locked dedicated instance, because multi-tenant SaaS rarely guarantees residency.

Running different models for different work is not inconsistency; it is proportionality. A firm can use a fast multi-tenant tool for internal research and a dedicated or private-cloud environment for privileged client data, and document why each choice is reasonable for the work it covers.

What isolation does not protect against

Isolation answers one question: whether another tenant's data can reach yours. It does not address whether your own people can reach material they should not, whether the vendor's staff can access your environment, or whether output is accurate. A firm that buys single-tenant and assumes the privilege problem is solved has addressed one exposure and left three open.

The strongest isolation model available still leaves the most common failure modes untouched, and this is worth stating plainly because isolation is often sold as though it were a complete answer to privilege risk.

Internal access is the first gap and usually the largest. Single-tenant infrastructure walls your firm off from other customers; it does nothing about which of your own lawyers can reach which matters. Cross-matter exposure inside your own environment is governed by your permissions and your ethical walls, not by your tenancy model. A firm with an untended permission structure has the same internal problem on dedicated infrastructure that it had on shared.

Vendor personnel are the second. Dedicated infrastructure does not by itself mean no vendor employee can access it; support and operations staff frequently can, under controls that vary widely. That is a contractual and audit question, covering privileged access management, logging of administrative access, and what happens when the vendor receives a subpoena for your data, and it is answered in the SOC 2 report and the agreement rather than by the architecture diagram.

Output accuracy is the third and is entirely orthogonal. A perfectly isolated model produces fabricated citations exactly as readily as a shared one. Isolation governs where data goes, not whether what comes back is true.

The useful framing is that isolation is one control among several rather than the control. It reduces a specific risk, that another customer's prompt could surface your client's material, and leaves internal permissions, vendor access, and verification to be handled separately.

The questions that separate a real isolation claim from a marketing one

"Your data is isolated" is not a claim you can evaluate, because every model is isolated in some sense. Four questions make it checkable: which model specifically, what enforces it, who at the vendor can reach it, and what artifact proves the control operated. A vendor that cannot answer the second and fourth is describing an intention ^[2][3].

Isolation is the easiest security property to assert and one of the harder ones to verify, because the vocabulary is loose. Logical separation in a shared database, separate database schemas per customer, separate application instances, and separate physical infrastructure can all be described as isolation.

The first question is which model, named specifically rather than adjectivally. Ask the vendor to state whether your data sits in shared storage with logical separation, a dedicated database, a dedicated application instance, or dedicated infrastructure. An answer that stays at the level of "your data is isolated and secure" has not answered the question.

The second question is what enforces it, and it is the one that distinguishes engineering from intention. Separation enforced by application code is a different assurance than separation enforced at the database or infrastructure layer, because application-layer separation fails the way software fails: a bug in the wrong place removes it. Ask where in the stack the boundary sits.

The third question is who at the vendor can cross the boundary, under what controls, and whether that access is logged. This is where dedicated infrastructure and dedicated access diverge, and firms routinely assume the first implies the second.

The fourth question is what artifact proves it. A SOC 2 Type II report tests whether controls actually operated over a period rather than whether they exist on paper, and ISO/IEC 27001 certification indicates a managed security program ^[2][3]. Read the scope: a report that excludes the product you are buying proves nothing about it. A vendor that answers the first and third questions confidently but cannot produce an in-scope artifact for the fourth has given you a description rather than evidence.