Provider risk moves to the cap table.

The shift was not the round size — it was the cap-table consequence

For most of 2024 and 2025 the financing news about frontier AI labs read like venture rounds at a different scale: bigger numbers, longer zeros, the same private-company category. What 2026 did was move those numbers into a different category altogether. Valuations crossed and approached the trillion-dollar line. The first labs printed a quarter that was operationally profitable rather than funded-loss. IPO prospectuses leaked, S-1-shaped documents showed up in trade reporting, and antitrust regulators opened files in three jurisdictions. The lab everyone treated as a research collective with a commercial side became, in the eyes of public-markets investors, a software company with an unusually high gross margin.

The downstream consequence is the part most engineering teams have not absorbed yet. When a lab is private and loss-funded, the buyer's risk question is mostly technical: does the model meet the workload, does the API stay up. When the lab is approaching IPO with a public balance sheet, antitrust scrutiny, governance review and a committed compute schedule, the buyer's risk question moves up two floors. Procurement now reads the lab the same way it reads a custodian bank or a clearing house: solvency, governance, exit, pricing trajectory after monetisation, regulatory exposure by jurisdiction. The model is a feature. The provider is a counterparty.

The line we keep hearing inside enterprise IT shops is a procurement-team line, not an engineering one: "we are not allowed to take a single-vendor dependency on a pre-IPO software company any more, and we have eight of them." The compute-moat dynamic that turned inference cost into a strategy decision — covered in the compute-as-moat piece — is the upstream cause; the cap-table conversation is the downstream effect. Both arrive at the same place: the buyer who treats the model provider as a commodity API renewal in 2026 is the buyer who rediscovers vendor risk the hard way in 2027.

What changed in the 12 months that made this a board item

Three structural moves explain why provider selection graduated from a junior procurement decision to a CFO-and-CIO joint review.

IPO economics changed the unit pricing trajectory

A loss-funded private company can price below cost to win share; a public company answering to quarterly margin expectations cannot. The labs that built share by underpricing inference were doing so on venture capital; the labs heading toward the public markets are reshaping price lists to make gross margin show up on a printed quarter. The buyer reading the API price list in 2024 was reading a strategic loss; the buyer reading the same list post-IPO will be reading a margin target. Industry analysts have published mid-cycle estimates of 20–40% token-price increases on the major commercial tiers in the first 18 months after the IPO window opens. Buyers who signed multi-year contracts without a price-pass-through ceiling are quietly running the math now; buyers who left it in the contract as a comfort clause are about to read what their comfort clause actually says.

Operational profit changed the diligence standard

When a lab reports a first operationally profitable quarter, two things happen at once. Equity research starts treating the company as a public-software comparable. And enterprise procurement is allowed — required, in the regulated sectors — to ask the public-software questions: what is the gross margin profile by product line, what is the customer concentration, what is the revenue at risk if the largest counterparty leaves, what is the regulatory exposure if a key jurisdiction imposes a new control. The questions are normal for a custodian or a clearer; they were exotic for a research lab. In 2026 they are the cover sheet of the provider risk register.

Governance shifted from "founder mode" to "public-markets mode"

Pre-IPO governance is a founder, a board of insiders and a research mission. Post-IPO governance is a public board, an audit committee, a disclosure cadence, an antitrust regulator with subpoena power, and a class of shareholders that votes on capital allocation. Each of those entities introduces a new way for the provider's roadmap to move in a direction the buyer did not predict. A board change, an antitrust remedy, a strategic-investor unwinding, a covenant breach — none of these are engineering events, all of them propagate to the API the buyer depends on. The procurement team that does not have a contingency for "our largest model provider is forced into a structural remedy" is the team that wakes up to a deprecation notice it cannot fight.

The model is a feature. The provider is a counterparty. The buyer who treats them as the same thing is the buyer whose audit committee asks, six months from now, why no one had a portability clause.

The four contract clauses every enterprise IT shop is now writing

Procurement teams at large enterprises have converged on a short list of clauses that did not exist in their AI contracts in 2024 and are non-negotiable in 2026 for any deal above roughly US$ 250k ARR. They are not exotic; custodian-bank and clearing-house contracts have carried equivalents for decades. The novelty is that they migrated into the AI provider contract.

1. Exit on change of control

If the provider is acquired, taken private, merged with a strategic, or restructured under an antitrust remedy, the buyer can exit without penalty inside a defined window — typically 90 days — and the provider supports an export of fine-tunes, prompts and evaluation sets in a documented format. The clause is not about anticipating a specific deal; it is about removing the cliff that turns "our provider was acquired" into "we just lost our AI program for a year." Buyers who skipped this clause when the category felt early are the ones drafting amendments now.

