AI governance
Who gets to say yes to an AI system, and who can switch it off?
Statements about fairness and transparency are easy to publish. Governance is the part that decides, records and enforces: who may approve a new use of AI, who can halt one, who hears first when it misbehaves. ISO/IEC 42001 gives those decisions a permanent home inside an AI management system (AIMS).
Back to ISO 42001 services01 · Three decisions
Start from three decisions, not a list of values
If nobody can answer these quickly, the governance is not there yet.
- Who can say yes? A product team wants to plug a third-party language model into the support desk. Someone must approve it, against criteria written down before the request arrived.
- Who can say stop? A model starts giving worse results for one customer segment. Someone needs both the authority and the access to pull it back, today.
- Who must be told? A user complains that an automated decision treated them unfairly. That complaint needs a route to a person able to investigate and change the system.
Principles still matter: they become the criteria those decision-makers apply. On their own, they decide nothing and leave no trace an auditor can test.
02 · Decision rights
A decision-rights map for AI
Illustrative. Rename the roles to fit your organisation, but keep every column.
| Decision | Raised by | Approved by | Trace it leaves |
|---|---|---|---|
| Adopting a new AI tool or feature | The team that wants it | The AIMS owner, after a risk and impact screen | An inventory entry and a screening record |
| Moving a model into production | The system owner | A release approver named in the procedure | Test results and a signed release |
| Changing training data or the model version | Engineering | The system owner, with reassessment if the change is material | A change ticket linked to the reassessment |
| Accepting a leftover risk | The risk owner | Someone with authority for that level of risk | A dated acceptance in the risk register |
| Pausing or withdrawing a system | Anyone who sees harm | The system owner, or a named deputy out of hours | An incident record and the decision |
| Answering an outside complaint | Support or legal | The system owner, escalating serious cases | The complaint log and its outcome |
In a small company one person may hold several of these roles. What cannot be shared is the trace: each decision needs a record of its own.
03 · Where it lives
Where ISO 42001 puts each piece
The seven auditable clauses, read as the governance question each one settles.
The clause numbers line up with ISO 27001 and other management-system standards because ISO writes them all on one shared skeleton, the harmonized structure. Most of what is specific to AI sits in clause 6 and in Annex A.
| Clause | The governance question it settles | What shows it is settled |
|---|---|---|
| 4 Context of the organization | What exactly is being governed, and on whose behalf? | A scope statement, a stakeholder list with their concerns, the AI inventory |
| 5 Leadership | Who at the top has committed, and to what? | A signed AI policy, assigned authorities, leaders present at reviews |
| 6 Planning | How are risks and harms found, and which targets are set? | Risk and impact assessments, treatment plans, measurable AI objectives |
| 7 Support | Do people have the skills, time and information to carry this out? | Competence records, awareness activity, controlled documents |
| 8 Operation | Do the plans actually run on live systems? | Assessments repeated on change, treatments working in production |
| 9 Performance evaluation | How does leadership know whether it works? | Measures, internal audit reports, management review minutes |
| 10 Improvement | What happens when something fails? | A nonconformity log and corrective actions with root causes |
04 · Right-sizing
The same governance at three sizes
Illustrative setups. The decisions stay fixed; the machinery scales.
Small team on AI APIs
- The founder signs the AI policy
- The CTO is AIMS owner and release approver
- A short monthly look at the inventory and any complaints
Product firm training models
- A small review group from engineering, product, security and privacy
- Every model has a named system owner
- High-stakes releases need the group's sign-off
Enterprise, many business units
- A board-level sponsor and a central AIMS office
- Business units own their systems and assessments
- Internal audit tests a sample of systems each year
05 · Warning signs
Signs the governance lives only on paper
Each is something an auditor tends to spot early.
- A forum that never says no. Minutes show every proposal approved, none with conditions.
- An owner who cannot find the system. The named owner has left, or cannot say where the model runs.
- A stop button nobody has pressed. Withdrawal is in the procedure, yet no one holds the access or has rehearsed the steps.
- Complaints that end at the help desk. Users question automated outcomes and tickets close without reaching the system owner.
- Objectives with no numbers. AI goals written as hopes, with nothing measured against them.
06 · Other frameworks
How this lines up with other governance frameworks
The same decisions, described in different vocabulary.
The NIST AI Risk Management Framework names governance as one of its four functions, GOVERN, and treats it as running through the other three. The EU AI Act places named duties on providers and deployers of high-risk systems, human oversight among them. One decision-rights map can serve all three; the crosswalk guides cover the detail.
Sources: ISO/IEC 42001:2023 clause numbers and titles as publicly listed; ISO's public material on the harmonized structure for management-system standards; NIST AI Risk Management Framework 1.0 (the GOVERN function); Regulation (EU) 2024/1689, the EU AI Act (Article 14 on human oversight, Article 26 on deployers). Descriptions are our own.
Governance questions from founders and risk leads
Is an AI ethics board the same thing as AI governance?
No. A board is one optional piece.
An ethics board advises on hard cases. Governance also needs approval rules, owners, records and a way to halt systems. Plenty of organisations govern AI well with no board at all, and some boards have no power to change anything.
Who should own the AIMS?
Someone senior enough to hold back a release.
Authority matters more than title. Commonly it is a CTO, a head of risk or a chief data officer. The test is simple: can this person delay or block a launch without being routinely overruled?
What does certification add on top of sound governance?
Outside proof, and a rhythm that keeps it alive.
You can govern AI well without any standard. Certification against ISO/IEC 42001 adds an independent check that buyers and partners can rely on, plus a schedule of audits that stops the machinery from going stale.
We have nothing yet. Where do we begin?
With the inventory and the three decisions.
List every AI system in use, give each one an owner, then write down who can approve, who can halt and who must be told. A policy and an assessment method come next, and both are far easier to write once those basics exist.
Map your decision rights before an auditor does.
An ISO 42001 readiness assessment tests who can approve, change and halt each AI system, and shows where the records are missing.