AI Blog

ISO 42001 vs NIST AI RMF vs the EU AI Act vs AIUC-1

Buyers ask for all four as if they were grades of one exam. They are four objects with four recipients — and an ISO/IEC 42001 certificate buys no presumption of conformity with the EU AI Act, because the harmonised standard for Article 17 is EN 18286:2026, uncited in the Official Journal as of mid-August 2026. Underneath, the evidence overlaps: build the core once, certify last, and note that only AIUC-1 was written for agents at all.

By Agentic AI Wiki 15 min read

A customer's security questionnaire asks whether you are ISO 42001 certified, NIST AI RMF aligned, EU AI Act compliant and AIUC-1 audited, as if those were four grades of the same exam. They are four different kinds of object with four different recipients, and the most expensive misunderstanding in the list is the one that sounds most reasonable: an ISO/IEC 42001 certificate buys you no presumption of conformity with the EU AI Act, because ISO 42001 is not a harmonised standard and the one written to be — EN 18286:2026 — had not been cited in the Official Journal as of mid-August 2026. The good news underneath is that this is not four programmes; it is one evidence core packaged four ways.

At a glance

Sort them by what kind of thing they are, and the confusion mostly dissolves.

FrameworkWhat it isWhat you end up holdingWho the audience is
ISO/IEC 42001 A certifiable management-system standard, published December 2023 An accredited certificate, three-year term with annual surveillance A customer's procurement team
NIST AI RMF A voluntary US risk framework — Govern, Map, Measure, Manage A self-attested mapping of your controls Your own risk function, and a questionnaire
EU AI Act Binding EU law, phased in from 2 August 2026 for the high-risk regime A technical file and a declaration of conformity A regulator, or a notified body
AIUC-1 A private certification for AI agents, backed by insurance An audited certificate, 12-month term with quarterly re-testing An underwriter, and increasingly a buyer
Four AI governance frameworks across four properties A matrix of four frameworks against four properties. ISO/IEC 42001 is voluntary, strongly certifiable by an accredited body on a three-year cycle, has no agent-specific controls, and is widely accepted as buyer evidence. The NIST AI Risk Management Framework is voluntary, self-attested rather than certifiable, has agentic overlays still forthcoming, and is usually accepted as a mapping. The EU AI Act is binding law, uses conformity assessment rather than certification, allocates duties by role rather than by agentic behaviour, and is required rather than credited. AIUC-1 is a private standard, certifiable through a single issuer, purpose-built for agents, and emerging as buyer evidence. Four different objects, asked for as if they were one LEGALLY BINDING CERTIFIABLE AGENT CONTROLS BUYER EVIDENCE ISO/IEC 42001 management system No — voluntary standard Accredited audit, three-year cycle None — written for AI systems Widely accepted certificate NIST AI RMF voluntary framework No — voluntary guidance No — you attest to yourself Agentic overlays still forthcoming Usually, as a control mapping EU AI Act regulation Yes — it is the law Conformity assessment Duties by role, not by autonomy Required, not credit earned AIUC-1 private certification No — a private standard Yes — one issuer, 12-month term Purpose-built for agents Emerging — young and single-source Solid = the property holds strongly · tinted = partially · outlined = not at all. No row dominates, which is the point.
No row dominates another. That is why the questionnaire asks for all four.

The expensive misunderstanding

Three standards on the road to EU AI Act presumption of conformity Three columns tracking what each standard does for Article 17 of the EU AI Act. ISO/IEC 42001, published in December 2023, is a certifiable AI management system standard but is not harmonised and carries no presumption of conformity. EN ISO/IEC 42001:2026, the European adoption published on 18 March 2026, is a European standard but is still not the Article 17 quality management system. EN 18286:2026, approved by CEN and CENELEC on 12 July 2026, is the standard written to carry presumption of conformity for Article 17, but it had not been cited in the Official Journal as of mid-August 2026, so the presumption does not yet operate. What buys presumption of conformity under Article 17 ISO/IEC 42001 published December 2023 A certifiable AI management system standard, with its own purpose and its own value. Presumption of conformity: none. Not a harmonised standard. A certificate is not a legal shield. EN ISO/IEC 42001:2026 published 18 March 2026 The European adoption of the same standard — a European standard, and still not Article 17. Presumption of conformity: none. The EN prefix is the thing most often mistaken for harmonisation. EN 18286:2026 approved 12 July 2026 Written to be the Article 17 quality management system; first JTC 21 standard approved. Presumption: pending citation. Not cited in the Official Journal as of mid-August 2026.
Three standards, one of which is on the path. None of them is on it yet.

Article 17 of the AI Act requires providers of high-risk systems to run a quality management system. ISO/IEC 42001 is a quality-management-shaped standard about AI. Putting those two sentences next to each other produces a conclusion that is intuitive, widely repeated, and wrong.

