At a glance
- The risk: A shared AI provider can become a concentrated dependency across important business services, while recovery plans remain focused only on the technology.
- The governance implication: Approve the dependency together with operating limits, fallback decisions, and clear authority to restrict or stop the affected workflow.
- The leadership takeaway: Ask who decides how the business serves customers when the AI service is unavailable, compromised, or no longer trustworthy.
When a financial institution places an AI service inside a consequential workflow, it is making more than a technology choice. It is deciding how much of that service can depend on a provider the institution does not control.
The critical question is not simply whether the provider can recover. It is whether the business knows what to do while confidence in the service is reduced—and who has authority to make that call.
A Resilient Provider Does Not Guarantee a Resilient Business
Vendor assessments usually examine availability, security controls, incident response, and contractual commitments. Those controls matter, but they do not define how an internal business service should operate during disruption.
An AI capability may support customer communication, fraud review, claims handling, or internal decisions. If it becomes unavailable, produces unreliable results, or must be isolated during an incident, the business still has to decide whether to continue manually, narrow the service, delay decisions, or stop the workflow.
That operating decision belongs to the institution, not the provider.
What Financial Authorities Have Signalled
On 31 August 2026, the Financial Stability Board said the potential effect of frontier AI on cyber risk was its most immediate concern. Its Chair called for financial firms to maintain robust response and recovery capabilities and for resilience among critical third-party and other common service providers.
A joint statement from the European Supervisory Authorities, published on 31 July 2026, described risks including rapid exploitation of vulnerabilities, attacks on shared infrastructure, and the use of single points of failure across entities. It encouraged prevention, detection, and management measures within ICT risk-management processes.
These publications are supervisory and policy signals, not evidence that a particular provider will fail. The FSB release is not a binding rule, and the European statement must be understood within its jurisdiction and existing supervisory expectations.
The Exposure Sits Between Technology and the Business Service
A common provider can create concentration at several levels: the model, cloud platform, identity service, integration layer, or data pipeline. An institution may understand each contract separately while missing how several business processes depend on the same underlying component.
Ordinary continuity planning can also assume that a technical service is either available or unavailable. AI introduces another condition: the service may be running while its output is not sufficiently trustworthy for the decision at hand.
Recovery therefore needs two tests. Has the technology returned? And has the business established enough confidence to rely on it again?
An Illustrative Insurance Scenario
Consider a fictional insurer using one external AI service to summarize claim documents, assist contact-centre staff, and flag potentially inconsistent submissions. The provider experiences a security incident and temporarily restricts several functions.
The claims team can revert to manual summaries, but queues will grow. The contact centre can operate without generated suggestions, but service times will increase. The fraud team may no longer receive alerts it had begun to rely on.
The provider owns restoration of its service. The insurer still owns the decisions about customer treatment, backlog priorities, manual checks, and when each use may resume. A technical recovery notice cannot make those decisions for the business.
This scenario is illustrative; it is not a client case or a claim about a specific institution.
Govern the Dependency Before It Becomes Critical
Before approving a material AI dependency, the business service owner should define the minimum acceptable service, the fallback method, and the conditions that require restriction or suspension. Technology, cyber risk, procurement, and the provider contribute evidence. They do not replace accountable business ownership.
The same decision should define who can declare that AI output is no longer trustworthy, who can authorize degraded operation, and what evidence is required before normal reliance resumes.
This is my reasoned interpretation of the official signals: resilience should be governed at the level of the business decision, not only at the level of the supplier contract or technical component.
Questions for the Leadership Team
- Which customer or operational decisions now depend on the same AI provider or shared technical component?
- Who can restrict or stop each workflow when the service is available but its output cannot yet be trusted?
- What evidence—not simply a provider status update—is required before the business resumes normal reliance?
Closing Thought
Third-party resilience matters. But an institution cannot outsource the judgment required to protect its customers and operations during disruption.
If leadership cannot explain how a critical workflow will degrade, who owns that decision, and who can stop it, the dependency has been adopted faster than it has been governed.
Sources and Further Reading
- Financial Stability Board: FSB Chair warns of risks arising from frontier AI models — 31 August 2026.
- European Supervisory Authorities: Statement on frontier AI models — 31 July 2026.
- Beyond1n0: Your AI Vendor Has Documentation. Do You Have a Defensible Decision?
- Beyond1n0: Before an AI Agent Acts for Your Business, Decide What You Have Authorized
About Gary Cheung: Gary writes about decision accountability, design-phase governance, and executive judgment in AI and information risk. Contact Gary.
