ComparisonEU AI Act

EU AI Act vs ISO/IEC 42001

Separate binding EU AI Act obligations from ISO/IEC 42001 AI management-system controls, then decide where evidence can be reused without treating management-system assurance as legal compliance.

For product, model-risk, legal, security, procurement, privacy, audit, and compliance teams comparing AI Act role and risk duties with management-system governance.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
3

Structured answer sets in this page tree.

Primary sources
5

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

The EU AI Act and ISO/IEC 42001 solve different problems. The AI Act is binding EU law for AI systems and general-purpose AI models in defined roles and risk categories. ISO/IEC 42001 is an organisational AI management-system standard for organisations that provide or use AI systems. ISO/IEC 42001 can organise governance, risk, lifecycle, supplier, audit, and improvement evidence, but it does not supersede AI Act role classification, prohibited-practice screening, high-risk conformity assessment, GPAI obligations, Article 50 transparency duties, regulatory registration, CE marking, or enforcement exposure.

Side-by-side comparison

EU AI Act vs ISO/IEC 42001: what each one controls

Use these rows to decide which workstream owns the legal answer, which workstream owns management-system controls, and which evidence can be reused without overstating assurance.

Review all sources
First framework
EU AI Act

Binding EU regulation for AI systems and general-purpose AI models, with obligations driven by role, risk category, use case, market placement, deployment, transparency, and enforcement route.

Second framework
ISO/IEC 42001

AI management-system standard for organisations that provide or use AI systems, focused on governance, policy, risk, controls, documented information, audit, review, and improvement.

Comparison row 1

Scope boundary

EU AI Act

Starts from AI Act jurisdiction and activity: AI systems or GPAI models placed on the EU market, put into service, used in the Union, or producing outputs intended for use in the Union, subject to the Act's scope and exclusions.

ISO/IEC 42001

Starts from the organisation's defined AI management-system boundary: the activities, products, services, AI systems, roles, interested parties, requirements, and locations included in the management-system scope.

Operational implication

A supplier's ISO/IEC 42001 scope can be narrower than the AI Act fact pattern for the supplied AI system; request both the management-system scope and the AI Act role/risk classification.

Comparison row 2

Covered actors

EU AI Act

Uses legal operator roles such as provider, deployer, importer, distributor, authorised representative, product manufacturer, and GPAI model provider, with duties varying by role.

ISO/IEC 42001

Uses organisational responsibilities such as top management, AI management-system owner, risk owner, process owner, product owner, supplier owner, audit owner, and control performer.

Operational implication

Map both role systems. A team may own an ISO/IEC 42001 control but still need a separate legal owner for the AI Act provider, deployer, or GPAI model-provider obligation.

Comparison row 3

Trigger

EU AI Act

Binding EU law that lays down harmonised rules for artificial intelligence and creates enforceable obligations for covered operators.

ISO/IEC 42001

International management-system standard for establishing, implementing, maintaining, and continually improving an AI management system within an organisation.

Operational implication

ISO/IEC 42001 management-system evidence can support governance evidence, but it is not AI Act compliance evidence for a specific system, model, role, or use case unless it is tied to the exact AI Act duty.

Comparison row 4

Core obligations

EU AI Act

High-risk providers must address AI Act requirements such as risk management, data governance, technical documentation, record-keeping, transparency to deployers, human oversight, accuracy, robustness, cybersecurity, quality management, conformity assessment, declaration, CE marking where applicable, registration where required, post-market monitoring, and incident reporting.

ISO/IEC 42001

ISO/IEC 42001 can organise policy, role assignment, lifecycle governance, risk treatment, supplier controls, monitoring, audit, review, and corrective action around high-risk systems, but it does not itself perform the AI Act conformity assessment.

Operational implication

For each high-risk system, keep an AI Act conformity file. Link ISO/IEC 42001 controls as supporting evidence only where they satisfy the exact AI Act requirement being tested.

Comparison row 5

Evidence record

EU AI Act

