NIST AI RMF and EU AI Act High-Risk Requirements: What Carries Over After the Digital Omnibus

Why framework alignment is not conformity

The NIST AI RMF is a voluntary framework. It can be used to prioritise risk, but it does not prescribe risk tolerance. The EU AI Act high-risk requirements are legal obligations, and they must be met in light of each system's intended purpose and the generally acknowledged state of the art. That difference matters for evidence. An RMF-aligned programme shows that an organisation manages AI risk in a structured way. It does not show that a given system meets the Act.

The Commission is explicit that providers must subject a high-risk system to a conformity assessment before placing it on the EU market, and that an independent conformity assessment body may be required depending on system type. The assessment demonstrates compliance with requirements including risk management, data quality, documentation and traceability, transparency, human oversight, accuracy, cybersecurity and robustness.

The Act also provides a route to a presumption of conformity. Under Article 40, a high-risk system that conforms to harmonised standards, with references published in the Official Journal, is presumed to conform with the corresponding requirements, but only to the extent those standards cover them. Conformity with common specifications gives a similar presumption. The mechanism is defined by reference to harmonised standards and common specifications and makes no provision for a voluntary framework. RMF alignment should therefore be treated as supporting evidence, not as a shortcut.

What the Digital Omnibus changed

Planning should now start from the amended Act, not the proposal. The Commission proposed targeted AI Act amendments on 19 November 2025, citing delays in establishing standards for the high-risk rules and in designating national competent authorities and conformity assessment bodies. Those amendments have since been acted on. Regulation (EU) 2026/1744, with an Official Journal date of 24 July 2026, sets new application dates for Sections 1, 2 and 3 of Chapter III, and a consolidated AI Act text dated 27 July 2026 reflects them.

The Commission describes the extension as giving time to implement the rules with clear standards. The earlier 2 August 2026 date is superseded. Because the dates have already changed once, they should be rechecked as of November 2026 and whenever new amendments, guidelines or standards references appear.

• 19 November 2025: Commission proposes the Digital Omnibus on AI, citing delayed standards and delays in designating authorities and conformity assessment bodies.
• 24 July 2026: Regulation (EU) 2026/1744 carries this Official Journal date and sets the new high-risk application dates.
• 27 July 2026: Consolidated AI Act text published reflecting the amendments.
• 2 December 2027: Application date for systems classified high-risk under Article 6(2) and Annex III.
• 2 August 2028: Application date for systems classified high-risk under Article 6(1) and Annex I.

Using RMF artefacts as inputs, requirement by requirement

The RMF's four functions, Govern, Map, Measure and Manage, are a practical starting inventory for an internal mapping exercise. Any such mapping is the organisation's own analysis and should be labelled that way in the gap register. The useful question for each artefact is which requirement it supports and what remains to be added.

Risk management is the closest conceptual fit. Article 9 requires a risk management system that is established, implemented, documented and maintained, run as a continuous iterative process across the whole lifecycle with regular systematic review and updating. It must identify and analyse known and reasonably foreseeable risks to health, safety or fundamental rights when the system is used as intended, and the system must be tested to identify the most appropriate and targeted risk management measures. RMF risk assessments and measurement records can feed this, but they need a defined risk tolerance and documented rationale for each system, because the framework does not supply one.

The same Article 9 system must be taken into account when ensuring accuracy, robustness and cybersecurity, so test results and risk decisions should sit in one record rather than in separate programmes.

Documentation is a second area. The Act requires technical documentation drawn up before placement on the market or putting into service and kept up to date, and requires providers to maintain a quality management system. Providers must keep specified documentation at the disposal of national competent authorities for a period ending 10 years after placement or putting into service. RMF governance policies and system profiles can inform these documents, but they do not replace the required content or the retention period.

For products under Annex I sectoral legislation, Articles 9(10) and 17(3) allow economic operators to integrate an assessment of AI-specific risks into existing risk and quality management systems where necessary and appropriate. That is a structural option for teams that already run mature sectoral processes.

Runtime controls and operational evidence that carry over

The Commission lists documentation and traceability and human oversight among the mandatory requirements. Both are operational in nature. A policy document states what a system should do. Evidence that a control was applied to a specific interaction shows what the system was actually permitted to do and what happened. That kind of record is useful under the RMF's measure and manage activities and under the Act's traceability and oversight expectations, which makes it one of the more portable evidence types across the two regimes.

The design points are consistent regardless of tooling. Tie every record to a specific system and version, because conformity obligations attach to the high-risk system as placed on the market or put into service. Keep intended purpose, risk tolerance and test results in the same documented risk management record. Set retention against the 10-year provider documentation period. Record human oversight decisions, such as approvals and overrides, alongside the automated decisions they relate to.

Trussed enforces policy in the execution path, at the level of individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Enforcement generates audit-ready evidence mapped to the EU AI Act and NIST. This supports runtime evidence needs. It does not deliver conformity, and it does not cover model lineage, dataset provenance or end-to-end tracing of agentic workflows, which must be addressed through other means.