An organisation can have an AI policy, an ethics statement and an executive committee and still have weak governance.
The weakness usually appears at the moment someone asks a practical question. Can this team upload customer records to the tool? Who decides whether an AI-generated recommendation needs human approval? Can a vendor switch the underlying model without review? What happens when an employee discovers a serious error? If the answer to every question is “send it to the AI committee”, the organisation has created a queue rather than an operating model.
An AI governance operating model defines who makes which decisions, what evidence they need and when the issue must move to a higher level.
Governance is a decision system
NIST’s AI Risk Management Framework places governance across the lifecycle. Its Govern function emphasises policies, accountability structures, organisational culture and processes that enable AI risk to be understood and managed.
That is a useful way to reframe the subject. Governance is not the meeting itself. It is the system that determines how decisions are made before, during and after the meeting.
For many organisations, a federated structure works better than a fully centralised one. Business teams retain accountability for the processes they operate. Specialists own their domains. A central AI function sets enterprise rules and adjudicates material exceptions. Trained local AI business stewards connect those layers.
Define seven decision types
Start by writing down the recurring decisions rather than drawing an organisation chart.
1. Use-case approval
Is the proposed AI use permitted, and under which conditions? Low-risk uses may be pre-approved when they follow defined patterns. Higher-risk uses need evidence and specialist review.
2. Data permission
What data can the system process? Which lawful, contractual, privacy or confidentiality constraints apply? A Certified AI Data Protection Officer type of capability is relevant where personal data and AI intersect, but the business owner must still explain why the processing is needed.
3. Technical and security acceptance
Can the system be integrated safely? Security specialists should assess identity, access, data flows, logging, external connections and new AI-specific attack surfaces. For material AI security risk, the Certified AI Cyber Risk Assessor provides a specialist learning route.
4. Model or vendor change
Which changes are routine, and which require reassessment? A new model version, material feature, data source or third-party integration can change behaviour without changing the product name.
5. Human-oversight design
Who reviews an output, what information do they receive, and what authority do they have? “Human in the loop” is not a complete control description.
6. Incident response
Who can suspend a system? Who informs affected functions? What evidence must be preserved? A governance model needs an emergency path that is faster than its ordinary committee cycle.
7. Retirement
Who decides that a system is no longer worth its cost or risk? Governance includes stopping systems, closing vendor access, retaining required records and confirming that downstream dependencies have been removed.
Push routine decisions down; pull material risk up
A useful rule is to place a decision at the lowest level that has the competence, evidence and authority to make it safely.
For example, a communications manager might approve routine use of an authorised drafting tool under published rules. The same manager should not unilaterally approve a system that profiles vulnerable customers. The difference is not that one person is trusted and the other is not. The risk, evidence requirements and affected rights are different.
Create escalation triggers around consequence rather than technology branding. Triggers might include sensitive data, decisions affecting employment or access to services, safety implications, external autonomous action, high financial exposure, a new vendor dependency or inability to explain how a critical result was produced.
Use a simple RACI only after decisions are clear
RACI charts are useful, but they often become decorative because teams fill them with broad activities such as “AI governance”.
Instead, create one row for a concrete decision: “approve a high-risk customer-facing AI use”, “accept a material model update”, “close a critical AI incident”. Then identify who is Responsible, Accountable, Consulted and Informed.
Only one role should be accountable for a decision. Multiple accountable boxes usually mean no one owns the outcome.
At enterprise level, the Certified Chief AI Officer represents the kind of role that may own AI-wide direction and escalation, but the exact allocation must fit the organisation’s legal structure and existing executives.
Attach evidence to the decision
Decision rights without evidence standards invite inconsistency. Define a minimum evidence pack for each decision type.
For a new material use, that might include intended purpose, process owner, affected groups, data categories, model or vendor, limitations, test results, human oversight, security/privacy findings, monitoring plan, incident route and exit conditions.
The OECD’s 2026 Due Diligence Guidance for Responsible AI is useful because it treats responsible AI as an ongoing process across business relationships and the AI value chain. That supports a governance model in which evidence continues after procurement rather than ending at contract signature.
Design the AI steward role carefully
An AI steward should not become a miniature lawyer, data scientist and security officer. The value of the role is translation and local control.
A strong steward can:
- identify the AI uses in their function;
- apply the organisation’s risk triage;
- make routine decisions within delegated authority;
- collect the evidence specialists need;
- help colleagues use approved workflows;
- spot exceptions and changes; and
- escalate material issues early.
The steward should not sign off matters outside their competence. Good governance makes escalation a strength, not a failure.
Test the operating model with four scenarios
Before publishing the framework, run tabletop exercises.
Scenario one: a vendor silently changes the model powering a customer chatbot. Who notices, who assesses the change and who can pause deployment?
Scenario two: an HR team wants to use AI to shortlist candidates. Which evidence is required before approval and which functions must be consulted?
Scenario three: employees are using a public tool because the approved system lacks a feature they need. Who decides whether to block, tolerate or replace the workflow?
Scenario four: an AI agent sends an incorrect external message. Who owns the incident, and what stops a repeat?
If the tabletop repeatedly ends with “we would discuss it”, the operating model needs more work.
Measure the governance system itself
Track metrics that show whether decisions are working: time to approve by risk tier, percentage of material systems with named owners, overdue reassessments, unresolved high-severity findings, incidents by control type, vendor changes reviewed on time and percentage of local decisions resolved without unnecessary escalation.
These measures reveal two opposite failures. A system may be too loose, with risks bypassing review, or too centralised, with low-risk activity trapped in approval queues.
Final takeaway
An AI governance operating model should make the organisation faster at ordinary decisions and more deliberate at consequential ones. That requires named decision rights, risk-based escalation, evidence standards and a clear connection between local AI stewards and enterprise leadership.
The test is simple: when an AI issue appears on Monday morning, do people know who can decide, what they need to show and when they must escalate? If they do, governance has started to become operational.
Responses