sota.io
2026-04-23·14 min read·

EU AI Act Art.36: Harmonised Standards and Presumption of Conformity for High-Risk AI Systems — CEN/CENELEC Standardisation Process, Official Journal Publication, and Compliance Strategy (2026)

Article 36 of the EU AI Act addresses a foundational mechanism of EU product regulation that predates the AI Act by decades but that the AI Act applies to its distinctive subject matter for the first time: the harmonised standards framework. Under this framework, European standardisation bodies develop technical standards at the Commission's request, those standards are published as harmonised standards in the Official Journal of the European Union, and AI system providers that comply with those standards can rely on a presumption that they also comply with the corresponding requirements of the AI Act. The mechanism translates abstract statutory requirements into concrete, auditable technical specifications that providers, notified bodies, and market surveillance authorities can use as a common reference.

Understanding Art.36 is essential for any provider that wants to demonstrate compliance with the high-risk AI requirements of Arts.8–15 without having to construct a bespoke compliance argument from first principles. It is equally important for providers who are building compliance documentation now, before all relevant harmonised standards have been developed and published, because the absence of harmonised standards does not suspend a provider's obligations — it simply means that providers must find other ways to demonstrate compliance while the standardisation process completes.

Art.36's Position in the Section 5 Conformity Architecture

Art.36 appears in Chapter III, Section 5 of the EU AI Act, immediately after Art.35 (conformity assessment procedures) and immediately before Art.37 (common specifications). This positioning is structurally deliberate: Art.35 establishes which conformity assessment procedure applies; Art.36 provides the primary compliance demonstration pathway (harmonised standards); and Art.37 provides the fallback pathway (common specifications) when harmonised standards are absent or inadequate.

The Section 5 architecture creates a hierarchical compliance demonstration system:

Providers are free to use any of these three pathways, individually or in combination. Using harmonised standards where they exist is generally the most efficient approach, because it aligns the provider's documentation with the reference framework that notified bodies and market surveillance authorities use for assessment.

The Standardisation Request Mechanism Under Reg. (EU) No 1025/2012

The process for creating harmonised standards under the EU AI Act follows the standardisation framework established by Regulation (EU) No 1025/2012 on European standardisation. Under this framework, the Commission issues standardisation requests (formerly called "mandates") to the European Standards Organisations (ESOs) — primarily CEN (Comité Européen de Normalisation), CENELEC (Comité Européen de Normalisation Électrotechnique), and ETSI (European Telecommunications Standards Institute). The ESO accepts the request, assigns it to a technical committee, and manages the drafting process that ultimately produces a European Standard (EN) or, in some cases, a Technical Specification (CEN/TS).

For the EU AI Act, the Commission has issued standardisation requests to CEN and CENELEC through CEN-CLC/JTC 21 (the Joint Technical Committee for Artificial Intelligence), which was established specifically to develop standardisation deliverables in support of the EU AI Act. CEN-CLC/JTC 21 works in close coordination with ISO/IEC JTC 1/SC 42 (the international AI standardisation committee) to align European standards with international standards wherever possible, reducing compliance burdens for providers operating in both EU and international markets.

The standardisation request specifies:

Once CEN-CLC/JTC 21 drafts a standard and it passes the formal approval process (including national ballot, resolution of comments, and final approval), the Commission reviews whether the standard satisfies the standardisation request. If it does, the Commission publishes a reference to the standard in the Official Journal. Publication in the Official Journal is the step that activates the Art.36 presumption of conformity — a standard that has not been published in the Official Journal does not create an Art.36 presumption, even if it has been formally adopted by CEN or CENELEC.

What Presumption of Conformity Means Under Art.36

The presumption of conformity is a rebuttable legal presumption: a provider who can demonstrate that their high-risk AI system complies with a harmonised standard whose reference has been published in the Official Journal is presumed to comply with the EU AI Act requirements corresponding to the scope of that standard. This presumption shifts the burden of proof in market surveillance proceedings — the market surveillance authority must affirmatively demonstrate non-compliance rather than the provider having to prove compliance from scratch.

Scope of the presumption: The presumption applies only to the EU AI Act requirements that the harmonised standard explicitly covers. If a harmonised standard addresses accuracy and robustness requirements under Art.15 but does not address the human oversight measures required by Art.14, using that standard creates a presumption of conformity with Art.15 but not with Art.14. Providers must separately demonstrate compliance with requirements not covered by available harmonised standards.

