Short answer. You keep it running by designing for the outage before it happens: route through an abstraction layer that can switch to a second model provider in seconds, keep that second provider warm with a small share of live traffic, and define a degraded mode that still serves customers when both are down. In 2025 Ableneo shipped 34 AI projects to production and 94% of them called an external model, so provider failover is a design constraint we set on day one, not a patch we add after the first incident.
Large model providers fail more often than most banks assume. In September 2026 three major providers had overlapping outages on the same day, and one insurer reported a six-hour disruption that caused it to miss roughly 1,200 customer interactions. If your compliance screening, customer advisory, or document processing sits on a single external API, that provider’s bad hour becomes your bad hour, and the regulator counts it against you, not the vendor.
The practical fix has three moving parts, and each one is testable before an incident:
Across our 2025 portfolio, roughly 4 of 5 projects reached production, and the ones that stay in production are the ones where this resilience layer was built in, not bolted on after go-live.
For a bank or insurer in the EU, model-provider resilience is not an engineering preference. It is a regulatory obligation with two owners. The Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied to EU financial entities since 17 January 2025. It requires firms to register every ICT third-party provider that supports a critical or important function, assess concentration risk, hold an exit strategy, and maintain business continuity plans that are tested, not just written. An external model provider that powers credit screening or claims triage sits squarely inside that regime.
The EU AI Act adds a second layer for high-risk systems, which cover most credit scoring and insurance pricing use cases. Article 15 requires high-risk AI to reach an appropriate level of accuracy and robustness and to perform consistently across its lifecycle, and it names technical redundancy, backup, and fail-safe plans as accepted ways to get there. Read together, DORA and Article 15 turn “what happens when the provider goes down” from an optional resilience story into a documented control an auditor will ask to see.
Design provider failover before the first outage: an abstraction layer, a warm secondary provider, and a defined degraded mode.
DORA treats an external model API the same way it treats any ICT third party supporting a critical function. The bank must record the contract in its register of information, classify the function’s criticality, hold exit and step-out clauses, and run a business impact analysis that models what a provider outage does to the service. Where that function cannot justify full redundancy, the firm needs fallback procedures that keep the business running while the primary is restored. The accountability does not transfer to the vendor. The financial entity remains responsible for continuity, so the design of the fallback is the bank’s obligation to prove.
Full duplication is rarely necessary. The cost-controlled pattern keeps one primary provider carrying the traffic and one secondary kept warm with a 2 to 5% live share, so the backup is proven without paying twice for capacity. Requests carry hard cost caps with automatic circuit-breakers, so a runaway retry loop during an incident self-terminates instead of generating a surprise bill. For the most sensitive functions, a small self-hosted model runs the degraded mode, which removes the external dependency entirely for the fallback path. The result is continuity at a marginal cost of single-digit percent, not 100%.
The first hour is a runbook problem, not a coding problem. Detection should be automatic: a health check on each provider trips failover before a human notices. The on-call engineer confirms the switch held, checks that the degraded mode is serving correctly, and logs the event start time for the DORA incident record. If the disruption meets the major-incident threshold, the reporting clock starts, so the timestamp matters. Customer-facing teams get a pre-written status line. None of this should be invented live, which is why the runbook is written and rehearsed during onboarding, not during the incident.
Classic disaster recovery assumes your own data center or cloud region fails and you fail over to another copy you control. Model-provider resilience is different in three ways. The failing component is a third party you do not operate, so you cannot fix it, only route around it. The providers share failure modes, because a September 2026 event showed several going down at once, so a second external provider is not full insurance. And the outputs are probabilistic, so a fallback model can be available yet behave differently, which means you validate the degraded path for quality, not only for uptime.
Resilience is where an AI system earns the right to stay in production. Ableneo has shipped AI into regulated environments across financial services and insurance in Central Europe, and in 2025 that meant 34 production projects across 4 countries, 94% of them built on large language models. That production track record is the reason we design provider failover, degraded modes, and DORA-ready evidence into the architecture from the first sprint, so the system survives an outage and the bank can show the auditor exactly how. You can see how this fits our approach to production-grade AI in the Ableneo AI Transformation FAQ.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.