How to Choose an AI Vendor Without Marrying One

Eighty-five percent of enterprise leaders plan to increase AI spend in 2026, after already committing an average of 12% of functional budgets to it in 2025. Only 22% have gotten AI to actually work across more than one business unit. Eleven percent, per Gartner's September 2026 survey of 1,300+ functional leaders, cannot say what their own function spent on AI last year. Put those three numbers next to each other and the story isn't "adoption is slow." It's that budget, use case, and vendor are moving faster than anyone is tracking them — and a chunk of the enterprise doesn't even own the ledger showing where the money went.

That's not a maturity problem procurement can out-negotiate its way past. It's a control-plane problem, and it starts earlier than the RFP. Most vendor selections are still a prompt bake-off with a legal appendix stapled on: forty prompts, a scoring rubric, a winner circled in a slide deck. The model behind that winner will change at least once before the contract term is up. What won't change is which cloud it runs on, which identity system gates it, where the logs live, and whether the "agent" the vendor demoed is actually something your team owns or a runtime borrowed from someone else's platform.

Gartner's own read on the market makes the split explicit. In its December 2025 assessment of nearly 30 AI technology races, three different companies won three different contests: Microsoft was named the company to beat in enterprisewide AI, on the strength of its partner ecosystem and control of everyday work surfaces. Google took enterprise agentic platforms, built around its model stack and infrastructure. OpenAI led the large language model race outright, still the frontrunner on raw model capability. Three winners, three different questions. A CIO who reads "OpenAI is winning" as "we should buy OpenAI" has answered a model question with a platform decision — and those are not the same purchase.

Call it gravity instead of vendor. You're not choosing the smartest model in a bake-off; you're choosing which cloud, which identity system, which data path, and how expensive it becomes to leave. Enterprises already on Microsoft find OpenAI arriving by default through Copilot and Azure. Enterprises on AWS or multi-cloud infrastructure often route Anthropic through Bedrock, frequently alongside Google's Vertex. Enterprises anchored in Google Cloud get Gemini as the path of least resistance through Workspace and BigQuery. None of those defaults are wrong. What's wrong is treating the demo as the decision and discovering the gravity well only once the exit is expensive.

Four questions do more to protect an enterprise than another round of prompt comparisons — a companion set to the four questions a board should ask about any AI ROI claim, asked one stage earlier, before the contract is signed rather than after. First: what's the riskiest action this system is allowed to take without a human approving it first? If the honest answer is "summarize a document," almost any credible lab clears the bar. If the answer is "file a claim, approve a limit, or pay an invoice," the vendor's safety story and your own approval architecture both start to matter far more than which model wrote the best paragraph in the demo. Second: where does the prompt, the retrieved document, and the resulting log actually sit, and does the vendor train on any of it? Residency and subprocessor terms deserve a paragraph in the evaluation, not a footnote added the week before signature — this matters especially for organizations operating across India, the EU, or other jurisdictions with active data-residency rules. Third: if the model changes in ninety days, what breaks? If the honest answer is "our entire tool layer," the enterprise has already married the API, not rented the model — an interoperable tool layer is the closest thing procurement has to a prenup. Fourth: when the system is wrong, what can be handed to an auditor? A service-level agreement is not an audit trail. An owner, a policy version, a tool allowlist, and an evaluation set the vendor doesn't control are — the same accountability discipline the CLEAR framework argues for at the model layer, applied one level up, to the vendor relationship itself.

None of this argues for picking one lab. Paying two frontier labs at once is increasingly the default rather than the exception, and it's often cheaper than a forced rewrite later. The pattern worth building toward: let the system of engagement — drafting, coding assistance, everyday copilots — run on more than one model, routed by task rather than brand loyalty. Keep the system of action — anything that writes, approves, or pays — behind a single control plane that your own team owns: identity, tool allowlist, logging, and evaluation, regardless of which lab is answering the prompt underneath. Two labs without that shared plane is just two bills and two audit gaps. Two labs with it is genuine leverage the next time a renewal conversation starts.

This is also where Gartner's spend numbers loop back around. The 11% of organizations that can't say what they spent on AI last year almost certainly can't say which vendor a given dollar routed through either — the two blind spots share a root cause. Fixing it isn't a bigger dashboard project for 2027. It's naming one owner per AI line item now, tied to a business outcome and reviewed on the same cadence as cloud spend, so that renewal season isn't the first time anyone adds up what's actually running where. Gartner's own data backs the case for doing this early: organizations that track return by category — productivity, risk, revenue — and are willing to kill underperforming bets reported positive returns on 81% of their initiatives; organizations that don't track it that way couldn't even state the return on nearly a third of theirs.

The same survey surfaces a second, quieter warning worth folding into the same review: the AI use cases enterprises pursue most — cybersecurity threat detection, IT service-desk automation, code generation — are not the ones delivering the strongest returns — asset and cost optimization, synthetic data generation, and, again, code generation. Popularity and payoff are not the same signal, and a vendor evaluation that only asks "can you do the popular thing well" is optimizing for the wrong list.

None of this requires naming a winner, and doing so would defeat the point. The lab that fits this year's gravity may not fit next year's, and it shouldn't need to for the enterprise to stay solvent. What has to survive the next model release, the next renewal, and the next name change is the layer underneath: one owner, one control plane, one exit clause that doesn't require rebuilding the tool stack from scratch. Sign the lab as a supplier. Don't marry it.

For how this applies to building an agent stack on a mid-market budget, see the 2027 agent stack for mid-market enterprises.