AI Act Post-Market Monitoring and Incident Reporting: The Complete Guide

Getting your AI system to market is only half the battle. Passing conformity assessment and affixing a CE mark may feel like crossing the finish line, but under the EU AI Act (Regulation (EU) 2024/1689), it is really the starting line for a permanent set of obligations. The Regulation requires continuous post-market monitoring and immediate reporting of serious incidents — obligations that never end while the system is in service. A provider that treats compliance as a one-time event will eventually face enforcement action, reputational damage, or both.

This guide covers the two interlinked pillars of ongoing compliance: the post-market monitoring system under Article 72 and serious incident reporting under Article 73. We walk through what to monitor, how to build monitoring infrastructure, when and how to report incidents, and who is responsible for what along the provider-deployer chain.

• Post-market monitoring is mandatory for all high-risk AI providers. It must be proportionate, active, and systematic throughout the entire lifecycle of the AI system (Article 72).
• The monitoring system must be documented as part of your technical documentation and integrated with your quality management system.
• You must track performance, bias, usage patterns, complaints, and log data — and demonstrate that you do so.
• Serious incidents — those causing death, serious health harm, disruption of critical infrastructure, violation of fundamental rights, or serious damage to property or the environment — must be reported to the relevant market surveillance authority within strict timelines (Article 73).
• Providers bear the primary monitoring and reporting obligation. Deployers must retain logs, cooperate with providers, and inform the provider immediately when they become aware of a serious incident.
• Failure to maintain a post-market monitoring system or report serious incidents can result in fines of up to EUR 15 million or 3% of global annual turnover.
• The monitoring system is not optional, not aspirational, and not a "nice-to-have." It is an enforceable legal requirement from 2 August 2026 onward.

Post-market monitoring system (Article 72)

Article 72 requires every provider of a high-risk AI system to establish and document a post-market monitoring system. The system must be proportionate to the nature of the AI technology and the risks of the system, and it must collect, document, and analyse relevant data provided by deployers or collected through other sources throughout the lifetime of the system.

What "proportionate, active, and systematic" means

• Proportionate means the depth and frequency of monitoring must match the risk level. A credit scoring system serving millions of consumers demands more intensive monitoring than a limited internal pilot.
• Active means the provider cannot simply wait for complaints. It must proactively seek out evidence of degradation, misuse, bias shifts, and emerging risks — through automated pipelines, deployer reporting channels, and independent audits.
• Systematic means monitoring must follow a documented plan with defined metrics, thresholds, frequencies, and escalation procedures. Ad hoc spot checks do not satisfy the requirement.

Integration with the broader compliance framework

The post-market monitoring system does not exist in isolation. It must feed into and draw from:

• The risk management system (Article 9) — monitoring data must be used to update risk assessments iteratively throughout the lifecycle.
• The technical documentation (Article 11) — the monitoring plan and its results form a mandatory section of your Annex IV documentation.
• The quality management system (Article 17) — the QMS must include procedures for post-market monitoring, and monitoring outcomes must trigger corrective actions within the QMS workflow.
• The logging system (Article 12) — automatic logs generated by the system provide the raw data that monitoring processes analyse.

If any of these systems is missing or disconnected, the whole compliance architecture has a gap.

What to monitor

The AI Act does not prescribe a rigid list of metrics, but Articles 9, 12, and 72 together with the Commission's draft guidance make expectations clear. Below is a practical framework.

Performance monitoring (accuracy, drift, degradation)

Track the core output quality of your AI system continuously:

Set alerting thresholds for each metric. When accuracy drops below a defined baseline or drift exceeds a statistical threshold (e.g., Population Stability Index > 0.2), the monitoring system should automatically trigger an investigation workflow.

Bias monitoring (fairness metrics over time)

Bias testing is not a one-time exercise. Population distributions shift, societal patterns evolve, and models that were fair at deployment can become unfair in production. Monitor:

• Demographic parity — are positive outcomes distributed proportionally across protected groups?
• Equalised odds — are true positive and false positive rates consistent across groups?
• Predictive parity — does the system's precision hold across groups?
• Disparate impact ratio — does any group receive favourable outcomes at a rate less than 80% of the most favoured group?

Where the system processes data related to protected characteristics (or proxies), disaggregate all performance metrics by those characteristics. Document the methodology and any limitations (e.g., where protected characteristics are inferred rather than directly observed).

Usage monitoring (intended purpose vs actual use, misuse detection)

The AI Act ties obligations to the system's intended purpose as defined in the provider's instructions for use. Monitoring must detect when actual use drifts beyond that intended purpose:

• Track the types of inputs being submitted. Are users submitting data categories that the system was not designed or validated for?
• Monitor deployment contexts. Is a system designed for pre-screening being used for final decision-making?
• Detect adversarial inputs or prompt-injection attempts.
• Flag usage volumes or patterns that suggest the system is being applied at a scale or in a domain not covered by the conformity assessment.

