EU AI Act Art.73: Obligations of Deployers of High-Risk AI Systems — Incident Reporting, Monitoring Cooperation, and MSA Compliance (2026)

EU AI Act Article 73 is the deployer-side complement to the provider's post-market monitoring obligations established by Art.72. While Art.72 imposes on providers the obligation to design and operate a post-market monitoring system, Art.73 specifies what deployers — the organisations and individuals who put high-risk AI systems into actual operational use — must do to support that monitoring system, to report serious incidents, and to cooperate with market surveillance authority investigations.

For developers and compliance teams, Art.73 has direct operational consequences. The deployer is typically closer to the AI system's real-world consequences than the provider: the deployer sees the actual outputs, actual user populations, and actual operational failures before the provider does. Art.73 formalises this proximity by imposing a first-responder role on deployers in the incident detection and reporting chain. A deployer who fails to report a serious incident to the provider — or who fails to cooperate with an MSA investigation — faces the same penalty exposure as a provider who fails to file a conformity assessment.

The Commission's interpretation of Art.73 positions deployers as active participants in the post-market monitoring ecosystem rather than passive recipients of AI services. The quality of the provider's post-market monitoring under Art.72 depends substantially on the quality of the deployer's incident reporting under Art.73. The two obligations are architecturally linked.

Art.73 in the Post-Deployment Obligations Architecture

Art.73 sits within Chapter VIII of the AI Act alongside post-market monitoring (Art.72) and market surveillance provisions (Art.74). The deployer obligations in Art.73 serve as the information supply chain for the provider's monitoring system:

Art.73(1): The Deployer Monitoring Cooperation Obligation

Art.73(1) establishes the foundational deployer obligation: deployers of high-risk AI systems shall implement the post-market monitoring instructions provided by the provider under Art.72, and shall cooperate with the provider's post-market monitoring system throughout the operational lifetime of the system.

Scope of the obligation. Art.73(1) applies to any natural or legal person who deploys a high-risk AI system in a professional context, including deployers operating under their own brand under Art.26(2). The obligation applies from the moment of deployment through to decommissioning.

What "implementing monitoring instructions" means in practice. The provider's post-market monitoring plan under Art.72 will typically specify:

• What performance metrics the deployer must collect and report (accuracy rates, error frequencies, user correction rates)
• What incident thresholds trigger notification to the provider (severity bands, categories of harm)
• The format and channel for deployer incident reports
• The frequency of routine monitoring data transmission (weekly, monthly, event-triggered)
• Record retention requirements for deployer-side monitoring logs

The deployer must build operational capacity to fulfil these requirements, including designating a responsible individual for monitoring coordination and establishing internal escalation procedures.

Contractual implementation. Art.73(1) creates a legal obligation that should be reflected in the deployment contract between provider and deployer. Providers routinely include Art.73-aligned monitoring obligations in deployment terms. Deployers who fail to include Art.73 compliance requirements in their operational procedures cannot rely on provider instructions as a shield: the regulatory obligation is imposed directly on the deployer.

SME considerations. For SME deployers, the proportionality principle permits a lighter-weight monitoring implementation, but the obligation to report serious incidents to the provider (Art.73(2)) is not proportionality-qualified. Every deployer, regardless of size, must maintain the capacity to report serious incidents.

Art.73(2): Deployer Serious Incident Notification to Provider

Art.73(2) specifies the deployer's duty to notify the provider when it becomes aware of a serious incident involving the high-risk AI system. This is the primary mechanism by which providers receive incident data from their deployment network.

Triggering condition: awareness of a serious incident. Art.73(2) uses the same trigger as Art.65 for provider MSA reporting: the deployer's clock starts when the deployer becomes aware (or should reasonably have become aware) of a serious incident as defined by Art.3(49). The serious incident definition covers:

