2026-04-23·13 min read·

EU AI Act Art.37: Common Specifications for High-Risk AI Systems — Commission Implementing Acts, Mandatory Compliance Baseline, and the Art.36 Fallback Architecture (2026)

Article 37 of the EU AI Act establishes the Commission's power to issue common specifications — implementing acts containing technical requirements that providers of high-risk AI systems must comply with when the harmonised standards framework under Art.36 is absent or inadequate. Where Art.36 relies on a cooperative, standardisation-body-led process that produces voluntary standards published in the Official Journal, Art.37 creates a direct Commission pathway that produces mandatory requirements enforceable without the intermediary of a standardisation body.

Understanding Art.37 is essential for providers who are monitoring the EU AI Act compliance landscape, because common specifications represent the binding floor when the market-led harmonised standards process cannot deliver adequate coverage in time. A provider who assumes that harmonised standards will arrive before obligations apply, and therefore defers compliance documentation, risks being caught by a common specification with immediate effect.

Art.37's Position in the Section 5 Architecture

Art.37 sits immediately after Art.36 (harmonised standards) and before Art.38 (existing Union harmonised legislation) in Chapter III, Section 5. This placement is architecturally deliberate: Section 5 establishes the layered conformity demonstration framework, and Art.37 is the fallback layer when the primary layer fails.

The three-tier Section 5 hierarchy is:

Art.36 — Harmonised standards (primary pathway): CEN/CENELEC-developed standards, published in the Official Journal, creating a rebuttable presumption of conformity. Voluntary. Provider choice to use or demonstrate compliance by other means.
Art.37 — Common specifications (fallback pathway): Commission-issued implementing acts, activated when harmonised standards are unavailable or inadequate. Mandatory when invoked — providers in the relevant scope cannot choose to ignore common specifications in the way they can choose not to use harmonised standards.
Bespoke compliance pathway (always available): Direct demonstration of compliance with the underlying Arts.8–15 requirements without relying on standards or common specifications. Higher documentation burden, no presumption of conformity, but always permitted under the AI Act's performance-based regulatory approach.

Art.37 functions as the backstop that ensures providers always have a technically specified baseline to work with, even if the standardisation process has not yet delivered harmonised standards for their system category.

The Two Triggers for Art.37 Common Specifications

The Commission's power to issue common specifications under Art.37 is conditional, not unlimited. Two distinct triggers can activate the mechanism:

Trigger 1 — No harmonised standards available: When no harmonised standard has been published in the Official Journal covering a requirement applicable to a specific category of high-risk AI systems, the Commission may adopt a common specification covering those requirements. This trigger addresses the standardisation gap problem: the EU AI Act's obligations apply from the relevant application date regardless of whether harmonised standards exist, and providers in sectors where CEN-CLC/JTC 21 has not yet produced published standards would otherwise have no technical reference point beyond the statute itself.

Trigger 2 — Published standards are insufficient: When harmonised standards have been published but the Commission considers that they do not adequately satisfy the relevant AI Act requirements, the Commission may adopt a common specification to supplement or supersede those standards. This trigger addresses the adequacy problem: a published harmonised standard that technically satisfies the standardisation request but that market surveillance experience shows is insufficient to prevent non-compliant systems from reaching the market may be supplemented or replaced by a common specification.

The distinction between the two triggers matters for providers because the legal effect is different in each case:

Under Trigger 1, no harmonised standard exists, so the common specification is the only Art.36/Art.37 pathway available. Providers have no choice between voluntary standard and mandatory specification.
Under Trigger 2, a harmonised standard exists alongside the common specification. The Commission's adoption of a common specification under this trigger signals that relying on the harmonised standard alone is no longer sufficient for the purposes of presumption of conformity. Providers who have built their compliance documentation around the harmonised standard must assess whether they need to supplement it to address the common specification's additional requirements.

Mandatory Nature of Common Specifications

The most important operational difference between Art.36 harmonised standards and Art.37 common specifications is their legal character. Harmonised standards under Art.36 are voluntary: using them is the most efficient path to demonstrating compliance (because compliance with the standard creates a presumption of conformity with the underlying requirement), but a provider can decline to use a harmonised standard and instead demonstrate compliance with the underlying Art.8–15 requirements directly.

Common specifications under Art.37 do not work this way. When the Commission adopts a common specification covering a requirement applicable to a provider's high-risk AI system category, that provider must comply with the common specification unless they can demonstrate that they comply with the underlying requirement through an alternative means that achieves at least the level of protection established by the common specification.

