How We’re Preparing Ethen for Private and Enterprise Deployments

Private AI deployment is a spectrum, not a single switch. At one end is a shared service with strong per-project controls; then a dedicated environment for one organization; then deployment inside the organization's own cloud account; and at the far end an isolated or offline environment that never touches an external network. Each step adds isolation, and each also changes things beyond where data lives: which models are available, who operates and updates the system, whether the system can improve from use, and how long it takes to start. Today, Ethen offers project-level controls — provider allowlists, budgets, logging modes including zero retention, customer-supplied keys — plus local models through Ethen Desktop and versioned GPU deployment recipes. Broader deployment options are direction, which we will pursue where demand warrants and describe only when they exist. This article explains the spectrum, the trade-offs, and why any label like "sovereign" must name its actual guarantees.

Key takeaways

• Private deployment is a spectrum. Shared with controls, dedicated, customer cloud, isolated.
• Data location is only one variable. Models, operations, updates and improvement rights change too.
• Today: project controls, local models, versioned GPU recipes. Broader options are direction, not commitments.
• Labels must name guarantees. "Private" and "sovereign" mean nothing without specifics.
• Start from the data and the models. Isolation chosen first often discovers model limits later.

Why organizations want private deployment

Organizations ask for private AI deployment for a handful of recurring reasons. Contracts with their own customers may restrict where data can go. Regulation may require certain data to stay within a jurisdiction or a controlled environment. Internal policy may forbid sending source code, financial records or health information to external services. And some organizations simply want more control: over when models change, over who can access logs, over the ability to inspect and audit the system.

These are legitimate and often non-negotiable requirements. The difficulty is that "private deployment" is used to mean very different things, and the differences matter. A buyer who asks for "private AI" and receives a shared service with a no-training promise has a very different arrangement from one who receives an isolated environment with only local models. Both may be the right answer for different needs.

The deployment spectrum

Figure 1 shows four broad options.

Shared service with project controls. The organization uses a service operated by the provider, with controls that govern what each project may do: which AI providers it may use, how much it may spend, what is logged and retained, and which keys it uses. This is the fastest way to start and offers the widest choice of models.

Dedicated tenant. The service runs in an environment set aside for one organization, so infrastructure is not shared with other customers. The provider still operates it.

Customer cloud. The service runs inside the organization's own cloud account. Data is processed within infrastructure the organization controls, under its own access and encryption policies, with operational responsibility shared.

Isolated or offline. The system runs in an environment with no external network connection — on the organization's own hardware or an air-gapped network. Only models that can run locally are available. The organization operates it.

The standard definitions of cloud deployment models published by NIST describe public, private, community and hybrid clouds in similar terms. The point for AI is that each option changes the whole system, not just the location of a server.

What changes across the spectrum

Figure 2 compares three points on the spectrum across five considerations.

Where data is processed. This is the variable most people focus on, and it matters. But it is not the only one.

Model availability. The largest AI models are offered as hosted services. A shared service can reach many of them. A customer-cloud deployment can reach those its cloud provides or those it can host. An isolated deployment can use only models that run on the hardware available. The capability gap between local and hosted models is real, which we discuss in Why Local AI Still Matters in a Cloud-First World.

Who operates and updates. More isolation means more operational responsibility for the organization: installing updates, monitoring health, replacing hardware, keeping models current. That is a cost, and it needs people.

Improvement from use. AI systems can improve by learning from completed work, but that learning needs data. In a shared service, any use of customer work to improve the system should require explicit consent, separated by purpose. In isolated deployments, any learning has to happen inside the boundary. Ethen Research Lab has published proposals on exactly this problem: Private AI Improvement Without Raw Data Export and Toward a Sovereign Improvement Protocol for Enterprise AI. Both are research proposals, not shipped features.

Time to start. A shared service can be useful the same day. Isolated deployments can take months.

What Ethen offers today

Ethen's current capabilities sit mostly at the first point on the spectrum, plus two paths that support more isolated work.

