Air-Gapped AI Deployment for Regulated Networks

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.

What "Air-Gapped" Actually Requires

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.

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.

Where AI Deployments Add Their Own Requirements

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.

Getting Updates Across the Boundary Without Breaking It

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:

1. Stage the update on a separate, internet-connected system. The enclave itself never touches the internet at any point in this process.
2. Validate integrity through signature verification before the update goes anywhere near the disconnected environment, so a compromised or corrupted package gets caught before it crosses the boundary.
3. Transfer the validated update across the air gap on physical media, on a controlled cadence rather than continuously, so every crossing is a deliberate, logged event rather than an automatic background process.
4. Deploy to a canary subset inside the enclave first, rather than promoting straight to full production.
5. Observe behavior during a defined window before deciding whether the update is safe to roll out further.
6. Promote to production, with the previous version kept available specifically so a rollback doesn't require crossing the air gap a second time under pressure.

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.

Governance and Evidence Don't Get to Skip the Network Restriction Either

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:

• The policy decision made and the specific rule that triggered it
• Which model and model version handled the request
• Which tool, if any, was invoked
• The enforcement action taken: allowed, blocked, or rewritten
• A timestamp
• Request and response metadata
• The policy version in effect at that moment
• The deployment version the request ran against

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.

Where Platforms Actually Fail This Test

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:

• Telemetry that's on by default. Usage analytics, crash reporting, and "phone home for a version check" are frequently baked into a platform's default configuration, not something a team consciously enabled, and they're easy to miss during a security review that's mostly focused on the model itself.
• License validation that assumes connectivity. A tool that needs to check in with a licensing server to confirm it's authorized to run isn't air-gapped, regardless of what else about its deployment is isolated.
• Container images that pull dependencies at runtime. An image that looks self-contained but fetches a base layer or a package from a public registry the first time it starts will simply fail, or worse, hang waiting on a DNS resolution that never completes, inside a disconnected network.
• Auxiliary services that aren't the main model call. Embedding generation, a secondary classification model, a content-safety check, anything routed to an external API for convenience during development tends to get forgotten precisely because it isn't the obvious, headline inference call.

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

The Deployment Choice Depends on What's Actually Required

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.

Questions to Ask Before Committing to This Tier

1. Is there a specific regulatory or contractual requirement that prohibits any external data path, or is air-gapped being chosen as a precaution without one?
2. Can the team realistically own signed, physical-media update cycles for every component in the stack, not just the primary model, embeddings, guardrails, and every MCP server included?
3. What happens to the timeline when a critical vulnerability needs patching and the update process is measured in days rather than minutes?
4. Does the observability and evidence pipeline already have a concrete plan to run fully local, or does the current architecture quietly assume a cloud dashboard will be there?
5. Who owns the physical process of crossing the air gap, and is that process itself documented, signed, and auditable, or does it depend on one person's memory?
6. Would a VPC or self-hosted deployment actually satisfy the real requirement, or does the requirement specifically demand zero network path under any circumstance?

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.

Isolation Is an Architecture, Not a Configuration Flag

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.