On-Prem vs VPC vs Air-Gapped Deployment for Enterprise AI

Almost nobody chooses a deployment model on the technical merits. They choose it because a clause, an auditor, or a security questionnaire appeared to demand it — and then spend two years building an architecture to satisfy a sentence nobody in the room has read closely.

The decision usually arrives sideways. Someone in the commercial team forwards a spreadsheet — a customer's security questionnaire, three hundred rows of it — with one cell highlighted, and the highlighted cell says something like the solution must be deployed within the customer's own environment. There is a deadline attached, because the deal is in its final week and this is the last open item. The architects read the sentence, decide that "the customer's own environment" cannot safely be interpreted as anything short of the customer's own data centre, and start pricing hardware. Within a month the AI programme that was going to launch in the second quarter has become an infrastructure project, and the reason it became one is a single ambiguous line whose author is not in the conversation and may no longer work at the company that sent it.

What is remarkable about this scene is how rarely anyone asks the obvious question. Nobody calls the person who wrote the row. Nobody asks what risk the requirement was drafted to address, what evidence its owner would accept as satisfying it, or whether it was written about a data-warehouse procurement in a different decade and copied forward ever since. The requirement is treated as a physical constraint, like a load-bearing wall, when it is in fact a claim someone made about what they need to be able to prove. Treating it as a wall is how organisations end up buying the most restrictive deployment posture available to satisfy an obligation that would have accepted considerably less, at a cost they will carry for the life of the system.

The three options are not really three architectures

It is worth being clear about what is actually on the table, because the standard framing obscures it. Running on your own hardware in your own facility, running in a dedicated private network inside a cloud account you control, and running with no route to any public network at all are usually presented as three points on a spectrum of security, as though each step buys you a measurable increment of safety over the one before. That framing is what makes the conversation unwinnable, because on a spectrum of safety there is no principled place to stop — every argument for the middle option is also an argument that you could have been safer, and no security team wants to be the one who chose "less safe" in a document that will be read after an incident.

The more useful framing is that these are three different answers to a single question: who can be compelled to hand over your data, and what would they have to do to get it. A private network inside a cloud account changes the shape of the tenancy and the identity boundary, but the underlying infrastructure is still operated by someone with a legal existence and an address. Your own facility moves the custody of the machines to you and moves a great deal of operational responsibility with it. Severing the network entirely changes what is possible in principle rather than what is permitted by policy. Each of these is a meaningfully different claim about control, and the reason organisations pick the wrong one is that they are trying to answer a safety question when the requirement in front of them was almost always about custody, jurisdiction, or auditability — questions with much more specific answers than "more secure, please."

Notice what this does to the decision. If the requirement is about custody of data at rest, there are several architectures that satisfy it and they differ enormously in operational cost. If it is about a named jurisdiction, the answer may be a region selection rather than a building. If it is about the ability to produce an evidence trail on demand — who accessed what, when, under whose authority, and what the system did with it — then the deployment topology is close to irrelevant and the real requirement lands on logging, retention, and access control, which you would have needed regardless. The architectures diverge wildly; the requirements they satisfy overlap far more than anyone assumes.

Find the person, not the sentence

The single most valuable hour in any enterprise AI deployment decision is the one spent tracing a requirement back to its owner. Requirements of this kind come from roughly three places, and the three behave completely differently. A contractual clause has a counterparty who can be asked what it was intended to cover, and clauses of this sort are frequently inherited from a template that predates the technology being deployed. An internal control has an owner inside your own organisation, usually someone who will tell you, if asked directly, exactly what evidence they need to sign off — and it is often less than the architecture team assumed, because the control owner cares about being able to demonstrate something, not about where the servers are. A customer's security questionnaire is the least authoritative of the three and the most likely to be treated as the most binding, because it arrives attached to revenue. Questionnaires are assembled by aggregation; rows accumulate across years and acquisitions, and a meaningful share of any long questionnaire consists of requirements nobody has revisited since they were written.

The discipline that follows is simple to describe and socially difficult to practise. For each requirement driving the deployment decision, you want three things written down: what specifically is being required, who owns the requirement and can grant an exception or an interpretation, and what artefact would constitute satisfaction. That last one is the load-bearing question. "The solution must be deployed within the customer's own environment" is not a specification; "we must be able to show our regulator that this data never left our control, and we accept a dedicated tenancy with customer-managed keys and a documented access model as showing that" is a specification, and it is one that several architectures can meet. Until you have the second form, you are not making a decision — you are guessing at somebody else's intent and paying for the guess in infrastructure.

This is also where the cost of guessing compounds in a way that is easy to miss. Every step up the restriction ladder narrows what the system can do and widens what your team must operate, and those costs do not sit still. They show up as model choices you can no longer make, integrations you can no longer reach, and a release cadence set by your own capacity rather than the platform's. That drag is a large part of why so many ambitious programmes quietly die: Gartner has predicted that over forty percent of agentic AI projects will be cancelled by the end of 2027, citing escalating costs and unclear business value among the causes. A deployment posture chosen defensively, to satisfy a requirement nobody verified, is one of the more reliable ways to manufacture both.

The restrictive choice is a ratchet

There is one more asymmetry that deserves naming, because it explains why organisations keep landing in the strictest configuration even when everyone privately suspects it is unnecessary. Restriction is easy to add and nearly impossible to remove. Once you have told a customer that their workload runs in an isolated environment, that statement enters their vendor record, gets cited in their next audit, and is repeated back to you as an established fact in the renewal. Once your own security team has approved a deployment on the strength of its isolation, relaxing it later requires someone to sponsor a change whose only benefit is operational convenience — a case nobody enjoys making. The decision you took in a rushed week to close one deal becomes the standing description of how your product works.

The right response is not to fight for the loosest posture, which is its own kind of unexamined default. It is to make the deployment model a deliberate output rather than an inherited input. A platform's Enterprise Deployment options are worth evaluating precisely on how cleanly they can be re-selected: whether the same system, the same agents, and the same operating model can run in a dedicated private network, in your own facility, or fully disconnected, without a rewrite between them. When that is true — and it is a genuine architectural property, not a marketing claim, one worth testing hard during evaluation — the requirement conversation stops being existential. You can start at the level your evidence actually supports and move if the evidence changes, rather than pre-committing to the strictest option because it is the only one you are sure will never be questioned. It is the same reasoning that runs through the broader literature on how autonomous systems get adopted inside large organisations: the constraints that decide these programmes are institutional far more often than they are technical, and the teams that succeed are the ones who work the institutional layer with the same rigour they bring to the stack.

So the mental model worth carrying is this. A deployment model is not a security setting; it is a claim you are agreeing to defend, indefinitely, to people you have not met yet. Before you choose which claim to make, find out what claim you were actually asked for — because the gap between those two things is where most of the cost of enterprise AI infrastructure quietly lives, and it is nearly always larger than anyone in the room believes.