Does ISO 42001 certification satisfy the EU AI Act?
ISO/IEC 42001 certification does not satisfy the EU AI Act by itself. The Regulation does not refer to ISO/IEC 42001 or to certification against it, and a certificate does not give a presumption of conformity. Under Article 40(1), only harmonised standards whose references are published in the Official Journal do that. The first such standard, EN 18286:2026 on quality management, was cited on 14 October 2026 through Commission Implementing Decision (EU) 2026/2274. A customer or regulator asking for AI Act evidence alongside an ISO 42001 certificate is therefore asking two different questions, and the certificate answers only part of one of them.
Whether the certificate helps, and how much, depends on your role, the risk tier of the system and the date that applies to it. A provider of an Annex III high-risk system must show a quality management system covering the aspects listed in Article 17, along with technical documentation and a conformity assessment route. A deployer has a different set of duties, and a provider of a general-purpose model is governed by Chapter V and supervised by the AI Office. The high-risk rules for Annex III systems apply from 2 December 2027 after the 2026 amendment, so a provider planning a launch in the meantime should confirm which dates govern its system before choosing a standard to build against.
In practice, start by mapping your certificate's scope against the AI Act roles you hold. Ask your certification body and your readiness partner which clauses and optional controls of ISO/IEC 42001 you have implemented, and whether logging and record keeping are among them, since a 2023 Commission JRC report found those covered only to a limited degree. Then decide whether to plan against EN 18286:2026 for the quality management part, and confirm with your auditor how an ISO 42001 audit trail would be presented to a market surveillance authority. An AI management system still helps with governance, but it does not replace the Article 17 evidence.
How EN 18286:2026 maps to the Article 17 quality management system
Article 17 requires providers of high-risk AI systems to run a quality management system covering at least 13 aspects. EN 18286:2026 is the first harmonised standard cited for that duty, and it addresses the QMS part of the Commission's standardisation request C(2025) 3871. The cards below show what the standard is expected to cover and what your counsel should check against the standard text.
Compliance strategy and accountability
Article 17 expects the QMS to set out how the provider secures conformity, including the procedures, the responsible roles and the management accountability for them. In an ISO/IEC 42001 program, this maps most naturally to the AI policy, roles and management review. Confirm with counsel whether EN 18286:2026 names a specific accountable role or leaves the allocation to the provider, because that determines which governance records an assessor will ask for.
Design control and system design records
The QMS must cover design and design-verification procedures for the high-risk system, including the techniques used to design and control it. Provider teams usually hold this evidence in architecture reviews, design tickets and change approvals, scattered across tools. Ask whether the standard requires a documented design history for each system version, and whether your current ISO/IEC 42001 controls already produce records at that level of detail.
Testing and validation procedures
Article 17 requires examination, test and validation procedures to run before, during and after development, with defined frequency and acceptance criteria. Evidence typically includes test plans, pre-release results and sign-off records. Confirm with counsel how EN 18286:2026 expects testing to be linked to the performance metrics in the technical documentation, since a generic test log will not show that the system meets its intended purpose.
Data management procedures
The QMS must include data management procedures for acquisition, collection, analysis, labelling, storage, filtration and retention of training, validation and testing data. ISO/IEC 42001 covers data at a high level, so many providers need a dedicated data lineage record. Check with counsel whether EN 18286:2026 sets the depth of data governance evidence, and whether bias examination is handled here or in the separate AI Act standards still in progress.
Risk management and post-market monitoring
The QMS must connect the risk management system described in Article 9 to post-market monitoring, so that field data feeds back into risk decisions. Records include monitoring plans, incident triage and corrective actions. The EU AI Act risk management standard, prEN 18228, was still in progress when CEN-CENELEC reported in May 2026, so confirm with counsel which risk management duties EN 18286:2026 covers in full and which still depend on that work.
Serious incident reporting and record keeping
Article 17 expects the QMS to cover serious incident reporting procedures and record keeping for the system's lifetime. A JRC analysis of ISO/IEC 42001 found logging and record keeping covered only to a limited degree, as an optional control. Treat this as a gap to close deliberately: define log retention, incident intake and reporting roles, then ask counsel to confirm the exact retention and reporting obligations in the Act before relying on the standard for them.
Where ISO/IEC 42001 and the AI Act QMS overlap and where they differ
This table compares ISO/IEC 42001:2023 with the AI Act's Article 17 quality management system duty and the harmonised standard EN 18286:2026 across legal status, presumption of conformity, logging, risk controls, post-market monitoring and certification route. Read each row as a question: what the AI Act requires, and whether a certified AI management system alone answers it.
| Aspect | ISO/IEC 42001:2023 | AI Act Article 17 and EN 18286:2026 |
|---|---|---|
| Legal status | Voluntary international management system standard published by ISO/IEC | Article 17 is binding for high-risk providers; EN 18286:2026 is a harmonised standard cited in the Official Journal |
| Presumption of conformity | No presumption of conformity with the AI Act | Only harmonised standards with references in the Official Journal give a presumption under Article 40(1) |
| Scope of the QMS | Requirements for establishing, maintaining and improving an AI management system | At least 13 aspects, including compliance strategy, design control, testing, data management and accountability |
| Logging and record keeping | Covered only to a limited degree, as one of the optional controls | Record-keeping is a named QMS aspect the provider must maintain |
| Risk controls | Risks and controls are high-level and flexible, with optional items the organization selects | Risk management is a required QMS aspect tied to the high-risk requirements of Articles 8 to 15 |
| Post-market monitoring | Not addressed as a specific regulatory process | Post-market monitoring processes are covered by EN 18286:2026, which answers the QMS part of standardisation request C(2025) 3871 |
| Certification route | Certification by an accredited body is possible, but the AI Act does not refer to ISO/IEC 42001 certification | Internal control under Annex VI or notified body assessment under Annex VII; confirm which route applies to your system |
| Use for AI Act evidence | Helps show governance structure, but must be mapped to Article 17 and checked by an assessor | Written to support Article 17 conformity, though sectoral QMS and Article 17(3) and (4) provisions may also apply |
What the Commission's JRC found missing from ISO/IEC 42001
The 2023 Commission Joint Research Centre analysis of the preliminary AI standardisation work plan found ISO/IEC 42001 broadly in line with the AI Act's quality management system requirement in Article 17. The gap is in depth. The standard is high-level and flexible, and several of its risk and control items are optional, so an organization can certify against it without having addressed every point an assessor would expect to see for AI Act purposes. The JRC view is that this limits how far an ISO/IEC 42001 certificate can be used to show regulatory compliance on its own. Treat the certificate as evidence of a governance system, not as proof that a specific high-risk system meets the Act.
Logging and record keeping is the clearest example. The same JRC report found these topics covered only to a limited degree in ISO/IEC 42001, and only through optional controls. Article 12 expects high-risk systems to support automatic event logging over their lifetime, and Article 17 expects record keeping to be part of the provider's quality management system. Before relying on a certificate, list the Annex A controls you have selected and map each one to the Article 12 and Article 17 evidence it would produce, such as log retention settings, change records and post-market monitoring reports. Where a control is not selected, or selected without a defined log scope, the gap belongs in your remediation plan. Confirm this mapping with your certification body and with your legal team, because the mapping is your own work and no certificate performs it for you.
Do not assume that selecting a control means it covers the AI Act requirement behind it. Ask the implementation partner and the auditor to walk through each mapped control and show the record it produces. Confirm the current status of harmonised standards with your own compliance adviser, since the Commission has cited EN 18286:2026 as the first harmonised quality management standard and other AI Act standards were still in progress when CEN-CENELEC reported in May 2026.
What ISO 42001 changes for providers, deployers and general-purpose model providers
A provider of a high-risk AI system must run a quality management system that meets Article 17, which lists at least 13 aspects including compliance strategy, design control, testing, data management, risk management, post-market monitoring, serious incident reporting, record-keeping and accountability. The Commission's first harmonised standard, EN 18286:2026, is a quality management standard that answers the quality management part of the Commission's standardisation request, so a provider that follows it has a clearer route to show conformity with Article 17. An ISO/IEC 42001 management system can supply governance structure and document control, but the Commission's JRC found it high-level and flexible, with logging and record keeping covered only to a limited degree. Route selection matters: most Annex III systems use internal control under Annex VI, while some biometric systems and Annex I products involve a notified body under Annex VII.
- Where the management system helps: policy ownership, roles, management review, internal audit and corrective action can be shared across AI projects.
- Where EN 18286 fits: it maps directly to the Article 17 quality management system that the provider must maintain, including post-market monitoring.
- Where a separate artefact is needed: the technical documentation, risk management file and logging design required by the Act must exist as AI-specific records.
- Conformity route: confirm whether your system falls under internal control (Annex VI) or notified body assessment (Annex VII) before you budget for the quality management work.
- Certification is not conformity: an ISO/IEC 42001 certificate does not itself establish presumption of conformity.
Before relying on any certificate, ask the certifying body and your legal adviser how its scope maps to the Article 17 aspects and to the route your system uses.
A deployer uses a high-risk AI system under its own authority and owes duties that are mostly operational: using the system according to the provider's instructions, assigning competent human oversight, monitoring operation, keeping logs for the retention period the Act sets, informing affected persons where required, and reporting serious incidents. Most of these duties sit in daily processes that an AI management system can organize, such as an AI system inventory, role assignments, training records and review cycles. The Act does not refer to ISO/IEC 42001 certification, so the management system works as evidence of how the deployer runs these processes, not as proof that a particular deployment meets the high-risk rules.
- Where the management system helps: an inventory of AI systems, documented ownership, competence records and periodic reviews give auditors a traceable process.
- Human oversight: the management system can define who oversees each system and how they can intervene, but the oversight records for each deployment still need to be kept.
- Logs and retention: confirm with the provider which logs the system generates and how long you must keep them, since the retention period is set by the Act and the instructions.
- Incident handling: procedures for escalating and reporting serious incidents to the provider and authorities should be tested, not only written.
- Provider inputs: the provider's instructions for use and documentation are a separate artefact you must obtain and follow.
Ask your provider which conformity route and standard it relies on, and whether it will supply the documentation you need to demonstrate your own deployer duties.
A provider of a general-purpose AI model has Chapter V obligations, supervised by the AI Office, and may use the code of practice to show compliance. The code of practice is the route the Act names for this tier, not a harmonised standard, so an ISO/IEC 42001 management system does not by itself establish that the model's documentation, copyright policy or training-data summary duties are met. The management system is most useful for the governance layer that sits around those documents: who approves a model release, how changes are reviewed, how incidents are logged and how documentation stays current. Systemic-risk models carry additional duties that need their own risk assessment and reporting records.
- Where the management system helps: release approval, change control, incident handling and document versioning can follow the same process used for other AI products.
- Where the code of practice fits: it sets the route the AI Office will look at for documentation and copyright compliance, so confirm which parts you are following.
- Where a separate artefact is needed: the model documentation, training-content summary and copyright policy are model-specific records that the management system cannot replace.
- Systemic risk: the risk assessment, evaluation and serious incident records required for systemic-risk models must be kept as their own evidence.
- Enforcement: AI Office supervision means evidence should be ready for regulator review, not only for internal audit.
Confirm with your legal adviser which general-purpose model duties apply to your model and whether the code of practice or another route fits your organization.
Where an AI management system still helps
Even without a presumption of conformity, an ISO/IEC 42001 management system gives an organization the governance and records that make AI Act evidence possible. Each card below supports the Article 17 quality management system and the Annex IV technical documentation, and none of them replaces that evidence.
Governance structure and accountability
Name one accountable owner for each AI system, with a documented decision path for approval, change and withdrawal. Article 17 expects a provider to set out an accountability framework for management, and an AI management system forces that framework to exist in writing. Check that the owner has authority to stop a release, that the minutes of approvals are kept, and that the same people appear in the AI Act documentation.
AI system inventory
An inventory lists every AI system the organization builds, buys or deploys, with its purpose, provider or deployer role, and risk tier. The inventory is the starting point for scope decisions and for deciding which Annex IV documents must exist. Check that it is updated when a system changes purpose, because a changed use can change the risk classification.
Supplier and value chain controls
Most organizations rely on third-party models, datasets and hosting. A management system sets how suppliers are assessed, which contract terms are required and who receives the information needed for a downstream conformity file. Check that each supplier has been asked for the technical information it holds, and that gaps are logged rather than assumed away.
Competence and AI literacy records
Training records show that staff who operate or oversee AI systems have the knowledge the work requires. The AI Act sets a duty on AI literacy for providers and deployers, and an AI management system gives the training plan and its attendance records a fixed home. Check that records name the role, the course content and the date, and that they are refreshed when systems change.
Internal audit cycles
Scheduled internal audits test whether the documented process is followed in practice, which is the question an assessor asks first. ISO/IEC 42001 requires an internal audit programme, and its findings feed corrective actions. Check that audit results are tied to the quality management system and that corrective actions are closed with evidence, not only logged.
Customer assurance requests
Enterprise customers and procurement teams often ask for proof of AI governance before signing. A management system lets an organization answer those requests from controlled documents, with consistent wording and a named owner. Check that any certificate or statement given to a customer is accurate about its scope, and that it does not imply AI Act conformity or a CE marking the organization has not obtained.
How to plan an ISO 42001 and AI Act readiness path
This sequence turns a general AI management system into evidence that maps to the AI Act's high-risk requirements, with each phase producing a document an assessor or auditor can test. It is built around the 2 December 2027 and 2 August 2028 high-risk application dates, which set the planning anchors for the work.
Confirm your role and risk tier
Start by recording, for each AI system in scope, whether your organization acts as provider, deployer, importer or distributor, and which risk tier applies: prohibited, high risk under Annex III or Annex I, transparency risk, or minimal risk. Legal counsel or the compliance lead owns this decision, and it should be reviewed against the Annex III and Annex I categories before anything else is built. The step is done when each system has a signed classification record with its role, tier and the applicable date from the Digital Omnibus amendments. Confirm the dates with the Official Journal text in Regulation (EU) 2026/1744 rather than relying on older summaries.
Map Article 17 aspects to existing clauses
Providers of high-risk systems must run a quality management system covering at least 13 aspects listed in Article 17, including compliance strategy, design control, testing, data management, risk management, post-market monitoring, serious incident reporting, record-keeping and accountability. Build a crosswalk that places each aspect against the clauses and controls you already run for ISO/IEC 42001 or other management systems, and mark gaps where no existing process applies. The mapping is owned by the quality or compliance function, with engineering and legal reviewing their rows. It is complete when every Article 17 aspect points to a named procedure, record and owner, and every gap has an assigned remediation item.
Decide whether to adopt EN 18286 as the QMS basis
Commission Implementing Decision (EU) 2026/2274 cites EN 18286:2026 as the first harmonised standard, and only harmonised standards with references published in the Official Journal give a presumption of conformity under Article 40(1). Decide whether the quality management system will be built on EN 18286, kept as an ISO/IEC 42001 system with an EN 18286 crosswalk, or run as a sectoral system that includes the AI Act aspects under Article 17(3). The decision belongs to the executive sponsor with the compliance lead, and it should be recorded with its reasons. The step is done when a written decision exists, the standard's scope has been checked against your systems, and the team knows which other AI Act standards are still in progress.
Close logging and record-keeping gaps
The Commission's Joint Research Centre found that ISO/IEC 42001 covers logging and record keeping only to a limited degree, as one of its optional controls, so this area usually needs explicit work. Define which events, model versions, inputs, outputs and human oversight actions must be logged for each high-risk system, how long records are kept, who can access them, and how they are protected from alteration. Engineering owns the logging design, and operations owns retention and access. The step is done when a logging specification exists, a sample of logs has been reviewed against it, and retention periods are confirmed with legal counsel.
Prepare technical documentation and risk records
Assemble the technical documentation for each high-risk system and link it to the risk management, data governance, testing and human oversight records that the Articles 8 to 15 requirements call for. Keep the documentation as a versioned set tied to specific system releases, so an assessor can see what was true at placement on the market. Product, engineering and compliance share ownership, with the provider accountable for the final file. The step is done when a review has confirmed each document exists, names its owner, and matches the deployed version, and when the file is ready for an independent review or notified body assessment where one applies.
Test the controls and run an internal audit
Before any external review, test the quality management system and technical documentation against the evidence you have written down. Sample records, walk through a real change from request to release, and check that post-market monitoring and serious incident reporting processes work as described. An internal auditor independent of the system owners should run this step, and findings should be logged with corrective actions. The step is done when the internal audit report is issued, each finding has an owner and closure evidence, and management has reviewed the results.
Engage an independent assessor or certification body
Most Annex III systems use internal control under Annex VI, so the provider's own declaration rests on evidence the provider holds. Some biometric systems and Annex I products go through a notified body under Annex VII, and the Regulation does not refer to ISO/IEC 42001 certification as a route to compliance. If an external certificate is wanted for procurement or governance reasons, engage an accredited certification body or independent auditor and confirm in writing what they will certify and against which standard. DeployOpen prepares systems, controls and evidence but does not issue audit reports, attestations or certificates. Ask any assessor for a written scope, the standard version they test against, and the evidence they expect before you commit budget.
Questions buyers ask about ISO 42001 and the AI Act
Is ISO 42001 certification enough to comply with the EU AI Act?
No. ISO/IEC 42001 certification does not by itself show compliance with the AI Act, and the Act does not refer to it as a route to conformity. The Commission's Joint Research Centre found the standard broadly in line with the Act's quality management system requirement, but high-level and flexible, with several risks and controls left optional. A certificate from an independent certification body can support your evidence, but you still need to map each Article 17 aspect and the technical documentation to specific records. Ask any certification body which AI Act requirements its audit actually tests before you rely on the certificate.
What does EN 18286 change for AI providers?
EN 18286:2026 is the first harmonised standard cited under the AI Act, so it is the first standard whose use gives a presumption of conformity with the Act's quality management requirements. The Commission's Implementing Decision (EU) 2026/2274 lists it as the only harmonised standard so far, and it covers post-market monitoring processes as well as the QMS. CEN-CENELEC describes it as a non-sector-specific QMS standard for AI system providers that offers a clearer route to show conformity with Article 17. It does not cover every AI Act requirement, and CEN-CENELEC reported in May 2026 that other standards, including prEN 18228 on AI risk management and prEN 18283 on managing bias, were still in progress.
Can an ISO 42001 certificate be used in an AI Act conformity assessment?
Not as a conformity assessment in its own right. Under the Act, most high-risk systems follow internal control under Annex VI, and some follow a notified body assessment of the QMS and technical documentation under Annex VII. The Regulation does not name ISO/IEC 42001 certification as a conformity route. An ISO 42001 certificate may be useful evidence inside your internal control file or for a notified body to review, but the notified body or your own declaration remains the basis for conformity. Confirm with your notified body, if one is involved, how it will treat existing certificates before you plan the audit.
What must our own team do, and what can a partner prepare?
Your organization owns its AI systems, its risk decisions, its quality management system and its declaration of conformity. Those roles cannot be handed to an implementation partner. A partner can help prepare the systems and the evidence: a system inventory, logging and record-keeping configuration, documentation templates, test records, change control and monitoring procedures, all running inside your own infrastructure. Independent auditors and certification bodies are the only parties that issue audit reports or certificates. Decide early which person signs off each control, because that accountability stays with you.
How long does an AI management system take to build, and what drives the effort?
No duration can be stated here without a written scope, so treat any single figure you hear with caution. The main drivers are the number of AI systems in scope, whether any is high-risk under Annex III or Annex I, how much of your quality management system already exists in sectoral or ISO 27001 processes, the maturity of your logging and data governance, and how many business units and suppliers you must coordinate. Ask for the effort broken into inventory, gap analysis, documentation, technical configuration, internal audit and certification body fees, and check which items recur each year, such as surveillance audits, monitoring and model changes.
What drives the cost of ISO 42001 and AI Act work, and what should we ask for in a quote?
Costs fall into four groups: your internal staff time, external consultant or implementation fees, certification body fees for ISO/IEC 42001, and any notified body fees if an AI Act route requires one. Cost rises with the number of AI systems, the number of high-risk systems, the amount of custom integration on self-hosted platforms, and the number of suppliers whose documentation must be collected. Ask any provider for a written scope listing the systems and standards covered, the deliverables, the one-time work, the recurring work and the items you must supply yourself. Requests for a fixed price usually depend on that scope being agreed in writing first.
Can an implementation partner issue an ISO 42001 certificate or AI Act report?
No. An implementation partner prepares systems, controls and evidence, but only an independent certification body can issue an ISO/IEC 42001 certificate, and only the relevant independent auditor or notified body can issue an assessment result. DeployOpen prepares systems and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Before you engage any firm, confirm which accreditation its certification body holds, who will sign the certificate, and whether the auditor is independent of the team that built the controls.
What to confirm with your certification body and counsel
Before you commit budget to an ISO/IEC 42001 certification, ask the certification body in writing how it will treat EN 18286:2026 and the AI Act evidence you plan to show. Ask whether its audit scope will reference EN 18286 at all, whether it will test your quality management system against the Article 17 aspects, and whether it will accept Annex VI internal-control evidence or the Annex VII technical documentation that a notified body would review. The answer changes what the certificate proves. A certificate that covers only the ISO/IEC 42001 requirements will not, by itself, give you the presumption of conformity under Article 40(1), so get the certification body's position in its own words and keep it on file with the statement of applicability.
Ask the certification body whether its certificate will be accepted by your customers and by the national market surveillance authorities in the Member States where your systems are used. Customers may ask for a specific scope, a named standard or evidence that the certificate covers the systems they buy. Authorities will look at the technical documentation and the risk management, data and logging records, which an AI management system does not fully cover on its own. Confirm also who in your organization owns the response if an authority asks for evidence that sits outside the certified scope.
Ask counsel to confirm the standards and dates at the time you read this page, not at the time you drafted your plan. The first harmonised standard, EN 18286:2026, was cited in the Official Journal on 14 October 2026 under Commission Implementing Decision (EU) 2026/2274, and other AI Act standards were still in progress when CEN-CENELEC reported in May 2026. Check the current list of cited standards in the Commission Implementing Decision (EU) 2026/2274, then confirm the high-risk application dates in the consolidated text of Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744. Have counsel record which version of each text your plan relies on and set a review date for when the Official Journal changes.
How DeployOpen prepares AI management system and AI Act evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the records that an AI management system or AI Act file depends on are produced where the AI systems actually run. We prepare systems, controls and evidence for assessment; the organization owns its controls, and only an independent auditor or certification body issues reports or certificates.
How we scope
- Engagements are fixed-scope, with the AI systems, platforms and roles in scope agreed in writing before work starts.
- The written scope names which AI management system or AI Act requirements the evidence work covers, and which remain with your team.
- Scope also states which third-party assessor, if any, you have engaged, so no one assumes an assessment is included.
How we build
- We configure logging, access control, change records and inventory tooling in your environment to capture evidence as systems run.
- We document the controls, roles and policies that your AI governance process relies on, in the form your assessor will request.
- We test the configured controls against the written requirements and record the results for your review before handover.
How we hand over
- You receive the configuration records, control documentation, test results and evidence index in an agreed format.
- Handover includes a walkthrough so your internal owners know where each record lives and how it is produced.
- We do not issue audit reports, attestations or certifications; your independent assessor reviews the evidence and decides.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial written scope.
- Retainers can cover maintaining evidence collection as platforms change and as the AI Act dates and standards move.
- Confirm with us in writing which support tasks, response expectations and review cycles a retainer includes before signing.