• Death or serious risk to the health or safety of persons
• Serious and irreversible disruption to critical infrastructure (where the deployed system is in a critical infrastructure context)
• Infringement of obligations under Union law protecting fundamental rights
• Serious damage to property or the environment beyond a significance threshold

Notification timeline. Art.73(2) requires notification to the provider without undue delay. Unlike the specific timelines in Art.65 (15 days for provider-to-MSA reporting), Art.73(2) uses the functional "without undue delay" standard, which requires notification as soon as practically possible given the circumstances. For life-safety incidents, same-day notification is the expected standard. For other serious incidents, notification within 24 to 72 hours reflects the general regulatory interpretation.

Near-miss notification. While Art.73(2) technically applies only to serious incidents as defined by Art.3(49), the provider's monitoring plan will typically extend the notification requirement to near-miss events — incidents that fell below the Art.3(49) threshold but demonstrated system behaviour inconsistent with the intended use or the risk assessment. Deployers should review provider monitoring instructions for near-miss reporting requirements, which are contractual obligations rather than directly statutory.

Content of deployer notification. The notification to the provider should include:

1. Date, time, and location of the incident
2. Description of the AI system output or behaviour that caused or contributed to the incident
3. Description of the harm or near-miss that resulted
4. User population characteristics relevant to the incident (without unnecessary personal data)
5. Operational context (inputs, environmental conditions, any unusual factors)
6. Human override status — whether human oversight was in place and whether it was exercised
7. Any immediate corrective action taken by the deployer

Provider's downstream obligation. Once notified by the deployer, the provider must evaluate the incident against the serious incident threshold and, if confirmed, report to the relevant MSA under Art.65 within the Art.65 timelines. The provider's Art.65 clock does not start from the deployer's notification — it starts from the moment the provider has established the causal link or reasonable likelihood of such link.

Art.73(3): Deployer Direct MSA Reporting — When Providers Are Unreachable

Art.73(3) addresses a critical gap in the deployer-to-provider notification chain: what happens when the provider is unreachable, unresponsive, or has ceased to exist. In these situations, Art.73(3) permits — and in some cases requires — the deployer to notify the MSA directly.

Triggering conditions for direct MSA reporting. Direct MSA reporting by the deployer is appropriate when:

• The provider cannot be identified (e.g., the provider is a non-EU entity with no EU representative and no known contact channel)
• The provider has not responded to a serious incident notification within a reasonable period given the incident's severity
• The provider has ceased operations or entered insolvency proceedings
• The deployer has reasonable grounds to believe the provider intends to conceal or minimise the incident

Procedure for direct MSA reporting. When the deployer files directly with the MSA, the deployer should document the attempts to notify the provider and the reasons for escalating to direct MSA reporting. The MSA will then act under Art.74 to investigate and may require the provider to file the corresponding report.

Practical implication for deployers. Art.73(3) means deployers cannot use provider unresponsiveness as a shield against MSA investigation. If a deployer becomes aware of a serious incident and does not notify the provider in a timely manner, and does not notify the MSA directly when the provider is unreachable, the deployer faces direct regulatory exposure under Art.99 penalty provisions.

Art.73(4): Deployer Cooperation with Market Surveillance Authority Investigations

Art.73(4) establishes the deployer's duty to cooperate fully with MSA investigations triggered by serious incident reports or market surveillance activities under Art.74.

Scope of cooperation. Art.73(4) requires deployers to:

• Provide MSA investigators with access to the deployed AI system and its operational environment on request
• Make available all incident logs, monitoring data, and output records maintained under Art.73(1) instructions
• Provide access to the deployer's personnel responsible for AI system operation and oversight
• Respond to written information requests from the MSA within the timelines specified by the MSA
• Preserve evidence — incident logs, system outputs, configuration data — from the moment the deployer is notified of an MSA investigation

Confidentiality limits on cooperation. Art.73(4) is subject to confidentiality protections under EU law. Deployers may redact trade secrets from documents disclosed to the MSA, provided they explain the basis for each redaction and make non-confidential versions available. However, operational data about the AI system's performance in the specific incident context cannot be withheld on trade secret grounds.