Evidence is legal and system/model specific: AI Act role and risk classification, Annex basis or exception, prohibited-practice review, technical documentation, logs, instructions for use, FRIA where applicable, EU database registration, declaration, transparency notices, post-market monitoring, serious-incident records, and GPAI documentation.

ISO/IEC 42001

Evidence is management-system based: scope, AI policy, interested-party requirements, responsibilities, AI objectives, risk criteria, risk assessments, risk treatment plans, AI system impact assessments, operational controls, supplier controls, monitoring results, internal audits, management reviews, nonconformities, and corrective actions.

Operational implication

A shared repository is useful only if each item names the obligation or control it supports. Avoid a single undifferentiated evidence pack.

Comparison row 6

Risk categories and classification

EU AI Act

Classifies AI Act treatment by prohibited practices, high-risk systems, transparency-risk systems, minimal/no-risk systems, and GPAI model rules; Annex I and Annex III routes drive high-risk analysis.

ISO/IEC 42001

Uses organisation-defined AI risk criteria, risk assessment, risk treatment, AI system impact assessment, and management-system controls rather than AI Act risk categories.

Operational implication

Do not substitute an ISO risk rating for an AI Act risk category. Keep a legal high-risk/prohibited/transparency/GPAI determination beside management-system risk records.

Comparison row 7

Enforcement

EU AI Act

Enforced through AI Act governance, market-surveillance, supervisory, AI Office, and penalty mechanisms depending on the obligation, operator, and model/system type.

ISO/IEC 42001

Assured through customer due diligence, contracts, internal audits, management review, corrective-action processes, and any external management-system assessment the organisation chooses to use; ISO/IEC 42001 does not create AI Act penalties.

Operational implication

Regulatory exposure follows the AI Act, while assurance findings follow the management-system route. Escalate legal noncompliance, audit nonconformities, and customer evidence gaps through different owners.

Comparison row 8

Overlap and reuse

EU AI Act

The AI Act benefits from strong governance evidence, especially for high-risk risk management, quality management, documentation, monitoring, incident handling, and instructions for use.

ISO/IEC 42001

ISO/IEC 42001 benefits from legal requirements as interested-party or applicable requirements that feed AI policy, risk criteria, operational controls, audit plans, and management review.

Operational implication

Build one AI governance operating model with two labels on each control: the AI Act duty it supports, if any, and the ISO/IEC 42001 requirement or control objective it supports.

Comparison row 9

Practical decision rule

EU AI Act

Use the AI Act whenever the question is: is this practice prohibited, is this system high-risk, what operator role applies, what GPAI duties apply, what transparency notice is required, what conformity route applies, or what regulator-facing evidence is needed?

ISO/IEC 42001

Use ISO/IEC 42001 whenever the question is: does the organisation have a defined AI management-system scope, policy, roles, risk criteria, controls, monitoring, internal audit, management review, and improvement process for AI?

Operational implication

A reliable compliance file answers both questions separately and only reuses evidence after the relevant legal owner and management-system owner confirm the same artifact satisfies their different tests.

Practical decision rule

How should teams use ISO/IEC 42001 for EU AI Act compliance planning?

  • Use ISO/IEC 42001 to run the governance system: scope, policy, objectives, roles, risk criteria, impact assessment, operational controls, supplier oversight, monitoring, audit, management review, and corrective action.
  • Use the EU AI Act to answer legal classification and obligation questions: prohibited practice, high-risk status, operator role, GPAI status, transparency duty, conformity route, registration, declaration, post-market monitoring, incident reporting, and enforcement exposure.
  • For each AI system or GPAI model, keep one row that states what ISO/IEC 42001 evidence exists and a separate row that states what AI Act obligation that evidence supports.
  • Treat ISO/IEC 42001 conformity or audit evidence as assurance about the management system, not proof that each AI system or GPAI model satisfies the AI Act.
Section 1

Use the comparison to keep law and management-system assurance separate

