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-risk 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 data. A system that was compliant at deployment may become non-compliant through performance degradation.

Components of a compliant monitoring programme

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 documentation, 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?