EU AI Act Article 40: Harmonised Standards and the Presumption of Conformity

You cannot use it yet. That is the blunt reality of Article 40 of Regulation (EU) 2024/1689 in mid-2026: the legal mechanism exists, but the technical standards it depends on have not been published, so no high-risk AI provider can currently rely on it. Article 40 is the presumption of conformity — the rule that a high-risk AI system conforming to harmonised standards is presumed to meet the corresponding requirements. This guide explains how that presumption attaches, why the standards are still in development, and how to plan a technical file around standards that do not yet exist.

This is the legal mechanism, not the procedure and not the definition. Article 43 is the conformity-assessment procedure that uses the presumption; the harmonised standard (definition) glossary entry is the term. This article is about the presumption itself.

---

What Article 40 actually does

Article 40(1) establishes that a high-risk AI system which conforms to harmonised standards — or relevant parts of them — whose references have been published in the Official Journal of the European Union is presumed to conform with the corresponding requirements of Chapter III, Section 2 (Articles 9 to 15), to the extent those standards cover them.

That presumption is the practical backbone of demonstrating compliance. Chapter III, Section 2 sets out open-ended obligations: your risk management system must be "appropriate," your data governance "relevant" and "representative," your cybersecurity "adequate." Without a reference point, adequacy is a judgment call you must defend from first principles. A published harmonised standard converts "meet the requirements" into "conform to a known, pre-validated technical specification" — a far easier thing to evidence and a far harder thing for a regulator to reject.

Article 40(1) also extends the presumption to general-purpose AI (GPAI) models that conform to harmonised standards covering the relevant Chapter V obligations. GPAI standardisation is at an even earlier stage than the high-risk work, so treat this as a roadmap item, not a usable route today. Confir does not market GPAI provider compliance as complete; it sits on the roadmap.

---

What a harmonised standard is — and how one comes to exist

A harmonised standard is a European standard (EN) developed by CEN, CENELEC, or ETSI at the European Commission's request. The AI Act draws on the definition in Regulation (EU) No 1025/2012 — the Standardisation Regulation — which is the source of the term across all EU harmonisation legislation.

The process runs in four steps:

1. The Commission issues a standardisation request (a mandate) to the European Standardisation Organisations.
2. CEN, CENELEC, or ETSI develop the standard through a multi-stakeholder process — industry, academia, civil society, national bodies.
3. The Commission assesses the resulting standard against the request.
4. If satisfied, the Commission publishes the reference in the Official Journal. Only at that point does the standard carry legal effect for the presumption.

For the AI Act, CEN and CENELEC are developing the standards under standardisation request M/606, issued to support the high-risk requirements. The request mechanism is the structure to watch; there is no confirmed publication date for the references, and a draft standard in circulation is at most useful technical guidance.

The critical point: a standard's mere existence does not create the presumption. Publication of the reference in the Official Journal is the trigger. Until that happens, conformity with a draft buys you nothing legally.

---

How the presumption of conformity works in practice

Conformity with a published harmonised standard means the requirements that standard addresses are presumed met. You need not independently re-prove each Chapter III, Section 2 requirement the standard covers — the standard does that work for you.

Three mechanics matter:

• "Or parts thereof." Article 40 lets you apply only the relevant sections of a standard and claim the presumption only for the requirements those sections cover. Requirements left uncovered still need separate evidence in your Article 11 / Annex IV technical file.
• Scope is requirement-by-requirement. A standard covering data governance (Article 10) and transparency to deployers (Article 13) does not extend the presumption to cybersecurity (Article 15) if the standard is silent on it. There is no blanket pass for the whole system.
• The presumption is rebuttable. It is a legal starting point, not an absolute. A market-surveillance authority that finds actual non-compliance can challenge it — but the burden of showing a breach sits with the authority, not with you. That burden-shift is the commercial value of the presumption.

---

Voluntary in law, the default route in practice

Harmonised standards are voluntary. No provider is obliged to apply them. You may demonstrate conformity by any technically adequate means.

In practice, though, the presumption makes them the cheapest and most legally defensible route. An evidence framework grounded in a published EN is far harder for a regulator or a notified body to reject than a bespoke proprietary methodology you invented and now have to justify line by line.

The interaction with Article 43 sharpens this for biometric systems. For Annex III, point 1 biometrics, fully applying harmonised standards that cover all the Chapter III, Section 2 requirements opens a choice between the Annex VI internal-control route and the Annex VII notified-body route. Without those standards, Annex VII is mandatory. The route detail belongs to the Article 43 conformity assessment routes guide; the point here is simply why a provider would want the standards: they expand your options and lower your assessment cost.

---

Article 40 vs Article 41: harmonised standards vs common specifications

