Ask a room of bank architects which foundation models power their AI, and the honest answer is usually two or three, from the same short list of providers everyone else uses. That is a systemic concentration nobody chose and everybody has. Your institution's AI capability, and increasingly its operations, now depend on a handful of external companies you do not control, cannot fully inspect, and could not quickly replace. Resilience governance exists for exactly this situation, and AI has made it urgent.
This article treats AI as the third-party and resilience problem it has become. It covers the concentration risk hiding in your model choices, the resilience controls that DORA and its peers demand, and how to architect for a provider failure you cannot prevent but can survive.
§ 9.1The dependence you did not decide
Foundation-model dependence crept in through convenience. A team needed a capable model, the best ones came from three or four providers, and every team made the same reasonable choice. The result is an institution-wide dependence on external providers, often concentrated in one or two, frequently accessed through a cloud provider that is itself a concentration. You now carry three stacked dependencies: the model provider, the cloud it runs on, and often a single region.
This matters because the failure modes are real and outside your control. A provider can deprecate a model you built on, change its behavior with an update, raise prices, suffer an outage, or restrict access for reasons of its own, including regulatory ones. When that provider is embedded in customer-facing operations, its problem becomes your incident.
Resilience principle
Assume every external model provider will, at some point, fail you: an outage, a deprecation, a behavior change, or an access restriction. Governance is not preventing that. It is ensuring your institution keeps operating when it happens. Design for the failure you cannot prevent rather than hoping for the reliability you cannot guarantee.
§ 9.2Mapping the concentration
You cannot govern a dependence you have not mapped. The first control is an honest inventory of external AI dependencies across three dimensions.
| Dimension | Question | Concentration risk |
|---|---|---|
| Model provider | Which providers, which models, powering what? | Over-reliance on one provider across critical functions |
| Cloud / hosting | Where does inference run? Which region? | Single cloud or region as a shared point of failure |
| Criticality | Which dependencies sit in critical operations? | A provider embedded in a service you must not lose |
The revealing exercise is criticality. List the AI-dependent functions your institution could not run without for a day. For each, name the external providers it depends on. The functions that depend on a single external provider with no fallback are your resilience gaps, and they are usually more numerous than anyone expected. This map is the input to every resilience control that follows.
§ 9.3What DORA and its peers require
The EU's Digital Operational Resilience Act is the most developed articulation of what regulators now expect around third-party technology dependence, and its logic applies well beyond the EU. Four requirements matter most for AI.
- Register your ICT third parties. Maintain a register of third-party providers supporting critical functions. Foundation-model and AI providers belong in it. If your AI providers are not in your third-party register, your resilience program does not know they exist.
- Assess concentration risk. Explicitly evaluate the risk of over-dependence on any single provider. This is where the concentration map becomes a required assessment, not an optional one.
- Ensure exit and substitutability. Have a plan to exit or substitute a critical provider. For foundation models this is hard and therefore important: can you switch providers, and how long would it take?
- Test resilience. Test your ability to withstand provider disruption, including scenario testing of a critical provider failing. Untested resilience is assumed resilience.
§ 9.4Architecting for substitutability
The hardest DORA requirement for AI is exit and substitution, because switching foundation models is not like switching a commodity vendor. Models differ in behavior, and an application tuned to one may not work with another without rework. Three architectural moves make substitution feasible.
- Abstract the provider. Route model calls through an internal abstraction layer rather than coding directly against one provider's interface. When you must switch, you change the abstraction, not every application. This is the single highest-value resilience investment for AI.
- Qualify a fallback. For each critical AI function, identify and periodically test an alternative provider or model that could carry the load, even at reduced quality. A degraded fallback that works beats a superior primary that is down.
- Degrade gracefully. Design critical functions to operate in a reduced mode without AI when necessary. If the model is unavailable, does the function fail entirely, or fall back to a rules-based or human process? A function that cannot operate without AI is a function with no floor.
Worked example
A bank ran customer-facing servicing through a single foundation-model provider, coded directly against its interface. The provider changed the model's behavior in an update, and overnight the servicing assistant started giving subtly wrong answers. The bank had no abstraction layer, no qualified fallback, and no non-AI degraded mode. Restoring service meant an emergency scramble to adjust prompts against the changed model, with customers affected for two days. The postmortem's three recommendations were exactly the three moves above. Had any one been in place, the incident would have been hours, not days, and had all three been in place, minutes.
§ 9.5Two rulebooks
US enterprise
You do not have DORA, but you have the same expectations through third-party risk management guidance from the OCC, Fed and FDIC, and through operational resilience principles. AI providers belong in your existing third-party risk program with the same rigor as any critical vendor. The gap most institutions have is that AI dependencies entered through engineering convenience and never went through third-party risk assessment at all. Close that gap first: get them in the program.
GCC / MENA
SAMA and the CBUAE run mature outsourcing and third-party risk frameworks, and AI providers fall squarely within them. Data residency compounds the concentration problem: the requirement to keep data in-region can narrow your provider and fallback options, making substitutability harder and the abstraction layer more valuable. Where in-region hosting is required, a qualified in-region fallback is both a resilience control and a residency control at once.
Eight articles of controls and one article of resilience mean nothing if you cannot show they work. The final article closes the loop: how to measure AI governance, assess its maturity, and report it to the board in a way that answers the one question directors actually ask.
AI created an institution-wide dependence on a handful of external providers, often stacked: model provider, cloud, and single region. Treat it as the third-party and resilience problem it is.
Map the concentration across provider, hosting and criticality. The functions depending on a single external provider with no fallback are your resilience gaps.
Assume every provider will eventually fail you. Governance ensures you keep operating, not that failure never happens.
Architect for substitutability: abstract the provider behind an internal layer, qualify a fallback, and design a non-AI degraded mode. The abstraction layer is the highest-value move.
US institutions apply existing third-party risk guidance; GCC institutions apply mature outsourcing frameworks where residency makes a qualified in-region fallback doubly valuable.