Your AI Vendor Count Is Hiding One Foundation Model.

Three contracted AI vendors can still fail as one service when they share a foundation model, cloud control plane or identity layer. Count common roots, test genuinely independent substitutes and show which critical operations remain inside tolerance when the shared dependency fails.

Three AI vendors do not give you three independent services. They may be separate on the vendor register and identical at the point that matters: the model, cloud, gateway, identity service or monitoring layer on which each product depends.

The control is a provider-normalised dependency graph. Map every direct AI service back to its common technical roots, connect those roots to critical operations, then test whether your nominated substitute survives the same failure. This is not another vendor due-diligence checklist. It is a portfolio resilience test.

The graph is a proposed internal control from TheAICommand, not an APRA-prescribed template. CPS 230 supplies enforceable operational resilience and service-provider requirements. CPG 230 supplies non-binding guidance. APRA's April 2026 AI letter and May 2026 System Risk Outlook add published supervisory observations and risk concerns. Those sources should inform the control without being presented as if every sentence in them were a prudential obligation.

Why does three vendors still equal one dependency?

Procurement records the party you pay. Operational resilience needs to know what actually delivers the service.

Vendor [VENDOR_A] might provide a document assistant. [VENDOR_B] might summarise contact-centre records. [VENDOR_C] might support software development. If all three route work to [FOUNDATION_MODEL_FAMILY], use the same [CLOUD_CONTROL_PLANE], or depend on one identity or model gateway, the contractual diversity can conceal a common failure domain.

APRA described this problem directly in its Letter to Industry on Artificial Intelligence, published 30 April 2026. Following targeted engagement in late 2025 with selected large banks, insurers and superannuation trustees, APRA observed heavy dependence at some entities on a single provider across multiple AI use cases. It also said few entities demonstrated robust contingency planning or tested exit and substitution strategies for critical AI providers.

The same letter said embedded AI can make foundation models, training data and fourth-party dependencies opaque. APRA set out an expectation that entities have visibility across the AI supply chain, understand material changes and test the credibility of substitution, portability and exit. That is a supervisory communication, not a new prudential standard. It is still a clear warning against treating the direct-vendor count as the resilience answer.

APRA's System Risk Outlook of May 2026 identifies supply-chain concentration and inadequate assurance among its AI concerns. It also describes material third-party concentration as a potential system-wide single point of failure and includes concentration of AI providers among the dependencies it expects entities to manage actively. Again, this is a published risk outlook rather than an enforceable instrument.

Your map therefore needs two views. The legal-entity view supports contracting, ownership and material-service-provider classification. The common-root view shows which services can disappear, degrade or change together.

What does CPS 230 actually require?

CPS 230 has applied since 1 July 2025. APRA finalised targeted amendments in April 2026, and the current replacement CPS 230 determination commenced on 1 July 2026. The operational-risk policy update records that sequence and the July 2026 commencement of the updated standard and guidance.

Under the current enforceable standard, an APRA-regulated entity must identify and document the processes and resources needed to deliver critical operations. That includes people, technology, information, facilities and service providers, and the interdependencies across them, together with associated risks, obligations, key data and controls. Its BCP testing program must cover all critical operations and test severe but plausible scenarios, including material-service-provider disruptions and the use of contingency arrangements.

CPS 230 also requires a service-provider management policy that covers entering, monitoring, substituting and exiting material arrangements. The policy must address risks from fourth parties that material service providers rely on in providing a critical operation. Before entering or materially modifying a material arrangement, the entity must assess reliance risks, including geographic or concentration risk involving the provider or parties on which it relies. For each material arrangement, the entity must ensure its BCP can be executed and an orderly exit can be conducted. Where those approvals and changes are tracked matters too: an obligations register with human change control keeps the approval state of each AI service inspectable.

That does not mean every foundation model, cloud service or AI component automatically belongs in the formal material-service-provider register. CPS 230 defines material service providers by reliance for a critical operation or exposure to material operational risk, subject to the standard's minimum categories and APRA's powers. Classification remains an entity-specific assessment.

The current CPG 230, July 2026, is prudential guidance and expressly does not create enforceable requirements. It says a prudent entity would take reasonable steps to list fourth parties involved where a material arrangement supports a critical operation. It also discusses managing the aggregate operational risk of a cohort of service providers where the combined impact is material, even if each provider is not itself classified as material.

That distinction supports a broader internal dependency graph than the formal register. Put every relevant upstream dependency in the graph, with an evidence status. Apply the CPS 230 classification test separately.

The 2026 CPS 230 amendments provide limited relief from specified contractual requirements where an arrangement is with a listed exempt-provider category and uses standardised terms or is not documented in a formal agreement. APRA's final-amendments announcement of 30 April 2026 explains the targeted relief. All other CPS 230 requirements continue to apply. This is not a general AI or cloud exemption.

How do you test a common-root failure?

Start with an evidence-backed graph, not a workshop guess. For every approved AI service, record:

• the direct vendor, contracted service, business owner and approved use case;
• the critical operation supported, tolerance level and minimum service level;
• the served model family, version alias, model operator and evidence date;
• the hosting cloud, region, control plane, gateway, identity and retrieval dependencies;
• disclosed subcontractors and fourth parties, plus unknown or contested edges;
• material-change notification and internal change-assessment routes;
• the nominated substitute and every root it shares with the primary service; and
• the exit owner, last test date, measured switch time and unresolved prerequisites.

