ISO 42001 vs NIST AI RMF vs EU AI Act: One Gateway, Three Frameworks

Three frameworks, three audiences, one underlying question

By mid-2026 it is common for a single AI team to be answering three different governance requests in the same quarter: a customer's procurement questionnaire asking whether the company holds ISO 42001 certification, an internal risk committee asking whether the AI program follows the NIST AI RMF, and a compliance officer asking for the specific documentation the EU AI Act requires because the company serves EU users. These can feel like three separate compliance projects competing for the same limited engineering time. They are not. They are three audiences asking overlapping variants of the same underlying question: can you demonstrate control over what your AI systems do.

What each framework actually is

NIST AI RMF is a voluntary risk-management methodology published by the US National Institute of Standards and Technology. It has no certification, nobody audits you against it and hands you a certificate, and that is by design. It gives organisations a shared vocabulary and a structured process for identifying, measuring, and managing AI risk, the "what" and "why" of a risk program, without prescribing a specific technical implementation.

ISO/IEC 42001:2023 is the opposite in structure: a certifiable international management-system standard, in the same family as ISO 27001 for information security. It defines the "how", a formal structure for establishing, implementing, maintaining, and improving an AI management system, verified by third-party audit. Because it is certifiable, it produces something procurement teams can actually check a box against, which is exactly why it is spreading fastest through vendor-qualification processes rather than through internal risk programs.

The EU AI Act is neither voluntary nor a management system, it is binding law. It became broadly applicable on 2 August 2026, with general-purpose AI enforcement powers active and high-risk obligations phased in on a longer timeline following the Omnibus package adjustments. We covered the specific dates and obligations in detail in our EU AI Act 2026 guide; the point that matters here is that unlike the other two, non-compliance carries statutory penalties, not just a lost sale or an unflattering audit finding.

Where they actually differ, and where enterprises get tripped up

The practical confusion is not usually about what the frameworks say, it is about who is asking and why. A 2026 crosswalk published by NIST itself maps AI RMF functions directly onto ISO 42001 clauses, because the two were designed to be compatible rather than competing, US companies with European operations most commonly run NIST AI RMF as the internal methodology and EU AI Act compliance as the binding legal floor, with ISO 42001 added specifically because enterprise buyers in financial services, healthcare, and the public sector increasingly require certification as a condition of vendor qualification. That last shift is worth sitting with: ISO 42001 certification is moving from a differentiator to table stakes in procurement, which means the business case for getting it is now a sales-cycle argument as much as a risk-management one, and it tends to shorten the sales cycle for exactly that reason.

The trap enterprises fall into is treating each framework as its own workstream with its own tooling, its own spreadsheet, its own audit prep. That approach triples the manual effort for a set of frameworks that are all, underneath the paperwork, asking for the same four things: who can access the AI system, what did they do with it, can you prove it after the fact, and is there a human accountable for the outcome.

What the common requirement looks like in infrastructure terms

Access control, logging, traceability, and oversight are not policy language, they are properties of infrastructure, which is why the fastest path to satisfying all three frameworks runs through the same control point rather than through three separate compliance initiatives.

Access control maps directly to Odock's virtual API keys and access grants: every model and MCP tool call requires an explicit grant tied to an organisation, team, or user principal, documented in scope and principals. That answers the "who can access the AI system" question for all three frameworks simultaneously.

Logging and traceability map to usage records: a durable, queryable row per request capturing identity, resolved model, tokens, cost, latency, and routing history, without ever storing the prompt or completion content itself, which keeps the evidence trail useful for audits without becoming its own data-protection liability.

Oversight and demonstrable risk management map to the policy inheritance and security engine layers: policy inheritance shows exactly which organisation, team, key, model, and MCP rules applied to a given request, and the SafetySec engine produces evidence of whether a request was allowed, redacted, observed, or blocked. Put those together and an auditor working from any of the three frameworks is looking at the same underlying record, just asking for it in a different vocabulary.

The honest limits here

None of this replaces the parts of these frameworks that are organisational rather than technical. ISO 42001 certification still requires a documented management system, defined roles, and an actual third-party audit, a gateway does not audit itself. The NIST AI RMF still requires you to actually run the risk-identification and measurement process, a log is evidence for that process, not a substitute for doing it. And the EU AI Act still requires you to correctly classify your AI systems by risk tier, which is a legal and product judgment no infrastructure layer can make for you. What a gateway does is remove the excuse that the underlying evidence does not exist or is too scattered to produce, which in practice is where most governance programs actually stall.

Where Odock.ai comes in

I built Odock so that the evidence these three frameworks all ask for falls out of normal operation rather than requiring a separate reporting project, so weigh this accordingly. Every request through Odock produces one record with identity, policy outcome, and safety outcome attached, the same record structure whether the person asking is a procurement analyst checking ISO 42001 fit, a risk committee applying the NIST AI RMF, or an EU regulator asking for AI Act traceability.

If your team is currently maintaining separate tracking for each framework, the fastest simplification available is not choosing which one to drop, it is putting your AI traffic behind infrastructure that produces the shared evidence once. Request a demo or start with the security and guardrails documentation to see what the record looks like before your next audit asks.

Sources

• AI Governance Frameworks Compared: NIST vs ISO 42001 vs EU AI Act, NeuralTrust
• Global AI Governance Comparison 2026: EU AI Act vs NIST AI RMF vs ISO/IEC 42001, GAICC
• 5 Key Differences Between the NIST AI RMF and ISO 42001, Vanta
• NIST AI RMF to ISO/IEC FDIS 42001 Crosswalk, NIST
• Odock security and guardrails
• Odock usage records