Project-level controls. Ethen's documentation describes per-project provider allowlists that deny unlisted providers by default, enforced budgets, logging modes that default to metadata only, a zero-data-retention mode set per project, customer-supplied provider keys encrypted and scoped to a project, and fail-closed behavior when controls cannot be checked. These controls are documented as alpha. We explain them in Why Enterprise AI Needs More Than SSO and Admin Controls.

Local models through Ethen Desktop. Ethen Desktop can work with local model runtimes on the user's own machine, talking to them only on the local machine, with each operation checked against what the runtime actually supports. Work that stays entirely on a local model is not sent to a model provider. See How Ethen Desktop Talks to Local Models and Ethen Across Desktop, Web and Local AI.

Versioned GPU deployment recipes. For organizations that want to host models on dedicated GPU capacity, Ethen pins each GPU deployment to a named, versioned template with explicit health checks, and keeps recipes disabled until their backing images exist. See Versioning GPU Deployment Recipes in Ethen, and for choosing between local runtimes and GPU hosting, Local AI or GPU Hosting: What to Check First.

What Ethen does not offer today, according to our documentation, includes data residency guarantees and enterprise single sign-on with directory provisioning; those are outside the current release scope.

What we are preparing for

Our direction is to support more of the spectrum where organizations need it: dedicated environments, deployment in customer cloud accounts, and isolated environments for the most restrictive cases. We will pursue each where demand warrants and describe it only when it exists, with its guarantees stated precisely. We are not announcing timelines here.

Several principles shape that preparation.

One product, several deployment shapes. The same controls — allowlists, budgets, logging modes, approvals, evidence — should work in every deployment option, so moving between them does not mean learning a new system.

Capabilities degrade honestly. Some capabilities depend on hosted models or external services. In more isolated deployments, those capabilities should be clearly unavailable rather than silently worse.

Updates are controlled. In private deployments, organizations should decide when models and software change, and be able to test changes first. Ethen Research Lab's Tenant Replay proposal explores how changes could be evaluated against an organization's own work inside its boundary.

Improvement stays inside the boundary unless agreed otherwise. No learning from an organization's work should leave its boundary without explicit, purpose-specific consent.

Why "sovereign" must name its guarantees

"Sovereign AI" has become a popular label, and it can mean almost anything: data stored in a country, a provider headquartered in a country, models trained in a country, infrastructure owned by a government, or simply a marketing promise. A label that can mean anything protects nothing.

Our position is that any deployment label — private, dedicated, sovereign — should come with a list of specific guarantees: where data is processed and stored; who can access it, including the operator's staff; which subprocessors are involved; whether any data or derived information leaves the boundary, and under what consent; who controls model and software updates; how deletion works; and what independent verification exists for each claim. If a guarantee is not on the list, it should not be assumed.

That applies to Ethen as much as anyone. When we offer deployment options beyond those described above, we will describe them in these terms.

Common misconceptions about private AI

"Private means the model provider never sees anything." Not necessarily. In many arrangements, requests still reach a model provider under contract terms. Only fully local or isolated processing guarantees that no external provider sees the content.

"No training on my data means my data is private." A no-training commitment is valuable, but it says nothing about logging, retention, staff access or subprocessors. Each needs its own answer.

"Isolation removes risk." Isolation removes some risks and adds others: outdated software, weaker monitoring, models downloaded from untrusted sources, and fewer people watching for problems.

"We need the most isolated option for everything." Most organizations have a few genuinely sensitive workloads and many ordinary ones. Applying maximum isolation everywhere sacrifices capability for no benefit on the ordinary work.

"Pseudonymized data is safe to send anywhere." Research has shown that language models can re-identify people from pseudonymous text in some settings. Treat pseudonymized data as sensitive unless you have evidence otherwise.

Questions to ask any vendor about private deployment

