When the Vendor Disappears: Model Continuity After an AI Provider Fails

Most post-bubble reckonings arrive slowly. A quarterly review notices the run rate. An audit committee asks for the business case. A restructuring advisor requests the invoice trail. Vendor failure is different. It arrives on a specific date, usually with short notice, and it converts an abstract governance concern into an operational outage with a countdown attached.

As consolidation and shutdowns work through the AI vendor market, this is the trigger most boards will feel first. It is also the trigger that exposes the underlying problem in its clearest form. The enterprise did not lose a supplier. It lost the only running instance of a system whose behavior it never documented.

Why this is a capital question, not an IT question

An outage is scoped by uptime. A vendor failure is scoped by the balance sheet. Prepaid annual commitments, capitalized implementation cost, integration labor, retraining, and the downstream processes that silently depend on the vendor's output are all in scope at once. None of them are usually recorded against a single line item, which is why the first hours of a vendor failure are spent discovering the exposure rather than managing it. That discovery problem is the same one described in shadow AI spend — only now it has a deadline.

The seven-step continuity triage

The sequence below is ordered deliberately. Preservation comes before analysis, because evidence expires. Classification comes before disposition, because a decision taken against an incomplete asset inventory cannot be defended later.

1. 01Locate every dependency on the distressed vendor — direct API integrations, embedded features inside other vendors' products, departmental subscriptions, and human workflows that consume the output without knowing its source.
2. 02Preserve prompts, logs, configurations, data rights and model outputs — everything that documents how the system behaved, captured while credentials still work.
3. 03Determine which business processes will fail and when — mapped to concrete dates, not to a general risk rating.
4. 04Separate transferable enterprise assets from inaccessible vendor property — what leaves with you, and what was never yours.
5. 05Measure prepaid spend, implementation cost and stranded commitments — the recoverable claim and the sunk position, stated separately.
6. 06Decide whether to retain, replace, restructure, acquire or impair — with the evidence base attached to the decision.
7. 07Revalidate the replacement system against the behavior previously approved — not against the vendor's benchmark, but against what your own approval documentation said the system would do.

What is actually transferable

The distinction that governs everything downstream is between the enterprise's own artifacts and the vendor's property. It is a line most contracts draw quietly and few buyers read closely before they need it.

• Transferable, usually: source data, prompt and instruction libraries, retrieval corpora, evaluation sets, output archives, integration code you wrote, and the documented business logic around the model.
• Not transferable, usually: model weights, fine-tuned adapters trained on the vendor's base model, the inference stack, safety and guardrail layers, undocumented post-processing, and the version history that explains why outputs changed.
• Contested, frequently: derived embeddings, vendor-hosted indices, and fine-tuning artifacts where the contract is silent on ownership of the trained result.

The third category is where most of the value and most of the litigation sits. It is also where the enterprise's negotiating position degrades fastest, because a distressed vendor's estate has every incentive to treat ambiguous assets as its own.

Sizing the stranded position

Once the asset line is drawn, the financial exposure becomes calculable rather than speculative. Three figures matter, and they should never be blended: the prepaid balance that constitutes a claim against the estate, the implementation and integration cost that is stranded regardless of outcome, and the forward cost of replacement including revalidation. Boards routinely see only the first, which is the smallest of the three.

Replacement is not a procurement exercise

The final step is the one most often skipped. A replacement vendor will demonstrate that its system performs well. That is not the question. The question is whether it reproduces the behavior that was approved, tested, and relied upon by the processes now running on it. Without preserved outputs and evaluation sets, that comparison cannot be made, and the enterprise silently accepts a different system under the old approval. This is the provenance failure described in when the model changes, executed at portfolio scale in a single migration.

Vendor failure and model continuity as a practice area

AI Capital Recovery treats vendor failure and model continuity as an explicit practice area for a straightforward reason: the trigger is urgent and specific, but the work it requires is the same forensic reconstruction the rest of the portfolio needs. An enterprise that runs the seven-step triage against one distressed vendor has, by the end of it, built the evidence apparatus it lacked across every other AI commitment it holds.

The immediate pain opens the door. The reconstruction reveals the larger problem. Once the disposition question is on the table for one vendor, the retain, restructure, impair or terminate framework applies to the rest of the book — and the ROI gap stops being an industry statistic and becomes a set of specific, named positions with evidence attached.

“The enterprise did not lose a supplier. It lost the only running instance of a system whose behavior it never documented.”