This mandatory character means that providers cannot simply ignore a common specification in the way they can deprioritise a harmonised standard. Non-compliance with a common specification is direct non-compliance with an implementing act — an EU legislative measure — rather than simply a failure to use a voluntary technical standard. Market surveillance authorities can base enforcement actions directly on common specification non-compliance without needing to establish that the underlying Art.8–15 requirements have been violated.

The Commission's Consultation Obligations

Before adopting a common specification, Art.37 requires the Commission to consult specified stakeholders. This consultation obligation serves both procedural legitimacy and technical accuracy purposes: technical requirements that have not been reviewed by the relevant expert community are more likely to contain errors or impose disproportionate burdens on providers.

The Commission must consult:

The relevant European standardisation bodies: CEN, CENELEC, and ETSI must be given the opportunity to comment on the proposed common specification. This consultation requirement reflects the fact that standardisation bodies retain their role as the primary technical standards-setting institutions under the AI Act framework, and the Commission's power to bypass them under Art.37 is exceptional and subject to their oversight.
The AI Office: The AI Office, established under Art.64, has supervisory and enforcement responsibilities across the AI Act. Its input into common specifications ensures that the technical requirements are consistent with enforcement practice and the AI Office's understanding of risk patterns in the affected sector.
Relevant stakeholders and experts: The AI Act's co-regulatory philosophy — shared responsibility between legislators, standardisation bodies, industry, and civil society — extends to the common specification process. Expert groups, industry representatives, civil society organisations, and affected provider communities must have an opportunity to submit technical input before a common specification is finalised.

Practically, this means that common specifications do not appear without warning. The Commission's consultation processes are public, and providers who monitor EU regulatory developments can track proposed common specifications through the public consultation phases before adoption. Providers in sectors where harmonised standards are delayed should proactively monitor the Commission's standardisation gap assessment to anticipate where Trigger 1 common specifications are most likely to emerge.

Adopting Common Specifications as Implementing Acts Under Art.97

Common specifications are adopted as implementing acts under the examination procedure set out in Art.97 of the EU AI Act, in accordance with Regulation (EU) No 182/2011. This means:

The Commission prepares a draft implementing act containing the proposed common specification
The draft is submitted to the AI Standing Committee (the regulatory committee established under Art.97, composed of Member State representatives)
The AI Standing Committee delivers an opinion by qualified majority vote
If the opinion is positive (or if the committee fails to deliver an opinion), the Commission may adopt the implementing act
If the opinion is negative, the Commission may submit the draft to an appeal committee or adopt a revised version

The implementing act is then published in the Official Journal of the European Union and enters into force in accordance with its own terms. Unlike harmonised standards, which create a presumption of conformity that providers choose to invoke, a common specification implementing act is part of EU secondary legislation and is directly binding on providers within its scope from the date of its application.

Providers should monitor the Official Journal not only for harmonised standard references under Art.36 but also for implementing acts containing common specifications under Art.37. The two legal instruments appear in different parts of the Official Journal (standards references in the L Series; implementing acts also in the L Series but as legislative measures rather than communications), so providers tracking both categories need different monitoring approaches.

Presumption of Conformity From Common Specifications

Compliance with a common specification creates a presumption of conformity with the EU AI Act requirements that the common specification covers, equivalent to the presumption created by a harmonised standard under Art.36. This presumption operates identically to the Art.36 presumption: it is rebuttable by market surveillance authorities who can produce evidence of actual non-compliance notwithstanding compliance with the common specification, and it applies only to the requirements within the scope of the common specification.

The equivalence of the two presumptions is deliberately designed. From a provider's perspective, building a compliance documentation architecture around a common specification should produce the same regulatory outcome as building it around a harmonised standard. The provider who complies with a common specification covering Art.14 human oversight requirements can present that compliance to a notified body or market surveillance authority as evidence of conformity with Art.14, using the same documentation structures and audit trails as a provider relying on a harmonised standard.

This equivalence also means that the partial-coverage problem applies equally to common specifications as to harmonised standards. A common specification that covers Art.13 transparency requirements but not Art.15 robustness requirements creates a presumption only for Art.13, and providers must separately address Art.15 compliance — whether by relying on a harmonised standard (if one exists for Art.15 in their sector), another common specification, or direct compliance demonstration.

How Common Specifications Interact With Art.43 Conformity Assessment

Art.43 governs the conformity assessment procedures that providers must complete before placing high-risk AI systems on the EU market. Compliance with common specifications feeds into Art.43 in two ways:

For Annex III systems using internal-control self-assessment under Art.43(2): The provider's technical documentation must demonstrate compliance with all applicable requirements. When a common specification exists covering requirements applicable to the provider's system, the documentation should establish compliance with that common specification. Since the common specification creates a presumption of conformity, documentary evidence of common specification compliance — testing records, technical analyses, design documentation aligned with the specification's requirements — satisfies the Art.43 documentation obligation for the covered requirements.

For systems requiring notified body assessment under Art.43(1): The notified body assessing the provider's technical documentation will use the relevant harmonised standards and common specifications as the assessment framework. A provider who has not aligned their technical documentation with an applicable common specification will face an adverse assessment finding, because the notified body will identify the common specification as the applicable compliance baseline and find the documentation insufficient for not addressing it.

Providers whose systems fall within the scope of a common specification should update their Art.43 compliance documentation to address the specification's requirements before beginning a notified body assessment, and should ensure that their ongoing quality management system (required under Art.17 for providers of Annex III systems) incorporates monitoring of common specification updates.

The 2026 Common Specifications Landscape

As of 2026, the Commission has not yet adopted common specifications under Art.37 for most EU AI Act high-risk system categories. The standardisation process under CEN-CLC/JTC 21 remains the primary pathway for providers to obtain technical guidance on the Arts.8–15 requirements. However, several factors increase the probability of Art.37 common specifications emerging in the near term:

Standardisation timeline pressure: The EU AI Act's application dates for high-risk system categories in Annex III (excluding financial services, insurance, and migration systems) took effect in 2026. For system categories where CEN-CLC/JTC 21 has not yet published harmonised standards in the Official Journal, providers are operating in a standards gap. If the standardisation process continues to lag behind the Act's application timeline, the Commission has both the authority and the political incentive to adopt common specifications.

GPAI model obligations: The general-purpose AI model obligations under Chapter V (Arts.53–55) took effect in August 2025, and the Commission's implementing measures for GPAI model risk assessments are still being developed. Common specifications for GPAI model providers are a likely area of Commission action if the evolving GPAI model codes of practice do not produce adequate technical guidance.

High-priority risk areas: Market surveillance authorities in Member States have identified certain Annex III categories — particularly AI systems in employment decisions, access to essential services, and law enforcement — as priority enforcement areas. If harmonised standards for these categories do not emerge on schedule, the Commission may prioritise common specifications for them.

Providers should monitor:

Commission implementing act proposals published in the Official Journal
AI Office documentation on standardisation gap assessments
The CEN-CLC/JTC 21 work programme for indication of which deliverables are on schedule vs. delayed
National competent authority guidance on interim compliance approaches for categories without harmonised standards

Updating and Amending Common Specifications

Art.37 also addresses the lifecycle management of common specifications once adopted. The Commission may amend, supplement, or repeal common specifications using the same implementing act procedure under Art.97. Amendments to common specifications can be triggered by:

New technical evidence showing that the existing requirements are insufficient
Developments in the harmonised standards landscape (for example, if a harmonised standard is published that adequately covers an area previously addressed by a common specification, the Commission may repeal the common specification for that area to simplify the compliance landscape)
Feedback from market surveillance authorities on enforcement experience
Technological changes that make existing technical requirements obsolete or inadequate

Providers whose compliance documentation is built around a common specification must maintain a monitoring programme for amendments. An amended common specification does not automatically invalidate prior compliance documentation, but providers must assess whether the amended requirements materially change the technical baseline and whether their existing systems continue to satisfy the updated specification.

The transition period for amendments to common specifications is established in the amending implementing act. Providers should not assume that a transition period equivalent to the original common specification's application date applies to amendments — amending acts may provide shorter transition periods if the Commission considers the amendment urgent.

Provider Decision Matrix: Art.36 vs. Art.37 Pathways

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

class ConformityPathway(str, Enum):
    HARMONISED_STANDARD = "Art.36 — Harmonised Standard"
    COMMON_SPECIFICATION = "Art.37 — Common Specification"
    BOTH = "Art.36 + Art.37 — Both available"
    BESPOKE = "Bespoke — No standard or specification available"

class ComplianceObligation(str, Enum):
    VOLUNTARY = "Voluntary — provider may choose alternative pathway"
    MANDATORY = "Mandatory — provider must comply or demonstrate equivalent"
    MANDATORY_WITH_ALTERNATIVE = "Mandatory with alternative — must meet level of protection"