Use confidence labels such as verified, vendor-stated, inferred and unknown. An inference may direct investigation. It must not be reported to the board as a confirmed architecture fact.

Use this prompt to turn approved evidence into a first-pass graph. Procurement, technology, business-continuity and risk owners must verify every edge and make all materiality decisions before use.

Using only [APPROVED_SOURCE_PACK], create a dependency graph for each [AI_SERVICE_ID].

Return direct vendor, supported critical operation, foundation model, hosting cloud, region or control plane, gateway, identity, retrieval, monitoring, fourth parties, evidence source, evidence date and confidence.

Group services by shared root. Mark every missing or inferred edge HUMAN REVIEW REQUIRED. Do not classify a provider as material, approve a substitute or state that an unknown dependency is independent.

Then test failure by common root. A useful scenario removes or materially degrades the root across every connected service at once. Test at least model unavailability or material model change (every served model eventually reaches a retirement date), a shared cloud or control-plane outage, loss of the common identity or gateway, and removal or alteration of an upstream service or data-handling arrangement. If the shared root fails through a data breach rather than an outage, the notification clock on your vendor arrangements starts alongside the resilience response.

For each scenario, record which critical operations are affected, the remaining independent capacity, whether minimum service levels can be maintained, the actual time to switch, the people and approvals required, and the evidence produced by the test. The question is not whether a fallback name exists. It is whether the fallback works inside the relevant tolerance without relying on the failed root.

Apply a four-proof substitution test:

1. Capability: the alternative performs the minimum function needed during disruption.
2. Infrastructure: it does not share the failed model, cloud control plane, gateway or identity dependency.
3. Data and control: required data, context, access controls and records remain available on an independent path.
4. Execution: authorised people can activate and operate it within tolerance, using tested instructions.

Use this prompt to challenge a proposed fallback. The critical-operation owner and authorised BCP decision-maker must review the evidence, decide remediation and retain activation authority.

Red-team [SUBSTITUTION_PLAN_ID] against [DEPENDENCY_GRAPH_VERSION] and [CRITICAL_OPERATION_TOLERANCE].

Assume [COMMON_ROOT] fails across every connected service. Test capability, infrastructure independence, data and control continuity, and executable human activation. Identify shared roots, untested assumptions, unavailable evidence and steps that exceed tolerance.

Return PASS, FAIL or NOT PROVEN for each proof with evidence references. Do not approve the plan, activate a service or accept residual risk.

Fictional worked example: [VENDOR_A], [VENDOR_B] and [VENDOR_C] are separate contracts supporting [CRITICAL_OPERATION]. The graph shows all three use [FOUNDATION_MODEL_FAMILY]; two also share [CLOUD_CONTROL_PLANE]. The documented fallback is [VENDOR_C], so it fails the infrastructure-independence proof. Human owner [RESILIENCE_OWNER_ROLE] establishes a minimum-service manual process and evaluates [INDEPENDENT_SERVICE_OPTION]. A supervised exercise records switch time [TEST_DURATION], service achieved [MINIMUM_SERVICE_RESULT] and decision [HUMAN_DECISION_ID]. The example is fictional and does not establish any real provider architecture or materiality classification.

Do this Monday

1. Choose one critical operation. Take the operation with the highest AI-assisted dependency or least credible workaround. Confirm its current tolerance and minimum service level with the accountable human owner.
2. Normalise five services. Trace five direct AI vendors back through their models, clouds, gateways, identity services and known fourth parties. Record the primary evidence and label every unknown.
3. Challenge the substitutes. Compare each nominated fallback with the primary service. Reject any claim of independence that relies only on a different product name or contract.
4. Run one common-root scenario. Remove the most repeated root from the exercise. Measure the operational impact, remaining capacity, switch time and manual intervention required.
5. Reconcile the governance records. Link the graph to the critical-operations register, BCP, service-provider records, change process and board reporting. Keep the formal CPS 230 materiality classification distinct from broader internal mapping.
6. Assign the unknowns. Give each missing dependency edge an owner, evidence request and due date. Escalate any unknown that prevents a credible tolerance or substitution conclusion.

Bottom line

Vendor diversity is not resilience when every route ends at the same foundation model or control plane. CPS 230 requires you to understand critical-operation interdependencies and manage concentration, continuity, substitution and exit where its materiality tests are met. A common-root graph makes the hidden portfolio exposure testable without pretending every upstream component is automatically an MSP. Let AI assist with mapping and challenge, but keep architecture confirmation, materiality, risk acceptance and BCP activation with named people.

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, Banking, Insurance, Life Insurance, Health Insurance and Superannuation (prudential standard) determination No. 1 of 2026, including CPS 230 Operational Risk Management, dated 23 April 2026, in force 1 July 2026. https://www.apra.gov.au/standards/cps-230
2. Australian Prudential Regulation Authority, CPG 230 Operational Risk Management, prudential practice guide, July 2026. https://www.apra.gov.au/practice-guides/cpg-230
3. 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
4. Australian Prudential Regulation Authority, APRA's System Risk Outlook, 21 May 2026. https://www.apra.gov.au/apras-system-risk-outlook-may-2026
5. Australian Prudential Regulation Authority, Operational risk management, policy update recording the 2026 CPS 230 and CPG 230 amendments. https://www.apra.gov.au/consultations/operational-risk-management
6. Australian Prudential Regulation Authority, Final targeted amendments to CPS 230 Operational Risk Management, 30 April 2026. https://www.apra.gov.au/news-and-publications/final-targeted-amendments-cps-230-operational-risk-management