2. Portability of prompts, fine-tunes and evaluation sets

The exit clause is theatre without portability. The practical version: prompts, fine-tunes, embeddings, retrieval indices, evaluation sets and routing policies must be exportable in a form that runs against a functionally-equivalent model from a second provider without rewriting the application. The clause names the second provider — or a class of them — and the export format. The provider is allowed to charge for the export only at documented cost. We covered the parallel clause for residency in the sovereign-AI piece; portability is the same idea applied to the application layer.

3. Price-pass-through ceiling with renegotiation triggers

The pricing-trajectory risk after IPO is real and the clause that controls it is specific. The contract names a maximum annual increase on per-token pricing — 8–15% is the current band — and defines two trigger events that re-open negotiation: a price increase by the provider that exceeds the ceiling, and a model deprecation that forces the buyer onto a more expensive tier. The price-pass-through question on the procurement side mirrors the cost-build-up question on the vendor side covered in the compute-moat piece: the buyer wants the build-up; the buyer also wants the ceiling.

4. Sub-processor diversification and disclosure cadence

The largest labs ran on one or two hyperscaler clouds in 2024; many still do. The clause that emerged in 2026 is not "diversify the hyperscaler" — that is the provider's problem. The clause is disclosure: the provider tells the buyer which sub-processors run inference, which jurisdictions they sit in, and which would survive the loss of any one of them. The buyer's audit team gets a refresh cadence — usually quarterly — and a notification window before a material change. The deeper rationale, including the sub-processor cascade and the data-protection envelope, is in the AI sub-processors piece; the procurement clause is the operational hook that makes the policy enforceable.

The provider risk register that survives a board review

Procurement and risk teams that have done this work converge on a register with eight rows. The columns are less interesting than the rows; the register is what the audit committee asks to see when the board adds AI to its quarterly risk review.

The register is not the work; the register is the artefact that proves the work was done. The work is the architectural posture that lets the buyer move workload between providers without rewriting the application. That is the next section.

The three architectural moves that turn provider risk into a hedge

The cap-table conversation is a board conversation; the only place it actually gets resolved is the application architecture. Three moves separate a buyer who can talk about provider risk from a buyer who has hedged it.

1. Model-agnostic application layer

The application speaks to a routing layer; the routing layer speaks to N providers. The prompts, the evaluation sets, the validation policies and the observability sit above the provider boundary. When a provider deprecates a model, raises a price, throttles capacity or gets restructured, the buyer changes a routing weight — not an application. The work that pays for itself is in the boundary: a thin abstraction that does not leak provider-specific behaviour into the application, an evaluation harness that compares candidates against the buyer's actual workload, and a router with policy. The compute-moat piece covered the cost dimension of the router; the provider-risk dimension is the policy that decides which workload runs on which provider when one of them ships news.

2. Eval-driven failover, not pitch-driven

The failover policy is set by an evaluation set that runs on a cadence — daily on a small set, weekly on the full corpus — and the candidate provider's score on the buyer's own documents decides the routing weight, not the provider's marketing claim. The point is mundane and underrated: a model that wins the public benchmark loses on a specific buyer's KYB packets, claims forms or long-context invoices roughly half the time. The buyer with an eval harness already running knows the failover target before the failover event; the buyer without one finds out in production. The closest piece on this on the engineering side is the verifiable-reasoning piece; the verifier is upstream of the eval set, and both reduce the surface area where a model change propagates as a quality regression.

3. Sub-processor diversification on the provider side and the deployment side

The buyer's hedge is not only across providers; it is across deployment shapes. For sensitive workloads, an in-region or on-prem footprint reduces the buyer's exposure to the provider's hyperscaler dependency. For commodity workloads, multi-cloud routing across the provider's own footprint reduces the exposure to a single region. The shape that ships is a 3×3 matrix: provider on one axis, deployment posture on the other, workload class in the cells. Most enterprises end up with two providers, three deployment postures and a workload-mapping policy that fits on one page. The sovereign-AI piece goes deeper on the deployment axis; the provider risk register is the axis the matrix lives on.

The mistakes we keep seeing

Five anti-patterns show up across enterprise engagements in the first half of 2026 and each of them is the kind of thing an audit committee finds embarrassing in hindsight.

Lock-in by prompt engineering, not by contract. The application is technically portable; the prompts are not. Switching provider means re-tuning every prompt against the new model, which is a quarter of work nobody scheduled. The fix is to keep prompts in a separate repository, version them, and run the eval harness on every change against both incumbent and candidate providers. The cost is modest; the option value is large.

"Procurement read the SOC 2" as the entirety of due diligence. A SOC 2 is a control audit on the provider's operations. It is silent on cap-table risk, governance shape and IPO trajectory. The buyer who treats the SOC 2 as the provider risk file is the buyer whose audit committee finds out the file was incomplete when the next disclosure event lands.

