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 — carrying 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-riskriskIn the EU AI Act's terms, the combination of the probability 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 → 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 → on the basis of the instructions for use and, where relevant, inform providers of any serious incidents or malfunctioning." This creates a continuing obligation that persists throughout the operational life of the AI system.

The rationale is compelling: AI system performance can degrade over time as the real-world data environment changes (data drift), 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 providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name — carrying manufacturer-style duties: design controls, documentation, conformity.Open full entry →'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 rate, 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 risk 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 — e.g. 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, labelling 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?