EU AI Act, ISO/IEC 42001 and NIST AI RMF: how they fit together

The EU AI ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry →, ISO/IEC 42001ISO/IEC 42001The international requirements standard for AI management systems, published in 2023 and certifiable. It defines how an organization establishes, implements, maintains, and continually improves a management system for AI. Certification against ISO/IEC 42001 does not create a legal presumption of conformity with the EU AI Act. See AI management system, harmonized standard.Open full entry → and the NIST AI RMFNIST AI RMFThe AI Risk Management Framework of the US National Institute of Standards and Technology, published as version 1.0 in 2023. It is a voluntary framework built around four functions: govern, map, measure, and manage. In a layered setup, it serves as the risk method inside a management system such as ISO/IEC 42001. See ISO/IEC 42001, ISO/IEC 23894.Open full entry → answer different questions and are designed to be used together. The AI Act sets legal obligations for AI systemsAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs (predictions, content, recommendations or decisions) that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → placed on the EU market. ISO/IEC 42001 specifies requirements for an AI management systemAI management systemThe organizational structure, policies and processes for governing AI across its life cycle, as formalized in ISO/IEC 42001.Open full entry → that an organization can certify. The NIST AI RMF offers voluntary riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → management outcomes and actions, and states that its functions are not a checklist and not a required sequence. This article explains how to use them together without merging them into a new framework.

Every link in that chain has an anchor in an authoritative framework. This article maps that chain to the frameworks an AI governanceAI governanceGovernance extended for AI: the same organizational steering at the highest level, widened to cover what makes AI different (it works in probabilities rather than fixed rules, learns from data, and can act at a speed and scale no human reviewer can match). It inherits the existing governance structure and brings AI inside the disciplines the organization already runs, rather than creating a parallel system in a silo. It operates on two levels, design and execution. See governance, governance design, execution level, responsible AI.Open full entry → professional works with, so it can be used as a single mental structure without losing the ability to speak each framework's language when an auditor, a regulator, or a certification asks. It is a companion to what is AI governance, which sets out the chain itself.

The two-level structure: design and execution

The split between governance designgovernance designThe design tier of AI governance: policy, roles, organizational structure, and risk appetite. Governance design sets the boundaries within which AI systems may operate; the execution level tests whether reality stays inside them. See execution level, risk appetite.Open full entry → and execution is the structure the major AI frameworks already use.

The NIST AI Risk Management Framework separates its govern function, the cross-cutting organizational layer of policies, accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress; never the system itself. The EU AI Act attaches obligations to the role rather than the technology, with provider duties in Article 16 and deployer duties in Article 26, supported by technical documentation (Article 11) and record-keeping (Article 12). See provider, deployer, record-keeping, responsible AI.Open full entry →, and culture, from the map, measure, and manage functions that run continuously against each system. Govern is the design level; map, measure, and manage are execution. NIST is explicit that govern is infused throughout the others and that their outputs feed back into govern to update it, which is the design-execution loop.

ISO/IEC 42001 is built as an AI management system on the Plan-Do-Check-Act cycle: the planning clauses establish the design (context, leadership, policy, roles, risk planning), and the operation, evaluation, and improvement clauses are the execution (running the controlscontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry →, auditing, correcting). A management system is by definition a design that operates continuously, which is the same two levels.

The AIGP body of knowledge follows the same shape: its early competencies cover establishing organizational expectations, policies, and roles (design), and its later domains cover governing development and deployment across the AI life cycleAI life cycleThe looped stages of an AI system: design → data/development → validation → deployment → operation & monitoring → retirement, each with native controls and gated transitions.Open full entry → (execution).

How much of this chain is law?

