APRA CPS 234 and AI: What Financial Services Firms Need to Know in 2026

APRA CPS 234 (Information Security) and CPS 230 (Operational Risk) together create a compliance framework that makes cloud AI use uncomfortable for Australian financial services firms. The standards do not prohibit AI — they require regulated entities to manage AI-related risks with the same rigour applied to any other critical information system. For most banks, insurers, and superannuation funds, this calculation increasingly favours private, on-premises AI deployment over cloud alternatives. This guide explains why.

APRA's Prudential Framework, Briefly

The Australian Prudential Regulation Authority (APRA) regulates banks, insurers, and superannuation funds. Its prudential standards are binding on regulated entities — non-compliance can result in enforceable directions, civil penalties, and director-level personal liability under the Banking Act and SIS Act.

For technology and information security, the key standards are:

CPS 234 and CPS 230 are the two that most directly shape AI deployment decisions. They are technology-neutral, but their application to AI is increasingly clear in APRA's commentary and guidance.

CPS 234 in Detail

CPS 234 sets prudential requirements for information security. The key obligations:

Paragraph 13: Information Security Capability

An APRA-regulated entity must maintain an information security capability commensurate with the size and extent of threats to its information assets, and which enables the continued sound operation of the entity.

For an entity deploying AI:

• The AI system is an information asset (or processes information assets)
• Threats to that system are threats to the entity's information security capability
• The entity must maintain controls commensurate with those threats

Cloud AI providers introduce threats the entity does not directly control: foreign legal jurisdiction, provider employee access, supply chain risks, subprocessors. On-premises AI keeps threats within the entity's direct control surface.

Paragraph 14: Information Security Policy Framework

The entity must have a policy framework that provides direction on the responsibilities of all parties (including third parties) for maintaining information security.

For AI use, this requires:

• Documented policy on what AI tools are approved
• Clear rules on what data can be used with which tools
• Responsibilities for AI-related security incidents
• Integration with broader information security policies

Many regulated entities currently have AI policies that lag practice — staff use cloud AI tools that have not been formally approved, with data that may not be appropriate.

Paragraph 15: Information Asset Identification and Classification

The entity must identify and classify its information assets by criticality and sensitivity.

For AI deployment decisions:

• What data will the AI process?
• How is that data classified?
• Does the AI deployment model preserve the classification's protective controls?

A customer's transaction history is typically classified as confidential. Sending it to a US cloud AI provider via API arguably reduces its protective controls — the data is now subject to provider security controls outside the entity's direct view.

Paragraph 17: Implementation of Controls

An APRA-regulated entity must implement controls to protect its information assets commensurate with the criticality and sensitivity of those information assets, and undertake systematic testing and assurance regarding the effectiveness of those controls.

Where information assets are managed by a third party, the entity must evaluate the third party's information security capability.

This is the provision that creates the biggest compliance gap for cloud AI:

• The entity cannot directly inspect cloud AI provider security controls
• The entity must rely on the provider's certifications (SOC 2, ISO 27001) which describe processes but not specific data handling
• The entity cannot conduct independent testing of the provider's controls in any meaningful way
• The entity must somehow assure itself, and APRA, that controls remain effective over time

On-premises AI deployment makes this entire framework simpler: the controls are the entity's own controls, applied to a system the entity owns. CPS 234 paragraph 17 reduces to "do what you do for all your other information systems."

Paragraph 23-26: Notification Obligations

The entity must notify APRA of material information security incidents within 72 hours, and material information security control weaknesses as soon as possible.

For AI use, this means having visibility into incidents that occur in the AI system. With cloud AI, the entity depends on the provider's incident reporting — which may be slow, partial, or absent for issues the provider does not consider serious. With on-premises AI, the entity has direct visibility.

CPS 230 and Material Service Providers

CPS 230 (Operational Risk Management), effective 1 July 2025, introduced specific requirements around material service providers — third parties that perform functions material to the entity's operations.

Paragraph 50: Material Service Provider Identification

The entity must identify all material service providers and the services they perform.

A cloud AI provider used in operational workflows (customer service automation, document processing, decision support) is likely a material service provider once usage scales beyond pilot deployments.

