No single standard. One coherent map.
There is no global rulebook for AI. Dozens of jurisdictions are writing their own, and the instruments that matter — binding regulation, risk frameworks, certifiable management systems, and the harmonised standards still being drafted — overlap as much as they diverge. They also keep moving. Knowing all of them is not the point. Knowing which bind you, which are still in flight, and how they fit together, is.
- Written against
- ISO 31000:2018 · ISO/IEC 23894:2023 · ISO/IEC 38500:2024 · ISO/IEC 38507:2022 · ISO/IEC 42001:2023 · ISO/IEC 42005:2025 · ISO/IEC 42006:2025 · NIST AI RMF 1.0 · IEEE 7000-2021 · Regulation (EU) 2024/1689
- Last updated
The instruments are not interchangeable, and the differences decide how each is used. Regulation sets what you must do, and differs sharply by jurisdiction. Risk frameworks set how to organize the work. Management systems make the result auditable.
EU AI Act
The first comprehensive AI law. Risk-tiered, enforceable, extraterritorial. Binding — this is the one with penalties.
US state law
No federal statute, so the map is state by state. Texas TRAIGA reaches developers and deployers generally; California SB 53 reaches frontier-model developers, with its heaviest duties triggered only above a revenue and compute threshold. Both applied from January 2026; Colorado’s replacement act applies from January 2027.
Canada — no AI statute
No comprehensive AI statute. What binds instead is privacy law and sector supervision — PIPEDA, Quebec’s Law 25, and OSFI Guideline E-23 for federally regulated financial institutions. Covered in full under supervision below.
NIST AI RMF
Govern, Map, Measure, Manage. Voluntary, but no longer without legal weight: Texas gives an affirmative defence to organizations substantially complying with its Generative AI Profile, or another recognised AI risk management framework, which reaches the ISO set too.
ISO/IEC 23894:2023
AI-specific risk management guidance built on the ISO 31000 clause structure. Cannot be implemented on its own.
ISO 31000:2018
General risk management. Its stated purpose — creating and protecting value — is why risk and value belong in one conversation.
ISO/IEC 42001:2023
The certifiable AI management system standard — the anchor for an auditable practice.
ISO/IEC 42005:2025
AI system impact assessment. Published, not proposed — the method behind a risk register that addresses consequences.
ISO/IEC 42006:2025
Requirements for bodies auditing and certifying an AIMS. Determines what an auditor will actually look for.
ISO/IEC 38507:2022
Written for the governing body: AI risk appetite, accountability, and a maintained view of every system in use.
OECD AI Principles
The shared intergovernmental baseline for trustworthy AI, adopted across dozens of countries and echoed in most national policy.
IEEE 7000-2021
Value-based engineering — ethical values elicited and traced into system design as requirements. Ethical value, never financial.
For most enterprises, three instruments do the heavy lifting. They are not alternatives — they interlock. The EU AI Act says what is required, NIST gives the structure to manage it, and ISO/IEC 42001 makes the result certifiable.
EU AI Act — the regulation with teeth
The first comprehensive AI law, structured by risk tier: prohibited practices, high-risk systems, limited-risk transparency duties, and minimal risk. Penalties reach up to 7% of global turnover. The timeline is staggered — prohibited practices and AI literacy are in force; general-purpose AI obligations applied from August 2025 and became enforceable in August 2026, alongside the Article 50 transparency duties; high-risk obligations were deferred to December 2027 for stand-alone systems and August 2028 where AI is embedded in regulated products. The deferral moved when the high-risk obligations apply, not what they require. The practical task is classifying each system into the right tier, and establishing whether you act as provider, deployer, or both.
NIST AI RMF — a working structure for AI risk
A voluntary US framework organized around four functions: Govern sets culture and accountability; Map establishes context and identifies risk; Measure analyzes and tracks it; Manage acts on it. It is not certifiable and creates no obligation, which is precisely why it travels well — it gives a team somewhere to start without committing the organization to an audit. It also maps cleanly onto the controls in ISO/IEC 42001, so work done here is rarely wasted later.
ISO/IEC 42001 — the AI management system
The first certifiable management-system standard for AI. It defines how an organization governs AI across its lifecycle — policy, risk assessment, controls, roles, and continual improvement — in the same shape ISO 27001 gives information security, which means an organization already certified there recognizes the machinery. Companion standards complete it: 42005 for impact assessment and 42006 for the bodies that certify. For most enterprises this is the anchor, because it converts intent into a practice a third party can examine.
The AI-specific instruments are recent. The disciplines they extend are not. Four standards supply the foundation, and recognizing them reduces the work rather than adding to it: an organization with a mature risk function or an established governance practice already holds most of the machinery.
- 01
ISO 31000 — risk management
Principles, framework, and process for managing risk in any organization. Its stated purpose is the creation and protection of value, which is the reason a serious AI risk practice also has to talk about return.
- 02
ISO/IEC 23894 — AI risk management
The bridge between the two. It mirrors ISO 31000's structure and extends its principles where AI differs — dynamism, the quality of available information, human and cultural factors. It presupposes the ISO 31000 baseline rather than replacing it.
- 03
ISO/IEC 38507 — governance for the governing body
Board-level guidance covering AI risk appetite, accountability, and the maintained inventory of systems in use. It is the standard that makes AI oversight a governance obligation rather than a technical one.
- 04
IEEE 7000 — ethics into design
A method for eliciting ethical values from stakeholders and tracing them into system requirements. Developed largely in Vienna with supporting German standards work, it gives responsible AI an engineering process rather than a statement of principle.
The instruments above operate at two levels, and the level decides how each one is used. Governance is the system by which the use of technology is directed and controlled, the governing body evaluates, directs, monitors. Management plans, builds, runs and monitors the activities delivering against that direction. Each body below describes both.
| Framework | Governance — the governing body | Management — the organization |
|---|---|---|
| ISO | ISO/IEC 38500, applied to AI by ISO/IEC 38507 — evaluate, direct, monitor. ISO/IEC 42001 reaches into this half too: policy, objectives, authorities and risk criteria (cl. 5, 6.1) and management review (9.3). | ISO/IEC 42001 — plan, do, check, act. Support and operation (cl. 7, 8), and most of Annex A. |
| NIST AI RMF | GOVERN — culture, accountability, risk tolerance. Cross-cutting by design rather than a stage. | MAP · MEASURE · MANAGE — establish context, analyse, and act. |
| OCEG | LEARN · ALIGN — context and stakeholders, then strategy to objectives. | PERFORM · REVIEW — operate the controls, then test design and operating effectiveness. |
Read across the table rather than down it. They differ in vocabulary and in where they draw the line, not in whether the line exists. An organization already running one of these has the machinery for the others — what it needs is the AI-specific extension, not a second programme.
The ISO row is the one worth reading closely, because the split runs inside a single standard rather than between two. ISO/IEC 42001 carries directive content, and at the two points where a decision belongs to the governing body and not to top management, its own notes hand off: clause 5.2 refers AI policy development to ISO/IEC 38507, and clause 6.1.1 refers the determination of risk appetite to ISO/IEC 38507 and ISO/IEC 23894. The boundary sits in the notes, not in the requirements, which is where it is easiest to pass over.
ISO/IEC 42001 says as much itself. Its introduction states that the document contains no specific guidance on management processes, and that an organization may combine generally recognised frameworks, other international standards, and its own experience to implement the processes it needs. The comparison is not imposed on the standards. It is what they invite.
The Digital Omnibus on AI deferred parts of the Act. What moved is when the high-risk obligations begin to apply, not what they require. Risk management, data governance, logging, transparency and human oversight were left exactly as they were, and they take longer to design and build than the new runway allows.
- —High-risk obligations for stand-alone Annex III systems — employment, credit, education, essential services — moved to 2 December 2027.
- —High-risk obligations for AI embedded in products already under EU product-safety regulation (Annex I) moved to 2 August 2028.
- —The deferral itself is a change to dates, but it did not travel alone. The Omnibus also added an Article 5 prohibition covering AI whose reasonably foreseeable output includes non-consensual intimate imagery or child sexual abuse material absent adequate safeguards, with a transition to 2 December 2026; narrowed the Annex I product scope; and consolidated enforcement over AI systems built on general-purpose models by the same provider. The Chapter III requirements themselves were not rewritten.
- —Prohibited practices and AI-literacy duties — in force since 2 February 2025.
- —General-purpose AI obligations — applied since 2 August 2025, enforceable by the Commission since 2 August 2026.
- —Article 50 transparency — disclosure that a user is dealing with AI, and marking of generative and synthetic media — since 2 August 2026. Systems already on the market have until 2 December 2026 for the machine-readable marking under Article 50(2).
- —The substance of the deferred duties. Risk management, data governance, logging and human oversight take longer to design and build than the runway now allows. What moved is the date they begin to apply, not what they require.
Prohibited practices · AI literacy
In force. Banned use cases apply outright, and staff working with AI must be demonstrably competent to do so.
General-purpose AI obligations
Applied to GPAI models placed on the market from this date: technical documentation, published training-data summaries, EU copyright compliance, and information sharing with regulators and downstream deployers.
Article 50 transparency · GPAI enforcement
Transparency duties apply — disclosure that a user is dealing with AI, and marking of generative and synthetic media. Generative systems already on the market before this date have until 2 December 2026 to meet the machine-readable marking requirement under Article 50(2). The Commission's enforcement powers over general-purpose AI models commence on the same date.
Legacy GPAI models
Models placed on the market before August 2025 lose their grace period and must be brought into compliance.
High-risk — stand-alone (Annex III)
Employment, credit, education, and essential-services systems. Deferred from 2026 — the runway is for building the inventory and classification now, not for waiting.
High-risk — embedded (Annex I)
AI embedded in products already covered by EU product-safety regulation, following the conformity-assessment route those products already use.
Penalties reach up to 7% of global turnover for the most serious breaches. Which of these obligations attach to you depends on the role the Act assigns — see below.
The Act assigns duties by role, not by whether you built the model. The role most organizations occupy is deployer, the party using an AI system under its own authority. Buying software with AI inside makes you a deployer, whether or not anyone in procurement noticed. The split is simple to state: the provider proves the system was built right, the deployer proves it is being used right.
- —Conformity assessment and CE marking before the system reaches the market.
- —Technical documentation, a risk management system, and data governance across the lifecycle.
- —Instructions for use detailed enough to make compliant deployment possible.
- —Post-market monitoring and serious-incident reporting.
- —Use in accordance with the provider’s instructions (Art. 26).
- —Human oversight assigned to people with both the competence and the authority to intervene.
- —Input data relevant and sufficiently representative, wherever you control it.
- —Operation monitored, and use suspended where risk emerges.
- —Automatically generated logs retained for at least six months.
- —Affected persons informed — including workers and their representatives before a high-risk system goes live.
- —A Fundamental Rights Impact Assessment where Article 27 applies: a deployer document no vendor can produce for you.
Article 25 turns a deployer into a provider. Put your own name or trademark on a high-risk system, make a substantial modification to it, or repurpose it into a high-risk use it was not sold for, and the full provider obligation set attaches — conformity assessment, CE marking, technical documentation. Fine-tuning a bought model can cross that line. So can pointing a general-purpose tool at a hiring, credit, or access decision.
None of this is transferable by contract. A vendor’s assurances are evidence that you exercised diligence; they are not a substitute for obligations the regulation places on you directly. Nor is the pattern EU-specific. ISO/IEC 42001 is scoped to organizations that provide or use AI — the standard says both — with a dedicated control set for responsible use (A.9) and for allocating responsibilities across third parties and suppliers (A.10).
The rules are supranational; enforcement is not. Which authority comes asking depends on where the organization sits, what the system decides, and which sector it operates in, and in both regions we cover, that answer changed during 2026.
The Act is European; enforcement is national. Germany’s implementing law — the Gesetz zur Marktüberwachung und Innovationsförderung von künstlicher Intelligenz, KI-MIG — passed the Bundestag on 11 June 2026, cleared the Bundesrat on 10 July, and entered into force at the end of that month, ahead of the Act’s own 2 August 2026 date. It settles a question that had been open for a year: who comes asking.
Germany chose a hybrid model rather than a new agency. The Bundesnetzagentur becomes the central market-surveillance authority, the single point of contact toward the EU AI Office, and the central complaints office, supported by the KoKIVO coordination and competence centre and the UKIM chamber. Sector regulators supplement it where they already hold the mandate — notably BaFin for the financial sector and the BSI on the cybersecurity of high-risk systems.
That split is not academic. Inside a single bank, systems can fall under different supervisory routes depending on what they decide, and establishing which authority governs which system is genuine work rather than a formality. For smaller organizations there is an upside worth using: the regulatory sandbox route is designed with access for SMEs and startups in mind.
Austria and Switzerland complete the picture differently. Austria set up the KI-Servicestelle at RTR as an advisory and information body, with a two-step expansion into a full national AI authority planned; the designation of its market-surveillance and notifying authorities ran past the August 2025 deadline. Swiss firms sit outside the Act domestically but are caught by its extraterritorial reach the moment they place an AI system on the EU market or its output is used there, which for most Swiss software businesses is the operative fact.
Canada has no comprehensive AI statute. The Artificial Intelligence and Data Act died with Bill C-27 when Parliament was prorogued in January 2025 and has not been reintroduced; the responsible minister has indicated that any future law would be a new design rather than a revival. In June 2026 the federal government launched a national AI strategy instead, with privacy and online-safety modernization among its stated priorities.
The absence of a statute is not an absence of obligation. What binds a Canadian organization today is privacy law and sector supervision. The Privacy Commissioner reads PIPEDA broadly enough to reach most AI systems handling personal information. Quebec’s Law 25 requires disclosure where a decision is made exclusively by automated processing, and gives the individual a right to an explanation, the closest thing to AI-specific law in force in the country. Ahead of both, federally regulated financial institutions face OSFI’s revised Guideline E-23 on model risk management, which brings AI and machine-learning models expressly into scope for the first time. It takes effect 1 May 2027 after an eighteen-month transition, which makes the preparation a 2026 exercise.
For organizations operating on both sides of the Atlantic, the binding constraint is often still the EU AI Act. Its extraterritorial reach attaches the moment a system is placed on the EU market or its output is used there, regardless of where the model was built.
A compliance programme built against one snapshot of this landscape will be wrong within a year. That is not an argument for waiting. It is an argument for building against obligations rather than against dates.
Four examples from the last eighteen months. The Digital Omnibus deferred the EU AI Act’s high-risk deadlines after they had already been set, moving when they apply while leaving what they require untouched. Colorado repealed and replaced its AI Act before the original ever took effect. Canada’s Artificial Intelligence and Data Act died with Bill C-27 and has not returned, leaving privacy law and sector supervision to carry the weight. And in Europe the harmonised standards that will eventually grant presumption of conformity — prEN 18228 for risk management, EN 18286 for quality management, the latter now through formal vote — are still not cited in the Official Journal, so Article 40 conformity cannot yet be claimed through them.
Nor is the landscape uniform. No jurisdiction outside the EU has a comparable timetable, and the United States has no federal statute at all, a state-by-state patchwork instead, with Texas and California in force since January 2026.
The practical consequence is a design principle. Build the risk management, data governance, logging and human oversight the regulation describes, and keep the mapping to specific clauses, standards and dates in a layer you can change. It is also why the classification work matters more than the calendar: once each system’s tier, role and exposure are established, mapping them onto whichever regime applies is comparatively mechanical, and it survives the next amendment. The obligations have proved far more stable than the deadlines and instruments attached to them.
The map is not the answer. It is the start of one.
Read together, the ISO set forms a coherent spine: 38507 places accountability with the board, 23894 governs how risk is managed, 42005 assesses impact, 42001 holds the management system, and 42006 defines what certification demands of it. But which of these apply to you — and what to actually do about them — depends on your systems, your risk surface, and the role the regulation assigns you. That is the conversation worth having.
Get a clear map of what applies to you.
Tell us where AI sits in your organization. We will respond with a read on which instruments apply, which are worth adopting voluntarily, and where one piece of work can satisfy several at once.
Start a conversation