APRA CPS 230 and AI Governance

Why CPS 230 belongs in AI governance conversations

APRA CPS 230 belongs in AI governance conversations because enterprise AI is increasingly operational infrastructure. APRA describes CPS 230 as a prudential standard for operational risk management across APRA-regulated entities, with related materials and practice guidance. The standard is not written as an AI standard. That is exactly why it matters. AI governance in regulated financial services cannot live only in responsible-AI principles or model risk forums. When AI systems affect critical operations, business continuity, service providers, incident response, or customer outcomes, they become operational risk.

AI can create operational risk in several ways. A customer service agent may provide incorrect advice during a high-volume event. A claims workflow may delay payment because a document classifier fails. A fraud model may generate false positives that overload operations. A software agent may update records without adequate review. A security agent may trigger containment actions without sufficient authority. A model provider outage may degrade an important business process. A SaaS vendor may enable AI features that process sensitive records outside the original operating design. None of these examples require AI to be classified as a critical operation by itself. AI can still support, influence, or disrupt critical operations.

For boards and executives, the CPS 230 lens changes the question. The question is not only whether AI is fair, explainable, or innovative. It is whether the entity can continue operating safely when AI fails, changes, is misused, or depends on a provider. That requires inventory, ownership, risk assessment, service provider review, monitoring, incident playbooks, fallback design, and evidence. AI governance should therefore connect directly to operational risk management and business continuity, not sit beside them.

Current APRA context as of July 2026

APRA’s operational risk management page was last updated on April 30, 2026 and sets out details of CPS 230 and related materials. APRA states that on April 30, 2026 it released final targeted amendments to CPS 230, CPG 230, and the corresponding Material Service Provider Register template. APRA also states that the updated CPS 230 and CPG 230 commence on July 1, 2026. That date matters for any July 2026 AI governance analysis because older implementation summaries may still focus on the original July 1, 2025 commencement and transitional arrangements.

APRA’s latest update is relevant to AI governance because it addresses material arrangements with certain service providers and the MSP Register template, and much AI capability is delivered through service providers. AI governance often depends on providers that are not traditional outsourcing vendors in the old sense: foundation-model providers, cloud AI services, SaaS platforms, data processors, analytics tools, document automation providers, security platforms, customer operations vendors, and agent orchestration systems. Some may be deeply embedded in operations without being recognised early as material AI dependencies.

This report is not legal advice and does not interpret APRA obligations for any specific entity. It provides a governance view: if an AI system, agent, model provider, or AI-enabled vendor can affect operational resilience, service continuity, material arrangements, incident response, or board oversight, then CPS 230 should be part of the internal governance conversation. Regulated entities should involve qualified prudential, legal, risk, compliance, security, procurement, and operational-resilience teams when determining actual obligations.

AI as operational risk, not only model risk

Many organisations begin AI governance with model risk, and model risk remains important. But CPS 230 pushes AI governance into operational risk. Operational risk asks how failures in people, processes, systems, external events, and service providers can affect the entity. AI can sit inside all of those categories. People may over-rely on AI output. Processes may be redesigned around model predictions. Systems may call AI services during operational use. External events may affect model providers. Service providers may host AI capabilities. The risk surface is broader than model validation.

This broader view is particularly important for generative AI and agents. A traditional predictive model may support a decision, but an AI agent can act through tools. It can search records, draft communications, update tickets, call APIs, trigger workflows, and hand tasks to other systems. That shifts operational risk from advice risk to action risk. Governance should therefore assess not only whether the model is accurate, but whether the workflow can tolerate incorrect, delayed, unauthorised, or unavailable AI action.

Operational risk also includes dependency risk. A workflow may become dependent on AI quietly. Users may rely on generated summaries instead of reading source records. Operations teams may reduce staffing because automation appears reliable. Developers may embed model calls in production workflows. Vendors may make AI features default. If those dependencies are not mapped, the entity may discover operational exposure only during disruption. CPS 230-oriented AI governance should make AI dependency visible before stress reveals it.

Critical operations and AI dependency mapping

The first CPS 230-oriented AI governance task is dependency mapping. Identify where AI systems, AI agents, model APIs, vendor AI features, document processors, analytics models, copilots, and workflow automations support or influence critical operations. The mapping should not stop at systems formally labelled AI projects. Embedded AI in platforms, vendor features, employee tools, and agent integrations can all become operational dependencies. A critical operation can be affected by an AI system that no one in the formal AI inventory owns.

Dependency mapping should consider the path from AI activity to operational impact. Does AI triage work queues, route customer requests, summarise risk information, prioritise claims, draft customer communications, monitor fraud, assess cyber events, generate code, support reconciliations, review documents, or trigger operational actions? Does a failure create delay, incorrect action, customer harm, regulatory exposure, financial loss, or manual overload? Could the workflow continue without AI? How quickly? With what staffing and controls?