Rebuttability: The presumption can be rebutted by national competent authorities conducting market surveillance if they produce evidence that the system does not in fact comply with the requirements, notwithstanding compliance with the harmonised standard. This means that standard compliance is a strong evidentiary foundation, not an absolute defence. A provider who has implemented a harmonised standard in a defective manner, or whose system has characteristics that the standard did not anticipate, cannot rely on standard compliance alone to avoid enforcement.

Partial standards: Harmonised standards can cover a subset of a requirement rather than the entire requirement. When a standard covers Art.13 transparency requirements only in part — for example, covering the obligation to inform operators but not the specific technical formats for instructions for use — providers benefit from the presumption only for the portion covered. They must separately address the uncovered portion.

Versions and amendments: The presumption attaches to the specific version of the standard referenced in the Official Journal. When a standard is amended and the updated version is published in the Official Journal, providers should consider whether to update their compliance framework to align with the new version, particularly if the amendment was issued to address compliance weaknesses or new risk patterns.

The Art.36 × Art.37 Interaction: Standards vs. Common Specifications

Art.37 gives the Commission authority to issue common specifications — implementing acts that establish technical requirements directly — in two situations: (1) when no harmonised standards have been published for a specific requirement, or (2) when published harmonised standards are considered insufficient to ensure compliance with the relevant AI Act requirements.

The relationship between Art.36 and Art.37 creates a tension that providers must understand:

Standards are voluntary; common specifications are mandatory when invoked. A provider can choose not to use a harmonised standard and instead demonstrate compliance by other means — the standard creates only a presumption, not a mandatory pathway. Common specifications issued under Art.37, by contrast, are mandatory for providers who cannot demonstrate compliance with the underlying requirements through other means. When the Commission determines that a common specification is necessary, providers in the affected area cannot simply ignore it.

The Commission can object to a standard it considers inadequate. Under the formal objection procedure established by Reg. (EU) No 1025/2012, the Commission can object to a harmonised standard if it is satisfied that the standard does not fully meet the requirements it is supposed to cover or does not satisfy the standardisation request. When a formal objection is raised, the reference to the standard is not published in the Official Journal (or is withdrawn if already published), and the standard does not create an Art.36 presumption. This is a relevant risk for providers who are tracking draft standards in anticipation of publication: a draft standard can be objected to before publication.

Standards withdrawal: The Commission can also publish a warning notice for a published harmonised standard if it no longer adequately covers the requirements, creating uncertainty for providers who have built their compliance case on that standard. Providers should monitor the Official Journal not only for new standard publications but also for warning notices affecting standards they rely on.

CEN-CLC/JTC 21 and the AI Act Standardisation Pipeline

CEN-CLC/JTC 21 is structured around working groups that address specific areas of the EU AI Act. The committee's work programme in 2025–2026 includes deliverables covering:

The committee coordinates extensively with ISO/IEC JTC 1/SC 42, whose standards — particularly ISO/IEC 42001 (AI management systems), ISO/IEC 42005 (AI risk management), and ISO/IEC 5338 (AI lifecycle) — are expected to form the technical foundation for many of the harmonised standards that CEN-CLC/JTC 21 will submit for Official Journal publication. Providers that have already implemented ISO/IEC 42001 or ISO/IEC 42005 may find that their existing documentation substantially overlaps with the harmonised standards once published.

The timeline for harmonised standard publication under the EU AI Act is subject to the standard development process, which typically takes 2–4 years from standardisation request to Official Journal publication. This means that a significant portion of the period between the EU AI Act's application date for high-risk systems (2026-08-02 for new Annex III systems, 2027-08-02 for Annex I systems under existing legislation) and the availability of comprehensive harmonised standards will require providers to operate on bespoke compliance documentation without the benefit of Art.36 presumptions.

Compliance Strategy Before Harmonised Standards Are Published

The absence of published harmonised standards does not exempt providers from the Arts.8–15 requirements. It means that providers cannot rely on the Art.36 presumption mechanism and must instead build their compliance case directly from the statutory requirements and any available technical guidance. Several approaches exist for this interim period:

Reference ISO/IEC standards: ISO/IEC 42001, 42005, and 5338 are not EU harmonised standards and do not create an Art.36 presumption. However, they represent the current international state of practice in AI risk management and governance, and compliance documentation built around these standards is likely to align closely with the harmonised standards that CEN-CLC/JTC 21 will eventually publish. Providers that implement these standards now will be well-positioned to demonstrate compliance with both the statutory requirements and, once available, the harmonised standards.

