Your AI Fallback Is Not a Recovery Plan.

Your recovery playbook fails if the tool meant to execute it disappears with the crisis. Test every AI-assisted action after removing the model, data pipeline, credentials and provider support. A fallback is credible only when people can still start, run and evidence the action.

A recovery action is not credible because the plan says "manual fallback available". It is credible when named people can execute it under the failure conditions that made the fallback necessary.

An AI outage affecting a critical operation ordinarily belongs in the business continuity and operational resilience controls required by current CPS 230 Operational Risk Management, in force from 1 July 2026. This article examines the narrower CPS 190 case: the dependency is needed to execute a financial-viability recovery or exit action, or contributes to viability stress.

Build an AI dependency-to-action test. This is a proposed internal control from TheAICommand, not an APRA-prescribed template. It links each recovery, exit or relevant resolution-support action to the AI dependencies it uses, removes those dependencies during a simulation and requires human owners to prove the action still works.

Which APRA plan are you actually testing?

CPS 190 Recovery and Exit Planning is an enforceable prudential standard. It applied to covered APRA-regulated entities other than RSE licensees from 1 January 2024 and to RSE licensees from 1 January 2025. Its detailed application excludes purchased payment facility providers and generally excludes a foreign ADI unless APRA determines otherwise.

CPS 190 requires a recovery and exit plan showing how the entity could restore financial resilience and, if recovery is ineffective, enable an orderly and solvent exit from regulated activity. The Board must approve the plan, oversee reviews and oversee execution of actions. All covered entities must maintain the capabilities required to execute the plan and take reasonable preparatory steps that consider legal, financial, operational and structural requirements.

The enhanced SFI requirements in CPS 190 matter here. For each action, an SFI must analyse timelines, barriers, execution risks, key dependencies and preparatory measures. It must also conduct operational testing as part of a comprehensive review at least every three years. APRA retains a general power to adjust or exclude specific requirements for an entity. Non-SFIs have different minimum requirements, so do not apply the same action-level and testing rules to them.

CPG 190 Recovery and Exit Planning is non-enforceable guidance. It says realistic simulation can expose execution barriers, while actions tested under narrow or outdated scenarios are less credible. Preparatory measures may include playbooks, approvals and data-system improvements.

Resolution is different. Under CPS 900 Resolution Planning, APRA may determine a bespoke resolution plan setting out steps APRA may take if an entity becomes non-viable. CPS 900 applies to SFIs and non-SFIs that APRA determines provide a critical function, meaning one important to financial-system stability or the availability of essential financial services to a particular industry or community. That term is not interchangeable with a CPS 230 critical operation. Requirements attach after APRA notifies the entity. CPG 900 Resolution Planning, which is guidance rather than an enforceable standard, says that before notification there are no CPS 900 requirements the entity must meet and no requirement to prepare for its implementation.

If notified, the entity supports APRA's resolution planning. CPS 900 can require critical-function and shared-service analysis, assessment of barriers and execution risks, pre-positioning, operational continuity, and capabilities involving data and systems. APRA's resolution plan is not the entity's CPS 190 plan.

What makes an AI dependency fatal to the action?

APRA's 30 April 2026 letter to industry on AI is supervisory guidance and observations, not a new prudential standard. APRA states that its framework is technology and vendor agnostic. Its expectation for credible fallback where AI supports critical operations is broader than CPS 190. Here, the letter is evidence that AI reliance and substitution require examination, not authority for turning every AI outage into recovery and exit planning.

The CPS 190 link exists when the dependency is needed to execute a financial-viability recovery or exit action, or contributes to the viability stress. APRA also reported that, among the large entities it sampled, few had demonstrated robust contingency planning or tested exit and substitution strategies for critical AI providers. CPS 190 and CPS 900 do not need to name foundation models before such a dependency can weaken an action.

Start by separating a helpful tool from an execution dependency. If AI only improves the style of a pre-approved communication, losing it may add time without blocking the action. If it is the only way to produce a portfolio extract, locate counterparty exposures, generate transfer files, calculate an action sequence or retrieve the current playbook, its failure may stop the action.

Map the complete fault domain, not just the model name:

• model endpoint and any upstream model selected by routing;
• cloud region, network path, orchestration service and application interface;
• identity service, service account, secrets store and privileged access;
• source systems, transformation jobs, retrieval index and data export;
• monitoring, logs and evidence needed for human review;
• provider documentation, support staff, contract rights and data portability; and
• internal staff knowledge needed to verify and execute the output.

A second model is not an independent fallback when it uses the same provider account, cloud region, identity service, data pipeline or orchestration layer. A manual procedure is not independent when its instructions live only in the unavailable application. A human reviewer is not a fallback when that person cannot access the source data or reproduce the calculation. Mapping which of your live services share those roots day to day is the vendor-concentration exercise; this test asks the narrower recovery question of whether the plan survives the shared root failing.

Call a dependency fatal only if its failure prevents the action from starting, completing within its approved timeline, producing its required decision evidence or remaining within the authority model. That definition stops the test becoming a generic technology inventory. The question is always whether the recovery or exit action still executes.

How does the dependency-to-action test work?

Create one test record for each [ACTION_ID]. Record the trigger, decision authority, intended outcome, start and completion time assumptions, required artefacts and human action owner. Then link every execution step to its dependencies and an independent path.

