BYOC, SaaS, or On-Premises: Choosing a Deployment Topology for Enterprise AI

Deployment topology is the first architectural decision and the hardest to reverse. It determines which data the system may legally touch, and every later choice inherits that constraint.

It is routinely treated as an infrastructure detail to settle after the functional design — which is how teams discover in month four that the system they built cannot process the data it was built for.

From the standard

“Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.”

The three topologies

Vendor-hosted SaaS

Your data is processed on the vendor's infrastructure. This is the fastest path to production and the right answer more often than security-conscious organizations like to admit — for public data, for internal content with no regulatory exposure, and for anything where the cost of a breach is embarrassment rather than a filing.

It fails on one specific condition: when a contract, a regulator, or a residency clause says the data does not leave. No data processing agreement changes where the packets go, and no certification substitutes for that.

Bring-your-own-cloud

The system splits along a hard boundary. A control plane orchestrates sessions, evaluates policy, and collects traces — and holds no customer data at rest. An execution plane runs inside your own cloud account, under your identity and access management, your network policy, and your egress rules. It is the only component that ever connects to your systems.

This is the topology that resolves most enterprise objections, because it makes the residency question answerable with a network diagram rather than a legal assurance. It costs more operationally: you run infrastructure, you patch it, and you own the failure modes inside your perimeter.

Fully on-premises

Both planes run in your environment. Appropriate for air-gapped networks, classified work, and operational technology environments where outbound connectivity is prohibited outright rather than merely restricted.

Two dependencies usually force outbound access and have to be resolved explicitly: model inference, which should route through a gateway you already operate, and retrieval embeddings, which should run resident and locally rather than calling a hosted embedding service. Solve both and the remaining stack has no reason to reach the internet.

What isolation actually means inside the execution plane

Choosing BYOC settles where the code runs. It does not settle how safely it runs there, and that distinction matters because an agent that writes and executes code is a remote code execution path you built deliberately.

Container-level isolation is insufficient for that workload. Containers share a kernel, and kernel escapes are a known category rather than a hypothetical. Agent-generated code belongs in a hardware-isolated sandbox — a MicroVM with its own kernel — so that a successful escape lands the attacker in an empty virtual machine.

Isolation alone still leaves an exfiltration path. Pair it with egress denied by default: a network filter and a DNS sinkhole restricting outbound traffic to an allowlist you define. A fully compromised agent then has nowhere to send anything, because exfiltration requires a destination and there is none.

The question to ask a vendor

Ask whether the on-premises build is the same codebase as the hosted one. Many vendors maintain two, and the self-hosted branch inevitably trails — you receive last year's system at this year's price, and every support conversation begins with establishing which version you are running.

Then ask what changes between topologies. In a well-built system the answer is deployment configuration and nothing else: the same containers, the same policy engine, the same audit pipeline, with the control plane relocated. If the answer involves a different feature matrix, the restrictive option is a second-class product and should be priced as one.