Your AI vendor rents its compute.

The provider behind your provider

When you contract a document AI platform, you diligence the company whose name is on the invoice. You check its security posture, its data residency, its financial health, its references. What almost nobody checks is the layer underneath: the compute provider that actually runs the inference the platform depends on. For years that layer was invisible on purpose — it was a hyperscaler, it was assumed permanent, and asking about it felt like asking whether the electricity would stay on. In 2026 that assumption stopped being safe, because a large and growing share of AI inference moved off the incumbent clouds and onto a new category of provider that did not exist as a serious force three years ago.

These are the GPU-native providers — neoclouds — companies built specifically to buy accelerators at scale and rent them back as capacity. They grew explosively because the demand for inference outran what the incumbents could allocate, and they filled the gap with speed the larger players could not match. That speed came at a structural cost. Many of them financed their fleets with debt raised against the accelerators themselves, on the assumption that demand and refinancing would both stay strong. Their revenue often concentrates in a small number of anchor customers, so the loss of one or two contracts reshapes the business. And the gap between how much capital they raised and how operationally mature they are is real: contracted GPU capacity is not the same thing as incident response, SLA enforcement and the transparency a regulated buyer expects. The result is a supplier layer that is simultaneously essential to the AI you buy and more financially fragile than the vendor sitting on top of it.

What a neocloud is — and why it is fragile

It helps to be precise about the fragility, because "startup risk" is too vague to diligence. Three specific properties make a debt-financed GPU provider a different kind of dependency than a hyperscaler, and each one behaves in a predictable way when the market turns.

The growth is financed by debt that bets on refinancing. Accelerators are expensive and depreciate, so buying a fleet at scale usually means borrowing against it. That works while capital is cheap and utilization is high. It strains the moment either reverses — rates rise, a debt tranche comes due, or utilization dips below the level the repayment schedule assumed. A provider in that position has less room to absorb a demand shock than its headline growth rate suggests.

The revenue is concentrated. A provider whose book is dominated by a few large customers is exposed to the decisions of those customers. If an anchor tenant renegotiates, insources, or moves to a cheaper provider, the economics that underwrote the debt change overnight. Concentration on the sell side is the mirror of the concentration risk you would flag in any critical subprocessor — it just sits one layer further down than you are used to looking.

The operational maturity lags the capitalization. Raising billions and racking accelerators is fast. Building the incident response, the change management, the security controls and the SLA enforcement that an enterprise buyer relies on is slow. A provider can be very well funded and still be early on the things that matter when something breaks at 2am. Capacity is the part that shows up in the pitch; the operational spine is the part you only test when you need it.

A neocloud can be growing fast, be well capitalized and still be fragile — because the growth is borrowed, the revenue is concentrated, and the operations are younger than the balance sheet. The three do not cancel out; they compound.

Three infrastructure risks, all called "the cloud"

Part of why this risk hid for so long is that "where the AI runs" is doing several jobs at once, and boards keep answering the wrong one. A vendor can look excellent on two of these axes and be exposed on the third — and the third is the one that ends the relationship rather than merely raising its price.

The reason this matters for a procurement team is that the first two questions are the ones the market talks about. The pricing pages compete on token economics; the infrastructure conversation obsesses over power. The financial durability of the provider your vendor rents from is the axis almost nobody raises, because until recently it was nobody's job to ask and the provider was assumed permanent. The gap between what gets discussed and what actually caps continuity is exactly where this risk lives.

Why a provider's balance sheet reaches your SLA

It is tempting to file a compute provider's solvency under "someone else's problem" — the vendor's, the market's, the investors'. The reason it is your problem is that the dependency chain is unbroken and it terminates at your contract. Your SaaS platform runs a document workflow. That workflow depends on inference to classify, extract and reason. That inference runs on compute rented from a specific provider. And that provider's ability to keep serving depends on its balance sheet surviving the next downturn in a market that is famously cyclical. Every link is real, and the risk propagates up the chain the same way a supplier's insolvency propagates through any supply chain: the weakest financial link sets the continuity ceiling for everything above it.

