Renting intelligence is the new outsourcing mistake

It started with an API key and a company card. Someone in operations wanted to know whether a model could draft replies to supplier queries. It could, and quite well. By the end of the quarter the drafts went out with light edits. By the end of the year nobody could describe the process without it.

At no point did anyone decide to rent a core capability. The decision made itself, which is the most expensive way decisions get made.

That's how most organisations arrived where they are with AI. The question of owning vs renting AI gets asked late, usually when the process is already something the business runs on. By then the answer has been given by default. We call it the default nobody chose, and for one specific kind of work we think it's the wrong one.

Not for all AI work. For the work that is core to the business and runs every day.

Outsourcing already ran this experiment

In the outsourcing wave of the late 1990s and 2000s, firms moved IT and back-office work to specialist suppliers to cut cost. The logic was sound on paper. A supplier running the same work for many clients could run it more cheaply, and the client could concentrate on what it did best. For work that looks the same in every company, the logic mostly held in practice too.

It broke on work that turned out to be core. When a firm handed out something that shaped how it made money or served its customers, the same three things tended to follow. The know-how left with the work, because the people who understood the process now sat on the supplier's payroll. The supplier gained leverage, because it held the knowledge and switching meant rebuilding it. And bringing the work back in-house, what researchers call backsourcing, proved complex and costly.¹

Large buyers have since adjusted. Outsourcing didn't go away, but in Deloitte's 2024 survey, 70% of organisations had selectively brought parts of previously outsourced work back in-house over the previous five years, while still outsourcing.²

So the lesson is narrower than "outsourcing was a mistake", and far more useful. The mistake was outsourcing what was core.

Think of it as floor space. You can rent a warehouse for overflow stock, and nobody loses sleep over it. You don't rent the production line that makes your product, because then the landlord decides when it runs, what it costs and what it's allowed to make.

Renting a model through an API for core work is renting the production line. It isn't outsourcing a task around the capability. It's outsourcing the capability itself.

Three things you hand over: the price, the roadmap and the rules

Build a process on a model reached through an API, and three decisions move to the provider. This is what AI vendor lock-in looks like in practice. Not one clause in one contract, but a dependency spread across everything that makes a process predictable.

None of this is bad faith. It's simply what renting is, and the main providers all work this way. Landlords aren't villains; they just own the building.

For an experiment, each of the three is manageable. For a core process, each is a structural dependency. The price, the timing of change and the rules of access for something your business runs on are all set outside your business.

You're also teaching your supplier how your business works

When core work runs through a rented model, your business runs through it too. The contracts you draft, the support cases you resolve, the way you price a job, the documents that describe how your organisation actually operates: all of it passes through a system whose terms you don't set.

The major providers' business and API terms, OpenAI's and Anthropic's among them, say customer data is not used to train their models by default.⁵ Consumer plans are often treated differently, and terms change. In August 2025, Anthropic updated its consumer terms to ask users of its Free, Pro and Max plans whether their chats could be used to train its models; business and API customers were not affected.⁶

So the point isn't that anyone is misusing your data. The point is who sets the terms. When your data is protected by a clause in someone else's contract, the protection lasts as long as the contract says, and the contract is theirs to revise. When the data stays inside your own operational boundaries, the protection doesn't depend on a clause at all.

For core, steady work, owning should be the default

Owning the infrastructure your AI runs on reverses all three handovers.

The cost becomes an asset you plan, not a meter someone else reads. You decide how hard to run it and when to replace it. The roadmap becomes yours: you choose which model runs, and a model that does the job keeps doing it until you decide otherwise. And the data and the know-how stay inside your own operational boundaries, on your terms.

This is what we mean by Sovereign Enterprise AI: an organisation's ability to develop, deploy and govern AI systems under its own control, with its own infrastructure, its own data and its own models, inside its own operational boundaries.

Two questions get merged here, and they shouldn't be. Owning the infrastructure settles where the model runs and who controls it. Whether the model is open-weight, meaning its weights are published for anyone to download and run, or proprietary, is a separate question. In practice, owning usually means running an open-weight model on your own hardware, because the largest proprietary models are generally available only as hosted services, through their maker's API or a major cloud platform, and the customer never holds the weights.⁷ But a decision about one doesn't settle the other.

Owning isn't free of work, either. Someone patches the system, watches it and takes the call when it stops. That is the honest price of control, and it belongs in the decision.

Even so, the default is the wrong way round in many organisations today. Renting is the starting position and owning is the option that needs a business case. For core, steady work, flip it. Owning is the starting position, and renting is the choice that has to argue its way in.

Is owning also cheaper for a given workload? That's a question for real numbers, and it deserves its own careful treatment. The argument here holds before the numbers. For work your business depends on, control over its price, its roadmap and its terms is worth having.

When renting is the right answer

Renting is the right call more often than an argument like this might suggest. Here is when.

• Experiments and pilots. If you don't yet know whether a use case works, buying infrastructure for it is premature. Rent, learn, then decide.
• Spiky or unpredictable demand. Work that runs in bursts is exactly what metered pricing is good at.
• Work that isn't core. If a task looks the same in your business as in every other, a supplier controlling it costs you little. That's the warehouse, not the production line.
• Low volumes. Small, occasional use rarely justifies owning anything.
• Capabilities only the largest models offer today. If the work genuinely needs a model you can only reach through an API, rent it.

In every one of these cases we'd tell you to rent, and we'd say so to anyone who asked. The mistake isn't renting. It's letting work that has become core stay rented because nobody went back to the question.

Owning vs renting AI: the four-question test

The outsourcing wave taught this lesson once, and many firms paid full price for it, in years and in money. The second lesson is cheaper.

So take the AI work you already rent and put each piece through the four questions. Some of it will come out "rent", and that's fine. The rest is the default nobody chose. Decide it on purpose.