Inference vendor risk is now counterparty risk

A three-year inference contract usually starts with unit price and ends with a discount traded for committed volume. The discount is the visible half. The other half is that for three years you have not only bought compute, you have placed your architecture on one company’s cash-recovery cycle. On 14 October, Gartner put a number on that cycle.

Gartner ran the arithmetic

If AI providers hold their current pace of capital spending, more than $3.5 trillion of AI infrastructure spending could be exposed to impairment by the end of 2030, according to Gartner. Push the trajectory further and more than $4 trillion in asset value faces write-down risk through 2032. The spending assumptions behind it: AI providers are expected to spend nearly $1 trillion on AI infrastructure in 2026 and invest an additional $6 trillion between 2027 and 2030.

The reasoning is not complicated. Enterprise and consumer AI revenue will not be enough to support profitable returns on all the planned capital expenditure. The question is not how much demand exists but whether demand, once converted into revenue, covers assets already bought.

The size of the gap shows up in another figure. Secondary coverage of the release states that data centres would need $8.5 trillion in cumulative revenue to cover capex and reach a 12 per cent return on invested capital, while Gartner forecasts no more than $3.6 trillion; on that trajectory, 12 per cent ROIC does not arrive until the end of 2032 at the earliest. Both numbers are a retelling of Gartner’s model rather than a recorded financial fact, and should be cited that way.

Who goes first

Gartner expects more than 80 per cent of neocloud providers to cease independent operations by 2030. Its reason is that this tier lacks the large and highly diversified revenue streams of the hyperscalers, which can carry a period of sub-par returns.

Hyperscalers sit in a different position. Gartner’s reading is that their other businesses keep funding AI investment even when AI-specific returns fall short. Treating the two tiers as one risk category does not hold up; they face two different sets of books.

Demand is not the problem. Gartner expects spending on AI-optimised infrastructure-as-a-service to rise from $66 billion in 2027 to $174 billion in 2030, a steep line. Its concern is that many compute providers will fail to recover their investment before the current generation of AI semiconductors is replaced. Revenue growth and capital recovery are separate calculations over separate horizons.

Why this lands on your architecture

For the past three years, the identity of an inference vendor was a safe assumption to ignore. When pricing stopped working you moved, and the change landed in a config line or an SDK parameter. That substitutability made the vendor look like a constant.

If four-fifths of one tier disappears within five years, the constant becomes a variable with an expiry date. Everything that treated it as constant deserves a re-read: budget models built on one vendor’s pricing shape, capacity plans that place workloads across regions, where data residency and logs live, who holds the run records, and the service-level terms in the contract.

The symptom rarely arrives on the day service stops. It shows up at the negotiating table first. To get a lower unit price you sign a minimum-volume commitment, tying your usage to one vendor’s capacity. To keep model behaviour stable you pin a version to their route. For convenience the logs and run records stay only on their platform. Each decision was reasonable at the time, and all of them assume the company will still be there.

Five questions before signing

First, transfer terms. If the vendor is acquired, restructured or exits the business, what happens to the contract and the capacity already bought, and who owes continued service. Second, the volume commitment and its penalties: what happens if you miss the floor, and what the vendor owes you if it misses the capacity it promised.

Third, model versions and deprecation notice: how much notice before the model you built on is retired, and what acceptance makes a replacement equivalent. Fourth, exportability and format for data, logs and run records, and whether your own systems can parse them independently. Fifth, the exit window: how many days between notice and the service actually stopping.

Put those five answers in an annex rather than an email thread. A vague answer is also an answer, and it says the capability is not on the roadmap. Take the discount, but when you trade commitment for it, price the migration cost into the same table first.

What we do ourselves

Inside this company we keep model calls behind a gateway, so the provider is a configuration entry rather than code. Changing vendors is a config change and a re-run of the acceptance set, not a change to business logic. The point is not cost. It answers one question: when the counterparty changes, how much time do you lose.

One acceptance rule goes with it. After moving each workload class to another vendor, can the same set of test cases confirm it has not got worse? That set is ours rather than the vendor’s, and it covers factual accuracy, schema validity, refusal behaviour and tool-selection correctness. If the same cases fail after the move, the migration is not done, however much it saved.

