AI regulation and standards: the EU AI Act, OECD principles, ISO AI standards and NIST AI RMF

Why this matters

Compliance shapes AI work earlier than it shapes most technology. Whether a use case is permitted at all, what must be documented before launch, whether a human must review each decision, and whether a vendor's model can be used for a given purpose can all depend on which regime applies. A security professional who meets these questions only at audit time meets them after the architecture has been fixed.

The four instruments in this lesson are different kinds of thing, and confusing them is the commonest error. The EU AI Act is law, binding on organisations in its scope. The OECD AI Principles are an intergovernmental recommendation, influential but not binding on companies. The ISO/IEC AI standards are voluntary international standards, one of which can be certified against. The NIST AI Risk Management Framework is voluntary guidance from a US agency. They overlap heavily in content, because they draw on one another, and they differ completely in consequence.

This lesson explains what each asks for and how they fit together. It is not legal advice: whether a particular system falls into a particular category is a question for counsel, and the security role is to supply the facts that question needs and to build the controls the answer requires.

The lesson

The EU AI Act's risk-based approach, and what it asks of providers and deployers

The EU AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024. Its obligations are phased in from 2025 onwards: the prohibitions apply first, then the rules for general-purpose AI models, then the bulk of the high-risk requirements. Exam scenarios are more likely to test the structure than the calendar.

The Act is risk-based: what it demands depends on what the system is used for, not on which technique it uses. There are four tiers.

• Unacceptable risk: prohibited practices. A short list of uses banned outright, including social scoring, manipulative or deceptive techniques and the exploitation of vulnerabilities such as age or disability to distort people's behaviour harmfully, and some biometric uses such as untargeted scraping of facial images to build recognition databases and emotion recognition in workplaces and education, subject to narrow exceptions.
• High risk. Systems that are safety components of products already under EU product-safety rules, and systems used in listed sensitive areas such as employment and recruitment, education, access to essential services including creditworthiness assessment, law enforcement, migration and critical infrastructure. These carry the heaviest obligations.
• Limited risk: transparency duties. People must be told when they are interacting with an AI system such as a chatbot, and synthetic content such as deepfakes must be disclosed or marked as artificially generated.
• Minimal risk. Everything else, such as spam filtering or game AI, with no specific obligations beyond general ones.

Separately, the Act places duties on providers of general-purpose AI models, the foundation models that many applications are built on: technical documentation, information for downstream providers, a copyright policy and a summary of training content. Models judged to pose systemic risk carry further duties, including evaluation, adversarial testing, incident reporting and cybersecurity protection.

Two roles decide who does what.

• The provider develops a system, or has it developed, and places it on the market or puts it into service under its own name. For a high-risk system, the provider carries the main burden: a risk management system, data governance for training data, technical documentation, automatic logging, instructions for use, design for human oversight, appropriate accuracy, robustness and cybersecurity, a quality management system, conformity assessment before release and monitoring after it.
• The deployer uses a system under its authority in a professional capacity. A deployer of a high-risk system must use it according to the instructions, assign human oversight to competent people, make sure input data it controls is relevant, monitor operation, keep the logs under its control and inform affected workers. Certain deployers must also assess the impact on fundamental rights before use.

A deployer can become a provider. Putting your own name on a high-risk system, substantially modifying it, or repurposing a general system for a high-risk use can move the provider obligations onto you. A company that takes a general chatbot and uses it to rank job applicants is the scenario to recognise.

Two further points make the Act matter outside Europe. Its reach follows the market and the output: it can apply to a provider established elsewhere that places a system on the EU market, and to systems whose output is used in the EU. And it asks providers and deployers to ensure adequate AI literacy among staff who operate AI systems, which turns the awareness training in lesson 30 into a compliance obligation for organisations in scope. The Act also sits alongside the GDPR, which continues to govern any personal data the system processes; complying with one does not discharge the other.

The OECD AI principles as the common ancestor of many national rules

The OECD AI Principles were adopted in 2019 and updated in 2024. They are a recommendation from the Organisation for Economic Co-operation and Development, adhered to by governments, including some outside the OECD's membership. They bind no company directly, and they matter because so much national policy descends from them.

They have two parts. The values-based principles describe trustworthy AI: inclusive growth, sustainable development and well-being; respect for human rights and democratic values, including fairness and privacy; transparency and explainability; robustness, security and safety; and accountability. The recommendations to governments address national policy, such as investing in research, building an enabling ecosystem, developing skills, interoperable governance and international co-operation.

