Who decides, who answers: what ISO/IEC 42001 leaves to the board
ISO/IEC 42001 marks two points where the decision belongs to the board. This piece is for board members, CROs and heads of AI governance: what those decisions are, what the board needs in front of it, and how to name who answers for each AI system.
By Reinhardt Mühlhäusser · Published
- Written against
- ISO/IEC 38507:2022 · ISO/IEC 42001:2023 · ISO/IEC 23894:2023 · Regulation (EU) 2024/1689
- Last updated
Most AI programmes begin with management work: the inventory, the policy, the risk assessment. That effort is real, and it covers most of what regulation asks for. A few questions sit above it. What is AI for in this organization? How much risk will we accept? Who answers when it goes wrong? ISO/IEC 42001 is precise about where its own reach ends, and for the first two it points to ISO/IEC 38507, the standard written for the governing body. The sections below show where the standard draws that line, what the board needs to see before it decides, and how accountability gets allocated, one system at a time.
ISO/IEC 42001 is the interesting case, because it is not purely a management standard. Its leadership and planning clauses require an AI policy, AI objectives compatible with the strategic direction of the organization, allocated responsibilities and authorities, and risk criteria that separate acceptable risk from unacceptable. That is direction, and it sits inside the standard. Management review in clause 9.3 is oversight. Both halves are present.
What the standard does not do is address the governing body, and it says so itself, at exactly the two points where the decision is properly the board’s. The note to clause 5.2 refers organizations developing an AI policy to ISO/IEC 38507. The note to clause 6.1.1 refers the determination of how much risk the organization is willing to take or retain to ISO/IEC 38507 and ISO/IEC 23894. The line does not fall between the two standards. It runs through the middle of ISO/IEC 42001, and the notes are where the standard draws it.
Another standing obligation is visibility: a maintained, high-level view of every AI system in use, which function owns it, what risk it carries, and how it serves the strategy. That is the AI inventory, seen from the governance side rather than the risk side, and without it the board has nothing to evaluate.
Cadence and forum are part of the decision rather than administration around it. Who meets, how often, and with what standing inputs determines whether direction gets revised as the portfolio changes, or is set once at launch and quietly outlived. Reviewing project status and asking whether the direction still holds are different meetings. The second is the governing one, and it needs its own place on the agenda.
The standards are explicit. ISO/IEC 42001 requires roles, responsibilities and authorities to be defined and allocated (clause 5.3), and its Annex A reference controls carry that into AI specifically (A.3.2) and across partners, suppliers and third parties where the control is applied (A.10.2). The EU AI Act adds a sharper version for deployers of high-risk systems in EU scope, from 2 December 2027 (2 August 2028 for Annex I products): human oversight assigned to people with the competence and the authority to intervene. Authority is the word doing the work there: oversight becomes a control at the point the overseer can stop the system.
One named individual, senior enough to stop the system. Not a function, not a committee, not "the AI board". If naming who is accountable takes more than one name, nobody is.
Who runs the monitoring, reviews the overrides, decides on retraining, and executes the retirement. Day-to-day operation of the controls, distinct from answering for them.
Whose input is required before a decision is taken, and who therefore has to be asked rather than informed afterwards. For AI the list has to reach outside the delivery team, because changes that look purely technical often are not: swapping a model version, widening the data a system may reach, or extending it to an adjacent decision can move the organization’s legal position and not just the system’s behaviour. Under Article 25 of the EU AI Act, a new intended purpose can make a deployer into a provider.
Who hears about an incident, within what period, and in what form. Defined in advance, because the moment it is needed is the worst possible moment to design it.
Ordinary RACI is not difficult. The allocation is. Accountability for a decision no human made, taken by a system a vendor built, on data a third party supplied, is the allocation that takes the most work to settle, and an incident is a poor moment to be settling it for the first time. The same allocation then recurs at finer grain during delivery: every control has an operator, every lifecycle stage a sign-off, every incident a first responder and someone with the authority to stop the system. Those are set out with the controls themselves.
A good place to start is one consequential AI system. Write down five names: who owns it, who monitors it, who can challenge it, who can stop it, and who answers for the outcome. Wherever the answer comes back as a committee or a policy, that's the first gap to close. Then check whether the board has set risk appetite as thresholds, or whether the delivery team is setting it by default. Neither step needs a new structure. The allocation lives in the management system you already run, under ISO/IEC 42001 clause 5.3. Valment works this way: AI integrated into existing structures, with the board's decisions feeding it.
Get direction and delivery working together.
Tell us what governance exists today and where AI actually runs. We will respond with a read on how the direction and the management system line up, and a sensible first step — often an ISO/IEC 42001 gap analysis.