Air-gapped deployment
Running a system with no network path out of the customer's environment, so model endpoints and data cannot leave it at all.
Category
What keeps it honest
Related terms
An air-gapped deployment has no route to the outside. Models, retrieval indexes, tools, and data all run inside the customer's own environment, and the question “could this leave” has a structural answer rather than a policy answer.
What it forces
Every model has to run locally, which usually means an SLM or a self-hosted open-weight model rather than a provider endpoint. Updates arrive through a controlled process rather than a pull. Evaluation runs inside the boundary. Observability stays inside the boundary. Anything that assumed a call to an external service has to be replaced or removed at design time, not discovered at cutover.
When it is the right constraint
Regulated environments where data classification forbids egress, systems handling material that cannot cross a jurisdiction, or institutions whose security posture treats any outbound path as a risk to be eliminated rather than monitored.
The weaker forms, named honestly
Most work does not need a true air gap. A customer-controlled cloud account, a private endpoint with documented egress, or an agreed hybrid architecture are different and weaker guarantees, and calling them air-gapped is wrong. Model endpoints, data paths, identities, and any permitted egress are documented against whichever boundary was actually agreed.
Often confused with
How it differs from similar terms.
| air-gapped deployment | Compared with | What's different |
|---|---|---|
| Air-gapped | On-premises | On-premises means the customer's hardware. Air-gapped additionally means no network path out. |
| Air-gapped | Private cloud | A private cloud account is customer-controlled but still networked, with documented rather than absent egress. |
Want these terms worked through on one of your own decisions? Start with a Decision Blueprint