The examinable idea is lineage. The responsible-AI principles in lesson 30, the trustworthiness characteristics in the NIST framework and the requirements in the EU AI Act all express values that the OECD set out early. The OECD's definition of an AI system has also been influential in later legislation. So an organisation that has mapped its controls to the OECD values has done much of the conceptual work for the others, but it has not complied with anything by doing so, because the principles impose no obligations on it. A scenario that asks which instrument is a non-binding, intergovernmental statement of principles is pointing here. Read the phrase "OECD standards" as this body of principles: there is no OECD AI standard to certify against.

ISO AI standards, and what certifying an AI management system means

ISO and IEC publish AI standards through a joint committee. Three are worth knowing by number and purpose.

• ISO/IEC 42001:2023 specifies an AI management system, and it is certifiable. It follows the same management-system structure as ISO/IEC 27001 for information security: context, leadership, planning, support, operation, performance evaluation and improvement, with a set of AI-specific control objectives and controls in an annex. It expects the organisation to set AI policy and objectives, assess AI risks, assess the impact of its AI systems on individuals and society, and manage the system life cycle, including data and third-party suppliers.
• ISO/IEC 23894:2023 gives guidance on AI risk management, adapting the general risk management approach of ISO 31000 to AI. It is guidance, not a certification target.
• ISO/IEC 22989 defines AI concepts and terminology, which gives contracts, policies and audit reports a shared vocabulary.

What certification means is the part scenarios test. An accredited certification body audits the organisation and confirms that its AI management system meets the standard within a stated scope. It shows that there is a governed, repeatable process for developing or using AI and for managing its risks. It does not show that any particular model is accurate, fair or secure, and it says nothing about systems outside the scope. When a vendor offers an ISO/IEC 42001 certificate as evidence for a specific product, the questions are whether that product and the relevant sites are in scope, and when the certificate was issued and last audited. Organisations already certified to ISO/IEC 27001 can usually integrate 42001 into the same management system rather than build a second one.

The NIST AI Risk Management Framework and its functions

The NIST AI Risk Management Framework (AI RMF 1.0) was published in January 2023. It is voluntary and is not specific to any sector or use case: organisations adopt it by choice, or because a customer or contract asks them to.

It describes characteristics of trustworthy AI: valid and reliable; safe; secure and resilient; accountable and transparent; explainable and interpretable; privacy-enhanced; and fair, with harmful bias managed. The overlap with lesson 30 is deliberate.

Its core has four functions:

• Govern: the culture, policies, roles, accountability and processes for AI risk. It is cross-cutting, informing and running through the other three rather than being a step before them.
• Map: establish context. What is the system for, who is affected, what could go wrong, what are its limitations and dependencies? Most later failures trace back to a context nobody mapped.
• Measure: analyse and track the mapped risks with quantitative and qualitative methods, including testing, evaluation, verification and validation, and monitoring the trustworthiness characteristics over time.
• Manage: prioritise risks and act on them, by mitigating, transferring, avoiding or accepting, allocate resources, and plan response and recovery, including for third-party components.

NIST publishes a companion playbook with suggested actions per function, and profiles that tailor the framework to a context. NIST AI 600-1, the Generative AI Profile published in 2024, applies the framework to risks that are specific to or worsened by generative AI.

Exam scenarios often describe an activity and ask which function it belongs to. Assigning a model owner and writing policy is Govern; identifying stakeholders and intended use is Map; running a bias evaluation or red-team exercise is Measure; deciding to withdraw a model or add a human reviewer is Manage.

Choosing the framework a scenario's organisation is actually subject to

A scenario usually gives clues about obligation, and the right answer depends on separating what an organisation must do from what it chooses to adopt.

• Where do the system and its outputs reach? If it is placed on the EU market or its outputs are used in the EU, the EU AI Act may apply, whatever the organisation's home country. If it processes personal data of people in the EU, and the organisation is established in the EU or offers goods or services to, or monitors, people there, the GDPR applies to that processing, including data protection by design and data minimisation.
• What role does the organisation play? Building and selling a hiring tool makes it a provider; buying one and using it on its own candidates makes it a deployer. The obligations differ.
• What is the use? The same model is minimal risk filtering spam and high risk ranking job applicants.
• What does it need to prove, and to whom? A customer or partner asking for independent assurance points to ISO/IEC 42001 certification. A customer asking for alignment with the NIST AI RMF, or an internal programme looking for a structured method, points to the NIST AI RMF. A board asking what values the programme upholds points to the OECD principles.

These combine rather than compete. A common pattern is to use the NIST AI RMF as the working method, an ISO/IEC 42001 management system as the certifiable container, and a mapping to the EU AI Act and GDPR for the legal obligations, with the OECD values as the shared vocabulary. The usual distractor is treating a voluntary framework as satisfying a legal duty: adopting the NIST AI RMF does not make a high-risk system compliant with the EU AI Act, and a 42001 certificate does not either, though both produce much of the evidence that compliance needs.