Presumption of conformity under EU product law operates only through harmonised standards cited in the Official Journal. ISO/IEC 42001 is not one. The European adoption, EN ISO/IEC 42001:2026, published on 18 March 2026, is a European standard but is not the Article 17 QMS and does not become harmonised by having an EN prefix — which is precisely the detail that gets missed, because the prefix is the visual cue everybody uses. The standard actually written for Article 17 is EN 18286:2026, approved by CEN/CENELEC on 12 July 2026 as the first of the JTC 21 AI Act standards to reach final approval. It was still not cited in the Official Journal as of mid-August 2026, so following it is a choice rather than a shortcut, and conformity has to be demonstrated directly against the Act.

Three consequences worth acting on:

  • Do not let a certificate close an obligation. If a compliance plan says "ISO 42001 certified, therefore Article 17 satisfied", it has a gap sized like the whole technical file. Certification is genuinely useful evidence toward the Act — the management system it builds is most of what Article 17 wants — but it is evidence, not presumption.
  • Watch the citation, not the publication. The date that changes your legal position is an OJEU citation, not a CEN approval. Put that on a calendar the way you would a certificate expiry.
  • The gap between approval and citation is where the work sits. Building against EN 18286 now is a reasonable bet on where the requirements land; assuming it already carries presumption is not.

What each one is actually for

ISO/IEC 42001 — the transferable artefact

Its distinctive property is not its content, it is that an accredited third party issues a certificate a stranger will accept. AWS, Anthropic and Microsoft hold it; the audit is a two-stage process with annual surveillance on a three-year cycle, and the reported cost and timeline land in the tens of thousands of dollars and several months rather than in either extreme people expect. If your problem is that enterprise procurement stalls on an AI questionnaire, this is the only item on the list that directly solves it — a certificate ends the conversation in a way that a self-attestation does not.

NIST AI RMF — the vocabulary and the internal spine

Voluntary, unauditable, and the most useful of the four for actually organising work. Its four functions give you a structure your own teams can argue inside, and its language is the lingua franca of American security questionnaires. What it will not do is settle anything with an outside party, because you are grading yourself. Treat it as the spine you hang the other three off, not as a deliverable.

EU AI Act — the one with a defendant

The only one where non-compliance is illegal rather than embarrassing, and the only one whose obligations depend on a question the others never ask: what role are you in? Provider and deployer carry different duties for the same system, and if you compose someone else's model into your own agent and put your name on it, you may have become the provider without noticing. Get the role determination and the risk classification right first; almost every downstream question is a function of those two answers.

AIUC-1 — the one that is actually about agents

Published by the Artificial Intelligence Underwriting Company: 51 requirements and 130 controls, 65 mandatory and 65 optional, across security, safety, reliability, accountability, data and privacy, and society, mapped to MITRE ATLAS and the OWASP top ten for agentic applications. Certificates run 12 months with quarterly technical testing, and ElevenLabs was the first company to hold one. The interesting design decision is the enforcement mechanism: the publisher underwrites insurance priced off the audit score, so a higher-scoring agent pays a lower premium. That aligns the incentives in a way an auditor's opinion does not — and it is also the caveat, because the standard's author sells the policy.

They are not four programmes

One evidence core, four different proof objects A shared evidence core sits in the centre: an inventory of AI systems, a risk assessment per system, documented human oversight, incident and change logs, evaluation records, and supplier controls. Four arrows lead outward to four different proof objects, each with a different recipient. ISO/IEC 42001 produces an accredited certificate for a procurement team. The NIST AI Risk Management Framework produces a self-attested control mapping for a security questionnaire. The EU AI Act produces a technical file and declaration of conformity for a regulator or notified body. AIUC-1 produces an audited certificate priced into an insurance premium for an underwriter. The core is built once; only the packaging differs. Build the evidence once, package it four ways The shared evidence core An inventory of AI systems · a risk assessment per system documented human oversight · incident and change logs evaluation records · supplier and model provenance controls Roughly the same artefacts in all four cases. ISO/IEC 42001 An accredited certificate on a three-year cycle Recipient: procurement NIST AI RMF A self-attested mapping of controls to functions Recipient: a questionnaire EU AI Act A technical file and a declaration of conformity Recipient: the regulator AIUC-1 An audited certificate, re-tested quarterly Recipient: an underwriter What differs is the recipient, the proof object and the enforcement mechanism — not most of the underlying work. Which is why the sequencing question is who asks you first, not which framework is best.
The core is built once. What differs is the packaging, the recipient and what happens when you are wrong.

Ask what evidence each framework actually wants and the lists converge hard. An inventory of the AI systems you run. A documented risk assessment per system. Evidence that a human can oversee and intervene. Incident and change logs. Evaluation records showing the thing was tested against something. Controls over the models and suppliers you depend on. That set satisfies most of all four, and building it once is the difference between a compliance function and a compliance department.

