Module 8 — The Operating Cadence

Module 8 of AI Risk Management Pro: the Art. 72 post-market monitoring plan, serious incident reporting deadlines under Art. 73, what a substantial modification reopens under Art. 43(4), and the review calendar that holds the programme together.

A programme is finished when it stops being a project and becomes a calendar. Everything in the preceding seven modules is a snapshot; this module is about the loop that keeps the snapshots true, and about the two events — an incident and a substantial modification — that make the loop visible to someone outside the organisation.

Art. 72: the monitoring plan is a required artefact

Art. 72(1) requires providers to establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk system. Art. 72(2): 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 systems throughout their lifetime, and shall allow the provider to evaluate continuous compliance with the Chapter III requirements.

Art. 72(3) is the one to note operationally: the post-market monitoring system shall be based on a post-market monitoring plan, and that plan shall be part of the Annex IV technical documentation. So it is not an internal practice — it is a document, inside the file, which the readiness review in Module 7 tests.

What makes a plan operable rather than decorative is that its metrics are the ones that would move the register. Design it backwards from Module 3:

Each needs a threshold and an owner, because Art. 9(2)(c) requires the register to be evaluated against post-market data — and a metric with no threshold produces a dashboard nobody acts on. The threshold is what converts monitoring into a register event.

For providers of high-risk systems already covered by sectoral Union law with equivalent post-market obligations, Art. 72(5) allows integration, in the same spirit as Art. 17(3).

Art. 73: incidents, and the clock

Art. 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to any of: 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; infringement of obligations under Union law intended to protect fundamental rights; or serious harm to property or the environment.

Art. 73(1): 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 the incident occurred.

The deadlines, which are worth committing to memory because they are short and asymmetric:

Two provisions make the clock survivable. Art. 73(5): where necessary to ensure timely reporting, an initial, incomplete report may be submitted, followed by a complete one. And Art. 73(6): following a report, the provider shall without delay perform the necessary investigations, including a risk assessment of the incident and corrective action — without altering the system in a way that may affect the subsequent evaluation of the causes before informing the authorities.

That last clause is the one engineering teams break by instinct. The reflex after an incident is to ship a fix. Do not alter the system in a way that affects the evaluation of causes before informing the authorities. Write it into the incident runbook, because it contradicts every other operational habit.

Note also the interaction with the deadline: the 15 days (or 2, or 10) run from becoming aware of the incident, not from establishing the causal link. An organisation that spends three weeks determining whether the system caused the harm has already missed the deadline. The initial incomplete report in Art. 73(5) is the mechanism designed for exactly that situation.

Deployers are not exempt. Art. 26(5) requires monitoring per the instructions, informing the provider where relevant, and — where there is reason to consider that compliant use may nonetheless present an Art. 79(1) risk — informing the provider or distributor and the relevant market surveillance authority without undue delay, and suspending use. Art. 73 reporting also reaches deployers who identify a serious incident. A deployer runbook that routes everything to the vendor and stops there is incomplete.

And under Art. 26(5) read with the GDPR interplay: where the incident involves personal data, the GDPR 72-hour breach clock may run in parallel on a different trigger. The two timelines are independent and both can apply.

Substantial modification: what reopens, and what does not

Art. 3(23) defines a substantial modification as a change after placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment by the provider, and as a result of which either compliance with the Chapter III requirements is affected, or the intended purpose for which the system was assessed is modified.

The consequence is in Art. 43(4): a substantially modified system shall undergo a new conformity assessment, regardless of whether the modified system is intended to be further distributed.

The asymmetry this creates is the most useful planning insight in the module. Changes you document in advance are cheap; changes you do not are expensive. Annex IV element 2(f) asks for a description of predetermined changes to the system and its performance, with the technical solutions adopted to ensure continuing compliance. A retraining cadence, a threshold recalibration policy, or a planned expansion of input features — described in element 2(f) at assessment time — are foreseen, and do not reopen the assessment. The same changes undocumented are candidates for a full reassessment.

So the practical rule: write the change envelope into element 2(f) while writing the file. It costs a paragraph and buys the ability to operate the system.

Art. 25(1)(b) is the mirror image for deployers: making a substantial modification to a high-risk system makes the deployer its provider, with the whole of Chapter III attaching. Module 2's trigger list exists for this.

The calendar

This is the deliverable of the module. Put it in one place with named owners, and the programme survives personnel changes.

Monthly

• Monitoring metrics against thresholds; any breach opens a register row.
• Open register rows with mitigation in flight.
• Incident log review, including near-misses that did not meet the Art. 3(49) threshold.

Quarterly

• Full register review per high-risk system against monitoring data (Art. 9(2)(c), Art. 9(4)).
• Inventory re-sweep for new or newly AI-enabled systems (Module 2).
• Annex IV file currency check: any element whose evidence is older than the last system change.
• Literacy register recompute and coverage figure (Art. 4).

Annually

• Readiness review, the four tests from Module 7.
• Risk scale and tolerance band revalidation.
• QMS procedure review (Art. 17), ownership and accountability framework.
• Supplier evidence refresh for material vendors.

On trigger

• Procurement or renewal → classification (Module 2).
• Retraining, fine-tuning, feature change → substantial-modification assessment against element 2(f).
• Intended-purpose change → reclassification and Art. 25 check.
• Incident → report on the Art. 73 clock, investigate, register change, and a file update under Annex IV element 6.
• Regulatory change → re-screen. The 2 December 2026 Art. 5 addition is the next scheduled one.

The deadline map as it now stands

Keep this visible, because a large share of published material still carries the pre-Omnibus dates:

Regulation (EU) 2026/1744 — the Digital Omnibus, in force 27 July 2026 — is what moved the high-risk dates and rewrote Art. 4. A programme plan citing August 2026 for Annex III obligations is working from a superseded timetable.

Check yourself

1. We have 15 days to report any serious incident. — Not always. Two days for a widespread infringement or an Art. 3(49)(b) critical-infrastructure disruption; ten days where a person has died.
2. We fixed the system immediately after the incident, then reported. — Art. 73(6) prohibits altering the system in a way that may affect the evaluation of causes before informing the authorities.
3. Retraining the model monthly means a new conformity assessment every month. — Not if it is described as a predetermined change in Annex IV element 2(f). That paragraph is the cheapest thing in the file.
4. Post-market monitoring is an internal practice. — It is a plan, and the plan is part of the Annex IV documentation (Art. 72(3)).

You have finished the eight modules. The examination is twenty-five questions drawn from a bank of 104, stratified across all eight modules, graded on our server, 70% to pass.

Sit the AI Risk Management Pro examination →