Track CEN-CLC/JTC 21 draft standards: CEN-CLC/JTC 21 publishes its work programme and makes draft standards available for public comment during the formal enquiry phase. Monitoring these drafts allows providers to align their compliance documentation with the likely content of future harmonised standards, reducing the rework required when final standards are published.

Use Commission guidance documents: The Commission and the EU AI Office have published, or are in the process of publishing, guidance documents on the interpretation of specific AI Act requirements. While guidance documents do not create legal presumptions, they represent the Commission's interpretive position and can serve as a reference for compliance documentation.

Document the compliance reasoning explicitly: Without harmonised standards, the provider's technical documentation must contain explicit, traceable reasoning explaining how each Art.8–15 requirement is satisfied. This requires more detailed documentation than a statement of standard compliance would, but it is legally sufficient and has the advantage of being tailored to the specific system rather than relying on a generic framework.

The Formal Objection Procedure

Under Art.11 of Reg. (EU) No 1025/2012 (as applied to the EU AI Act context), the Commission can raise a formal objection to a harmonised standard by publishing a notice in the Official Journal explaining its grounds for objection. The grounds must relate to the standard's failure to adequately cover the EU AI Act requirements it was intended to address.

When a formal objection is raised before a standard's reference is published in the Official Journal, the standard does not enter the harmonised standards regime and creates no Art.36 presumption. When a formal objection is raised after publication, the Commission may simultaneously remove the standard's reference from the Official Journal or publish a warning notice restricting the standard's scope.

For providers, the formal objection procedure creates a monitoring obligation: standard compliance documentation should reference the specific version of the standard with the specific Official Journal reference, and providers should maintain a watch for Commission notices affecting that reference. A provider who is unaware that the Commission has raised a formal objection to a standard they rely on may be in a situation where they believe they benefit from an Art.36 presumption that no longer exists.

Python Implementation: HarmonisedStandardsComplianceTracker

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

class StandardStatus(Enum):
    DRAFT_IN_DEVELOPMENT = "draft_in_development"
    NATIONAL_BALLOT = "national_ballot"
    PUBLISHED_EN = "published_en"
    OJ_REFERENCED = "oj_referenced"
    OJ_OBJECTION_RAISED = "oj_objection_raised"
    OJ_WARNING_NOTICE = "oj_warning_notice"
    WITHDRAWN = "withdrawn"

class CoverageLevel(Enum):
    FULL = "full_coverage"
    PARTIAL = "partial_coverage"
    NONE = "no_coverage"

@dataclass
class HarmonisedStandard:
    reference: str
    title: str
    covers_requirements: list[str]
    status: StandardStatus
    oj_reference: Optional[str] = None
    oj_publication_date: Optional[str] = None
    warning_notice: Optional[str] = None
    version: str = "1.0"

@dataclass
class RequirementCoverageAssessment:
    requirement: str
    article: str
    covered_by_standards: list[str]
    coverage_level: CoverageLevel
    gap_description: Optional[str] = None
    alternative_demonstration_approach: Optional[str] = None

@dataclass
class ComplianceFrameworkStatus:
    system_name: str
    assessment_date: str
    requirement_assessments: list[RequirementCoverageAssessment]
    standards_relied_upon: list[str]
    uncovered_requirements: list[str]
    interim_compliance_approach: list[str]

