The AI governance operating model: roles, gates and evidence
How to design an AI governance framework that approves useful work quickly and stops harmful work early, without a committee bottleneck.
Design for throughput and for stop conditions
An AI governance framework has two jobs: let low-risk, useful work proceed with minimal friction, and reliably stop or reshape work that carries material risk. Frameworks that fail usually do only one of the two.
The design lever is tiering. Define impact tiers up front, publish what each tier requires, and let teams self-serve at the lowest tier with a registration step rather than a committee submission.
Roles that actually need to exist
You need an accountable executive for AI overall, a named business owner per AI system, a risk or security reviewer, a privacy or legal reviewer for personal-information use, and a technical reviewer for integrations and evaluation.
In smaller organisations one person may hold several of these. That is acceptable provided the roles are named and the reviewer is not approving their own build.
The gates
Gate one, intake: purpose, data classes, impact tier, owner. Gate two, design review: data boundary, identity and permissions, oversight point, evaluation plan, supplier position. Gate three, pre-deployment: evaluation results, logging in place, incident path, conditions accepted.
Gate four, in-life review: usage, incidents, drift or model change, continued business justification. Retire systems that no longer earn their risk.
Want this assessed against your environment?
Send us the specifics and a senior advisor will respond within one business day.
Evidence that satisfies boards and auditors
The inventory, the impact assessments, the approval decisions with conditions, the evaluation results, the supplier assessments and the review minutes. Six artefacts, kept current, answer nearly every question that gets asked.
Report to the board on the portfolio — how many systems, at what tiers, what changed, what incidents occurred and what decisions are required — rather than on individual tools.
Common failure patterns
A single committee reviewing every request creates a queue, and the queue creates shadow AI. Policies written without an inventory govern nothing. Controls applied uniformly to all use cases exhaust goodwill on low-risk work and leave nothing for the high-risk case.
Fix these by tiering, registering, and spending review effort where impact and autonomy are highest.
Sources and further reading
- ISO/IEC 42001 AI management systems
- NIST AI Risk Management Framework
- Australia's AI Ethics Principles
This article provides general information and decision support. It is not legal advice, audit assurance, certification advice or a guarantee of outcome.
Related reading
Securing enterprise AI adoption: a practical AI security control set
The AI security controls that matter first — identity, data boundaries, model access, logging, human oversight and supplier assurance.
Read articleAI risk assessment: how to assess an AI system before it ships
A repeatable AI risk assessment covering purpose, data, model behaviour, integration, human oversight, failure modes and evidence.
Read articleISO 42001 vs ISO 27001: how the two management systems interlock
What each standard covers, where they overlap, and how to run one integrated management system instead of two parallel programmes.
Read article