Your AI Vendor's Off-Balance-Sheet Debt Is Your Problem Too

The $1.65 trillion in hidden liabilities sitting behind America's five biggest AI companies isn't just a Wall Street story. It's a procurement story.

Nikkei ran a study this week that deserves more attention than it got outside financial circles.

Five US tech giants — the ones whose APIs power a significant fraction of enterprise AI deployments right now — are carrying an estimated $1.65 trillion in hidden debt. Data center leases, GPU supply commitments, long-term infrastructure contracts. Off-balance-sheet obligations that don't show up cleanly in the numbers most enterprise procurement teams look at when they assess vendor stability.

Meta's off-balance-sheet exposure alone is roughly $420 billion — nearly triple its transparent debt.

The financial press covered this as a capital markets story: what it means for stock valuations, what it signals about AI spending sustainability. That's a legitimate conversation.

But there's a different conversation that enterprise AI buyers should be having, and mostly aren't: what this capital structure means for how your vendor behaves toward you over a three-year contract.

The difference between a vendor with healthy margins and a vendor running on capital markets

Most enterprise software categories have a reasonably predictable vendor economics model. The vendor builds a product, prices it at some multiple of cost, invests in R&D and sales, takes a margin. Pricing changes are usually modest and defensible — they track inflation, feature additions, or competitive positioning.

AI infrastructure right now works differently in a specific way: the largest vendors are not pricing their services at a margin above cost. They are pricing them at whatever the market will bear while the capital market subsidizes the difference. OpenAI, Anthropic, and the major cloud AI providers are all operating in a regime where inference is priced below long-run cost — because the strategic goal is adoption and market position, not current-period profitability.

This is not a secret. It's been widely reported and the vendors themselves have discussed it in various forms.

What's less discussed: this pricing model is contingent on continued access to capital at the volumes required to sustain it. The $1.65 trillion in hidden infrastructure commitments represents obligations that must be serviced regardless of what happens to AI revenue. When the capital environment tightens, or when investors shift to demanding returns rather than funding growth, the math changes — and it changes fastest in the places where pricing was furthest below true cost.

For enterprise buyers, this creates a risk that doesn't show up in standard vendor assessments.

The vendor risk you're not screening for

Standard enterprise vendor assessment covers operational risk: uptime, SLA, data residency, security posture, incident response. These are real and the right questions to ask.

What they don't cover is pricing structure risk — the probability that your vendor's commercial terms change materially mid-contract because its capital structure requires it.

This is a different kind of risk, and it's harder to screen for because it's not visible in the vendor's current behavior. A vendor whose pricing is subsidized by capital markets is not a vendor in financial distress — it's a vendor whose pricing today reflects a bet on tomorrow's scale. That bet can be maintained for years. When it resolves, it resolves quickly.

We've seen three specific scenarios in conversations with enterprise clients:

Scenario one: repricing at renewal. The contract term ends and the renewal quote is materially higher — not because the vendor raised list prices, but because the capital-market subsidy that allowed below-cost pricing has been withdrawn. The client's budget was built on a rate that was never sustainable. The renewal cycle is when that becomes their problem.

Scenario two: feature tier restructuring. The vendor doesn't raise the base price — it moves capabilities that were previously included into higher tiers. What was an enterprise plan at $$X becomes a standard plan at$$X, and the features you were actually using now require an enterprise-plus tier at $2X. This is a price increase with a different shape.

Scenario three: model deprecation on short notice. The specific model your workflow was built around gets deprecated or moved to a legacy tier. Migration to the successor model requires prompt engineering rework, integration updates, and in some cases retraining — all of which has a cost that didn't appear in the original budget.

None of these scenarios require vendor malfeasance. They're normal responses to a capital structure under pressure. The problem is that most enterprise AI buyers built their procurement case on current pricing and current capabilities — with no explicit model for how either might change.

What open weights actually fixes — and what it doesn't

The natural response to vendor pricing risk is: use open weights models. DeepSeek, Llama, Mistral, Qwen. Self-host. No API dependency, no pricing exposure.

This is a real option and for some workloads it's the right call.

But it trades one cost structure for another. Self-hosting a frontier-class model requires GPU infrastructure, model serving capacity, and ongoing maintenance — engineering work that has a real cost that doesn't appear on a model provider's invoice. We've written about this before in the context of total AI project cost: the compute layer is typically 11% of total spend. Swapping the compute source from a vendor API to your own infrastructure doesn't eliminate the other 89%. It restructures some of it while adding new categories — infrastructure management, security patching, model version control.

Open weights also doesn't solve the capability gap risk in reverse. When a vendor deprecates a model, you have a migration problem. When an open source model community moves on, you have a maintenance problem — you're now responsible for a model version that nobody else is running in production, which means you're also responsible for finding and fixing the security issues nobody else will find for you.

The point is not that open weights is a bad choice. It's that vendor pricing risk and open weights hosting risk are different problems that require different mitigation strategies — and conflating them means you're not actually solving either.