Use three failure states. DEGRADED tests slow, incomplete or unreliable output. UNAVAILABLE removes access completely. UNTRUSTED assumes the model or pipeline still responds but its outputs cannot be relied on. The third state is essential because a live service can still be unusable during data corruption, model change or security compromise. Silent served-model swaps are a real operating pattern, which is why logging the served model behind a fallback matters to the evidence trail.

Use this prompt to create the draft dependency map from controlled documents. The recovery-plan owner and each action owner must verify every step, dependency, authority and timing assumption before testing.

Using only [APPROVED_RECOVERY_EXIT_PLAN], [ACTION_PLAYBOOKS] and [AI_DEPENDENCY_REGISTER], map [ACTION_ID]. Do not decide that the action is credible.

For each execution step return:
1. required input, output and human decision
2. model, provider, pipeline, identity, data, cloud and staff dependencies
3. shared fault domains
4. proposed DEGRADED, UNAVAILABLE and UNTRUSTED tests
5. independent execution path and evidence required
6. missing owner, access, skill, contract or data requirement

Mark assumptions NOT TESTED. End with a human test plan and approval fields.

Run the exercise in a controlled environment. Remove the selected dependencies rather than asking participants to imagine their absence. Disable the AI account. Revoke the test credential. Withhold the retrieval index. Make the provider help desk unavailable. Supply new information progressively, as it would emerge in stress.

Require participants to produce the action artefacts, not merely describe them. That might include the source query, verified calculation, approval paper, transfer-data extract, counterparty list, communication pack or execution checklist. Retain timestamps, access logs, decisions, errors and workarounds.

Fictional worked example: [ENTITY_NAME] uses an AI assistant to assemble the due-diligence index for recovery action [ASSET_SALE_ACTION_ID]. The stated fallback is a second model. The test removes provider [AI_PROVIDER_ID] and reveals that both models use its identity service, retrieval index and document store. The authorised action owner cannot obtain the current asset schedule or prove which documents were supplied. Human reviewer [RECOVERY_REVIEWER_ROLE] records the action as BLOCKED, not passed. The team then creates an approved source-system query, independent read-only access, an offline index template and a named manual verification role. A later test must prove those measures work. This fictional example does not show that an asset sale is appropriate or achievable for any real entity.

Use this prompt to challenge the test result. For an SFI's comprehensive review, CPS 190 requires operationally independent, appropriately experienced and competent persons to assess the plan's effectiveness and execution readiness. For other testing, use the entity's approved review authority.

Review [ACTION_TEST_RECORD] against [APPROVED_ACTION_CRITERIA]. Do not infer missing evidence or approve the recovery, exit or resolution action.

Identify any step that reused a removed dependency, shared a fault domain, exceeded its timing assumption, lacked human authority, used stale data or failed to produce the required artefact. Return INDEPENDENT, CONDITIONAL or BLOCKED for each step with evidence references and remediation required. Mark unresolved issues HUMAN DECISION REQUIRED.

For an entity notified under CPS 900, use the result only within the APRA-led process and applicable requirements. CPG 900 highlights shared services, third-party contracts, operational continuity, data and systems as potential resolvability considerations. The same exercise can expose a barrier. The entity does not determine APRA's resolution option; any internal readiness conclusion remains part of the APRA-led process.

Do this Monday

1. Choose one action, not the whole plan. Select a recovery or exit action with an AI-assisted execution step and a named human owner.
2. Draw the dependency-to-action map. Include model, upstream provider, cloud, identity, data, retrieval, orchestration, evidence and staff skills. Circle shared fault domains.
3. Set the pass evidence. Define the artefacts, authority checks and timing assumptions that must be demonstrated. Do not use "participants discussed the fallback" as a pass criterion.
4. Remove the dependency. Run one degraded, unavailable or untrusted scenario without provider support. Make participants use the actual alternative path.
5. Record blocked steps. Preserve logs, decisions, elapsed time, missing access and failed hand-offs. A blocked result is useful evidence, not a reason to soften the rating.
6. Fund the preparatory measure. Assign a human owner and due date for independent data access, documentation, skills, contracts or tooling, then schedule the retest through existing recovery and exit governance.

Bottom line

AI can assist recovery and exit work, but the plan must survive the loss of that assistance. A second tool inside the same fault domain is not a fallback, and a tabletop assertion is not an operational test. Link every action to its dependencies, remove them and require people to produce the evidence. If the action cannot run without the failed AI stack, it is not yet credible.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. Australian Prudential Regulation Authority, CPS 190 Recovery and Exit Planning, in force from 1 January 2024 for covered entities other than RSE licensees and from 1 January 2025 for RSE licensees. https://www.apra.gov.au/standards/cps-190
2. Australian Prudential Regulation Authority, CPG 190 Recovery and Exit Planning, current guidance from 1 January 2024. https://www.apra.gov.au/practice-guides/cpg-190
3. Australian Prudential Regulation Authority, CPS 900 Resolution Planning, in force from 1 January 2024, with entity requirements applying following APRA notification. https://www.apra.gov.au/standards/cps-900
4. Australian Prudential Regulation Authority, CPG 900 Resolution Planning, current guidance from 1 January 2024. https://www.apra.gov.au/practice-guides/cpg-900
5. Australian Prudential Regulation Authority, APRA Letter to Industry on Artificial Intelligence (AI), 30 April 2026. https://www.apra.gov.au/news-and-publications/apra-letter-industry-artificial-intelligence-ai
6. Australian Prudential Regulation Authority, CPS 230 Operational Risk Management, in force from 1 July 2026. https://www.apra.gov.au/standards/cps-230