ISO/IEC 42001 is a management system, not a badge
Organisations buy the standard expecting a control checklist and receive an operating model instead. The distinction decides whether the certificate is worth anything eighteen months later, when the AI estate has changed and the documents have not.
The request usually arrives already framed as a project. A customer has asked for ISO/IEC 42001 in a procurement round, or a board has decided the organisation should have it, and what is wanted is a plan with a date on it.
The plan is straightforward to write and it will produce a certificate. Whether it produces anything else depends on a choice made in the first fortnight, and the choice is usually made by accident.
ISO/IEC 42001 is an artificial intelligence management system standard. That phrase is doing all of the work. It is built in the same shape as ISO/IEC 27001 for information security and ISO 9001 for quality: context, leadership, planning, support, operation, evaluation, improvement — a loop the organisation runs, not a list of controls it installs. The controls in Annex A matter, and they are the part everybody reads first, and they are downstream of the loop rather than a substitute for it.
The claim: an organisation that implements the annex without the loop will pass its initial audit and fail its estate. The certificate says a system was operating. The value depends on whether it keeps operating when the models, suppliers and use cases change — which, in this field, they will, faster than in any estate these standards were originally written for.
Where each version of the work ends up
| Implemented as a checklist | Implemented as a management system |
|---|---|
| An inventory assembled for the audit | An inventory maintained because a system cannot go live without an entry |
| Impact assessments written for the systems in scope | An assessment triggered by a stage gate, for anything that meets a stated threshold |
| Policies approved and filed | Policies that name an owner and a review date, and are read by the people who build |
| Supplier questions answered once, at onboarding | Supplier obligations in the contract, tested on a cycle |
| Objectives described qualitatively | Objectives with measures, reviewed by management on a schedule that exists |
The right-hand column is not more expensive to build. It is more expensive to fake, which is a different property, and it is the one that determines whether the second surveillance visit is uneventful.
The loop, in the order it actually has to be built
- 01 Inventory What AI is in use, including what was bought inside something else.
- 02 Classification Which systems matter, against a threshold somebody wrote down.
- 03 Controls Annex A, scoped to what the classification says is needed.
- 04 Evidence The artefacts each control produces, in the ordinary course of work.
- 05 Review Management review with measures, and internal audit that can say no.
Stage one is where most programmes lose a month, and it is worth understanding why: the difficult part of an AI inventory is not the systems the organisation built. It is the AI arriving inside products it already bought. A customer relationship platform ships a summarisation feature, a service desk adds a triage model, a recruitment tool adds ranking. None of that was procured as AI, none of it appears on an AI register assembled by asking the engineering teams, and some of it is closer to the regulated end of the spectrum than anything the organisation built itself.
Stage two is where the standard is most often mis-scoped in the other direction. Not every system needs the full apparatus. A threshold written down in advance — consequence to individuals, autonomy of the decision, reversibility, scale — lets an organisation apply weight where it is warranted, and defend the decision not to apply it elsewhere. Without that threshold, everything is either in scope, in which case the programme collapses under its own paperwork, or nothing is, in which case the certificate is describing a very small system indeed.
What it does and does not buy you commercially
That third and fourth line are worth being blunt about with a buyer, because the market is currently not. A management system standard attests to a process. It does not make a statement about the behaviour of a given model, and a supplier answering a question about model accuracy by pointing at a certificate has changed the subject.
The relationship to the EU AI Act is similarly oversold. A functioning AI management system produces a great deal of what a high-risk provider would need under the Act — the quality management system, the documentation discipline, the post-market monitoring habit — and that overlap is real and worth having. It is not the same as conformity, the Act has its own harmonised-standards route, and a percentage figure for how much of one covers the other is a marketing artefact rather than a finding.
What this does not tell you
We do not certify anyone, and we are not an accredited certification body. What we do is design the operating model the standard assumes you already have, and tell you honestly which parts of your estate the scope statement should exclude. Interpretation of what the Act requires of your organisation remains a matter for your counsel and your notified body.
Nor is a certificate the right first move for everybody. For an organisation with two AI systems and no procurement pressure, the same money buys more risk reduction spent on the inventory, the classification threshold and one properly conducted impact assessment. The standard is a good answer to a specific commercial question — a customer requires third-party assurance — and an expensive answer to a question nobody has asked.
The person who should decide differently is the one about to approve the programme. Ask what will still be running twelve months after the audit. If the answer is a folder, buy the operating model instead, and let the certificate be the by-product it was designed to be.