Operational guide · Articles 26, 72 and 73

EU AI Act monitoring: from signal to decision

Defensible monitoring connects every observation to the live version, an explicit threshold, a decision authority and retained evidence.

On this page
Scope and timeline

Start with the applicable regime, not the dashboard

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
Accountability

Make information flow without confusing the roles

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.
Production baseline

Identify exactly which version is being observed

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
Monitoring plan

Build monitoring that results in a decision

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.

  1. Baseline specify the version and approved limit
  2. Observation measure over a defined population and window
  3. Qualification distinguish variation, drift, risk and incident
  4. Authority assign continuation, restriction or suspension
  5. Evidence retain the signal, analysis, action and timestamp
Serious incident

Qualify the facts before starting the regulatory clock

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.
Incident chronology

Preserve the facts from the first signal to resumption

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.

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

Authorise resumption only after a closure test

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.
Monitoring record

Maintain a record that can be read and challenged

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

In this dossier

Primary sources

Sources this page relies on

Last documentary review: 6 September 2026.

Before you write to us

Frequently asked questions

When do Articles 72 and 73 apply?

Rules for high-risk systems now follow the amended Article 113 timeline: 2 December 2027 for Article 6(2) and Annex III, and 2 August 2028 for Article 6(1) and Annex I. Transitional and sector-specific provisions must be assessed for the system concerned.

Is a dashboard enough for EU AI Act monitoring?

No. Signals must connect to a production baseline, calculation method, threshold, owner and predefined decision when the limit is crossed.

Who reports a serious incident?

The route depends on role and facts. Article 73 addresses reporting by providers; Article 26 also includes deployer information duties. The escalation plan should allocate actions before an incident.

When is corrective action closed?

After correction on an identified version, successful closure testing, documentation of side effects and an explicit decision on residual risk and resumption.

Monitoring review

Does every signal lead to an assigned, evidenced decision?

We examine the live version, monitoring plan, responsibilities, incident route and resumption criteria.

Present the system