class HarmonisedStandardsComplianceTracker:
    """
    EU AI Act Art.36 harmonised standards compliance tracking.

    Tracks which harmonised standards have been published in the Official
    Journal, what requirements they cover, and identifies gaps requiring
    alternative compliance demonstration under Arts.8-15.
    """

    # Mapping of AI Act Arts.8-15 requirements to coverage tracking
    HIGH_RISK_REQUIREMENTS = {
        "art_8_general": "Art.8 — Compliance with requirements for high-risk AI systems",
        "art_9_risk_management": "Art.9 — Risk management system",
        "art_10_data_governance": "Art.10 — Data and data governance",
        "art_11_technical_documentation": "Art.11 — Technical documentation",
        "art_12_record_keeping": "Art.12 — Record-keeping and logging",
        "art_13_transparency": "Art.13 — Transparency and provision of information",
        "art_14_human_oversight": "Art.14 — Human oversight",
        "art_15_accuracy_robustness": "Art.15 — Accuracy, robustness and cybersecurity",
    }

    def __init__(self):
        self._standards: dict[str, HarmonisedStandard] = {}
        self._load_known_standards()

    def _load_known_standards(self) -> None:
        # ISO/IEC 42001 — expected to form basis of QMS and risk management standards
        self._standards["ISO_IEC_42001_2023"] = HarmonisedStandard(
            reference="ISO/IEC 42001:2023",
            title="Artificial intelligence — Management systems",
            covers_requirements=["art_9_risk_management", "art_17_qms"],
            status=StandardStatus.PUBLISHED_EN,
            oj_reference=None,  # Not yet referenced in OJ as harmonised standard
        )
        # ISO/IEC 42005 — AI risk management
        self._standards["ISO_IEC_42005"] = HarmonisedStandard(
            reference="ISO/IEC 42005",
            title="Artificial intelligence — AI system impact assessment",
            covers_requirements=["art_9_risk_management"],
            status=StandardStatus.DRAFT_IN_DEVELOPMENT,
            oj_reference=None,
        )
        # CEN-CLC/JTC 21 work programme deliverables (draft status as of 2026)
        self._standards["CEN_JTC21_TS1"] = HarmonisedStandard(
            reference="CEN/CLC/JTC 21 — WG 1 Draft",
            title="AI Risk Management — Technical Specification for EU AI Act Art.9",
            covers_requirements=["art_9_risk_management"],
            status=StandardStatus.DRAFT_IN_DEVELOPMENT,
            oj_reference=None,
        )

    def register_standard(self, standard: HarmonisedStandard) -> None:
        self._standards[standard.reference] = standard

    def get_oj_active_standards(self) -> list[HarmonisedStandard]:
        return [
            s for s in self._standards.values()
            if s.status == StandardStatus.OJ_REFERENCED
            and s.warning_notice is None
        ]

    def assess_requirement_coverage(
        self, requirement_key: str
    ) -> RequirementCoverageAssessment:
        if requirement_key not in self.HIGH_RISK_REQUIREMENTS:
            raise ValueError(
                f"Unknown requirement key: {requirement_key}. "
                f"Valid keys: {list(self.HIGH_RISK_REQUIREMENTS.keys())}"
            )

        covering_standards = [
            s.reference
            for s in self.get_oj_active_standards()
            if requirement_key in s.covers_requirements
        ]

        if len(covering_standards) == 0:
            return RequirementCoverageAssessment(
                requirement=self.HIGH_RISK_REQUIREMENTS[requirement_key],
                article=requirement_key,
                covered_by_standards=[],
                coverage_level=CoverageLevel.NONE,
                gap_description=(
                    "No harmonised standard with OJ reference currently covers "
                    "this requirement. Provider must demonstrate compliance directly "
                    "from statutory text and available guidance documents."
                ),
                alternative_demonstration_approach=(
                    "Document compliance with requirement directly in technical "
                    "documentation. Consider referencing ISO/IEC standards as "
                    "technical baseline while OJ publication is pending."
                ),
            )

        return RequirementCoverageAssessment(
            requirement=self.HIGH_RISK_REQUIREMENTS[requirement_key],
            article=requirement_key,
            covered_by_standards=covering_standards,
            coverage_level=CoverageLevel.FULL,
            gap_description=None,
            alternative_demonstration_approach=None,
        )

    def generate_compliance_framework_status(
        self, system_name: str
    ) -> ComplianceFrameworkStatus:
        assessments = [
            self.assess_requirement_coverage(req)
            for req in self.HIGH_RISK_REQUIREMENTS
        ]

        oj_standards = [s.reference for s in self.get_oj_active_standards()]
        uncovered = [
            a.requirement
            for a in assessments
            if a.coverage_level == CoverageLevel.NONE
        ]

        interim_approach = []
        if uncovered:
            interim_approach.extend([
                "Reference ISO/IEC 42001:2023 (AI management systems) as technical baseline",
                "Reference ISO/IEC 42005 (AI risk management) when published",
                "Monitor CEN-CLC/JTC 21 work programme for draft standard availability",
                "Build direct statutory compliance documentation for each uncovered requirement",
                "Track Official Journal for harmonised standard publication notices",
            ])

        return ComplianceFrameworkStatus(
            system_name=system_name,
            assessment_date=datetime.date.today().isoformat(),
            requirement_assessments=assessments,
            standards_relied_upon=oj_standards,
            uncovered_requirements=uncovered,
            interim_compliance_approach=interim_approach,
        )

    def check_for_objections_and_warnings(self) -> list[dict]:
        issues = []
        for ref, std in self._standards.items():
            if std.status == StandardStatus.OJ_OBJECTION_RAISED:
                issues.append({
                    "standard": ref,
                    "issue": "formal_objection",
                    "message": (
                        f"Commission has raised a formal objection to {ref}. "
                        "Art.36 presumption no longer applies. "
                        "Switch to direct compliance demonstration immediately."
                    ),
                })
            elif std.warning_notice:
                issues.append({
                    "standard": ref,
                    "issue": "warning_notice",
                    "message": (
                        f"Commission has published a warning notice for {ref}: "
                        f"{std.warning_notice}. Review whether your compliance "
                        "documentation remains adequate."
                    ),
                })
        return issues


