Every enterprise AI conversation I sit in eventually turns into a debate about which model is smartest. Claude versus GPT versus Gemini versus whatever open-weights model just posted a new benchmark score. That is a real question, but it is not the first one enterprises need to answer.
The first question is where the work is allowed to happen. Which model reasons best matters, but only after you know whether that model is allowed anywhere near your data in the first place. Get that wrong and the smartest model in the world is not an option, it is a policy violation waiting to be discovered by your security team.
The real first question
Every AI deployment decision is really a data-location decision. Before anyone picks an assistant, a copilot, or an agent framework, somebody has to answer a duller question first: where is this specific class of data allowed to sit, and who is allowed to send it outside the walls.
That question used to get answered once, by whoever ran infrastructure. Now it gets asked project by project, team by team, because agentic tools showed up faster than the policy did. Most enterprises are answering it ad hoc right now, which means two teams in the same company can reach opposite conclusions about the same data class in the same month.
The three postures
There are three real postures for running AI work inside an enterprise today, and most companies of any size end up needing all three.
1/ Frontier API. You call a hosted frontier model directly. This is the fastest path to real capability, the model is state of the art the day you ship it. The cost is that your data leaves your walls and lands on a third party's inference endpoint, even if only for the length of the call.
2/ Cloud-marketplace hosted. You run the model inside your own cloud tenancy, through your AWS, Azure, or GCP account, usually behind a private endpoint. Your data stays inside your environment. In exchange you typically run a release or two behind whatever is newest on the frontier, and you take on real operational work: provisioning, scaling, access control.
3/ Open-weights on-prem. You run the weights yourself, in your own data center or a private cloud you control end to end. This is maximum control over data and inference, full stop. It also means you own the entire ops burden, GPUs, patching, scaling, monitoring, and you are usually running a model that trails the sharpest frontier options, since the very best models are rarely the ones anyone can self-host.
None of these three is the right posture in general. Each is right for a specific data class and a specific use case, and most enterprises end up running all three at once, on purpose, not by accident.
The inputs that actually decide it
Once the three postures are on the table, picking one stops being a technology debate and becomes an ordering problem. Four inputs decide it, and they bite in this order.
What the security review will pass, first. This is the actual gate. It does not matter how good a model is if data of a given sensitivity is not allowed to leave your walls for any reason. Security sets the ceiling before capability gets a vote.
Where the data already lives, second. Data gravity is real. If a workflow's data already sits inside one cloud provider's environment, the marketplace-hosted posture for that provider is a much shorter path than migrating the data somewhere else first just to reach a different model.
How much capability lag a use case tolerates, third. Drafting internal documentation can absorb a model that is a few months behind the frontier without anyone noticing. A customer-facing workflow, or anything high stakes, usually cannot.
Unit economics at scale, fourth. A posture that pencils out in a pilot running a hundred calls a day can invert once volume is real. Check the cost curve at the volume you actually expect, not the volume of the demo.
Which model is smartest does not make this list until the very end. That comparison matters, it just does not go first.
I have lived this from both directions
I have sat on both sides of this exact tension, once with AI, once with plain cloud migration.
At AWS, I worked the security side directly, getting Salesforce's Einstein AI roadmap through Amazon's own AppSec and privacy bar before enterprise-wide AI adoption could move. The model's capability was never the blocker. The review was.
Long before frontier models existed, enterprises fought a version of this same fight over contact-center software, on-prem against cloud, pointed in the opposite direction. At Cisco, I owned the customer-facing migration of the WebEx contact-center ecosystem off on-prem and into the cloud. Different technology, same underlying argument: control and ownership on one side, faster capability and less operational burden on the other.
What this looks like in practice
Picture a large enterprise rolling out agentic drafting help for its support organization. That support team also sits on the most sensitive customer data in the company: account histories, payment details, the works.
If the company has exactly one posture for all of AI, that team goes last, because the posture has to be set by the strictest data class anyone in the company touches, and support touches the strictest one. A marketing team running the same kind of agentic tool on public-facing content ends up waiting behind them, for reasons that have nothing to do with marketing's own data.
If the company has already decided posture per data class, both teams move immediately, on different postures, at the same time. Support runs on a cloud-marketplace or on-prem posture built for regulated customer data. Marketing runs on the frontier API, because public content was never the bottleneck. Same company, both teams moving, on different postures.
What I would actually do
If I were setting this up inside an enterprise today, in order.
1/ Map data classes before use cases. Use cases multiply every week. Data classes do not, most companies have a handful: public content, internal operational data, regulated customer data, and maybe one or two more.
2/ For each data class, get security and legal in a room once, decide the allowed posture, and write it down somewhere every team can find it.
3/ Stand up more than one posture in parallel. Do not wait for the frontier API rollout to finish before starting the on-prem build for the data class that needs it, they are not sequential problems.
4/ Put a date on revisiting the decision, a quarter out, not whenever someone escalates. Capability gaps between postures close over time, and a posture set in a rush is worth rechecking on purpose.
Do all four and the smartest-model debate becomes what it always should have been, a real conversation, just not the first one.
This is post 3 of 9 in my Thoughtful interfaces series. The rest lives at hagestedt.com/writing.