EU AI Act monitoring: from signal to decision

Articles 72 and 73 concern high-risk AI systems. Before monitoring is designed, the system, classification route, role of each entity and any applicable transitional or sector-specific rules must therefore be established.

Regulation (EU) 2026/1744 postponed the application of Chapter III, Sections 1 to 3 to 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and to 2 August 2028 for those covered by Article 6(1) and Annex I. The Commission must issue guidance, including a post-market monitoring plan template, by 2 September 2027.

2 December 2027

Article 6(2) · high-risk systems listed in Annex III

2 August 2028

Article 6(1) · high-risk systems linked to Annex I

2 September 2027

Commission guidance on the monitoring plan

Article 72 places the post-market monitoring system with the provider. Article 26 requires the deployer to monitor operation of the high-risk system on the basis of the instructions for use and to inform the prescribed parties when a risk or incident emerges.

The chain must be settled before an incident: signals transmitted, internal deadline, accessible data, on-call contact, suspension authority and route to the authority. Shared responsibility without explicit allocation becomes an unowned responsibility.

Provider · Article 72

Establish and document a proportionate system; actively collect and analyse relevant lifecycle data.

Deployer · Article 26

Monitor according to instructions; suspend use and inform without undue delay when a risk is identified.

Operational interface

Name who qualifies, protects the service, reports and authorises any resumption.

Drift only exists relative to a baseline. It describes the system actually authorised, its operating conditions and accepted limits. Every measure, complaint, correction or decision must lead back to this identifier.

• System — model, rules, prompts, tools and external components
• Data — sources, schemas, periods, populations and transformations
• Execution — infrastructure, parameters, interfaces and dependencies
• Use — intended purpose, users, exposed people and context
• Controls — thresholds, human oversight, abstention and fallback
• Acceptance — performance, limitations, residual risk and signatory

The plan is not a list of metrics. It explains how an observation becomes a reproducible decision. Each signal combines a scope, measurement window, method, threshold, owner and predetermined action.

Useful signals depend on purpose and risk: overall and subgroup performance, changing inputs, abstentions, bypassed oversight, unavailability, complaints, security, use outside intended purpose or interaction with another AI system.

• Baseline — specify the version and approved limit
• Observation — measure over a defined population and window
• Qualification — distinguish variation, drift, risk and incident
• Authority — assign continuation, restriction or suspension
• Evidence — retain the signal, analysis, action and timestamp

Under Article 3(49), a serious incident is an incident or malfunction that directly or indirectly leads to one of the four outcomes below. A technical anomaly is therefore not automatically a serious incident; it must still remain traceable if it may affect risk or compliance.

• Health — death or serious harm to a person’s health
• Infrastructure — serious and irreversible disruption to the management or operation of critical infrastructure
• Fundamental rights — infringement of Union-law obligations intended to protect them
• Property or environment — serious harm to property or the environment

No later than 15 days

General rule, after a causal link or its reasonable likelihood is established; reporting is immediate.

No later than 2 days

Widespread infringement or serious, irreversible critical-infrastructure disruption; reporting is immediate.

No later than 10 days

Death, once a causal relationship is established or suspected; reporting is immediate.

The investigation must not depend on late reconstruction. One register preserves the order of events, affected versions and decisions, without altering the system in a way that could compromise evaluation of the causes before the authority is informed.

• Detect — timestamp the signal and identify its source
• Preserve — freeze relevant logs, versions, inputs and outputs
• Contain — protect people and restrict or suspend use
• Qualify — assess extent, severity and causal link
• Inform — activate the provider, deployer and authority route
• Correct — analyse the cause and record the selected action
• Resume — submit the test and residual risk to the authorised decision-maker

Corrective action is not closed because it has been marked complete. The control is replayed on the corrected version under the conditions that exposed the issue, then side effects and residual risk are submitted to the designated authority.

Same phenomenon

The test covers the signal or failure that triggered the action.

Corrected version

The result is tied to an identified, reproducible configuration.

Non-regression

Critical functions that were not at issue are also replayed.

Signed decision

Continuation, restriction or resumption is assigned with the residual risk.

The record must allow someone who did not experience the event to understand what was observed, why a decision was made and which version it concerns. Every item is dated, assigned and linked to the evidence chain.

• Plan — purpose, scope, sources, indicators and frequency
• Baselines — successive configurations and acceptance decisions
• Register — signals, changes, complaints, risks and incidents
• Escalation — roles, contacts, internal deadlines and authorities
• Investigations — causality, containment and corrective actions
• Closures — tests, non-regression, residual risk and authorisation