AI governance under APRA's expectations

APRA expects regulated entities to govern AI with a framework and reporting lines, an inventory of AI in use, named owners for each system until it is retired, human involvement in high-risk decisions, staff training, visibility over the AI supply chain, and security and assurance (checking that controls actually work) that continue for as long as a system runs. It treats all of this as work CPS 230 and CPS 234 already require. This guide takes each of APRA’s expectations in turn and sets out what it means in practice for a bank, insurer or superannuation trustee. The detail of the letter itself is on the framework page.

The inventory expectation

APRA asks for an inventory of AI tooling and AI use cases. It also observed staff using enterprise AI tools outside approved control frameworks. That observation matters more than the expectation, because it tells you where supervisors are looking. They are finding AI in use that risk functions cannot account for, from vendor decisioning platforms to AI features switched on inside software the entity already runs.

In practice the inventory is a register of every AI system and agent, each with a named owner and a status such as proposed, live or retired, with version history as systems change. A list assembled once for the letter fails the expectation as soon as a new tool arrives. The register has to be the working record, and it has to be fed by discovery across the places AI turns up, not only by what project teams declare.

Ownership from design to retirement

The ownership expectation runs from design to decommissioning. The test a supervisor applies is simple. For any system, who is accountable for it now, and did that accountability survive the project team disbanding? Ownership written into a business case and never updated fails that test. Ownership held on the system’s register record, with its history kept as people move, passes it. Decommissioning needs the same care, because a retired system should leave a record of when it stopped and who decided.

Human involvement in high-risk decisions

APRA expects humans involved in high-risk decisions. The governance work has two parts. You need to know which systems make or contribute to such decisions, and you need to show where the human sits in each. That is a property of the register and the assessments rather than a policy statement. Record each system’s outputs, whether it affects individuals and its level of human oversight, then have the assessment describe the oversight as it actually operates.

Staff training

The letter expects staff training on AI use, misuse, limitations and secure practices. Treat it as a record, not an event. Know who is assigned which course, who has completed it and whose completion has expired. The AI literacy guide covers how to match training to role.

Visibility over the AI supply chain

Most AI risk in a regulated entity arrives through vendors. APRA asks entities to map the full AI supply chain, including third and fourth parties, to hold contracts that give transparency, auditability and assurance over model behaviour and material changes, and to manage concentration risk with credible exit and substitution plans. Start from the register. Every system in it names the company behind it, so the list of vendors that need due diligence follows from what you run. The vendor AI risk guide covers due diligence and contract terms.

Security and checking that keeps running

APRA found point-in-time, sample-based assurance ill suited to models that learn, adapt and degrade. It expects risk and security assessments before deployment and throughout a system’s life, change control for AI and continuous monitoring proportionate to each use case’s criticality. It also flagged identity and access management that has not caught up with non-human actors such as AI agents.

In practice that means an assessment that runs again when a system changes materially, security testing such as red teaming against the real deployment, and monitoring that raises an alert when a tracked figure crosses a limit you set. Agents need their own identities on the record, so access can be reviewed and revoked like any other.

Where this meets your prudential processes

A regulated entity already runs a risk platform, a service provider register, critical operations mapping, incident management and board reporting. The AI work does not replace any of it. What the register and assessments produce should feed those processes, with risks and controls going to the risk platform, vendors to the provider register and incidents to incident management, so your teams keep working where they always have.

Where Aicura fits

Aicura’s AI Register holds every system and agent with three owner roles and their history, a status for each system through to Retired and a version for every material change. Discovery reads sources such as device management tools, code repositories, cloud inventories and IT asset registers, and surfaces AI in use that is not yet on the register. Risk assessments start when a system is registered and run again on material change. At Pro, impact assessments, vendor records with contracts and a list of register vendors that have no record yet, security testing, monitoring and training records sit on the same system records.

For the prudential side, Pro incidents include OAIC, APRA and ASD notification pathways, risks and controls can be copied across to ServiceNow GRC, and webhooks (automatic event messages) carry events to your security monitoring (SIEM) and prudential process feeds. Aicura gives guidance for your own judgement. It does not certify, audit or issue a verdict on your prudential obligations.

A note on this page

APRA’s letter is the primary source and this page is a practitioner’s reading of it, not legal or prudential advice. How the expectations apply is a matter between your organisation, its advisers and its supervisor. Read the letter itself on APRA’s website and treat this page as a map of the work rather than an opinion on your obligations.