ISO/IEC 42001 is a voluntary, certifiable management-system standard; the EU AI Act is binding law with duties determined by territorial scope, operator role, regulated object, risk class, and application date.
An AIMS can organise evidence used for AI Act work. ISO/IEC 42001 certification does not create a presumption of conformity with the Act or replace its classification, technical, transparency, conformity-assessment, registration, or post-market duties.
Run two linked analyses. First determine whether and how the applies to each system or general-purpose AI model; it is binding EU law for actors and activities within its territorial scope. Separately define the AIMS scope and ISO/IEC 42001 processes; the standard is voluntary unless another commitment makes it applicable. Reuse evidence only after identifying which legal requirement and which management-system requirement it supports.
Side-by-side comparison
ISO/IEC 42001 vs EU AI Act: scope, duties, evidence, and decision rule
This side-by-side comparison helps teams decide when to apply ISO/IEC 42001 as the primary framework, when analysis takes priority, and how to sequence evidence by framework purpose.
Use ISO/IEC 42001 to structure a defined AIMS, its risk and impact processes, controls, monitoring, audit, management review, and improvement.
Second framework
EU AI Act
Use the to determine binding obligations from territorial scope, operator role, prohibited or high-risk classification, transparency duties, GPAI status, and staged application dates.
ISO/IEC 42001 vs EU AI Act: scope, duties, evidence, and decision rule
Document the AIMS boundary and AI Act applicability separately; an organisation-wide certification scope cannot replace system- or model-specific legal analysis.
ISO/IEC 42001 ownership should sit with the team that can operate the relevant management system, control process, risk method, supplier relationship, incident process, privacy process, or AI governance scope.
The AI Act assigns duties to defined operators such as providers, deployers, importers, distributors, authorised representatives, product manufacturers, and providers of general-purpose AI models. One organisation can hold several roles.
ISO/IEC 42001 work is triggered by scope definition, implementation, certification readiness, customer assurance, control gaps, incidents, supplier changes, or management review.
analysis is triggered by the Regulation's territorial scope, including relevant placement on the market, putting into service, use in the Union, or output used in the Union, followed by the facts that determine operator role and the applicable system or model duties.
At intake, record both decisions: whether the activity is inside the AIMS and whether the Regulation applies to the organisation, system or model. A negative answer on one side does not decide the other.
The requires legal compliance work tied to the specific role and risk class of the system: prohibited-practice checks, high-risk requirements, transparency duties, conformity assessment, registration, and post-market monitoring.
A shared task register is useful only when each task cites the controlling AI Act provision and the relevant ISO/IEC 42001 clause or selected control separately.
ISO/IEC 42001 evidence should show the process operating: owners, decisions, registers, control records, test results, review minutes, audit samples, or corrective actions.
AI Act evidence depends on the duty and can include technical documentation, instructions, logs, quality- and risk-management records, conformity documentation, registration, transparency information, post-market monitoring, and incident records.
ISO/IEC 42001 timing follows implementation, audit, certification, review, supplier, incident, or change cycles rather than a single universal deadline.
The Act applies in stages. Chapters I and II applied from 2 February 2025 and Article 113(3)(b) provisions from 2 August 2025. The Council's 29 June 2026 final approval of the Digital Omnibus moves high-risk rules for Annex III stand-alone systems to 2 December 2027 and product-embedded systems to 2 August 2028, subject to signature, Official Journal publication, and entry into force of the amending act.
Record the applicable provision, operator, system or model, placement date, transition rule, amending-act publication status, and deadline. Keep those dates separate from AIMS audit and certification cycles.
ISO/IEC 42001 is usually tested through certification audits, internal audits, customer assurance, management review, or governance review, depending on how the organization adopts it.
is enforced as binding EU law through market-surveillance authorities, notified-body and conformity-assessment routes where applicable, post-market monitoring, and penalty exposure.
ISO/IEC 42001 can supply management-system evidence such as scope, roles, risk and impact assessments, treatment decisions, controls, monitoring, audits, reviews, and corrective actions.
The AI Act may use some of the same underlying records, but the Act's legal tests and required documents remain controlling. ISO/IEC 42001 certification does not create presumption of conformity with the Act.
Reuse a record only after checking the legal actor, regulated object, system version, scope, date, acceptance criteria, retention rule, and required approval. Preserve separate conclusions.
Use the as the controlling source whenever the work concerns legal scope, operator role, prohibited practices, risk classification, GPAI, transparency, conformity, registration, monitoring, reporting, or enforcement.
Document the AIMS boundary and AI Act applicability separately; an organisation-wide certification scope cannot replace system- or model-specific legal analysis.
ISO/IEC 42001 ownership should sit with the team that can operate the relevant management system, control process, risk method, supplier relationship, incident process, privacy process, or AI governance scope.
The AI Act assigns duties to defined operators such as providers, deployers, importers, distributors, authorised representatives, product manufacturers, and providers of general-purpose AI models. One organisation can hold several roles.
ISO/IEC 42001 work is triggered by scope definition, implementation, certification readiness, customer assurance, control gaps, incidents, supplier changes, or management review.
analysis is triggered by the Regulation's territorial scope, including relevant placement on the market, putting into service, use in the Union, or output used in the Union, followed by the facts that determine operator role and the applicable system or model duties.
At intake, record both decisions: whether the activity is inside the AIMS and whether the Regulation applies to the organisation, system or model. A negative answer on one side does not decide the other.
The requires legal compliance work tied to the specific role and risk class of the system: prohibited-practice checks, high-risk requirements, transparency duties, conformity assessment, registration, and post-market monitoring.
A shared task register is useful only when each task cites the controlling AI Act provision and the relevant ISO/IEC 42001 clause or selected control separately.
ISO/IEC 42001 evidence should show the process operating: owners, decisions, registers, control records, test results, review minutes, audit samples, or corrective actions.
AI Act evidence depends on the duty and can include technical documentation, instructions, logs, quality- and risk-management records, conformity documentation, registration, transparency information, post-market monitoring, and incident records.
ISO/IEC 42001 timing follows implementation, audit, certification, review, supplier, incident, or change cycles rather than a single universal deadline.
The Act applies in stages. Chapters I and II applied from 2 February 2025 and Article 113(3)(b) provisions from 2 August 2025. The Council's 29 June 2026 final approval of the Digital Omnibus moves high-risk rules for Annex III stand-alone systems to 2 December 2027 and product-embedded systems to 2 August 2028, subject to signature, Official Journal publication, and entry into force of the amending act.
Record the applicable provision, operator, system or model, placement date, transition rule, amending-act publication status, and deadline. Keep those dates separate from AIMS audit and certification cycles.
ISO/IEC 42001 is usually tested through certification audits, internal audits, customer assurance, management review, or governance review, depending on how the organization adopts it.
is enforced as binding EU law through market-surveillance authorities, notified-body and conformity-assessment routes where applicable, post-market monitoring, and penalty exposure.
ISO/IEC 42001 can supply management-system evidence such as scope, roles, risk and impact assessments, treatment decisions, controls, monitoring, audits, reviews, and corrective actions.
The AI Act may use some of the same underlying records, but the Act's legal tests and required documents remain controlling. ISO/IEC 42001 certification does not create presumption of conformity with the Act.
Reuse a record only after checking the legal actor, regulated object, system version, scope, date, acceptance criteria, retention rule, and required approval. Preserve separate conclusions.
Use the as the controlling source whenever the work concerns legal scope, operator role, prohibited practices, risk classification, GPAI, transparency, conformity, registration, monitoring, reporting, or enforcement.
How should teams decide between ISO/IEC 42001 and EU AI Act for compliance planning?
Run the AI Act applicability and classification analysis first whenever the organisation places, puts into service, deploys, imports, distributes, or supplies an AI system or general-purpose AI model connected to the Union.
Run the ISO/IEC 42001 scope and conformity analysis separately whenever the organisation chooses to establish, operate, audit, or certify an AIMS.
When both apply, map provisions and clauses to shared records without claiming equivalence, legal approval, or presumption of conformity.
Do you need ISO/IEC 42001, EU AI Act compliance, or both?
Start with the . Determine territorial scope, the organisation's operator role, and whether the regulated object is an AI system or a general-purpose AI model. Then test prohibited practices, transparency duties, general-purpose AI model duties, and high-risk status. High-risk examples can include systems used for recruitment, education access, creditworthiness, essential public benefits, certain biometric uses, critical infrastructure, law enforcement, migration, and justice, but Article 6, Annex I or III, and any exclusion or qualification control the result for the specific system.
Run the ISO/IEC 42001 analysis separately. Define the AIMS boundary, the organisation's roles in relation to AI systems, relevant interested-party requirements, risk criteria, risk assessment and treatment, impact assessment, controls, monitoring, internal audit, management review, and improvement.
Use both when the organisation wants an auditable management system and also falls within the Act. A shared inventory and shared evidence repository can reduce duplicate work, but every reused record must still satisfy the specific legal provision and the specific AIMS requirement.
Choose ISO/IEC 42001 as the lead source for establishing, operating, auditing, or certifying an AIMS.
Choose the as the controlling source for legal scope, operator roles, prohibited practices, high-risk classification, transparency, general-purpose AI model duties, conformity assessment, registration, monitoring, incident reporting, and penalties.
Do not describe ISO/IEC 42001 as an AI Act harmonised standard unless its reference has been published in the Official Journal for the relevant requirements. The Commission states that ISO/IEC 42001:2023 is not aligned with the quality-management-system standard requested for the Act.
For ISO/IEC 42001, retain the documented AIMS scope, AI policy, role assignments, risk criteria, risk assessments, treatment plans, statement of applicability, impact assessments, operating controls, monitoring results, internal-audit records, management-review outputs, and corrective actions.
For the AI Act, the required evidence depends on the role and provision. A high-risk-system provider may need a risk-management system, data-governance records, technical documentation, logs, instructions for use, human-oversight design, accuracy and cybersecurity evidence, a quality-management system, conformity documentation, registration, post-market monitoring, and serious-incident records. Deployers, importers, distributors, product manufacturers, authorised representatives, and general-purpose AI model providers have different records.
A record can serve both sets only when its scope, system version, actor, acceptance criteria, approval, retention period, and review trigger fit both requirements. Certification evidence alone does not prove that a legal duty has been met.
Applicability record: establishment locations, market and use facts, affected persons, operator roles, system or model identity, intended purpose, exclusions considered, classification, and applicable dates.
Requirement map: one row per AI Act provision and ISO/IEC 42001 requirement, with owner, evidence, system version, approval status, gap, and review trigger.
Operating evidence: tests, logs, instructions, approvals, supplier records, monitoring results, incident decisions, and corrective actions generated by the process.
Assurance record: keep the ISO certification scope and audit conclusion separate from any AI Act conformity assessment, declaration, registration, or authority communication.
Give every AI system and general-purpose AI model a stable identifier. Use it to link the legal applicability record, the AIMS inventory entry, risk and impact assessments, controls, tests, supplier evidence, incidents, and review decisions without merging their conclusions.
Reopen the analysis when the intended purpose, operator role, model or system version, deployment geography, supplier, data, affected population, or legal classification changes. A scheduled AIMS audit is not a substitute for a legal change trigger or statutory deadline.
1. Identify the system or model, intended purpose, provider chain, users, affected persons, territories, and lifecycle stage.
2. Assign every AI Act operator role held by the organisation; one organisation can hold more than one role.
3. Test prohibited-practice, high-risk, transparency, and general-purpose AI model provisions, including exclusions and application dates.
4. Define the AIMS scope and organisational roles, then run ISO/IEC 42001 risk, impact, control, monitoring, audit, review, and improvement processes.
5. Map evidence at provision or clause level. Record gaps rather than treating similar labels as equivalent.
6. Route legal conformity decisions to the accountable legal or regulatory owner and AIMS conformity decisions to the management-system owner and, when used, the certification body.
Do not claim that ISO/IEC 42001 certification equals AI Act compliance, that it is currently the Act's harmonised quality-management-system standard, or that it creates a presumption of conformity. Under Article 40, that presumption depends on compliance with harmonised standards whose references are published in the Official Journal, and only to the extent that those standards cover the relevant requirements.
Do not import an AIMS role into the Act, use an organisational risk rating as the Act's legal classification, or treat an internal audit as the required conformity assessment. Also avoid describing every AI system as high-risk: the result depends on Article 6, Annex I or III, and any applicable exclusion or qualification.
Do not cite a standard title as evidence that a process is operating.
Do not reuse an old audit artifact after the scope, service, supplier, or risk has changed.
Do not hide exceptions; record them as risk acceptance, corrective action, or management-review inputs.
Which AI Act dates must the AIMS calendar keep separate?
The Act entered into force on 1 August 2024 and applies in stages. Chapters I and II applied from 2 February 2025. The provisions listed in Article 113(3)(b), including Chapter V on general-purpose AI models and most penalty provisions, applied from 2 August 2025. The Council gave final approval to the Digital Omnibus on AI on 29 June 2026: the approved amendments move the high-risk rules for Annex III stand-alone systems to 2 December 2027 and the rules for high-risk systems embedded in regulated products to 2 August 2028. The amending act must be signed and published in the Official Journal before it enters into force, so retain the published legal text used for each deadline.
Those dates do not answer every transition question. Article 111 contains rules for some systems and models already placed on the market, including a 2 August 2027 compliance deadline for providers of general-purpose AI models placed on the market before 2 August 2025. The approved Digital Omnibus changes other application and transition provisions, including a 2 December 2026 deadline for certain AI-generated-content transparency solutions. Record the exact provision, amending text, publication status, and transition rule used for each conclusion.
Maintain a legal deadline field separately from the next AIMS review, audit, and certification dates.
Trigger reassessment for significant changes, changed intended purpose, new operator roles, new territories, serious incidents, or a revised legal classification.
Update downstream technical documentation, registration, instructions, monitoring, and AIMS records when the decision changes.
ISO/IEC 42001 identifies the management-system requirements side of this comparison, separating voluntary certification evidence from EU AI Act legal duties.
"requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System"