@dataclass
class ConformityPathwayAssessment:
    requirement: str
    system_category: str
    harmonised_standard_available: bool
    harmonised_standard_oj_published: bool
    common_specification_available: bool
    harmonised_standard_deemed_insufficient: bool = False

    def determine_pathway(self) -> ConformityPathway:
        has_valid_standard = (
            self.harmonised_standard_available
            and self.harmonised_standard_oj_published
            and not self.harmonised_standard_deemed_insufficient
        )
        if has_valid_standard and self.common_specification_available:
            return ConformityPathway.BOTH
        if has_valid_standard:
            return ConformityPathway.HARMONISED_STANDARD
        if self.common_specification_available:
            return ConformityPathway.COMMON_SPECIFICATION
        return ConformityPathway.BESPOKE

    def compliance_obligation(self) -> ComplianceObligation:
        pathway = self.determine_pathway()
        if pathway == ConformityPathway.HARMONISED_STANDARD:
            return ComplianceObligation.VOLUNTARY
        if pathway == ConformityPathway.COMMON_SPECIFICATION:
            return ComplianceObligation.MANDATORY_WITH_ALTERNATIVE
        if pathway == ConformityPathway.BOTH:
            return ComplianceObligation.MANDATORY_WITH_ALTERNATIVE
        return ComplianceObligation.VOLUNTARY

    def documentation_strategy(self) -> str:
        pathway = self.determine_pathway()
        if pathway == ConformityPathway.HARMONISED_STANDARD:
            return (
                "Document compliance with harmonised standard. "
                "Maintain OJ reference monitoring for version updates. "
                "No mandatory common specification — standard is primary pathway."
            )
        if pathway == ConformityPathway.COMMON_SPECIFICATION:
            return (
                "Common specification is mandatory compliance baseline. "
                "Align technical documentation with CS requirements. "
                "Monitor Official Journal for CS amendments and updates. "
                "Document alternative pathway if deviating from CS."
            )
        if pathway == ConformityPathway.BOTH:
            return (
                "Common specification mandatory — standard insufficient per Commission finding. "
                "Use harmonised standard as baseline, supplement with CS gap analysis. "
                "Document compliance with both instruments where scopes overlap. "
                "CS requirements take precedence where they conflict with standard."
            )
        return (
            "No standard or specification available. "
            "Demonstrate compliance directly with Arts.8–15 requirements. "
            "Document technical analysis, testing, and risk assessment methodology. "
            "Monitor CEN-CLC/JTC 21 pipeline and Commission implementing act proposals."
        )


class CommonSpecificationsComplianceTracker:
    """Tracks provider compliance with Art.37 common specifications."""

    def __init__(self, provider_name: str, system_id: str):
        self.provider_name = provider_name
        self.system_id = system_id
        self.applicable_specifications: list[dict] = []
        self.compliance_records: list[dict] = []

    def add_specification(
        self,
        cs_reference: str,
        oj_publication_date: str,
        requirements_covered: list[str],
        application_date: str,
        trigger: str,
    ) -> None:
        self.applicable_specifications.append({
            "cs_reference": cs_reference,
            "oj_publication_date": oj_publication_date,
            "requirements_covered": requirements_covered,
            "application_date": application_date,
            "trigger": trigger,
            "status": "monitoring",
        })

    def record_compliance(
        self,
        cs_reference: str,
        compliance_evidence: list[str],
        assessment_date: str,
        gaps_identified: list[str],
    ) -> None:
        self.compliance_records.append({
            "cs_reference": cs_reference,
            "compliance_evidence": compliance_evidence,
            "assessment_date": assessment_date,
            "gaps_identified": gaps_identified,
            "compliant": len(gaps_identified) == 0,
        })

    def coverage_gaps(self) -> list[dict]:
        covered_requirements = set()
        for record in self.compliance_records:
            if record["compliant"]:
                for spec in self.applicable_specifications:
                    if spec["cs_reference"] == record["cs_reference"]:
                        covered_requirements.update(spec["requirements_covered"])
        all_requirements = set()
        for spec in self.applicable_specifications:
            all_requirements.update(spec["requirements_covered"])
        return [
            {"requirement": req, "status": "gap — no compliant CS coverage"}
            for req in all_requirements - covered_requirements
        ]

    def monitoring_obligations(self) -> list[str]:
        return [
            f"Monitor OJ for amendments to {spec['cs_reference']}"
            for spec in self.applicable_specifications
        ] + [
            "Monitor AI Office for new common specification proposals",
            "Monitor CEN-CLC/JTC 21 for harmonised standards that may replace CS",
            "Review Commission implementing act consultations quarterly",
        ]