The output should be an AI dependency register linked to critical operations and business owners. Each dependency should record the AI function, vendor or internal owner, data sources, user group, autonomy level, fallback path, monitoring, incident owner, and review cadence. This register should connect to operational risk and business continuity processes rather than sitting in an innovation tracker. The enterprise needs to know which AI dependencies matter under stress.

Operational risk appetite and AI tolerances

Operational risk appetite for AI should be explicit. Some AI errors are tolerable because the work is low impact, reversible, and reviewed by humans. Other errors are unacceptable because they affect customers, members, policyholders, payments, security, regulated reporting, continuity, or critical operations. Risk appetite should define where AI may assist, where it may recommend, where it may act with approval, and where it may not act. It should also define when AI dependency becomes too concentrated or opaque.

Tolerances should be practical. If a critical operation depends on AI-supported triage, what level of outage, delay, error, queue growth, manual fallback, or provider unavailability is tolerable? If an AI vendor changes a model, how quickly must the entity detect material performance change? If an agent attempts a prohibited action, should the response be alert, approval, block, containment, or incident escalation? These questions turn AI risk appetite into operational thresholds.

Tolerances should be tested. A paper tolerance is not resilience. The entity should run scenarios: model provider unavailable, vendor AI feature disabled, agent blocked from a tool, incorrect summaries in a customer-impacting workflow, prompt-injection manipulation, excessive false positives, unavailable logs, failed human approval queue, or an offshore processor incident. These exercises reveal whether AI governance is ready for operational stress. They also create evidence for audit and management review.

Material service providers and AI vendors

AI governance under CPS 230 must pay close attention to service providers. APRA’s 2026 update discusses material arrangements and the Material Service Provider Register template. AI complicates service-provider governance because AI capability is often delivered through a chain: cloud provider, model provider, SaaS vendor, data processor, orchestration layer, monitoring tool, and subcontractors. A business team may see only one vendor contract, while the operational dependency spans several technical providers.

Provider review should be concrete. Does the provider support a critical operation or material business process? What AI functionality is provided? What data is processed? Is data used for training or product improvement? Where is processing performed? What subcontractors support the service? How are model changes notified? What logs and evidence can be exported? What service levels apply? What incident notice is available? Can AI features be disabled? What happens if the provider withdraws a model or changes behaviour? What exit or fallback path exists?

AI provider governance should be ongoing. A model provider can change models. A SaaS vendor can add AI features. A cloud provider can change service characteristics. An AI platform can alter data-handling terms. A subcontractor can change location. The entity should define material change triggers and periodic review. Provider opacity is itself a risk factor. Where assurance is limited, the entity should document the limitation, apply compensating controls, reduce autonomy, or decide that the residual risk is outside appetite.

Business continuity and fallback design

Business continuity for AI-enabled workflows should be designed before the workflow becomes business-critical. The key question is simple: if the AI system is unavailable, wrong, degraded, delayed, or blocked, can the entity continue the operation within tolerance? The answer depends on manual fallback, alternate providers, staff skills, data access, workflow design, customer communication, and monitoring. AI governance should require continuity planning for material AI dependencies.

Fallback should be realistic. A plan that says humans will review everything manually may fail if staff no longer know the process, source systems are hard to navigate, volumes are too high, or approvals are not staffed outside business hours. A plan that switches to another model provider may fail if prompts, data formats, security controls, logging, or contractual approvals are not portable. A plan that pauses the workflow may be acceptable for low-impact processes but unacceptable for critical operations. Continuity design should be tested, not assumed.

Fallback planning should also preserve governance. During disruption, organisations often relax controls. That may be necessary in some cases, but the relaxation should be approved, time-bound, monitored, and evidenced. If an AI tool is replaced by manual work, how will evidence be retained? If an agent is disabled, who approves alternative actions? If a model provider is unavailable, can another provider be used without exposing data or violating policy? CPS 230-oriented AI governance should anticipate stress behaviour.

Operational incidents and AI-specific scenarios

AI incident management should be connected to operational risk incident management. An AI incident may involve unavailable AI tooling, incorrect or harmful output, unauthorised data disclosure, prompt injection, unsafe agent action, excessive false positives, vendor outage, monitoring failure, uncontrolled cost escalation, or evidence loss. Some incidents will be security incidents. Some will be privacy incidents. Some will be operational incidents. Some may be all three. Governance should define triage criteria and escalation paths.

The incident record should capture what happened, which AI system or vendor was involved, which operation was affected, whether a critical operation or tolerance was implicated, what controls operated, what human review occurred, what data was involved, which customers or processes were affected, what remediation occurred, and what evidence supports the record. If APRA notification analysis is required, that analysis should be documented by the appropriate internal team. This report does not decide notification obligations.

