The whole platform inside your perimeter, AI included.
The platform, the AI models, the inference and the knowledge they retrieve from all run on your hardware, inside your boundary, and we have shipped it that way in production.
You are not choosing between AI and sovereignty
On most AI platforms, every question your people ask and every document retrieved becomes a prompt sent to a vendor cloud. That is how those platforms were built, not how AI has to work.
- Every prompt is a disclosure. On a hosted-model platform, the most sensitive data you hold leaves the building with every request.
- A model is just a component. GPUs, a serving runtime, model weights and retrieval: all four can sit in your own data centre.
- One platform, your boundary. x101 deploys on public cloud, private cloud, on-premises or fully air-gapped, by configuration.
What air-gapped has to mean
The term has been stretched. Some vendors call a single-tenant cloud tenancy air-gapped. Others call an on-premises install air-gapped while inference still travels to a hosted model API. Both fail the fibre-cut test. We hold the term to five properties. All five, or the claim does not hold.
No outbound dependency
Every capability, orchestration, retrieval, analytics, research, agents and actions, operates indefinitely with zero egress. Not "degrades gracefully." Operates.
Inference on your hardware
The serving stack runs on GPUs you own, in a facility you control. No prompt crosses the boundary: not for an answer, not for an analysis, not for a question typed at 2 a.m.
The weights are inside too
Inference locality is not enough if the model is fetched from a vendor endpoint at start-up. Weights ship inside the signed offline package, or the platform binds to models you already host.
The knowledge is inside
The property most often missed. x101 is only as good as what it retrieves from: your policies, contracts, runbooks, records and history. If retrieval reaches a hosted index, the platform is not disconnected, and the queries themselves leak intent.
Updates arrive offline
Signed, inspectable artifact packages: validated by your security team, staged in non-production, promoted through your own change management. Never a background pull.
Who needs true air-gapped AI
For most enterprises, a governed cloud or private-cloud deployment is the right answer. Air-gapped exists for the environments where the security architecture itself rules out egress, and where anything less ends the procurement conversation before it starts.
Defense and classified networks
Restricted networks run disconnected by design; platforms that need a vendor cloud are out.
Sovereign cloud and government
Where data leaving the sovereign perimeter is itself a compliance violation.
Regulated banking and finance
Banks under residency controls, or with customer data too sensitive for any vendor cloud.
Healthcare under strict residency
Health systems that treat operational data as patient-data adjacent; air-gapped removes the residency review from procurement.
Critical infrastructure operators
Energy, telecom, water and transport, where a third-party cloud is an attack surface, not just a compliance question.
Any zero-egress security policy
Where outbound connectivity from production systems is an unacceptable risk, air-gapped is the only way an AI platform lands.
Sovereign AI: your models, on your GPUs
Air-gapped is a network property: nothing leaves. Sovereign is the stronger claim: the intelligence itself belongs to you. Every model x101 uses is deployed in-house on GPU-based machines you own, served fast, trained and retrained internally, and no data ever leaves the environment.
LLMs deployed in-house
Best-in-class open-source models, deployed on GPU-based machines inside your perimeter: bundled and delivered through the signed offline process, or the local model stack you already run. Model-agnostic and swappable as better ones ship.
High-speed inference
Models are served through the latest high-throughput inference engines, tuned for your GPUs, so on-premises does not mean slow. Sized during scoping against your request volume, not quoted from a generic configuration.
Completion, embedding and voice
Every model class the platform needs deploys side by side: completion models for reasoning and answers, embedding models for retrieval, and speech models for voice, so conversations, search and phone calls all run locally.
ML trained on-premises
Machine learning models for detection, forecasting and scoring are trained, versioned and retrained internally on your own data, with drift monitoring, and are never externalised.
No data leaves the environment
No prompt, record, document, embedding or telemetry crosses the boundary, and nothing you operate on is used to train anyone else's models. Your data tunes your deployment, and only yours.
The whole platform beside them
The orchestrator, specialist agents, Agent Studio, connectors, knowledge indexes and audit store all deploy inside the same boundary, identical in behaviour to any other deployment.
For a sovereign-cloud or national-infrastructure review, this is usually the paragraph that decides it. The answer to "where does the AI run, and who controls it" is: your data centre, and you.
Degrees of on-premises
"On-prem" covers a wide range, and the differences only surface under security review. Three configurations, in order of how much of the intelligence sits inside your boundary. Each is right for a different security architecture; air-gapped is the only valid choice for some.
| Property | Full on-premControlled egress for updates | Sovereign on-premWeights and inference inside | Air-gapped StrictestZero outbound connectivity |
|---|---|---|---|
| Platform, data, prompts and knowledge all insideModules · records · documents · prompts · knowledge indexes | Inside the boundary, Yes | Inside the boundary, Yes | Inside the boundary, Yes |
| Model weights inside | Outside, partial, or dependent on connectivity, Optional | Inside the boundary, Yes | Inside the boundary, Yes |
| Outbound connectivity required | Outside, partial, or dependent on connectivity, Controlled egress point | Outside, partial, or dependent on connectivity, Controlled egress point | Inside the boundary, None |
| Update mechanism | Outside, partial, or dependent on connectivity, Pull over controlled egress | Outside, partial, or dependent on connectivity, Pull over controlled egress | Inside the boundary, Signed offline packages |
| Survives a severed internet link | Outside, partial, or dependent on connectivity, Degraded | Inside the boundary, Yes | Inside the boundary, Yes |
- inside the boundary
- outside, partial, or dependent on connectivity
x101's production deployments (see the case studies) sit in the sovereign on-prem column: platform, weights, inference and knowledge all inside, with a controlled egress point retained for update delivery. Air-gapped removes that last path and replaces it with the signed offline package workflow. The architecture is the same; what changes is the update mechanism and the security review that precedes it.
What air-gapped asks of you, honestly
Four things worth planning for. None of them is a reason to send your data elsewhere; all of them are easier to absorb on the table before signature rather than after.
Model updates arrive in batches
You receive validated packages on your own cadence, not the newest model the week it ships. For most workloads this is immaterial; the model is rarely the bottleneck. Plan the refresh cycle deliberately rather than letting it drift.
Your deployment learns from your data
Which is the point, and also a ramp. The knowledge that makes retrieval useful is your documents, records and history. Well-structured estates reach value quickly; estates living in unstructured tickets and tribal knowledge should budget for curation work.
Inference hardware is a line item
Inference locality means inference GPUs. Sizing depends on request volume, connector scope and knowledge size, so it belongs in the business case. We size it during scoping, not after signature.
Support diagnostics need a defined path
When you raise a ticket, the relevant logs are exported by your team, sanitised and shared. Agree the sanitisation procedure and the responsible role during onboarding, not during your first severity-one.
Bring us the constraint, not just the requirement.
Tell us the boundary you have to hold and the outcomes you need, and we will scope against them.