AI Systems Are Operational Processes — and CPS 230 Knows It
CPS 230 requires regulated entities to identify their critical operations and manage the risks to them end to end, with effective internal controls, monitoring, and remediation. If an AI model triages insurance claims, scores credit applications, or routes customer queries, it has become part of an operational process — and potentially a critical one. The standard's expectation is clear: you must understand how that process works, what could disrupt it, and how you would maintain the service if it failed. 'The model is a black box' is not an acceptable answer under a standard built on operational transparency and outcome-focused resilience.
Third-Party AI Is Now Squarely a Service Provider Risk
Most Australian financial institutions do not build foundation models in-house — they consume AI through third parties: OpenAI via Azure, AWS Bedrock, or specialist vendors. This is exactly the territory CPS 230 was designed to cover. The standard extended requirements to all material service providers, explicitly including SaaS and cloud, and requires a service provider register, formal agreements, and robust ongoing monitoring. Notably, APRA reserves the right to inspect material service providers directly. When your underwriting depends on an external AI API, that provider is a material service provider in the CPS 230 sense. The questions APRA expects you to have answered: what happens if the API goes down, changes its model, or is withdrawn? Do you have a fallback that keeps the critical operation within tolerance?
Know the Notification Clock
CPS 230 imposes hard notification timeframes that AI failures can trigger. Entities must notify APRA as soon as possible and no later than 72 hours after becoming aware of an operational risk incident likely to have a material financial impact or materially affect the entity — and no later than 24 hours after a disruption to a critical operation moves outside approved tolerance levels. If an AI system supporting a critical operation degrades or produces materially wrong outputs at scale, that clock may already be running. Your incident response process needs to recognise AI-driven failures as reportable events, not just infrastructure outages.
Business Continuity Must Account for AI Failure Modes
CPS 230 requires credible business continuity planning, tested against severe but plausible scenarios, with defined tolerance levels for disruption. AI introduces failure modes that traditional systems do not — silent model drift, degraded accuracy on edge cases, or confidently wrong outputs. A robust CPS 230 posture means your continuity planning addresses not just 'the system is down' but 'the system is up and producing subtly wrong results.' That requires monitoring designed specifically for AI: tracking output distributions, flagging anomalies, and defining the point at which a human takes over.
Accountability Cannot Be Delegated to a Model
A recurring theme across APRA's framework — and reinforced by CPS 230's emphasis on board and senior management accountability — is that responsibility sits with named individuals, not systems. An AI model cannot be accountable. The executive who owns the operational process the model supports remains accountable for its outcomes. In practice this means clear ownership of every AI-supported critical operation, documented decision rights about when the model's output can be overridden, and an audit trail that lets you reconstruct why a given decision was made.
Stay Current: The Standard Itself Is Still Moving
CPS 230 is not static. As recently as 30 April 2026, APRA released targeted amendments introducing limited exemptions from specific contractual requirements for certain categories of material service providers, where contractual compliance is not practicable — with accompanying updates to the CPG 230 guidance. For institutions relying on large global AI providers (where you have little leverage to negotiate bespoke contractual terms), these amendments matter. Part of a mature CPS 230 posture is tracking how the standard evolves and adjusting your service provider arrangements accordingly.
How GOSOL Helps
GOSOL works at the intersection of AI delivery and Australian financial regulation. We help regulated entities deploy AI and automation in a way that stands up to prudential scrutiny — mapping AI systems against CPS 230 obligations, designing monitoring and human-in-the-loop controls, and building the audit trails that turn 'we use AI' into 'we govern AI.' Our experience building compliance platforms to APRA and ASIC standards means we understand both sides: the technology, and the obligation it sits under.
