EU AI Act Art.82: Formal Non-Compliance — MSA Notification, Corrective Deadlines, and Developer Remediation Guide (2026)

EU AI Act Article 82 establishes the formal non-compliance enforcement track: the mechanism market surveillance authorities use when they find procedural or documentary deficiencies in a high-risk AI system's compliance record, independent of whether that system has caused harm, presented a demonstrated risk, or triggered any safety concern.

Art.82 is the administrative backbone of the EU AI Act's enforcement architecture. Where Art.79 responds to systems that present risk, and Art.81 responds to compliant systems that somehow still cause harm, Art.82 responds to a third category: systems that may work perfectly well but whose compliance documentation, marking, registration, or representation obligations are incomplete, missing, or incorrect. These are the kinds of deficiencies an audit reveals — not necessarily what accident reports flag.

For developers, Art.82 defines the remediation window: the period between an MSA finding a formal deficiency and escalating to market restrictions. Understanding that window — and how to close the gap before MSA escalates under Art.82(3) — is the practical core of formal non-compliance management.

Art.82 became applicable on 2 August 2026 as part of the Chapter VIII market surveillance enforcement framework.

Art.82 in the Chapter VIII Enforcement Architecture

Art.82 occupies a specific position in the Chapter VIII enforcement sequence. Understanding where it sits clarifies when it applies and how it interacts with the adjacent enforcement articles:

The three-track enforcement decision tree for high-risk AI systems:

The critical implication: Art.82 requires no harm, no accident, no user complaint. A routine MSA audit that finds a missing EU Declaration of Conformity, an incorrect notified body identification number, or a registration gap in the EU AI Act database triggers Art.82 directly.

Art.82(1): The Nine Formal Non-Compliance Triggers

Art.82(1) specifies the grounds on which an MSA can initiate the formal non-compliance procedure. These are documentary, administrative, and procedural gaps — not substantive safety failures. The MSA does not need to demonstrate that the system caused harm to invoke Art.82(1).

Trigger 1 — CE Marking Applied Without Meeting Requirements

The CE marking has been affixed to the AI system or its documentation, but the provider did not correctly complete the conformity assessment procedure required under Art.43. The marking is present but unauthorised — the conformity process had gaps, used an incorrect conformity assessment route, or involved a notified body where third-party assessment was not required (or vice versa).

Developer risk: CE marking affixed to a system that should have undergone third-party conformity assessment under Art.43(1) but instead followed a provider self-assessment path. Also applies where CE marking was applied before technical documentation was complete.

Trigger 2 — CE Marking Not Applied

For high-risk AI systems in Annex III categories where CE marking is required, the marking is absent. The system has been placed on the market or put into service without the CE marking that Union harmonisation legislation requires.

Developer risk: Highest exposure for providers who deploy iteratively — each version placed on the market requires its own conformity assessment and CE marking; a deployment pipeline that bypasses marking creates per-deployment Art.82(2) exposure.

Trigger 3 — EU Declaration of Conformity (DoC) Not Drawn Up

No EU Declaration of Conformity exists for the system. The DoC under Art.47 and Annex V is a mandatory document that must be drawn up before the system is placed on the market or put into service. It must contain all minimum elements listed in Annex V.

Developer risk: Early-stage deployment without documentation completion. Also affects providers who maintain DoC templates but fail to issue system-specific DoC documents for each product line and version covered.

Trigger 4 — EU Declaration of Conformity Incorrectly Drawn Up

A DoC exists but does not comply with Art.47. Common failures: missing required Annex V elements, incorrect references to harmonised standards or common specifications, wrong system identification, outdated AI Board or Commission contact information, or incorrect scope statement.

Developer risk: Template reuse across product lines without customisation. DoC drawn up before standards were finalised and not updated after harmonised standard publication.

Trigger 5 — Notified Body Identification Number Missing or Incorrect

Where third-party conformity assessment was required (Art.43(1)) and a notified body was involved, the notified body's identification number must appear on or accompany the CE marking. The number is absent, incorrect, or refers to a body not listed in NANDO (EU Notification and Designation Online) for the relevant module.

