Deployment boundaries and patterns

Choose a boundary from requirements

Deployment location is an architecture decision, not the definition of sovereignty. Begin with required controls, threats, legal or contractual constraints, continuity needs, skills, performance, and accepted dependencies. Then choose a pattern that can satisfy them.

Public cloud and managed AI

A managed environment can provide strong security, resilience, and operational capabilities. Sovereignty questions include administrative authority, service telemetry, regional scope, encryption-key control, model and service update policy, portability, provider concentration, and exit.

Use this pattern when the accepted shared-responsibility model is explicit and the required controls can be independently verified.

Private cloud or dedicated environment

A private or dedicated environment can narrow tenancy and network exposure while retaining managed capabilities. Verify what “private” covers: compute, control plane, support access, storage, networking, keys, logging, model endpoints, and artifact sources may have different boundaries.

On-premises or customer-operated platform

Customer-operated infrastructure increases direct control but also transfers responsibility for capacity, patching, supply-chain integrity, reliability, backup, skills, and incident response.

Do not assume ownership equals control. An on-premises workload that pulls unverified packages at build time or cannot be recovered has material sovereignty gaps.

Hybrid architecture

Hybrid systems deliberately place components in different environments. A common pattern keeps sensitive retrieval and records inside a controlled boundary while using an approved external model endpoint for eligible requests.

Hybrid design requires clear routing, classification, identity, DLP, failure, and evidence rules. Document what happens when classification is uncertain or the external service is unavailable.

Edge and distributed inference

Edge deployment can reduce latency and data movement, but introduces device identity, fleet management, physical exposure, model distribution, constrained observability, intermittent connectivity, and secure-update challenges.

Define the authority that approves and signs workloads, the evidence retained locally, and the recovery path for unavailable or compromised devices.

Restricted-network and air-gapped systems

Restricted or disconnected systems require an alternate supply chain. Plan the connected import zone, malware and license checks, SBOMs, signatures, approval, internal registries, package repositories, model storage, offline builds, controlled updates, and evidence export.

Air-gapping reduces some remote paths; it does not remove insider, artifact, configuration, operational, or physical risk.

Compare patterns using the same questions

For each candidate, record:

Data and processing boundary:
Administrative and key authority:
Artifact and model supply chain:
External control-plane dependencies:
Egress and support access:
Continuity and recovery:
Portability and exit:
Evidence available:
Skills and operating responsibility:
Known limitations:

The preferred pattern is the one that satisfies required controls with acceptable residual dependency, risk, cost, and operational complexity—not necessarily the pattern with the most local infrastructure.