Article 40(1) attaches the presumption of conformity only to harmonised standards whose references have been published in the Official Journal under Regulation (EU) No 1025/2012, and no such reference exists for Regulation (EU) 2024/1689. ISO/IEC 42001:2023, published 18 December 2023 across 51 pages, is not one of them, so no AI management system certificate on the market grants a presumption of anything. That presumption also reaches only Chapter III Section 2, Articles 8 to 15, plus Chapter V Sections 2 and 3, while Article 17, the quality management system an AIMS most resembles, sits in Section 3 and is outside the mechanism entirely; it is assessed only through Article 43(3), and only for the eleven live Annex I Section A product categories such as medical devices and in vitro diagnostics. What binds a provider is Article 16(c) plus the thirteen lettered points of Article 17(1), and three of those thirteen route straight into Articles 9, 72 and 73, which no organisational audit produces. The route left open today is Article 41(5): duly justify, in writing and per system, that your technical solutions meet the Section 2 requirements to a level at least equivalent. Getting that wrong sits in the Article 99(4) tier, up to EUR 15 000 000 or 3 percent of total worldwide annual turnover, whichever is higher. Start this week by building the Article 17(1) evidence register: thirteen rows, (a) to (m), each with an artefact path and a named owner.
Article 40(1) of the EU AI Act grants a presumption of conformity to one class of document: harmonised standards whose references have been published in the Official Journal of the European Union under Regulation (EU) No 1025/2012. On the day this post published there were none for Regulation (EU) 2024/1689, the AI Act itself, published in the Official Journal on 12 July 2024. That settles most of ISO 42001 vs AI Act: a certificate cannot buy a presumption that does not yet exist for anybody.
The structural point is sharper than the timing one. Article 40(1) reaches Chapter III Section 2 and, as applicable, Chapter V Sections 2 and 3. Article 17, the quality management system obligation an AI management system genuinely resembles, sits in Section 3, outside the presumption mechanism entirely. Which systems Chapter III reaches is assumed here, and covered in which systems Chapter III actually reaches.
What Article 40 actually grants, and why no certificate on the market has it
Article 40 has three paragraphs, and the first is the whole grant:
High-risk AI systems or general-purpose AI models which are in conformity with harmonised standards or parts thereof the references of which have been published in the Official Journal of the European Union in accordance with Regulation (EU) No 1025/2012 shall be presumed to be in conformity with the requirements set out in Section 2 of this Chapter or, as applicable, with the obligations set out in of [sic] Chapter V, Sections 2 and 3, of this Regulation, to the extent that those standards cover those requirements or obligations.
ISO/IEC 42001:2023 is not a harmonised standard, so the first condition already fails. It is an international standard from ISO/IEC JTC 1/SC 42, published 18 December 2023 across 51 pages, and it has never been cited in the Official Journal under the AI Act. Neither has anything else: the European Commission's harmonised standards portal carries no artificial intelligence entry and no entry for Regulation (EU) 2024/1689.
The shelf is empty rather than abandoned. Article 40(2) obliges the Commission to issue standardisation requests covering the Section 2 requirements and, as applicable, the Chapter V obligations. That work sits with CEN and CENELEC, through their joint technical committee on artificial intelligence, JTC 21. Its topic page lists the standards supporting the AI Act as under development, among them an AI Quality Management System standard, and puts the effect in the future tense: once published in the Official Journal, these standards will provide a legal presumption of conformity. When that happens the presumption attaches to conformity with the cited European standard, not to a certificate against some other document.
The fourth subparagraph of Article 40(2) does ask for deliverables covering Chapter III Sections 2 and 3 together, the only place Section 3 enters the mandate, but it does not widen the Article 40(1) grant.
Article 41 common specifications, and the route left open today
Article 41(1) lets the Commission adopt implementing acts establishing common specifications, but only when two conditions hold together: a requested harmonised standard was refused, late, non-compliant with the request or insufficient on fundamental rights; and no reference to a harmonised standard has been published in the Official Journal. Article 41(3) gives those specifications the same presumption against Section 2, and Article 41(4) repeals them once a harmonised standard is cited. No such implementing act existed when this post published. That leaves Article 41(5). A provider applying neither harmonised standards nor common specifications shall duly justify that it has adopted technical solutions meeting the Section 2 requirements to a level at least equivalent thereto: written, per system, against Articles 8 to 15.
Two instruments, two objects: an organisation against a system
ISO states its own scope plainly: ISO/IEC 42001:2023 specifies requirements and provides guidance for establishing, implementing, maintaining and continually improving an AI management system within the context of an organization. The object of certification is the organisation.
Article 8(1) names a different object: high-risk AI systems shall comply with the requirements laid down in Chapter III Section 2. Section 2 is Articles 8 to 15, one compliance umbrella plus seven substantive requirements covering risk management, data governance, technical documentation, record-keeping, transparency to deployers, human oversight, and accuracy, robustness and cybersecurity. Each is a property of one system, measured on that system's data and evaluations, and no organisational certificate discharges a per-system requirement.
Those dates cover Chapter III Sections 1, 2 and 3, with the exception of Article 6(5), and are worked through in the dates the Digital Omnibus moved and the ones it did not.
| ISO/IEC 42001:2023 | EU AI Act Chapter III | |
|---|---|---|
| Legal status | Voluntary international standard | Regulation (EU) 2024/1689, binding, OJ 12 July 2024 |
| Object | The organisation's AI management system | The individual high-risk AI system |
| Who is bound | Whoever seeks certification | The provider named under Article 16(b) |
| Issuer of the evidence | Accredited body under ISO/IEC 17021-1 and ISO/IEC 42006:2025 | The provider under Annex VI, or a notified body under Annex VII |
| Headline artefact | Certificate plus statement of applicability | EU declaration of conformity, Article 47, kept 10 years |
| Presumption of conformity | No | Only via Article 40 or Article 41 |
| Consequence of not having it | Commercial | Up to EUR 15 000 000 or 3 percent of worldwide turnover, Article 99(4) |
| Date it bites | On certification, by choice | 2 December 2027 for Annex III, 2 August 2028 for Annex I |
Article 17 is where an AIMS gets closest, and it sits outside the presumption
Chapter III Section 3 is Articles 16 to 27, and Article 17, Quality Management System, sits inside it. Article 16 lists twelve lettered obligations of providers, (a) to (l), and point (c) is a quality management system complying with Article 17. Article 17 stays outside the Article 40(1) grant even on the day the first harmonised AI quality management standard is cited.
Article 17 does get assessed in one place. Under Article 43(3), a provider whose high-risk AI system is covered by the Union harmonisation legislation listed in Section A of Annex I follows that sectoral conformity assessment, the Section 2 requirements form part of it, and then, verbatim, "Assessment of the quality management system set out in Article 17 shall also be undertaken, and points 3, 4.3, 4.4. and 4.5, the fifth paragraph of point 4.6 and point 5 of Annex VII shall apply."
That hook is scoped tightly. Annex I Section A runs to twelve numbered points of which point 1, Directive 2006/42/EC on machinery, is deleted, leaving eleven live hardware entries that begin at toys and end at medical devices under Regulation (EU) 2017/745 and in vitro diagnostics under Regulation (EU) 2017/746. Machinery moved to Section B as point 21, Regulation (EU) 2023/1230, on 27 July 2026, so a robot cell is the wrong example here; that half is covered in our post on whether a machine learning safety component needs a notified body.
Annex III splits differently. Article 43(1) lets a point 1 provider that applied harmonised standards, or available common specifications, choose between the Annex VI internal control procedure and the Annex VII assessment involving a notified body; where standards do not exist or were applied only in part, Annex VII is compulsory. Article 43(2) sends points 2 to 8 down Annex VI with no notified body. The empty shelf removes a choice rather than deferring an obligation.
The thirteen points of Article 17(1), and who actually discharges each one
Article 17(1) requires the quality management system to be documented in a systematic and orderly manner in the form of written policies, procedures and instructions, and to include at least thirteen lettered aspects, (a) through (m).
Three of the thirteen, (g), (h) and (i), are pointers into other AI Act articles, satisfied by an Article 9 risk management system, an Article 72 monitoring system and an Article 73 reporting procedure, none of which an audit of your organisation produces. Point (e) is sharper: the Act assumes the harmonised-standards gap and makes documenting your substitute a quality management system obligation. Point (a) makes model change management a named obligation, and a model registry that carries no approval record per version does not discharge it.
A house convention we use is a per-system register checked in next to the model, keyed to the lettered points so a gap is a missing file:
# article-17-evidence.yaml
# House convention, not a tool format. Keys are the lettered points of
# EU AI Act Article 17(1). One file per high-risk AI system.
system: credit-decision-model
provider_of_record: acme-gmbh # the entity named under Article 16(b)
article_17_1:
a: { artefact: docs/compliance/change-control.md, owner: head-of-risk }
b: { artefact: docs/model/design-record.md, owner: ml-lead }
c: { artefact: docs/model/qa-plan.md, owner: ml-lead }
d: { artefact: evals/release-gate.md, owner: ml-lead }
e: { artefact: docs/compliance/equivalence-argument.md, owner: head-of-risk }
f: { artefact: docs/data/data-management-procedure.md, owner: data-lead }
g: { artefact: docs/compliance/article-9-rms.md, owner: head-of-risk }
h: { artefact: docs/compliance/pmm-plan.md, owner: head-of-risk }
i: { artefact: runbooks/serious-incident.md, owner: on-call-lead }
j: { artefact: docs/compliance/authority-contact.md, owner: legal }
k: { artefact: docs/compliance/records-index.md, owner: legal }
l: { artefact: docs/ops/capacity-and-supply.md, owner: platform-lead }
m: { artefact: docs/compliance/raci.md, owner: coo }
aims_certificate:
held_by: none
covers_any_point_above: false # a certificate is organisational,
# these artefacts are per systemThirteen keys, thirteen artefacts, thirteen owners, and no certificate held upstream of you fills in a row.
| Article 17(1) point | What actually discharges it |
|---|---|
| (a) Compliance strategy and modification management | Article 43 route decision plus a model change-control record |
| (b) Design, design control, design verification | Per-system design record |
| (c) Development, quality control, quality assurance | Per-system QA plan |
| (d) Examination, test and validation procedures, and frequency | Evaluation suite and release gate |
| (e) Specifications, and the means used where standards are not applied in full | The Article 41(5) equivalence argument |
| (f) Data management, acquisition through retention | Article 10 data governance record for that system |
| (g) The risk management system referred to in Article 9 | Article 9 risk management system, per system |
| (h) Post-market monitoring per Article 72 | Article 72 monitoring plan |
| (i) Serious incident reporting per Article 73 | Article 73 procedure and incident runbook |
| (j) Communication with authorities, notified bodies, operators | Named contacts and a logged channel |
| (k) Record-keeping of relevant documentation | Documentation index with retention |
| (l) Resource management, incl. security of supply | Capacity and supplier continuity record |
| (m) Accountability framework for management and staff | Signed responsibility matrix |
What an AIMS certificate evidences, and what the Act asks for instead
An ISO/IEC 42001 certificate is issued by a conformity assessment body operating under ISO/IEC 17021-1 as supplemented by ISO/IEC 42006:2025. Annex A of ISO/IEC 42001 is a normative annex of controls the organisation selects from and justifies, with exclusions recorded, and the auditor works from that record.
An AI Act certificate under Article 44 is a different instrument from a different regime: issued by a notified body under Annex VII, valid for at most five years for Annex I systems and four years for Annex III systems, and suspended, withdrawn or restricted under Article 44(3) where the system no longer meets the Section 2 requirements. No AIMS certificate is an Article 44 certificate.
What the Act asks of a provider is narrower. Article 16(k) obliges the provider, upon a reasoned request of a national competent or market surveillance authority, to demonstrate the conformity of the high-risk AI system with the Section 2 requirements. Article 47(1) has it draw up a written machine readable, physical or electronically signed EU declaration of conformity for each system, and Article 47(4) makes drawing it up an assumption of responsibility for compliance with Section 2. The signature is the provider's, never the certification body's.
What no certificate reaches when the model runs on your own hardware
The question changes shape the moment the weights sit inside your perimeter, and it changes in three concrete places.
Scope is the first. A vendor's AIMS certificate is issued against the vendor's organisation, and its scope statement describes the vendor's own operations, sites and services. Run the same model on your own hardware, under your own change control, and the certified management system is not the one operating your deployment.
Whose name is in the box is the second. Article 16(b) requires the provider's name, registered trade name or trade mark and contact address on the high-risk AI system or its accompanying documentation. A regulated organisation that self-hosts and adapts a model can find its own name in that box, at which point the thirteen points of Article 17(1) are its obligations. Where adaptation crosses that line is worked through in when adapting a model makes you the provider.
Third is where on-premise deployment helps rather than hurts. Article 17(1)(f) demands documented procedures across data acquisition, collection, analysis, labelling, storage, filtration, mining, aggregation and retention, and Article 17(1)(d) demands test and validation procedures with a stated frequency. When training data, evaluation sets and inference logs never leave your perimeter, those procedures describe systems you own end to end, and the evidence comes off your own infrastructure instead of being requested from a supplier under an NDA and taken on trust.
The Act's text lands on these settings from the other direction too. Annex I Section A after 27 July 2026 is medical devices, IVDs and the rest of the hardware list, so Article 43(3), the one place a notified body assesses the Article 17 quality management system, reaches product categories whose equipment and data already sit on the customer's site.
Reading a vendor's certificate: scope, accreditation, exclusions
A certificate is only as wide as its scope statement, so send the vendor six questions in writing. The template below is a house document, not any tool's interface:
Certificate review, ISO/IEC 42001 vendor evidence request 1. Certification body and accreditation Which body issued the certificate, and which accreditation body accredited it for ISO/IEC 42001? 2. Scope statement, verbatim The scope sentence exactly as printed, naming the legal entity, the sites and the services it covers. 3. Our deployment against that scope Does the scope cover the product, model version and deployment mode we run, including any customer-managed instance? 4. Statement of applicability The current statement of applicability, or the excluded controls and the justification for each exclusion. 5. Dates and surveillance Issue date, expiry date, last surveillance audit, and any nonconformities still open. 6. AI Act position For each high-risk AI system you supply us: are you the provider under Article 16, and can you produce the Article 47 EU declaration of conformity and the Article 17 documentation?
Four answers should stop the review: an issuing body with no ISO/IEC 42001 scope on its accreditation body's register; a scope sentence naming the parent entity and "AI services" and nothing narrower; a refusal to share the statement of applicability; and a scope covering the vendor's hosted service while you run a customer-managed instance.
The AI Act obligations survive whatever comes back. If the vendor is the provider, you still need its Article 47 declaration and its Article 13 information to deployers; if you are the provider, the certificate is a supplier assurance document and nothing more. It is the same exercise as confirming a vendor's certificate scope before you buy, and teams under a sector regulator will recognise it from how AI compliance stacks up in financial services.
Where 42001 sits next to 42005, 42006, 23894 and NIST AI RMF
A governance team gets offered five documents, and one of them is something you can hold a certificate against.
Of the five, ISO/IEC 42005:2025 is the one aimed at an individual system: guidance on impact assessment methodology, timing and documentation, and being guidance it offers nothing to certify against.
With one compliance budget and a high-risk system in scope, the sequencing that survives contact with Article 16 is evidence first, certificate second. The evidence is what Article 16(k) asks for on a reasoned request and what Article 47(4) makes you responsible for. A certificate is a good forcing function and genuine procurement currency, but it substitutes for no line of the register, and nothing in Articles 40, 41, 43 or 44 says holding one shortens a conformity assessment. Our wider AI for business coverage covers the operating-model side.
What to do this week
Open Article 17(1) and write out the thirteen points, (a) to (m), one row each, against the single highest-risk AI system you operate. Put a file path and a person's name on every row, and leave the rows you cannot fill empty rather than aspirational. Then look hard at the three rows pointing at Articles 9, 72 and 73: those need engineering work, not document work, and a certificate will never fill them in.
| Document | Published | Type | Certifiable | AI Act presumption |
|---|---|---|---|---|
| ISO/IEC 42001:2023 | 18 December 2023, 51 pages | Management system requirements | Yes, via ISO/IEC 42006:2025 bodies | No |
| ISO/IEC 42005:2025 | 28 May 2025 | Guidance, AI system impact assessment | No | No |
| ISO/IEC 42006:2025 | July 2025, 31 pages | Requirements for certification bodies | Not applicable, it binds the auditor | No |
| ISO/IEC 23894:2023 | 6 February 2023, 26 pages | Guidance, AI risk management | No | No |
| NIST AI 100-1 | 26 January 2023 | Voluntary framework, Govern / Map / Measure / Manage | No scheme exists | No |
FAQ
Quick answers to the questions this post tends to raise.
