After you meet the EU AI Act's requirements for a system, you still need to watch it in use. Providers of high risk systems must run post-market monitoring, deployers must keep human oversight and monitor operation, and both report serious incidents. Build a routine of metrics, logs, reviews and change triggers, with records you can hand to an authority.
What does the Act expect after launch?
The European Commission's AI Act page sets out the structure. Providers of high risk systems must have a post-market monitoring system in place. Deployers are responsible for human oversight and monitoring. Authorities handle market surveillance, and the page states that providers and deployers will also report serious incidents and malfunctioning. It does not list reporting deadlines, so read the Act's serious incident article for the exact clock before you finalize your procedure.
Dates matter, and they moved. The Commission page, last updated 3 August 2026, lists these: prohibited practices and AI literacy from 2 February 2025, governance and general purpose AI obligations from 2 August 2025, transparency rules from August 2026, high risk rules for Annex III use cases from 2 December 2027, and rules for AI embedded in regulated products from 2 August 2028, after the AI Omnibus changes that entered into force on 27 July 2026. Check the page again when you plan, because timelines can change.
Which obligations apply to you?
First decide your role per system. A provider develops or places a system on the market. A deployer uses it under its own authority. One company can be both for different systems. Then decide the risk category: prohibited, high risk, transparency risk, or minimal. Monitoring duties are heaviest for high risk systems, but AI literacy and transparency duties apply earlier and need upkeep too.
What should a monitoring routine include?
Build five loops.
- Performance and drift: track accuracy and error rates on live data against the thresholds you set at launch, and review them on a fixed schedule. Write down the trigger that sends a system back to review.
- Logging: keep operation logs that let you reconstruct what the system did, store them with access control, and test that you can retrieve them.
- Human oversight: record who oversees each system, what they can override, and sample reviews showing they actually use that power.
- Incidents and complaints: one intake channel, a severity scale that includes harm to people, a named investigator, and a record of corrective actions.
- Change: any new model version, new training data, new use case or new population of users goes through a check that asks whether the risk category or documentation changes.
How do you handle serious incidents?
Prepare before you need it. Write a one page procedure: how staff recognize a serious incident, who decides, who notifies the authority, which facts to collect, and who informs your provider or deployer counterpart. Run a tabletop with a realistic scenario once a year. Keep the exercise notes.
What about general purpose models you buy?
If you build on a third party model, monitor the vendor too. Track version changes, published model documentation, and incidents they disclose. Keep your own tests, because you answer for how the system behaves in your use.
What evidence do you keep?
Keep dated monitoring reports, drift and error dashboards exported on a schedule, log retrieval tests, oversight review samples, incident records, change checks, training records for AI literacy, and an updated inventory showing role and risk category per system. Review the inventory at least quarterly.
What to do
- Confirm each system's role and risk category against the current Act text and timeline.
- Set live metrics and a threshold that triggers review.
- Turn on logging and test retrieval.
- Document human oversight and sample it monthly.
- Write the serious incident procedure from the Act's article and run a tabletop.
- Add a change check to your release process.
- Review vendor model changes quarterly.
- Update the inventory and AI literacy training records on a schedule.
Quick check
Who must run post-market monitoring?
Providers of high risk AI systems, according to the Commission's AI Act page. Deployers have their own duties around oversight and monitoring.
Are the high risk dates fixed?
They have already changed once. The Commission page lists 2 December 2027 for Annex III uses and 2 August 2028 for AI in regulated products, so check it before you plan.
How Safeguard helps automate this
Monitoring is a routine, and routines are where manual effort drains a team. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code rather than by screenshot, and monitoring runs continuously between reviews. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which helps show which AI libraries and model packages are in your builds. The agent can open tested fix pull requests, but it is off by default, every category starts on Manual, and you decide which categories run automatically. Safeguard helps prepare evidence; regulators and notified bodies decide compliance. Book a call.
Sources
Last reviewed: 18 October 2026.
