EU AI Act Art.40 Harmonised Standards: Conformity Presumption — Developer Guide (2026)

EU AI Act Article 40 is the presumption-of-conformity engine for high-risk AI systems. Where a high-risk AI system is built in accordance with harmonised standards whose references have been published in the EU Official Journal, the system is presumed to comply — automatically — with the specific Chapter II requirements those standards cover. For developers, this is the most powerful compliance shortcut available: instead of independently demonstrating conformity with each of Arts.9–15, you demonstrate alignment with a published standard and the legal presumption does the rest.

The mechanism is not new. Harmonised standards have powered CE marking for physical products under the New Legislative Framework for decades — medical devices under MDR, machinery under the Machinery Regulation, radio equipment under RED. Art.40 imports this proven mechanism into the AI domain, adapted for the software-intensive, iterative nature of AI system development.

For cloud infrastructure providers and SaaS AI builders, Art.40 is doubly important. First, harmonised standards will define the de-facto conformity baseline — auditors, insurers, and enterprise customers will increasingly expect Art.40-aligned systems even before standards are mandatory. Second, the standards evidence you accumulate under an Art.40-aligned programme is conformity documentation that your Art.43 assessment process directly consumes. Building the standards programme early means your Art.43 assessment is faster and lower-cost.

What Art.40 Does: Four Paragraphs

Art.40(1) — The Presumption of Conformity

High-risk AI systems 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 shall be presumed to be in conformity with the requirements set out in Chapter 2 of this Title, to the extent that those requirements are covered by such standards.

Three conditions activate the presumption:

1. The standard must be a harmonised standard under EU Regulation 1025/2012 (not any ISO/IEC standard — only those given an EN designation and published in the OJ)
2. The reference to that standard must be published in the Official Journal — this is the formal act that activates the presumption
3. The standard must cover the specific requirement — the presumption applies requirement-by-requirement, not wholesale

Scope limitation: The presumption covers Chapter II requirements (Arts.8–15: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy/robustness/cybersecurity). It does not cover Chapter III obligations (Art.16 provider duties, Art.17 QMS, Art.18 post-market monitoring, etc.) — those remain separate compliance obligations.

Art.40(2) — Commission Standardisation Requests

The Commission can issue standardisation requests (mandates) to one or more European standardisation organisations (ESOs): CEN, CENELEC, or ETSI, under the procedure of Art.10 of Regulation (EU) No 1025/2012.

A Commission mandate is not an instruction — ESOs retain technical independence. But mandates define the scope and timeline. The AI Act mandate to CEN-CENELEC (via JTC 21) is the primary vehicle for generating the harmonised standards corpus the AI Act needs.

Art.40(3) — Official Journal Publication

The Commission publishes references to harmonised standards in the Official Journal. Until a reference is published, even an EN-designated standard does not trigger the Art.40(1) presumption. For developers tracking standards, the OJ reference date — not the standard's own publication date — is the operative moment.

Art.40(4) — Commission Review Before Publication

Before publishing a reference, the Commission assesses whether the harmonised standard sufficiently covers the applicable requirements. This is the quality gate. A standard can be technically published as an EN before the Commission is satisfied it fully covers the relevant requirements — in which case the OJ reference is withheld until the gap is closed. This matters for developers who adopt standards early: confirm the OJ reference exists before treating the presumption as active.

The 2026 Standards Landscape

What Exists Today

As of 2026, the harmonised standards specifically designed for Art.40 are still maturing through the CEN-CENELEC JTC 21 process. The full corpus needed to cover Arts.9–15 is not yet in place. The current position:

Practical consequence: In 2026, developers cannot fully rely on Art.40 presumptions for all Chapter II requirements. Art.41 Common Specifications (the Commission fallback) will fill gaps where harmonised standards are absent or incomplete. Developers should design their compliance programmes to support both pathways.

The CEN-CENELEC JTC 21 Mandate

The European Commission issued a mandate to CEN and CENELEC (M/591) to develop harmonised standards supporting the EU AI Act. JTC 21 (Joint Technical Committee 21, AI) is the primary body executing this mandate, working across:

