Module 8 — After the Market: Post-Market Monitoring and Serious Incidents

Module 8 of the AI Act Provider certification: the Art. 72 post-market monitoring system and plan, Art. 73 serious incident reporting and its deadlines, corrective action under Art. 20, and how substantial modification reopens everything.

The obligations do not end at market placement; in an important sense they begin there. Art. 9 requires the risk management system to take an input from post-market data, which means the loop only closes when the system is retired.

Art. 72 — the post-market monitoring system

Providers shall establish and document a post-market monitoring system proportionate to the nature of the AI technologies and the risks of the high-risk system.

The system shall actively and systematically collect, document and analyse relevant data, which may be provided by deployers or collected through other sources, on the performance of high-risk AI systems throughout their lifetime, and shall allow the provider to evaluate the continuous compliance of systems with the Chapter III Section 2 requirements.

Where relevant, post-market monitoring shall include an analysis of the interaction with other AI systems.

The system shall be based on a post-market monitoring plan, which forms part of the technical documentation referred to in Annex IV — element 9. It is therefore not an operational document produced later; it is written before the system goes to market and assessed with the rest of the file.

Three design questions decide whether the plan is real:

Where does the data come from? Deployers hold the operational signal. Getting it requires a contractual route and a practical channel, and neither appears by itself. This is the mirror image of the deployer's Art. 26(5) duty to inform you.

What is compared against what? The plan should name the declared performance from the Art. 13 instructions as the baseline, and describe what deviation looks like. Monitoring without a stated baseline generates data and no conclusions.

What triggers what? Deviation thresholds should map to actions: investigate, notify, correct under Art. 20, or reassess conformity. A plan with no trigger table is a promise to look.

Art. 73 — serious incident reporting

Providers of high-risk systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred.

What is a serious incident. Defined by consequence: an incident or malfunctioning of an AI system that directly or indirectly leads to the death of a person or serious harm to a person's health; a serious and irreversible disruption of the management or operation of critical infrastructure; the infringement of obligations under Union law intended to protect fundamental rights; or serious harm to property or the environment.

Note the third limb. An incident need involve no physical harm at all — a systematic infringement of a fundamental-rights protection is a serious incident, which puts discriminatory output squarely inside the reporting regime.

Deadlines. The report shall be made immediately after the provider has established a causal link between the AI system and the serious incident, or the reasonable likelihood of such a link, and in any event not later than 15 days after the provider — or, where applicable, the deployer — becomes aware of the serious incident.

Shorter periods apply to the gravest categories: in the event of a widespread infringement or a serious and irreversible disruption of critical infrastructure, and in the event of the death of a person, the report is required considerably sooner. Where the causal link has not yet been established, the provider still reports within the applicable deadline — an initial report is not deferred pending investigation.

After reporting. Following the report of a serious incident, the provider shall without delay perform the necessary investigations, including a risk assessment of the incident and corrective action. It shall cooperate with the competent authorities and, where relevant, with the notified body, and shall not perform any investigation which involves altering the system in a way which may affect any subsequent evaluation of the causes before informing the authorities.

That last constraint catches engineering teams by reflex: the instinct on discovering a defect is to fix it immediately, and here fixing it first can destroy the evidence the authority needs.

Where the deployer sees it first. The deployer's Art. 26(5) duty — suspend, inform the provider or distributor and the market surveillance authority — is in practice what starts your clock. A provider with no channel for that information will miss deadlines it never knew were running.

Art. 20 — corrective action

Providers who consider or have reason to consider that a high-risk system they have placed on the market or put into service is not in conformity shall immediately take the necessary corrective actions to bring it into conformity, withdraw it, disable it or recall it, as appropriate, and shall inform the distributors of the system concerned and, where applicable, the deployers, the authorised representative and importers accordingly.

Where the system presents a risk within the meaning of Art. 79(1) and the provider becomes aware of it, it shall immediately investigate the causes, in collaboration with the reporting deployer where applicable, and inform the market surveillance authorities and, where applicable, the notified body, of the nature of the non-compliance and of any relevant corrective action taken.

The threshold is "considers or has reason to consider", the same low bar the deployer works to under Art. 26(5). Waiting for certainty is not the standard.

Substantial modification reopens the file

When post-market monitoring produces a change, ask immediately whether the change is a substantial modification: a change not foreseen or planned in the initial conformity assessment which affects compliance with the Chapter III Section 2 requirements, or which results in a modification to the intended purpose.

If it is, Art. 43 requires a new conformity assessment, and the consequences cascade: an updated Annex IV file, a new declaration of conformity, a database update, and — if the system's classification itself changed — potentially a different assessment route.

If the change was pre-determined at the initial conformity assessment and documented in the technical documentation, it is not a substantial modification. That is the entire commercial argument for declaring your update and continuous-learning behaviour up front, and it is worth engineering effort to keep as much routine change as possible inside the declared envelope.

The loop, stated once

Art. 9 identifies risks and requires review over the lifecycle. Art. 72 collects the field data that Art. 9(2)(c) feeds on. Art. 73 escalates the worst of it to authorities. Art. 20 acts on non-conformity. Art. 43 reassesses when the response amounts to a substantial modification. Art. 11 keeps the file current throughout, and Art. 18 holds it for ten years.

A provider organisation that treats those as six separate obligations owned by six teams will discover the gaps between them at the worst moment. A provider that treats them as one loop with named owners at each handover will not.

Check yourself

1. We will build the post-market monitoring plan after launch. — It is element 9 of Annex IV and is assessed with the technical documentation, so it exists before market placement.
2. No one was physically harmed, so it is not a serious incident. — The definition includes infringement of Union law obligations intended to protect fundamental rights. Discriminatory output can qualify.
3. We found the defect and patched it, then reported. — Art. 73 prohibits investigation that alters the system in a way that may affect subsequent evaluation of the causes before informing the authorities.
4. Our weekly model refresh triggers reassessment every week. — Not if the change was pre-determined at the initial conformity assessment and documented in the technical documentation.

Previous: Module 7 — Conformity, declaration, marking, registration

You have completed the eight modules. Together they cover Chapter III from the seat of the organisation that builds and places the system — sit the Provider examination →