A deployment pattern is the structural decision about how an AI model connects to your organization's systems, data, and users. It determines what the model can see, what it can do, who can invoke it, and what happens when something goes wrong. Choosing a model and choosing a deployment pattern are related decisions, but they're not the same one — and in most enterprise contexts, the pattern carries more weight.
That's the thesis of this section, and it's worth sitting with for a moment before moving on.
The Model Gets the Attention. The Pattern Gets the Problems.
When buyers start an AI evaluation, the conversation tends to organize around models. Which foundation model? Which vendor? Which benchmark score? These are reasonable questions, and they matter. But they're also not where most enterprise AI deployments succeed or fail.
The problems that surface six months into a production deployment are almost never model problems. They're pattern problems. The data the model needed wasn't accessible in the right form. The agent made a decision nobody could reconstruct afterward. The embedded AI in a SaaS tool couldn't be scoped to exclude a sensitive user population. The cost structure that looked manageable in a pilot collapsed under production query volume. None of these failures trace back to which model was selected. All of them were determined by how the model was deployed.
Buyers are already making pattern-level decisions when they evaluate AI. They're just not using that language. The AE who can name the pattern — and articulate what it implies — has a structural advantage in the conversation, because they're operating at the level where the real trade-offs live.
Note: In identity, we recognize this dynamic from federation design. The protocol choice — SAML, OIDC, whatever — is rarely the problem six months in. The problem is usually the trust model: the IdP can't express the claims the application needs, or the delegation structure doesn't survive token expiration, or the session lifetime assumptions don't match the user's actual workflow. The protocol was fine. The architecture was wrong. AI deployment follows the same pattern. The model is the protocol. The deployment pattern is the trust model. Your instinct to ask "what's the trust relationship here?" applies directly — just aimed at a different set of actors.
What "Consuming Safely" Actually Means
Enterprise buyers are not, in almost any case, training AI models. They are consuming models that someone else trained. This distinction matters more than it might seem.
Building a model requires decisions about data, architecture, compute, and alignment. Consuming a model requires decisions about access, scope, auditability, and control. The first is an ML engineering problem. The second is an enterprise architecture problem — and it's the one sitting across the table from you.
"Consuming safely" in this context doesn't primarily mean content filtering or model alignment, though those matter. It means: can you control what data the model can access? Can you audit what it did with that access? Can you revoke access for a specific user or use case without taking down the whole deployment? Can you explain the model's behavior to a procurement officer, an auditor, or a skeptical agency CIO? These are operational questions with architectural answers. And the answers depend almost entirely on the deployment pattern, not the model.
Note: Identity practitioners will recognize this as the same question set we apply to any system requesting access to sensitive resources. Least privilege. Auditability. Revocability. The difference with AI is that the "system" requesting access can generate its own queries, chain its own actions, and operate across sessions in ways that traditional access models weren't designed to handle. Your existing instincts are correct. The scope of what they need to cover is larger.
Seven Patterns, Seven Trade-off Profiles
The meaningful decision space for enterprise AI consumption maps to seven deployment patterns. Each one represents a different answer to the fundamental questions: how close does the model get to your data, how much autonomy does it have, and how much control do you retain?
Each pattern has a distinct cost structure, a distinct reliability profile, and a distinct set of questions worth surfacing in discovery. Some patterns are cheap to start and expensive to scale. Some offer strong auditability and weak flexibility. Some are the right answer for a specific use case and a genuinely bad answer for the one next to it. None of them is universally correct, and any buyer who's been told otherwise has been talking to someone with a product to sell.
The rest of this section walks through each pattern in sequence: what it is, how it works mechanically, what it costs, where it breaks, and what questions to ask when you recognize it on the table. Implementation knowledge isn't the point. Pattern recognition is — the ability to hear a buyer describe their AI initiative and know which structural decisions they've already made, which ones they haven't made yet, and which ones they don't know they're making.
That's the skill that makes a discovery conversation useful instead of performative. It's what separates a seller who can navigate the technical conversation from one who has to wait for a solutions engineer to show up.
The patterns are the map. The rest of this section is the legend.