• WG 1: Foundational standards (vocabulary, concepts)
• WG 2: AI trustworthiness
• WG 3: Use cases and applications
• WG 4: AI sustainability
• WG 5: AI governance
• WG 6: AI assessment methodologies

ETSI has parallel work streams relevant to telecommunications-embedded AI. Vertical harmonised standards (e.g., for medical AI under MDR, safety AI under Machinery Regulation) involve additional bodies.

ISO/IEC 42001 and EU AI Act Alignment

ISO/IEC 42001:2023 (AI management system — Requirements) is the most comprehensive published standard aligned with EU AI Act concepts. It covers:

• AI policy, objectives, risk management
• AI system lifecycle controls
• Data management (alignment with Art.10)
• Human oversight provisions (alignment with Art.14)
• Monitoring and performance evaluation (alignment with Art.9)
• Transparency and documentation (alignment with Art.13)

ISO/IEC 42001 certification does not trigger Art.40 presumption until the EN designation and OJ reference are in place. However, building your compliance programme on 42001 now creates a migration path to Art.40 presumption when the OJ reference publishes.

Art.40 × Chapter II Requirements Coverage Matrix

Developer implication: Until OJ references publish, treat standards adoption as preparation for Art.40 rather than active presumption. Maintain independent conformity evidence for each Art.9–15 requirement in parallel.

Art.40 vs Art.41: Harmonised Standards vs Common Specifications

Art.41 provides the Commission's fallback power: when harmonised standards are absent, insufficient, or contested, the Commission can issue Common Specifications (delegated acts) that establish the technical requirements directly. Common Specifications under Art.41 carry the same presumption of conformity as harmonised standards under Art.40 — but they bypass the ESO process entirely.

Strategic implication: Align now with the emerging harmonised standards (ISO/IEC 42001, JTC 21 outputs) rather than waiting for Art.41 Common Specifications. Common Specifications are a regulatory backstop, not a compliance strategy.

Art.40 × Art.43: Standards Feeding Conformity Assessment

The Art.40 presumption has a direct mechanistic relationship with Art.43 conformity assessment:

Track 1 (Annex VI — Internal Control): When harmonised standards are active, the internal control assessment under Annex VI uses the standard coverage as its primary evidence base. The provider's QMS (Art.17) documents how the system was built against the standard. The conformity evidence file references specific standard clauses to the Art.9–15 requirements they cover.

Track 2 (Annex VII — Notified Body): Notified bodies are accredited to assess against specific standards. When an EN-designated standard is active and the notified body is accredited for it, the assessment process uses the standard's requirements as its test methodology. A system demonstrably conformant with a harmonised standard passes the notified body assessment for the requirements the standard covers.

Conformity assessment efficiency gain: A fully harmonised standards programme (when active) converts Art.43 assessment from open-ended requirement analysis to structured standard-clause-by-clause verification. This is faster, cheaper, and more auditor-legible than bespoke requirement-by-requirement analysis.

Art.40 × Art.48: Standards References in the Declaration of Conformity

Under Art.48(2), the EU Declaration of Conformity must include the harmonised standards applied and the common specifications complied with. This is the documentary link between the Art.40 presumption and the Art.48 compliance assertion:

Declaration of Conformity — Standards Section
─────────────────────────────────────────────
Harmonised standards applied:
  - EN ISO/IEC 42001:2023 (AI Management System) [when OJ reference active]
  - EN ISO/IEC 23894:2023 (AI Risk Management) [when OJ reference active]
  
Requirements covered by above standards:
  - Art.9 (Risk Management System) — covered by EN ISO/IEC 23894 §6.1–6.4
  - Art.10 (Data Governance) — covered by EN ISO/IEC 42001 §8.4
  - Art.13 (Transparency) — covered by EN ISO/IEC 42001 §8.5.3
  
Requirements NOT covered by harmonised standards (independent conformity evidence required):
  - Art.11 (Technical Documentation) — independent evidence [Annex IV package]
  - Art.12 (Record-Keeping) — independent evidence [audit log system]
  - Art.14 (Human Oversight) — independent evidence [override testing records]
  - Art.15 (Accuracy/Robustness) — independent evidence [performance benchmarks]

Maintaining this mapping — which Art.9–15 requirements each standard covers, and which require independent evidence — is the core records management task of an Art.40-aligned programme.

