Art. 26.5 EU AI Act: Post-Market Monitoring for Deployers
Updated: June 2026 — full revision to Validai quality standard
Introduction: Monitoring as Continuous Compliance
Art. 26.5 extends the deployer's compliance obligation beyond the point of initial deployment. The regulation requires that deployers "monitor the operation of the high-risk AI system 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 provider'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 loop back through the supply chain. 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
- Is there a documented performance baseline for each high-risk AI system at the point of deployment?
- Are KPIs defined with specific monitoring thresholds?
- Is there a monitoring dashboard or regular review process for each high-risk AI system?
- Are escalation thresholds documented and known to the oversight function?
- Is there a documented notification procedure for reporting incidents to the provider?
- Are monitoring results recorded and retained per Art. 26.6?