Three questions enterprise buyers should add to their vendor assessment

Standard vendor assessments are well-designed for the risks they were built to catch. We'd add three questions that most of them currently miss:

First: what is the vendor's current cost of compute relative to its published API pricing, and how does that ratio trend as scale increases?

This is a hard question to get a direct answer to, and you probably won't. But how the vendor responds to the question is diagnostic. A vendor that can explain, in general terms, how their infrastructure economics work and what their path to sustainable pricing looks like is a different risk profile than a vendor who deflects or doesn't understand the question.

Second: what has this vendor's pricing history looked like over the past 24 months, and specifically, how have they handled model deprecation and capability tier changes?

This is answerable. Check the vendor's changelog, their pricing page history (Wayback Machine is useful for this), and the community discussion in their developer forums and Reddit. A pattern of frequent tier restructuring or short-notice model deprecation is a leading indicator of how they'll handle future capital pressure.

Third: if this vendor's pricing increased by 3× tomorrow, what would our migration path look like and what would it cost?

This is the question most procurement teams don't want to answer because the answer is usually "we don't know, and it would be expensive." That's exactly why it should be asked before signing a multi-year commitment rather than after a renewal surprise. The answer should include: which workflows depend on vendor-specific features that have no equivalent elsewhere, what the re-engineering cost would be, and what the timeline would be to migrate critical processes.

If the answer is "migration would take twelve months and cost more than two years of vendor fees" — that's a negotiating position, not a vendor selection outcome. It should affect the contract terms you accept.

What contract terms actually protect you

The vendor assessment conversation is about knowing what you're getting into. The contract terms conversation is about what you can do when the situation changes.

Three clauses worth negotiating explicitly in AI vendor contracts, particularly for multi-year commitments:

Pricing stability provisions. The contract should specify what conditions allow the vendor to reprice during the term, and what notice period is required. "Pricing may change with 30 days notice" is not a stability provision. "Pricing is fixed for the contract term for the capabilities specified in Exhibit A" is.

Model continuity provisions. If your workflow depends on a specific model or capability, that dependency should be named and the vendor should be required to provide either continuity or a defined migration support package if the model is deprecated. What constitutes "support" should be specific — not "we'll help you migrate" but "we'll provide [X] hours of migration engineering at no additional cost within [Y] timeline."

Exit ramp provisions. The contract should specify your right to terminate and what data portability and migration assistance looks like if you do. In a well-negotiated contract, this is a mutual risk management provision — the vendor has more certainty about your commitment, and you have more certainty about your options if the relationship changes.

These are negotiable in most enterprise AI contracts. They are not offered by default. You have to ask for them, and you have more leverage to ask before you sign than after.

The procurement frame that's missing

There's a pattern we've seen across the enterprise AI deals we've been part of or adjacent to: procurement teams are applying a software vendor framework to an infrastructure vendor dynamic, and the two have different risk profiles.

When you buy enterprise SaaS, the vendor's economics are relatively stable — the software is built, the margin is predictable, the pricing reflects a reasonably clear cost structure. The main risk is product direction and support quality.

When you buy API access to a model that's being priced below cost on a capital-markets timeline, you're in a different relationship. The vendor's incentive is adoption now and monetization later. That transition from "adoption" to "monetization" phase is the moment your renewal looks different from your initial contract.

The companies that are best positioned when that transition happens are the ones who saw it coming and structured their contracts accordingly — or who made architecture choices that gave them genuine optionality when the pricing environment changed.

That requires thinking about vendor risk earlier in the procurement process than most teams currently do.

One thing we might be wrong about

The scenario we're describing — AI vendors moving toward cost-reflective pricing as capital market conditions change — is directionally likely but not inevitable on any particular timeline. AI infrastructure costs are falling. It's possible that the gap between current pricing and sustainable pricing closes through cost reduction rather than price increase. In that case, the renewal risk we're describing doesn't materialize.

We're also working from aggregate data — the Nikkei figures are estimates, and the actual capital structure of any specific vendor is more complex than a headline number. Some vendors in this category are better capitalized than others. Some have revenue trajectories that make the math more sustainable.

The argument isn't "all AI vendors will have a pricing crisis." The argument is that vendor pricing stability — which has been assumed rather than examined in most enterprise AI procurement — is worth examining explicitly, particularly for multi-year commitments in business-critical workflows.

The downside of treating this risk seriously is that you spend some legal time on contract provisions that turn out to be unnecessary. The downside of not treating it seriously is that you find out three years into a deployment that the pricing your ROI case was built on has changed in ways you have no contractual recourse for.

Working notes from B2B AI deployment in North America. Part of an ongoing series on what we keep noticing across wildly different industries — and what the industry isn't ready to say out loud.

If you're currently evaluating enterprise AI vendors or structuring a multi-year AI commitment, this is one of the conversations we have with clients before they sign — alongside the data readiness, integration scope, and total cost modeling that determines whether the economics hold. [A 1-on-1 strategy call is the starting point.](https://zenaicorp.com/en)