Six Vendors Is Too Many to Manage the Old Way
The average enterprise now has six or more active AI vendors. This is not a problem that will solve itself. The natural trajectory of AI procurement is more vendors, not fewer, as different teams adopt different tools for different use cases and as vendors differentiate on specific capabilities. Managing this the way enterprise software was managed in 2018 does not work. The purchasing criteria, the evaluation framework, and the consolidation logic are all different, and the companies that have not updated their approach are finding this out expensively.
The CIOs who navigated the client-server transition in the late 1980s faced an almost identical challenge, and watching what they did right and wrong is instructive.
When IBM's Monopoly Ended
Through the early 1980s, most enterprise IT ran on IBM. The relationship was simple: one strategic vendor, deep integration, high switching cost, predictable pricing. Then client-server architecture arrived, and the economics inverted. Specialized servers from DEC, Sun, HP, and a dozen smaller vendors offered better price-to-performance ratios for specific workloads. Within a few years, the average large enterprise's server room looked like a trade show floor.
The IT departments that managed this transition successfully were the ones that built formal evaluation criteria before they started consolidating. They looked at total cost of ownership across the full lifecycle, not just the per-unit price. They measured integration cost: how much engineering work was required to connect this vendor's systems to existing infrastructure. They benchmarked performance on the actual workloads they needed to run, not the vendor's reference benchmarks. And they calculated switching cost explicitly: if they standardized on this vendor and it failed or pivoted, what would it cost to migrate?
The IT departments that managed by relationship got into long-term contracts with vendors who had the best salespeople, not the best technology. Some of those relationships lasted into the mid-1990s despite delivering mediocre value, because the switching cost analysis had never been done and nobody knew how expensive leaving would be until they tried to leave.
Why AI Vendor Management Is Different from SaaS Management
The SaaS procurement framework that most enterprises built over the last fifteen years handles one thing well: per-seat software with predictable monthly pricing. You evaluate the tool, negotiate the contract, manage the renewal. The cost is linear with headcount and the value is visible in user adoption metrics.
AI vendor management breaks this framework in three specific ways.
First, the pricing model is consumption-based, not seat-based. Cost scales with usage intensity, not user count, which means a small team running a high-volume workflow can generate more AI spend than a large team using AI occasionally. The procurement process needs to account for projected consumption patterns, not just the number of seats.
Second, capability overlap is significant and growing. OpenAI, Anthropic, Google, Mistral, and Cohere all offer models that can perform many of the same tasks. The differentiation is in cost-per-output for specific workload types, in reliability characteristics, in context window behavior, and in how well each model's outputs match your specific use case. Evaluating these differences requires running your actual workloads through each vendor, not reading their documentation.
Third, the switching cost calculation is different. Migrating from one SaaS vendor to another is primarily a data migration problem. Migrating from one AI vendor to another is a prompt migration problem, an output calibration problem, and often a quality regression problem that requires substantial engineering time to resolve. Factor this in before you standardize on a vendor because their sales team is responsive.
The Evaluation Framework That Works
Start with workload segmentation. List your production AI workloads and classify each by latency requirement, output sensitivity, volume, and task complexity. This gives you a map of what you actually need vendors to do, rather than what they claim to offer.
Run benchmark evaluations on your own inputs. Vendor benchmarks are useful for orientation. They are not sufficient for procurement decisions. Run each candidate vendor against a representative sample of your actual production inputs and measure output quality, latency, and cost per output. This takes a week of engineering time and prevents years of suboptimal vendor lock-in.
Calculate total cost of ownership explicitly. The model price per token is one component. The integration engineering cost, the switching cost, the reliability cost (what does a vendor outage cost you in production?), and the compliance cost (does this vendor meet your data residency requirements?) are the others. Vendors that look cheap on token price sometimes look expensive on TCO.
Build a consolidation hypothesis before you start consolidating. The client-server CIOs who consolidated successfully had a thesis: they were consolidating around two primary vendors with different strengths, keeping a small number of specialists for specific workloads, and eliminating everything else. The ones who consolidated without a thesis ended up with a different kind of sprawl.
IBM's dominance ended because the market offered better options. The companies that captured that value were the ones with frameworks to evaluate the options rigorously. The companies still managing AI vendors through spreadsheets and relationship calls are making the same mistake their 1988 predecessors made. Oberhahn's vendor-level attribution makes the TCO calculation tractable: you can see what each vendor is actually costing you across all dimensions before you decide who to consolidate around.