Paragraphs 51-54: Material Service Provider Management

For material service providers, the entity must:

• Conduct due diligence before engagement
• Document arrangements in formal agreements with specific terms
• Monitor performance and risk
• Have an exit strategy

The exit strategy requirement is particularly relevant for cloud AI. If a provider:

• Changes pricing significantly
• Modifies terms of service unfavourably
• Suffers a major outage or security incident
• Is subject to a foreign legal order affecting Australian data

The entity must be able to exit and replace the provider without unacceptable operational disruption. For deeply integrated cloud AI, this can be very difficult — the entity may have built workflows, trained staff, and integrated systems around a specific provider's API.

On-premises AI uses open-source models (Llama 3, Gemma 4, Mistral) with no vendor lock-in. The entity owns the hardware, the deployment, and the configuration. There is no "exit" required because there is no provider to exit from.

Paragraph 55: Concentration Risk

The entity must manage concentration risk in material service providers — not relying too heavily on any single provider or category of provider.

The cloud AI market is highly concentrated: OpenAI, Microsoft, Google, Amazon dominate. Several major Australian financial services firms have publicly committed to AI strategies built on one or more of these providers. Concentration risk is real and rising.

On-premises AI using open-source models diversifies away from this concentration: the entity is not dependent on a single foreign vendor for ongoing service.

SPS 232 — Superannuation-Specific Considerations

For superannuation entities, SPS 232 (Data Risk Management) adds specific requirements:

• Data quality and integrity controls
• Data access controls and audit logging
• Specific consideration of data location and sovereignty
• Member data handling obligations

The Superannuation Industry (Supervision) Act 1993 (SIS Act) and SPS 232 together create heightened obligations around member data. Sending member data to overseas cloud AI providers is increasingly difficult to reconcile with these obligations.

What APRA Has Said About AI Specifically

APRA's public commentary on AI has emphasised several themes:

Technology Neutrality

APRA's standards are technology-neutral. AI does not get a special exemption from CPS 234 or CPS 230. The same rigour applied to traditional IT systems applies to AI.

Risk-Based Approach

The intensity of controls should match the risk. AI used for high-impact decisions (lending, claims assessment, financial advice) warrants more rigorous controls than AI used for back-office tasks (document classification, internal search).

Accountability

Entities cannot outsource accountability to vendors. The entity's board and senior management remain accountable for the risks introduced by AI use, regardless of which vendor provides the underlying technology.

Operational Resilience

APRA increasingly emphasises operational resilience — the ability to maintain core functions through disruptions. Dependence on overseas cloud providers creates resilience risks that domestic, on-premises infrastructure does not.

In multiple speeches and information papers (2024-2026), APRA leadership has noted that boards of regulated entities should be actively asking questions about AI risk, sovereignty, and the firm's ability to operate if a key AI provider became unavailable.

The Compliance Math: Cloud AI vs Private AI

Comparing the compliance overhead:

The pattern is clear: cloud AI carries substantial compliance overhead that on-premises AI eliminates. For regulated entities, "the cheapest deployment" calculation should include this overhead, not just the per-user licence costs.

For broader context, see our analysis in private LLM vs public LLM and sovereign AI Australia.

Real-World Scenarios

Scenario 1: Mid-Tier Insurer Using ChatGPT Enterprise

A general insurer with 800 claims staff deploys ChatGPT Enterprise to assist with claim summary drafting. Staff paste claim details (including personal information, medical reports, and incident specifics) into ChatGPT.

CPS 234 issues: Third-party processing of confidential information assets; provider's security controls outside the insurer's direct evaluation.

CPS 230 issues: ChatGPT becomes operationally embedded; concentration risk in a single foreign vendor; exit strategy requirements.

Privacy Act issues: Cross-border disclosure (APP 8), use beyond original collection purpose (APP 6).

Alternative: On-premises private AI deployment with the same functional capability. Total compliance overhead substantially lower. No data leaves the insurer's environment.

Scenario 2: Major Bank Considering Copilot Rollout

A retail bank is evaluating Microsoft Copilot for its corporate staff. Initial rollout would cover knowledge management and internal document Q&A, with later expansion to customer-facing applications.

