Reading time: 6 min
Single-tenant in practice means one thing: a dedicated, isolated instance that runs your workload and no one else's. You share no compute, no storage, and no model, and your data does not leave your perimeter. The difference from shared cloud is not a clause in a contract, it is a concrete boundary you can show an auditor. Below we break that boundary into parts: what is actually isolated, how data flows and where it stops, who controls the update cycle, and what an auditor sees. We also show where a naive single-tenant setup falls short, even when it looks dedicated on paper. Which model to pick for your data we unpacked separately in the piece on single-tenant versus shared cloud. Here the question is what a dedicated instance looks like once it is running.
What is actually isolated
A „dedicated instance" is not one thing, it is a set of boundaries. It is worth breaking them apart, because a setup gets called single-tenant when only some of them are closed.
- Compute. Your workload gets allocated resources, not a slot in a shared pool where another customer's load bleeds into your results.
- The model and its weights. The model instance runs for you alone. You do not share one endpoint with other organizations, so your prompts and contexts never enter a common queue.
- Storage and index. Documents, embeddings, and the vector store live in your environment, not in shared storage with logical separation.
- Network. The environment has its own segment, and outbound traffic is controlled, not open by default to a public API.
Only when all four boundaries are closed does „single-tenant" mean what it promises. If one is open, the isolation is partial, even though the label says full.
How data flows, and where it stops
In a dedicated instance the data path is short and closed. Source documents, drawings, BOMs, tickets, go into an index inside your environment. Context retrieval and model inference happen in the same instance, and the answer comes back to you. What matters is what is not on that path: no call to a public API on the outside, no shipping of document content to a shared model, no logs landing outside the perimeter. Embeddings are computed locally, not sent off to an external service. It is that closed loop, rather than the label „private", that keeps production data from leaking out the side.
The update cycle you control
In shared cloud a provider-side change hits everyone at once: a new model version or a change in behavior lands when the provider decides. In single-tenant you decide when and what changes in the environment. A new version can be tested on your data first, results compared, and only then rolled out, or a version pinned for as long as stability matters more than novelty. For a process you have wired into daily work, that predictability often matters more than same-day access to the newest model.
How it looks point by point
The simplest way is to compare the two models on the dimensions that actually define the isolation boundary.
| Dimension | Shared cloud | Single-tenant |
|---|---|---|
| Compute | Shared pool | Dedicated, yours alone |
| Model and weights | Shared endpoint | Separate instance |
| Data and index | Logical separation | Own environment |
| Outbound traffic | Often to a public API | Controlled, in perimeter |
| Update cycle | Provider-side | Your side |
| Answer to an auditor | Explain the separation | One sentence |
What an auditor sees
Under NIS2 an auditor asks two things: where exactly data is processed, and who can reach it. With a shared instance the answer means explaining the logical separation mechanism and convincing the auditor it holds. With a dedicated instance the answer „a separate environment, only ours, with documented isolation" defends itself in one sentence. That is not a cosmetic difference: how easily you can defend the data boundary translates directly into the time and risk of an audit. We go into this further in the piece on public-cloud AI and the NIS2 audit.
Where a naive setup falls short
An environment gets sold as single-tenant and still leaks. These are worth asking about before you treat the boundary as closed.
- Isolated app, but inference in a public API. The instance itself is yours, yet embeddings or answer generation still go out to an external service. Data leaves the perimeter even though the panel looks private.
- A shared model endpoint behind the scenes. „Dedicated" sometimes holds only at the application layer, while the model serves many customers from one queue.
- Logs and telemetry outside the perimeter. Prompt content and document fragments end up in the provider's external logging system.
- Backups in shared storage. The environment is dedicated, but the backup lands where other customers' backups do.
- Unclear who holds the keys. If the encryption keys sit with the provider, an isolated environment does not end the conversation about access.
These are control questions, not accusations. A well-designed single-tenant passes them without stretching, and the answers can be shown, not just stated.
What this model does not solve
Single-tenant settles the question of the environment boundary, but it does not replace several other things. It is not the same as on-prem: it is still a dedicated instance at an infrastructure provider, not hardware in your own server room. When owning your own iron is worth it and when it is not we unpack in the piece on on-prem AI in manufacturing. Environment isolation also does not replace access control inside the company: data not leaving the outside does not mean everyone inside should see it. A dedicated environment is not automatically cheaper, and the entry barrier tends to be higher than shared. And finally, single-tenant is a guarantee of a boundary, not a guarantee of model quality. A good result still depends on the documents it works on.
The next step
If your production data cannot share an environment with anyone else, it is worth seeing what a dedicated instance would look like for one concrete task. On a short call we will walk through the isolation boundaries for your case, point by point. Book a call with Fryderyk, 30 minutes, no pitch.
Author: Fryderyk Pryjma, CortexMine. We work with manufacturers on private Digital Worker deployments on their own infrastructure.
Prefer to check on your own first? The readiness mini-audit takes 10 minutes and leaves no data behind.