Post-market monitoring, serious incidents, and audit readiness

Lesson 5 of 5 in Conformity Assessment, Standards, CE Marking, and Post-Market Duties.

The CE mark is the starting gun, not the finish line. Article 72 requires every provider of a high-risk system to run a post-market monitoring system proportionate to the risks: actively and systematically collecting and analysing performance data throughout the system’s lifetime — from deployers, from logs, from users — to verify continuing compliance with Articles 8–15. The plan sits inside the technical documentation (Annex IV section 9), follows a Commission template, and can integrate with sectoral post-market regimes (an MDR manufacturer extends its existing vigilance system rather than building a second one).

Why so insistent? Because everything you learned in foundations about drift applies with legal force here: a model that was conformant at assessment can silently stop being conformant as the world moves. Monitoring is how the Act converts that statistical fact into a legal duty — and its findings feed straight into Article 20 corrective actions and, when things go badly, Article 73.

Article 73 attaches deadlines to that definition, and the clocks are graduated by severity. Providers report to the market surveillance authority of the Member State where the incident occurred:

15 days — the general rule: report immediately after establishing a causal link (or its reasonable likelihood) between system and incident, and no later than 15 days after the provider (or deployer, who must inform the provider) becomes aware.
10 days — where the incident is the death of a person: immediately after establishing or suspecting the causal link, and no later than 10 days after awareness.
2 days — for a widespread infringement or a serious and irreversible disruption of critical infrastructure: no later than 2 days after awareness. These are the incidents whose blast radius grows by the hour.

Where needed, the provider may file an initial incomplete report followed by a complete one — the clock rewards speed over polish. Every report triggers a duty to investigate, assess risk, and take corrective action, without altering the system in a way that would compromise the later evaluation before informing the authority. And there is a sectoral carve-out: for high-risk systems already under equivalent reporting regimes (medical devices under the MDR, for instance), Article 73 narrows to fundamental-rights infringements — the one category the sectoral law does not watch.

Interactive sorting exercise: You run incident response for a high-risk AI provider. For each event, start the correct Article 73 reporting clock — or recognise that none applies.

Last piece: audit readiness. Market surveillance authorities (Art 74) can demand full access to documentation, training/validation/testing datasets, and — through APIs or other appropriate means — the system itself. Source code is reachable only on a reasoned request and only when two conditions are both met: access is necessary to assess conformity with Chapter III Section 2, and testing and audit procedures based on data and documentation have been exhausted or proved insufficient (Art 74(13)).

The professional consequence: build the evidence pack so the second condition is never met. If your Annex IV file, logs, and test records answer every conformity question, code access stays off the table. The provider who documents poorly is the provider who ends up handing over source code.

Tool: AI Incident Tabletop — Run the clocks under pressure: classify a live incident, pick the right deadline, and draft the initial report before time expires.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.