Common Specifications Coverage Decision Matrix

Scenario	Art.36 Available	Art.37 CS Active	Trigger	Provider Action
Standard gap, no CS	No	No	—	Bespoke compliance + monitor pipeline
Standard gap, CS issued	No	Yes	Trigger 1	CS mandatory — align documentation
Standard published, adequate	Yes	No	—	Standard voluntary — use or bespoke
Standard published, CS also issued	Yes	Yes	Trigger 2	CS mandatory — standard insufficient
Standard amended, CS pending	Yes (old)	Pending	Trigger 2	Monitor; CS overrides once in force
CS repealed, standard adequate	Yes	Repealed	—	Standard voluntary again
CS amended	Yes/No	Yes (amended)	—	Assess amendment impact on documentation

24-Item Art.37 Common Specifications Provider Checklist

Scope Identification (Items 1–6)

Identify all EU AI Act requirements (Arts.8–15, Annex IV) applicable to your system category
For each requirement, determine whether a harmonised standard covers it (Art.36 check)
For requirements without harmonised standard coverage, monitor for active or proposed common specifications
Check the Official Journal for published implementing acts containing common specifications for your Annex III category
Check the AI Office's published documentation on standardisation gaps and interim compliance guidance
If operating in a sector with delayed standardisation (employment, critical infrastructure, law enforcement), actively monitor Commission implementing act proposals

Compliance Documentation (Items 7–14)

For each applicable common specification, map the CS requirements to your system's technical architecture
Identify gaps between your current technical documentation and the CS requirements
Prepare gap closure plan with timeline aligned to the CS application date
Document compliance evidence for each CS requirement: testing records, design analysis, risk assessment outputs
If deviating from CS requirements, document the alternative means and demonstrate equivalence
Align your Art.17 quality management system to incorporate CS compliance monitoring
Update your Art.13 instructions for use documentation to reference CS compliance where relevant
Prepare Art.48 Declaration of Conformity annex referencing applicable common specifications

Notified Body and Conformity Assessment (Items 15–18)

Before initiating Art.43 notified body assessment, ensure technical documentation addresses all applicable CSs
Provide the notified body with the list of applicable common specifications and your compliance evidence
For internal-control self-assessment under Art.43(2), conduct self-assessment against CS requirements as if a notified body were reviewing
Document the Art.35 conformity assessment pathway selection in the context of any applicable CS

Monitoring and Lifecycle Management (Items 19–24)

Establish Official Journal monitoring for new or amended common specification implementing acts
Subscribe to AI Office updates on common specification proposals and standardisation gap assessments
Monitor CEN-CLC/JTC 21 work programme for harmonised standards that may replace applicable CSs
When a CS is amended, assess whether the amendment requires documentation updates before the transition deadline
When a CS is repealed (because a harmonised standard now adequately covers the requirement), reassess whether to adopt the standard or use bespoke compliance
Maintain a version-controlled register of all applicable common specifications with OJ references, application dates, and compliance status

Art.37 in the Broader EU AI Act Compliance Architecture

Art.37 is the enforcement backstop for the standardisation-based compliance framework. Providers who understand the Art.37 mechanism can anticipate where mandatory technical requirements will emerge, prepare their compliance documentation infrastructure in advance, and avoid the disruption of being caught by a common specification with immediate application when they had assumed that harmonised standards would arrive first.

The practical lesson for EU AI Act compliance programme managers is threefold. First, do not assume that compliance documentation can be deferred until harmonised standards are published. The Art.37 common specification mechanism means that mandatory technical requirements can arrive through a different channel if standards are delayed. Second, monitor the Commission's standardisation gap assessments and implementing act proposals as closely as the CEN-CLC/JTC 21 work programme. Third, build compliance documentation that can be adapted to address either harmonised standards or common specifications, because the structure of the underlying Arts.8–15 requirements is the same regardless of which technical reference instrument is in force.

For providers deploying high-risk AI systems in sectors where CEN-CLC/JTC 21 standardisation is most delayed — particularly Annex III categories covering employment, essential services, and law enforcement AI — the Art.37 common specification pathway is not a theoretical contingency. It is the most likely source of binding technical requirements in 2026 and 2027, and preparation now is more efficient than reactive compliance once implementing acts are published.