NIST AI RMF and the EU AI Act: An Honest Crosswalk for US Compliance Teams
Your legal team just told you that your company is in scope for the EU AI Act. You already run a mature NIST AI Risk Management Framework programme. The question everyone is asking is: how much of what we've already built counts?
The honest answer is: a lot - and not enough. Vendor-side estimates, including Glacis's published crosswalk, put NIST AI RMF coverage of EU AI Act obligations at roughly 60-70%. That sounds reassuring until you look at what lives in the remaining 30-40%. That's where the conformity assessments, the technical file, the registration database, and the hard statutory incident-reporting clocks sit. That's where the fines are.
This post maps the overlap honestly, names the five gaps that no amount of RMF maturity closes, flags a problem with the official NIST crosswalk that most teams haven't noticed, and gives you a 90-day plan if you're starting from a mature RMF programme.
Why These Are Different Kinds of Document
Before the crosswalk, you need to understand why the mapping is structurally imperfect - not because either document is poorly written, but because they are doing different jobs.
The NIST AI Risk Management Framework (NIST AI 100-1) was published in January 2023 as a voluntary framework, organised around four functions - GOVERN, MAP, MEASURE, MANAGE - plus seven trustworthiness characteristics. It tells you how to manage AI risk. It is outcome-oriented, sector-agnostic, and deliberately flexible. There is no certification, no notified body, no declaration of conformity. The RMF is a methodology.
The EU AI Act (Regulation (EU) 2024/1689) is product law. It tells you what you must produce, prove, register, and report - and it attaches those obligations to specific legal roles (provider, deployer, importer, distributor) and specific risk classes. Non-compliance carries penalties up to €35 million or 7% of worldwide annual turnover, whichever is higher, for the most serious infringements. The Act is not a methodology; it is a set of binding legal duties with enforcement teeth.
This distinction shapes everything that follows. The RMF will help you build the controls that satisfy the Act's requirements. It will not, on its own, generate the artefacts the Act demands as proof.
The RMF is a voluntary, outcome-oriented framework about how you manage risk. The EU AI Act is binding product law about what you must produce, prove, register, and report. The delta is not conceptual — it is evidentiary and procedural.
The Honest Crosswalk: Function by Function
The four RMF functions map meaningfully - but not completely - to the Act's high-risk obligations. The table below shows where the alignment is genuine and where it runs out.
| RMF Function | What the RMF Covers | Corresponding AI Act Articles | Alignment Quality | What the RMF Doesn't Generate |
|---|---|---|---|---|
| GOVERN | Policies, accountability, culture, roles, risk tolerance | Art. 17 (QMS), Art. 26 (deployer duties), Art. 4 (AI literacy) | Strong — governance structures directly support QMS design | No analogue to the EU declaration of conformity or notified body engagement |
| MAP | Context, risk identification, categorisation, impact assessment | Art. 6 + Annex III (classification), Art. 9 (risk scoping), Art. 27 (FRIA inputs) | Moderate — RMF context-setting supports classification but uses no legal taxonomy | No role-determination logic (provider vs. deployer vs. importer); no Annex III checklist |
| MEASURE | Testing, evaluation, metrics, bias analysis, monitoring | Art. 15 (accuracy, robustness, cybersecurity), Art. 10 (data governance, bias testing) | Strong — MEASURE practices directly produce evidence for Arts. 10 and 15 | No prescribed format; evidence must be restructured for Annex IV technical file |
| MANAGE | Risk response, residual risk, incident response, continuous improvement | Art. 9 (residual risk), Art. 14 (human oversight), Art. 72 (post-market monitoring) | Moderate — incident response outcomes align, but timelines and triggers differ | No statutory clock on incident reporting; no post-market monitoring plan template |
The overlap is real and valuable. Your GOVERN work feeds directly into the Article 17 quality management system. Your MEASURE outputs are the raw material for Article 10 data governance and Article 15 accuracy and robustness evidence. Your MAP risk identification process supports Article 9 risk management scoping. Don't rebuild what you have - reformat and supplement it.
The Five Gaps No Amount of RMF Maturity Closes
These are not gaps you can close by doing more RMF work. They require different instruments entirely.
Gap 1: Conformity Assessment and CE Marking (Article 43)
The RMF has no analogue to a conformity assessment. There is no NIST equivalent of a notified body, no EU declaration of conformity, and no CE marking process. For most standalone high-risk AI systems under Annex III, providers can self-assess against the Act's requirements - but that self-assessment must follow a prescribed procedure and produce a signed declaration. For systems in certain sensitive domains (biometric identification, certain law enforcement uses), a notified body must be involved.
The artefact you must produce: A signed EU Declaration of Conformity, plus - where required - a notified body certificate. Your RMF documentation is useful input, but neither document exists in the RMF world. See our full guide to Article 43 conformity assessment and CE marking.
Gap 2: The Annex IV Technical File (Article 11)
Article 11 of the EU AI Act requires providers of high-risk AI systems to maintain a technical file structured according to Annex IV, which prescribes nine specific sections covering system description, design specifications, training methodology, validation and testing results, risk management documentation, and post-market monitoring plans.
This is a prescriptive document with a prescribed structure. Your RMF artefacts - risk registers, MEASURE outputs, governance policies - contain much of the underlying content, but they are not organised into Annex IV's nine sections, they are not maintained as a single retrievable file, and they are not written to the standard a market surveillance authority would expect to inspect. Reformatting is not trivial.
The artefact you must produce: A complete, maintained Annex IV technical file, updated for every substantial modification. See our Article 11 and Annex IV guide for the full section-by-section breakdown.
Gap 3: Registration in the EU Database (Articles 49 and 71)
Before placing a high-risk AI system on the EU market, providers must register it in the EU's publicly accessible AI database. This is a pre-market step - not something you do after launch. The registration requires specific data fields (Annex VIII), including system name, version, intended purpose, risk classification rationale, and conformity assessment status.
The RMF has no concept of a product registry or pre-market notification. It is a lifecycle risk management framework, not a market-placement process.
The artefact you must produce: A completed registration entry in the EU AI Act database, submitted before market placement. Your internal AI system inventory (which a mature RMF programme should have) is the starting point, but the database fields and the timing requirement are entirely new.
Gap 4: Serious Incident Reporting on Statutory Clocks (Article 73)
The RMF's MANAGE function includes incident response as an outcome. That's valuable. But the Act's Article 73 serious incident reporting regime is a different instrument: it imposes hard statutory timelines for notifying national market surveillance authorities when a high-risk AI system causes or contributes to a serious incident (death, serious harm, significant disruption to critical infrastructure, or a serious fundamental rights violation).
The RMF's open-ended "incident response" outcome does not generate a notification procedure with defined triggers, defined recipients, defined timelines, or defined content. Those must be built explicitly.
The artefact you must produce: A documented serious incident reporting procedure, with defined triggers mapped to Article 73's definitions, named notification recipients (national competent authorities), and timelines. This procedure must be tested before the system goes live.
Gap 5: Role Determination Under Articles 22, 25, and 26
This is the gap most US teams discover last and find most disorienting. The RMF has no concept of legal role at all. It treats your organisation as a single actor managing AI risk. The Act does not.
The Act assigns obligations by role: provider, deployer, importer, distributor. The obligations differ significantly. Providers carry the heaviest burden - conformity assessment, technical file, CE marking, registration, post-market monitoring. Deployers have a shorter but real list under Article 26, including fundamental rights impact assessments under Article 27 where in scope.
Article 25 of the EU AI Act provides that a deployer who substantially modifies a high-risk AI system, or places it on the market under their own name or trademark, is reclassified as a provider and takes on the full provider obligation set. This "role-flip" catches many US companies who rebrand or fine-tune third-party models for EU customers.
The artefact you must produce: A documented role determination for every AI system in scope, signed off by legal counsel, with a clear analysis of whether Article 25 applies. See our roles explainer and our Article 22 authorised representative guide - because if you are a US-based provider with no EU establishment, you will also need an authorised representative.
Honourable Mention: Article 5 Prohibitions Are Not Risks to Manage Down
A risk-based framework like the RMF is built on the premise that risks can be identified, assessed, and mitigated to an acceptable residual level. Article 5's prohibited practices are not risks - they are absolute bans. Social scoring by public authorities, real-time remote biometric identification in public spaces (with narrow exceptions), manipulation of vulnerable groups, and - from 2 December 2026 - AI-generated non-consensual intimate imagery and AI-generated CSAM.
No amount of risk management makes a prohibited practice compliant. If any of your systems touch these use cases, the answer is not better controls - it is discontinuation.
A Note on the Official NIST Crosswalk
NIST maintains crosswalk documents on the AI Resource Center (AIRC) that map the AI RMF to the EU AI Act, among other frameworks. These are useful directional tools. But there is something important that most teams using them don't know: the NIST AI RMF crosswalk to the EU AI Act maps to the proposed AI Act text, not to the final Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744.
The final Act differs from the proposal in ways that matter - including the addition of the Annex IV technical file structure, changes to the conformity assessment routes, and the role-determination provisions in Article 25. Treat the NIST crosswalk as a useful starting point for identifying thematic alignment, not as an authoritative compliance mapping against the law as it stands.
The Corrected Timeline (Read This Before You Relax)
Many articles published before August 2026 state that the high-risk AI deadline was 2 August 2026. That date is now wrong, and if you've read it recently, you've read an outdated source.
Regulation (EU) 2026/1744 - the Digital Omnibus on AI - was published in the Official Journal of the EU on 24 July 2026 and entered into force on 27 July 2026, moving the Annex III standalone high-risk obligations from 2 August 2026 to 2 December 2027, and Annex I embedded-product high-risk obligations to 2 August 2028.
Here is what is actually in force right now:
| Obligation | Status |
|---|---|
| Article 5 prohibitions (incl. social scoring, biometric manipulation) | In force since February 2025 |
| Article 4 AI literacy duty | In force |
| GPAI provider obligations (Arts. 53-55) | In force since August 2025 |
| Article 50 transparency (AI disclosure, deepfake labelling) | In force since 2 August 2026 |
| New prohibitions: non-consensual intimate imagery, AI-generated CSAM | Applies from 2 December 2026 |
| Annex III standalone high-risk obligations (Arts. 8-15, 17, 43, 49, 72, 73) | Applies from 2 December 2027 |
| Annex I embedded-product high-risk obligations | Applies from 2 August 2028 |
The deferral is real. But it is not a pause - it is a resequencing. The obligations themselves are unchanged; only the enforcement date moved. And 15 months is not long when you are building a conformity assessment programme from scratch.
90-Day Plan for a Mature RMF Programme That Just Discovered EU Scope
This assumes you have a functioning RMF programme - governance policies, a risk register, MEASURE outputs, incident response procedures - and have just confirmed that one or more of your AI systems is in scope for the EU AI Act as a high-risk system.
For every AI system potentially in scope: (1) run the Annex III classification check against Article 6 and Annex III use cases; (2) determine your legal role — provider, deployer, or both; (3) apply the Article 25 role-flip test to any system you've fine-tuned, rebranded, or substantially modified; (4) if you are a US-based provider with no EU establishment, identify your authorised representative obligation under Article 22. Output: a scoped system inventory with role assignments, signed off by legal.
For each in-scope system, assess: (1) Do you have a conformity assessment route identified? (2) Do you have an Annex IV technical file structure started? (3) Is the system registered (or registerable) in the EU database? (4) Do you have a serious incident reporting procedure with Article 73 triggers? (5) Is your role determination documented and defensible? Map your existing RMF artefacts to each gap — identify what can be reformatted versus what must be built new.
Prioritise the Annex IV technical file — it is the longest lead-time item and the foundation for conformity assessment. Reformat your existing MEASURE outputs, risk register entries, and governance documentation into the nine Annex IV sections. Draft your serious incident reporting procedure. Begin the EU database registration data fields (Annex VIII). If you are on the notified body route for conformity assessment, begin engagement now — queue times will grow as December 2027 approaches.
Run a tabletop exercise against your Article 73 incident reporting procedure. Verify that your post-market monitoring plan (Article 72) has defined triggers for updating the technical file and re-running conformity assessment after substantial modifications. Confirm your Article 17 QMS covers all thirteen elements. Brief your board or risk committee on the five gaps and the December 2027 deadline. Assign owners to each open item with quarterly review dates.
What Not to Do
Mistake 1: Assuming RMF maturity equals conformity. It does not. A mature RMF programme is the best possible starting point - it means your controls exist, your risk culture is established, and your documentation habits are good. But the Act requires specific artefacts in specific formats, produced through specific processes. "We have a risk management framework" is not a defence in a market surveillance inspection.
Mistake 2: Assuming the December 2027 deferral means nothing is due now. Article 5 prohibitions, Article 4 AI literacy, Article 50 transparency obligations, and GPAI provider obligations are all in force. If your systems interact with EU users - chatbots, recommendation engines, content generators - Article 50 disclosure duties apply today. The deferral bought time for the heavy high-risk obligations; it did not pause the regulation.
The Bottom Line
The NIST AI Risk Management Framework is a genuinely excellent foundation for EU AI Act compliance. Your GOVERN work maps to the QMS. Your MEASURE outputs feed the technical file. Your MANAGE processes support post-market monitoring. The RMF is not the wrong tool - it is an incomplete tool for this specific job.
The delta is not conceptual. You understand risk management. The delta is evidentiary and procedural: five specific artefacts that the Act requires and the RMF will not generate for you. Name them, assign owners, and start building. The December 2027 deadline is closer than it looks.
This post is for informational purposes only and does not constitute legal advice. The EU AI Act is a complex regulation; consult qualified legal counsel for advice specific to your organisation's situation.
Related reading
ISO/IEC 42001 Is Not a Presumption of Conformity Under the EU AI Act - and Neither Is EN 18286:2026 Yet
ISO/IEC 42001 certification is useful AI governance infrastructure - but it is not a presumption of conformity under the EU AI Act. Neither is EN 18286:2026, yet. Here's why, and what to do about it.
The EU AI Act's Notified Body Bottleneck: Why Conformity Assessment Still Isn't Ready
The Digital Omnibus pushed the high-risk AI Act deadline to December 2027 largely because notified bodies and harmonised standards are not ready. Here is the state of the conformity-assessment infrastructure, what still applies on schedule, and how to use the extra runway.
Does the EU AI Act Apply to Open-Source AI? A Plain-English Guide to the Article 2(12) Exemption
Free and open-source AI gets a carve-out under Article 2(12) - but it is narrower than most maintainers think. Here is exactly where the exemption applies, where it stops (Annex III, Article 5, Article 50), and the separate rules for open-source GPAI models.