- The 'which AI governance framework should we adopt?' question is misframed — NIST AI RMF, ISO/IEC 42001, and the EU AI Act overlap far more than they differ.
- Most enterprises hedge, building toward two or three frameworks at once because no one knows which one the next customer or auditor will ask for. It's expensive and it doesn't end — there's always a fourth framework coming.
- The frameworks are labels. Underneath them sits one set of real controls: risk classification, logging, traceability, human oversight, documentation, incident response.
- Build that control structure once — the Control Core — then map it to whichever framework's label you're asked to produce. NIST already publishes crosswalks that prove the controls are interoperable.
- For a consultancy, the deliverable isn't a certificate. It's a control capability that survives the next framework — and that's what large organizations will actually pay for.
Which AI governance framework should you adopt? NIST AI RMF, ISO/IEC 42001, or the EU AI Act?
I've come to think the question is wrong.
Not wrong as in premature. Wrong as in misframed — the way "which cloud provider makes us secure?" is misframed. The framework was never going to be the thing that governs your AI. The controls underneath it are. And once you see that, the entire "which one?" debate collapses into a much more useful question: what is the control structure that would satisfy all of them at once?
The clock that makes this urgent
The Three Frameworks, Honestly
Two are voluntary and one is law — they answer different questions (how to think, how to prove, what's required) but they're aimed at the same underlying risks.
Before the argument, the education. If you're a leader being asked to "pick a framework," here is what you're actually choosing between.
NIST AI RMF is a risk-management framework, not a certification. The US National Institute of Standards and Technology released version 1.0 in January 2023, and added a Generative AI Profile (NIST-AI-600-1) in July 2024. It's built around four functions — Govern, Map, Measure, Manage — and it's voluntary and free. Nobody stamps you "compliant." It gives you a structured way to think about AI risk. It is also, quietly, being revised: in April 2026 NIST opened a concept note for a critical-infrastructure profile. The framework is a living document, not a finish line.
ISO/IEC 42001 is the one you can actually get certified against. Published in December 2023, it's the world's first certifiable AI management system standard — it works like ISO 27001 does for information security. You build an AI Management System, an external auditor assesses it, and you walk away with a certificate you can hand to a customer or a board. Its value isn't the thinking; it's the proof.
The EU AI Act isn't voluntary at all. It's law, with teeth. It entered into force in August 2024 and phases in over three years: the ban on prohibited practices began in February 2025, general-purpose-AI model obligations in August 2025, the bulk of the high-risk obligations in August 2026, and the final high-risk classification rules in August 2027. The penalties are not symbolic — prohibited-use violations run up to €35 million or 7% of total worldwide annual turnover, whichever is higher. If you operate in the EU market, this isn't a framework you choose. It's a floor you clear.
fig. — three frameworks, three different jobs
| NIST AI RMF | ISO/IEC 42001 | EU AI Act | |
|---|---|---|---|
| What it is | Voluntary risk framework | Certifiable management standard | Binding law |
| What you get | A way to think about risk | A certificate to show | The right to operate in the EU |
| Who asks for it | US partners, boards, self-direction | Enterprise customers, procurement | Regulators, EU market access |
| Cost of ignoring it | Weak internal discipline | Lost deals | Fines up to 7% of global turnover |
| Ends? | Being revised (2026) | Recertification cycles | Phases through 2027 — then the next law |
Three different jobs: how to think, how to prove, what's required. Notice what they are not. They are not three different definitions of what good AI governance looks like.
The Hedging Trap
Because no one knows which framework the next customer or auditor will demand, organizations build toward several at once — an expensive bet that never resolves, because there's always another framework coming.
Here's what I see organizations actually doing. They hedge.
They build toward two or three frameworks simultaneously, because nobody knows which one the next customer, auditor, or regulator will ask for. The procurement team wants ISO 42001. The US partner references NIST. Legal is watching the EU AI Act clock. So the organization spins up three parallel workstreams, three sets of documentation, three vocabularies for the same underlying reality.
It's expensive. And it solves nothing durable — because next year there is likely a fourth framework. A sector-specific standard. A national variation. An updated version of one you already implemented. The market for AI governance tooling has already raced from "do you need a platform?" to "which platform?" without ever consolidating on the framework underneath — Gartner published its first-ever Magic Quadrant for AI Governance Platforms in June 2026, which is what a market looks like when the answer flips from whether to which before anyone agreed on the standard. You are being asked to standardize on a moving target, three times over, forever.
And the organizations doing the hedging are not, by and large, actually covered. In Credo AI's 2026 State of AI Governance survey of 371 senior leaders, 60% of enterprises were scaling AI while only 4% judged their governance mature enough for it. That gap is the hedging trap made visible: enormous effort spread across multiple frameworks, and still almost nobody feels ready. Spreading yourself thinner across more labels doesn't close it.
That's not governance. That's a certificate treadmill.
The Reframe: Controls, Not Certificates
Strip the labels away and all three frameworks demand the same real things — and the standards bodies themselves publish crosswalks proving the controls are interoperable.
Strip the labels off and look at what each framework actually requires you to do. Underneath the different vocabularies, they converge on the same handful of real controls:
- Risk classification — knowing which of your AI systems are high-stakes and which aren't.
- Logging and audit trails — a durable record of what the system did and why.
- Traceability and lineage — where the data came from, which model version ran, what changed.
- Human oversight — defined points where a person can intervene, and someone accountable when they don't.
- Model and data documentation — the system described well enough that someone who didn't build it can govern it.
- Incident response — what happens when the model does something it shouldn't.
Every one of the three frameworks wants these. They ask for them in different words, in different orders, with different evidence formats. But the substance is the same. Same logging. Same risk assessment. Same traceability. Different labels depending on who's asking.
This isn't wishful thinking on my part. The standards bodies say it themselves. NIST maintains a public, living crosswalk registry — documents that formally map AI RMF's controls onto other standards, including ISO/IEC 23894 and ISO/IEC 42005, plus Singapore's AI Verify, Korea's TTA guidance, and Japan's AI guidelines. The most recent entries were updated in August 2025. Read that for what it is: a government standards body publishing the official translation table between frameworks — because it already assumes one control set should satisfy many of them.
Make it concrete. Take one control — audit logging — and watch the same underlying capability answer three different masters:
- NIST AI RMF → satisfies the Measure and Manage functions: evidence that system behavior is tracked and monitored over time.
- ISO/IEC 42001 → satisfies the operational-control and record-keeping clauses of the AI Management System: documented, auditable evidence the AIMS is running.
- EU AI Act → satisfies the Article 12 record-keeping / automatic-logging obligation for high-risk systems, and feeds the Annex IV technical documentation.
Same log. Same retention. Same immutable trail. Three different auditors, three different citations, one control you built once. Now multiply that across all six controls, and the "which framework?" question dissolves — you're not building three governance programs, you're building one and rendering it three ways.
This is already how the mature players operate. When Anthropic earned ISO/IEC 42001 certification in January 2025, it didn't invent a parallel governance stack for the certificate — it mapped the controls it already ran to the standard's clauses. The certificate was an output of the control structure, not the reason for it.
Arrival
In Arrival, Louise Banks stops trying to translate the aliens' language word-by-word and realizes every sentence is a projection of one underlying, non-linear meaning — the same thought rendered in different symbols. Once she sees the meaning beneath the symbols, translation stops being the hard part.
AI governance frameworks are the symbols. The control structure is the meaning. Chase the symbols one at a time and you translate forever; build the meaning once and every framework becomes a rendering of something you already have.
The Control Core
Build the control structure once as a framework-neutral core, keep a thin mapping layer that renders it into any framework's evidence format, and assign clear ownership — so a new framework is a relabeling job, not a rebuild.
So here's the operating model I think holds. Stop building toward frameworks. Build one control structure — the Control Core — and treat every framework as a rendering of it.
Three layers:
fig. — build the core once, render it on demand
The Core — build once, framework-neutral
The real controls: risk classification, logging, traceability, human oversight, documentation, incident response. Designed against the underlying risk, not against any one framework's checklist. This is the asset. It's where the money and effort go — once.
The Mapping Layer — relabel cheaply
A thin translation layer that renders the same core controls into whichever framework's evidence format is asked for. The same audit log answers NIST's "Measure," ISO 42001's clause, and the EU AI Act's record-keeping article. A new framework becomes a mapping exercise, not a rebuild.
Ownership — who runs each control
Every control in the core has a named owner: security owns the audit trail, model owners own traceability and documentation, product owns human-oversight design, risk owns classification. Governance stops being a project the compliance team runs alone and becomes a standing capability with distributed accountability.
The shift is subtle but total. In the hedging model, a new framework is a new project — new documentation, new workstream, new cost. In the Control Core model, a new framework is a new column in the mapping layer. You already have the controls. You already have the evidence. You're just rendering it into a new format for a new audience.
The framework becomes what it always should have been: a label you print on demand, not a structure you rebuild from scratch.
The ownership layer is where this actually lives or dies
Let me not gloss the hardest part. Naming an owner per control is easy on a slide; making it stick is the whole game. The control that starts every turf war is human oversight — product thinks it's a risk function, risk thinks it's a model-owner responsibility, the model owner thinks it's a product design decision. So it ends up owned by no one, which is exactly how a control becomes a paragraph in a policy nobody operates. The tie-breaker: absent an explicit assignment, human oversight defaults to the CISO's office — someone owns it on day one, and the org can reassign later with intent rather than leaving a vacuum.
Two rules keep the ownership layer alive. First, every control has one accountable owner, not a committee — the person whose name is on it when an auditor or an incident arrives. Contributors can be many; the owner is one. Second, the control has to be wired into work the owner already does, not bolted on as extra compliance homework. An audit trail the security team already runs for other reasons stays current; a "governance log" invented for the certificate goes stale the day after the audit and quietly rots until the next one. The failure mode isn't bad intentions — it's a control that depends on someone doing unrewarded upkeep after everyone stopped watching. Design the ownership so staying compliant is a byproduct of the owner's normal job, and it survives the owner changing teams. Design it as extra work, and it won't survive the first reorg.
What This Means for Delivery
What large organizations will pay for isn't another certificate — it's a control capability that survives the next framework, delivered as assess → build core → map → operate.
I operate in the consultancy space, so let me be direct about what I think large organizations are going to want — and what it means to deliver it.
They will not, for much longer, want help "getting ISO 42001 certified" as an end in itself. They'll get burned by the treadmill first: certified against one framework, then asked for another, then watching a third become law. What they'll want — once they've felt that pain — is a control capability that survives the next framework. Something that turns each new standard into a mapping job instead of a fire drill.
That reshapes the engagement. The deliverable isn't a certificate; it's the Control Core and the capability to run it. The sequence:
- Assess — inventory the AI systems, classify them by risk, and find which of the six core controls already exist in some form (most organizations have fragments — a logging system here, a model registry there).
- Build the Core — design the six controls against the underlying risk, framework-neutral, filling the gaps. This is the real work and the durable asset.
- Map — build the crosswalk layer to whichever frameworks the client faces today: NIST, ISO 42001, the EU AI Act. Certification, when needed, falls out of this almost as a byproduct.
- Operate — hand over ownership, cadences, and the mapping capability so the client can absorb the next framework themselves without calling you in a panic.
That last step matters. A consultancy selling the treadmill wants you back every time a new framework appears. A consultancy selling the Control Core makes itself less necessary over time — and that's precisely why the client trusts it. You're not selling compliance. You're selling the thing that makes compliance a solved, repeatable problem.
A fair question at this point: doesn't building the Core cost more up front than just chasing the one certificate procurement is asking for this quarter? For the first framework, often yes — you're building the durable structure instead of the disposable artifact. The math flips on the second. The certificate-chaser pays close to full price again for framework number two, and again for number three. The Core-builder pays once for the controls and a fraction each time for a new mapping column. Frame it to the CFO as what it is: a higher first cost that turns every subsequent framework from a project into a line item. The break-even is the second framework — and there is always a second framework.
And when your board asks the question it will actually ask — "are we ISO 42001 certified, yes or no?" — the Core doesn't dodge it. You still get certified. The difference is that the certificate is now a report you run off the control structure, not a nine-month program you launch from zero. "Yes, and we can produce the equivalent evidence for NIST or the EU AI Act on request" is a much stronger board answer than "yes" — and it's only available to the organization that built the Core first.
Governance as a Capability, Not a Certificate
The organizations that win won't be the most-certified — they'll be the ones who built the control structure once and can render any framework on demand.
The frameworks will keep coming — new standards, national variations, new versions of the ones we have. Chase each one and you've signed up for an infinite backlog. Build the thing they all point at, once, and every new framework is just another rendering.
Stop chasing certificates. Build the control structure — once — and relabel it on demand.
Same logging. Same risk assessment. Same traceability. Different labels depending on who's asking. That's not a compliance strategy. It's a capability that outlives every framework you'll ever be handed.
The clock in the opening isn't hypothetical. The organizations that move now — while it's still a choice and not yet a scramble — are the ones who'll meet the next framework as a formality instead of a fire drill.
