DORA and AI in Finance: Operational Resilience for Production AI Systems

The uncomfortable truth for many firms is that their AI systems were never built to this standard. They were built to demonstrate a capability, and resilience was assumed to be someone else’s problem, usually the vendor’s. DORA removes that assumption.

The constraint that owns the workflow

DORA sets expectations that apply to the ICT systems supporting a firm’s critical functions, and a production AI system in the decision path is squarely among them. The firm must manage ICT risk across the lifecycle of these systems, which means identifying how an AI system could fail and controlling for it before it does. It must detect, classify, respond to, and report significant ICT-related incidents within defined expectations, so an AI failure is not something the firm discovers through customer complaints and handles ad hoc. It must test its operational resilience, including scenario and disruption testing, rather than assuming systems will hold. And it must manage the risk of its ICT third parties, the cloud platforms, model providers, and API services an AI system almost always depends on, because a critical dependency the firm cannot see into or exit from is a resilience exposure the firm owns regardless of who operates it.

The failure modes DORA is built to catch map directly onto how AI systems actually break. An AI service that goes down or degrades and takes a customer-facing or decision-critical function down with it. A concentration on a single third-party provider whose outage the firm has no way to absorb. And the incident the firm cannot detect, classify, or report because the AI system was never instrumented to reveal its own failures, so a silent degradation operates unreported past the point where reporting was required.

The position: an AI system’s resilience is a property of the whole system, not the model

Here is the stance I would hold against the model-centric habit that dominates AI programs. Resilience under DORA is not a property of the model. It is a property of the entire system the model sits inside, and most AI resilience failures have nothing to do with the model’s accuracy at all. They come from the dependencies the model relies on, the fallbacks that were never built, and the monitoring that was never wired in. A perfectly accurate model behind a single third-party API with no fallback and no incident detection is a resilience failure waiting to happen, and its accuracy will not save it when the API goes dark.

The reasoning is about where AI systems actually fail in production. They fail when the model-hosting provider has an outage and there is no secondary path. They fail when latency spikes under load and the system has no graceful degradation, so it either hangs or returns nothing. They fail when a dependency changes behavior and the system, uninstrumented, keeps operating on a quiet malfunction no one notices. None of these is a modeling problem, and none is solved by a better model. They are solved by engineering the system, dependencies, fallbacks, degradation paths, and monitoring, to the resilience standard DORA now requires. Treating AI resilience as a model concern rather than a systems concern is exactly the mistake that leaves a firm unable to answer for its AI when DORA asks.

Engineering inside the constraint

The architecture has to make availability, recoverability, and observability first-class properties. Third-party dependency risk is managed explicitly: the firm maps which external providers each AI system depends on, assesses the concentration risk of relying on any single one, and engineers fallbacks so the failure of a provider degrades the service gracefully rather than taking a critical function down. Where an AI system supports a critical function, the firm needs a defined path for what happens when the AI is unavailable, whether that is a fallback to a simpler model, a rules-based path, or a controlled handoff to human operators, because a critical function that has no answer when its AI goes dark is a resilience gap by DORA’s definition.

Incident detection has to be built into the system rather than bolted on after. The AI system is instrumented to surface its own degradation, latency, error rates, output-quality drift, and dependency health, so a failure is detected as an event the firm can classify and, where significant, report within DORA’s expectations, rather than discovered late through downstream effects. This is the difference between an incident the firm manages and an incident that manages the firm. Resilience testing is deliberate: the firm operates scenario and disruption tests against its AI systems, simulating provider outages, latency spikes, and dependency failures, to prove the fallbacks work before a real disruption tests them for it.

All of this depends on continuous monitoring against defined thresholds and a reconstructable operational record that captures what the system did, how it performed, and when it degraded, so the firm can classify and report incidents and demonstrate its resilience posture to a supervisor. Governance and evaluation stay in the picture, because a resilient system that produces wrong outputs reliably is not a success: the AI has to be evaluated against an explicit standard for both performance and behavior under stress, repeatably, which is the work a rubric-based evaluation engine like PRISM is built to carry. Human oversight and defined escalation paths, placed by consequence, ensure that when an AI system supporting a critical function degrades, a person is positioned to take over the decisions that cannot wait for a fix.

Where it almost broke

A firm operated a customer-facing AI service that supported a function customers relied on daily, and it operated well, accurate and responsive, for a long stretch. The service depended on a single external model provider, and the firm had never built a fallback, because the provider had always been available and resilience had never been the team’s remit. Then the provider had a regional outage. The AI service had no secondary path and no graceful degradation, so the customer-facing function simply stopped, and because the system had not been instrumented to surface its own dependency health, the firm learned about the failure from customers rather than from its own monitoring. The incident operated for a stretch before it was detected, classified, and handled, and the delay itself became part of the problem under resilience expectations.

The model had performed flawlessly right up to the moment its dependency vanished, and the model was never the issue. The fix was systems engineering, not modeling: a defined fallback path so a provider outage degraded the service to a reduced capability rather than a dead one, dependency-health instrumentation so the firm detected the failure itself and immediately, and disruption testing so the fallback was proven before the next outage rather than during it. An AI system is only as resilient as its weakest dependency and its ability to see its own failure, and accuracy buys nothing when the service behind it is unreachable.

DORA and AI in finance settles a question many firms had left open: production AI systems that sit in the path of real operations are critical technology, and they have to be engineered to the same operational-resilience standard as anything else the business depends on. That standard lives in the system, not the model, in the dependencies mapped and hedged, the fallbacks built and tested, the incidents made detectable and reportable, and the human paths ready when the AI cannot carry the load alone. A firm that treats its AI as an accurate experiment adjacent to the core will find, when DORA asks, that it cannot account for the resilience of systems its customers now depend on.

If you are operating AI in production under DORA, the question that matters is not how accurate your models are. It is what happens to the function they support when a provider goes down, whether you would detect that failure yourself and in time to report it, and whether you have proven your fallbacks before you need them. An AI system that is accurate but not resilient is not an outcome that survives scrutiny.