# Legal AI Data Isolation: Private Cloud vs Multi-Tenant

> Private cloud, single-tenant, or multi-tenant legal AI? Learn what each data isolation model protects, and how to verify a vendor isolation claim yourself.

[Home](https://rankshieldlegal.com/) / [Blog](https://rankshieldlegal.com/blog/) / AI Confidentiality Privilege and isolation
# Private Cloud or Multi-Tenant: What Legal AI Data Isolation Actually Protects
When a legal AI vendor says your data is "isolated," the word is doing a lot of quiet work. Isolation means at least four different things in practice, from a shared database with a tenant tag to a dedicated instance running only your data, and they protect privilege to very different degrees. This guide defines each legal AI data isolation model, private cloud and multi-tenant included, explains what each actually protects, and shows how to verify the claim yourself.

By [Jamie Kloncz](https://rankshieldlegal.com/about/), Founder, RankShield ** 16 min read ** Published August 22, 2026

Choosing between legal AI data isolation models, private cloud, multi-tenant, and the options in between, is a privilege decision disguised as an infrastructure one. Confidentiality under ABA Model Rule 1.6 requires reasonable efforts to prevent unauthorized access to client information, and the isolation model is a large part of what "reasonable" means when a third party processes your data [[1]](#ref-1). The problem is that "isolated" is a marketing word as often as a technical one, and the gap between a logically separated row in a shared database and a dedicated instance is the gap between adequate and strong protection.
The stakes are concrete. In a multi-tenant system, your data sits in shared infrastructure separated by software controls; in a single-tenant or private-cloud model, it runs in infrastructure dedicated to you. Both can be defensible, but they fail differently, and matching the model to the sensitivity of the matter is the actual decision. A misconfiguration that exposes one tenant's data to another is a different order of risk than a dedicated instance that simply has fewer neighbors to leak to.
This guide is written from the perspective of a verification vendor, not a law firm, and it is informational rather than legal advice. It defines the four common isolation models, explains where multi-tenant creates privilege risk, what single-tenant and private cloud protect, how to verify an isolation claim rather than accept it, and how to match the model to your matters.

## 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]](#ref-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.
Model What is shared Privilege consideration
Multi-tenant Compute, storage, and often one database, separated by software controls A misconfiguration can expose one tenant to another; depends on the vendor's controls [1]
Logical single-tenant Compute, but your data in a dedicated database or namespace Stronger separation of data; still shares the underlying platform
Dedicated single-tenant Nothing at the application layer; a full instance runs only your data Fewer paths for cross-customer exposure; higher cost
Private cloud or on-premises Nothing; you control the infrastructure Strongest control and residency; highest operational burden

## 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]](#ref-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](https://rankshieldlegal.com/blog/attorney-client-privilege-ai) covers that broader duty.

Source: AICPA SOC 2 Trust Services Criteria; ISO/IEC 27001; ABA Formal Opinion 512 Download SVG

## 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]](#ref-2) [[3]](#ref-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]](#ref-2) [[3]](#ref-3). The companion guide on [reading a SOC 2 report](https://rankshieldlegal.com/blog/read-soc-2-report-legal-ai-tool) 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]](#ref-2) [[3]](#ref-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]](#ref-2) [[3]](#ref-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.
4 questions which model, what enforces it, who at the vendor can cross it, and what artifact proves the control operated

Test yourself
## Test yourself on legal AI data isolation
Five questions on what isolation buys you, and what it does not.

- 1 A firm moves to single-tenant infrastructure. What internal risk is unchanged? Cross-tenant data leakage Cross-matter exposure among the firm's own lawyers Vendor subpoena exposure **Answer:** Cross-matter exposure among the firm's own lawyers Tenancy walls your firm off from other customers. Which of your own lawyers can reach which matters is governed by your permissions and ethical walls, and an untended permission structure has the same problem on dedicated infrastructure as on shared.
- 2 Does dedicated infrastructure mean no vendor employee can access your data? Yes, that is what dedicated means No, support and operations staff frequently can; it is a contractual and audit question Only if you also hold ISO 27001 **Answer:** No, support and operations staff frequently can; it is a contractual and audit question Firms routinely assume dedicated infrastructure implies dedicated access. Privileged access management, logging of administrative access, and subpoena handling are answered in the agreement and the SOC 2 report, not by the architecture.
- 3 How does isolation affect output accuracy? Stronger isolation reduces fabrication Not at all; the two are orthogonal Only in single-tenant deployments **Answer:** Not at all; the two are orthogonal Isolation governs where data goes, not whether what comes back is true. A perfectly isolated model produces fabricated citations exactly as readily as a shared one, which is why verification is a separate control.
- 4 Which question best distinguishes engineering from intention? How long has the vendor been in business What enforces the separation, and at which layer of the stack How many customers use the product **Answer:** What enforces the separation, and at which layer of the stack Separation enforced by application code fails the way software fails: a bug in the wrong place removes it. Separation enforced at the database or infrastructure layer is a materially different assurance.
- 5 A vendor produces a SOC 2 Type II report. What still needs checking? Nothing further Whether its scope covers the product you are buying Whether the auditor is US-based **Answer:** Whether its scope covers the product you are buying A SOC 2 Type II tests whether controls actually operated over a period rather than existing on paper, but a report that excludes the specific product proves nothing about it. Read the scope before treating it as evidence.
Honest self-check. There is no sign-up, and nothing is stored.

Questions answered
## Straight answers to the common questions
The questions readers ask about this topic, answered directly. **No forms, no sales pitch.**

JAMIE KLONCZ · SEO AGENCY NAPLES ************** ONLINE
Pick a question on the left, or search above. You will get the direct answer, the way an answer engine would give it.

← PREV NEXT → [REQUEST ACCESS →](https://rankshieldlegal.com/contact/)

- **What is data isolation in legal AI, and why does it matter for privilege?** Data isolation is how a legal AI vendor keeps one customer's data separate from another's, and it matters because confidentiality under ABA Model Rule 1.6 requires reasonable efforts to prevent unauthorized access to client information. Isolation exists on a spectrum: multi-tenant systems separate customers with software controls inside shared infrastructure, while single-tenant, private-cloud, and on-premises models give each customer dedicated infrastructure. The model determines how the system fails. A multi-tenant misconfiguration can expose one customer's data to another, whereas a dedicated instance has no other customer to expose. For privileged material, the isolation model is a central part of what counts as a reasonable effort, which is why it belongs in your vendor evaluation rather than buried in an architecture diagram.
- **Is multi-tenant legal AI a privilege risk?** Multi-tenant AI is not inherently improper, but it concentrates the privilege risk in one place: the vendor's software controls. In a multi-tenant system, the wall between customers is code and configuration rather than dedicated infrastructure, so a bug, a misconfiguration, or a flawed access check can let one customer's data surface in another's session. For most business data that residual risk is acceptable. For privileged client material, it raises the standard of proof you should demand, because you are relying on the vendor's engineering to protect a duty you cannot delegate. The practical answer is to either require strong evidence the controls are sound, such as a current in-scope SOC 2 Type II, or move sensitive matters to a more isolated model.
- **What is the difference between single-tenant and private cloud for legal AI?** Single-tenant and private cloud both remove the shared-neighbor risk, but they differ in control. A dedicated single-tenant instance runs the application on infrastructure devoted to your data alone, so the common multi-tenant failure of cross-customer exposure has no pathway, though the vendor still operates the underlying platform. Private cloud, and on-premises, goes further by giving you control of the infrastructure itself, including where data physically resides and who can access it. That control is what makes data-residency guarantees real rather than merely contractual, which matters when a client's outside-counsel guidelines or a regulator require privileged data to stay in a jurisdiction. The trade-off is that stronger isolation carries a higher operational burden and cost.
- **How do I verify a legal AI vendor's data isolation claim?** Do not accept the word "isolated"; make the vendor describe and evidence it. First, ask which specific model applies to your data, since a vendor may offer several tiers and quote the strongest while selling you a cheaper one. Second, ask how the separation is enforced technically, so you know whether it is a shared database with a tenant tag or a dedicated instance. Third, require evidence: a current SOC 2 Type II report scoped to the product shows the controls were tested over a period, and an ISO/IEC 27001 certification shows a managed security program. Read the scope so it covers the service you are actually buying. A vendor that cannot describe the model or produce the evidence is asking you to take isolation on faith.
- **Which isolation model should a law firm require for legal AI?** Match the model to the sensitivity of the work rather than forcing one choice on everything. Multi-tenant is reasonable for low-sensitivity, non-privileged tasks where cost and speed matter. Step up to dedicated single-tenant or private cloud for privileged, high-stakes, or residency-constrained matters. Use clear triggers: if a matter must be provably walled off from every other client, require dedicated infrastructure rather than logical isolation; if a vendor cannot describe how isolation is enforced, require the architecture in writing before relying on it; and if data must stay in a jurisdiction, require private cloud or a region-locked dedicated instance. A firm can reasonably run different models for different work, documenting why each is appropriate, which is proportionality rather than inconsistency.
- **If we buy single-tenant, is the privilege problem solved?** No. Isolation answers one question, whether another customer's data can reach yours, and leaves three exposures open. Internal access is usually the largest: cross-matter exposure among your own lawyers is governed by your permissions and ethical walls rather than by your tenancy model, so 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, since dedicated infrastructure does not by itself mean no vendor employee can access the environment; that is a contractual and audit question covering privileged access management, logging of administrative access, and subpoena handling. Output accuracy is the third and is entirely orthogonal, because a perfectly isolated model fabricates citations exactly as readily as a shared one. Treat isolation as one control among several rather than the control.
- **How do I test a vendor's isolation claim?** Ask four questions, because "your data is isolated" is not evaluable when logical separation in a shared database, separate schemas, separate application instances, and separate physical infrastructure can all be described that way. First, which model specifically, named rather than described adjectivally. Second, what enforces it and at which layer of the stack, which is the question that separates engineering from intention: separation enforced by application code fails the way software fails, while separation at the database or infrastructure layer is a different assurance. Third, who at the vendor can cross the boundary, under what controls, and whether that access is logged. Fourth, what artifact proves the control operated, normally a SOC 2 Type II report or ISO/IEC 27001 certification, and read the scope, because a report excluding the product you are buying proves nothing about it. A vendor confident on the first and third but unable to produce an in-scope artifact has given you a description rather than evidence.

## References

- American Bar Association. Formal Opinion 512: Generative Artificial Intelligence Tools (Model Rule 1.6 confidentiality). July 2024. [https://www.americanbar.org/news/abanews/aba-news-archives/2024/07/aba-issues-first-ethics-guidance-ai-tools/](https://www.americanbar.org/news/abanews/aba-news-archives/2024/07/aba-issues-first-ethics-guidance-ai-tools/)
- AICPA. SOC 2 Trust Services Criteria. 2022. [https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2)
- International Organization for Standardization. ISO/IEC 27001 Information Security Management. 2022. [https://www.iso.org/standard/27001](https://www.iso.org/standard/27001)

Written by
## [Jamie Kloncz](https://rankshieldlegal.com/about/)
Founder, RankShield
Jamie Kloncz is the founder of RankShield, the verifiable AI and quantum security platform behind RankShield Legal. An engineer by training, he built RankShield after his own devices and business were attacked, including an AI voice-cloning scam that targeted his family, on one conviction: unverifiable security is the real danger, so every consequential action should leave a receipt anyone can independently check.
[More about Jamie →](https://rankshieldlegal.com/about/)

Try it · Free
## Check a citation against live case-law
Paste a citation from an AI-drafted brief and see whether the case actually exists, resolved against live case-law. Free, no sign-up. Then request early access to certify a full filing.
[Try the citation checker](https://rankshieldlegal.com/ai-legal-citation-checker/)

Keep reading
## Related guides
[AI Confidentiality How to Prove Privileged Data Never Reached a Third-Party AI Model Read guide →](https://rankshieldlegal.com/blog/prove-privileged-data-never-reached-ai/)[AI Confidentiality Can Law Firms Use AI Without Waiving Attorney-Client Privilege? Read guide →](https://rankshieldlegal.com/blog/attorney-client-privilege-ai/)[Firm Security How to Read a SOC 2 Report for a Legal AI Tool Read guide →](https://rankshieldlegal.com/blog/read-soc-2-report-legal-ai-tool/)