EU AI Act Article 41: Common Specifications and the Backup Presumption of Conformity

It is a real compliance route, not a theoretical one. Conforming to a common specification under Article 41 of Regulation (EU) 2024/1689 produces the same presumption of conformity that a harmonised standard would — which matters because, in mid-2026, the harmonised standards that Article 40 depends on are still unpublished. Article 41 is the legislative backstop: where the standards route fails, the European Commission can adopt its own technical specifications by implementing act, and a provider that conforms to them is presumed to meet the underlying requirements.

This page is about the common-specification instrument itself. The default harmonised-standards mechanism lives at Article 40 harmonised standards and the presumption of conformity, and the underlying term sits at the harmonised standard (definition) glossary entry. Here the subject is the fallback, the triggers that bring it into play, and the one feature it has that Article 40 does not.

---

What Article 41 is: the Commission's fallback when standards are missing

Article 41(1) empowers the European Commission to adopt common specifications by implementing act, covering the requirements in Chapter III, Section 2 (Articles 9 to 15) for high-risk AI systems, and the Article 53 obligations for general-purpose AI (GPAI) model providers. A common specification is a Commission-drafted technical specification that substitutes for a harmonised standard — it is not a product of CEN, CENELEC, or ETSI.

The whole article turns on a dependency. Article 40 harmonised standards are the default route to the presumption of conformity. Article 41 exists precisely because that route can stall — and in mid-2026 it has: the references for the standards under Commission request M/606 are still unpublished. The common specification is the legislative answer to that gap.

State the thesis plainly. Conforming to a common specification produces the same presumption of conformity as conforming to a harmonised standard. It is not a weaker, second-class route; for the requirements it covers, the legal effect is identical. The difference is in origin and durability, not in strength — a point the comparison below makes precise.

---

When the Commission can act: the Article 41(1) triggers

Article 41(1) is conditional, not open-ended. The Commission may adopt common specifications only where the harmonised-standards route has failed in a defined way.

Trigger (a) turns on the standardisation request. The Commission must have requested standards under Regulation (EU) No 1025/2012, and one of the following must hold: no standardisation organisation accepted the request; the standards delivered do not adequately address the requirements or the fundamental-rights concerns they were meant to cover; or the standards are not delivered within the deadline set.

The fundamental-rights dimension matters and is easy to miss. Common specifications can be reached for not only where standards are simply absent, but where the standards that exist do not adequately address fundamental-rights concerns. A standard can be present and still insufficient.

Article 41(2) adds a procedural prerequisite. The Commission must first have followed the standards request process and consulted the relevant bodies — including the AI Board established under Article 65, and consultation of stakeholders such as the advisory forum — before resorting to common specifications. The instrument is an implementing act, adopted through the examination procedure referenced in Article 98(2) (comitology). That sharply distinguishes it from the multi-stakeholder European-standard drafting of Article 40.

---

Article 40 vs Article 41: a side-by-side comparison

Both instruments produce a presumption of conformity. They differ in who drafts them, how they take effect, and how long they last.

The table owns the distinctions specific to this page; the Article 40 mechanism itself is explained on its own guide. The point to carry forward: the two presumptions are legally equivalent in effect, differing only in origin and durability.

---

The presumption and the equivalence escape hatch

Article 41(3) is the operative grant. A high-risk AI system, or a GPAI model, that conforms to common specifications — or relevant parts of them — is presumed to conform with the Chapter III, Section 2 requirements (or the Article 53 obligations) to the extent the common specifications cover them. As with Article 40, this is requirement-by-requirement, never a blanket pass for the whole system.

Article 41(4) is the distinctive feature of this article. Providers are not obliged to apply common specifications. A provider may instead adopt other technical solutions — but only if it can demonstrate those solutions meet the requirements to a level at least equivalent to the common specifications.

Spell out the practical burden. Take the equivalence route and you must document, in the Article 11 / Annex IV technical file, why your alternative solution achieves an at-least-equivalent level. That is a heavier evidentiary load than simply citing the common specification and claiming the Article 41(3) presumption. You are proving a comparison, not pointing at a published text.