When the compute market tightens — and it tightens every time a wave of over-building meets a cooling in demand — the squeeze does not announce itself as a credit event. It arrives as a provider quietly rationing capacity to conserve cash, a region that becomes "temporarily unavailable", an SLA that slips because the provider cut the staff who enforced it, a price step blamed on "infrastructure costs", or in the sharp cases an acquisition or wind-down that forces your vendor to migrate its entire inference stack on someone else's timeline. The buyer who never asked which provider sits underneath experiences all of these as unrelated vendor problems. The buyer who mapped the dependency sees them for what they are: a provider's financial fragility reaching up through the stack to touch the SLA they signed.

The due-diligence frame that treats compute as a supply input

The correction is not to become a credit analyst for the GPU market. It is to add the compute provider to the list of things you already diligence in a critical vendor — the same discipline you apply to a critical subprocessor, a data-residency commitment or a security posture. Five moves turn the abstract risk into a concrete procurement question.

Map which compute the service actually runs on

Ask the vendor the question they are not used to hearing. Which providers run the inference behind this service, in which regions, and what share of the workload sits with each? What capacity guarantee sits behind the SLA — reserved capacity, a priority tier, or a best-effort pool that gets rationed under load? And what is the plan if a primary provider fails, is acquired, or rations capacity: is there a second provider already integrated, or is the answer a hopeful "we would migrate"? The vendor who can answer crisply has thought about this. The vendor who treats the question as exotic is telling you they have assumed their provider is permanent.

Diligence the provider's durability like a subprocessor

You already assess the financial health of a payment processor or a core data subprocessor before you depend on it. Extend the same lens one layer down. You will rarely get audited financials for a private provider, but the direction of travel is a legitimate diligence input: is this provider funded to survive a downturn, or levered against a bet on continued refinancing? Is its revenue diversified, or does it hang on two anchor tenants? Has it built the operational spine — incident response, security attestations, change control — or only the capacity? Treat a compute provider the way you treat any supplier whose failure would interrupt your service, because that is exactly what it is.

Make stack portability a contract clause, not a hope

The single most valuable protection is that your vendor can move providers without rebuilding the platform. That is an architectural property, and it can be named in the contract: a commitment that the service is not hard-wired to one provider's proprietary surface, that models and pipelines can run on an alternative, and that a provider failure triggers a defined migration path rather than an outage. A vendor that has engineered portability will say so plainly. A vendor that has built everything around one provider's bespoke stack has taken on a lock-in that becomes your continuity risk the day that provider stumbles.

Reserve capacity and a continuity plan that survives consolidation

Hope is not a continuity plan. When the GPU market consolidates — providers merge, get acquired, or exit — the customers who keep serving are the ones whose vendors reserved capacity in writing and held a tested fallback. Ask for the continuity plan: not a paragraph of reassurance, but a named secondary provider, a defined recovery objective, and evidence that the migration has actually been rehearsed rather than sketched. A continuity plan that has never been run is a hypothesis, and a provider consolidation is a poor time to test it for the first time.

Read concentration as the risk it is

Concentration looks efficient on a cost sheet and reads as a single point of failure the moment the concentrated party is under strain. If a vendor runs all of its inference on one provider, and that provider concentrates its own revenue on a few tenants, you are two layers deep in correlated risk that a single downturn can trigger. The mature posture spreads critical inference across more than one provider — accepting some cost and complexity — so that one provider's trouble degrades the service rather than stopping it. This is the same instinct as diversifying any single point of failure; the input being diversified is the balance sheet under the compute.

Four ways it goes wrong

The buyers who get surprised in the next compute shakeout tend to make the same four mistakes. Each one is silent right up until the moment it is not.

Assuming compute is an infinite, stable commodity. The cloud sold permanence so convincingly that a generation of buyers internalized it as a law of nature. It is not a law of nature; it is a supplier relationship, and the newest and fastest-growing suppliers are also the least proven. Capacity that "just runs" runs only as long as the company behind it stays solvent, and in a cyclical market that is not a safe assumption to leave unpriced.

Anchoring the stack on a single provider with no portability. Building the entire platform around one provider's proprietary surface feels efficient and is the fastest path to shipping. It also means that a provider's failure, acquisition or rationing becomes a rebuild under time pressure. A stack that cannot move is a stack that inherits its provider's every problem, on the provider's timeline rather than the customer's.