# Usage example
if __name__ == "__main__":
    tracker = HarmonisedStandardsComplianceTracker()
    status = tracker.generate_compliance_framework_status("HireScore AI v2.1")

    print(f"System: {status.system_name}")
    print(f"Assessment date: {status.assessment_date}")
    print(f"OJ-active standards relied upon: {status.standards_relied_upon or 'None'}")
    print(f"\nUncovered requirements ({len(status.uncovered_requirements)}):")
    for req in status.uncovered_requirements:
        print(f"  - {req}")

    print(f"\nInterim compliance approach:")
    for step in status.interim_compliance_approach:
        print(f"  {step}")

    objection_check = tracker.check_for_objections_and_warnings()
    if objection_check:
        print(f"\nWARNING — {len(objection_check)} standard issue(s) detected:")
        for issue in objection_check:
            print(f"  [{issue['issue'].upper()}] {issue['message']}")
    else:
        print("\nNo active standard objections or warning notices detected.")

Harmonised Standards Coverage Matrix for EU AI Act Arts.8–15

RequirementArticleCEN-CLC/JTC 21 StatusISO/IEC BaselineOJ Reference AvailableInterim Approach
General compliance gatewayArt.8Underpins all WGsISO/IEC 42001 scopeNoDirect statutory documentation
Risk management systemArt.9WG 1 — active draftISO/IEC 42005NoISO/IEC 42001 + direct documentation
Data governanceArt.10WG 2 — active draftISO/IEC 5338 partialNoDirect documentation + DG guidance
Technical documentationArt.11 + Annex IVWG 3 — active draftNo direct equivalentNoFollow Annex IV structure directly
Record-keeping and loggingArt.12WG 3 scopeISO/IEC 42001 partialNoDirect documentation
Transparency + info to operatorsArt.13WG 4 — active draftISO/IEC 42001 partialNoDirect documentation + AI Office guidance
Human oversightArt.14WG 5 — active draftNo direct equivalentNoDirect documentation
Accuracy, robustness, cybersecurityArt.15WG 6 — active draftISO/IEC 42001 + 27001NoISO/IEC 27001 (cybersecurity) + direct
Quality management systemArt.17WG 7 — active draftISO/IEC 42001NoISO/IEC 42001 as primary reference
Conformity assessment procedureArts.35 + 43WG 8 — active draftNo direct equivalentNoArt.43 procedural text directly

Status as of April 2026. CEN-CLC/JTC 21 work programme deliverables are subject to change. Official Journal references for AI Act harmonised standards have not yet been published as of this date.

Art.36 and the Relationship with General Product Safety Standards

For Annex I high-risk AI systems — AI components embedded in products regulated by existing EU product safety legislation — there is an additional layer of harmonised standards that may already be in place. Medical devices with AI components may already comply with EN ISO 13485 (quality management systems for medical devices) and the IEC 62304 family of software lifecycle standards. Machinery AI components may already comply with EN ISO 12100 (safety of machinery risk assessment and reduction).

These existing sectoral standards do not in themselves create an Art.36 presumption under the EU AI Act, because they were not developed under a standardisation request issued pursuant to the AI Act. However, they may provide partial coverage of AI Act requirements — particularly where the AI Act's technical requirements overlap with requirements in existing product safety legislation — and they can serve as part of a bespoke compliance documentation package for the requirements not yet covered by published AI Act harmonised standards.