Incident scenarios should be rehearsed. Examples include a model provider outage during a high-volume customer event, an AI summarisation error affecting operational decisions, an agent attempting to change records outside authority, a vendor AI feature exposing sensitive information, a prompt injection causing a tool call (the OWASP LLM01:2025 Prompt Injection risk category), or a failed approval queue delaying customer service. Exercises should test detection, escalation, containment, fallback, communication, evidence, and remediation. The goal is to make AI incidents operationally manageable before they become real.

Human oversight and maker-checker controls

Human oversight is central to CPS 230-aligned AI governance because operational risk often rises when people become passive monitors of automation. A human-in-the-loop statement is weak if the reviewer lacks time, context, authority, training, or evidence. Maker-checker controls should be explicit for material AI actions. Who proposes the action? Who approves it? What information does the checker see? Can the checker reject or escalate? Is the approval recorded? Are overrides monitored?

For high-impact workflows, oversight should be designed around failure modes. If AI triages claims, reviewers need enough information to detect misclassification. If AI drafts customer communications, approvers need source evidence and policy guidance. If an agent proposes a system change, the approver needs technical context and rollback planning. If AI summarises documents, reviewers may need source citations and confidence indicators. Oversight should not require humans to blindly trust a fluent output.

Oversight should also be tested for capacity. A control that requires approval for every AI action may fail if volumes are high. A control that approves actions by silence may fail during outage or staff absence. A control that relies on one expert may fail under stress. Governance should monitor approval queues, rejection rates, override rates, escalation patterns, and reviewer workload. Human oversight is a control only when it can operate at the required volume and speed.

Evidence and audit readiness

CPS 230-oriented AI governance should be evidence-led. The entity should be able to show what AI dependencies exist, which critical operations they affect, which providers support them, which controls apply, which incidents occurred, which tolerances were tested, which fallback plans exist, and which risk acceptances remain open. Evidence should be retained in a structured way that risk, compliance, operational resilience, security, privacy, and internal audit teams can use.

Audit evidence should include inventory records, dependency maps, provider assessments, material arrangement records, offshoring review where relevant, risk assessments, continuity plans, exercise results, monitoring thresholds, operational control events, human approvals, incidents, remediation tickets, exception approvals, and management review outcomes. For AI agents, evidence should include delegation boundaries, tool permissions, review gates, blocked actions, and control changes. Evidence should be attributable and tamper-evident where risk justifies it.

Audit readiness matters because AI governance often has scattered records. Business owners keep approvals in email. Security has logs. Procurement has contract records. Risk has spreadsheets. Vendors have dashboards. Developers have traces. Internal audit needs a coherent story. The governance system should connect the operational risk question to evidence: what happened, who owned it, what control applied, what provider was involved, what decision was made, and what changed afterward.

Board oversight and senior management accountability

CPS 230 is ultimately a board and senior management issue because operational resilience is not only a technology function. AI governance reporting should therefore be framed in business terms. Boards need to know which AI-enabled workflows affect critical operations, where material provider dependencies exist, what incidents or near misses occurred, which tolerances were breached or tested, which fallback plans are credible, and where residual risk sits outside appetite.

Senior management should receive enough detail to act. A dashboard showing AI adoption is not operational risk reporting. Useful reporting distinguishes between governed adoption and unmanaged exposure. It shows high-risk use cases, control gaps, overdue remediation, provider concentration, exception ageing, incident themes, evidence completeness, and maturity changes. It should also show whether business teams have the resources to operate fallback and oversight controls.

Board oversight should include challenge. What AI dependencies would matter in a disruption? Which AI vendors support critical operations? What would happen if a model provider failed? How are agent permissions limited? How are human approvals evidenced? Which AI incidents were near misses? What has internal audit tested? What is the remediation backlog? These questions help boards govern AI as operational risk without requiring them to become model engineers.

Conclusion: Helixar perspective

Helixar supports CPS 230-aligned AI governance by making AI activity visible and controllable during operational use. Operational risk teams can define policies, but those policies need to operate across providers, workflows, SaaS tools, internal applications, and agents. This research emphasizes observing AI actions, evaluating policy, supporting proportionate governance responses, and retaining evidence. That makes it easier to connect AI governance to operational risk, service provider management, incident response, and audit readiness.

For critical-operation exposure, this governance pattern can help identify and monitor AI activity that supports material workflows. For provider governance, it can help show where AI activity flows through approved providers and where policy violations or exceptions occur. For agents, it can help enforce tool boundaries, require approvals for higher-risk actions, block prohibited actions, and record delegation-related evidence. For incidents, it can help preserve the event trail needed to understand what happened.