CLOUD Act complication. Where a deployer maintains incident logs or operational AI data on US-based cloud infrastructure (AWS, Azure, GCP), the MSA's data request and a concurrent US government CLOUD Act production order could create a dual-compellability conflict. The deployer may face simultaneous legal obligations to disclose to the EU MSA and to withhold from the EU MSA pending US government access. Deployers in sensitive sectors — critical infrastructure, healthcare, law enforcement — should assess CLOUD Act exposure before siting AI-related operational data on US infrastructure.

Art.73(5): Incident Log Retention and Documentation

Art.73(5) specifies the deployer's documentation obligations that underpin all other Art.73 requirements.

What the incident log must contain. The deployer's incident log should record:

• Every incident notification sent to the provider (date, time, content, channel, recipient confirmation)
• Every incident investigated but not escalated to the provider (with documented rationale for non-escalation)
• Human oversight intervention events, including overrides and refusals to override
• System downtime or operational interruptions related to system behaviour
• User complaints that constitute near-miss indicators
• Corrective actions taken by the deployer in response to incidents

Retention period. Art.73(5) requires deployers to retain incident logs for the same period as providers retain technical documentation — a minimum of 10 years from the date of the incident. Where sector-specific regulation imposes longer retention (MDR/IVDR require 15 years for implantable devices), the longer period applies.

Format and accessibility. Logs must be maintained in a format that can be produced to the MSA in a legible and auditable form. Deployers who maintain logs in proprietary formats must be able to convert them on request.

Art.73(6): Public Sector and Critical Infrastructure Deployer Obligations

Art.73(6) imposes heightened obligations on deployers in public sector and critical infrastructure contexts, reflecting the higher stakes of AI system failures in these environments.

Public sector deployers. Public bodies deploying high-risk AI systems (Annex III categories 1-3: biometric identification, critical infrastructure, education, employment, essential services, law enforcement, migration/border control, administration of justice) are subject to the Art.73 deployer obligations and additionally face national transparency requirements in most Member States. Public sector deployers should document every AI-assisted decision that has a significant effect on individuals, and maintain records sufficient to explain those decisions.

Critical infrastructure operators. Deployers who operate critical infrastructure (energy grids, water supply, digital infrastructure, transport networks) must align Art.73 incident reporting with the parallel obligations under the NIS2 Directive (Art.23 NIS2: 24-hour early warning, 72-hour incident report, final report within one month). Where an AI system incident also constitutes a NIS2 significant incident, the Art.73 notification to the provider and the NIS2 early warning to the CSIRT/NCA should proceed on parallel tracks.

DORA intersection. Financial sector deployers subject to DORA (Digital Operational Resilience Act) must align Art.73 incident reporting with DORA Art.17 ICT incident reporting (immediate notification, intermediate report, final report). AI system incidents that constitute major ICT incidents under DORA require simultaneous Art.73 provider notification and DORA Article 17 competent authority reporting.

Art.73(7): Deployer Obligations for GPAI-Component High-Risk Systems

Art.73(7) addresses a complexity specific to AI systems built on general-purpose AI (GPAI) model components that also qualify as high-risk AI systems: the deployer's Art.73 obligations interact with the GPAI model provider's obligations under Art.53(1)(b) (serious incident reporting for GPAI models with systemic risk).

The dual-provider structure. When a high-risk AI system incorporates a GPAI model (e.g., an LLM used in a high-risk medical device application), there are two providers in the chain: the GPAI model provider and the high-risk AI system provider who integrated the GPAI model. The deployer's Art.73 notification to the high-risk AI system provider triggers that provider's Art.65 reporting to the MSA. But if the incident also involves the GPAI model exhibiting systemic-risk behaviour, the GPAI model provider has a separate obligation to report to the AI Office under Art.53(1)(b).

