The most important component in many new AI products doesn’t sit inside the company. It arrives through an API.
That isn’t necessarily a problem. Businesses have been renting technology for years: cloud infrastructure, payment platforms, CRM systems, security tools and almost everything else that can be attached to a monthly invoice. We don’t build an electricity generator every time we need to switch on a light.
AI changes the nature of that dependency, though. We’re no longer renting only storage or processing capacity. We’re renting something that writes content, generates code, interprets documents, speaks to customers and increasingly influences decisions. In other words, companies are beginning to rent part of their operational intelligence.
And the terms of that rental are still being written.
It’s been longer than I intended since I last published here. I could pretend I was waiting for the AI market to settle down, but at its current pace that would postpone the next article indefinitely. So I’m back with a question I’ve been thinking about for some time—and, I hope, without another long pause before the next one.
The question is not “Which model is the smartest?” It is: How much of our business are we willing to build around intelligence that we don’t own, whose behaviour we don’t fully control and whose price may change?
The answer shouldn’t be “none”. That would be unrealistic and, in many cases, commercially foolish. But “we’ll think about it later” isn’t much of a strategy either.
The smartest model is a moving target
Selecting an AI model can feel oddly similar to choosing a winner in a race that never ends. By the time the procurement process is complete, someone has released a faster runner.
The 2026 Stanford AI Index describes a market in which capabilities continue to advance rapidly while our ability to measure and manage them develops more slowly. It also notes that leading US and Chinese models have traded places at the top of performance rankings repeatedly since early 2025. That should make any five-year strategy built around today’s leaderboard slightly uncomfortable.
Benchmarks matter. They help us compare reasoning, coding, multimodal capabilities, latency and other characteristics. But a benchmark is not a business case, and the model that performs best overall may add no meaningful value to a specific task.
A customer-service workflow may need consistent answers, controlled language and fast response times. A complex fraud investigation may justify deeper reasoning and a much higher cost per request. Document classification might work perfectly well with a small model. Using the most capable model for all three would be like sending a senior partner to sort the office mail: impressive, certainly, but difficult to defend in the budget meeting.
The better question is not “What is the most intelligent model available?” It is “What is the least expensive level of intelligence that performs this task reliably enough?”
That small change in wording has large consequences. It moves the conversation away from model prestige and towards outcomes, evaluation and economics. It also makes it easier to change providers later because the requirement belongs to the company, rather than being defined by whatever the current model happens to do well.
Lock-in rarely announces itself
Vendor lock-in is often discussed as if it begins with a dramatic contract and ends with a heroic migration programme. Usually, it arrives much more politely.
The first integration uses a provider-specific API. Then the team adopts its tools, safety filters, vector store, agent framework and monitoring features. Prompts are tuned to the quirks of one model. Evaluation results assume its style of response. Security controls, support processes and employee training grow around it. A year later, changing a model is technically possible in the same way that moving house is technically possible. The word “possible” is doing quite a lot of work.
This dependency appears at several levels:
- Technical: APIs, tool-calling formats, model-specific features and platform services.
- Operational: evaluation suites, monitoring, support procedures and the knowledge accumulated by teams.
- Data: retrieval pipelines, embeddings, context structures and rules governing where information can be processed.
- Commercial: committed cloud spend, licensing, negotiated discounts, capacity agreements and support contracts.
- Behavioural: users learn what a model is good at, work around its weaknesses and gradually redesign their jobs around it.
The last one is easy to underestimate. Once a tool becomes part of how people work, switching costs are no longer confined to the technology budget.
It is also worth being precise about what we mean by an “AI provider”. OpenAI and Anthropic offer proprietary models. Meta has built a different proposition around open-weight models. Microsoft, Google and Amazon combine models, cloud infrastructure, enterprise platforms and distribution. These aren’t interchangeable business models, even if they sometimes appear in the same vendor comparison slide.
The concentration is significant enough that the UK’s Competition and Markets Authority has warned about over-dependence on a small number of firms, pointing to control over critical inputs, routes to market and a dense network of strategic partnerships. That doesn’t mean large providers are plotting to imprison every customer. It means their incentives and yours will not always be identical. This should not come as a shocking revelation to anyone who has previously met a supplier.
Lock-in isn’t automatically bad. A deep relationship with one platform can accelerate delivery, simplify security and provide capabilities that would be expensive to reproduce. The problem begins when dependency is accidental, invisible or treated as free.
The model price is not the cost of AI
AI pricing creates an appealing illusion of precision. Input tokens cost this much. Output tokens cost that much. Multiply by projected usage, add a cautious buffer and place the number in a spreadsheet.
The spreadsheet will look excellent. Reality may be less cooperative.
Token prices are only the visible part of the cost. A production AI service may also require data preparation, retrieval infrastructure, evaluation, guardrails, security reviews, observability, human supervision, incident handling and repeated testing when a provider updates a model. Agents can multiply usage by performing several model calls for what appears to the user to be one task. Longer context improves some answers while quietly increasing the bill. Failed or low-quality outputs still consume resources, even when they produce no value.
This is why cost per token is useful for engineering but incomplete for management. The business needs to understand cost per successful unit of work: a resolved case, an approved document, a useful software change, a qualified opportunity or whatever outcome the system is meant to produce.
The FinOps Foundation’s guidance on forecasting AI costs makes a similar distinction. It recommends tracking the cost per unit of work and recognizes that closed services, hosted open models and self-managed infrastructure have different trade-offs across quality, control, complexity and cost. Its separate guidance on generative AI cost tracking also highlights the difficulty created by different tokenization methods, hidden costs and decentralized usage.
There is another cost that rarely appears in the first business case: the price of changing your mind.
If a better model becomes available, migration means more than replacing an endpoint. The company may need to repeat evaluations, adapt prompts, revalidate controls, test integrations, retrain users and obtain new legal or risk approvals. A cheap model with a high exit cost may ultimately be more expensive than a slightly dearer one with clearer boundaries and better portability.
Open models offer freedom, not free freedom
At this point, it is tempting to declare that open models solve the problem. They certainly change the equation.
Open-weight models can offer more control over deployment, data location, customisation and infrastructure. They can reduce dependence on a single model vendor and may be attractive for stable, high-volume workloads or regulated environments. They also give companies more options when a provider changes its product or commercial terms.
But downloading model weights is not the same as acquiring a self-managing AI capability.
Someone still has to provide compute, optimise inference, apply updates, monitor performance, manage security, evaluate new versions and support the service. Greater control comes with greater operational responsibility. The FinOps Foundation’s infrastructure framework describes exactly this trade-off: self-managed infrastructure can improve control and long-term economics, but demands upfront investment, specialized expertise and considerably more operational work.
Owning the keys doesn’t make building maintenance disappear.
For many companies, the sensible answer will not be fully proprietary or fully open. It will be a portfolio: managed frontier models where maximum capability matters, smaller or open models for predictable high-volume tasks, and conventional software for problems that never needed generative AI in the first place. A deterministic rule engine is not old-fashioned when the answer must always be the same. Sometimes boring technology is simply technology that has finished proving itself.
Optionality needs design, not slogans
Some organisations respond to lock-in risk by demanding complete “model agnosticism”. The phrase sounds reassuring. It can also encourage teams to build an abstraction layer so generic that it removes the very capabilities that made the models useful.
Real optionality does not mean every model can be replaced in five minutes with no consequences. It means the company understands its dependencies, chooses them deliberately and can move critical workloads within an acceptable time and cost.
That requires a few practical disciplines:
- Define the required quality, latency, privacy and cost for each use case before selecting a model.
- Maintain your own evaluation set, based on real business tasks rather than public benchmarks alone.
- Keep business data, workflow logic and outcome metrics under company control wherever practical.
- Isolate provider-specific capabilities behind clear architectural boundaries, especially for critical processes.
- Measure cost per useful outcome and track failure, review and rework—not only consumption.
- Test an alternative model periodically for the workloads where losing choice would create material risk.
- Include exit costs and migration effort in procurement and business cases.
Evaluation is particularly important. The NIST AI Risk Management Framework treats the design, use and evaluation of AI systems as part of managing trustworthiness. From a business perspective, evaluation also gives a company something more basic: an independent definition of “good enough”. Without that, the provider effectively defines quality on the company’s behalf.
Not every workload needs an exit plan of equal sophistication. A tool that drafts internal meeting summaries is not the same as an AI component approving customer transactions or influencing a medical decision. Optionality should follow criticality. Otherwise, the organisation can spend a fortune protecting itself from a migration it would never rationally undertake.
The decision is not whether to depend, but where
Enterprise technology has always involved dependency. Cloud platforms, operating systems, databases and SaaS products all create it. AI providers are not uniquely malevolent, and building everything internally is neither practical nor desirable.
What is different is the role AI is beginning to play. When a third-party model helps shape customer interactions, software, analysis and decisions, the dependency moves closer to the company’s ability to operate and differentiate. That deserves more scrutiny than a line item labelled “API consumption”.
Before approving the next AI platform, I would ask one uncomfortable question:
If this provider doubled its price, changed its terms, removed a capability or simply stopped being the best option, what would we have to rebuild?
If the answer is “very little”, excellent. If the answer is “we don’t know”, the organization has already learned something valuable. And if the answer is “most of the product”, that may still be an acceptable decision—but it should appear in the business case, not emerge as a surprise two years later.
Companies will rent more intelligence. The economic and technological logic is too strong for anything else. The strategic task is not to avoid the rental market. It is to know what we’re renting, understand the full price and retain the ability to leave when the arrangement no longer works.
We don’t need to own every model. But we should be careful not to outsource the right to change our mind.