Helixar does not determine APRA obligations, make a system compliant by itself, or replace legal, prudential, operational resilience, or audit advice. Its role is practical: help the entity operate AI controls and retain evidence that controls operated. That evidence can support CPS 230-aligned reviews, internal audit, management reporting, incident analysis, and remediation. In an operational-risk context, proof matters as much as policy.

Mechanically, this is where the control plane earns its place in a CPS 230 program: it sits in front of or in place of the AI gateway, so every AI or agent action that touches a critical operation or a material service provider is evaluated at the moment it is attempted, across every model provider in the chain this report describes. At each action it verifies user and agent identity and context, evaluates the action against operational-risk policy, and applies a graduated response that maps directly to CPS 230 tolerances: observe low-impact work, alert on drift, require maker-checker approval before a customer-impacting or record-changing action, and block or contain an agent that attempts a prohibited or out-of-authority tool call. Because it is fail-closed by default and enforces organisation-wide cost caps, an agent cannot keep acting when policy, a model provider, or an approval queue is unavailable, which is the fallback discipline the continuity section calls for. Every one of these decisions is written to a tamper-evident, independently verifiable evidence trail, giving operational risk, security, and internal audit the single coherent record the evidence section asks for instead of decisions scattered across model logs, vendor portals, and ticketing systems. SOC 2 and ISO 27001 evidence packs are available today, and APRA CPS 234, EU DORA, and ISO 42001 are mapped and delivered at implementation, so the same action-level evidence feeds the framework reviews that sit alongside a CPS 230 operational-risk program.

Implementation roadmap

The first phase is discovery. Identify AI systems, AI agents, model providers, vendor AI features, AI-supported workflows, data flows, and business owners. Link each AI dependency to operational processes and determine whether it supports or influences a critical operation, material business process, or regulated workflow. Pay special attention to embedded SaaS AI and vendor features because they often bypass formal AI project intake.

The second phase is operational risk assessment. For each material AI dependency, assess impact, provider reliance, continuity, human oversight, autonomy, data sensitivity, incident detectability, fallback design, offshoring and subcontractor exposure where relevant, and residual risk. Classify the use case and define controls. Decide whether provider arrangements require additional review, contract changes, monitoring, or inclusion in service provider registers or reporting processes.

The third phase is control operation and assurance. Implement runtime policies, monitoring, review gates, incident playbooks, fallback exercises, management reporting, and evidence retention. Test scenarios. Review provider changes. Track exceptions. Report high-risk exposures to senior management. Involve internal audit once the control design is mature enough to test. Improve the system after incidents, exercises, audit findings, and APRA guidance updates.

Common failure patterns

The first failure pattern is treating AI as innovation rather than operational dependency. Teams celebrate adoption but do not map the workflows that rely on AI. The second is vendor invisibility. AI features appear inside existing platforms without service-provider review. The third is manual fallback fantasy. Continuity plans assume staff can replace AI instantly, but the manual process has not been tested at volume. The fourth is unclear incident classification. AI incidents bounce between technology, privacy, security, operations, and compliance with no clear owner.

The fifth failure pattern is weak agent control. An agent receives broad user permissions and can call tools without purpose-bound limits or review gates, the failure mode catalogued as OWASP LLM06:2025 Excessive Agency in the OWASP Top 10 for LLM Applications. The sixth is stale provider assurance. A model or SaaS vendor changes behaviour, terms, subcontractors, or geography without reassessment. The seventh is evidence fragmentation. When management asks what happened, records are spread across model logs, vendor portals, chat tools, emails, ticketing systems, and spreadsheets.

The remedy is operational discipline. Treat material AI use like a real dependency. Map it, classify it, assign owners, define tolerances, review providers, test fallback, monitor runtime behaviour, capture evidence, and report residual risk. The CPS 230 lens is useful because it brings AI governance back to the central prudential question: can the entity continue operating within its approved risk appetite when technology, providers, people, or processes fail?

The takeaway

APRA CPS 230 is not an AI governance standard, but it is highly relevant to AI governance in APRA-regulated environments. AI systems and agents can affect critical operations, business continuity, service provider exposure, incident response, and operational resilience. A regulated entity that governs AI only through ethics principles or model validation may miss the operational-risk reality of modern AI adoption.

The strongest approach is to connect AI governance to existing operational risk management. Build an AI dependency register. Map critical-operation exposure. Review AI providers. Define tolerances and fallback. Monitor agentic activity. Rehearse incidents. Retain evidence. Report residual risk to senior management and the board. Involve qualified teams for actual regulatory interpretation and obligations.

AI governance becomes serious when it can answer operational questions under stress. Which AI dependency failed? Which operation was affected? Which provider was involved? Which control operated? Who approved the fallback? Was a tolerance breached? What evidence proves the response? CPS 230 gives regulated entities a strong reason to build those answers before disruption asks for them.