What genuinely differs is worth naming precisely, because it drives sequencing:

  • Who receives the evidence. A procurement reviewer, your own risk committee, a regulator, an underwriter. Same facts, four audiences with four tolerances for "we have a policy for that".
  • What the proof object is. A certificate, a mapping, a technical file, a priced policy. Only two of the four are things a stranger can verify without trusting you.
  • What happens when you are wrong. A lost deal, an internal finding, an enforcement action, a claim. These are not comparable in severity, and the ordering is not the same as the ordering of effort.
  • How fast it goes stale. Three years, whenever you feel like it, on legislative timelines, or quarterly. AIUC-1's quarterly re-testing is the only cadence in the list that resembles how fast an agent deployment actually changes.

All four are thin where agents are thickest

Here is the uncomfortable part for anyone shipping agents rather than models. ISO/IEC 42001 and the NIST AI RMF were both written for AI systems that produce outputs. Neither has much to say about a system that holds credentials, takes actions in other people's systems, spawns sub-agents, and can complete a chain of irreversible steps before a human observes anything. The failure modes that make agents distinctive are not absent from these frameworks because the authors disagreed about them — they are absent because the frameworks predate them.

The gap is being worked, unevenly:

  • NIST has moved. An AI Agent Standards Initiative was announced in February 2026 through the Center for AI Standards and Innovation, an AI Agent Interoperability Profile is planned for the fourth quarter of 2026, and COSAiS — control overlays extending SP 800-53 to AI, including dedicated single-agent and multi-agent overlays — is forthcoming. Useful when it lands; not something to cite today.
  • The EU AI Act allocates by role, not by autonomy. Nothing in the risk classification turns on whether a system acts. An agent that files insurance claims and a model that scores them can land in the same class with the same duties, which is coherent as law and thin as engineering guidance.
  • AIUC-1 is the only one purpose-built, and it is young, single-issuer, and commercially entangled with the insurance it prices. That is not a disqualification — it is the trade you are making, and it should be made deliberately.
  • The runtime layer is somewhere else entirely. The controls that actually bound an agent — egress policy, scoped credentials, approval gates on irreversible actions, a kill switch — live in your architecture, and none of these four frameworks will tell you how to build them. Certification says you have a process for deciding; it does not say the decision was good.

When to pick which

SituationStart withBecause
Enterprise deals stalling on AI questionnaires ISO/IEC 42001 The only accredited certificate a stranger accepts without trusting you
You place a high-risk system on the EU market EU AI Act, role determination first It is law; everything else is optional next to it
You sell an autonomous agent that acts on customer systems AIUC-1 The only control set written for what an agent actually does
You need to organise the work internally first NIST AI RMF Free, structural, and the vocabulary the other three borrow
All of the above, limited budget Build the evidence core, certify last The artefacts overlap; the packaging is the cheap part

The sequencing rule that survives contact with a real budget: identify who will ask you first, build the evidence core against the union of all four, and buy the certificate whose absence is currently costing you deals. Certification is a packaging decision made late, not a programme you start with.

FAQ

Does ISO/IEC 42001 certification make us EU AI Act compliant?

No. Presumption of conformity operates only through harmonised standards cited in the Official Journal, and ISO/IEC 42001 is not one — nor is its European adoption, EN ISO/IEC 42001:2026. The standard written for the Article 17 quality management system is EN 18286:2026, approved by CEN/CENELEC on 12 July 2026 but not cited in the Official Journal as of mid-August 2026. A 42001 certificate is strong evidence toward the Act's requirements; it is not a legal shield.

Is NIST AI RMF certifiable?

No. It is a voluntary framework you attest to yourself. That makes it excellent for organising internal work and for answering American security questionnaires, and useless as an artefact a sceptical counterparty can verify.

What does AIUC-1 cover that ISO 42001 does not?

Agent behaviour. AIUC-1's 51 requirements and 130 controls are organised around six risk pillars and mapped to MITRE ATLAS and the OWASP top ten for agentic applications, so it addresses tool use, autonomy and agent-specific attack surface directly. ISO/IEC 42001 governs how you manage AI as an organisation and is silent on what your agent is allowed to do at runtime.

Why does insurance backing matter?

Because it changes who bears the cost of a wrong assessment. AIUC underwrites policies priced off the audit score, so a higher-scoring agent pays a lower premium and the assessor has money on its own opinion. It also means the standard's author sells the product it grades you for — an alignment worth having and a conflict worth naming.

Can we do just one?

Yes, if you have one audience. Most organisations do not: a US enterprise buyer, an EU regulator and an insurer want different objects from the same facts. Build the evidence core once — inventory, per-system risk assessment, oversight documentation, incident and evaluation records, supplier controls — and treat each framework as a packaging exercise on top of it.

Which one covers our agent's runtime controls?

None of them, in the sense of telling you what to build. AIUC-1 comes closest by naming agent-specific controls; NIST's agentic overlays are forthcoming rather than usable. Egress policy, scoped credentials, gates on irreversible actions and a kill switch are architecture decisions, and a certificate attests that you have a process for making them rather than that you made them well.

Further reading

On this wiki:

Sources: