EU AI Act Art.26 Deployer Monitoring, Incident Reporting, and Market Surveillance Cooperation (2026)

Post #1645 in the sota.io EU AI Act Compliance Series — ART25-26-DEPLOYER-PACK-2026 #4/5

Deploying a high-risk AI system is not a one-time compliance event. The previous posts in this series covered what you must do before and during deployment: stay within the intended purpose (Post 1), address fundamental rights risks (Post 2), and ensure your staff have sufficient AI literacy (Post 3). This post covers what you must do after go-live: monitoring the system's operation, detecting problems, reporting serious incidents, retaining logs, and cooperating with market surveillance authorities if they come knocking.

These are the Art.26 obligations that most deployers underestimate. They do not require expensive infrastructure by default, but they require organizational discipline: someone must be watching, someone must know what to escalate, and someone must be able to produce records when an NCA conducts an audit.

The Post-Deployment Obligation Gap

There is a common misconception that Art.26 compliance ends at deployment. The logic goes: if you have confirmed you are within the intended purpose, conducted an AI literacy program, and done your fundamental rights review, you are compliant. Switch on the system and move on.

This is wrong. Art.26 contains a set of ongoing, operational obligations that continue for as long as the system is in use. The intended purpose doctrine defines the boundary. The monitoring obligation requires you to actively check that you remain within it. The incident reporting obligation requires you to act when problems cross defined thresholds. The log retention obligation requires you to maintain evidence. The market surveillance cooperation obligation requires you to respond to NCA inquiries.

None of these are satisfied at deployment and forgotten. They define a compliance operating mode that runs in parallel with normal operations.

Art.26(4): The Monitoring Obligation

Art.26(4) requires deployers to monitor the operation of the high-risk AI system on the basis of the instructions for use. Specifically, it requires deployers to inform the provider when they detect:

• Anomalies — unexpected outputs, irregular behavior, edge cases the system handles poorly
• Malfunctions — system errors, crashes, timeouts that affect operation
• Unexpected performance characteristics — the system performing significantly differently from what the instructions for use lead you to expect

The monitoring obligation is deliberately connected to the instructions for use. The provider defines the operational envelope; the deployer watches for deviations. This is the feedback loop the Act envisions: deployers surface operational problems that the provider uses to improve the system and, where necessary, trigger their own Art.73 serious incident reporting obligations.

What Monitoring Looks Like in Practice

For most SaaS deployers using third-party AI APIs, effective monitoring means instrumenting around the AI integration point:

Output quality monitoring tracks whether AI-generated outputs remain within expected quality ranges. For a CV-screening tool, this might mean sampling 5% of decisions weekly and having an HR specialist review them for anomalies — outputs that are systematically biased toward or against protected groups, nonsensical recommendations, or decisions clearly inconsistent with stated criteria.

Performance drift monitoring tracks whether the system's behavior changes over time. Many AI models experience performance drift as the input distribution shifts — a credit model trained on pre-COVID data may behave differently during economic downturns. Monitoring for drift requires establishing baseline metrics at deployment and tracking deviations.

Error rate monitoring tracks technical failures — API errors, response latency, null outputs, malformed responses. A sudden spike in error rates may indicate an infrastructure problem at the provider's end that could affect the quality of decisions being made.

Disparity monitoring tracks whether outputs are systematically different across demographic groups. For Annex III, Category 4 (employment) and Category 5 (credit, essential services), monitoring for differential outcomes across gender, ethnicity, age, or disability status is both an Art.26 monitoring obligation and an Art.21 Charter obligation.

Connecting Monitoring to Art.27 FRIA Updates

For deployers who must conduct an Art.27 Fundamental Rights Impact Assessment (Art.27 FRIA — covered in Post 2), monitoring data is not just an Art.26 obligation: it feeds directly into the FRIA review process. Art.27 requires deployers to review and update their FRIA when significant changes occur. Monitoring findings — especially disparity monitoring results — are the primary inputs to those FRIA reviews.

This creates an integrated compliance loop: FRIA identifies risks at deployment → monitoring watches for those risks materializing → FRIA is updated when they do.

Art.26(5): Log Retention

Art.26(5) requires deployers to retain logs that are automatically generated by the high-risk AI system, to the extent that those logs are accessible to them, for a minimum period of six months.

This provision has two important qualifications that deployers often overlook:

"To the extent accessible." Not all AI providers expose full system logs to deployers. A third-party API may only return output values, not the internal inference logs that capture model confidence scores, feature weights, or decision pathways. Art.26(5) recognizes this: it does not require deployers to obtain logs they cannot access. But it does require retaining whatever they can access — API request/response logs, downstream decision records, human override records.

"Six months minimum." Six months is a floor, not a ceiling. For high-risk use cases in employment, credit, and healthcare, deployers should consider whether sector-specific regulations impose longer retention requirements. GDPR data retention principles apply to any personal data in those logs. Some national employment law frameworks require records of hiring decisions to be retained for two to three years to support potential discrimination claims.

What to Log

Given the six-month retention obligation, deployers should systematically capture:

1. API call records — timestamp, input data hash (not raw PII), output value, response latency, any error codes
2. Decision records — the downstream action triggered by the AI output (e.g., "application advanced to interview stage"), the human review outcome if applicable, any override of the AI recommendation
3. Anomaly records — logged instances where monitoring detected anomalies, and what action was taken
4. System-level logs from the provider — if the provider's API returns confidence scores, uncertainty flags, or model version identifiers, capture and retain these; they become critical evidence during any NCA investigation

For SaaS platforms, this typically means an AI decision log table in your database — separate from general application logs, with explicit retention policies, access controls, and a deletion schedule that complies with GDPR retention limits.

Art.26(6): Serious Incident and Malfunction Notification

Art.26(6) requires deployers to notify the provider of any serious incident or serious malfunction of a high-risk AI system that they become aware of.

The definition of "serious incident" links to Art.73, which defines it as an incident that directly or indirectly causes:

• Death of a natural person
• Serious injury to a natural person
• Serious harm to property
• Serious disruption to the provision of essential services
• Serious and irreversible harm to a natural person's rights

For most enterprise deployers, the relevant category is the last one: serious and irreversible harm to rights. This captures scenarios where an AI system makes a consequential decision — a denied loan, a rejected job application, a deprioritized benefit claim — and that decision was the result of a malfunction or anomaly that would not have occurred in normal operation.

The Notification Chain

The Art.26(6) notification goes to the provider. The deployer's obligation is to make the provider aware of the problem; the provider then carries the obligation under Art.73 to notify the national competent authority (NCA) and, if appropriate, the AI Office.

This chain creates a coordination requirement between deployer and provider that should be established contractually before deployment. Deployers should ensure their API agreements or service contracts specify:

• How to report a serious incident to the provider (dedicated reporting channel? Escalation contact?)
• What response time the provider commits to
• How the provider will keep the deployer informed of the investigation and NCA notification

For providers who are also subject to DORA (financial services) or NIS2 (critical infrastructure operators), incident notification obligations may be shorter and more demanding than the AI Act's timelines — and the channels may overlap. SaaS deployers in these sectors should map their AI Act incident reporting obligations against their existing DORA or NIS2 procedures to create a unified incident response workflow.

When Deployers Must Also Notify the NCA Directly

Art.26(6) establishes the provider as the primary notification channel. But deployers are not always shielded from direct NCA contact. Under Art.74, NCAs have the power to request information directly from deployers as part of market surveillance activities. If an NCA reaches out during an investigation, the Art.26(7) cooperation obligation (covered below) applies.

There is also a category-specific trigger: deployers of high-risk AI systems used by public bodies, or deployers of systems used in critical infrastructure, may face national-law notification requirements for incidents affecting public service continuity. Art.26 does not override those national requirements.

Art.26(7): Market Surveillance Cooperation

Art.26(7) requires deployers to cooperate with national competent authorities in any investigation or audit related to a high-risk AI system. This is a broad, unqualified obligation.

Market surveillance under Art.74 gives NCAs significant investigative powers: they can request access to documentation, request information about the system's deployment and operational results, conduct on-site inspections, and require deployers to take corrective action. For high-risk AI systems in sectors that already have strong regulatory oversight — financial services, healthcare, employment — NCAs may be conducting AI Act compliance checks in parallel with existing sector supervision.

What Market Surveillance Cooperation Looks Like

The cooperation obligation is not a passive obligation to answer questions when asked. It implies maintaining documentation that makes cooperation possible. Specifically:

Deployment documentation — records showing that the system was used within its intended purpose, that human oversight was implemented as required under Art.26(3), and that the AI literacy program under Art.26(9) was conducted for relevant staff.

Monitoring records — evidence of ongoing monitoring activity, anomaly detection, and any provider notifications made under Art.26(6).

FRIA records — if an Art.27 FRIA was required, deployers must produce it on request. The FRIA is specifically listed as documentation that NCAs can request under Art.74.

Incident records — logs of any serious incidents detected, notifications made to providers, and the subsequent response.

NCAs are entitled to obtain all of this without advance notice. Deployers who have integrated Art.26 compliance into their operational processes — rather than treating it as a one-time deployment checklist — will be able to produce this documentation quickly. Deployers who have not will face a painful reconstruction exercise under deadline pressure.

Art.26(8): Suspension Obligation

Art.26(8) is the most dramatic operational obligation: it requires deployers to suspend or discontinue use of a high-risk AI system if they discover a substantial risk to the health, safety, or fundamental rights of natural persons.

The trigger is "substantial risk" — a threshold that requires judgment. Not every anomaly requires suspension. The standard is a serious, credible risk that was not known at the time of deployment and that could cause the kinds of harm associated with serious incidents under Art.73.

Practically, this means deployers must have a decision framework that identifies:

1. Who has authority to make the suspension decision — this should not require board-level approval, but it should require sign-off from a defined role (e.g., DPO, CISO, Head of Compliance, CTO)
2. What thresholds trigger review — monitoring data that crosses defined thresholds should automatically escalate to the suspension decision-maker for evaluation
3. What suspension looks like operationally — for API-based AI integrations, suspension typically means disabling the AI feature and reverting to manual processes; deployers need to have that fallback ready before they need it

The suspension obligation also interacts with business continuity. For high-risk AI systems embedded in core workflows — a credit scoring model that processes thousands of applications daily, an AI-assisted recruitment tool used across all hiring pipelines — suspension has operational consequences. The AI Act accepts those consequences. It does not provide an exception for business disruption when the health, safety, or fundamental rights of natural persons are at substantial risk.

Integrating the Operational Obligations: A Compliance Operating Mode

The monitoring, log retention, incident reporting, cooperation, and suspension obligations in Art.26 collectively define what a compliance operating mode looks like for a deployer of high-risk AI. This is not compliance-at-deployment; it is compliance-as-operations.

A practical implementation approach structures these obligations around three layers:

Automated layer — your technical infrastructure: API call logging, anomaly detection rules, performance drift monitoring, disparity analysis pipelines. These run continuously without human intervention and generate the raw data that human review acts on.

Human review layer — a defined schedule of human oversight activities: weekly output sampling, monthly disparity reviews, quarterly FRIA review meetings. Human review turns automated data into decisions — whether to notify the provider, escalate to compliance, or trigger suspension.

Escalation and response layer — documented processes for the uncommon but important events: serious incident notification procedures, NCA cooperation protocols, suspension decision authority matrix. These processes exist in the background until needed, but they must exist before they are needed.

Timeline for Operational Compliance

Art.26 Penalties Under Art.99

Deployers who fail to comply with Art.26 obligations face enforcement under Art.99 of the EU AI Act. The penalty structure for Art.26 violations mirrors the broader penalty regime:

For violation of deployer obligations, Art.99 provides for fines of up to €15 million or 3% of global annual turnover (whichever is higher) for enterprises, and €7.5 million or 3% of global annual turnover for SMEs and startups.

These fines are not automatic and are subject to the standard Art.99 assessment factors: severity, duration, whether the violation was negligent or intentional, corrective actions taken, whether authorities were notified proactively. But the ceiling is significant for any deployer operating at scale.

The practical lesson: the monitoring, logging, and incident reporting obligations are not just operational housekeeping — they are documented evidence of good faith compliance that NCAs will consider if enforcement proceedings begin.

Post-Deployment Compliance Checklist

Before and during production operation, verify:

• Monitoring instrumentation deployed: output quality, performance drift, error rates, disparity analysis
• Monitoring alert thresholds defined and tested
• Log retention pipeline active: API logs, decision records, anomaly records retained for ≥6 months
• Log access controls implemented (GDPR-compliant, no PII without legal basis)
• Serious incident notification procedure documented: who decides, how to notify provider, what timeline
• Provider incident reporting contact confirmed (API agreement / service contract)
• NCA cooperation documentation folder maintained: deployment records, monitoring evidence, FRIA (if required)
• Suspension decision authority defined: role, thresholds, fallback operational procedure
• Art.26(7) cooperation readiness review scheduled annually
• FRIA review trigger linked to monitoring data (for Art.27-scope deployers)

What Comes Next in the ART25-26-DEPLOYER-PACK Series

The fifth and final post in this series synthesises Art.26 and Art.27 into a consolidated deployer compliance checklist — covering all Art.26 obligations across all four posts plus the Art.27 FRIA requirements, structured as a pre-deployment gate and a post-deployment operating review.

For deployers who want to go deeper on Art.27 FRIA methodology before that finale, the companion FRIA series covers the scope and triggering conditions, the seven-section assessment template, sector-specific considerations for employment, education, and social services, and the monitoring and update cycle.

For the host-in-the-EU angle, Art.26 + Art.73 incident reporting covers how to build a unified incident pipeline when your AI system is also subject to CRA or DORA.