The Bank's AI Recovery Drill Is a Learning Assessment

Resilience Scrutiny Is Moving Beyond Policy

On October 13, Reuters reported that US and European supervisors were increasing their questions about AI oversight and financial-system stability, while still gathering information rather than prescribing a new set of bank-specific AI rules. Banks should treat that distinction seriously. A supervisory question is not itself a new obligation, but it exposes whether the firm can explain its controls and show that they work.

The established baseline is already demanding. The ECB’s supervisory priorities for 2026-28 put incident response, ICT third-party risk and operational resilience at the centre of DORA implementation, while signalling deeper engagement on banks’ AI use. In the UK, the Bank of England, FCA and HM Treasury have also said firms need effective detection, containment, response and recovery capabilities for frontier-AI-driven cyber risks, while clarifying that their May 2026 statement does not create new expectations.

A Quiz Cannot Test a Handoff

Most banking compliance microlearning can confirm that an employee recognises a policy term, a reporting line or a risk category. It cannot show whether an operations analyst raises the right alarm, whether the incident lead brings in the accountable AI owner, or whether risk and IT agree when to suspend an automated decision. Those are handoffs under pressure. They are where a contained defect can become customer harm, service disruption or delayed recovery.

This distinction matters because the DORA technical standards require continuity tests to use severe but plausible disruption scenarios and to verify the ability of staff, systems and third-party services to respond. Technical recovery exercises prove that infrastructure can fail over or restore. Bank AI incident training should test the parallel human system: detection, decision rights, evidence, escalation and use of an approved fallback.

A Hypothetical Agent Failure

Consider a fictional scenario. An AI agent helps route payment exceptions for manual review. After an approved model update, it begins assigning cases using stale account-status data. Queue volumes fall, which initially looks like an efficiency gain. Then an operations analyst sees unusual reversals and customer complaints. The scenario is hypothetical, but the decisions should mirror the bank’s approved procedures.

• Operations decides whether the evidence meets the incident trigger and preserves the affected cases.
• The incident lead identifies the accountable AI, service and business owners and starts the agreed escalation path.
• Risk assesses customer, conduct and regulatory impact without attempting to run the technical recovery.
• IT and security specialists determine technical containment and recovery actions under the incident-response plan.
• The business owner authorises the documented fallback, such as pausing the agent and restoring a controlled manual queue.

An agentic AI scenario assessment should not ask learners to diagnose model architecture. It should ask what they are authorised to do with the information available at that moment. Branching choices can expose false confidence: an employee may know the policy yet select an unauthorised workaround, escalate too late or approve a fallback without the required owner.

Score the Decision Rather Than the Click

A useful assessment needs a short rubric that maps to the runbook. Score each role against observable decisions, not completion or recall alone:

1. Signal recognition: identifies the abnormal pattern and its possible service impact.
2. Escalation quality: contacts the right owner through the defined route with sufficient facts.
3. Decision verification: separates an AI output from an approved operational decision and retains relevant evidence.
4. Fallback discipline: selects the authorised continuity measure instead of inventing a local workaround.
5. Cross-team coordination: sequences actions so that containment, customer protection and recovery do not conflict.

The output should be a remediation view, not a technical assurance claim. App-Learning can aggregate gaps by role, business unit and decision point, then assign targeted practice where escalation or fallback choices repeatedly fail. It does not replace recovery tooling, cyber incident-response teams, model validation or legal advice on a bank’s specific duties.

The Runbook Must Drive the Learning System

AI operational resilience learning becomes stale when it is built as a one-off course. Every scenario should have a named business owner, a source runbook, a version date and a review trigger. Update it after a material policy change, a production incident, a new third party, a revised recovery objective or a meaningful change to the AI-enabled workflow. The content team should change the scenario only after the control owners approve the underlying procedure.

This creates a practical control loop. The runbook defines the approved response. The scenario tests whether people can execute its handoffs. Assessment data identifies the weak points. Control owners then improve the procedure, the learning flow or both. The useful proof is not that staff completed a course. It is that the bank can move from an unreliable AI-enabled decision to a controlled fallback without losing ownership, evidence or time.