What an Air-Gapped Enterprise AI Deployment Involves

“Can it run air-gapped?” is one of the first questions a regulated buyer asks, and one of the least precisely answered. The term is used loosely enough that two parties can agree to it and mean different things, which is a poor basis for a procurement decision.

This is what it means when we say it.

What Air-Gapped Actually Means

An air-gapped deployment runs with no outbound network route. Not a restricted route, not an allow-listed one, not a proxy with egress filtering. No route.

That single constraint has one large consequence: no commercial model API is reachable. Everything that would ordinarily be resolved by calling a provider has to be resolved inside the boundary or not at all.

It is worth being clear about what this excludes, because these are all sometimes described as air-gapped and none of them are:

• A private VPC with egress restricted to named endpoints. This is a good control. It is not an air gap.
• A dedicated instance hosted by a model provider. Your data is isolated from other tenants. It is still leaving your perimeter.
• An on-premises deployment that calls out for inference. The platform is inside; the reasoning is not.

The Architecture

Inside the boundary, a locally deployed open-source model runs on customer-provided GPU hardware. Inference happens on your hardware, inside your perimeter, and nothing about the request leaves it.

This works because of how the intelligence layer is arranged. The model was never where the institutional advantage lived. Knowledge, memory and skills sit in the layer above it, so the model underneath is a component rather than a dependency, and swapping a commercial provider for a local open-source model is a control-plane decision rather than a rebuild.

One distinction matters here and is frequently blurred. Running a model locally is hosting, not training. The local model is not fine-tuned on your data, and no part of the layer depends on adapting model weights. The layer is built from operational work and sits above whichever model is in use. If that were not true, an air-gapped deployment would mean committing permanently to whatever open weights were current on the day you deployed, which is precisely the trap the architecture is designed to avoid.

How Updates Get In

This is the question that separates people who have run air-gapped systems from people who have read about them.

Platform releases and model weights are introduced through the customer’s own controlled transfer process. Every organisation operating an air-gapped environment already has one, because it already runs other software there, and it is already governed, logged and staffed.

We do not specify the mechanism, and vendors who do are usually overreaching. The transfer path is the customer’s control, subject to the customer’s own change management. What we supply is a release that can be verified and installed offline, with its dependencies, and a documented procedure for doing so.

The practical consequence worth planning for is cadence. Updates arrive on the schedule your transfer process supports, not on ours. Organisations that batch quarterly should expect quarterly.

What Stays Identical

Most of the platform does not change at all, which is the point of building the controls into the architecture rather than the deployment.

Policy and access enforcement, scoping between tenant, workspace and domain, agent evaluations, tracing, metrics and the full audit trail all behave exactly as they do in a managed deployment. An audit record written in an air-gapped environment contains the same fields and supports the same reconstruction of an agent decision as one written anywhere else.

This matters for assurance. You are not being asked to accept a reduced-governance variant in exchange for isolation.

What Genuinely Differs

Three things, and they should be weighed honestly.

Model selection is narrower. You are choosing among open-weight models that will run on your hardware, not among the frontier of commercial offerings. For a large share of enterprise work this is not a constraint that binds, particularly where the layer resolves the context and the model performs a short final step. For the hardest reasoning tasks, it is a real difference.

Update cadence is yours. See above.

Operational burden is yours. GPU capacity planning, hardware lifecycle and the transfer process are all customer responsibilities. This is not unusual for organisations already operating in this mode, but it is a genuine cost and it belongs in the business case.

When It Is the Right Answer

Air-gapped deployment is not the default and should not be. It is the correct answer when data genuinely may not leave the building: defence and government work, certain critical national infrastructure, and specific regulated datasets where the obligation is absolute rather than risk-managed.

For most regulated enterprises, the binding constraint is residency rather than isolation. Data must stay in a jurisdiction, under a legal regime, with demonstrable controls. That is satisfied by an in-region deployment in your own environment, which preserves full model choice. The deployment options and the regional control mappings set out which applies where.

The question to take into a procurement conversation is not “do you support air-gapped?”, to which most vendors will say yes. It is: where does inference run, what leaves the perimeter, how do updates arrive, and which of the governance controls survive the isolation? The answers to those four separate the deployments that meet the obligation from the ones that merely describe it.