Developer risk: Affects high-risk AI systems in Annex III categories where notified body involvement is mandatory. Also affects systems that changed notified body after initial certification without updating markings.

Trigger 6 — Technical Documentation Not Available or Not Complete

Technical documentation required under Art.11 and Annex IV is either entirely absent or materially incomplete. MSA access to technical documentation during Art.74 investigations is a primary audit trigger — a provider who cannot produce documentation on request faces immediate Art.82(1) exposure.

Developer risk: Version-specific documentation gaps are common. Documentation maintained for the initial deployment version but not updated after significant modifications under Art.83. Training data documentation absent or access-restricted. Annex IV section 2 (description of elements of the AI system and its development process) incomplete for transformer-based architectures.

Trigger 7 — Registration in EU AI Act Database Not Completed

The high-risk AI system has not been registered in the EU AI Act database managed by the Commission under Art.49 and Art.71. Registration is a pre-market obligation for Annex III category systems in scope.

Developer risk: Registration was completed for the initial system version but not updated after modifications that constitute new systems or significant changes. Systems placed on market before the registration database was operational and not retrospectively registered.

Trigger 8 — Authorised Representative Not Designated

Providers established outside the Union must designate an authorised representative in the Union under Art.22 before placing a high-risk AI system on the EU market. The authorised representative must hold a written mandate, be able to represent the provider to MSAs, and be registered as such in the EU AI Act database under Art.49(4).

Developer risk: Non-EU providers who sell directly to EU customers without EU legal entity or formal authorised representative designation. Also affects providers who had an authorised representative but the mandate expired or the representative withdrew without replacement.

Trigger 9 — Instructions for Use or Safety Information Absent

Instructions for use required under Art.13 — covering the intended purpose, performance metrics, human oversight measures, limitations, and maintenance instructions — are absent or materially incomplete. Art.13(3) specifies minimum elements; absence of any element creates Art.82(1)(i) exposure.

Developer risk: AI-as-a-service providers who deliver API access without product-level documentation. SaaS deployments where instructions are embedded in UX but not produced as a standalone document accessible to deployers. Instructions not translated into the language of the market where the system is deployed.

Art.82(1) Quick-Reference: Formal Non-Compliance Triggers

Art.82(2): MSA Notification and the Corrective Deadline

Once an MSA establishes a formal non-compliance finding under Art.82(1), it is required to notify the relevant economic operator — typically the provider, but also the importer or distributor in some cases — and set a reasonable period for correcting the non-compliance.

What "Reasonable Period" Means in Practice

The EU AI Act does not specify a fixed deadline for Art.82(2) corrective periods. The period is set by the MSA in light of the nature and severity of the deficiency. MSA practice across the EU is likely to mirror approaches established under other Union harmonisation legislation:

Key principle: The corrective period is not a grace period in which the MSA takes no further action. During the period, the MSA expects visible progress. Providers who do nothing during the corrective period risk the MSA shortening its timeline and escalating under Art.82(3) earlier.

Who the MSA Notifies

Art.82(2) refers to "the relevant economic operator." In the EU AI Act's supply chain model, this means:

• Provider (Art.3(3)): Primary target of Art.82 notification in most cases. Provider is responsible for conformity assessment, CE marking, DoC, technical documentation, and registration.
• Authorised representative (Art.22): If the provider is outside the Union, the authorised representative acts as the MSA's contact. Art.82(2) notification can be directed to the authorised representative, who must then ensure the provider remedies the non-compliance.
• Importer (Art.3(6)): Where the importer placed the system on the EU market and the provider cannot be reached, the MSA may engage the importer under Art.23 obligations.
• Distributor (Art.3(7)): If the distributor placed a system on the market despite knowing it was non-compliant, Art.82(2) notification can address distributor obligations under Art.24.

Art.82(3): Escalation When Non-Compliance Continues

If the formal non-compliance identified under Art.82(1) persists after the Art.82(2) corrective period expires, the MSA must take all appropriate provisional measures to restrict or prohibit the system's availability on the national market, withdraw it from the market, or require a recall.

Three Escalation Measures Under Art.82(3)

Market restriction or prohibition: The MSA issues a decision restricting continued sale, deployment, or use of the non-compliant system within its national territory. The restriction can be product-wide or limited to specific deployment contexts. For AI-as-a-service, this may translate to a prohibition on new customer onboarding in that Member State.

Market withdrawal: The MSA requires the economic operator to actively remove the non-compliant system from the market — stopping new sales and deployment, but not necessarily affecting existing installations. Withdrawal is less severe than recall and is appropriate where the non-compliance is formal rather than safety-critical.

Recall: The MSA requires return of the non-compliant system from end users. Recall is typically reserved for cases where the formal non-compliance compounds or accompanies a safety concern, or where continued use creates ongoing documentation liability for deployers.

Art.82(3) vs Art.79 escalation timing:

Art.82(4): Cross-Border Notification — Commission and Member State Coordination

When an MSA takes the escalation measures described in Art.82(3), it is required to notify the Commission and all other Member States without delay. The notification must include details of the non-compliance, the measures taken, and any information the economic operator has provided.

The Art.82(4) Notification Chain

The Art.82(4) notification mechanism serves two functions:

1. Commission oversight: The Commission monitors the pattern of Art.82(4) notifications to identify systemic non-compliance issues at the product category or provider level. A provider generating multiple Art.82 notifications across Member States creates an escalation risk: the Commission may use the pattern to initiate harmonised action under Art.80 or flag the provider to the AI Office.

2. Cross-border enforcement coordination: When one MSA notifies others under Art.82(4), each notified MSA can:

• Open its own Art.82 investigation into the same non-compliance in its territory
• Coordinate corrective deadlines so the provider faces a unified EU-wide timeline
• Request additional information under Art.75 (mutual assistance) to support their investigation

The RAPEX/ICSMS route: Art.82(4) notifications are processed through RAPEX (Rapid Alert System for non-food products) and ICSMS (Information and Communication System on Market Surveillance) — the same cross-border notification infrastructure used across Union harmonisation legislation. AI system Art.82 notifications appear in the same system as machinery, medical device, and toy safety alerts.

Provider Exposure After Art.82(4) Notification

Once Art.82(4) notification is filed, the provider faces:

• Potential parallel Art.82 investigations in up to 26 additional Member States
• Public RAPEX visibility in some categories — Art.82(4) notifications can become publicly accessible
• Commission monitoring flagging the provider for potential Art.60 EU AI Act database scrutiny
• Art.99 penalty exposure in each jurisdiction where Art.82(3) measures are taken

Art.82 vs Art.79 and Art.81: The Three-Track Enforcement Matrix

Understanding Art.82 requires understanding where it sits in relation to the two adjacent enforcement tracks:

The Art.79 + Art.82 parallel scenario: When an MSA investigates a high-risk AI system under Art.79 and finds both a safety risk AND formal non-compliance (missing technical documentation, absent CE marking), both procedures can run simultaneously. The Art.79 procedure addresses the risk; the Art.82 procedure addresses the documentation deficiency. The provider faces two separate corrective deadlines from the same MSA — and both can escalate independently.

CLOUD Act Risk at the Art.82 Technical Documentation Level

Technical documentation required under Art.11 and Annex IV is a primary Art.82(1)(f) trigger. For AI providers who store technical documentation on US-hosted infrastructure — AWS S3, Microsoft Azure blob storage, Google Cloud Storage, Atlassian Confluence hosted on US servers — the CLOUD Act creates a structural risk that compounds Art.82 exposure:

The CLOUD Act risk creates a secondary Art.82 pathway: documentation that is technically available under normal conditions becomes inaccessible or legally compromised when a US government compelled access request intersects with an EU MSA's Art.74 documentation access right. Under an EU-based infrastructure model, the documentation access chain is entirely within EU jurisdiction — no dual compellability conflict arises.

Python Implementation: FormalNonComplianceTracker

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

class Art82Trigger(Enum):
    CE_MARKING_WITHOUT_REQUIREMENTS = "a"  # Art.82(1)(a)
    CE_MARKING_ABSENT = "b"               # Art.82(1)(b)
    DOC_NOT_DRAWN_UP = "c"               # Art.82(1)(c)
    DOC_INCORRECTLY_DRAWN_UP = "d"       # Art.82(1)(d)
    NOTIFIED_BODY_NUMBER_MISSING = "e"   # Art.82(1)(e)
    TECHNICAL_DOCUMENTATION_GAP = "f"    # Art.82(1)(f)
    REGISTRATION_ABSENT = "g"            # Art.82(1)(g)
    AUTHORISED_REP_MISSING = "h"         # Art.82(1)(h)
    INSTRUCTIONS_FOR_USE_ABSENT = "i"    # Art.82(1)(i)

class Art82Status(Enum):
    FINDING_CONFIRMED = "finding_confirmed"      # Art.82(1) finding made
    NOTIFICATION_SENT = "notification_sent"      # Art.82(2) provider notified
    REMEDIATION_IN_PROGRESS = "in_progress"      # Corrective period active
    REMEDIATION_COMPLETE = "complete"            # Non-compliance resolved
    ESCALATED_MEASURES = "escalated"             # Art.82(3) measures taken
    CROSS_BORDER_NOTIFIED = "cross_border"       # Art.82(4) notification filed

@dataclass
class Art82Finding:
    system_id: str
    trigger: Art82Trigger
    msa_member_state: str
    finding_date: date
    corrective_deadline: date
    status: Art82Status = Art82Status.FINDING_CONFIRMED
    remediation_actions: list[str] = field(default_factory=list)
    escalation_date: Optional[date] = None
    cross_border_notification_date: Optional[date] = None

    @property
    def days_to_deadline(self) -> int:
        return (self.corrective_deadline - date.today()).days

    @property
    def is_overdue(self) -> bool:
        return date.today() > self.corrective_deadline and \
               self.status not in (Art82Status.REMEDIATION_COMPLETE,)

    @property
    def art99_exposure_risk(self) -> str:
        if self.status == Art82Status.ESCALATED_MEASURES:
            return "HIGH: Art.82(3) measures active — Art.99 penalty process may begin"
        if self.is_overdue:
            return "ELEVATED: Corrective deadline passed — escalation imminent"
        if self.days_to_deadline <= 7:
            return "MODERATE: <7 days to deadline — urgent remediation required"
        return "LOW: Within corrective period"

@dataclass
class FormalNonComplianceTracker:
    provider_name: str
    findings: list[Art82Finding] = field(default_factory=list)

    def add_finding(
        self,
        system_id: str,
        trigger: Art82Trigger,
        msa_member_state: str,
        finding_date: date,
        corrective_period_days: int
    ) -> Art82Finding:
        finding = Art82Finding(
            system_id=system_id,
            trigger=trigger,
            msa_member_state=msa_member_state,
            finding_date=finding_date,
            corrective_deadline=finding_date + timedelta(days=corrective_period_days),
        )
        self.findings.append(finding)
        return finding

    def escalate(self, finding: Art82Finding) -> None:
        finding.status = Art82Status.ESCALATED_MEASURES
        finding.escalation_date = date.today()

    def notify_cross_border(self, finding: Art82Finding) -> None:
        finding.status = Art82Status.CROSS_BORDER_NOTIFIED
        finding.cross_border_notification_date = date.today()

    def compliance_summary(self) -> dict:
        open_findings = [f for f in self.findings
                        if f.status != Art82Status.REMEDIATION_COMPLETE]
        overdue = [f for f in open_findings if f.is_overdue]
        escalated = [f for f in self.findings
                    if f.status in (Art82Status.ESCALATED_MEASURES,
                                   Art82Status.CROSS_BORDER_NOTIFIED)]
        return {
            "provider": self.provider_name,
            "total_findings": len(self.findings),
            "open_findings": len(open_findings),
            "overdue": len(overdue),
            "escalated_art82_3": len(escalated),
            "cross_border_notifications": sum(
                1 for f in self.findings
                if f.status == Art82Status.CROSS_BORDER_NOTIFIED
            ),
            "art99_exposure": [
                {"system": f.system_id, "trigger": f.trigger.name,
                 "msa": f.msa_member_state, "risk": f.art99_exposure_risk}
                for f in self.findings if f.art99_exposure_risk != "LOW: Within corrective period"
            ]
        }

Art.82 Developer Preparedness Checklist

1. CE Marking audit across all deployed versions Map every version of each high-risk AI system currently on the EU market. Verify that CE marking is applied to each version, that the marking is correct (format, accompanying documentation), and that the conformity assessment pathway matches the Annex III category. Flag any version where marking status is unclear.

2. EU Declaration of Conformity inventory Maintain a DoC register with one entry per system version placed on the market. Each entry should confirm: DoC drawn up (Art.47), minimum Annex V elements present, correct harmonised standard or common specification references, system-specific identification (not a generic template). Review the register quarterly.

3. Technical documentation versioning policy Establish a policy for when a system modification triggers a new Annex IV documentation cycle. Significant modifications under Art.83 require updated technical documentation — not just amended notes. Ensure documentation for each deployed version is stored in an accessible, audit-ready format under EU jurisdiction.

4. EU AI Act database registration check Confirm that every high-risk AI system in scope under Art.49 is registered in the EU AI Act database before or at market placement. Set a process alert for new system versions and modifications that require updated registration entries.

5. Authorised representative mandate verification (non-EU providers) If the provider is established outside the Union, confirm that the authorised representative designation under Art.22 is current: written mandate exists, mandate is not expired, representative is registered in the EU AI Act database under Art.49(4), and representative has been briefed on the Art.82 notification procedure they may receive.

6. Notified body identification number audit For systems requiring third-party conformity assessment under Art.43(1), verify that the notified body's identification number is correctly applied. Check the NANDO database to confirm the notified body remains designated for the relevant category. Flag any marking that references a withdrawn or expired notification.

7. Instructions for use completeness review Review all system-level instructions for use against Art.13(3) minimum elements. Confirm: intended purpose statement, performance metrics and limitations, human oversight measures for Art.14, maintenance and update guidance, deployer information requirements under Art.26. Ensure instructions are available in the official language(s) of each Member State where the system is deployed.

8. Art.82(2) response protocol Define and document the internal process that activates when an MSA Art.82(2) notification arrives: who receives it, who is responsible for remediation, what escalation path exists if the corrective period is too short, and how the response is documented for Art.82(4) cross-border notification management.

9. CLOUD Act technical documentation risk assessment Audit the infrastructure hosting technical documentation, training data records, and conformity documentation. For each documentation category, assess whether storage on US-hosted infrastructure creates a dual compellability risk. Prioritise migration to EU-jurisdiction hosting for Annex IV documentation accessed under Art.74 investigation powers.

10. Cross-border monitoring for parallel Art.82 investigations After any Art.82(2) notification, monitor the EU AI Act database and MSA communications for signs that Art.82(4) notification has been filed. A notification filed by one MSA may trigger parallel investigations in other Member States — the provider should proactively address the non-compliance EU-wide, not only in the notifying state.

Chapter VIII Series Navigation

This post is part of the EU AI Act Chapter VIII enforcement series covering the full market surveillance framework:

Conclusion

Art.82 defines the enforcement consequence of incomplete compliance documentation — not safety failure, but administrative non-conformity. For developers, the key insight is that Art.82 can be triggered entirely by audit, without any user complaint, incident report, or operational failure. The nine triggers in Art.82(1) are documentary: marking, declarations, documentation, registration, representation, instructions.

The corrective period under Art.82(2) is the critical window. Providers who respond immediately, document their remediation steps, and resolve deficiencies before the deadline avoid Art.82(3) escalation. Providers who ignore the notification — or treat it as a bureaucratic formality — face market restrictions, withdrawal, recall, and Art.82(4) cross-border notification that can cascade across all 27 Member States.

The practical takeaway: formal compliance documentation is not a one-time deliverable at product launch. It is a maintenance obligation across every version, every deployment, and every market where the system operates. Art.82 is what happens when that maintenance obligation fails an audit.