The influence asymmetry sharpens the choice. Because the Commission drafts common specifications unilaterally, a provider that disagrees with the prescribed approach has the equivalence route as its only lever — where, with a harmonised standard, it could have shaped the text inside the CEN or CENELEC committee. The equivalence escape hatch is the substitute for that lost influence.

The presumption is rebuttable, exactly like the Article 40 presumption. A market-surveillance authority that finds actual non-compliance can still challenge it — but where the presumption attaches, the burden of proving a breach shifts to the authority. That burden-shift is the commercial value of conforming.

---

Supersession: common specifications are temporary by design

Article 41(5) to (6) sets the sunset. Where harmonised standards are subsequently adopted and their references published, the Commission must amend or repeal the common specifications covering the same requirements.

Read this operationally: a common specification is a stopgap with a built-in expiry. Once the CEN or CENELEC standard lands for the same requirements, providers applying the standard rely on it instead, and the common specification falls away for those requirements. The consequence for your technical file is to build it modularly — so a section grounded in a common specification can be re-pointed to a harmonised standard when one publishes, without rebuilding the file.

This ties directly to the 2026 reality. Because the standards under M/606 are not yet published and the high-risk obligations may bite on the statutory date, common specifications are the most likely first-published presumption route for some requirements. They could arrive before the standards they will eventually be replaced by.

Caveat the timeline precisely. High-risk obligations for stand-alone Annex III systems read 2 August 2026 in the statute. A deferral of those obligations to 2 December 2027, agreed in the Digital Omnibus (6 to 7 May 2026; COREPER around 13 May 2026), 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.

---

Worked example: a recruitment-AI provider choosing between routes

Talentbridge is a 140-person applicant-screening provider headquartered in Amsterdam, serving employers across the Netherlands, Germany, and France. Its CV-ranking and candidate-shortlisting system falls under Annex III, point 4(a) (recruitment and selection) by virtue of Article 6(2) — high-risk. Because point 4(a) is not biometrics, it sits on the Annex VI internal-control route, so no notified body is mandatory.

The standards gap bites. With no harmonised-standard reference published under M/606 in mid-2026, Talentbridge cannot rely on the Article 40 presumption for its data-governance evidence under Article 10 or its accuracy-and-robustness evidence under Article 15. It must either defend those from first principles or find another anchor.

The decision point arrives when the Commission publishes a common specification covering Article 10 data governance. Talentbridge can either (a) conform to it and claim the Article 41(3) presumption for that requirement, or (b) keep its existing bias-testing methodology and discharge the Article 41(4) equivalence burden by documenting why that methodology is at least equivalent to the common specification.

Talentbridge adopts the common specification for Article 10, to minimise its evidentiary burden, while flagging the section so it can swap in the M/606 harmonised standard once published under the Article 41(5) supersession rule. It plans to the now-adopted 2 December 2027 deadline, and keeps a standards-watch owner monitoring both the comitology track and CEN/CENELEC progress. The posture is honest: take the lighter route where one exists, preserve the option to move to the durable standard later.

---

What this means for your compliance roadmap

Treat common specifications as a live route to watch, not a hypothetical. They may be the first published presumption route for some high-risk requirements while the M/606 standards lag, so the provider that ignores them may be ignoring the only available shortcut.

Map each Chapter III, Section 2 requirement to its evidence source now. Flag which rest on a common specification, which on a documented judgment call, and which will move to a harmonised standard later. Then decide the route per requirement: conform to the common specification (lighter evidence) or take the Article 41(4) equivalence route (heavier evidence, but it preserves your own methodology). Structure the technical file modularly, so the Article 41(5) supersession swap to a harmonised standard does not force a rebuild.

---

How Confir helps

Confir's assessment maps your compliance areas to the specific Articles — 9, 10, 11, 13, 14, and 15 — that common specifications and harmonised standards will eventually cover. It outputs an Annex IV technical documentation pack and an Article 47 / Annex V Declaration of Conformity, and flags per requirement whether the basis is a common specification, a harmonised standard, or a documented judgment call. As a common specification publishes, or is later superseded by a standard, the mapping updates while the structure stays stable.

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. GPAI coverage is partial and on the roadmap, not marketed as complete.

---

Related guides

• Article 40 harmonised standards and the presumption of conformity
• harmonised standard (definition)
• Article 43 conformity assessment routes
• conformity assessment overview
• Article 17 quality management system