Enterprises are told they have to choose: modern AI, or data that never leaves the building. That trade is a product limitation, not a law of physics. With x101, the platform, the AI models, the inference and the knowledge they retrieve from all run on your hardware, inside your boundary. No prompt, no record and no document ever crosses it, and we have shipped it that way in production.
An AI platform is hungry by design. Every question your people ask, every document it retrieves, every record it reads and every action it prepares becomes a prompt. If prompts leave the building, the volume and sensitivity of what crosses the boundary is an order of magnitude beyond anything a traditional integration ever exposed, and a prompt sent to a commercial endpoint is a disclosure event, whatever the data processing agreement says about retention.
The assumption that the intelligence has to live somewhere else is an artefact of how most platforms were built, not a property of the technology. A model is a component: it needs GPUs, a serving runtime, a set of weights and something to retrieve from, and all four can sit in your data centre. Most vendors stop at "the platform runs on-prem but it still phones home to our model API" because the model is the part they own.
That is fine for SaaS-comfortable customers. It is disqualifying wherever the security model treats vendor cloud as an unacceptable data path. x101 was built so the question never arises: the same platform deploys on public cloud, private cloud, on-premises or fully air-gapped, by configuration.
"When the fibre to the internet is cut, does the product still work?"
The one question that reliably separates a disconnected deployment from a hosted product with an on-premises collector in front of it
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.
Every capability, orchestration, retrieval, analytics, research, agents and actions, operates indefinitely with zero egress. Not "degrades gracefully." Operates.
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.
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 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.
Signed, inspectable artifact packages: validated by your security team, staged in non-production, promoted through your own change management. Never a background pull.
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.
Restricted networks operate disconnected by design; platforms that need a vendor cloud are out before evaluation begins.
Where data leaving the sovereign perimeter is itself a compliance violation.
Banks under residency controls, or that classify operational and customer data as too sensitive for any vendor cloud.
Health systems that treat operational data as patient-data adjacent; air-gapped removes the residency review from procurement.
Energy, telecom, water, transport: a third-party cloud is an attack surface, not just a compliance question.
Where outbound connectivity from production systems is an unacceptable risk, air-gapped is the only way an AI platform lands.
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.
AI models run on GPU-based machines inside your perimeter: bundled self-hosted models delivered through the signed offline process, or the local model stack you already run. Model-agnostic and swappable as better ones ship.
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.
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.
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 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 orchestrator, the specialist agents, Agent Studio, the connectors to your internal systems, the knowledge indexes and the 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.
"On-prem" covers a wide range, and the differences only surface under security review. Four 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 |
Platform on-prem, model hosted
What most vendors mean by "on-prem"
|
Full on-prem
Controlled egress for updates
|
Sovereign on-prem
Weights and inference inside
|
Air-gapped Strictest
Zero outbound connectivity
|
|---|---|---|---|---|
|
Platform runs in your data centre
|
Yes | Yes | Yes | Yes |
|
Business data stays inside
Records · documents · operational data
|
At rest only | Yes | Yes | Yes |
|
Prompts stay inside
|
No | Yes | Yes | Yes |
|
Model weights inside
|
No | Optional | Yes | Yes |
|
Knowledge indexes inside
|
Partial | Yes | Yes | Yes |
|
Outbound connectivity required
|
Continuous | Controlled egress point | Controlled egress point | None |
|
Update mechanism
|
Continuous pull | Pull over controlled egress | Pull over controlled egress | Signed offline packages |
|
Survives a severed internet link
|
No | Degraded | Yes | Yes |
inside the boundary outside, partial, or dependent on connectivity
Scroll the table sideways to see every column →
The production deployments below 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.
Two Tier-1 telecom deployments run x101 fully inside the operator's own data centre, with every AI model served on the operator's own hardware and zero public-AI endpoints. Both operators' sovereignty policies prohibited public AI outright, which had disqualified other platforms before evaluation began.
Figures as reported in each linked case study. Customer identities withheld at their request.
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.
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.
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 locality means inference GPUs. Sizing depends on request volume, connector scope and knowledge size, and it belongs in the business case from the start. We size it during scoping, not after signature.
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.
If your security architecture rules out egress, that should shape the evaluation from the first conversation, not surface in week nine. Tell us the boundary you have to hold and the outcomes you need, and we will scope against them.