CLOUD Act × Art.40: Standards Evidence Jurisdiction Risk

Harmonised standards evidence generated by conformity assessments (test results, gap analyses, standard clause verification reports) is documentation subject to the same CLOUD Act jurisdiction analysis as other conformity records.

The CLOUD Act exposure pathway for standards evidence:

1. Developer uses a US-based conformity assessment consultancy to produce Art.40 standards gap analysis
2. Gap analysis documents are stored on US-entity infrastructure (AWS, Azure, Google Cloud under US parent)
3. US federal agency issues CLOUD Act order to the consultancy or cloud provider
4. Standards gap analysis — including identified non-conformities and remediation plans — is compelled to disclosure without notice to the EU provider

For high-risk AI systems handling sensitive data (biometrics, critical infrastructure), this is not a theoretical exposure. An Art.40 conformity programme produces documentation that, if compelled, could reveal system architecture weaknesses and compliance gaps.

Mitigation: Store standards evidence — gap analyses, clause-by-clause mapping tables, test results, assessor reports — on EU-sovereign infrastructure where no CLOUD Act compellability exists. This is the same infrastructure sovereignty argument that applies to technical documentation under Art.11, conformity records under Art.18, and certificates under Art.44. A single EU-sovereign record-keeping infrastructure covers all of them.

Python Implementation: Harmonised Standards Tracking

from dataclasses import dataclass, field
from datetime import date
from typing import Optional
from enum import Enum

class PresumptionStatus(Enum):
    ACTIVE = "active"           # OJ reference published
    PENDING = "pending"         # EN designation done, OJ reference not yet published
    NOT_YET = "not_yet"        # Standard in development / not EN-designated
    WITHDRAWN = "withdrawn"     # OJ reference withdrawn

class RequirementCoverage(Enum):
    FULL = "full"               # Standard fully covers requirement
    PARTIAL = "partial"         # Standard partially covers requirement
    NONE = "none"               # Standard does not cover requirement

@dataclass
class HarmonisedStandardRecord:
    standard_id: str                    # e.g., "EN ISO/IEC 42001:2023"
    title: str
    eso: str                            # CEN | CENELEC | ETSI
    iso_base: Optional[str]            # e.g., "ISO/IEC 42001:2023"
    en_publication_date: Optional[date]
    oj_reference_date: Optional[date]   # None if not yet published
    presumption_status: PresumptionStatus
    requirements_covered: dict[str, RequirementCoverage]  # art_ref -> coverage
    
    @property
    def presumption_active(self) -> bool:
        return self.presumption_status == PresumptionStatus.ACTIVE
    
    def covers_requirement(self, art_ref: str) -> bool:
        """Returns True if standard provides at least partial coverage."""
        coverage = self.requirements_covered.get(art_ref, RequirementCoverage.NONE)
        return coverage != RequirementCoverage.NONE

@dataclass
class ConformityPresumptionChecker:
    """Evaluates Art.40 presumption coverage for a high-risk AI system."""
    
    standards: list[HarmonisedStandardRecord] = field(default_factory=list)
    
    CHAPTER_II_REQUIREMENTS = [
        "Art.9",   # Risk management
        "Art.10",  # Data governance
        "Art.11",  # Technical documentation
        "Art.12",  # Record-keeping
        "Art.13",  # Transparency
        "Art.14",  # Human oversight
        "Art.15",  # Accuracy/robustness/cybersecurity
    ]
    
    def active_standards(self) -> list[HarmonisedStandardRecord]:
        return [s for s in self.standards if s.presumption_active]
    
    def presumption_coverage_map(self) -> dict[str, list[str]]:
        """Returns mapping of requirement -> list of active standard IDs that cover it."""
        coverage: dict[str, list[str]] = {req: [] for req in self.CHAPTER_II_REQUIREMENTS}
        for std in self.active_standards():
            for req in self.CHAPTER_II_REQUIREMENTS:
                if std.covers_requirement(req):
                    coverage[req].append(std.standard_id)
        return coverage
    
    def uncovered_requirements(self) -> list[str]:
        """Requirements NOT covered by any active harmonised standard."""
        coverage_map = self.presumption_coverage_map()
        return [req for req, stds in coverage_map.items() if not stds]
    
    def conformity_report(self) -> dict:
        coverage_map = self.presumption_coverage_map()
        uncovered = self.uncovered_requirements()
        return {
            "active_standards": [s.standard_id for s in self.active_standards()],
            "coverage_by_requirement": coverage_map,
            "uncovered_requirements": uncovered,
            "independent_evidence_needed_for": uncovered,
            "doc_ref_note": (
                "Uncovered requirements require independent conformity evidence "
                "and must be detailed in the DoC per Art.48(2)."
            )
        }