When misuse is detected, the provider must determine whether it constitutes a reasonably foreseeable misuse (which should have been addressed in the risk management system) or an unforeseeable scenario requiring updated risk documentation.

Feedback and complaints

Establish formal channels for:

• Deployer feedback — structured mechanisms for deployers to report issues, unexpected behaviours, near-misses, and user complaints.
• Affected person complaints — where affected individuals can flag concerns about AI-driven decisions that impact them (particularly relevant for systems subject to Article 86 rights of explanation).
• Internal reporting — procedures for employees and contractors to escalate concerns.

Every complaint must be logged, triaged, investigated, and — where substantiated — fed back into the risk management system. Complaint volume and category data should be part of regular monitoring reports.

Log retention (Article 12 — automatic logging, 6+ months retention for deployers)

Article 12 requires high-risk AI systems to have automatic logging capabilities. Logs must record events relevant to identifying risks, facilitating post-market monitoring, and enabling traceability. The minimum log content includes:

• The period of each use (start and end dates/times).
• The reference database against which input data was checked.
• Input data for which the search led to a match.
• The identification of natural persons involved in the verification of results.

Deployers must retain the logs automatically generated by the high-risk AI system for a period appropriate to the intended purpose, and in any case at least six months unless otherwise provided in applicable EU or national law (Article 26).

Providers should design their logging infrastructure to make it easy for deployers to comply — automated log export, tamper-evident storage, and retention management tools.

Serious incident reporting (Article 73)

What counts as a "serious incident"

Article 73 requires providers to report any serious incident to the market surveillance authorities of the Member State(s) where the incident occurred. The term "serious incident" is defined in Article 3(49) of the AI Act:

A serious incident means any incident or malfunctioning of an AI system that directly or indirectly leads to any of the following:

1. Death or serious damage to health — The system's output or failure contributes to the death of a person, or causes serious damage to a person's health. This includes both physical and psychological harm.

2. Serious and irreversible disruption of critical infrastructure — The system causes or contributes to the disruption of the management and operation of critical infrastructure (energy, transport, water, banking, digital infrastructure, healthcare, etc.) in a way that is serious and irreversible.

3. Breach of fundamental rights — The system's output or failure leads to a breach of obligations under Union law intended to protect fundamental rights — including non-discrimination, privacy, data protection, freedom of expression, and the right to an effective remedy.

4. Serious damage to property or the environment — The system causes widespread damage to property or the environment that is serious in scope and impact.

The key phrase is "directly or indirectly." A system that provides a recommendation subsequently acted upon by a human, leading to harm, may still trigger the reporting obligation if the causal chain is sufficiently direct.

Who must report

The provider is the primary reporting obligor. However, the obligation depends on awareness:

• Providers must report to the relevant market surveillance authority after becoming aware that a serious incident has occurred.
• Deployers must inform the provider (and, where applicable, the distributor) immediately after becoming aware of a serious incident (Article 26). If the deployer cannot reach the provider, or in cases where the deployer itself has provider obligations (e.g., under Article 25), the deployer must report directly to the market surveillance authority.

The Commission's draft guidance

In September 2025, the European Commission published its draft guidance on serious incident reporting, providing critical clarification on several ambiguous aspects of Article 73.

Reporting template

The guidance includes a standardised reporting template structured in three parts:

1. Initial notification — basic identification of the system, the incident, and the immediate harm.
2. Intermediate report — updated information as the investigation progresses, including root cause analysis.
3. Final report — complete findings, corrective actions taken, and measures to prevent recurrence.

Providers should integrate this template into their incident management workflow now, rather than attempting to adopt it under the pressure of an actual incident.

Clarification of "indirect causal link"

The guidance clarifies that "indirectly leads to" covers situations where: the AI system's output was a material factor in a chain of events leading to harm, even if a human intervened; the system failed to perform its intended function and that failure contributed to the harm; or the system's cumulative effects over time led to harm (e.g., systematic bias causing discriminatory outcomes across a population). The guidance explicitly states that human oversight does not automatically break the causal chain — if the system's output was designed to inform the human decision, and the human reasonably relied on it, the indirect link may still be established.

Examples from the guidance

The Commission's draft guidance provides illustrative examples:

• A medical triage AI that incorrectly classifies a patient as low-priority, contributing to a delayed diagnosis that results in serious health deterioration — this is a reportable serious incident.
• A predictive policing system that systematically over-predicts risk in minority neighbourhoods, leading to disproportionate surveillance and a breach of non-discrimination rights — reportable under the fundamental rights category.
• An autonomous vehicle subsystem that misidentifies a road hazard, contributing to a collision causing serious injury — reportable under the health/death category.
• A minor software glitch that causes a temporary display error in an AI-powered dashboard, with no downstream impact on decisions or safety — not reportable as a serious incident.