Two instruments can generate a presumption of conformity. Article 41 lets the Commission adopt common specifications by implementing act where harmonised standards do not exist, are insufficient, or where there are urgent safety or fundamental-rights concerns. A common specification is a legislative substitute for a missing or inadequate harmonised standard, and it carries its own presumption.

Once a harmonised standard is published for the same requirements, it supersedes the common specification for providers who apply it. The operational takeaway: if you want to shape what "conformity" means technically, you have far more influence inside the CEN and CENELEC process than over a Commission-drafted common specification handed to you finished.

---

The 2026 gap: standards still in development

As of mid-2026, no confirmed date has been given for publication of the Official Journal references to the AI Act harmonised standards under M/606. The consequence is direct: you cannot yet rely on the Article 40 presumption.

That collides with the timeline. High-risk obligations for stand-alone Annex III systems read 2 August 2026 in the statute. A deferral to 2 December 2027, agreed in the Digital Omnibus (6–7 May 2026; COREPER around 13 May), is now adopted: the European Parliament approved it on 16 June 2026 and the Council adopted it on 29 June 2026. It enters into force on publication in the Official Journal, expected before 2 August 2026, and stand-alone high-risk obligations now apply from 2 December 2027.

So the obligations may bite before the standards that are supposed to ease them arrive. You have three realistic options while references are pending:

1. Engage with the open CEN/CENELEC committee process through your national standards body, so the standard reflects how systems like yours actually work.
2. Watch for and apply Article 41 common specifications if and when the Commission publishes them to fill the gap.
3. Build the Article 11 / Annex IV evidence framework directly against the requirements, cross-referencing adjacent available standards — ISO/IEC 42001 AI management systems and ISO/IEC 27001 for information security — while accepting that these do not carry the Article 40 presumption.

The technical documentation pack must be assembled regardless of standards availability. The only open question is what evidence fills each section until a harmonised standard defines what "adequate" means.

---

Worked example: a fintech planning around pending standards

Clarivault is a 90-person credit-scoring provider headquartered in Dublin, serving lenders across Ireland, Germany, and Spain. Its model scores consumer creditworthiness, placing it squarely in Annex III, point 5(b) (creditworthiness and credit scoring) under Article 6(2) — high-risk, and on the Annex VI internal-control route because point 5(b) is not biometrics.

Because no harmonised-standard reference is yet published, Clarivault cannot claim the Article 40 presumption today. So it builds its Annex IV evidence directly against Articles 9, 10, 13, 14, and 15. It cross-maps each control to the ISO/IEC 42001 management-system controls it has already implemented, documenting clearly that this mapping supports its evidence but does not invoke the presumption.

Clarivault assigns a standards-watch owner to monitor M/606 progress and any Article 41 common specification. It structures the technical file modularly, so that when a reference is published, the conforming sections can be swapped in to claim the presumption for the requirements those sections cover — without rebuilding the file from scratch.

Its planning posture is honest: it builds to the now-adopted 2 December 2027 deadline, and it documents every "adequate-conformity" judgment call transparently. Absent a published standard, transparent reasoning about why its chosen evidence is adequate is the only defensible position. Realistic lead time to a complete, swap-ready file: eight to twelve weeks, with the bottleneck being the bias and robustness evidence under Articles 10 and 15.

---

What this means for your compliance roadmap

Treat harmonised standards as the destination route, not a current dependency. Design the technical file so that published standards can be adopted incrementally, section by section, as references appear in the Official Journal.

Map each Chapter III, Section 2 requirement to its evidence source now. Flag explicitly which of those sources are placeholder judgment calls awaiting a harmonised standard, so that when one publishes you know exactly which sections to revisit. The structure stays stable; only the evidence behind the flagged sections changes.

Keep watch on M/606 and on Article 41. The first published reference for any requirement you address is the moment your defensibility improves materially — that is when an open judgment call becomes a presumption.

---

How Confir helps

Confir's assessment maps your compliance areas to the specific Articles — 9, 10, 11, 13, 14, and 15 — that the harmonised standards will eventually cover, and outputs an Annex IV technical documentation pack plus an Article 47 / Annex V Declaration of Conformity. Because the mapping is structured by requirement, you can see at a glance which sections rest on a published standard and which rest on a documented judgment call. As references publish, the mapping updates while the underlying structure stays stable, so adopting a standard does not mean rebuilding the file.

The engine is deterministic and rule-based — no model inference, no hallucination. The same intake produces the same requirement mapping and the same documentation structure every time, which is what makes the output defensible when an authority asks how a conclusion was reached.

---

Related guides

• harmonised standard (definition)
• Article 43 conformity assessment routes
• Article 17 quality management system
• conformity assessment overview
• ISO/IEC 42001 AI management systems