Together those two practices cover only the half we control. Whether a vendor disappears is not something we can judge and not a place we hold an information edge. What we can control is being able to move at our own pace after a notice arrives, and the way to do that is unglamorous: keep the replacement action small enough that it is routine rather than a project.

Putting the three horizons on one page

Horizon matching only works as a table. Three columns: your contract term, the model deprecation notice period, and the vendor’s cash-recovery cycle. The first two live in the contract, the third in its financial logic, and the risk sits in whichever stretch does not line up.

The most common mismatch is the middle column. A three-year contract, while a model goes from deprecation notice to retirement in a few dozen days. When the notice period ends, the acceptance set you built does not migrate by itself: prompt structure, tool-call formats and refusal boundaries can all shift, and the third year then contains a conversion job nobody budgeted for.

Writing that column into the annex solves half of it. Ask for the notice period, the acceptance criteria for the replacement model, and an obligation to assist migration inside that window. Whatever cannot be written down, at least measure its length, because the length is what tells you which workloads can sit on that road.

Turning exposure into a number

Sort workloads into migration-difficulty classes, record what share of traffic each one holds and how many days each needs, then weight the result into a single exposure figure in days. It does not have to be precise. Its job is to convert an unanswerable question, whether this company survives, into an answerable one: if it goes, how much time do we lose.

Its second use is surfacing disagreement. In one team, engineers usually believe a switch is trivial while business owners believe it is impossible; the weighted figure puts both assumptions in the same place and shows which workload class the difference sits in. And if your workloads are small and portable, the number comes out small, in which case the correct answer is to accept the risk and spend the attention elsewhere.

Limits: this is a model output, not an event

First, the $3.5 trillion is what Gartner’s model produces under a stated premise: providers maintain their current pace of capital spending. Change the premise and the figure changes. It is not a write-down that has happened.

Second, analysts have given widely different readings of the same question. Buyers heard comparable warnings about cloud overcapacity years ago, and those were partly right and partly unfulfilled. Cite who forecast what, under what premise, and do not restate it as fact.

Third, neocloud survival risk does not transfer to the hyperscalers. Their revenue structures differ, and Gartner judges them separately. Using the first group’s conclusion to describe the second misreads the release.

Fourth, the risk being real does not mean every buyer should migrate. If your workloads are small, portable and latency-tolerant, a vendor disappearing is inside your tolerance. The answer depends on how much you would have to move, not on how loud the warning is.

Our judgement

Our judgement is that inference procurement has moved from unit price to horizon matching. Three durations have to line up: your contract term, the model deprecation cycle, and the vendor’s cash-recovery cycle. Everyone assumed all three were long enough; today only the contract term is something you can write down.

Three things follow that can be done tomorrow. First, tag every vendor you use with two numbers: how many days to move all workloads, and what share of workloads is movable. The second number usually looks worse than the first, because some workloads are held in place by capability or compliance.

Second, write transfer terms, deprecation notice and exit window into the current contract annex while you still have leverage. Third, abstract the vendor into one layer so replacement does not touch business code, and define migration as done only when the same acceptance cases pass on the other side.

The question to leave with: if this vendor told you today that service stops in 90 days, how many days would it take you to move everything? That number is your exposure. It is worth calculating before any discount, because a discount saves one year of spend, while the part you cannot move stays where it is.

Sources

Gartner press release, Gartner Says Over $3.5 Trillion of AI Infrastructure Spending Could Be Exposed to Impairment by the End of 2030, 2026-10-14 (source of the $3.5tn, $4tn, 12% ROIC and the $1tn plus $6tn spending figures)

AI Weekly coverage of the same release (the $8.5tn cumulative revenue requirement against a $3.6tn forecast ceiling, and the 80% neocloud figure, both retold from Gartner’s model)

HostingJournalist, Gartner Warns of $3.5 Trillion AI Infrastructure Impairment Risk by 2030 (source of the $66bn to $174bn AI-optimised IaaS range)