@dataclass
class StandardsComplianceTracker:
    """Tracks organisation's clause-by-clause compliance with a harmonised standard."""
    
    standard_id: str
    clauses_assessed: dict[str, bool] = field(default_factory=dict)  # clause -> compliant
    evidence_locations: dict[str, str] = field(default_factory=dict)  # clause -> evidence path
    gaps: list[str] = field(default_factory=list)
    
    def assess_clause(self, clause: str, compliant: bool, evidence: str = "") -> None:
        self.clauses_assessed[clause] = compliant
        if evidence:
            self.evidence_locations[clause] = evidence
        if not compliant and clause not in self.gaps:
            self.gaps.append(clause)
    
    @property
    def compliance_rate(self) -> float:
        if not self.clauses_assessed:
            return 0.0
        compliant = sum(1 for v in self.clauses_assessed.values() if v)
        return compliant / len(self.clauses_assessed)
    
    def gap_summary(self) -> dict:
        return {
            "standard": self.standard_id,
            "clauses_assessed": len(self.clauses_assessed),
            "compliance_rate": f"{self.compliance_rate:.1%}",
            "open_gaps": self.gaps,
            "gap_count": len(self.gaps),
        }


# Example: 2026 standards state
STANDARDS_2026 = ConformityPresumptionChecker(standards=[
    HarmonisedStandardRecord(
        standard_id="EN ISO/IEC 23894:2023",
        title="AI Risk Management",
        eso="CEN/CENELEC",
        iso_base="ISO/IEC 23894:2023",
        en_publication_date=date(2023, 11, 1),
        oj_reference_date=None,  # OJ reference pending as of 2026
        presumption_status=PresumptionStatus.PENDING,
        requirements_covered={
            "Art.9": RequirementCoverage.PARTIAL,
        },
    ),
    HarmonisedStandardRecord(
        standard_id="EN ISO/IEC 42001:2023",
        title="AI Management System",
        eso="CEN/CENELEC",
        iso_base="ISO/IEC 42001:2023",
        en_publication_date=None,  # EN adoption in progress
        oj_reference_date=None,
        presumption_status=PresumptionStatus.NOT_YET,
        requirements_covered={},  # No active presumption yet
    ),
])

# Get what's currently NOT covered (everything, given pending OJ references)
report = STANDARDS_2026.conformity_report()
print(f"Uncovered requirements (need independent evidence): {report['uncovered_requirements']}")

Art.40 Intersection Matrix

Practical Compliance Programme

Phase 1: Standards Inventory (Now)

Even before OJ references publish, build your standards inventory:

1. Identify candidate standards: ISO/IEC 42001, ISO/IEC 23894, emerging JTC 21 outputs
2. Map to requirements: For each candidate, document which Art.9–15 requirements it covers (and how completely)
3. Track OJ reference status: Monitor the EU Official Journal for new references at eur-lex.europa.eu/oj/

Phase 2: Gap Analysis Against Best Available Standards

Perform clause-by-clause assessment against ISO/IEC 42001 (or EN equivalent when published):

1. Document coverage: Which clauses address which requirements
2. Identify gaps: Requirements where the standard offers no coverage
3. Build independent evidence: For uncovered requirements, develop bespoke conformity evidence now

Phase 3: Transition to Active Presumption

When OJ references publish:

1. Activate presumption: Update your conformity documentation to reference the OJ publication date
2. Update DoC: Amend Art.48 Declaration of Conformity to list the harmonised standards
3. Notify notified body (if applicable): If Track 2 assessment is in progress, inform the notified body that OJ reference is now active

Phase 4: Ongoing Standards Surveillance