Start with the AI Act fact pattern: whether there is an AI system or general-purpose AI model, which operator role applies, whether the use is prohibited, high-risk, transparency-limited, GPAI, or minimal/no-risk, and whether outputs are used in the Union.

Then scope ISO/IEC 42001 separately: which organisation, business unit, products, services, AI systems, roles, interested-party requirements, and AI management-system processes are inside the management-system boundary.

  • Do not label an AI system compliant with the AI Act merely because an organisation has ISO/IEC 42001 controls.
  • Use ISO/IEC 42001 to structure AI policy, risk criteria, lifecycle controls, supplier controls, audits, management review, nonconformity, and continual improvement.
  • Keep AI Act evidence tied to the exact legal duty: role, risk tier, article, annex, conformity route, registration item, disclosure, incident report, or GPAI obligation.
  • Where one record serves both workstreams, tag the same evidence with both the AI Act obligation and the ISO/IEC 42001 clause/control purpose.
Section 2

Where ISO/IEC 42001 helps and where it stops

ISO/IEC 42001 is useful when the practical problem is management: setting AI policy, defining scope, assigning responsibilities, assessing AI risks and impacts, integrating controls into operations, maintaining documented information, auditing, and improving the system.

The AI Act still controls legal outcomes. High-risk providers need AI Act technical documentation, quality management, conformity assessment, EU declaration of conformity, CE marking where applicable, EU database registration where required, post-market monitoring, and serious-incident handling. GPAI model providers need their own model documentation, transparency, copyright, systemic-risk, and AI Office-facing duties where applicable.

  • Use ISO/IEC 42001 as governance infrastructure for evidence readiness, not as a substitute legal test.
  • Use the AI Act to decide whether a model or system can be placed on the EU market, put into service, deployed, registered, labelled, or kept in operation.
  • Treat future harmonised AI Act standards separately from ISO/IEC 42001 unless a source shows the specific standard has been published for the relevant AI Act requirement.
  • For vendor assurance, ask both questions: what is inside the supplier's ISO/IEC 42001 scope, and what AI Act role and risk obligations apply to the supplied AI system or GPAI model?
Section 3

Evidence boundaries for a combined AI Act and ISO/IEC 42001 programme

A combined programme should keep one inventory but separate conclusions. The same AI inventory entry can list intended purpose, role, supplier, users, geography, data, lifecycle stage, risk controls, notices, logs, and owner, while the AI Act conclusion and the ISO/IEC 42001 conclusion remain distinct fields.

This boundary matters in audits and disputes. An ISO/IEC 42001 audit can show whether a management system is implemented and maintained within its scope. It does not by itself prove that a specific high-risk AI system passed the right AI Act conformity route, that an Annex III exception was documented correctly, that a GPAI model provider made the required information available, or that Article 50 notices were shown in the product experience.

  • AI Act evidence fields: operator role, risk tier, prohibited-practice result, high-risk basis or exception, applicable obligations, technical documentation, conformity route, registration, declaration, CE marking, transparency notice, post-market monitoring, and incident handling.
  • ISO/IEC 42001 evidence fields: management-system scope, AI policy, interested-party requirements, role assignments, AI objectives, risk criteria, risk assessment, risk treatment, AI system impact assessment, operational controls, monitoring, internal audit, management review, corrective action, and continual improvement.
  • Shared evidence fields: AI inventory, intended use, lifecycle owner, supplier record, user instructions, logs, test results, human oversight controls, change history, security controls, data-quality controls, and management approvals.
  • Boundary field: the legal or assurance question each evidence item answers, so later reviewers do not infer one framework's conclusion from the other's paperwork.
Recommended next step

Separate AI Act obligations from ISO/IEC 42001 controls before audit or launch

Sorena can help convert this comparison into role classification, risk-tier decisions, ISO/IEC 42001 control mapping, evidence requests, and review-ready supporting source references.

Primary sources

References and citations

eur-lex.europa.eu
Referenced sections
  • Primary legal source for the AI Act obligations that must remain distinct from management-system assurance.
"conformity assessment"
Related guides

