Cloud versus on-premise versus air-gapped agentic AI

Deployment labels are shortcuts, not architectures. Two products described as on-premise can differ on model endpoints, licensing, identity, telemetry, package retrieval and support. Evaluate the complete dependency graph and operating model.

How do the three deployment models differ?

Dimension	Cloud	On-premise connected	Air-gapped
Runtime location	Provider or private cloud	Customer-controlled infrastructure	Customer-controlled isolated boundary
Internet dependency	Expected	Possible or optional	Prohibited across the gap
Model location	Hosted or private endpoint	Local, hosted or mixed	Inside the boundary
Identity	Cloud or federated identity	Enterprise identity	In-boundary identity and lifecycle
Updates	Online service path	Online or managed package	Controlled transfer and local validation
Telemetry	Provider, customer or both	Configurable boundary	Local collection and authorized export
Evidence custody	Contract and configuration dependent	Customer or shared	Inside the boundary by default
Support	Remote service access may be possible	Remote or customer-mediated	Approved artifacts and local procedures

An organization may use more than one model. Define where each workflow and data class is allowed to run.

What should the dependency inventory include?

List model endpoints, embeddings, vector stores, identity providers, policy services, secrets, package repositories, licenses, time sources, DNS, telemetry, update channels, vulnerability feeds, support access and evidence stores.

For each dependency, state location, data exchanged, identity used, availability need, failure behavior and owner. Then test the system with the dependency unavailable. A diagram that omits background calls does not establish an isolated deployment.

How should model placement be decided?

Match model capability to the task while respecting data location, handling rules, latency, hardware, energy, update process and provider terms. Retain a dated endpoint manifest and evaluation results for the tasks it is authorized to perform.

Model independence is useful only if policy, tool contracts and evidence survive a route change. Re-evaluate quality and safety before replacing an endpoint.

How do identity and authorization change?

Cloud deployments can often federate existing enterprise identity. On-premise and disconnected environments need an available local source of identity, group or attribute data, credential lifecycle and emergency access.

Authorization should be evaluated at each action regardless of topology. Disconnection is not an excuse to broaden permissions. Cache only the policy data and decisions the operating model can support, with explicit expiry and fail behavior.

How should updates work in a disconnected environment?

Treat every imported model, package, policy and configuration as a controlled supply-chain event. Verify origin and digest, inspect the contents, scan in an approved transfer zone, test compatibility, approve installation, retain evidence and maintain rollback.

Define the reverse flow for logs, incidents and support artifacts. Export only what policy authorizes, and preserve the evidentiary relationship between the exported artifact and the in-boundary source.

What failure behavior should be demonstrated?

Test loss of model service, policy service, identity, evidence store, target system, time source and operator availability. Exercise partial success, ambiguous timeout, duplicate request, full queue and rollback.

For every state, decide whether the agent denies, holds, retries, reconciles, degrades to a bounded mode or requires operator action. The decision should be visible to the user and recorded.

How should teams choose among the options?

Start with mission and data constraints, then compare whole-life operations. Cloud can speed managed delivery. On-premise can increase infrastructure control while retaining selected connectivity. Air-gapped deployment supports disconnected boundaries but transfers update, model, monitoring and support responsibilities inward.

Require an end-to-end demonstration in the proposed topology. Verify the evidence export, not only the happy-path user interface. Record assumptions, residual dependencies and the event that triggers a new architecture review.