What APRA means by “assurance” of your AI estate

What APRA means by "assurance" of your AI estate

Assurance is one of those words that survives translation between organisational functions, while quietly changing meaning between them.

Engineers hear “testing.”

Auditors hear “audit.”

Executives hear “someone’s checked it.

But when APRA used that word in their 30 April 2026 letter, it meant something much narrower than any of those.

And that gap – between what the regulator means and what the industry heard – is why most AI programs in Australian financial services can’t currently satisfy it.

Three things that are not the same thing

  1. Testing produces findings. You exercise a system against expected behaviour and learn where it deviates. Testing is bounded by what you thought to test for, which is why it’s necessary and never sufficient.
  2. Audit produces an opinion. An auditor assesses whether a control was designed appropriately and operated effectively over a period, then signs a conclusion. Audit is retrospective by construction, and it depends on the control being the right control in the first place – which, as I argued yesterday, is precisely what breaks at the upper layers of an AI estate.
  3. Assurance produces defensible evidence that a stated risk is being managed within a stated tolerance, attributable to a named accountable person, refreshed at a defined cadence.

Read the definition of assurance again. That’s four requirements in there. And each one can fail independently…

Evidence without a tolerance is a dashboard. A tolerance without evidence is a policy. Both without an accountable name is a working group.

And any of it produced once, at go-live, for a system that changes weekly, is essentially just… theatre.

What APRA actually asked for

The 30 April letter followed a targeted supervisory review conducted in late 2025 across banks, insurers and superannuation trustees.

The finding: assurance practices are not keeping pace with the scale, speed and complexity of AI adoption.

Two of the stated expectations should be read closely. Between them, they define the job.

The first is integrated assurance, applied across cyber security, data governance, model performance risk, operational resilience, privacy and conduct risk.

Six domains. One assurance view.

That rules out the arrangement most entities actually have – where each of those risks is assured separately, by a different function, against a different framework, on a different cycle. And nobody holds the composite picture.

The second expectation is harder to meet.

APRA expects second line risk management and internal audit to have the technical capability and tooling to independently assess AI systems. Including probabilistic models and agentic workflows.

Read that again with your own organisation in mind.

I don’t mean review documentation about the model. Nor to attend a vendor briefing on the model. I mean to independently assess a probabilistic system and an agentic workflow, with the capability and tooling to do it.

Truth be told, I haven’t yet met an Australian second line function that can do this today.

Most internal audit teams have one or two people who could learn it. Almost none have the tooling – because tooling for independently assessing an agentic workflow is barely a product category yet.

The independence problem

There’s a structural difficulty sitting underneath that expectation…

Independent assessment assumes you can inspect the thing.

But AI capability increasingly arrives embedded inside software and platforms you buy. Which constrains how far any entity can genuinely evaluate model performance, bias, resilience or security for itself.

You’re being asked to independently assure a component you cannot open.

APRA saw the consequence of this and named it directly: boards relying on vendor presentations and summaries, without adequate examination of risks like unpredictable model behaviour and the effect on critical operations.

That isn’t board laziness.

It’s what happens when the only available evidence about a component is produced by the party selling it.

Which means assurance at the upper layers has to be built out of things you can observe – behaviour, actions, boundaries, outcomes – rather than things you cannot inspect. That reorientation is a whole methodological shift, and I’ll address it properly later in this series.

The sentence to get right

A lot of commentary on this letter has been imprecise in one of two directions. Both are wrong in ways that matter if you’re quoting them to a board.

The letter did not create new prudential requirements. It’s a letter, not a standard. The obligations still live in CPS 220, CPS 230 and CPS 234, and APRA continues to describe its framework as technology and vendor agnostic.

But it isn’t merely a restatement either.

APRA has now published, observation area by observation area, what those standards mean when applied to AI. And those published expectations are testable. An entity now has a written supervisory yardstick where previously it had a principles-based framework and its own interpretation of it.

So the accurate formulation is this…

What the law requires didn’t change. What a supervisor will accept as evidence that you’ve met it did.

If your AI governance position rests on the framework being principles-based and open to interpretation, sorry but that position closed on 30 April.

APRA also signalled what comes next: proportionate prudential reviews, thematic activities, and direct engagement with AI suppliers, with further policy action if warranted.

The supplier engagement is the part few people have priced in. It means look-through. It means your vendors need to be answering questions about your deployment.

And this is no longer just an APRA conversation. ASIC issued its own open letter to licensees and market participants on 8 May 2026, on cyber resilience in an environment where frontier models compress the margin for error on the fundamentals.

That’s two regulators. Eight days apart. On adjacent problems.

What an assurance artifact looks like

If you take one practical thing from this post, make it about the shape of the deliverable:

  1. An AI assurance artifact states the use case and its criticality.
  2. It states the risk tolerance in terms someone could actually breach.
  3. It names the accountable executive.
  4. It sets out the evidence supporting the claim that the system is operating inside tolerance – drawn from continuous observation, not a point-in-time test.
  5. It records the assessment performed by a function independent of the team that built it, including what that function was unable to assess, and why.
  6. And it carries a review cadence tied to the rate of change of the system, not to the financial year.

That’s six elements.

Few organisations can currently produce all six.

The elephant in the room

Enterprise AI adoption in regulated Australian industries is no longer limited by model capability, engineering capacity, or executive appetite.

All three are abundant.

It’s limited by the inability to produce defensible evidence that a deployed system is operating inside a tolerance somebody has signed for.

That’s an assurance capability gap. It sits in the second line. And it will not be closed by buying another platform.


Sources

About Satheeshan Siva

Continue the conversation.

I write about what emerging technology makes possible and what it takes to make it work inside a real organisation. If you disagree with something here, or want to discuss what it means for yours, get in touch.