1. Where exactly is data processed and stored, including logs and backups?
2. Which of your staff can access our data or logs, and under what controls?
3. Which subprocessors are involved, including model providers?
4. Does any data, or anything derived from it, leave our boundary? Under what consent?
5. Who decides when models and software are updated? Can we test changes first?
6. Which models are available in this deployment option, and which are not?
7. How is deletion handled, and how is it confirmed?
8. Which of these answers has been independently verified?

How to choose a deployment option

Figure 3 suggests an order for the decision.

What data? Classify what the AI will actually see. Many workloads involve less sensitive data than first assumed; some involve more.

What rules? Identify the contracts, regulations and internal policies that apply to that data.

Which models? Check whether the models needed for the work can run, or be reached, in each option. This is the step most often skipped, and the one that most often forces a change of plan.

Who operates? Decide whether the organization has the people to operate a more isolated deployment.

What is guaranteed? Get each guarantee named in writing, using the list above.

Often the answer is a mix: a shared service with strict project controls for most work, and local or isolated processing for the most sensitive tasks.

A worked example

The following example is illustrative. A healthcare software company wants AI help across three kinds of work: drafting marketing content, reviewing its own source code, and summarizing de-identified support tickets that occasionally contain patient details despite redaction.

Marketing content involves no sensitive data and benefits from the most capable models, so it uses a shared service with default controls. Source code is confidential but not regulated; it uses a shared service with a provider allowlist limited to approved providers, zero data retention and customer-supplied keys. Support tickets may contain regulated data despite redaction; they are summarized with local models on managed machines, accepting lower model capability in exchange for keeping the data on the company's hardware.

One organization, three deployment shapes, chosen by data and rules rather than by a single policy for everything.

Tradeoffs and limitations

Isolation costs capability. More isolated deployments have access to fewer and smaller models.

Isolation costs operations. Someone has to run, update and monitor private deployments.

Controls are not certifications. Project-level controls support compliance programs; they do not certify them.

Most options beyond today's are direction. Dedicated, customer-cloud and isolated deployments are not announced here, and nothing in this article should be read as a commitment or timeline.

FAQ

What are the options for deploying AI privately? Broadly: a shared service with strong per-project controls, a dedicated environment for one organization, deployment in the organization's own cloud account, or an isolated or offline environment with local models.

What does sovereign AI actually mean? It has no single meaning. Any "sovereign" offering should list specific guarantees about data location, access, subprocessors, data leaving the boundary, update control, deletion and independent verification.

Can Ethen run in a private environment? Today Ethen offers project-level controls on its service, local models through Ethen Desktop and versioned GPU deployment recipes. Broader private deployment options are direction and will be described when available.

Does Ethen offer data residency? According to current documentation, data residency is outside the scope of the current release.

Is private deployment always better? No. It trades model capability, convenience and speed for control. Many organizations are best served by a mix.

Related reading

• Why Enterprise AI Needs More Than SSO and Admin Controls
• Why Local AI Still Matters in a Cloud-First World
• Local AI or GPU Hosting: What to Check First
• How Ethen Desktop Talks to Local Models
• Versioning GPU Deployment Recipes in Ethen

References

1. Mell, P., & Grance, T. (2011). The NIST Definition of Cloud Computing. NIST Special Publication 800-145. https://doi.org/10.6028/NIST.SP.800-145
2. Ethen Research Lab (2026). Private AI Improvement Without Raw Data Export. Research proposal. https://upcube.ai/resources/research/private-ai-improvement
3. Ethen Research Lab (2026). Toward a Sovereign Improvement Protocol for Enterprise AI. Research proposal. https://upcube.ai/resources/research/sovereign-improvement-protocol
4. Ethen Research Lab (2026). Tenant Replay: Private Evaluation Inside Enterprise Boundaries. Research proposal. https://upcube.ai/resources/research/tenant-replay
5. Ethen Docs. Enterprise controls. https://upcube.ai/docs/enterprise/enterprise-controls
6. Lermen, S. et al. (2026). Large-scale online deanonymization with LLMs. arXiv:2602.16800. https://arxiv.org/abs/2602.16800