APRA AI Guidance: What the 2026 Letter Means for Banks, Insurers and Their AI Vendors

Short answer: APRA's AI guidance is a letter to all APRA-regulated entities dated 30 April 2026. It says AI governance has not kept pace with adoption and expects stronger board literacy, AI inventories, human oversight of high-risk decisions, AI-specific security controls and tighter supplier management. Vendors selling AI to these entities should expect deeper due diligence and new contract clauses.

Related guides:

• APRA CPS 234 checklist
• Enterprise AI governance
• How to write an AI governance policy

Key takeaways

• APRA published its letter to industry on artificial intelligence on 30 April 2026, addressed to all APRA-regulated entities: banks, insurers and superannuation trustees.
• The letter does not create a new prudential standard. It states that existing prudential standards already apply to AI risk, and that few entities have operationalised governance in practice.
• Expectations cover board literacy, information security, governance maturity, supplier risk management, and assurance and change management.
• For vendors, supplier risk matters most: entities must map the full AI supply chain, including fourth parties, and secure terms on audit rights, model updates, incident notification and data handling.
• Vendors with an AI inventory, model change logs, AI security testing and exit support will move through procurement faster.

---

What is APRA's letter to industry on artificial intelligence?

It is a supervisory letter dated 30 April 2026 that sets out what APRA found when it looked at AI adoption and what it now expects. The letter is published on apra.gov.au and is addressed to all APRA-regulated entities.

The letter follows engagement APRA conducted in late 2025 with a group of selected large banks, insurers and superannuation trustees. Its central finding is a gap between adoption and control. APRA found that most entities accept their prudential obligations already extend to AI risk, yet few have turned that into working governance.

Several observations in the letter are directly about vendors. APRA noted:

• Overreliance on vendor material, such as vendor presentations and summaries, without sufficient examination of key AI risks.
• Concentration on single providers across multiple use cases.
• Weak contracts, with few specific provisions on audit rights, model updates, incident notification or data handling changes.
• Opaque upstream dependencies, such as foundation models and training data.
• Untested exits, with few entities showing tested exit and substitution strategies.

On status: the letter describes APRA's prudential framework as principle based and neutral about which technology or vendor an entity uses, so the letter sets expectations rather than new rules. APRA says it is finalising its forward plan for supervising AI risk and will take stronger supervisory action and, where appropriate, pursue enforcement where entities fail to manage AI risk. The letter sets no new compliance deadline, but existing prudential standards already apply.

What does APRA expect from regulated entities?

APRA expects boards to understand AI well enough to challenge it, and expects executive management to lift controls across security, governance, suppliers and assurance. The table below is our paraphrase of the letter, not an exhaustive list.

Area	What APRA said
Board	AI literacy sufficient to set direction and challenge management. An AI strategy aligned with risk appetite, including third-party dependency monitoring and defined resilience triggers.
Information security	Credible fallback processes for AI reliance. Controls for AI-specific attack paths, including privileged access management, patching, hardened configurations and controls over autonomous workflows. Testing of AI-generated code and libraries. Identity and access management for non-human actors such as AI agents.
Governance maturity	AI policy and standards. Ownership across the AI lifecycle, from design to decommissioning. An inventory of AI tooling and use cases. Human involvement for high-risk decisions. Staff training.
Supplier risk management	Visibility over the full AI supply chain, including third-party and fourth-party dependencies. Contracts giving transparency, auditability and assurance, including insight into model behaviour, material changes and performance issues. Substitution and exit planning for critical providers.
Assurance and change	Recognised control frameworks with AI change controls. Integrated assurance across cyber, data, model risk, resilience, privacy and conduct. A technically capable second line. Monitoring before deployment and through the lifecycle, proportionate to criticality.

The letter names the attack pathways APRA is concerned about: prompt injection, data leakage, insecure integrations, exploit injection, and misuse of autonomous AI agents. It also flags model drift and bias, and questions whether point-in-time, sample-based assurance is enough.

For the internal framework side, see ISO 42001 for AI risk management.

How does the AI letter connect to CPS 230, CPS 234 and CPS 220?

The letter does not name specific prudential standards, but it says existing standards apply to AI, and the obvious candidates are CPS 230, CPS 234 and CPS 220. Law firm HWL Ebsworth's summary of the letter reads it the same way: the firm, not APRA, names CPS 230 and CPS 234 among the existing requirements that apply to IT services leveraging AI. The mapping below is our interpretation, not APRA's text.

CPS 230 Operational Risk Management. CPS 230 sets out how entities manage service providers, including the fourth parties their material service providers rely on. APRA's CPS 230 page has the current text of the standard. In that text, paragraph 48 says entities must classify providers of "risk management, core technology services and internal audit" as material service providers "unless it can justify otherwise". Agreements with material service providers must cover service levels, audit access, termination and APRA's access to documentation. If your AI product supports a critical operation such as claims or credit assessment, your customer may treat you as a material service provider.

CPS 234 Information Security. Where a third party manages an entity's information assets, CPS 234 requires the entity to assess that party's information security capability and to consider the testing the third party performs. Entities must notify APRA of material information security incidents no later than 72 hours after becoming aware of them, which is why customers push incident notification clauses down to vendors. Our APRA CPS 234 checklist covers the requirements in detail.

