Trace the shared dependency behind every AI fallback

Consider a constructed continuity test with two model suppliers. The primary endpoint can be replaced, but both routes rely on the same identity service and retrieval gateway. Removing that shared dependency stops the business task on both paths. Two model contracts have not created two independent ways to complete the work.

Identify which dependencies can stop both routes and demonstrate the work that remains possible. The example is illustrative, not a report about a supplier. Assess resilience from request to completed business outcome, with model-provider choice as one part of that path.

The earlier article on capital-cycle risk asks whether a system can survive a change in inference price. The article on model retirement asks how to replace a version on a supplier’s schedule. This decision concerns a different failure: two apparently available choices can stop together during an operational disruption. A portable prompt and a model evaluation set help with migration, but they do not show that the rest of the service can continue.

Count failure domains, not contracts

The Bank of England’s analysis of AI in the financial system warns that reliance on a small number of AI service providers can create systemic operational risk, especially when rapid migration is not feasible. It describes a scenario in which an outage of vendor-provided models interrupts vital customer-facing services. That is an assessment of possible financial system effects, not evidence that any named enterprise’s fallback will fail.

Map a representative task from request through identity, permitted evidence, model access and final handoff. Record the owner and location of each dependency, then map the alternate route. Components shared by both remain relevant failure domains even when the model names differ.

Ask suppliers about the layers the contract does not display. Two products may run on different infrastructure, or may rely on a common cloud, identity or data provider. The buyer should seek evidence rather than infer independence from branding. Where a supplier will not disclose an upstream dependency, record the uncertainty and test the outage scenarios that can be simulated at the buyer’s boundary. A contract for an alternate endpoint is useful only when the route to it can be invoked under the disruption it is meant to cover.

The July 2026 announcement of UK oversight for designated critical third parties states that the regime complements existing duties for regulated firms to manage their own third-party arrangements and contingency plans. Oversight of a supplier therefore does not answer whether a particular customer’s manual or alternate route works. Applicability and legal interpretation belong with the firm’s counsel. The practical question for any buyer is still what happens to its service when a shared dependency is absent.

Rehearse the minimum service

Start with the outcome the organisation must preserve. It might be the ability to receive and triage a customer request, send a time-sensitive notice or complete a review with human judgement. An AI feature can be unavailable while the business service continues. Conversely, a healthy model endpoint is not useful if the request, permitted evidence or final handoff cannot reach it.

Agree the minimum service and who may invoke it. Options include an independently supported model path, restricted functionality, a staffed manual queue or a pause on non-essential work. State the effects on quality, throughput and communication. Test how work reaches the alternative and returns to the normal record.

The Bank’s operational resilience guidance asks the firms it regulates to identify important business services, set impact tolerances, map their dependencies and test whether the services can continue through severe but plausible disruption. Those are sector-specific expectations, not a rule imposed on every AI buyer. The method is still a useful way to avoid mistaking a spare supplier for a tested service outcome.

illustrative fixture

Choose the service the fallback can preserve

Swipe or scroll for the full diagram →

Can the minimum service complete work during the tested disruption?

Owner: Business service owner. Threshold: Agreed quality, elapsed time, access boundary and staff capacity.

Expand

Accept the demonstrated route when it meets the service tolerance.

Retain narrower scope

Restrict the service or retain a supported manual route when a guardrail fails.

Gather more evidence

Test the missing dependency or capacity condition before relying on the fallback.

illustrative fixture

Define the minimum service

Baseline

Completed cases, elapsed time, review effort and customer communication under the normal route.

Outcome

Cases completed to an acceptable standard while a model provider and then a shared upstream dependency are unavailable.

Guardrails

Permission boundaries, unreviewed effects, stranded queue items and staff capacity during the degraded mode.

Decision rule

Accept the fallback only if the minimum service stays within the organisation's stated tolerance in both disruptions.

Decision owner

Business service owner

Population

The named model outage and shared-dependency outage.

Test the routes separately. First remove the primary model endpoint and observe whether the second route completes work. Then remove one shared dependency that the map exposed, such as the gateway or retrieval source, and observe whether the minimum service survives. Reconcile the queue afterwards so a recovered system does not repeat an action a human completed during the outage. A rehearsal that only returns a successful model response stops before the decision that matters.

Use the findings to prioritise spending. A further model endpoint may offer little protection against a shared gateway failure, while a manual route may need more staffing or a better handoff. Where an alternate route meets the service tolerance, retain evidence of the test and schedule reassessment of material changes.

What the map cannot prove

An internal drill cannot establish every supplier’s hidden infrastructure or predict a sector-wide event. Supplier disclosures may be incomplete, and simulated load may differ from demand during a real incident. Record those limits beside the test result. The evidence supports a decision about the specified scenarios and current configuration, which must be revisited when a provider or internal architecture changes.

The service owner should accept the demonstrated minimum work, the tested disruption and the remaining dependencies together. Name the next action for each material gap. Keep supplier choice within that service decision rather than treating provider count as the resilience result.