1. Monitor for revisions: Standards are revised; substantial revisions may require reassessment
2. Monitor for OJ reference withdrawal: The Commission can withdraw references (Art.40(4)); withdrawal restores the requirement to demonstrate independent conformity
3. Monitor for Art.41 Common Specifications: If the Commission issues CS covering areas your standards miss, update your programme

30-Item Harmonised Standards Checklist

Standards Identification (1–7)

• 1. Identified all harmonised standards relevant to your high-risk AI system category
• 2. Confirmed which standards have active OJ references (not just EN designation)
• 3. Tracked the OJ reference date for each active standard
• 4. Identified standards with pending EN adoption or OJ reference (monitoring required)
• 5. Assessed whether ETSI or vertical-sector standards apply (medical, machinery, telecoms AI)
• 6. Checked for Art.41 Common Specifications that supplement or replace harmonised standards
• 7. Documented the standards inventory in your Art.17 QMS records

Coverage Mapping (8–14)

• 8. Mapped each active harmonised standard to specific Art.9–15 requirements it covers
• 9. Identified requirements with full standard coverage (presumption fully active)
• 10. Identified requirements with only partial standard coverage (partial presumption; gap analysis needed)
• 11. Identified requirements with no standard coverage (independent conformity evidence mandatory)
• 12. Built a requirements-to-standards matrix (the Art.40(1) presumption map)
• 13. Documented which requirements rely on Art.41 Common Specifications vs Art.40 standards
• 14. Confirmed that Art.40 presumption extends only to Chapter II (Arts.8–15), not Arts.16–30 obligations

Compliance Evidence (15–21)

• 15. Performed clause-by-clause assessment against each adopted harmonised standard
• 16. Documented evidence for each clause assessed (records, test results, audit findings)
• 17. Stored evidence in EU-sovereign infrastructure (CLOUD Act jurisdiction isolation)
• 18. Linked standards evidence to Art.11/Annex IV technical documentation
• 19. Documented independent conformity evidence for requirements not covered by standards
• 20. Established retention schedule for standards evidence (minimum 10 years per Art.18)
• 21. Built gap remediation plan for open non-conformities in clause assessments

Declaration of Conformity Integration (22–25)

• 22. Listed all applied harmonised standards in Art.48(2) DoC with OJ reference dates
• 23. Listed requirements covered by each standard in the DoC
• 24. Listed requirements with independent evidence (not covered by standards) in the DoC
• 25. Version-controlled the DoC against each standards revision that affects coverage

Ongoing Surveillance (26–30)

• 26. Set up OJ monitoring for new harmonised standard references relevant to your AI category
• 27. Set up monitoring for OJ reference withdrawals (Commission can restrict per Art.40(4))
• 28. Set up monitoring for JTC 21 working drafts approaching EN publication
• 29. Defined trigger criteria for conformity reassessment when a standard is substantially revised
• 30. Included standards evolution tracking in your Art.9 risk management review cycle

Key Takeaways for Developers

1. Art.40 is the compliance shortcut — but it is not yet fully active (2026). The harmonised standards corpus is maturing. Plan for a mixed programme: partial Art.40 presumption where OJ references exist, independent evidence for uncovered requirements.

2. ISO/IEC 42001 is the right starting point. Build your AI management system against 42001 now. When the EN adoption and OJ reference publish, your existing programme converts to an active Art.40 presumption with minimal additional effort.

3. Monitor the OJ, not the standards bodies. A standard can be published months before its OJ reference appears. The presumption activates on the OJ reference date, not the EN publication date.

4. Art.41 Common Specifications are the regulatory fallback. Do not plan your programme around them — they are less developer-friendly than industry-driven harmonised standards. But know they exist and monitor the Commission's adoption timeline.

5. Store standards evidence on EU-sovereign infrastructure. Standards conformity documentation — gap analyses, clause-by-clause assessments, test results — carries CLOUD Act jurisdiction risk if held on US-entity infrastructure. One EU-sovereign records system covers Art.40 evidence and all other AI Act conformity documentation.

6. Art.40 × Art.43 integration is the efficiency gain. A mature harmonised standards programme dramatically reduces the cost and duration of Art.43 conformity assessment. The investment in standards alignment pays back in assessment efficiency.