Key Takeaway
When AI supports a critical operation, the Australian Prudential Regulation Authority (APRA) standard CPS 230 expects a credible continuity plan, and that plan is only as credible as the transparency behind it.
The Bottom Line Upfront (BLUF) - (Moderate Confidence)
In every organisation there is an org chart on paper and there is also the way things actually get done. APRA’s Operational Risk Management standard (CPS 230) will be met or failed in the gap between the two. Only organisations whose Board and executive visibly back the standard will fund the transparency needed to close it.
CPS 230 is APRA's binding standard on operational risk for banks, insurers and super funds. It never mentions AI. APRA's April 2026 letter to industry applied it to AI. Where AI supports a critical operation, the standard's requirements for continuity, fallback and supplier management apply in full.
Credit where it's due
APRA's operational risk standard, remade this year and in force since 1 July, is a well-built piece of regulation. It treats operational risk as more than an ICT problem. It recognises that ownership is distributed across an organisation while accountability still rests with the Board. Two provisions stand out. Paragraph 39(e) requires a communications strategy to support execution of the continuity plan. Engagement has been a common feature in the failures I have observed. Without clear ownership and endorsed direction, silos will form and keep running in their own self-interest. Paragraph 44 requires the plan to be updated each year for changes in organisational structure. While this shows real foresight, it also shows where paper and practice part company.
When the loop broke
I once watched a small data science capability slowly degrade, in my judgement, after a restructure absorbed it into a central area.
When it worked, it was a handful of experienced people focused on one thing: building, maintaining and assuring a single system. There was one reporting line. The team was owned, funded and supported by the business area it served, and it owned the whole data science lifecycle. Because the domain paid for them, they built domain expertise, had access and built relationships with the people using the system. They got raw feedback from users and could see what the model recommended and what the human decision-makers did with it. On paper the capability was fragile, held together with sticky tape and glue, working on a hodgepodge of systems and equipment that were tolerated rather than approved by the organisation's technical and compliance areas.
In practice it held, because the frontline business area treated the team, its successes and weaknesses as its own. As a critical function of the organisation the business area had substantial political capital it used prudently to procure the necessary resources, approvals and exemptions to get things done. Exciting and novel. It was a pioneering success with a little ‘skunkworks’ in its DNA and an unsustainable talent pool. That was great for moving fast and getting things done in the short term, but less suited for the boring work of making formerly novel analytics a normal part of business.
Well-meaning managers with fresh resources wanted to mature the capability, improving technical architecture, expanding its results and successful approaches more widely. Responsibility and the team moved to a central area. Nothing broke immediately. Top specialist talent departed for new challenges and well-deserved promotions. Over weeks and months other key people drifted back to the business area. Funding for some positions wasn't maintained beyond the financial year, because the sustainment reality wasn’t fully reflected in due diligence. The business area had once argued for the team's budget as its own. Now it saw the capability as baseline and expected the central area to find the money.
Gates and their keepers formed at both ends of the lifecycle. The business area became the intermediary between the data scientists and the users, so the raw feedback stopped. At the other end, the remaining data scientists lost sight of their own results. They could not tell you what their model had recommended yesterday, or which recommendations people had acted on. New members of the data science team never got the opportunities to meet and build relationships with end users, so domain knowledge regressed.
None of this needed bad actors. The issues were structural. The system rewarded headcount. Large modern organisations run by humans are predisposed to creating silos. FTE is what lets an area do work, win funding and continue to exist. The business area was freed from responsibility for a capability it no longer owned. Every player involved, from data and finance to ICT, business and policy, responded rationally to the incentives in front of them.
So nobody noticed, because senior management stopped asking for the metrics the original team used to provide. Nobody was told, because blaming the transfer was an easy answer to pass up the chain. Nobody could do the work, because relationships with users had gone opaque. And nobody cared about results, because the loop was never closed or improved. Whether it ultimately failed, nobody can say. The data that would answer the question stopped being collected.
Updating the plan after each restructure, as paragraph 44 requires, would have changed nothing. The plan would have described the org chart. The capability was degrading in the way things actually got done.
Sunlight
What would have fixed it was sunlight. Daily, weekly or monthly statistics linked to every production model, showing what the model recommended and how often the human decision-maker agreed, would have held everyone accountable to results. The same data would have given the business area material for integrity and assurance over individual cases.
The numbers are only half of it. The people at the frontline hold the real risk knowledge. With their domain expertise they can see when things are changing and not quite right, often before any metric moves. Sunlight means interviewing and engaging them regularly and treating what they say as evidence. That is a different thing from the green, amber, red traffic lights a board receives in its quarterly meetings.
Where the standard's pressure lands
Paragraph 19 makes the Board ultimately accountable, and paragraph 21(a) requires it to receive regular updates on the operational risk profile. In practice a board sees a summary grouped to ease the reporting burden. What rarely reaches it is an honest, evidenced account of what is going wrong, particularly where the culture doesn't reward bad news. Last edition argued that when everyone is responsible, nobody is. This is where it lands.
The people who hold the real risk knowledge are also where savings are sought, especially through automated decision-making aimed at reducing headcount.
Paragraph 43 requires testing against severe but plausible scenarios. A predecessor and mentor of mine used to say that battleships decided naval warfare in the First World War and aircraft carriers decided it in the Second. A continuity plan written by middle managers and compliance staff responds to what they have seen before. The better exercise brings multidisciplinary teams from every level of the organisation into workshops or hackathons to imagine what could happen. The scenarios may never come true. They will expose common weaknesses.
Assurance under paragraph 45 comes from internal audit, which is often run on a shoestring: well-meaning generalists without the specialist skills or the political backing to open the necessary doors.
Capital, not capacity
Where APRA finds material weaknesses, paragraph 18(c) lets it require an entity to hold additional capital. That is money held against losses, not money spent fixing the weakness. I would rather see investment directed at the assurance infrastructure itself: trained data and AI stewards distributed across the organisation, red-teaming and scenario exercises where appropriate supplemented by external expertise, and modernisation of the systems that cannot produce the data. The best exercises I have seen drew on a curated list of external specialists from a range of sectors.
The alternative view
The strongest counter-argument is that a regulator doesn't know the commercial realities of innovation, and prescribing spending adds overhead that could damage the very systems it wants to protect. Paragraph 40 already goes some way: entities must maintain the capabilities to execute the plan, including people, resources and technology. It covers the point, but it isn't watertight, because a plan can be executed with the bare minimum. AI changes the calculation. It is a learning capability, and behaviour may change over time. Its results shift as its data shifts and every time a vendor upgrades a model. Organisations that use it have to become learning organisations, and that takes sustained investment in the people who watch it.
What to Watch
Over the next six months, watch hiring. A serious bank will be recruiting data and AI governance officers and investing in custom AI tradecraft tied to its own business, rather than generic governance theory. Watch procurement, and whether AI governance becomes a gate and a line item in modernisation projects. And watch APRA's forward plan for AI supervision, for whether it addresses the capacity to execute or only the controls on paper.
Close
The key challenge for every organisation, APRA-regulated or not, is keeping the org chart on paper and the way things actually get done as close together as possible.