I’ve reviewed a lot of AI governance frameworks over the past few years. Beautiful documents. Professionally designed. Full of words like “responsible” and “ethical” and “human-centred.” Most of them are completely useless.
Not because the intentions are bad. The intentions are usually great. The problem is that governance documents don’t change behaviour. Systems change behaviour. And most companies have the document without the system.
The Governance Theater Pattern
Here’s how it typically plays out. The board asks about AI risk. Someone gets tasked with writing an AI governance framework. They spend three months producing a 40-page PDF. It gets presented to the board, everyone nods approvingly, and the PDF goes into a SharePoint folder where it quietly dies.
Meanwhile, the engineering team ships an ML model into production with no review process, no monitoring, and no clear owner. Nobody consults the framework because nobody knows it exists. Or they know it exists but can’t figure out how it applies to the thing they’re actually building.
I’ve seen this at three different organisations. The pattern is remarkably consistent.
Why Documents Fail
Governance frameworks fail for a few specific reasons.
First, they’re written by people who don’t build things. Compliance teams and consultants produce frameworks that read well but don’t map to how software actually gets built and deployed. There’s a section on “ensuring fairness” but no guidance on what statistical test to run, what threshold to use, or who reviews the results.
Second, they try to cover everything. A 40-page document that addresses every possible AI scenario is too long for anyone to read and too vague to be useful for any specific situation. When everything is a priority, nothing is.
Third, they’re static. AI governance gets written once and reviewed annually. But AI systems change weekly. A governance framework that doesn’t account for the pace of development is governance in name only.
What Actually Works
After building governance processes at both Westpac and Cochlear, I’ve landed on an approach that’s less impressive on paper but far more effective in practice.
Embed governance into existing workflows. Don’t create a separate governance process. Instead, add governance checks to the processes teams already use. We added a risk classification step to our standard deployment pipeline. Every model that goes to production gets automatically flagged based on what data it uses, who it affects, and what decisions it informs. No separate form. No extra meeting. It’s just part of the flow.
Make it specific and short. Our governance guidance fits on two pages. It answers three questions: What risk level is this system? What reviews does it need? Who is accountable? That’s it. Engineers actually read it because it takes four minutes, not four hours.
Assign clear ownership, not committees. Governance committees are where accountability goes to die. Every AI system at Cochlear has a single named owner who is responsible for its behaviour in production. Not a committee. Not a working group. A person with a name and a phone number. When something goes wrong at 2 AM, you need to know exactly who to call.
Risk Tiers That People Actually Use
We use three tiers, not the five or seven that most frameworks define.
flowchart LR
New[New AI System] --> Classify{Risk Classification}
Classify --> T1["Tier 1: Low Risk\nInternal tools, human-in-loop"]
Classify --> T2["Tier 2: Medium Risk\nCustomer-facing, personal data"]
Classify --> T3["Tier 3: High Risk\nPatient outcomes, financial decisions"]
T1 --> R1[Standard code review\n+ basic docs]
T2 --> R2[Pre-deploy review\n+ monitoring + quarterly check]
T3 --> R3[Review panel + external audit\n+ continuous monitoring + incident plan]Tier 1: Low risk. Internal tools, productivity aids, content suggestions where a human always makes the final call. These need basic documentation and standard code review. That’s it.
Tier 2: Medium risk. Customer-facing systems, anything that influences a business decision, models that process personal data. These need a documented review before deployment, ongoing monitoring, and a quarterly check-in.
Tier 3: High risk. Anything that directly affects patient outcomes, financial decisions, or access to services. These need a formal review panel, external audit capability, continuous monitoring with alerting, and a clear incident response plan.
Most of our AI systems are Tier 1. About 20% are Tier 2. We have a handful of Tier 3 systems, and those get serious attention. This distribution matters because it means we’re not applying heavy process to low-risk tools, which is what kills velocity and makes teams resent governance entirely.
The Monitoring Problem
The part most governance frameworks completely ignore is what happens after deployment. They focus on the approval process and forget that models drift, data distributions shift, and edge cases emerge in production that never appeared in testing.
We run automated checks on every production model. Prediction distributions, error rates, feature drift, demographic fairness metrics. When something moves outside expected bounds, the system owner gets an alert. Not a monthly report. An alert.
In the past 12 months, our monitoring caught three significant issues before they affected customers. One was a data pipeline change that silently altered a key feature. Without automated monitoring, we wouldn’t have noticed for weeks.
Getting Started Without the Big Document
If you’re starting from scratch, skip the framework document. Do these four things instead.
Make a list of every AI system in production. I guarantee it’s longer than anyone thinks. We found 14 systems that nobody was tracking when we did this exercise.
Assign an owner to each one. Just a name next to each system. You’ll be surprised how many have no clear owner.
Classify each system into the three risk tiers. This takes an afternoon, not a quarter.
Set up basic monitoring for anything in Tier 2 or 3. Prediction drift, error rates, and data quality checks. Off-the-shelf tools can do most of this.
You can do all four of these things in two weeks. They’ll give you more practical governance than a 40-page framework ever will.
The Real Test
Here’s how I judge whether an organisation has real AI governance or governance theater. I ask a random engineer: “If you wanted to deploy a new ML model to production tomorrow, what would you need to do?”
If they can answer clearly and specifically, governance is working. If they shrug or point to a document they’ve never read, it isn’t.
Governance isn’t about documents. It’s about whether the people building and deploying AI systems know what’s expected of them and have the tools to meet those expectations. Everything else is theater.