Reporting timelines and process

The AI Act and the Commission's guidance establish a structured reporting process with defined timelines. Delays in reporting are themselves a compliance violation.

Step-by-step process

Critical timeline details

• 2-day deadline for incidents involving death or serious damage to health: the clock starts when the provider becomes aware. "Becomes aware" includes constructive awareness — if the provider should reasonably have known based on available information (e.g., deployer reports, public reports), the deadline runs from that point.
• 10-day deadline for serious and irreversible disruption of critical infrastructure.
• 15-day deadline for all other serious incidents (fundamental rights breaches, property/environment damage).
• If the provider cannot complete the initial report within the deadline, it must file a preliminary report with available information and supplement it as the investigation progresses.
• Reports must be filed with the market surveillance authority of each Member State in which the incident occurred.

What the initial report must include

At minimum: the provider's identity; the AI system's identification (name, version, CE certificate number, EU database registration number); a description of the incident and harm caused; date and location; an initial assessment of the incident category; any immediate corrective measures taken; and contact details for follow-up.

Provider vs deployer monitoring obligations

Understanding who is responsible for what is critical to avoiding gaps and duplicated effort. The table below compares the monitoring and incident reporting obligations of providers and deployers for high-risk AI systems.

Key deployer obligations in detail

Deployers are not passive recipients. Under Article 26, deployers must: use the system in accordance with the provider's instructions; assign human oversight to competent persons; monitor the system's operation within their deployment context; retain logs for at least six months; inform affected persons that they are subject to a high-risk AI system; inform the provider immediately of any serious incident; and suspend use if they consider the system presents a risk.

A deployer that fails to inform the provider of a serious incident, or that continues to use a system it knows to be non-compliant, faces enforcement action and fines in its own right.

Building a monitoring system in practice

Theory matters, but execution is what regulators will audit. Below is a practical architecture for a post-market monitoring system.

Data pipelines

Design automated data pipelines that continuously ingest:

• Production inference logs — every prediction, classification, or recommendation, with timestamps, input metadata, confidence scores, and ground-truth labels where available.
• Deployer feedback — structured API or portal-based channels for performance observations, complaints, and anomaly reports.
• External data — regulatory bulletins, academic research, media reports, and complaints filed with data protection authorities.
• Retraining data — any new training data introduced through model updates, with lineage tracking.

Use event-driven architecture so that monitoring is near-real-time for safety-critical systems, rather than relying on weekly batch reports.

Alerting thresholds

Define quantitative thresholds that trigger automatic escalation:

Dashboard KPIs

Build a monitoring dashboard (internal or client-facing for deployers) that visualises:

• Overall accuracy and performance trends (daily/weekly rolling averages).
• Bias metrics by protected group, with trend lines and alert thresholds.
• Drift metrics (PSI, KL divergence) on input and output distributions.
• Complaint volume and categorisation.
• Log completeness and retention compliance.
• Open incident count and status.
• Time-to-resolution for previous incidents.

Escalation procedures

Document a clear escalation chain: Level 1 (monitoring team) triages alerts and investigates routine issues. Level 2 (technical lead / data science) conducts root cause analysis for critical alerts. Level 3 (compliance / legal) assesses whether the event constitutes a serious incident under Article 73 and drafts reports. Level 4 (executive / board) is authorised to make system suspension, recall, or withdrawal decisions and is briefed immediately for emergency-level events.

Documentation templates

Maintain pre-built templates for:

• Monthly monitoring report — summarising KPIs, trends, alerts triggered, investigations conducted, and corrective actions.
• Incident assessment form — structured questionnaire to determine whether an event meets the Article 3(49) threshold.
• Article 73 report — aligned with the Commission's standardised template (initial, intermediate, and final).
• Corrective action record — documenting the action taken, its rationale, its effect, and the verification that it resolved the issue.
• Risk management update — connecting monitoring findings to the Article 9 risk management system and recording how the risk assessment was updated.

Real-world monitoring scenarios

Scenario 1: Credit scoring performance degradation

Real-world example: A fintech provider operates a high-risk AI credit scoring system (Annex III, point 5(a)) deployed by 30 European lenders. Six months after deployment, the post-market monitoring dashboard shows that the system's false rejection rate for applicants from a specific national origin group has increased from 8% to 19%, while remaining stable at 7% for other groups. The disparate impact ratio has dropped below 0.6.

