Article 40 provides that high risk AI systems and general purpose AI models in conformity with harmonised standards, or parts of them, whose references have been published in the Official Journal, are presumed to be in conformity with the requirements in Chapter III, Section 2 or, as applicable, with the obligations in Chapter V, Sections 2 and 3, to the extent that those standards cover those requirements or obligations. Article 41 allows the Commission to adopt common specifications by implementing act where harmonised standards are absent, delayed or insufficient, with a similar presumption to the extent they cover the requirements. Article 42 provides specific presumptions for data governance in defined circumstances and for cybersecurity certification schemes. No presumption is general, and each presumption must be mapped to the requirement, the standard or specification, and the coverage, with gaps demonstrated by other means.
How does Article 40 work?
Article 40(1) creates the presumption for harmonised standards. The conditions are cumulative: the system or model must be in conformity with a harmonised standard or a part of it, the reference of the standard must have been published in the Official Journal in accordance with Regulation (EU) No 1025/2012, and the presumption applies only to the extent that the standard covers the requirement or obligation concerned. The presumption is a legal advantage, not a technical guarantee. It shifts the burden of showing non conformity, but it does not remove the need for the provider to show, in the technical documentation, which standards were applied, in full or in part, and how the system conforms to them. Where a standard is applied in part, the documentation must state the part applied and the other solutions adopted for the remainder. Where a standard is not applied, the documentation must describe the solutions adopted to meet the requirements, including other standards and technical specifications applied. A provider that states that it follows a standard, without stating the part, the version and the evidence, has not shown that the presumption applies. The presumption must be claimed provision by provision, with the standard, the part and the evidence cited for each.
What are the coverage limits?
Coverage limits are the central limit on the presumption. A standard is written for a defined scope, with defined requirements, and it may cover a requirement in full, in part, or not at all. A quality management standard covers Article 17, but it does not cover data governance in Article 10, human oversight in Article 14, or accuracy in Article 15, except where its scope expressly includes those topics. A risk management standard covers Article 9, but it does not cover the transparency, logging or robustness requirements, except where its scope includes them. A standard that covers a requirement in general terms may not cover the specific AI Act detail, such as the fundamental rights considerations in the risk management process or the specific data quality criteria in Article 10. The provider must therefore create a coverage map that lists each requirement in Chapter III, Section 2 or Chapter V, the standard or specification relied on for it, the part of the standard relied on, and the evidence. Requirements with no standard coverage must be shown by other means, with the reasoning recorded. A coverage map that claims full coverage from a single standard, without examining the standard scope, will fail on inspection by a notified body or a market surveillance authority.
For the broader regulatory framework, see codes, standards and sandboxes overview.
How do common specifications under Article 41 work?
Article 41 allows the Commission to adopt common specifications by implementing act, where it has requested a harmonised standard and the request was not accepted, the standard was not delivered on time, the standard insufficiently addresses fundamental rights concerns, or the standard does not comply with the request, and where no harmonised standard reference is published or expected within a reasonable period. Common specifications are a fallback, not a parallel standardisation route, and they are adopted only where the Article 41 conditions are met. Conformity with common specifications, or parts of them, gives a presumption of conformity to the extent they cover the requirements or obligations, in the same way as harmonised standards. When a harmonised standard reference is published for the same requirements, the Commission repeals the implementing acts or the parts of them for those requirements. A provider that relies on a common specification should therefore check the implementing act, the requirements covered, the date, and whether a harmonised standard has since been cited for the same requirements. The common specification record should be kept in the same way as the standards register, with the act, the coverage and the date recorded. A provider should not treat a common specification as permanent where the Article provides for its repeal on citation of a standard.
What specific presumptions does Article 42 provide?
Article 42 provides two specific presumptions that must not be confused with the general Article 40 presumption. Article 42(1) provides that, where a high risk AI system is trained and tested on data reflecting the specific geographical, behavioural, contextual or functional setting within which it is intended to be used, it is presumed to be in conformity with the data governance requirement in Article 10(4) on bias examination and data representativeness, subject to the full conditions in the Article. That presumption is narrow and fact specific, and it depends on the data actually reflecting the setting of use. Article 42(2) provides that high risk AI systems certified or for which a statement of conformity has been issued under a cybersecurity certification scheme under Regulation (EU) 2019/881, with references published in the Official Journal, are presumed to be in conformity with the cybersecurity requirements in Article 15, to the extent the scheme and the certificate cover those requirements. That presumption also depends on coverage and on the certificate. A provider that claims either presumption should record the facts, the scheme or data evidence, and the coverage, with the Article 42 conditions checked in full. A general claim of data representativeness or of cybersecurity certification, without the specific evidence, does not show that the presumption applies.
How should a provider build a presumption file?
A presumption file should contain the standards register, the common specifications register where applicable, the coverage map, the technical documentation references, the test and evaluation evidence for each requirement, and the review record. The standards register should list each standard, its number, version, publisher, Official Journal citation and date, restrictions, and the parts applied. The coverage map should list each requirement, the standard or specification relied on, the part, the evidence, and the gaps with the other means used. The file should be reviewed when a standard is cited, withdrawn, superseded or amended, when a common specification is adopted or repealed, and when the system changes. The review should be recorded with the date and the person responsible. A file that was correct when the system was first placed on the market can become incorrect when a standard changes, and the provider must update it as part of post market monitoring and change control. The presumption file should be kept with the technical documentation, so that a notified body or an authority can follow the reasoning from requirement to standard to evidence without needing to ask for further material.
Continue with harmonised standards process.
What does this guide not decide?
This guide does not decide whether any named standard, common specification or certification gives a presumption for any named system, and it does not reproduce Articles 40 to 42 in full. The presumption position for a specific system needs the standard, the citation, the coverage map and the evidence, checked against the consolidated Articles on the date of reliance. A provider with a specific presumption question should confirm the position with a notified body or legal adviser, with the coverage map in hand. A presumption is a legal conclusion that needs the full facts, not a general statement from a guide.
Frequently asked questions
Does a harmonised standard cover all high risk requirements?
No. The presumption in Article 40 applies only to the extent that the standard covers the requirement concerned. A standard on quality management does not cover data governance or human oversight unless its scope includes them. A coverage map is needed for each requirement, with gaps demonstrated by other means.
What happens when a common specification is replaced by a standard?
Under Article 41, when a harmonised standard reference is published for the same requirements, the Commission repeals the implementing acts or parts of them for those requirements. A provider relying on a common specification must check for a later standard citation and update its file accordingly.
Does cybersecurity certification give a general presumption?
No. Article 42(2) gives a presumption for the Article 15 cybersecurity requirements only to the extent that the certification scheme and the certificate cover them, and only where the scheme reference has been published in the Official Journal. The scheme, the certificate and the coverage must be recorded.
Can a provider claim a presumption without a coverage map?
Not in a way that can be tested. The technical documentation must show which standards were applied, in full or in part, and how the system conforms. A claim without a map, a version and evidence will not show that the presumption applies to any particular requirement.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗European Commission AI Act standardisation ↗