| Scope boundary | 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. | 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. | 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. |
|---|
| Covered actors | Uses legal operator roles such as provider, deployer, importer, distributor, authorised representative, product manufacturer, and GPAI model provider, with duties varying by role. | Uses organisational responsibilities such as top management, AI management-system owner, risk owner, process owner, product owner, supplier owner, audit owner, and control performer. | 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. |
|---|
| Trigger | Binding EU law that lays down harmonised rules for artificial intelligence and creates enforceable obligations for covered operators. | International management-system standard for establishing, implementing, maintaining, and continually improving an AI management system within an organisation. | 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. |
|---|
| Core obligations | 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 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. | 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. |
|---|
| Evidence record | 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. | 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. | A shared repository is useful only if each item names the obligation or control it supports. Avoid a single undifferentiated evidence pack. |
|---|
| Risk categories and classification | 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. | Uses organisation-defined AI risk criteria, risk assessment, risk treatment, AI system impact assessment, and management-system controls rather than AI Act risk categories. | 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. |
|---|
| Enforcement | Enforced through AI Act governance, market-surveillance, supervisory, AI Office, and penalty mechanisms depending on the obligation, operator, and model/system type. | 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. | 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. |
|---|
| Overlap and reuse | 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 benefits from legal requirements as interested-party or applicable requirements that feed AI policy, risk criteria, operational controls, audit plans, and management review. | 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. |
|---|
| Practical decision rule | 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? | 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? | 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. |
|---|