What should happen: The automated alerting system triggers a critical alert. Investigation reveals a macroeconomic shift disproportionately affected the relevant demographic, causing the model's features to become less predictive for that group. The provider determines this constitutes a potential breach of fundamental rights (non-discrimination) and files an initial serious incident report within 15 days. Corrective action includes retraining the model with updated data, adjusting feature weights, and deploying an interim manual review for affected applicants. All 30 deployers are notified. The risk management system is updated to include macroeconomic sensitivity analysis as a standing monitoring requirement.

Scenario 2: Medical diagnostic misdiagnosis

Real-world example: A provider offers an AI-powered radiology assistance tool classified as high-risk under Annex III, point 5(a) (AI intended for medical diagnostics). A hospital deployer reports that the system failed to flag a malignant tumour on a chest X-ray. The radiologist, relying on the AI's "no findings" output as a second opinion, did not catch the tumour in their initial review. The patient's diagnosis was delayed by four months, resulting in disease progression requiring more aggressive treatment.

What should happen: The deployer immediately informs the provider as required by Article 26. The provider classifies this under the death/serious health damage category and files an initial report within 2 days. Root cause investigation reveals the tumour was in an image region where the model had known lower sensitivity, but this limitation was insufficiently communicated in the instructions for use. Corrective actions: the provider updates the instructions for use, retrains the model with additional annotated data, and issues a safety communication to all deployer hospitals. The technical documentation is updated, and the provider initiates a broader review across all deployer sites.

Scenario 3: HR screening tool flagged for systematic bias

Real-world example: A multinational corporation deploys an AI-powered CV screening tool (high-risk under Annex III, point 4(a) — recruitment and selection of candidates). An employee in the HR department notices that the tool consistently ranks female applicants lower for engineering roles. The employee files an internal complaint.

What should happen: The deployer's compliance team analyses six months of screening data (retained under the log retention obligation) and confirms the disparity: female applicants are 2.3 times less likely to be shortlisted than equally qualified male applicants. The deployer immediately informs the provider and suspends use for engineering role screening. Root cause analysis reveals the training data was skewed toward historically male-dominated teams, embedding a gender proxy through features like university name. The provider files a serious incident report under the fundamental rights category within 15 days, retrains the model with debiased data, adds explicit fairness constraints, and communicates corrective measures to all deployers.

Does post-market monitoring apply to AI systems that are not high-risk?

The Article 72 obligations apply specifically to high-risk AI systems. However, providers of other systems should still monitor as good practice, because a system may be reclassified if its use context changes. Providers of general-purpose AI models with systemic risk have additional obligations. The EU AI Act compliance checklist covers monitoring across risk tiers.

How long must we keep monitoring data and logs?

Deployers must retain logs for at least six months (Article 26). Providers must operate the monitoring system for the entire lifetime of the AI system. In practice, retain monitoring data for at least the period of potential liability — typically several years. Sector-specific rules (medical devices, financial services) may impose longer periods.

What happens if a deployer discovers an incident but the provider is unreachable?

If the deployer cannot reach the provider within a reasonable timeframe, the deployer should report directly to the market surveillance authority of the Member State in which the incident occurred. The deployer should also document all attempts to contact the provider. Under Article 26, the deployer has an independent obligation to suspend use if they consider the system presents a risk, regardless of whether they have communicated with the provider.

Can a provider delegate monitoring to a deployer or third party?

A provider can contractually arrange for deployers or third-party service providers to collect data, operate dashboards, or perform monitoring activities. However, the legal obligation remains with the provider. The provider cannot delegate away its responsibility. If the third party fails to monitor adequately, the provider is liable. Any delegation must be documented in the quality management system and reflected in the contractual agreements with deployers.

Is every bias finding a "serious incident" that must be reported?

No. A bias finding is a serious incident only if it directly or indirectly leads to a breach of fundamental rights that is serious in nature. A minor statistical deviation that is detected, investigated, and corrected before it causes harm is not a reportable serious incident — although it should be documented internally and fed into the risk management system. The determination requires a case-by-case assessment of the severity, scope, and reversibility of the harm. When in doubt, err on the side of reporting — under-reporting carries greater regulatory risk than over-reporting.

How does the AI Act interact with GDPR breach notification?

The AI Act's serious incident reporting is separate from and additional to GDPR's personal data breach notification (Article 33 GDPR). A single event may trigger both: notification to the data protection authority under GDPR and to the market surveillance authority under Article 73. The timelines differ (72 hours vs. 2–15 days), the authorities differ, and the templates differ. Ensure your incident response plan addresses both. For more on the overlap between the AI Act and GDPR, see our detailed comparison.

Next steps

Post-market monitoring and incident reporting are living systems that must evolve as your AI system evolves and as new risks emerge in production. Audit your current monitoring capabilities against this guide, identify gaps, and close them before the 2 August 2026 enforcement deadline.

If you are unsure whether your AI system qualifies as high-risk, start with a free AI Act risk classification assessment. If it does, these obligations are the cost of doing business in the European AI market.