CPS 234 considerations: Even for internal use, the bank's confidential documents would flow through Copilot. Provider assessment, control validation, and incident response planning are all required at scale.

CPS 230 considerations: Microsoft becomes a material service provider for an even broader range of services than it already is. Concentration risk in Microsoft would increase significantly.

Alternative: Hybrid approach — Copilot for low-sensitivity productivity tasks (calendar, basic document help) and on-premises AI for any work involving confidential bank or customer information. This minimises compliance overhead while preserving the productivity benefits where they exist.

Scenario 3: Super Fund Deploying AI for Member Communications

A superannuation fund wants AI assistance for drafting member communications, summarising regulatory updates, and answering staff questions about complex member situations.

SPS 232 considerations: Member data handling is heightened; cross-border processing of member information is increasingly difficult to justify.

CPS 234 considerations: Member information is highly sensitive; controls must match sensitivity.

Alternative: On-premises private AI with the fund's policy library and (carefully governed) anonymised member case data. Full compliance with the data risk management framework.

The Practical Path Forward

For most APRA-regulated entities, the answer to "AI: cloud or private?" depends on the sensitivity of the data involved:

The trend across regulated entities is to deploy private AI for the medium-and-above sensitivity workloads while keeping cloud AI for purely productivity-side tasks. This minimises compliance overhead while capturing AI productivity benefits.

The AIRGAP LLM Perspective

AIRGAP LLM deploys private AI systems for Australian financial services firms — banks, insurers, brokers, wealth managers, and superannuation entities. Every deployment is designed around CPS 234 and CPS 230 compliance:

• On-premises infrastructure within the entity's controlled environment
• Open-source models with no foreign vendor dependency (no material service provider relationship to manage)
• Comprehensive audit logging for CPS 234 demonstration
• Integration with the entity's existing security and IT governance
• Documentation aligned with APRA's information security expectations

For APRA-regulated entities evaluating private AI deployment, we offer a confidential initial consultation including a compliance overhead comparison for your specific situation.

Contact AIRGAP LLM to discuss private AI for your regulated entity.

Frequently Asked Questions

Does APRA CPS 234 apply to AI tools?

Yes. CPS 234 (Information Security) applies to any information asset of an APRA-regulated entity, including the data that flows through AI tools. When an AI tool processes regulated information — customer data, financial records, sensitive operational data — the security obligations under CPS 234 apply to the AI system and its data flows. This includes cloud AI services that process information on behalf of the entity.

What does CPS 234 require for third-party AI providers?

Paragraph 17 of CPS 234 requires regulated entities to evaluate the information security capability of third parties that manage their information assets. For cloud AI providers, this means assessing the provider's security posture, ensuring contractual obligations align with the entity's security requirements, and maintaining the ability to demonstrate compliance to APRA. The entity remains accountable for information security regardless of third-party arrangements.

How does CPS 230 (Operational Risk) interact with AI?

CPS 230, effective from 1 July 2025, requires regulated entities to identify and manage material service providers. A cloud AI provider used in core operational workflows is likely a material service provider, triggering CPS 230's requirements around concentration risk, exit strategies, and operational resilience. Combined with CPS 234, this creates significant compliance overhead for cloud AI use that on-premises deployment avoids.

Can private/on-premises AI satisfy CPS 234 more easily?

Yes. On-premises AI deployment keeps information assets within the entity's controlled environment. This reduces the third-party risk surface (CPS 234 para 17 considerations are minimised), simplifies the security control framework (the entity controls all security measures directly), and provides auditable evidence of compliance. For most regulated entities, on-premises AI is the path of least compliance resistance for sensitive AI workloads.

What about APRA's information security guidance on AI specifically?

APRA has issued increasingly direct guidance on AI risk, including the CPG 234 (Information Security Guidance) and CPG 230 (Operational Risk Guidance) publications, plus periodic insights papers on technology risk. APRA's general position is technology-neutral but emphasises that AI does not change the entity's underlying obligations — it changes the risk surface that those obligations apply to. Entities are expected to apply existing prudential standards to AI deployments with the same rigour as other technology decisions.