What receives less attention is what must happen after deployment. Two articles cover it comprehensively.
Article 72 requires every high-risk AI system provider to establish a continuous monitoring system that tracks real-world performance across the system's operational lifetime. Article 73 requires those same providers to report serious incidents to national market surveillance authorities within timeframes measured in days, not months. Both obligations take effect August 2, 2026.
If your monitoring plan exists only on paper, or if your incident escalation path leads to a general IT helpdesk, you are not compliant with either article.
TL;DR
- Article 72 requires providers of high-risk AI systems to establish a documented post-market monitoring system: actively collecting performance data, detecting drift, and evaluating ongoing compliance with Chapter III, Section 2 requirements.
- The monitoring plan must be part of the Annex IV technical documentation. The European Commission's implementing act establishing the plan template was due by 2 February 2026.
- Article 73 requires providers to report serious incidents to national market surveillance authorities: within 15 days as a default, 2 days for widespread or severe incidents, and 10 days when a death is involved.
- Both obligations apply to providers, not just deployers. If you developed and placed a high-risk AI system on the market, the monitoring and reporting obligations belong to you.
Who These Articles Apply To
Articles 72 and 73 apply to providers of high-risk AI systems: entities that develop a high-risk AI system and place it on the EU market or put it into service in the EU, under their own name or trademark, regardless of whether they are established in the EU.
Deployers (the organizations that use a provider's high-risk system) have separate obligations under the AI Act (Article 26), but post-market monitoring and serious incident reporting to authorities remain the provider's responsibility.
Two situations commonly create ambiguity:
In-house development: A company that builds and deploys a high-risk AI system for its own internal use acts as both provider and deployer. Article 72 and 73 obligations apply in full.
Integration scenarios: A company that substantially modifies an existing high-risk AI system, or integrates it into a new context that changes its purpose, may be treated as a provider of a new system. The technical documentation, conformity assessment, and post-market monitoring obligations attach accordingly.
High-risk AI systems are those listed in Annex III (recruitment, credit scoring, critical infrastructure, education, law enforcement, biometric identification, and others; see the EU AI Act system classification guide for the full risk-tier breakdown) and those covered by the harmonization legislation in Annex I (medical devices, machinery, aviation, and others).
Article 72: What Your Post-Market Monitoring System Must Do
Article 72(1) requires a post-market monitoring system that is proportionate to the nature of the AI technology and the associated risks. Proportionality matters here: the system required for a low-stakes Annex III category (such as AI used in spam filtering) is less intensive than for a system making credit decisions or assessing job candidates.
The Core Obligation: Active, Systematic Data Collection
Article 72(2) specifies that the monitoring system must "actively and systematically collect, document and analyse relevant data" on performance throughout the system's lifetime. Passive logging that sits unread in a storage bucket does not satisfy this requirement. The obligation is to collect and analyze, which implies a defined review cadence and a structured analysis process.
Data sources are broad: the system collects data from deployers (who observe the system's real-world outputs), from the outputs themselves, and from any other relevant sources. Where the AI system interacts with other AI systems, post-market monitoring must include analysis of those interactions.
One exception applies: sensitive operational data of deployers who are law enforcement authorities is excluded from the collection obligation.
What to Monitor in Practice
The Article 72 text specifies that monitoring must evaluate the system's "continuous compliance with the requirements set out in Chapter III, Section 2," meaning the technical requirements for high-risk AI systems. Those requirements include accuracy, robustness, and cybersecurity; data governance; technical documentation; logging; transparency toward deployers; human oversight; and general fitness for purpose.
In practice, this translates to a monitoring program covering:
Performance metrics. Accuracy, precision, recall, F1 score, or equivalent metrics appropriate to the system's output type, tracked continuously against the baselines documented in the Annex IV technical file.
Prediction drift. Changes in the distribution of outputs over time, particularly when the input data distribution shifts from the training distribution. Rising prediction entropy or shifting output category frequencies are early signals that retraining or model adjustment is needed.
Override rate tracking. Where human oversight mechanisms exist (as required by Article 14 for high-risk systems), the rate at which human operators override the system's outputs is a leading indicator of performance degradation. A sustained increase in override rate triggers investigation.
Bias and fairness indicators. For systems operating on personal data across population groups, monitoring must detect whether accuracy or reliability is degrading differentially across groups covered by anti-discrimination law.
Input data quality. Changes in the quality, completeness, or distribution of inputs can degrade model performance even when the model itself is functioning correctly. Monitoring pipelines must detect dataset drift at the input level, not only at the output level.
Incident and near-miss logging. Any incident that approaches but does not meet the Article 3(49) threshold for a "serious incident," and any deployer complaint about system performance, should feed into the monitoring record.
The Post-Market Monitoring Plan
Article 72(3) requires the monitoring to be governed by a documented plan, which forms part of the Annex IV technical documentation. The European Commission was required to adopt an implementing act establishing a template for this plan by 2 February 2026.
At minimum, a compliant monitoring plan specifies: the performance metrics tracked and their baseline values; the data sources and collection method; the review cadence (how often data is analyzed and by whom); the thresholds that trigger escalation; the corrective action procedure when a threshold is crossed; and the record-keeping format that allows regulators to verify compliance.
The Commission's implementing act template, once adopted, provides the formal structure. Organizations that have not yet received the final template should build plans now using the Annex IV requirements as the framework, with the expectation of aligning to the template when it is finalized.
Secure Privacy's Privacy & AI Governance Platform includes a Risk Management module with lifecycle monitoring capabilities that support post-market monitoring plan documentation, threshold tracking, and automated compliance task triggers, reducing the manual overhead of maintaining a continuously live monitoring program across multiple AI systems.
Article 73: What Counts as a Serious Incident and When to Report It
The Definition of a Serious Incident
Article 3(49) of the EU AI Act defines a "serious incident" as an incident or malfunction of an AI system that directly or indirectly leads to at least one of the following:
- Death or serious harm to the health of a natural person
- Serious and irreversible disruption to the management or operation of critical infrastructure
- Infringements of obligations under EU law intended to protect fundamental rights
- Serious harm to property or the environment
The "directly or indirectly" language is significant. An AI system does not need to be the sole or proximate cause of harm to trigger the reporting obligation. If the AI system contributed to a chain of events that produced a serious outcome, the provider's obligation to investigate and report applies.
The Commission's draft guidance published on 26 September 2025 clarified several contested definitional questions, including the threshold for "serious harm to health" and the interaction between the AI Act's definition and sector-specific definitions under medical device and machinery regulations.
Who Reports and to Whom
Providers of high-risk AI systems placed on the EU market report to the market surveillance authority of the Member State where the incident occurred. If an incident occurs across multiple Member States, the provider reports to each relevant authority. The notified authority must immediately notify the European Commission of any serious incident it receives.
Deployers who become aware of a serious incident must notify the provider. They do not report directly to market surveillance authorities unless they have also modified the system in a way that makes them a provider.
The Three Reporting Timelines
Article 73 establishes a tiered timeline structure based on the severity and breadth of the incident:
| Incident type | Reporting deadline |
|---|---|
| Standard serious incident | 15 days from awareness of causal link |
| Widespread or specific serious incident (as defined in implementing act) | 2 days from awareness |
| Incident resulting in death | 10 days from awareness |
The clock starts when the provider establishes, or has reasonable grounds to believe, that a causal link exists between the AI system and the serious outcome — not when the incident itself occurred, and not when the provider is formally notified by a deployer.
Providers may submit an initial incomplete report when they cannot provide full information within the applicable deadline. The follow-up complete report must be submitted as soon as the additional information is available.
What Happens After You Report
Within seven days of receiving the notification, the market surveillance authority must take appropriate measures. In practice, this means the authority will assess the incident, may request additional information, and may require the provider to take corrective action, withdraw the system, or recall it from the market.
Article 73(4) specifies that providers must cooperate fully with competent authorities and must not alter the AI system in a way that affects the ability to investigate the incident before informing the authority.
The investigation the provider conducts in parallel must include a risk assessment and identification of corrective actions. The results feed into the post-market monitoring record.
Not sure whether your incident meets the Article 73 threshold? Secure Privacy's AI Governance module supports incident classification workflows aligned to the EU AI Act's definitions, with structured escalation paths and audit-trail documentation.
Building an Incident Detection and Escalation Workflow
The two-day reporting window for widespread or severe incidents requires a detection and escalation mechanism that does not depend on manual observation. The functional requirements:
Detection layer. Automated monitoring that flags anomalies in real time — not batch processing that runs overnight. For life-critical or critical infrastructure applications (medical diagnosis, traffic management, credit decisions), real-time anomaly detection is the only architecture that can meet the two-day window.
Severity classification. A decision matrix that maps each flagged anomaly to the Article 3(49) categories, distinguishing a serious incident from a performance issue that belongs in the monitoring log but does not trigger reporting.
Escalation path. A defined chain: who receives the automated alert, who makes the initial severity classification, who has authority to confirm a reportable serious incident, and who prepares and submits the notification to the market surveillance authority. This chain must be documented and tested before enforcement begins.
Regulatory contact mapping. Pre-identified contact details for the market surveillance authority in each EU Member State where the system is deployed. Locating contact details after an incident occurs wastes hours from a two-day window.
Template for the notification. The Commission's draft guidance from September 2025 includes a reporting template. Completing this template for the first time under a two-day deadline, with incomplete information, is a meaningful compliance risk. The template should be reviewed and a draft framework pre-populated before any incident occurs.
How Articles 72 and 73 Fit Into the Broader Technical File
The post-market monitoring plan is part of the Annex IV technical documentation — the same document that covers the system's description, training data governance, accuracy metrics, human oversight measures, and cybersecurity. This is not an accident: Article 72 treats post-market monitoring as the live evidence that what was declared in the technical file before deployment remains true during operation.
The link between Articles 72 and 73 is direct: the post-market monitoring system is the mechanism that should detect events that rise to the level of serious incidents. A provider whose monitoring system fails to detect a performance degradation that eventually causes serious harm has two failures to answer for: a monitoring failure under Article 72 and a reporting failure under Article 73.
For providers operating across multiple Annex III categories or regulated sectors (medical devices, machinery), Article 72(4) allows integration of the AI Act monitoring plan into existing sector-specific post-market surveillance frameworks, provided the integrated approach achieves equivalent protection. This is a practical relief for providers already subject to Medical Device Regulation or Machinery Directive monitoring requirements.
The EU AI Act's broader compliance framework covers the full lifecycle obligation set — Articles 72 and 73 are the operational continuation of what conformity assessment started before deployment.
FAQ
Does Article 72 apply to general-purpose AI models?
No. Articles 72 and 73 apply to providers of high-risk AI systems as defined in Annex III and Annex I. Providers of general-purpose AI models have separate obligations under Chapter V (Articles 51-56), which include incident reporting to the AI Office rather than to national market surveillance authorities.
What is the difference between a serious incident under Article 73 and a system malfunction under Article 72?
A malfunction is any deviation from intended performance, even if it causes no harm. Malfunctions feed into the post-market monitoring record under Article 72 but do not trigger the reporting obligation under Article 73 unless the malfunction results in one of the four serious outcomes: death or serious harm, critical infrastructure disruption, fundamental rights violations, or serious property or environmental harm.
Who is responsible for reporting if the provider is not established in the EU?
Non-EU providers that have placed high-risk AI systems on the EU market must appoint an EU-based authorized representative under Article 22. The authorized representative cooperates with the market surveillance authorities and may handle the Article 73 notification on the provider's behalf, but the primary obligation remains the provider's.
What happens if an incident occurs during the transition period before August 2, 2026?
Article 73 reporting obligations apply from 2 August 2026. Incidents that occur before that date are not subject to the reporting requirement, though providers may voluntarily notify authorities of significant safety issues under existing product safety frameworks.
Does the monitoring plan need to be reviewed annually?
The AI Act does not specify a mandatory review cadence for the monitoring plan itself, but it requires monitoring to be continuous and to evaluate ongoing compliance. In practice, the plan should be reviewed whenever the system is updated, when input data distributions change materially, when the deployment context expands, or when an incident reveals a gap in the monitoring approach.
Can deployers access the post-market monitoring data?
Deployers provide data into the monitoring system (as contemplated by Article 72(2)) but do not have a formal right of access to the provider's full monitoring records. However, deployers are entitled under Article 13 to information about the system's performance characteristics and limitations, and providers must inform deployers of any limitations discovered through post-market monitoring that affect intended use.
How does Article 73 reporting interact with GDPR breach notification?
A serious AI incident and a personal data breach may arise from the same event but trigger separate legal obligations. GDPR Article 33 requires notification to the data protection authority within 72 hours of becoming aware of a breach. Article 73 of the AI Act requires notification to the market surveillance authority within the applicable AI Act timeline. Both obligations may apply simultaneously and neither displaces the other.
What corrective actions can market surveillance authorities require after an Article 73 report?
Authorities may require the provider to take risk-mitigation measures, restrict or cease use of the system, recall it from the market, or inform affected deployers and users. The specific action depends on the severity of the incident and the risk assessment submitted with the notification. Providers retain the right to submit additional evidence and representations to the authority during the assessment.
Post-market monitoring and serious incident reporting are the operational backbone of EU AI Act compliance for high-risk systems. Conformity assessment and technical documentation are completed before deployment. Articles 72 and 73 are what compliance looks like every day after.
See how Secure Privacy's Privacy & AI Governance Platform supports post-market monitoring documentation, incident classification, and AI Act compliance workflows — built for the obligations that begin on August 2, 2026.
