Post-market monitoring plan

What it does

It carries assurance past launch. The plan states what evidence will be gathered once the system is in use, from which sources, who reviews it, how often, and what they are empowered to change. It brings together technical measures, complaints, incidents, user feedback and signs of misuse. The system owner owns the plan. It is written before release and operates for as long as the system is in use.

How to implement it

• Write the plan before go-live, scaled to the system's tier.
• List the evidence sources: performance data, complaints, incidents, overrides, feedback and supplier notices.
• Tag complaints and incidents so that those involving the system can be found.
• Set a review cycle and name the reviewers.
• Define the actions available: modify, restrict, retrain, withdraw.
• Feed findings into risk assessment, documentation and incident reporting.

Evidence it operates

Design: a monitoring plan for each system above the threshold. Operation: review records on the planned cycle; collated evidence from each source; a change made, or a system restricted or withdrawn, as a result of a review.

Where it fits

Begins at deployment and continues through operation. It is the primary control for post-market monitoring gap, draws performance evidence from drift and performance monitoring, and passes serious findings to regulatory incident notification. Providers of high-risk systems under the EU AI Act must have such a plan.

Limits

A plan is not monitoring; the reviews have to take place and lead somewhere. Evidence of harm is often held by people who do not know the system was involved, so the plan depends on complaints and incidents being tagged at source. Deployers hold most of the evidence and providers most of the ability to fix, which makes the exchange between them a weak point.