Founding cohortBe among the first to sit GRCP examinations when registration opens.Register interest →
GRCP™

Mapping ISO/IEC 42001 to EU AI Act obligations

Where an AI management system covers the Act's requirements, where it falls short, and what the Digital Omnibus and the first harmonised standard change.

Organisations preparing for the EU AI Act often already run, or are building, an AI management system based on ISO/IEC 42001:2023. It makes sense to ask whether one system can serve both. In large part it can. The standard and the Regulation share a risk-based outlook, and many of the processes the Act expects can sit within a 42001 framework.

Both instruments have changed recently. Regulation (EU) 2026/1744, known as the "Digital Omnibus on AI", was published in the Official Journal on 24 July 2026. It moved the high-risk deadlines. Obligations for stand-alone high-risk systems listed in Annex III now apply from 2 December 2027, not 2 August 2026. Obligations for AI embedded in products covered by Annex I Section A now apply from 2 August 2028. The prohibitions, AI literacy and general-purpose AI rules were already in force from 2025. The Omnibus also reworded the AI literacy duty in Article 4. Providers and deployers must now support the development of AI literacy among their staff, rather than ensure a particular level. The extra time is useful, but practitioners should treat it as time to prepare properly, not as a reason to wait.

A second, more technical change matters just as much. On 14 October 2026, Commission Implementing Decision (EU) 2026/2274 cited EN 18286:2026 in the Official Journal. EN 18286 is a quality management system standard written specifically for AI Act purposes, and it is the first harmonised standard under the Act.

Where ISO/IEC 42001 lines up well

ISO/IEC 42001 follows the familiar management system structure (clauses 4 to 10). It adds Annex A reference controls, implementation guidance in Annex B, and further informative annexes on objectives, risk sources and integration with other management systems. Several of its elements correspond closely to the Act's requirements for high-risk systems and their operators.

AI Act obligation Article Closest ISO/IEC 42001 element
AI literacy Art. 4 Cl. 7.2 (competence), 7.3 (awareness)
Risk management system Art. 9 Cl. 6.1.2–6.1.3, 8.2–8.3; Annex A.5 (ISO/IEC 23894 as guidance)
Data and data governance Art. 10 Annex A.7 (data acquisition, quality, provenance, preparation)
Technical documentation Art. 11 A.6.2.3, A.6.2.7 (design and technical documentation)
Record-keeping (logging) Art. 12 A.6.2.8 (recording of event logs)
Transparency and information to deployers Art. 13 A.8.2 (system documentation and information for users)
Human oversight Art. 14 No dedicated control; partly through A.6.2.2 (requirements) and A.9 (responsible use)
Accuracy, robustness, cybersecurity Art. 15 A.6.2.4 (verification and validation), A.6.2.6 (operation and monitoring); ISO/IEC 27001 for security
Quality management system Art. 17 Clauses 4–10 as a whole
Deployer obligations Art. 26 A.9 (intended and responsible use), A.10 (third-party relationships)
Fundamental rights impact assessment Art. 27 Cl. 6.1.4, 8.4; A.5 (ISO/IEC 42005 as guidance)

The fit is strongest at the organisational level: leadership accountability, defined roles, risk and impact assessment, life-cycle controls, supplier management, internal audit and corrective action. ISO/IEC 42005:2025, on AI system impact assessment, gives useful method for the Article 27 fundamental rights impact assessment (FRIA). It does not replace the FRIA. That obligation falls mainly on public bodies, private entities providing public services, and deployers of certain credit-scoring and insurance-pricing systems, and the results must be notified to the market surveillance authority.

Where it falls short

Overlap in topics does not mean the system conforms to the Act. Several gaps are structural.

Presumption of conformity. Certification to ISO/IEC 42001 does not give a presumption of conformity under the AI Act. A presumption arises only from harmonised standards cited in the Official Journal under Article 40. Even EN 18286 gives a narrow presumption, covering Article 17(1) and the first sentence of Article 11(1). It does not cover the substantive requirements in Articles 9, 10 and 12 to 15. The Commission has said EN 18286 is designed to sit on top of international standards such as ISO/IEC 42001, not to replace them. Harmonised standards for the remaining areas, including risk management, data governance, logging, human oversight, accuracy, robustness and cybersecurity, are still being drafted within CEN-CENELEC JTC 21.

Product-level conformity assessment. ISO/IEC 42001 certifies an organisation's management system. The Act assesses individual systems. Under Article 43, most Annex III systems follow internal control under Annex VI. Some biometric systems require a notified body, and Annex I products go through their existing sectoral procedures. Each substantial modification requires a fresh assessment. An ISO/IEC 42006-accredited certification audit is a different exercise from any of these.

Technical documentation content. Annex A.6.2.7 asks for appropriate technical documentation. Article 11 and Annex IV set out the required contents in far more detail, and a generic documentation control will not produce that file.

CE marking, declaration and registration. The EU declaration of conformity, the CE marking and registration in the EU database are regulatory outputs that 42001 does not address.

Post-market monitoring and serious incidents. Under Article 72, providers need a documented post-market monitoring system and plan. Article 73 sets fixed reporting deadlines. The general limit is 15 days after the provider becomes aware of a serious incident. It is two days for widespread infringements and for incidents involving serious and irreversible disruption of critical infrastructure, and ten days where a death occurs. Annex A.8.4 (communication of incidents) is a starting point, but it sets no deadlines and names no recipients.

Specific data governance requirements. Article 10 lists concrete practices. These include documenting design choices and data origin, examining and mitigating bias, ensuring that datasets are representative and as free of errors as possible, and reflecting the setting in which the system will be used. The Omnibus also moved the legal basis for processing special category data for bias detection into a new Article 4a, and made it subject to a strict necessity test. The A.7 controls point in the right direction but are far less prescriptive.

Practical recommendations

  • Classify first. Build an AI inventory that records your role (provider, deployer or both) and each system's risk category before mapping any controls.
  • Treat 42001 as the backbone, not the answer. Keep a regulatory requirements register that traces each applicable article to a specific process, control and piece of evidence.
  • Assess EN 18286 against your quality management system. If you are a provider of high-risk systems, close the gaps between your 42001 processes and EN 18286, using its informative mapping annexes.
  • Build the regulatory outputs separately. Create product-level templates for Annex IV technical documentation, declarations of conformity, post-market monitoring plans and serious incident playbooks with the Article 73 deadlines built in.
  • Make impact assessment a single process. Use clause 6.1.4 and ISO/IEC 42005 as one process that produces the FRIA, the GDPR DPIA input and the AI system impact assessment, with clear cross-references between them.
  • Integrate rather than duplicate. Article 17 allows providers already subject to sectoral quality management obligations to fold the AI requirements into those systems. Financial institutions can largely rely on their existing governance rules, except for risk management, post-market monitoring and incident reporting.
  • Track the standards pipeline. Plan to re-baseline as further harmonised standards are cited.

Closing thoughts

ISO/IEC 42001 gives organisations a sound management structure for governing AI, and much of what the AI Act expects can run through it. But the Act regulates products and their placing on the market, not just organisational discipline. Practitioners who state that difference clearly, and who build the product-level evidence the Act requires on top of a certified management system, will be better placed than those who treat a certificate as compliance. The revised timeline gives room to do this carefully. It does not change what has to be done.

This article is for general information and is not legal or professional advice.