What is AI post-market monitoring and incident reporting?
Global AI regulation
AI post-market monitoring and incident reporting is the ongoing process of watching an AI system after deployment, collecting evidence about how it performs in real use, identifying harmful failures or misuse, and escalating serious cases to regulators, customers or other responsible parties when legal or contractual thresholds are met. In practice, it turns AI governance from a launch exercise into a continuing control loop of logging, review, corrective action and, where required, formal notification.
What this means
Post-market monitoring starts when an AI system is live, not when it passes testing. It is the organised collection of evidence from real use: logs, operator feedback, user complaints, unexpected behaviour, misuse signals, failures caused by updates, and problems caused by interactions with other systems.
Incident reporting is the escalation layer on top. Most issues stay inside normal quality, security or risk processes. A smaller set crosses a defined threshold, such as serious harm to health, disruption of critical infrastructure, major rights violations, or another trigger set by sector law or contract. At that point the organisation may need to notify a regulator, a provider, a customer, or another responsible party within set deadlines.
So this topic is not simply "monitoring" and not simply "incident response". It is the bridge between live oversight and formal accountability.
Why it matters
AI systems often behave differently in production than they did in testing. Real users improvise, data shifts, interfaces change, third-party components are updated, and some systems continue to be adapted after release. Regulators and standards bodies care about post-market monitoring because pre-release checks cannot fully predict those field conditions.
For organisations, this is where governance becomes credible. A mature post-market regime helps you detect harm earlier, preserve evidence, decide whether to patch, roll back or suspend use, and show customers, auditors and authorities that you can manage deployed AI rather than merely approve it at launch. Without it, serious failures are discovered late, explanations are weak, and reporting deadlines are easily missed.
How it works
<strong>The basic control loop</strong>
Post-market monitoring should be active and systematic, not ad hoc. In the strongest current legal model, the provider of a high-risk AI system must have a written monitoring system and plan that are proportionate to the technology and the level of risk. In practical terms, that means collecting and reviewing logs, field complaints, deployer feedback, misuse reports, supplier notices, and signals that the system is behaving differently in production.
Good monitoring also watches for more than fully formed incidents. The OECD distinguishes between an incident, where the development, use or malfunction of AI has led to harm, and a hazard, where it could plausibly do so. That distinction is useful because serious legal duties often attach to incidents, but responsible governance should act earlier on hazards, near misses and repeated low-level defects.
<strong>When a problem becomes a reportable incident</strong>
Not every bug is a reportable AI incident. Most organisations need a severity ladder that separates routine defects, elevated risk signals, hazards or near misses, and reportable serious incidents. The exact threshold depends on the regime. The clearest cross-sector legal threshold so far comes from the EU AI Act, which treats as serious incidents events or malfunctions leading to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment.
A useful practical lesson from the EU model is that reporting does not wait for perfect certainty. The provider reports once it has established a causal link, or the reasonable likelihood of one, between the system and the serious incident. Where speed matters, the initial report may be incomplete and followed by a fuller one. In other words, the operating rule is usually "escalate and preserve evidence first, complete the analysis second".
<strong>Ownership across the AI value chain</strong>
Post-market duties rarely sit with one team or one company. In the EU model, the provider owns the formal post-market monitoring system for high-risk AI systems. The deployer also has live-use duties: it must monitor operation on the basis of the provider's instructions, inform the provider where relevant, and suspend use if it has reason to think the system presents a risk. If the deployer identifies a serious incident, it must immediately inform the provider and then the importer or distributor and the relevant authority. Deployers must also keep logs under their control for a defined period.
The value chain matters because incidents often involve hosted models, external data, embedded tools or downstream integrators. The EU AI Act expects written agreements between providers of high-risk AI systems and third parties supplying tools, services, components or processes, so that the provider has the information and technical access needed for compliance. NIST's Generative AI Profile pushes this same idea in operational terms by recommending incident clauses in vendor contracts, including responsibility allocation, response times and notice of serious incidents arising from third-party data and systems.
<strong>The evidence a monitoring system should produce</strong>
Monitoring matters because it creates evidence, not just awareness. Useful evidence usually includes a monitoring plan, production logs, version history, change records, user and operator feedback, issue tickets, severity decisions, risk assessments, communications with counterparties, corrective actions, rollback records and after-action reviews. This material is what allows a governance lead to explain what happened, why the organisation responded as it did, and whether legal duties were triggered.
This is also where post-market monitoring connects to assurance, audit and risk management. NIST's AI RMF places post-deployment monitoring, incident response, recovery and communication inside the MANAGE function. Its Generative AI Profile goes further by recommending error and near-miss tracking, after-action review, escalation paths to legal and regulatory bodies where applicable, and continuous monitoring of third-party generative AI systems in deployment. If an organisation cannot reconstruct the event and the decision trail around it, its monitoring regime is not yet mature.
<strong>How standards and voluntary frameworks use the concept</strong>
Standards and intergovernmental instruments treat post-market monitoring as a continuing governance duty. NIST frames it as regular monitoring and improvement for deployed AI systems. The Hiroshima Process Code of Conduct says organisations developing advanced AI should monitor vulnerabilities, incidents, emerging risks and misuse after deployment, facilitate responsible disclosure by users and third parties, document reported incidents, and share relevant information with public authorities and the public when appropriate.
The Hiroshima AI Reporting Framework turns that voluntary logic into a standardised public reporting process. It is open to organisations across the AI value chain, reports are published by OECD.AI, and the first round produced 25 public reports. This is not the same as mandatory incident notification to a regulator. Its value is comparability, public accountability and cross-border learning. The OECD's common reporting framework for AI incidents serves a different but related purpose by offering an interoperable taxonomy that jurisdictions can use for either mandatory or voluntary reporting schemes.
<strong>Where binding law is strongest today</strong>
Today, the strongest general AI-specific legal architecture is in the EU AI Act. For high-risk AI systems, providers must establish and document a post-market monitoring system that is proportionate to the risks, based on a monitoring plan that forms part of the technical documentation. The system must actively and systematically collect, document and analyse relevant field data throughout the system's lifetime, including, where relevant, its interaction with other AI systems.
The same law gives incident reporting real teeth. Providers of high-risk AI systems placed on the Union market must report serious incidents to the market surveillance authority of the Member State where the incident occurred. The baseline deadline is no later than 15 days after awareness, but the timetable tightens to 2 days for widespread infringements or serious and irreversible disruption of critical infrastructure, and 10 days in the event of death. After reporting, the provider must investigate without delay, perform a risk assessment and take corrective action. The authority must then take appropriate measures within seven days of receiving the notification.
The EU framework also shows how post-market monitoring interacts with sector law. It allows some integration with existing product-law monitoring systems and with internal governance arrangements in financial services. For general-purpose AI models with systemic risk, a related but distinct reporting duty already applies: providers must keep track of, document and report relevant information about serious incidents and possible corrective measures to the AI Office and, where appropriate, national authorities without undue delay.
One important boundary is timing. As of June 2026, most high-risk AI system rules are scheduled to apply from 2 August 2026, while the obligations for general-purpose AI providers already applied from 2 August 2025. The European Commission proposed adjusting the timing of high-risk rules because key standards and support measures have been delayed, and a provisional political agreement to defer several of these dates was reached in May 2026 under the Digital Omnibus, so the applicable date should be confirmed against the current position. So the institutional design is clear, but some implementation timing remains live.
Examples
Current EU example: the provider of a high-risk AI system is expected to run a documented post-market monitoring plan that gathers field evidence across the system's lifetime. If a serious incident is identified, the deployer informs the provider and relevant authority, the provider can submit an initial incomplete report if speed is critical, then it must investigate, assess risk and take corrective action. This is the core legal workflow the EU is building for deployed high-risk AI.
Current transport example: in the United States, NHTSA's Standing General Order requires named manufacturers and operators to report certain crashes involving automated driving systems or Level 2 advanced driver assistance systems. The point is timely, transparent notice from the field so the agency can investigate real-world safety concerns and, if needed, pursue defect action. It is a sector-specific example of post-market monitoring translated into mandatory incident reporting.
Current voluntary global example: the Hiroshima AI Reporting Framework allows organisations across the AI value chain to submit public reports on how they manage risks and govern advanced AI. OECD.AI publishes those reports, accepts rolling submissions, and says the first round generated 25 reports. This is not a hard-law incident trigger, but it shows how public reporting can create shared evidence and peer scrutiny before or alongside legal mandates.
Common misunderstandings
"Once we have passed pre-launch testing, post-market monitoring is optional." It is not. Monitoring exists because real-world use creates risks that testing alone cannot capture.
"Every bug is a reportable AI incident." It is not. Most defects stay inside normal quality, security or risk processes. External reporting is usually reserved for serious events that meet a legal or contractual threshold.
"Only the model developer has duties." Not always. Deployers, operators, distributors, importers and third-party suppliers can all have monitoring, logging, escalation or information-sharing responsibilities.
"Incident reporting starts only when causation is fully proved." Not necessarily. Some regimes require reporting once a causal link, or the reasonable likelihood of one, has been established.
"A transparency report is the same as an incident report." It is not. Transparency reports describe governance practices, capabilities, limitations or safeguards in broad terms. Incident reports are event-specific escalations tied to a concrete failure or serious risk.
Risks and boundaries
Post-market monitoring is not a substitute for risk assessment, assurance, red-teaming, security testing or an incident response plan. It is the live operational layer that feeds those mechanisms after deployment. An organisation can have good pre-deployment controls and still fail at live monitoring, and the reverse is also true.
It is also not just a regulator-facing exercise. Most of the work happens before any formal notice is sent: detect the issue, preserve evidence, assess severity, mitigate harm, decide whether a legal or contractual threshold has been met, and only then file or update notifications. If teams focus only on what must be reported externally, they often miss hazards, near misses and recurring smaller failures that point to a larger governance problem.
Legal duties remain uneven across jurisdictions and sectors. Outside the EU's cross-sector AI regime and specialist fields such as transport, many reporting models are still sector-specific or voluntary. Even where reporting is mandatory, a report does not by itself prove that AI caused the harm. Reporting systems can be incomplete or noisy, and information sharing must still respect privacy, confidentiality and intellectual property limits. As of June 2026, some EU high-risk implementation timing is still subject to possible legislative adjustment.
What to do next
Start by mapping your role for each deployment: provider, deployer, integrator, distributor, buyer, or systemic-risk model provider. That role map should determine who monitors the system, who decides severity, who has authority to suspend or roll back use, and who notifies regulators or counterparties.
Then put the operating model in writing. You need an incident taxonomy that separates routine defects, hazards, near misses and reportable serious incidents; logging and evidence-retention rules; named escalation owners; a notification matrix covering authorities and counterparties; and contract terms that require suppliers to provide timely notice, technical access and support.
Finally, rehearse the process. A tabletop exercise that starts with a user complaint, a drift signal or a third-party vulnerability and ends with a draft regulator notice is often the fastest way to find missing logs, missing owners and missing contractual rights. Review the whole regime after major model updates, deployment changes or supplier changes.
FAQs
Is post-market monitoring only relevant for generative AI?
No. Any deployed AI can create safety, rights, security or reliability problems in real use. Generative AI adds recurring issues such as confabulation, misuse and third-party model dependency, but the governance logic is wider.
What is the difference between a hazard and an incident?
A hazard is a situation that could plausibly lead to harm. An incident is where the development, use or malfunction of AI has already led, directly or indirectly, to covered harm. Mature teams track both.
Does every model error need to be reported to an authority?
No. Most errors stay inside normal quality or security processes. External reporting is usually reserved for serious events that meet a legal or contractual threshold.
Who reports when the provider and deployer are different organisations?
It depends on the regime. Under the EU AI Act, the provider usually has the formal authority-reporting duty for high-risk systems, while the deployer must monitor use and immediately alert the provider and authority if it identifies a serious incident or risk.
What evidence should we keep?
At minimum, keep monitoring plans, logs under your control, version and change records, user and operator feedback, incident triage decisions, corrective actions, and communications with counterparties or authorities.
Can voluntary reporting frameworks replace hard-law duties?
No. Frameworks such as the Hiroshima AI Reporting Framework can improve comparability and trust, but they complement rather than replace statutory notification duties.
Why is this linked to contracts?
Because incidents often involve suppliers, hosted models, data providers and integrators. Without notice clauses, access rights and agreed responsibilities, an organisation may not be able to investigate quickly enough or meet reporting deadlines.
Are the EU high-risk reporting deadlines already live?
The separate reporting duty for providers of general-purpose AI models with systemic risk already applies. Most high-risk AI system obligations are scheduled for 2 August 2026 under the published text, but a provisional political agreement to defer several of these dates was reached in May 2026 under the Digital Omnibus, so treat that date as not yet final.
Sources
Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (European Union). Core legal definitions of "serious incident", provider post-market monitoring duties, deployer monitoring and logging duties, GPAI systemic-risk reporting duty, deadlines, investigations, and enforcement flow under the EU AI Act.
Navigating the AI Act (European Commission). Current Commission explanation of who must monitor and report under the AI Act, applicability dates, governance structure, and the note that a proposal to adjust high-risk timing is under consideration.
Artificial Intelligence Risk Management Framework (AI RMF 1.0) (National Institute of Standards and Technology). The standards-based governance logic for post-deployment monitoring, incident response, recovery, communication and documentation in the MANAGE function.
Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (National Institute of Standards and Technology). Detailed operational practices for generative AI, including incident monitoring, after-action review, near-miss tracking, legal and regulatory escalation, third-party monitoring, and vendor contract considerations.
Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems (Ministry of Foreign Affairs of Japan). Voluntary commitments to monitor vulnerabilities, incidents, emerging risks and misuse after deployment, document incidents, support responsible disclosure, publish transparency reports, and share relevant information with authorities.
Hiroshima AI Reporting Framework (Organisation for Economic Co-operation and Development). The practical structure of the Hiroshima reporting process, its public and rolling submission model, its scope across the AI value chain, and the fact that the first round produced 25 reports.
Towards a Common Reporting Framework for AI Incidents (Organisation for Economic Co-operation and Development). Interoperable definitions of AI incidents and hazards, and the OECD view that a common framework can support both mandatory and voluntary incident reporting across jurisdictions.
Standing General Order on Crash Reporting (U.S. Department of Transportation, National Highway Traffic Safety Administration). A current sector-specific example of mandatory post-market incident reporting for automated driving systems and Level 2 advanced driver assistance systems.