Explore more topics

Are industry AI use cases high-risk under EU AI Act Annex III?
FAQ answer on when an industry AI use case falls under EU AI Act Annex III, how Article 6 classification works, when Article 6(3) can support a non-high-risk conclusion, and what evidence providers should keep.
EU AI Act AI System Classification Edge Cases FAQ
Answers for EU AI Act edge cases: AI system definition, inference versus simple rules, GPAI models, embedded products, territorial scope, roles, and classification evidence.
EU AI Act Applicability and Roles: Scope, Actor Map, and Evidence
Determine whether the EU AI Act applies to an AI system or GPAI model, map provider, deployer, importer, distributor, and product manufacturer roles, and record evidence for classification.
EU AI Act applicability test: scope, role, and risk classification
Stepwise EU AI Act applicability test for AI-system status, exclusions, territorial scope, operator role, prohibited uses, high-risk systems, GPAI models, transparency duties, and evidence records.
EU AI Act Article 5 Prohibited AI Practices Screening Guide
Screen AI systems against the EU AI Act Article 5 prohibitions, including manipulation, exploitation, social scoring, biometric and law-enforcement exceptions.
EU AI Act Article 50 transparency disclosures FAQ
Article 50 FAQ for EU AI Act transparency duties covering chatbot notices, synthetic content marking, biometric and emotion notices, deepfakes, public-interest text, timing, accessibility, and exceptions.
EU AI Act Article 50 transparency, labeling, and user disclosures
Source-grounded guide to EU AI Act Article 50 duties for user interaction notices, synthetic content marking, deepfake labels, emotion recognition notices, biometric categorisation notices, and related high-risk AI instructions for use.
EU AI Act Article 73 serious incident FAQ
FAQ on EU AI Act serious incident handling for high-risk AI systems, including Article 73 reporting, deployer escalation, corrective action, and GPAI systemic-risk distinctions.
EU AI Act Compliance Checklist by Risk Class
A practical EU AI Act checklist for classifying AI systems, assigning operator roles, screening prohibited practices, and collecting evidence for high-risk, GPAI, transparency, monitoring, and incident duties.
EU AI Act Compliance Program: roles, high-risk evidence, GPAI and incidents
Build an EU AI Act compliance program around provider, deployer, importer, distributor, high-risk, GPAI, transparency, monitoring, and incident evidence duties.
EU AI Act conformity assessment and notified bodies for high-risk AI
Grounded guide to EU AI Act high-risk AI conformity assessment routes, provider evidence, EU declaration of conformity, CE marking, and notified body involvement.
EU AI Act deadlines and compliance calendar | Article 113 dates
source-linked EU AI Act compliance calendar for Article 113 staged application dates, Article 111 transitions, GPAI, prohibited practices, AI literacy, and high-risk AI planning.
EU AI Act FAQ: scope, roles, high-risk AI, GPAI, FRIA, and dates
Grounded EU AI Act FAQ covering scope, provider and deployer roles, prohibited practices, high-risk classification, GPAI duties, transparency notices, FRIAs, EU database registration, serious incidents, and staged application dates.
EU AI Act FRIA FAQ: Article 27 Scope, Contents, and Notification
Source-grounded FAQ on when Article 27 requires a fundamental rights impact assessment, which deployers are covered, what the FRIA must contain, and how it relates to DPIAs and registration.
EU AI Act FRIA for high-risk AI systems: Article 27 scope and evidence
Source-grounded guide to EU AI Act Article 27 fundamental rights impact assessments: who must run a FRIA, Article 6(2) triggers, Annex III carveouts, DPIA overlap, notification, and registration evidence.
EU AI Act GPAI and Systemic-Risk Duties: Article 53 and 55 FAQ
FAQ on EU AI Act duties for general-purpose AI model providers, including Article 53 documentation, copyright and training-summary duties, Article 55 systemic-risk duties, serious incidents, cybersecurity, and staged enforcement.
EU AI Act GPAI evidence pack checklist for Article 53 and 55
Build a source-grounded evidence pack for EU AI Act GPAI model obligations: technical documentation, downstream information, copyright policy, training-content summary, and systemic-risk records where applicable.
EU AI Act GPAI Provider Obligations: Articles 53 and 55
Grounded guide to EU AI Act duties for general-purpose AI model providers: Article 53 documentation, copyright policy, training-content summary, downstream information, and Article 55 systemic-risk controls.
EU AI Act High-Risk AI Requirements: Articles 8-16 and 26
Map the EU AI Act requirements for high-risk AI systems: risk management, data governance, technical documentation, logs, transparency, human oversight, accuracy, robustness, cybersecurity, and deployer duties.
EU AI Act high-risk AI use cases by industry | Article 6 and Annex III guide
Industry-by-industry guide to EU AI Act high-risk classification under Article 6, Annex III, Annex I product safety routes, exclusions, and provider/deployer boundaries.
EU AI Act high-risk conformity assessment route selector
Select the EU AI Act Article 43 conformity assessment route for a high-risk AI system, including Annex I product legislation, Annex III categories, notified body triggers, standards, declaration, CE marking, registration, and evidence.
EU AI Act high-risk requirements checklist: Articles 8-15
Checklist for EU AI Act high-risk AI system requirements in Articles 8-15: risk management, data governance, documentation, logs, transparency, human oversight, accuracy, robustness, and cybersecurity.
EU AI Act penalties and fines: Article 99 tiers and GPAI exposure
EU AI Act penalties explained: Article 99 fine tiers, prohibited-practice exposure, incorrect information, SME caps, Member State rules, and GPAI model fines.
EU AI Act post-market monitoring and serious incident reporting
Grounded guide to EU AI Act Articles 72 and 73 for high-risk AI: monitoring plans, serious incident reporting, deployer escalation, corrective action, and GPAI distinctions.
EU AI Act post-market monitoring FAQ for high-risk AI systems
Answer to how providers and deployers should handle EU AI Act post-market monitoring for high-risk AI systems under Article 72, with serious-incident, log, corrective-action, and lifecycle-change triggers.
EU AI Act provider vs deployer role boundaries: Article 3 and Article 25 FAQ
FAQ on EU AI Act provider, deployer, operator, importer, distributor, authorised representative, product manufacturer, downstream provider, and GPAI model provider boundaries.
EU AI Act risk classification intake workflow
A grounded intake structure for classifying EU AI Act scope, prohibited practices, high-risk routes, Annex III use cases, GPAI model status, roles, and reassessment triggers.
EU AI Act serious incident reporting triage workflow: Article 73 and Article 55
Triage EU AI Act serious incidents by definition, actor, reporting route, deadline, deployer escalation, corrective action, and separate GPAI systemic-risk reporting.
EU AI Act Technical Documentation and Provider Evidence Templates
Build AI Act evidence templates for high-risk AI providers: Article 11 technical documentation, Annex IV fields, quality management, conformity, CE marking, registration, logs, and post-market monitoring.
EU AI Act technical documentation FAQ | Article 11 and Annex IV
What Article 11 and Annex IV require in high-risk AI technical documentation: system identity, intended purpose, architecture, data, testing, oversight, cybersecurity, conformity, and post-market monitoring.
EU AI Act Timeline and Phasing Roadmap: practical obligations and evidence guide
Practical EU AI Act guide to Timeline and Phasing Roadmap: scope, owners, evidence, edge cases, checklist steps, and external source-linked citations.
EU AI Act vs NIST AI RMF: legal duties, risk controls, and evidence boundaries
Compare the binding EU AI Act with the voluntary NIST AI RMF, including role classification, high-risk duties, GPAI, transparency, conformity evidence, and reuse limits.
FAQ: EU AI Act conformity assessment procedures and notified body selection
source-linked FAQ on EU AI Act Article 43 conformity assessment routes, Annex VI internal control, Annex VII notified-body review, CE marking, declarations, and registration.