AI Post-Market Monitoring Plan Template (EU AI Act Article 72)

Post-market monitoring plan for a high-risk AI system: data collection, thresholds, reviews, Article 73 incident reporting

AI・データ標準Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, Articles 72 and 73post market monitoring math更新 2026/10/20

エディタで開く.mdをダウンロード

使い方: Use it as the provider of a high-risk AI system; the plan is part of the Annex IV technical documentation. Define metrics and action thresholds tied to declared performance first, and rehearse the serious incident workflow. The main pitfall is missing the 2, 10 and 15 day reporting deadlines because triage has no owner.

プレビュー

Post-Market Monitoring Plan: [High-risk AI system] [version]

Post-market monitoring plan for a high-risk AI system, organised on Article 72 (post-market monitoring) and Article 73 (reporting of serious incidents) of the EU Artificial Intelligence Act, Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI). The plan forms part of the technical documentation under Annex IV. Under the amended Article 113, the high-risk requirements apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems; check the consolidated text. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice.

Field	Value
Document ID	[PMM-PLAN-001]
AI system and version	[Name] [version]
Annex III / Annex I category	[Example: Annex III point 4(a): recruitment and selection]
Provider	[Legal name]
Plan version	[0.1]
Status	[Draft / Approved / Superseded]
Plan owner	[@pmm-owner]
Quality management system reference	[QMS procedure ID]
Last updated	YYYY-MM-DD
Next review	YYYY-MM-DD

1. Scope and objectives

Item	Value
System versions covered	Example: 3.x placed on the market from YYYY-MM-DD
Markets	Example: All EU Member States
Deployers	Example: 37 employer organisations under contract
Integration with other regimes	[None / Integrated into [product legislation] monitoring / financial services governance]
Interaction with other AI systems	Example: Receives CV parsing output from a third-party system; analysed in 3.4

Objectives: [Example: confirm that the system continues to meet the requirements for high-risk systems in Chapter III Section 2 (accuracy, robustness, cybersecurity, human oversight, risk management) in real use; detect emerging risks, misuse and drift early; feed findings into the risk management system and corrective actions.]

2. Responsibilities

Role	Responsibility	Person or team
Plan owner	Maintains plan, chairs monitoring review	[@name]
Data and ML team	Collects telemetry, computes metrics	[@team]
Quality and regulatory	Assesses incidents, files reports	[@name]
Customer success	Collects deployer feedback	[@team]
Deployers	Monitor operation under instructions for use; inform the provider of risks and serious incidents (Article 26)	Contract clause [x]
Management	Approves corrective actions with significant impact	[@name]

3. Data collection

3.1 Performance data

Source	Data	Method	Frequency
Example: Production logs (Article 12 logging)	Inputs metadata, scores, overrides, latency	Automated export	Daily
Example: Outcome labels from deployers	Hiring decisions 6 months later	Quarterly data request	Quarterly
Example: Ground-truth audit sample	300 cases re-scored by experts	Manual	Quarterly

3.2 Incidents and complaints

Source	Data	Method
Example: Deployer incident reports	Malfunctions, harms, near misses	Support portal form, 24/7
Example: Complaints from affected persons forwarded by deployers	Description, outcome	Portal
Example: Security reports	Vulnerabilities	Disclosure programme

3.3 User feedback

[Example: quarterly survey of deployer recruiters (usability, trust, override reasons); free-text feedback in the interface reviewed weekly.]

3.4 External sources

[Example: market surveillance authority notices, published research on similar systems, media reports, changes in the third-party CV parser release notes.]

4. Metrics and thresholds

ID	Metric	Declared / baseline	Alert threshold	Action threshold
PM-01	Example: Ranking accuracy (NDCG@10 on audit sample)	0.78	< 0.74	< 0.70
PM-02	Example: Selection rate ratio by sex	>= 0.90	< 0.85	< 0.80
PM-03	Example: Selection rate ratio by age band	>= 0.90	< 0.85	< 0.80
PM-04	Example: Human override rate	8% to 20%	Outside 5% to 25%	Outside 3% to 35%
PM-05	Example: Input drift (population stability index)	< 0.1	> 0.2	> 0.3
PM-06	Example: Complaints per 10,000 assessments	1.2	> 3	> 6
PM-07	Example: Availability	99.5%	< 99.0% monthly	< 98%

Selection rate ratio for group $g$ relative to the group with the highest rate:

\text{SRR}_g = \frac{\text{selected}_g / \text{assessed}_g}{\max_h \left(\text{selected}_h / \text{assessed}_h\right)}

5. Analysis and review cadence

Activity	Frequency	Participants	Output
Automated dashboard check	Daily	Data and ML team	Alerts
Metric review	Monthly	Plan owner, ML, quality	Monitoring report
Fairness and drift deep dive	Quarterly	Plus external reviewer	Quarterly report
Management review	Annually	Management, quality	Plan update, risk management input

6. Serious incident reporting (Article 73)

6.1 Timelines

Situation	Latest report after becoming aware
Serious incident (general rule)	Immediately after establishing a causal link or reasonable likelihood of one, and no later than 15 days
Widespread infringement, or serious and irreversible disruption of critical infrastructure	Immediately, no later than 2 days
Death of a person	Immediately after establishing or suspecting a causal link, no later than 10 days

An incomplete initial report may be submitted first, followed by a complete report. Systems under the competence of the AI Office report to the AI Office instead (Article 75(1a) as amended).

6.2 Workflow

Step	Owner	Target
Triage and classification against Article 3(49)	Quality and regulatory	24 h
Preserve evidence: logs, model version, inputs; do not alter the system in a way that affects analysis of causes before informing the authority	ML team	Immediately
Initial report to market surveillance authority	Quality and regulatory	Within the timelines in 6.1
Investigation including risk assessment and corrective action; cooperate with authorities and notified body where relevant	Plan owner	[30] days
Inform affected deployers	Customer success	48 h

7. Corrective actions

Trigger	Possible actions	Decision by
Alert threshold	Investigation, increased sampling	Plan owner
Action threshold	Retraining, threshold change, deployer guidance update	Plan owner and management
Serious incident or non-conformity	Suspend feature, withdraw or recall, inform deployers and authorities (Article 20)	Management

Every corrective action records the cause, the change, the re-validation evidence and the date the related risk register entry was updated.

8. Documentation and records

Record	Location	Retention
Monitoring reports	[QMS repository]	[10 years after placing on market]
Incident files and authority correspondence	[Repository]	[10 years]
Metric data and audit samples	[Data platform]	[Per data retention policy]
Plan versions	[Technical documentation]	[10 years]

9. Plan review

The plan is reviewed [annually] and when: a substantial modification is made; a serious incident occurs; metrics show a new risk; the Commission guidance and template under Article 72(3) are published; or the Regulation or harmonised standards change.

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	First draft
1.0	YYYY-MM-DD	[@name]	Example: Approved with technical documentation

Standard and licence note

Based on Regulation (EU) 2024/1689 (the Artificial Intelligence Act) as amended by Regulation (EU) 2026/1744 (Digital Omnibus on AI), Articles 72 and 73 with references to Articles 3(49), 20, 26 and 75; EU legislative texts are free to reuse. The requirements are summarised in original wording and no text of the Regulation is reproduced. Check the consolidated text on EUR-Lex and current Commission guidance. This is a documentation format, not legal advice. Template licence: MIT.