---
title: "Air-Gapped Deployment: The Whole Platform Inside Your Perimeter, AI Included | x101"
url: https://www.x101.ai/air-gapped-deployment
description: "Air-gapped x101 means your data, your documents, the model weights and the AI inference all stay inside your perimeter. The five properties a true air-gapped claim has to meet, the in-house AI stack on your own GPUs, and the honest tradeoffs."
---

# 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.

### The simple test

**Disconnect the internet.** Everything still works: answers, actions, agents and audit, indefinitely. That is the whole definition of air-gapped, and most platforms fail it.

## 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.**

1. **No outbound dependency**: Every capability, orchestration, retrieval, analytics, research, agents and actions, operates indefinitely with zero egress. Not "degrades gracefully." Operates.
2. **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.
3. **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.
4. **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.
5. **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.

How three deployment configurations compare, from full on-prem through fully air-gapped.

| Property | Full on-prem | Sovereign on-prem | Air-gapped (Strictest) |
| --- | --- | --- | --- |
| Platform, data, prompts and knowledge all inside (Modules · records · documents · prompts · knowledge indexes) | Yes (inside the boundary) | Yes (inside the boundary) | Yes (inside the boundary) |
| Model weights inside | Optional (outside, partial, or dependent on connectivity) | Yes (inside the boundary) | Yes (inside the boundary) |
| Outbound connectivity required | Controlled egress point (outside, partial, or dependent on connectivity) | Controlled egress point (outside, partial, or dependent on connectivity) | None (inside the boundary) |
| Update mechanism | Pull over controlled egress (outside, partial, or dependent on connectivity) | Pull over controlled egress (outside, partial, or dependent on connectivity) | Signed offline packages (inside the boundary) |
| Survives a severed internet link | Degraded (outside, partial, or dependent on connectivity) | Yes (inside the boundary) | Yes (inside the boundary) |

x101's production deployments (see the [case studies](https://www.x101.ai/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.

- [Book a demo](https://www.x101.ai/contact)
- [Explore the Platform](https://www.x101.ai/platform)
- [Read the case studies](https://www.x101.ai/case-studies)