For providers already subject to sectoral harmonised standards, the most efficient approach is to conduct a gap analysis comparing the existing standards documentation against the AI Act's Arts.8–15 requirements, identify the uncovered requirements, and supplement the existing documentation to address those gaps. This approach avoids duplicating documentation that already exists under sectoral frameworks and focuses effort on the genuinely novel requirements introduced by the AI Act.

Monitoring Official Journal Publications for New Harmonised Standard References

Providers cannot rely on a harmonised standard they have learned about from CEN/CENELEC publications or industry sources — only standards whose references have been published in the Official Journal of the EU create an Art.36 presumption. This requires an active monitoring obligation:

Official Journal monitoring: Subscribe to alerts from EUR-Lex (the EU's official legal database) for Commission Decisions, Commission Communications, and implementing acts that include references to harmonised standards under Regulation (EU) No 1025/2012. New harmonised standard references for the EU AI Act will be published in the L-series (legislation) or C-series (information and notices) of the Official Journal.

CEN/CENELEC work programme tracking: Follow the CEN-CLC/JTC 21 work programme through the CEN BOSS (CEN Online Standards Service) or the publicly available JTC 21 work programme reports. Draft standards in national ballot or final approval stages are likely candidates for Official Journal publication within 6–18 months.

EU AI Office guidance: The EU AI Office publishes guidance documents and technical specifications that may reference or anticipate harmonised standards under development. These documents, while not creating Art.36 presumptions, signal the Commission's interpretive direction.

Standard version control: When a harmonised standard is updated through amendment or revision, the Official Journal must publish a reference to the new version before the new version creates an Art.36 presumption for the amended requirements. Providers should maintain version-specific documentation tracking which version of each standard they rely upon and the corresponding Official Journal reference.

22-Item Provider Checklist for Art.36 Compliance Strategy

Phase 1: Inventory and gap assessment

  1. List all Arts.8–15 requirements applicable to the high-risk AI system being developed or placed on the market
  2. Search EUR-Lex and the Official Journal for any harmonised standard references published under the EU AI Act (Art.36)
  3. For each published harmonised standard, identify which specific AI Act requirements it covers and the scope of that coverage
  4. Conduct a coverage gap analysis: for each Art.8–15 requirement, map which portion (if any) is covered by OJ-referenced harmonised standards
  5. For requirements with no OJ-referenced standard coverage, document the gap and the alternative compliance demonstration approach
  6. For requirements with partial standard coverage, identify the specific uncovered elements and document how they will be addressed

Phase 2: Standards monitoring setup

  1. Set up EUR-Lex alerts for Official Journal publications referencing harmonised standards under Regulation (EU) No 1025/2012 in the AI Act context
  2. Register with CEN-BOSS or equivalent service to monitor CEN-CLC/JTC 21 work programme progress
  3. Subscribe to EU AI Office newsletter or document publication alerts
  4. Establish a quarterly review calendar to update the standard coverage matrix in the compliance documentation
  5. Document the monitoring process and the personnel responsible for it in the quality management system

Phase 3: Interim compliance documentation (pre-harmonised standards)

  1. For each uncovered requirement, prepare direct statutory compliance documentation tracing the requirement text through the system's design, testing, and operational documentation
  2. Reference ISO/IEC 42001:2023 as a technical baseline where applicable, noting that it does not create an Art.36 presumption but represents international best practice
  3. Reference other relevant ISO/IEC standards (42005, 5338, 27001) where coverage overlaps with AI Act requirements
  4. Prepare a technical note explaining the current state of harmonised standards development and the provider's interim compliance strategy for use in conformity assessment documentation

Phase 4: Transition to harmonised standards compliance

  1. When a harmonised standard covering a previously undocumented requirement is published in the Official Journal, conduct a compliance gap analysis comparing the system's existing documentation against the new standard
  2. Update the conformity assessment documentation to reference the harmonised standard's Official Journal reference and document the compliance evidence
  3. Notify the notified body (for Track A systems) of the updated compliance framework and provide updated documentation
  4. Check for any formal objection notices or warning notices affecting standards currently relied upon

Phase 5: Objection monitoring and contingency

  1. Monitor Official Journal for Commission notices objecting to or raising warning notices about harmonised standards in the AI compliance space
  2. If a relied-upon standard is subject to a formal objection or warning notice, immediately assess whether the Art.36 presumption for affected requirements remains valid
  3. If the presumption is lost due to objection or withdrawal, revert to direct statutory compliance documentation for the affected requirements while tracking the development of a replacement standard

See Also