Deployer's role. The deployer should include in the Art.73 incident notification any information that would help the high-risk AI system provider assess whether the GPAI model component contributed to the incident — in particular, any evidence that the system behaviour was attributable to unexpected outputs from the GPAI model rather than integration-level failures.

CLOUD Act and Deployer Incident Records

Deployers who maintain their AI operational environments on US-based cloud infrastructure face a specific CLOUD Act risk that is distinct from (and compounds) the provider's CLOUD Act exposure for post-market monitoring data.

What data is at risk. Deployer incident logs, user interaction records, system output archives, and corrective action documentation all constitute data that could be subject to a US government CLOUD Act production order if stored on infrastructure operated by a US entity or its foreign subsidiaries. This data may include:

• AI system outputs that constitute personal data under GDPR (names, decisions, recommendations)
• Commercially sensitive operational data about the deployer's use case
• Security-relevant data about critical infrastructure operations

Conflict with Art.73(4) MSA cooperation. A CLOUD Act order to produce incident data may conflict with the deployer's obligation to disclose the same data to the EU MSA under Art.73(4). If the US government issues a sealed production order covering the same data, the deployer faces a dual-compellability conflict with no guaranteed legal resolution under current EU-US data sharing frameworks.

Practical mitigation. Deployers in high-risk sectors (healthcare, critical infrastructure, financial services, law enforcement) should store Art.73 incident logs and operational AI data on EU-jurisdiction infrastructure — either on-premises or via a cloud provider incorporated and operated exclusively under EU law with no US parent company with CLOUD Act obligations. This architectural choice eliminates the dual-compellability conflict.

Python Implementation: DeployerIncidentManager

The following implementation provides a structured Art.73-compliant incident management system for deployers. It captures the deployer notification chain, incident log, MSA escalation logic, and evidence preservation requirements.

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


class IncidentSeverity(Enum):
    """Art.3(49) serious incident categories relevant to deployer assessment."""
    LIFE_SAFETY = "life_safety"           # Death or serious health/safety risk
    CRITICAL_INFRASTRUCTURE = "critical_infrastructure"  # Serious disruption
    FUNDAMENTAL_RIGHTS = "fundamental_rights"  # EU law fundamental rights breach
    PROPERTY_DAMAGE = "property_damage"   # Serious property/environmental damage
    NEAR_MISS = "near_miss"              # Below threshold but documented
    NOT_SERIOUS = "not_serious"          # Operational issue, not Art.3(49)


class NotificationStatus(Enum):
    """Status of Art.73(2) provider notification."""
    PENDING = "pending"              # Incident recorded, notification not yet sent
    NOTIFIED = "notified"           # Provider notified successfully
    PROVIDER_UNREACHABLE = "provider_unreachable"  # Art.73(3) escalation needed
    MSA_DIRECT = "msa_direct"       # Art.73(3): direct MSA notification filed


@dataclass
class DeployerIncident:
    """Single incident record for Art.73(5) incident log."""
    incident_id: str
    detection_timestamp: datetime
    system_id: str
    severity: IncidentSeverity
    description: str
    ai_output: str                  # The specific AI output involved
    harm_or_near_miss: str          # Description of harm or near-miss
    human_oversight_active: bool    # Art.14: was human oversight in place?
    human_override_exercised: bool  # Art.14: was override exercised?
    operational_context: str        # Environmental/input context
    immediate_corrective_action: str
    notification_status: NotificationStatus = NotificationStatus.PENDING
    provider_notified_at: Optional[datetime] = None
    msa_notified_at: Optional[datetime] = None
    evidence_preserved: bool = False
    root_cause: Optional[str] = None
    follow_up_complete: bool = False


@dataclass
class ProviderNotification:
    """Art.73(2) notification sent to provider."""
    notification_id: str
    incident_id: str
    sent_at: datetime
    channel: str                    # Email, API, portal
    recipient: str                  # Provider contact
    confirmed_received: bool = False
    confirmed_at: Optional[datetime] = None


