APRA CPS 230 AI: operational risk and defensible use

APRA CPS 230 does not mention artificial intelligence, and that is exactly why it applies to it. The standard is about operational risk, business continuity, and the management of service providers — and when an APRA-regulated entity puts an AI system into a critical operation, or routes a critical process through a third-party model, that system falls squarely inside those obligations. If your bank, insurer, superannuation fund, or advice business is using AI in anything that touches customers, capital, or regulatory reporting, CPS 230 is already the frame regulators will use to assess whether that use is defensible. The question is not whether the standard applies. It is whether you can show you have treated the AI system as the operational risk it is.

According to APRA (2025), CPS 230 Operational Risk Management commenced on 1 July 2025 and requires regulated entities to manage the material service providers their critical operations depend on. It is deliberately technology-neutral. That neutrality is the point most financial-services firms miss: they wait for AI-specific rules while the general operational-risk obligations already reach every consequential AI deployment they run. This article sets out how AI use intersects CPS 230, where the Privacy Act 2026 overlaps, and what a defensible AI posture looks like in practice.

Why CPS 230 already covers your AI

CPS 230 asks a regulated entity to identify, assess, and manage the operational risks that could disrupt its critical operations — and to do the same for the service providers those operations depend on. An AI system used in underwriting, fraud detection, claims assessment, customer identity verification, or advice compliance is a component of a critical operation. A large language model accessed through a cloud API is a service provider dependency. Neither is exempt because it happens to be AI.

There are three CPS 230 threads that AI touches most directly:

Operational risk management. The entity must maintain a framework that identifies and controls the risks in its critical operations. An AI model that classifies, scores, drafts, or decides introduces failure modes a traditional process does not: silent accuracy drift, hallucinated outputs presented with confidence, sensitivity to changes in upstream data, and opacity about why a given output was produced. If these risks are not in your operational risk register, your framework has a gap that CPS 230 expects you to have found.

Business continuity. CPS 230 requires entities to be able to continue critical operations within tolerance levels through disruption. If a critical process now depends on an AI system — or on a third-party model that could be rate-limited, deprecated, or changed without notice — the continuity plan has to account for that. "The vendor upgraded the model and our outputs changed" is an operational disruption. So is "the API was unavailable for six hours during month-end."

Management of service providers. This is the obligation that most AI use pulls into scope, because the majority of mid-market AI is built on third-party foundation models and platforms. CPS 230 expects entities to maintain a register of material service providers, conduct due diligence, manage the risks of those relationships, and understand their concentration exposure. A model provider sitting inside a critical operation is a material arrangement, whether or not your procurement team has classified it that way.

The overlap with the Privacy Act 2026

CPS 230 is not the only regime in play. Where an AI system uses personal information — and in banking, insurance, super, and advice, it almost always does — the Privacy Act 2026 applies in parallel. The two regimes reinforce each other rather than compete.

The Act's automated-decision-making transparency and review obligations bite where AI meaningfully influences a decision about an individual: a credit assessment, a claims outcome, a fraud flag that freezes an account. CPS 230 asks you to control the operational risk of that same system. In practice the artefacts overlap heavily — the system inventory, the accountable owner, the record of how outputs are checked, the incident pathway. Building for one and ignoring the other wastes the work. We cover the automated-decision detail in our explainer on the Privacy Act 2026, and the broader governance frame in the Voluntary AI Safety Standard explained for boards.

Mapping AI risks to CPS 230 obligations

The following maps the AI-specific failure modes we see in APRA-regulated back offices to the CPS 230 obligation they engage and the control that answers it.

AI risk	CPS 230 obligation engaged	Control that makes it defensible
Model produces inaccurate outputs that flow into a critical operation	Operational risk identification and control	Accuracy monitoring against a labelled baseline; defined tolerance; alerting on drift
Third-party LLM provider changes, deprecates, or rate-limits the model	Management of service providers; business continuity	Provider register entry; contractual change notice; a fallback path and tested continuity plan
No named person accountable for the AI system	Operational risk framework; accountability	A named accountable owner per material AI system, visible to the risk function and board
AI output actioned without human review in a consequential decision	Operational risk control; human oversight	Defined human checkpoint with authority and information to override; the review logged
Concentration on a single model provider across multiple critical operations	Service-provider concentration risk	Concentration assessment; documented tolerance; a substitution strategy
No detection or response when the AI system misbehaves	Operational risk incident management	Incident response procedure covering AI-specific failure modes, with escalation and recording
Personal information used in AI without controls	CPS 230 data risk; Privacy Act 2026 overlap	Privacy Impact Assessment; purpose limitation; retention rules for logs and outputs
No record of what the system does or why an output was produced	Operational risk record-keeping	Audit logging of inputs, outputs, and the human review step

