Blog · arXiv Analysis · Published: July 10, 2026 · Modified: July 10, 2026 · Last reviewed: July 10, 2026

The AI Dependency Becomes the Resilience Perimeter

Jonathan Shelby's July 2026 arXiv paper argues that regulated firms should treat AI systems as operational dependencies, not only as model-risk objects.

For this essay, a resilience perimeter is the record that connects an AI component to the business service that depends on it, the disruption it can cause, and the fallback that would keep the service alive.

The Paper

The paper is The AI Resilience Gap: Bringing Artificial Intelligence Inside the Operational Resilience Perimeter, arXiv:2607.07359 [cs.CR]. The arXiv record lists Jonathan Shelby as the author and records submission on July 8, 2026. The downloaded PDF is 11 pages and lists the Department of Computer Science, University of Oxford, and Hertford College, Oxford, United Kingdom.

The argument is clean: the trustworthy-AI stack asks whether an AI system is safe, fair, transparent, governed, and fit to use. Operational resilience asks a different question: whether an important business service can continue or recover when a dependency fails. A model can pass the first test and still be a single point of failure for the second.

Two Logics

Shelby separates two regulatory logics. The first is model-centered: AI Acts, model-risk practices, management standards, and risk frameworks usually look at the system, its documentation, its harms, and its controls. The second is service-centered: operational-resilience regimes look at important business services, impact tolerances, severe-but-plausible disruption, third-party dependencies, and continuity.

The UK sources make that service-centered logic concrete. The Bank of England's April 2025 Financial Stability in Focus report treats AI as relevant to the resilience of the UK financial system and says the Financial Policy Committee is building a forward-looking monitoring approach for AI-related risks. Supervisory Statement 6/24, issued jointly by the PRA, FCA, and Bank of England, says the Critical Third Parties regime is aimed at risks to stability or confidence in the UK financial system from failure or disruption of services supplied to regulated firms and financial market infrastructures.

The Service Lens

The paper's useful move is to force every AI dependency through the service lens. The question is not only whether the model is accurate or explainable. It is which business service uses it, how critical the model is to that service, whether the service has an impact tolerance, and whether the service can remain inside that tolerance without the model.

This reframes ordinary AI inventory work. A register that lists models, vendors, datasets, and risk owners is not enough if it never maps the model to customer service, payments, transaction monitoring, credit decisioning, or other important services. The dependency is then governed in one register and absent from the register that decides whether the firm survives disruption.

Silent Failure

AI also complicates what failure means. A conventional resilience program can see a system outage: the service is down, latency is unacceptable, or recovery takes too long. A model can fail while still answering on time. It can drift after a provider update, behave differently under a new input distribution, or return confident but degraded outputs in the expected format.

The paper calls this silent degradation. For AI-dependent services, impact tolerances cannot be only duration-of-outage thresholds. They need correctness thresholds, drift monitoring, challenge sets, and trigger points that say when the model is treated as failed even though the endpoint is still alive.

Concentration

The concentration problem is the institutional version of the same failure. A firm may reasonably choose a strong frontier-model provider for customer support, internal coding, fraud review, and analyst productivity. Across the sector, many firms may make the same decision. What looked like efficient procurement becomes a common-mode dependency.

The Bank, FCA, and HM Treasury's May 2026 joint statement on frontier AI models and cyber resilience frames frontier AI as a cyber and operational resilience issue for regulated firms. It says firms need protective, detective, threat-containment, and cyber-response capabilities for faster and more disruptive frontier-AI-enabled attacks. Shelby's paper extends the point inward: the AI provider is not only a threat amplifier. It can also be the fragile service dependency.

Fallback Doctrine

The proposed AI Resilience Framework has five parts: map AI dependencies to important business services, classify them with a Criticality-Substitutability Matrix, extend impact tolerances to AI-specific failure modes, define a fallback doctrine, and manage provider-level concentration.

The fallback doctrine is the sharpest test. A fallback is not a sentence in a policy. It is a maintained capability that has been rehearsed. If a customer-service assistant is supposedly backed by a human call center, but staffing has been cut below the level needed to absorb the load, the fallback is fictional. If a transaction-monitoring model replaced a maintained rules engine and no current ruleset remains, the fallback is fictional. Governance should mark those cases as resilience failures, not as acceptable residual risk.

Governance Reading

The Spiralist reading is that AI governance must stop ending at the model boundary. A serious AI dependency receipt should include the business service, service owner, model owner, provider, deployment mode, allowed actions, criticality tier, substitutability tier, impact tolerance, drift metrics, outage metrics, fallback owner, last fallback test, exit plan, and provider-concentration exposure.

This belongs beside frontier AI buffers, deployment safety forecasts, transaction monitoring, infrastructure dependency, AI insurance, and the EU AI Act. The shared lesson is that a system can be governed, certified, documented, and still not be resilient.

Limits

The paper is a framework paper, not empirical proof that the AI Resilience Framework works across firms or jurisdictions. Its worked examples are illustrative. Its regulatory focus is strongly UK financial services, with DORA as the main EU resilience analogue. Applying the same logic to health care, education, public benefits, or labor platforms would require different service definitions, different legal hooks, and different harm thresholds.

The framework also does not solve the sector-wide visibility problem by itself. A single firm can map its own dependencies, but it cannot fully see how many other firms rely on the same provider, model family, cloud region, or evaluation stack. That is why concentration risk remains a regulatory problem, not only a procurement problem.

Source Discipline

Primary sources were arXiv abstract, HTML, PDF, plus the Bank of England, FCA, and joint regulator pages below. This page reproduces no tables or long passages.

The disciplined question for an AI dependency is not "is the model trustworthy?" It is: what service breaks when this dependency degrades, who notices, how fast, and what real fallback keeps the service inside tolerance?

Sources

Return to Blog