Three names come up in almost every AI governance conversation: ISO/IEC 42001, the EU AI Act and the NIST AI Risk Management Framework. They are frequently discussed as though they were three competing checklists, and a common request follows — which one should we adopt?

That question is difficult to answer well, because the three are not the same kind of instrument. One is a management system standard you can be certified against. One is law. One is a voluntary framework with no certification at all. An organisation can hold a certificate and still breach the law; it can comply with the law and hold no certificate; and it can use the framework without doing either.

The useful question is not which to adopt. It is which obligations actually apply to you, in which role, in which market — and what single body of evidence can answer all three.

ISO/IEC 42001 — a management system, certified at a point in time

ISO/IEC 42001:2023 specifies requirements for an AI management system. It follows the same structure as other management system standards: understand the organisation's context, establish leadership and roles, plan for risks and opportunities, run an AI risk assessment and an AI system impact assessment, operate a set of controls, audit internally, review at management level, and improve.

It is certifiable. An accredited certification body can audit the management system and issue a certificate. That has real value: it demonstrates that an organisation has built a repeatable way of governing its AI activity, and that an independent party has examined it.

What a certificate does not say is that any particular model is safe, accurate, fair or lawful. It attests to the system that governs the work, sampled at the time of audit. Treating a 42001 certificate as evidence about a specific AI system is a category error, and a well-briefed customer or regulator will say so.

The EU AI Act — law, and your obligations depend on your role

Regulation (EU) 2024/1689 is binding law with extraterritorial reach: it can apply to organisations outside the EU where the output of an AI system is used in the Union. Two questions determine what you must do.

What role do you hold? The Act distinguishes providers, deployers, importers, distributors and authorised representatives, and the obligations differ sharply between them. Many organisations assume they are only deployers, then discover that putting their own name on a system, or substantially modifying it, can move them into the provider role and the far heavier obligations that come with it.

What risk class is the system in? The Act sets out prohibited practices, high-risk systems (including the Annex III list covering areas such as employment, education, essential services, creditworthiness and law enforcement), transparency obligations for certain systems, and a separate regime for general-purpose AI models.

The timetable has already moved once. Under the Digital Omnibus agreed in 2026, the obligations for Annex III high-risk systems were deferred to December 2027. That is a deferral, not a repeal: the classification stands, and the systems that will be high-risk then are high-risk-shaped now. Organisations treating the delay as a reason to stop preparing have misread it — the work of establishing what you hold, in what role, in what class, does not get shorter for being started later.

NIST AI RMF — vocabulary and structure, not compliance

The NIST AI Risk Management Framework is voluntary, developed in the United States, and carries no certification scheme. It organises AI risk work into four functions — Govern, Map, Measure, Manage — and is accompanied by a Generative AI Profile addressing risks specific to generative systems.

Its value is different in kind from the other two. It gives an organisation a shared vocabulary and a way of structuring the conversation between risk, legal, engineering and the business. Nobody can be found non-compliant with it. That is precisely why it is useful early: it lets teams reason about AI risk before they are arguing about obligations.

And the two jurisdictions that get left out of the comparison

The United Kingdom has no single cross-sector AI statute in force. Regulation runs through existing regulators applying existing law within their remits — the FCA and PRA in financial services, the ICO for personal data, the MHRA for medical devices, and so on. Legislation has been signalled, so this is the position most likely to have changed by the time you read this. In practice, a UK organisation's nearest AI obligations usually already exist inside a sector regime it is already subject to.

India likewise has no comprehensive AI statute. NITI Aayog's Responsible AI work sets out principles, and the Digital Personal Data Protection Act governs personal data. For organisations operating across all four jurisdictions, the practical implication is not that the rules are equivalent — they are not — but that the underlying questions asked of an AI system are remarkably consistent.

How the three actually fit together

The cleanest way to hold them in mind:

  • ISO/IEC 42001 is how you run it — the management system around AI decisions.
  • The EU AI Act is what you must do — for these systems, in this role, in this market.
  • NIST AI RMF is how to think about it — a structure for identifying and treating the risk.

They overlap heavily in what they ask you to be able to show. All three want you to know what AI you have and what it is for. All three want risk and impact considered before deployment rather than after an incident. All three want human oversight to be a described arrangement rather than an assumption. All three want records that survive the departure of the person who made the decision.

That overlap is the opportunity. An organisation running three separate programmes against three separate documents will produce three inconsistent versions of the same facts, and will spend most of its effort reconciling them.

What to do if you are starting from nothing

Build once, map outwards:

  • One inventory. Every AI system and AI-enabled feature, including the ones a vendor switched on inside a product you already bought.
  • One risk and impact method. Proportionate, applied consistently, producing a written output that can be pointed at.
  • One evidence store. Where the assessments, evaluations, oversight procedures and decisions live, bound to the version of the system they describe.
  • One decision record. Who approved what, on what basis, and what conditions were attached.

Then map that body of work outwards to whichever instrument you are answering. The mapping is a translation exercise. The underlying evidence is the same, and it is the part that takes real time to build.

The trap worth naming

The most common expensive mistake in this area is buying a certificate as a substitute for evidence. A certification project can be run with consultants, templates and a defined end date, which makes it feel tractable. Assembling honest evidence about your actual AI systems is slower, less linear and harder to put a date on — and it is the thing that answers the question a regulator, a customer or an incident review will actually ask.

Certification is worth having. It is worth having because the underlying system is real, not instead of it.

Next insight

What counts as evidence that an AI system is governed

Every framework asks for evidence. Few of them say what a piece of evidence has to look like to be worth anything.

Read the next insight

Primary sources

This article is general information about AI governance. It is not legal advice, certification guidance or a statement that every cited requirement applies to every AI system. Regulatory timetables in this area move; check the current position before relying on it.