CPS 220 Risk Management. CPS 220 requires a board-approved risk management framework, risk appetite statement and risk management strategy. It applies to ADIs and general, life and private health insurers. Superannuation trustees are covered by the equivalent SPS 220. The letter's call for an AI strategy aligned with risk appetite sits naturally inside this framework.

What will AI vendors face in due diligence and contracts?

Expect AI-specific questions on top of your usual security review, and contract clauses aimed at the gaps APRA called out. The following is our practical view, not a statement of APRA requirements.

Due diligence questions are likely to cover:

1. Which models power the product, who provides them, and where they are hosted.
2. Whether customer data is used to train or fine-tune models.
3. How you test for prompt injection, data leakage and insecure integrations.
4. How AI agents and service accounts are scoped and logged.
5. How model updates are approved and communicated, and how drift is detected.
6. What happens to service and data if you or your model provider fail.

Contract clauses are likely to include:

• Audit and information rights, including APRA access where you are a material service provider.
• Notice of material model changes, deviations and performance issues.
• Incident notification fast enough for the customer to meet its 72-hour CPS 234 obligation.
• Disclosure of subprocessors, including foundation model providers.
• Limits on training with customer data, plus return and deletion on exit.
• Termination and transition assistance to support exit planning.

HealthTech vendors should note that private health insurers are APRA regulated. A HealthTech product used in claims, member services or benefit management may face these questions alongside privacy and health data obligations.

Which evidence maps to each APRA expectation?

The fastest way through review is to answer each expectation with an artifact the customer can file. This mapping is our recommendation of practical evidence. APRA does not prescribe these documents. Note that SOC 2 and ISO 27001 reports cover general security and contract assurance, not model behaviour; model-specific risks need the AI artifacts in the other rows.

APRA expectation (from the letter)	Evidence a vendor can provide
Visibility over the full AI supply chain, including fourth parties	AI bill of materials listing models, providers, hosting regions and AI subprocessors
Contracts providing transparency, auditability and assurance	AI contract addendum; independent audit report such as SOC 2 or ISO 27001
Understanding model behaviour, material changes and performance	Model documentation, model change release notes, drift monitoring summaries
Controls for AI-specific threats and attack paths	AI threat model, prompt injection and adversarial test results
Testing of AI-generated code and libraries	Secure SDLC policy, code review and dependency scanning evidence
Access for non-human actors such as AI agents	Agent permission model, scoped service accounts, audit logging
Human involvement for high-risk decisions	Documentation of human-in-the-loop and override controls
Inventory of AI tooling and use cases	List of AI features with purpose, data inputs and limitations
Substitution and exit planning	Exit plan, data export formats, continuity and recovery test results
Recognised control frameworks and change control	ISO 42001 or ISO 27001 certificate, AI change procedure
Continuous lifecycle monitoring	Periodic reports on model performance, incidents and control testing

Vendor readiness checklist

Use this before your next sales cycle with an Australian bank, insurer or super trustee. It reflects our recommendations based on the letter and the related prudential standards.

Governance

• AI policy with a named owner for every AI feature
• Staff training on AI use and secure practice, with records

Transparency

• AI inventory and AI bill of materials, including model providers
• Model documentation covering purpose, limitations and failure modes
• Written position on training with customer data

Security

• AI threat model and recent adversarial testing, with remediation tracked
• Scoped, logged credentials for AI agents and service accounts
• Security testing of AI-generated code and libraries

Change and resilience

• Model change process with testing, approval and customer notice
• Drift and performance monitoring with review thresholds
• Fallback mode if the model provider is unavailable
• Exit plan with data export formats

Contracts

• AI contract addendum ready for legal review
• Incident notification that supports a 72-hour regulator deadline
• Audit and access terms, including regulator access where required

How SecureSlate helps

SecureSlate helps SMB and HealthTech vendors prepare for security and AI governance reviews from regulated buyers. You can work with ISO 42001, ISO 27001 and SOC 2 in one control library, track an APRA AI readiness list such as the checklist above as a custom framework, record AI and supplier risks in a risk register, manage your own vendors and subprocessors with vendor risk workflows, and use automated evidence collection from your cloud and SaaS stack. AI-specific artifacts such as model change notes or adversarial test results still come from your own engineering processes. You can store them as evidence against the relevant controls. SecureSlate helps you organise that work, but it does not make a vendor APRA ready on its own: your customers decide what evidence satisfies them.

Start your free SecureSlate trial

FAQ

When was APRA's AI letter published?

APRA's letter to industry on artificial intelligence is dated 30 April 2026. It is addressed to all APRA-regulated entities.

Is APRA's AI guidance a new prudential standard?

No. The letter sets out supervisory findings and expectations. APRA states that existing prudential standards already apply to AI risk and says its framework applies whatever technology or vendor is involved. APRA has said it is finalising its forward plan for supervising AI risk and will consider whether further policy action is needed.

Does the letter apply directly to SaaS vendors?

No. It is addressed to APRA-regulated entities. Vendors feel it indirectly because those entities must manage supplier risk, and APRA specifically called out weak contracts, overreliance on vendor material and limited visibility over AI supply chains.

Which prudential standards does the AI letter reference?

The letter does not cite specific standards by name. It states that the current prudential framework already covers AI. In practice, CPS 230 on operational risk and service providers, CPS 234 on information security, and CPS 220 or SPS 220 on risk management are the most relevant.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.