Ongoing operations
Post-market monitoring
Compliance does not end at deployment. Article 72 requires providers of high-risk AI systems to establish and document a post-market monitoring system proportionate to the nature and risks of the system, running for its entire lifetime.
Transcript
Compliance does not end when a system goes live. The AI Act's Article 72 requires providers of high-risk AI systems to run a post-market monitoring system for the whole life of the system.
The reason is drift. The population a model was trained on shifts, the environment changes, and a system that was accurate at launch can degrade without a single line of code changing.
The AI Act's Article 72 requires a documented monitoring plan that forms part of the technical documentation: what you measure, how often, and what threshold triggers action.
Recording an observation against the system: pick its type, performance change, user feedback, incident, or audit, then a dated, attributable measurement. The summary counts above update by type as entries come in.
This is also what makes the AI Act's Article 9 workable. Risk management is defined there as a continuous iterative process, and a continuous process needs an input. Monitoring is that input.
Where monitoring shows the system no longer conforms, the next entry gets logged as an Incident instead, its own type in this same timeline. The AI Act's Article 20 requires immediate corrective action and notification of your distributors, deployers and authorities. Monitoring that never changes anything is not monitoring.
Why this is required
AI systems drift. The population they were trained on shifts, the environment they operate in changes, and adversaries adapt. A model that was accurate and fair at launch can degrade materially without a single line of code changing, which is why a point-in-time assessment cannot discharge an ongoing duty.
Article 72 requires you to actively and systematically collect, document and analyse relevant data on the system's performance throughout its lifetime, based on a post-market monitoring plan that forms part of the technical documentation.
This is also what makes Article 9 workable. Risk management is defined there as a continuous iterative process planned and run across the entire lifecycle, and a continuous process needs an input. Monitoring is that input; without it, Article 9 compliance is a document rather than a practice.
Article 20 closes the loop: where a provider considers that a high-risk system it has placed on the market is not in conformity, it must immediately take the necessary corrective action to bring it into conformity, withdraw it, disable it or recall it, and inform distributors, deployers, authorised representatives and importers.
Deployers have a parallel duty under Article 26(5): monitor the operation of the system in accordance with the instructions for use, and inform the provider where use may present a risk.
What EuroCompliant does
Monitoring records attach to each system: performance observations, accuracy measurements, user feedback, audits and reviews, each dated and attributable.
Monitoring data feeds the system's risk management record, so the AI Act's Article 9 iteration has evidence behind it rather than a periodic assertion that nothing has changed.
Automated scans can be run against systems on a recurring basis to supply objective measurements rather than relying entirely on human observation.
Walking through it
Write the monitoring plan
The AI Act's Article 72 requires a plan, and it belongs in the technical documentation. Define what you measure, how often, and what threshold triggers action.
Open /operations →Record observations against the system
Performance, accuracy, incidents, complaints and user feedback. Undated observations are not evidence.
Schedule automated testing
Bias, robustness and data-leakage scans give you measurements rather than impressions.
Open /scans →Act on what monitoring shows
Where the system no longer conforms, the AI Act's Article 20 requires corrective action and notification of your distributors, deployers and authorities. Monitoring that never changes anything is not monitoring.
The law
Post-market monitoring
Providers must establish and document a post-market monitoring system proportionate to the risks, actively collecting and analysing performance data across the system's lifetime.
Risk management system
A continuous iterative process run and updated across the entire lifecycle.
Corrective actions
Immediate corrective action, withdrawal, disabling or recall where a system is not in conformity, with notification of the supply chain.
Deployer monitoring
Deployers must monitor operation per the instructions for use and inform the provider where use may present a risk.
Frequently asked
How often do we need to monitor?
Article 72 says proportionate to the nature and risks of the system rather than setting a fixed interval. A credit scoring model affecting thousands of people monthly warrants a very different cadence from a low-volume internal tool. Whatever you choose, write it into the plan and follow it.
We are a deployer, not a provider. Does Article 72 apply?
Article 72 is a provider duty, but Article 26(5) requires deployers to monitor operation per the instructions for use and to inform the provider and market surveillance authority where they identify a risk or a serious incident. In practice you need monitoring either way.
Related guides
Serious incident reporting
The Article 73 duty when a high-risk AI system causes serious harm, with deadlines that tighten to two days in the worst cases.
Automated Scanning: Continuous Telemetry and Scan Pipelines
How scheduled scan jobs, 12 scan engines and local PII scrubbing produce dated Article 10/15 evidence without moving data outside the EEA.
Compliance checklists
How Articles 9 to 15 become tracked, owned, evidenced work rather than a document nobody reads.
Try it on your own systems
Everything in this guide runs in the live product. Start a free trial and follow along with your own data.
Start free trial