For high-risk AI systemshigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry →, part of it is. Article 9 requires a risk management system that is established, implemented, documented and maintained, and that runs as a continuous, iterative process across the life cyclelife cycleThe span of a single AI system from first intake to retirement, across which it must be governed. The horizontal axis of governance: where the governance chain holds one principle, the life cycle runs one system through time. Commonly drawn as six stages, plan and design, data and develop, verify and validate, deploy, operate and monitor, and retire, each with controls native to it and an anchor artifact. A loop rather than a line, because a system in production feeds new risk back into fresh assessment. See artifact, control, governance chain.Open full entry → with systematic review and updating. It requires identification and analysis of known and reasonably foreseeable risks, estimation and evaluation of risks arising from intended purpose and reasonably foreseeable misuse, evaluation of risks emerging from post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use, the product-regulation half of continuous monitoring.Open full entry →, and the adoption of appropriate and targeted risk management measures. Article 9(5) requires that the residual riskresidual riskThe risk that remains after controls have reduced it. No control reduces a risk to zero, and not every control is worth its cost, so a deliberate judgment is made: whether the cost of further control is justified by the reduction it would buy, and whether the remaining risk is acceptable against the organization's risk appetite. This is a design-level judgment, where execution reports back up and governance accepts the residual risk, calls for more control, or declines the use case. EU AI Act Art. 9(5) requires it to be judged acceptable per hazard and overall. See risk, control, risk appetite.Open full entry → for each hazard, and the overall residual risk, are judged to be acceptable.

Testing is part of that statutory sequence. Article 9(6) requires that high-risk AI systems are tested to identify the most appropriate and targeted risk management measures, and that testing establishes consistent performance for the intended purpose and compliance with the requirements of this Section. Article 9(8) requires testing at any time during development and, in any event, before the system is placed on the market or put into service, against prior defined metrics and probabilistic thresholds appropriate to the intended purpose. In control language: the law does not stop at control design. It requires a defined threshold, a test against it, and a judgment on what remains.

Risk, control, residual risk and testing are therefore statutory steps, not an interpretation. Two parts of the sequence are different in kind. The step from a responsible AIresponsible AIThe set of principles an AI system should live up to: fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, and human oversight. Widely shared and sitting under the EU AI Act and the major frameworks. On their own the principles are statements of intent; the law turns them into duties that cannot be met unless they are carried inside the organization's governance, which is how responsible AI lands in governance rather than beside it. The seven principles are organized into seven pillars, one pillar per principle. See principle, pillar, governance.Open full entry → principleprincipleOne of the seven responsible-AI values a governed system should live up to (fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, human oversight). A principle is abstract: it states an outcome, not a lever you can pull. It becomes governable by naming the harm that would breach it, assessing the risk that harm carries, and placing controls against that risk. Held this way, a principle becomes a pillar. See pillar, harm, risk.Open full entry → to a concrete harmharmThe concrete damage an AI system can do that a responsible-AI principle exists to prevent: in the EU AI Act's terms, harm to a person's health, safety, or fundamental rights. Harm is the bridge between an abstract principle and a governable risk; governance becomes operational the moment an organization names the specific harms it wants to prevent. For fairness, a harm is a group receiving systematically worse outcomes because of a characteristic that should not have counted. See principle, risk.Open full entry → is an analytical step that this knowledge base makes explicit; the law does not describe it. And evidenceevidenceThe concrete proof that a control is designed, implemented, and working: a test report, an audit trail, an impact assessment, a monitoring log. Each link in the governance chain produces an artifact, and together they are what an organization hands to its own board, a regulator, a customer, or an affected person to show, not say, that a system is governed. Its absence is itself the failure: a risk register without test results, or a mitigation claimed without validation, is a governance gap, not a paperwork one. The closing link of the governance chain. See control, governance.Open full entry → as an assurance concept comes from internal control and audit practice, although Articles 11, 12 and 17 on technical documentationtechnical documentationRecords a provider must compile and keep for a high-risk AI system to demonstrate conformity, covering its design, data, testing, risk management and monitoring.Open full entry →, record-keepingrecord-keepingThe EU AI Act obligation for high-risk AI systems to allow automatic recording of events over the system's lifetime, laid down in Article 12. Deployers must keep the logs under their control for a period appropriate to the system's purpose, at least six months, under Article 26(6). Logs are what make decisions reconstructable afterward. See evidence, human oversight.Open full entry → and the quality management system produce much of the same material.

