# 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.

<!--
Guidance: How to use this template
- The provider owns this plan. Monitoring must be proportionate to the
  nature of the AI technology and the risks of the system, and must
  actively and systematically collect, document and analyse data on
  performance over the system's lifetime.
- The amended Article 72(3) asks the Commission to adopt guidance,
  including a template for this plan, by 2 September 2027. When it is
  published, map this plan onto it.
- If the system falls under Annex I Section A product legislation, or is
  an Annex III point 5 system of a regulated financial institution, you
  may integrate this plan into existing monitoring systems if protection
  is equivalent. Say so in section 1.
- Keep section 6 (serious incidents) rehearsed: the reporting clocks are
  short and start when you become aware of the incident.
- Link to [AI Act technical documentation (Annex IV)], [AI risk
  assessment] and [Incident response plan].
-->

| 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

<!-- Guidance: Define which system versions, markets and deployers the plan covers and what it must show. -->

| 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

<!-- Guidance: Name who collects, analyses, decides and reports. Include deployers' role. -->

| 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

<!-- Guidance: List every data source, what is collected, how, how often and under what legal basis. Data from law-enforcement deployers' sensitive operational data is excluded from Article 72 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

<!-- Guidance: Define metrics tied to the declared accuracy and risk controls, with thresholds that trigger action. -->

| 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

<!-- Guidance: State how often each analysis happens, who attends and what records are kept. -->

| 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)

<!-- Guidance: A serious incident is an incident or malfunction that directly or indirectly leads to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of Union law obligations protecting fundamental rights, or serious harm to property or the environment (Article 3(49)). Report to the market surveillance authority of the Member State where it occurred. -->

### 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

```mermaid
flowchart LR
  A["Report received"] --> B["Triage within 24 h"]
  B --> C{"Serious incident?"}
  C -- no --> D["Log, analyse in monthly review"]
  C -- yes --> E["Start clock, notify management"]
  E --> F["Initial report to authority"]
  F --> G["Investigation and risk assessment"]
  G --> H["Corrective action"]
  H --> I["Complete report"]
```

| 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

<!-- Guidance: Define the range of actions, who decides, and how effectiveness is verified. -->

| 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

<!-- Guidance: List the records kept and for how long. -->

| 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

<!-- Guidance: State when the plan itself is reviewed and what triggers an update. -->

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.