Ignoring the provider's financial health in the vendor assessment. A vendor assessment that stops at the vendor treats the compute layer as invisible plumbing. But the plumbing has a balance sheet, and if it is levered against a bet that may not pay off, that fragility is now inside your supply chain whether or not it appears on your risk register. Filing the provider entirely under "the vendor's problem" means the continuity question never gets asked until the provider is already in trouble.

Signing a contract with no continuity clause for consolidation or failure. Most SaaS and AI contracts say a great deal about uptime and nothing about what happens if the underlying compute provider is acquired or fails. The implicit assumption is that the provider is permanent. When it is not, the contract that named a migration path, a secondary provider and a remedy is the one that protects the customer. Silence in the contract is not neutrality; it is an unwritten agreement that the customer absorbs the disruption of a provider event.

The trade-off nobody states out loud

Durability is not free, and pretending otherwise is how these conversations go wrong. The cheapest, fastest-growing provider is often cheap and fast precisely because it took on the debt and the concentration that make it fragile. Insisting that a vendor run on the most durable providers, keep a second one integrated, and reserve capacity in writing costs more than riding the cheapest available capacity — and it constrains some of the flexibility that made the cheap provider attractive in the first place. The buyer who demands maximum durability everywhere pays for resilience they may never need. The buyer who optimizes purely for price inherits maximum exposure.

The honest position is that this is a portfolio decision, not a binary. Insist on durability and portability for the workloads whose interruption is genuinely costly — the regulated pipeline, the customer-facing extraction with an SLA, the volume the business depends on daily. Leave the deferrable and experimental work on cheaper, best-effort terms where flexibility is worth more than certainty. The point is not to eliminate the trade-off; it is to make it a deliberate allocation instead of an accident of whichever provider your vendor happened to sign first.

What this means for document AI specifically

Document AI sits in an unusually exposed spot, for three reasons, and each one has a mitigation that a serious vendor should already be running.

The workload is steady, high-volume and business critical. An extraction pipeline runs a predictable, continuous load that a business often depends on daily — which means a provider event does not degrade a nice-to-have, it interrupts a core process. That is precisely the kind of workload that justifies the cost of a durable, portable, multi-provider posture rather than the cheapest available capacity.

Much of it does not need the frontier provider at all. A large share of classification and structured extraction clears the quality bar on compact models that can run on air-gapped or on-premise infrastructure the buyer controls, with the residency logic of a sovereign pipeline. Routing that share off any single external provider both reduces the dependency and keeps the sensitive material where it belongs — the same discipline as the supply-side economics that make compute a moat in the first place.

The buyers are sophisticated and regulated. Banks, insurers and accounting firms already run vendor continuity diligence and subprocessor assessment; adding a compute-provider durability question to the existing framework is a small extension, not a new program. The vendor that can name which providers run its inference, show its portability and produce a rehearsed continuity plan is the vendor that passes the diligence the incumbent running on a single fragile provider quietly fails. The provider-durability question sits alongside the broader provider due-diligence frame; financial continuity is one more axis on the same scorecard.

Closing thought

The buyer who still evaluates an AI vendor on price and features alone is running a due-diligence process built for a world where compute was a permanent, infinite utility — a world that stopped existing the moment inference moved onto a layer of fast-growing, debt-financed providers whose durability is genuinely uncertain. In the next compute shakeout, that buyer discovers that the continuity of the SaaS they contracted for depended on the solvency of a provider nobody diligenced. Meanwhile the vendor that spread its providers, engineered portability, reserved capacity in writing and moved the sensitive and steady work to infrastructure it controls delivers something the price-only competitor cannot: a service that keeps running when a provider does not.

At Cogneris we treat the compute provider the way we treat any other critical supplier — diligenced for durability, kept portable so no single provider is load-bearing, and partly resolved on infrastructure we control where the sensitive and steady document work belongs, so that a provider event upstream degrades gracefully instead of going dark. If you are running vendor diligence on a document AI programme, or rewriting the continuity section of a procurement template before the next renewal, see our product page, the pricing page, or talk to our team. The token price is what the headline writes about; whether the provider producing the token is still there next year is what the SLA turns on.