This is not a compliance checklist to survive an audit. It is the shape of an AI deployment that will not fail quietly in production — which is the same thing CPS 230 is trying to get you to build.

What defensible AI actually looks like

"Defensible" means you can show a regulator, a board, and your own risk committee that a given AI use was deployed knowingly, controlled deliberately, and monitored continuously. Five elements carry most of that weight.

A system inventory. You cannot manage what you have not listed. A defensible posture starts with a register of every AI system in production use, including the shadow tools that crept in through a copilot licence or a team's own subscription. Each entry records purpose, the critical operation it touches, the data it uses, the third-party providers behind it, and its risk classification. Most firms we assess do not have this, and the exercise of building it usually surfaces two or three deployments nobody had governance over.

Accountable owners. Every material AI system needs a named individual accountable for its performance and its incidents — not a committee, not "IT." CPS 230's operational-risk framework and the accountability expectations under APRA's broader regime both point to this. The owner is the person who answers when the model drifts.

Monitoring and incident response. AI systems degrade without anyone touching them, because the world they operate in changes. Defensible use means the system's accuracy is measured against a baseline on a defined cadence, degradation triggers an alert, and there is a written procedure for what happens when an output is wrong or harmful. The incident pathway must name AI-specific failure modes, not just generic IT outages.

Provider due diligence. Where a third-party model sits inside a critical operation, treat it as the material service provider it is. Due diligence covers the provider's own controls, data handling, change-notification commitments, and continuity. Concentration matters: if one provider underpins underwriting, fraud, and customer service, that is a single point of failure your continuity plan has to address.

Human checkpoints. For consequential decisions, a qualified human reviews the AI output before action, with both the information and the authority to override it — and the review is logged. This is where operational-risk control and Privacy Act 2026 review obligations meet. A rubber-stamp is not a checkpoint.

Where AI enters critical operations in practice

The abstraction becomes concrete quickly. In identity and onboarding, AI-assisted classification of customer documents is now common — an area where accuracy, auditability, and human checkpoints all matter, and one we detail in our finance broking document triage case study. In advice, AI is used to score adviser file notes and communications for compliance, which is precisely the kind of consequential, individual-affecting use that both CPS 230 and the Privacy Act reach; our financial adviser compliance scorecard work shows what a controlled version looks like. In each case the difference between a defensible deployment and a liability is not the model. It is the inventory, the owner, the monitoring, and the checkpoint around it.

Definitions and quick answers

Does CPS 230 apply to AI even though it does not mention it? Yes. CPS 230 is technology-neutral. An AI system inside a critical operation, or a third-party model your critical operations depend on, is captured by the operational-risk and service-provider obligations regardless of the technology involved.

Is a cloud LLM provider a "service provider" under CPS 230? If a critical operation depends on it, treat it as a material service provider — due diligence, register entry, concentration and continuity assessment. The label your procurement team applied does not change the obligation.

Do we need AI-specific policies, or is our existing operational-risk framework enough? The framework is the right home, but it usually needs extension. AI introduces failure modes — drift, hallucination, opacity — that generic operational-risk controls do not name. Extend the register, monitoring, and incident procedures to cover them.

How does this relate to the Privacy Act 2026? Where AI uses personal information or influences decisions about individuals, the Privacy Act applies alongside CPS 230. The two share most of the same artefacts, so build them once, deliberately.

What is the fastest way to know where we stand? A structured gap assessment against your live AI systems, the CPS 230 obligations they engage, and the Privacy Act overlap. That is a scoped piece of work, not a sprawling, multi-year programme.

Getting to defensible without the theatre

Most APRA-regulated mid-market firms are not starting from zero — they are starting from unknown. Adoption is already well ahead of governance: according to Deloitte (2025), across 542 financial-services respondents, only 46 per cent showed the traits of generative-AI "pioneers" with high or very high expertise, leaving the majority further behind on the risk and governance foundations the technology demands. There are AI systems in production, some governed and some not, and no single view of which critical operations depend on them. The work is to build that view, classify the risk, and put the five controls in place proportionate to it. An AI Readiness Audit produces the system inventory and the CPS 230 and Privacy Act 2026 gap analysis; our senior AI advisory supports the risk function and board in closing the gaps that assessment finds. Both are fixed-fee and led by senior practitioners who have done this in regulated environments.

If AI is in — or heading into — your critical operations and you cannot yet show it is defensible, contact us to scope a CPS 230 and Privacy Act 2026 gap assessment.