class DeployerIncidentManager:
    """
    Art.73-compliant incident management for high-risk AI deployers.
    Manages the detection→notification→cooperation→documentation cycle.
    """

    # Art.73(2): life-safety incidents — same-day notification expected
    LIFE_SAFETY_NOTIFICATION_HOURS = 24

    # Art.73(2): other serious incidents — "without undue delay" interpreted as
    STANDARD_NOTIFICATION_HOURS = 72

    # Art.73(3): if provider unresponsive after this period, escalate to MSA
    PROVIDER_RESPONSE_WAIT_HOURS = 48

    def __init__(self, deployer_id: str, system_id: str, provider_contact: str):
        self.deployer_id = deployer_id
        self.system_id = system_id
        self.provider_contact = provider_contact
        self.incidents: list[DeployerIncident] = []
        self.notifications: list[ProviderNotification] = []

    def record_incident(
        self,
        description: str,
        ai_output: str,
        harm_or_near_miss: str,
        severity: IncidentSeverity,
        human_oversight_active: bool,
        human_override_exercised: bool,
        operational_context: str,
        immediate_corrective_action: str,
    ) -> DeployerIncident:
        """Record an incident and determine Art.73(2) notification urgency."""
        incident_id = f"{self.system_id}-{datetime.now().strftime('%Y%m%d%H%M%S')}"
        incident = DeployerIncident(
            incident_id=incident_id,
            detection_timestamp=datetime.now(),
            system_id=self.system_id,
            severity=severity,
            description=description,
            ai_output=ai_output,
            harm_or_near_miss=harm_or_near_miss,
            human_oversight_active=human_oversight_active,
            human_override_exercised=human_override_exercised,
            operational_context=operational_context,
            immediate_corrective_action=immediate_corrective_action,
        )
        self.incidents.append(incident)
        return incident

    def notify_provider(self, incident: DeployerIncident, channel: str) -> ProviderNotification:
        """Art.73(2): Send notification to provider without undue delay."""
        notification = ProviderNotification(
            notification_id=f"notif-{incident.incident_id}",
            incident_id=incident.incident_id,
            sent_at=datetime.now(),
            channel=channel,
            recipient=self.provider_contact,
        )
        incident.notification_status = NotificationStatus.NOTIFIED
        incident.provider_notified_at = notification.sent_at
        self.notifications.append(notification)
        return notification

    def check_provider_response(self, incident: DeployerIncident) -> bool:
        """
        Art.73(3): Check if provider has responded and if MSA escalation is needed.
        Returns True if MSA escalation should be initiated.
        """
        if incident.notification_status != NotificationStatus.NOTIFIED:
            return False
        notification = next(
            (n for n in self.notifications if n.incident_id == incident.incident_id), None
        )
        if notification is None:
            return True
        if notification.confirmed_received:
            return False
        # Art.73(3) escalation threshold
        wait_period = timedelta(hours=self.PROVIDER_RESPONSE_WAIT_HOURS)
        if datetime.now() > notification.sent_at + wait_period:
            incident.notification_status = NotificationStatus.PROVIDER_UNREACHABLE
            return True
        return False

    def escalate_to_msa(self, incident: DeployerIncident, msa_contact: str) -> None:
        """Art.73(3): Direct MSA notification when provider is unreachable."""
        incident.notification_status = NotificationStatus.MSA_DIRECT
        incident.msa_notified_at = datetime.now()

    def preserve_evidence(self, incident: DeployerIncident) -> None:
        """Art.73(4): Mark evidence as preserved for MSA investigation cooperation."""
        incident.evidence_preserved = True

    def notification_overdue(self, incident: DeployerIncident) -> bool:
        """Check if Art.73(2) notification deadline has been missed."""
        if incident.notification_status != NotificationStatus.PENDING:
            return False
        hours = self.LIFE_SAFETY_NOTIFICATION_HOURS \
            if incident.severity == IncidentSeverity.LIFE_SAFETY \
            else self.STANDARD_NOTIFICATION_HOURS
        deadline = incident.detection_timestamp + timedelta(hours=hours)
        return datetime.now() > deadline

    def pending_notifications(self) -> list[DeployerIncident]:
        """Return incidents requiring Art.73(2) provider notification."""
        return [i for i in self.incidents if i.notification_status == NotificationStatus.PENDING]

    def pending_msa_escalations(self) -> list[DeployerIncident]:
        """Return incidents where Art.73(3) MSA escalation is due."""
        return [
            i for i in self.incidents
            if i.notification_status == NotificationStatus.PROVIDER_UNREACHABLE
            and i.msa_notified_at is None
        ]

    def incident_log_summary(self) -> dict:
        """Art.73(5): Structured incident log for MSA cooperation and provider reporting."""
        return {
            "deployer_id": self.deployer_id,
            "system_id": self.system_id,
            "total_incidents": len(self.incidents),
            "by_severity": {
                s.value: len([i for i in self.incidents if i.severity == s])
                for s in IncidentSeverity
            },
            "provider_notified": len([
                i for i in self.incidents
                if i.notification_status in (NotificationStatus.NOTIFIED, NotificationStatus.MSA_DIRECT)
            ]),
            "msa_direct_reports": len([
                i for i in self.incidents if i.notification_status == NotificationStatus.MSA_DIRECT
            ]),
            "evidence_preserved": len([i for i in self.incidents if i.evidence_preserved]),
            "overdue_notifications": len([i for i in self.incidents if self.notification_overdue(i)]),
            "human_oversight_active_rate": (
                len([i for i in self.incidents if i.human_oversight_active]) / len(self.incidents)
                if self.incidents else 0
            ),
            "generated_at": datetime.now().isoformat(),
        }

