APRA Asked for an Inventory. Have One That Counts.
APRA's 30 April letter to industry got two big things right. The harder ask sits in one line about inventory that most readers will read past, and it's where the work actually is.
Most APRA-regulated entities can't currently answer the question APRA just asked.
On 30 April 2026, APRA wrote to every regulated bank, insurer and superannuation trustee in Australia and asked: do you actually know what your AI is doing?
We've read the letter twice. Two things in it the industry will spend the next quarter agreeing with. A quieter point about inventory most readers will skim past. If you're the person inside your org responsible for the safe deployment of AI tooling, the inventory point is your problem.
What APRA got right (1): point-in-time audits don't fit adaptive systems
The strongest line in the letter calls out a "reliance on point in time and sample based assurance methods, despite these methods being ill suited to probabilistic models." That is right, but it stops short.
The probabilistic nature of the model is only half the reason point-in-time audits fail. The other half is that the actual use of the tool differs materially by user and evolves rapidly. Two teams given the same coding agent will integrate it into different systems, grant it different access, and take on materially different risk. A month later, both will have changed shape again. What you see when the tool comes in is not the risk you live with.
The audit you ran in March is a fact about March. The model has moved since, and so have the integrations people have built around it. Neither is a bug; both are how AI tooling actually lands in an organisation.
Most assurance functions are still structured around assets, not behaviours. That breaks the moment your asset is non-stationary. It breaks twice when every user is reshaping it. APRA is, politely, telling you to stop relying on those historical assumptions.
Inventory is the right word; tools are the wrong unit
APRA expects entities to "maintain an inventory of AI tooling and AI use cases." That instruction will be taken at face value, and most of the resulting registers will list tools. The tool is rarely the unit of risk.
Consider Claude Cowork in the hands of your finance team versus the same product in the hands of your HR team. Same vendor, same SKU, one line in the register. The data is different, the downstream actions are different, the blast radius if something goes wrong is different. The risks are different and the controls have to be separate. A row that reads "Claude Cowork: approved" tells your assurance function very little about either deployment.
Unlike most of the traditional IT estate, the end users of an AI tool materially shape what the tool actually does. The capabilities visible at procurement are an upper bound. The capabilities in flight are whatever each team has wired up: the connectors, prompts, workflow integrations, and data they feed it. A centralised function asking once a quarter is not well-equipped to produce a statement of fact about that surface, because the surface is being built and rebuilt by users every week.
We've heard, from more than one AI team, that a complete catalogue of AI tools is, in their view, the answer to APRA's challenge. It isn't. The tool is not the abstraction that carries the risk; the agent in context is.
Three reasons the tools-list approach decays under contact with reality:
- Agents are being created faster than they are catalogued. A new MCP server, a new Cursor workflow, an n8n job, an internal tool wrapped in an LLM call. Every one of these is an agent. None of them route through your AI council.
- The unit of risk is the agent, not the tool. The same tool in two teams produces two different risk surfaces. Auditing the tool tells you almost nothing about either.
- The picture decays. Last month's inventory is already wrong. Models update, scopes drift, integrations multiply.
This is also why point-in-time audits fail: they assess a tool when the thing carrying the risk is the agent. A static register of tools satisfies the letter of APRA's expectation and falls short of the intent of every other paragraph in the same document. The parts about adaptive behaviour, supplier opacity, integrated assurance, and continuous monitoring.
What APRA got right (2): boards must oversee AI, without becoming technologists
APRA wants directors who can "effectively challenge management on AI risks." Good. "AI literacy" is being read by many as technical literacy. It is not the same thing.
Boards don't need to be technical. They need to understand enough about how agents behave (what they reach, how autonomous they are, what stops them when they're wrong) to know when a management answer is real versus a confident-sounding non-answer. As above, that means seeing the agent in context, not the tool. A board briefed on tools rather than agents is being handed the wrong map and will, in good faith, ask the wrong questions.
What this looks like done properly
Done well, the operating model has three parts:
- Continuous agent discovery across code, CI/CD, cloud and SaaS. Not a survey, not a self-attestation, not a CMDB extract.
- A risk profile per agent, not per tool. We use GRASP (Governance, Reach, Agency, Safeguards, Potential damage), because it is the smallest set of dimensions a non-technical director can reason about and a technical team can measure.
- An oversight surface boards can actually use: agent-level evidence, expressed in behaviour terms, that a director can challenge without learning Python.
Done well, this is also the answer to APRA's harder ask: integrated assurance across cyber, data governance, model performance, resilience, privacy and conduct. You cannot integrate assurance across six functions if each function holds a different list of "AI things." You integrate by pinning everything to the agent.
If you're an APRA-regulated entity
We built ARIS for exactly this problem. It deploys inside your environment (no data egress), discovers the agents you already have, and produces an APRA-shaped picture of your AI estate: agent-by-agent, with GRASP risk profiles and a defensible audit trail.
If you want to know how your current AI footprint would read against APRA's expectations, we run a two-week pilot that ends with an executive-ready gap assessment.
References
- APRA calls for a step change in AI-related risk management and governance (30 April 2026 announcement)
- APRA letter to industry on artificial intelligence (AI) (full letter)
- Get a GRASP: A 5-Part Framework for Agent Risk (the framework referenced above)