Single-vendor concentration above 60% with no named contingency. The architecture is "we use provider X for everything"; the contingency is "we will figure it out if we have to." That is not a contingency; it is a sentence. The 60% line is not a magic number, but it is the threshold most risk committees will not accept without a named alternative provider and a current eval-harness result.

Treating an antitrust filing as a press story. Once a regulator opens a structural-remedy file on a major provider, the buyer's risk team should be reading the docket, not the recap. Antitrust remedies move roadmaps. The buyer who finds out from the press is the buyer who finds out late.

No dry-run of the exit clause. The clause is in the contract; the export procedure has never been executed. The first time the buyer tries to invoke it under pressure, it turns out the export format is ambiguous, the fine-tunes are not portable, or the contracted transition window is too short. The fix is boring: run an exit dry-run on a small workload once a year. The dry-run is the audit evidence that the clause is load-bearing.

What this means for document AI specifically

Document AI sits in the corner of the AI market most exposed to the provider squeeze. The workloads are high-volume, the per-document margin is thin by construction, and the buyer's procurement function is mature. A document AI vendor that does not control its own routing layer, evaluation harness and policy enforcement is a vendor whose pricing power belongs to the upstream provider. Three concrete consequences are already visible in our 2026 buyer conversations.

The RFP changed shape. The question in 2024 was "which model do you use." The question in 2026 is "which providers can your platform route across, which deployment shapes do you support, and what is the exit procedure if we ask for it." We answer in writing, we ship the eval-harness numbers on the buyer's own documents, and we demonstrate the routing change live. The buyer notices.

Pricing power moved to the platform that controls the router. A document AI platform that owns the routing, the evaluation set and the policy can absorb a 30% upstream price move without breaking the per-page price the buyer signed. A platform that is a wrapper around a single API cannot. The compute-moat piece covers the cost mechanics; the cap-table conversation is what makes them load-bearing.

Evidence outlasts the provider. The most underrated reason to invest in a signed audit trail and a per-tenant evidence envelope is that they survive a provider change. The buyer who is asked, four years from now, why a credit decision was made will not be served by "the model decided"; they will be served by the trace, the premises, the verifier output and the prompt version — all of which are portable across providers if the platform built them as first-class artefacts. We covered the shape of that envelope in the AI governance and audit-evidence piece; the provider-risk angle is why the envelope is not optional.

What a 90-day plan looks like for the buyer

The work is not a year-long programme; the bones of it fit in a quarter. The team that runs it is small — risk, procurement, platform, one operating-model owner — and the deliverables are documents, not code. We sketched the operating-model frame in the AI operating model piece; the provider-risk overlay is the slice of it that goes from a working programme to a board-grade one.

Days 1–30: the register. Stand up the provider risk register with the eight rows above. Fill every cell with a source link, not a paraphrase. Identify the rows where the buyer does not have an answer; those are the work items. Map every active AI workload to a single provider on a one-page diagram and compute the concentration ratio.

Days 31–60: the contracts. Pull every active AI provider contract above the 250k ARR threshold and check it against the four clauses — exit on change of control, portability, price-pass-through ceiling, sub-processor disclosure. Rank the gaps. Open the amendments on the contracts with the biggest gaps and the largest exposure. Brief the audit committee at month two with the register, the concentration ratio and the amendment list.

Days 61–90: the dry-run. Pick the workload with the highest concentration risk and run a provider-failover dry-run on a non-production slice. Use the eval harness; measure the regression; record the transition time. Write the dry-run report. The report is the artefact the board asks for in the next quarterly risk review. The dry-run is the test that the contract clauses, the architecture and the register all hold together in the only place that matters — the day a provider event forces the move.

Closing thought

The AI provider has graduated. The lab that read like a research collective in 2023 reads like a public-markets candidate in 2026, with a board, a roadmap accountable to public shareholders, antitrust exposure and a price list responsive to quarterly margin. None of that is bad news. The bad news is for the buyer who did not update the diligence frame, the contract template and the architectural posture to match. Provider risk did not appear in 2026; it just got large enough to land on the cap-table side of the buyer's house. The teams that move it from there to a hedged exposure inside the next two quarters are the teams that get to keep treating the model as a feature.

At Cogneris we build document AI with a model-agnostic routing layer, a per-tenant evaluation harness and a signed evidence envelope shipped by default — because the provider underneath us is a counterparty we expect to change, and the buyer above us is one we expect to keep. If you are sizing the provider-risk side of your document AI programme, see our product page, the trust pillar, or talk to our team. The model is the part of the system the press writes about; the provider is the part that has to survive a board review.