The Disappearing Model

08:17 on a Monday morning. A company’s customer-complaint workflow stops completing cases. The provider is still trading. The API credentials still work. But the model on which the workflow relies has been withdrawn, changed, restricted or made unavailable.

An engineer switches providerA.model to providerB.model. The request is accepted within an hour. Three weeks later, the business capability is finally restored. The replacement formats some responses differently, selects the wrong tool in edge cases, refuses cases that used to complete, performs poorly on internal documents and takes too long on longer cases.

The integration was quick to change. The service was not.

This is not a story about a provider going bankrupt. It is an operational-resilience question: if your primary AI model disappeared tomorrow, how long would it take to restore the business capability?

A model can disappear while its provider remains

“Disappearing” does not have to mean a permanent shutdown. A model can be superseded, retired, repriced, shifted to another tier, restricted in a region, rate-limited, altered through an update or made unsuitable by changed safety behaviour. An outage, contract change or lost feature can make an otherwise live endpoint the wrong component for a production service.

Those are normal conditions of a fast-moving platform market. They do not imply bad faith by providers. A named model and the business process built around it simply have different lifecycles.

That distinction also applies to products bought from someone else. A SaaS supplier may change its underlying model, route to another provider during an incident or use an orchestration layer that its customer cannot see. This is one extension of Third-Party Shadow AI: a supplier’s resilience choice can become your service and data-risk decision.

The question is not merely, “What if our provider vanishes?” It is: what if the particular capability our application relies upon changes?

The recovery clock starts before the code changes

Model Recovery Time is a proposed operational measure: if the primary model became unusable at 09:00 tomorrow, when could the organisation provide the underlying service again?

It is not API recovery time. It includes the model, prompts, tools, evaluation, controls, approvals and any human fallback required to put the service back into safe use. A low-risk drafting assistant may be able to pause. A workflow that directs complaints, supports regulated activity or makes customer commitments may need an explicit recovery objective and a reduced-function mode.

If the primary model becomes unusable at 09:00 tomorrow, when is the business capability restored?

1. MinutesA tested hot fallback can route traffic to a validated model automatically.
2. HoursAn alternative is integrated; configuration and targeted evaluation remain.
3. DaysAn alternative is known but not continuously tested; prompts and tools need adjustment.
4. WeeksThe application is materially tuned to one model; regression testing and workflow redesign are required.
5. UnknownNo alternative has been tested, so recovery time is an assumption rather than an objective.

A Beyond the Model conceptual resilience framework, not an industry standard.

The uncomfortable category is unknown. An organisation that has never tested an alternative cannot claim that a provider swap will take a day or a week. It has an assumption, not a recovery objective.

API compatibility is not behavioural compatibility

At first sight, a model integration can look portable. A model name is a string and another provider may accept a similar request. Yet the model is doing more than receiving an endpoint call.

Production systems may learn to rely on a model’s interpretation of instructions, its structured-output reliability, its tool choices, context handling, refusal behaviour, latency and many difficult edge cases. Some dependencies are written down. Many only appear when a product, its users and its surrounding systems have been in use for a while.

API compatibility is not behavioural compatibility.

An alternative can be technically connected without preserving the agreed service level, safety boundary or user experience. The service may need a different prompt, a different tool policy, a new latency budget, a fresh set of test results or a human decision before it can return to production.

The capability behind the capability

There is a second dependency to consider: the organisation’s own ability to operate without the model. If people can still perform, check and recover the work, a model incident is primarily a technology incident. If that knowledge, process and capacity have been removed because automation was cheaper, the same incident becomes a business-continuity problem.

This is where model dependency meets AI capability debt. Automating work can create value today while quietly reducing the human evidence, oversight and practical skill available to restore the work tomorrow. The right answer is not to avoid AI. It is to decide deliberately what recovery capacity the business needs and preserve it proportionately.

Start with the question that exposes the gap

Map the service, its owner, the model or supplier behind it, the data that may travel during a fallback and the point at which the organisation must stop rather than produce an unvalidated answer. Then ask how long it would take to restore the underlying business outcome, not merely an HTTP response.

That answer creates the next question. If the endpoint can be replaced within an hour, why can the capability take three weeks to recover?

The next article examines the hidden behavioural contract that makes one model difficult to substitute for another.