Plenty of platforms describe themselves as "private" or "on-premises" and still phone home. A license check, a telemetry ping, a background update call, a DNS lookup that reaches out before failing silently, any one of these is a live network path, and any outbound network capability at all means a platform doesn't meet a strict air-gapped requirement, regardless of how everything else is configured. Air-gapped AI means something more specific and more absolute than "private": no inbound connections, no outbound connections, nothing crossing the boundary except through a controlled, auditable process a human deliberately initiated.
This guide covers what that actually requires: the architecture that has to live entirely inside the boundary, how updates and models get in without breaking the boundary that makes the deployment air-gapped in the first place, what changes about governance and evidence when nothing can stream to the cloud, and the specific places platforms most often fail this test without realizing it.
Self-hosted, cloud VPC, and air-gapped deployment sit on a spectrum, and they're often discussed as interchangeable shorthand for "not a public API," which understates how different the strictest tier actually is. A self-hosted deployment can still reach out to a license server. A VPC deployment can still route through a NAT gateway for a software update. Air-gapped removes that option entirely: the network has no path out, by design, and every dependency an AI system needs, model weights, inference runtime, monitoring stack, container images, has to already be present inside the enclave before anything runs.
That has real architectural consequences. Observability tooling that assumes it can ship logs to a cloud dashboard has to run entirely locally instead. Package managers and container registries that assume live internet access need an internal mirror instead. Anything that would normally resolve a DNS name on the public internet needs to either fail gracefully or never attempt the lookup at all, because in disconnected networks even an innocuous, non-sensitive outbound call is a boundary violation, independent of what data it would have carried.
| Deployment | Internet connectivity | Typical control | Air-gapped? |
|---|---|---|---|
| Cloud API | Required | Provider | No |
| Cloud VPC | Usually possible | Customer and provider | No |
| Self-hosted | May exist | Customer | Not necessarily |
| Air-gapped | None | Customer | Yes |
That table is also where most vendor claims quietly fall apart: "self-hosted" and "on-premises" both leave room for a connectivity path that "air-gapped" is specifically defined to remove.
Everything above is true of any disconnected system, not just an AI one. What's specific to AI is the number of components beyond the core model that also need to live inside the boundary and stay verifiable. A model's weights need provenance that can be checked locally, not just downloaded once and trusted forever, which means cryptographic verification of model artifacts against a known signature has to happen inside the enclave, the same way a software package's integrity gets checked before it crosses the air gap. A local model registry, tracking exactly which model and version is running where, takes the place of whatever hosted registry a connected deployment would normally query.
The components that tend to get missed are the ones that aren't the headline inference model: embedding models used for retrieval, a separate guardrail or policy model doing content and PII detection, any MCP servers and their tool dependencies an agent relies on, and the prompt and output inspection layer sitting in front of and behind the main model call. Each of those is its own dependency with its own update cycle, and each one needs the same disciplined, offline handling as the primary model, or it becomes the one component quietly still trying to reach the internet.
The hardest architectural problem in offline AI deployment isn't running the model. It's changing anything about the deployment later without reopening the network connection the whole architecture exists to avoid. A controlled, signed update workflow, rather than a live connection, is what a defensible process actually looks like:
Policy updates, not just model updates, follow the same process. Nothing enters the enclave over a network connection at any step, which is the entire point: the boundary doesn't get a temporary exception for convenience.
A common mistake in air-gapped planning is treating the network restriction as something that applies to inference but not to logging, monitoring, or compliance evidence. It applies to all of it. If enforcement decisions, audit logs, and policy evaluation records can't stream to an external SIEM or a cloud-based observability platform, because streaming out would itself be a boundary violation, then the entire evidence pipeline has to run and persist locally, on infrastructure that lives inside the same kind of isolated network environments as everything else.
What that pipeline actually needs to preserve, per request, is specific:
That doesn't mean evidence stops getting generated. It means the export process for that evidence, the mechanism by which an auditor or a compliance reviewer actually gets access to it, needs the same deliberate, controlled-crossing treatment as a model update: a defined, signed, logged process for getting records out, rather than an assumption that a dashboard somewhere is already showing them in real time.
Most failures in air-gapped AI deployment aren't dramatic. They're a default setting nobody turned off. A handful of patterns account for most of them:
None of these show up in a product's marketing description. They show up during an actual deployment, which is why on-premises AI vendors get evaluated on documented, verifiable air-gapped operation rather than a claim of "runs anywhere."
Not every regulated workload needs the strictest tier. It's worth working through what actually requires self-hosting versus the full air-gapped tier before defaulting to the most restrictive option available, since air-gapped operation carries real operational cost: slower update cycles, more manual process, and infrastructure a team has to fully own rather than partially delegate. The workloads that genuinely require it, defense systems, certain healthcare and financial infrastructure, anything where even a theoretical external data path is contractually or statutorily prohibited, are the ones where that cost is clearly worth paying rather than a default reached out of caution alone.
A team that can't answer these with confidence isn't ready to commit to this tier yet, and finding that out before deployment is considerably cheaper than finding it out after.
An air gap isn't something a team configures once. It's something every component of the deployment has to continuously respect, the inference model, the embedding and guardrail models sitting alongside it, every MCP server and tool dependency an agent reaches for, and the evidence pipeline recording all of it. Secure AI infrastructure at this tier means that respect holds even as models get updated, policies change, and new tools get added, not just on the day the system was first deployed and reviewed. Get any one component wrong, later, quietly, after the initial review is long over, and the deployment isn't actually air-gapped anymore, no matter how carefully everything else was built.