Art.73 in the Series: Chapter VIII Post-Deployment Obligations

10-Item Art.73 Compliance Checklist

Use this checklist to verify your Art.73 deployer compliance posture:

1. Monitoring cooperation — Deployer has reviewed the provider's Art.72 post-market monitoring instructions and implemented all required data collection, feedback, and reporting procedures.
2. Incident detection capacity — Deployer has operational procedures for identifying serious incidents (Art.3(49)) in real time, including detection triggers for life-safety, critical infrastructure, fundamental rights, and property damage categories.
3. Notification timeline compliance — Deployer can demonstrate it has notified providers within 24 hours for life-safety incidents and within 72 hours for other serious incidents, with documented evidence of notification timing.
4. Notification content completeness — Each provider notification includes: incident timestamp, AI output description, harm description, operational context, human oversight status, and immediate corrective action taken.
5. MSA escalation readiness — Deployer has identified the competent MSA for each Member State where the AI system is deployed and has a documented procedure for direct MSA reporting when the provider is unreachable (Art.73(3)).
6. MSA cooperation procedure — Deployer has an evidence preservation protocol that activates immediately when an MSA investigation is notified, covering incident logs, system output archives, configuration data, and personnel records.
7. Incident log completeness — Incident log captures all incidents including those not escalated to the provider, with documented rationale for non-escalation; near-miss events documented separately.
8. Retention policy — Incident logs are retained for a minimum of 10 years from incident date, consistent with Art.72 technical documentation retention.
9. CLOUD Act assessment — Incident log and operational AI data storage infrastructure has been assessed for CLOUD Act exposure; sensitive-sector deployers use EU-jurisdiction infrastructure.
10. Sector-parallel reporting — Where the deployer is subject to NIS2 (critical infrastructure), DORA (financial sector), MDR/IVDR (medical devices), or equivalent sectoral legislation, incident reporting procedures for Art.73 and the parallel sectoral obligation run on simultaneous tracks with documented coordination.