Part 2 of 3 — A practical view on getting Gen AI through internal risk gates and into production.
TL;DR: AI governance for risk and compliance teams is the focus of Part 2 in this series. In Part 1 we covered how to build trust with the users and owners of an AI system. Part 2 is about the second audience: internal risk, compliance, security and legal teams. Their job is to assume something will go wrong and ask whether you would know about it, contain it, and explain it. Build for them properly and they become the reason your AI program scales rather than the reason it stalls. That means clear policy and standards, a workable risk rating framework, real observability, lifecycle ownership, and reporting your board can engage with.
Table of Contents
Risk and compliance teams are not the enemy
In Part 1 we looked at how to design AI Agents that the users and owners can trust. That is only the first layer. The next gate is your internal risk and compliance teams, and if you have ever worked in financial services, you know they hold the keys to production.
I have heard plenty of teams talk about risk as if it is an obstacle. It doesn’t have to be. Risk teams have one job: assume something will go wrong, then ask whether you would notice it, contain it, and explain it after the fact.
If you can answer those three questions credibly, they will sign you off. If you cannot, no policy document or executive sponsor is going to save you. You want to shift the conversation from roadblocks to guardrails.
APRA is already treating AI as an operational risk issue
In April 2026 APRA published a letter to all regulated entities laying out what it had found across a targeted engagement with banks, insurers and superannuation trustees during 2025. It was blunt. AI systems are being deployed without inventory. Lifecycle ownership is unclear. Post-deployment monitoring is weak. Decommissioning processes are largely absent.
That letter is not a discussion paper. It is a description of where your risk team is currently sitting, and existing standards like CPS 230 (Operational Risk Management) and CPS 234 (Info Security) already apply to AI as it stands today.
Why risk teams become your AI accelerators
Here is the bit teams miss. A risk team that trusts your platform becomes the fastest path to scale, because the marginal cost of approving the next AI use case drops dramatically once they trust the foundations you have built. Reaching that point takes four things working together.
Governance must be built into the platform
Strong AI governance is not a single control or approval gate. It’s policy, observability, lifecycle management, operational controls and accountability working together as a system. The organisations scaling AI successfully treat governance as part of the platform architecture, not as a compliance process bolted on afterwards.
The four elements below; policy and standards, risk rating, observability and inventory, and board reporting, are how that system gets built.
Building trust with internal risk and compliance teams
An AI Policy and Standards That Actually Drive Behaviour
The starting point is a written AI policy that everyone in the business has read, and a set of standards that sit underneath it.
The policy is the short, principles-based document: what AI we will and will not use, who can approve it, what data can go into it, who is accountable when something goes wrong.
The standards are the operational layer: how we evaluate models, what minimum guardrails apply to every deployment, how we test for prompt injection, how we manage third-party AI vendors under CPS 230, etc.
The Australian Government’s Voluntary AI Safety Standard gives you ten guardrails that map well to a policy of this kind. ISO/IEC 42001 gives you a more formal AI management system if you want to certify against an external standard, and for APRA-regulated entities it maps directly to CPS 230 and CPS 234.
Whichever framework you reach for, what matters is that the document is real, current, and tied to actual controls. The PDF in SharePoint that nobody enforces is worse than not having a policy at all, because it gives the risk team something to point at when things break.
Rating AI risk use case by use case
Not every AI system carries the same risk and treating them as if they do is how you end up bottlenecked at the risk committee with thirty pilots in the queue.
Practical dimensions for AI risk classification
A workable internal risk rating framework rates each use case on a few practical dimensions:
- Decision impact on customers — does the agent affect a customer outcome?
- Regulated activity proximity — is it operating in or near a licensed activity?
- Data sensitivity — what data does it see and store?
- Autonomy of action — does it act on its own, or recommend to a human?
- Reversibility — if it gets it wrong, how hard is it to unwind?
A low-risk internal productivity tool gets a light-touch review. A customer-facing agent that influences a credit decision goes through the full stack: model validation, bias testing, fallback design, human-in-the-loop controls, board awareness.
The Senate Select Committee on Adopting AI and the government’s mandatory guardrails consultation both point in the same direction: high-risk AI deserves more scrutiny than low-risk AI. Get this hierarchy working internally and you stop wasting cycles on the easy stuff.
Observability, inventory and lifecycle ownership
This is where most organisations are weakest right now, and it is where APRA was most direct. The fix is not glamorous:
- A registered inventory of every AI system, every model version, every prompt template, with a named owner and a clear lifecycle stage.
- A full audit trail of every interaction with the agent — prompt, retrieved context, intermediate tool calls, model used, response generated, latency and cost.
- Automated evaluation running against a ground-truth dataset on a schedule, so you can catch drift before a customer does, with alerting when something breaks tolerance.
- A decommissioning process for when an agent stops working or the use case goes away. Models no longer in active use are still in your risk footprint.
The technology is easier than the discipline
On AWS, you can build a lot of this natively with CloudWatch, OpenSearch and Bedrock Model Evaluation. If you are operating multi-cloud, you will need cross-platform tooling like Holistic.ai or Credo.ai. The technology is the easy part. The hard part is the discipline of keeping it current.
When your risk team can ask “show me everything Claude said about superannuation last Tuesday” and you can hand them a clean log within minutes, you have fundamentally changed the relationship.
Board-level reporting and personal accountability
One piece that is easy to miss. Australia’s Financial Accountability Regime (FAR) is now fully in force for banks, insurers and superannuation trustees. It introduces personal liability for senior executives — CEOs, CROs, CTOs and board directors face large penalties individually for failing to take reasonable steps to prevent breaches.
APRA’s letter was also clear that many boards still lack the technical literacy to provide effective challenge on AI risk.
Translating AI risk into the language a board can act on, risk appetite, control effectiveness, residual exposure, is now part of the job. The teams I have seen do this best build a quarterly AI risk pack covering the inventory, the use case ratings, model performance against ground truth, incident summaries, and changes in the regulatory landscape.
Boring on the surface. Career-saving when something goes wrong.
Why risk and compliance teams determine whether AI scales
Here is the pattern I keep seeing. Teams that treat risk as an adversary stall at one or two production AI systems and never get past it. Teams that bring risk in early, build the policy and observability up front, and run regular check-ins, end up with platforms that approve new use cases in weeks rather than quarters.
Your risk team does not want to slow you down. They want to spend their attention where it matters. Give them the inventory, the audit trail and the evaluation data, and they will spend their attention on the genuinely risky stuff and wave the rest through.
For risk and compliance teams, AI governance becomes credible when observability, auditability, lifecycle management, and operational controls are embedded directly into the platform.
The organisations succeeding with AI in regulated industries are not the ones avoiding governance. They are the ones operationalising it early enough that risk teams become enablers rather than gatekeepers. Trust at scale comes from proving you can monitor, explain, and control these systems continuously, not just at deployment time.
Effective AI governance for risk and compliance teams is ultimately about operational confidence — proving that AI systems can be continuously monitored, controlled, audited, and explained as they scale.
What’s next: Earning the regulator’s confidence
Building trust with internal risk teams gets you to production. The third and final audience is the one waiting outside the door — the regulators. APRA, ASIC, OAIC, AUSTRAC. They are not asking the same questions as your risk team, and they will not be satisfied with the same answers.
In my last blog of this series, I will cover how to design AI systems that hold up to regulatory scrutiny: robust guardrails, prompt injection defence, shadow AI management, and how all of this maps to the patchwork of Australian and international regulations now in force.
FAQ’s
Why are AI projects approved by risk teams more likely to scale?
Because a risk team that trusts your platform reduces the marginal cost of approving each new use case. Once the policy, observability and lifecycle controls are in place, every additional agent rides on the same approved foundation rather than going through full scrutiny on its own.
What does APRA actually expect for AI governance in 2026?
APRA’s April 2026 letter named four specific failures it is seeing across regulated entities: AI deployed without inventory, unclear lifecycle ownership, weak post-deployment monitoring, and absent decommissioning processes. Existing standards like CPS 230 and CPS 234 already apply to AI — APRA’s position is that these obligations are current, not emerging.
Do I need ISO 42001 certification to manage AI risk?
No, but it helps. ISO/IEC 42001:2023 is the international standard for AI Management Systems and maps directly to APRA’s CPS 230 and CPS 234. It is not mandatory, but it gives your risk team and your auditors a structured framework to assess against, which often shortens the time to internal sign-off.
What should a useful AI inventory actually contain?
Every AI system, every model version, every prompt template, with a named business owner, a lifecycle stage (pilot, production or decommissioned), a risk rating, and a link to the audit trail and evaluation data. Without this, you cannot answer the basic questions a regulator or board will ask.
How does the Financial Accountability Regime affect AI decisions?
FAR is now in force for banks, insurers and superannuation funds, with personal liability for accountable persons who fail to take reasonable steps to prevent breaches. AI decisions sit on someone’s personal accountability statement, which changes how seriously the board and executive engage with AI risk reporting.
Jeff is a senior technology and transformation executive with 25+ years of experience delivering large-scale Data+AI programs across global banking and financial services to drive real, measurable business value. Jeff has founded and scaled enterprise AI accelerator capabilities and established federated delivery models to enable safe, scalable AI adoption, and his focus is on accelerating the journey from AI strategy to production delivery. He has led the delivery of multiple production-grade generative and agentic AI solutions, including multi-agent platforms for financial markets users, Sales and Trader Assistants that generate real-time insights, and AI agents that automate regulatory and trade booking compliance, embedding AI directly into day-to-day workflows.
