Art. 26.5 EU AI Act: post-market monitoring for deployers

Updated: June 2026

Introduction: monitoring as continuous compliance

Art. 26.5 extends the deployerdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry →'s compliance obligation beyond the point of initial deployment. The regulation requires that deployers "monitor the operation of the high-risk AI systemhigh-risk AI systemAn AI system that falls under the EU AI Act's strictest requirements, following Article 6. There are two routes in: a system that is a product or safety component covered by the Union harmonization legislation in Annex I and subject to third-party conformity assessment, or a system used in one of the areas listed in Annex III, such as employment, education, or access to essential services. Article 6(3) contains a filter: an Annex III system is not high-risk if it does not pose a significant risk of harm to health, safety, or fundamental rights, although a system that profiles natural persons is always high-risk. See EU AI Act, Annex III, conformity assessment.Open full entry → on the basis of the instructions for use and, where relevant, inform providersproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry → of any serious incidentsserious incidentAn AI incident causing (or nearly causing) death, serious harm to health, property, fundamental rights or infrastructure. It triggers regulatory reporting duties for high-risk systems.Open full entry → or malfunctioning." This creates a continuing obligation that persists throughout the operational life of the AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs (predictions, content, recommendations or decisions) that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry →.

The rationale is compelling: AI system performance can degrade over time as the real-world data environment changes (data driftdriftThe gradual divergence of an AI system's behavior or performance from its validated state after deployment, without any code change or error. Drift is silent by nature: nothing breaks, accuracy simply decays until someone measures it. Causes are worth separating: a shift in the mix of incoming cases, a change in the source material, a change in surrounding systems, or an update to the underlying model by its provider. See model drift, agent drift.Open full entry →), as usage patterns shift, or as the system encounters edge cases not represented in training datatraining dataThe data used to fit an AI model's parameters; its quality, lawful rights and representativeness are central governance concerns.Open full entry →. A system that was compliant at deployment may become non-compliant through performance degradation.

Components of a compliant monitoring program

1. performance baseline

Before monitoring can be meaningful, you need a performance baseline. At deployment, document: the expected accuracy and error rates from the provider's technical documentationtechnical documentationRecords a provider must compile and keep for a high-risk AI system to demonstrate conformity, covering its design, data, testing, risk management and monitoring.Open full entry →, the demographic distribution of the affected population, and the distribution of input data characteristics. This baseline is what you monitor against.

2. ongoing metrics

Define KPIs that give early warning of performance degradation. Depending on the AI system type, relevant metrics include:

• Overall accuracy rate versus baseline
• False positive and false negative rates (particularly important for high-stakes decisions)
• Demographic parity metrics, are error rates consistent across protected groups?
• Override rateoverride rateThe share of proposals from an AI system that a human reviewer changes or rejects, used as an indicator of whether human oversight is functioning. A structural zero is a reason to investigate rather than a reassurance, because it can mean the system performs well or that the reviewer has stopped examining. It is a signal, not a standalone quality measure. See human oversight, automation bias.Open full entry →, how often do human overseers reverse AI outputs? A rising override rate signals a degrading model
• Input data distribution metrics, are inputs still within the range the model was validated on?

3. monitoring frequency

The monitoring frequency should be proportionate to the riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → level and decision volume. For high-volume, high-stakes systems (e.g. credit scoring processing thousands of applications per day), real-time monitoring dashboards are appropriate. For lower-volume systems, monthly performance reviews may be sufficient.

4. escalation procedures

Define clear thresholds that trigger escalation. What percentage accuracy decline constitutes a "malfunction" requiring notification to the provider under Art. 26.5? What level of demographic disparity requires suspension pending investigation? Document these thresholds in advance.

Obligation to notify the provider

Art. 26.5 specifically requires deployers to inform providers of serious incidents and malfunctioning. This creates a feedback loopfeedback loopA dynamic where a system's own outputs influence its future training data, amplifying initial patterns, for example investigating only flagged claims, then learning from those investigations.Open full entry → back through the supply chainsupply chainThe layered chain behind an AI product (foundation models, datasets, labeling services, integrators), each layer adding risk the buyer never contracted for directly.Open full entry →. In practical terms, deployers should:

• Include incident notification requirements in supplier contracts with defined response time SLAs
• Establish a direct communication channel with the provider's technical team for performance issues
• Document all notifications with timestamps and provider responses

Compliance checklist

1. Is there a documented performance baseline for each high-risk AI system at the point of deployment?
2. Are KPIs defined with specific monitoring thresholds?
3. Is there a monitoring dashboard or regular review process for each high-risk AI system?
4. Are escalation thresholds documented and known to the oversight function?
5. Is there a documented notification procedure for reporting incidents to the provider?
6. Are monitoring results recorded and retained per Art. 26.6?