AI governance

Governing AI with rigour: what ISO/IEC 42001 actually requires

The conversation about artificial intelligence in organisations usually starts in the wrong place. What tool to buy, which model is better, how much it saves. Rarely discussed is who decides, on what basis, and what happens when the system gets it wrong.

ISO/IEC 42001, published in 2023, is the first certifiable international standard for an Artificial Intelligence Management System (AIMS). Its contribution is not technical: it does not say how to train a model or what architecture to choose. Its contribution is governance. It brings to AI the same logic of management, risk and continual improvement that ISO/IEC 27001 brought to information security twenty years ago.

In the projects we have been supporting, the first finding is almost always the same, and it has nothing to do with the standard.

Nobody knows how much AI is already inside

When we inventory an organisation’s AI usage, the result surprises the board itself. Three layers appear.

The first is the declared layer: the project approved in committee, the supplier contracted, the pilot everybody talks about. It is usually the smallest layer.

The second is the embedded layer: AI features that arrived inside products already in use. The CRM that now suggests replies. The office suite that summarises meetings. The antivirus deciding with a model. Nobody made the decision to “adopt AI”: it arrived in an update, with the implicit consent of a contract signed three years earlier.

The third is the layer adopted by the teams: the hardest to see and the one that concentrates the most risk. People getting their work done with tools they chose themselves, pasting into a chat information the organisation classified as confidential.

No AI policy works if it is written before looking at those three layers. The inventory is not a formality preceding the project: for the first few weeks, it is the project.

What the standard asks for, on four planes

Read without anxiety, ISO/IEC 42001 organises into four planes.

Policy and governance. Defining principles of responsible use, roles and responsibilities and —above all— who decides. Which uses are allowed without authorisation, which require approval, which are prohibited, and who resolves the cases that fit no category. An AI policy that only lists good intentions is not a control.

Risks and impacts. Here is the most interesting difference from ISO/IEC 27001. The ISMS assesses risk to the organisation. The AIMS additionally requires assessing the impact on people: bias, explainability, the ability to appeal a decision, effective human oversight. They are two distinct analyses and one does not substitute for the other.

Life cycle and data. Managing the AI system end to end —design, training data, validation, deployment, monitoring, retirement— with explicit governance over the data feeding it. A model is only as traceable as the data it was built from.

Transparency and control. Traceability of decisions, accountability, internal audit and continual improvement. Being able to answer, six months later, why the system decided what it decided.

The question that organises the whole project

In practice, a single question determines how much rigour each AI system requires:

Does this system affect a decision that affects a person?

An assistant that helps draft an internal email and a model that decides whether credit is granted are, formally, both “AI systems”. Treating them with the same level of demand is a mistake in both directions: it bureaucratises the trivial and underestimates the critical.

We classify uses into three levels:

  • Internal productivity with no effect on third parties. Usage policy, training and control over what information can be entered. Little more.
  • Decision support with prior human review. Add system documentation, review criteria and a record of the times the person departed from the suggestion. That record is what later demonstrates the human oversight was real rather than decorative.
  • Decisions with direct effect on people. Full impact assessment, bias analysis, explainability, a complaints mechanism and continuous monitoring of the model’s behaviour in production.

Most organisations are currently in the first two levels. That makes the project far more tractable than is generally feared.

If you already have an ISMS, half the work is done

ISO/IEC 42001 shares the high-level structure with ISO/IEC 27001: context, leadership, planning, support, operation, performance evaluation and improvement. In an organisation with a working ISMS, the framework policy, the risk methodology, competence management, internal audit and management review are reused unchanged.

What gets added is narrow and specific: the inventory of AI systems, the impact assessment on people, governance of the life cycle and of the data, and management of AI suppliers with clauses almost no contract includes today.

In projects with a certified ISMS, the incremental effort of the AIMS runs at around a third of what implementing it from scratch would cost. It is a strong argument for not treating AI governance as a separate initiative.

The regulatory frame

Two things condition the design wherever you operate.

Personal data protection law applies in full to AI systems that process personal data, without any need for a new statute. Lawful basis, purpose, proportionality and data subject rights do not change because a model made the decision. If the system affects people, this is the first review, ahead of any consideration of the ISO standard.

National AI strategies and regulatory sandboxes are being put in place in a growing number of countries, including Uruguay, where AGESIC leads a strategy with a 2024–2030 horizon that includes controlled testing environments for use cases requiring supervised experimentation. For organisations that interact with the State, aligning with that framework has immediate practical value.

Where to start on Monday

You do not need a formal project to take the first two steps, and they are the ones that clear the picture most.

  1. Inventory. Ask each department what AI-enabled tools it uses, including those that arrived inside existing products and those someone adopted on their own. Without sanction: the objective is to see the real map, and you only see it if nobody is afraid to show it.
  2. Draw the data line. A clear rule about what information may not be entered into an external AI tool resolves, on its own, much of the immediate exposure. It is a decision of hours, not months.

With those two things done, the discussion about certifying ISO/IEC 42001 stops being abstract: you already know what would have to be governed.


Want to place your organisation against ISO/IEC 42001? The maturity assessment inventories AI usage and measures the gap against the standard in a few weeks.

your business partner

Protecting you today, innovating for tomorrow