---
title: "The Air-Gapped Deployment"
slug: "chapter-8-the-air-gapped-deployment"
kind: "chapter"
order: 9
label: "Chapter 8"
chapter: 8
part: "The Model Layer"
partLabel: "Part II"
partNumber: 2
epigraph: "Almost nobody will run it with the cable unplugged. Everybody should know that they could."
summary: "An air-gapped deployment is a sovereign AI platform running on a network with no route to the public internet. No model API calls leave. No telemetry leaves. Updates arrive on media or across a con…"
words: 1090
topics:
  - "Who needs it"
  - "What has to be inside the perimeter"
  - "Updates by signed bundle"
  - "What you give up"
  - "Why the same codebase must run both ways"
---

An air-gapped deployment is a sovereign AI platform running on a network with no route to the public internet. No model API calls leave. No telemetry leaves. Updates arrive on media or across a controlled transfer point, signed and verified. It is the strictest of the four deployment tiers from Chapter 3 and the one that tests every claim a platform makes about itself. This chapter walks through one, so that a CIO who will never run it understands what it proves about the platform that can.

## Who needs it

Defence and intelligence environments, obviously. Beyond them: certain financial trading and risk desks whose regulators treat any external connection as a reportable event. Research facilities working with export-controlled material. Hospitals or public-health agencies with specific data sets they have chosen never to put on a connected network. Critical-infrastructure operators whose control networks are segregated by design. Law firms running matters for clients who require it.

The common thread is that the data classification rules out connected operation, not that the organization is unusual in any other way. The people inside still want an agent that answers questions from their documents, drafts, summarizes and reasons. They want the same platform as everyone else, minus the cable.

## What has to be inside the perimeter

Everything. That is the discipline, and it is useful to enumerate it, because every item is something a connected deployment might have quietly outsourced.

**The models.** Open-weight models on local GPUs, served by an inference engine inside the network. The model catalogue from Chapter 6 lists only these. There is no commercial provider in the routing table, because there is no route to one.

**The embeddings.** Retrieval over the institution's documents depends on an embedding model that turns text into vectors. In a connected deployment this is often a cheap API call. Inside the gap it is another local model, smaller than the chat models, running on the same hardware.

**The vector store and the database.** Memory, documents, conversations, agent configurations and audit logs live in databases the institution runs. A platform that depends on a managed vector database or a hosted analytics service fails here.

**Identity.** The single sign-on and the identity layer from Part IV must work against the institution's own directory with no external identity provider in the chain.

**The connectors.** The systems of record the agents reach are inside the perimeter by definition, so the connectors and the broker that governs them run there too.

**The clients.** Web, desktop, browser extension and terminal all point at the internal platform. For a browser extension this means building the extension against the internal host rather than the public one, which is a single configuration value at build time in a platform designed for it, and impossible in one that was not.

**The build itself.** The platform's source, its dependencies and its container images have to be available inside the network to be built, patched and redeployed. A platform that pulls dependencies from the internet at deploy time cannot be deployed.

## Updates by signed bundle

A sealed network still needs new versions. The pattern that works is a release bundle: the platform's images, the model weights, the dependency archives and a manifest, cryptographically signed by the vendor and verified by the institution before anything is loaded. The bundle crosses the gap on approved media or through a one-way transfer device. Nothing inside the network ever reaches out to check for updates; the institution decides when a bundle enters and verifies what it contains.

This sounds exotic and is not. It is how software has reached secure facilities for decades. What is new is that the bundle now includes model weights measured in tens or hundreds of gigabytes, and that the platform has to be able to swap a model in and out, through the same catalogue and evaluation process as a connected deployment, without any external dependency.

## What you give up

Honesty about the costs matters more here than anywhere.

You give up the frontier. The best commercial models are not available inside the gap, and the open-weight models that are will lag them by six months to a year on the hardest tasks. For most institutional work this is invisible; for the small set of workloads that genuinely need the frontier, the air-gapped environment will be slower or worse, and the institution should decide knowingly.

You give up convenience. Every model, every update and every new connector arrives through a controlled process rather than a download. The people running the platform need more skill and more time.

You give up some breadth. Connectors to external services, web search, cloud-hosted tools of any kind, do not exist. The agents work with what is inside.

You pay for hardware. The GPU tiers from Chapter 7 are not optional; they are the only place a model can run.

What you keep is total certainty about where the data is. For the organizations on the list above, that is the entire point, and it is worth every item on the list.

## Why the same codebase must run both ways

The air-gapped deployment is rare. Its importance is out of proportion to its frequency, because it is the proof that the platform has no hidden dependencies.

A platform whose code is identical in the vendor's cloud and behind an air gap cannot be secretly sending telemetry, because there is nowhere for it to go. It cannot depend on a managed service, because the service would be unreachable. It cannot have a model baked in, because the model would have to be swappable for one that exists inside. Every property that makes the sealed deployment possible is a property the connected deployments inherit for free.

That is why I advise CIOs who will never unplug the cable to ask the air-gap question anyway, and to ask for a demonstration rather than a slide. Watch the platform start on a machine with networking disabled. Watch an agent answer from a local document through a local model. Watch an administrator switch that model to another local one. A vendor that can do this has built a sovereign system. A vendor that cannot has built a hosted one with an on-premise brochure, and the institution will find out which at the worst possible moment.

Part III turns from the model to the data: how agents reach systems of record where they live, through connectors and a broker, without the migration projects that have consumed institutional IT budgets for a generation.