The full sequence is a traceability chain. It connects legal requirements to responsible AI principles at one end and to the evidence an organization needs at the other. It is an explanatory sequence, not a separate governancegovernanceThe system through which an organization steers itself: corporate governance, risk management, compliance, lines of accountability, risk appetite, and the operating model. It exists across everything the organization does, before and beyond AI. AI governance is this same system extended for AI. See AI governance, governance design, execution level.Open full entry → framework.

Where ERM anchors the harm-risk-control chain

AI governance does not start from a blank page. It inherits the enterprise risk management an organization already runs, and three ERM frameworks anchor that inheritance.

COSO ERM, in its 2017 form, provides the enterprise structure the design level sits inside. Its five components, governance and culture, strategy and objective-setting, performance, review and revision, and information, communication and reporting, span twenty principles. The harm-risk-control chain is the risk identification, assessment, and response that COSO places under performance, applied to the seven AI principles, and the residual-risk-against-appetite judgment is a COSO mechanism. Risk appetiterisk appetiteThe level of risk an organization's leadership is willing to accept in pursuit of its objectives, set at the governance design level. It is the benchmark against which residual risk is judged acceptable or not, inherited from the organization's broader governance and applied to AI. A concept from enterprise risk management (COSO ERM) before it is an AI one. See residual risk, governance design.Open full entry → is a COSO concept before it is an AI one.

The IIA Three Lines Model, renamed in 2020 from the older "three lines of defensethree lines of defenseAccountability model: the first line owns and operates risk, the second line sets policy and challenges, the third line (internal audit) independently assures, adapted to AI governance organization-wide.Open full entry →", anchors the roles at the design level: the first line owns and manages risk and controls, the second line provides oversight, challenge, and expertise (where a dedicated AI governance function or AI Officer typically sits), and the third line provides independent assurance. The providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → and deployerdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → roles the AI Act defines operate inside this structure, not beside it.

ISO 31000 anchors the generic risk discipline itself: its process, establish the context, then risk assessment (identification, analysis, evaluation), then risk treatment, with communication and monitoring throughout, is the generic form of the harm-risk-control chain. ISO/IEC 42001's risk clauses are the AI-specific expression of that generic process, which is exactly why AI governance can be described as inherited-and-extended rather than invented. The alignment is not coincidental: analysis of the EU AI Act's Article 9, the ISO risk standards, and the NIST RMF finds they converge on the same top-level steps, define, assess, and treat risks, all under a govern process, which is precisely the design-and-execution structure this knowledge base uses.

Why the sources line up

The three sources converge because they describe the same discipline. Risk management did not begin with AI. Identify what can go wrong, judge how serious it is, put a measure in place, test whether the measure works, and accept or escalate what remains. The EU AI Act writes that sequence into law for high-risk AI systems. ISO/IEC 42001 places it inside a management system that can be certified. The NIST AI RMF describes it as voluntary outcomes and actions.

The vocabulary differs. The AI Act speaks of risk management measures, ISO of controls and continual improvement, NIST of functions and outcomes, and the AIGP body of knowledge of governance practice. Reading them as three competing methods makes the work harder than it is. Reading them as one discipline in four vocabularies makes it possible to satisfy several at once, because the underlying question is the same each time: does this control address the risk, and can you show that it works?

Sources and framework alignment

Source	How it is used here
EU AI Act (Regulation (EU) 2024/1689)	Applicable legal obligations
ISO/IEC 42001	Management system and continual improvement context
NIST AI RMF	Risk management concepts and outcomes
Internal control and audit practice	Control objectivescontrol objectiveA statement of the outcome a control must achieve, such as "unauthorized payments must not be technically executable". It says what must be true rather than what must be built, which leaves room for more than one control activity to meet it. Keeping the objective separate from the activity is what keeps a control register testable. See control activity, enforcement point.Open full entry →, testing and evidence

Continue reading

• What is AI governance
• Governance across the AI life cycle
• Responsible AI vs AI governance: what is the difference