EU AI Act AI Supply Chain Incident Response: When Your Third-Party AI Provider Fails — Art.73 Deployer Obligations

Post #1455 in the sota.io EU AI Act Compliance Series

At 02:14 UTC on a Tuesday morning, your monitoring alerts fire: the third-party AI API powering your SaaS product's document analysis feature is returning hallucinated legal citations. Users in Germany's Bundesanwaltschaft are filing documents with fabricated case law. Dozens of court clerks have already flagged the errors.

You kill the feature. Your engineering team is on a call. But there is a second question — one that most SaaS developers have not prepared for: are you legally required to report this incident to an EU national authority? And if so, how fast?

Under EU AI Act Art.73, the answer may be yes — and the reporting window is shorter than most incident response playbooks assume.

This is the fourth post in the 5-part EU AI Act AI Supply Chain Compliance series. Parts 1–3 covered when SaaS developers become deployers, Art.13/26 due diligence checklists, and vendor contract requirements. Now we cover what happens when things go wrong.

What EU AI Act Art.73 Actually Requires

Art.73 — "Reporting of serious incidents" — creates an obligation for providers of high-risk AI systems to report serious incidents to the market surveillance authority of the member state where the incident occurred or where the affected user is located.

But Art.26 extends incident-adjacent obligations to deployers: if you are a deployer of a high-risk AI system and you become aware of a serious incident, you must immediately inform the provider and suspend the deployment if necessary. You become the first link in the incident escalation chain.

The Art.73 Reporting Timeline (Days, Not Hours)

One of the most persistent misconceptions in EU AI Act compliance documentation is that Art.73 borrows GDPR's hours-based breach notification windows. This is incorrect. The EU AI Act uses a calendar-day framework — significantly different from the GDPR notification regime that most security teams know:

The distinction matters because many AI supply chain incidents fall into the "serious incident, non-life-threatening" bucket — the 10-day window. This is more time than GDPR's 72-hour breach notification, but it still demands an operational incident response process that begins immediately when the incident is detected.

What triggers the clock: The countdown starts from when the deployer or provider "becomes aware" of the serious incident — not when it is fully diagnosed, not when root cause analysis is complete, not when the vendor confirms the failure.

What Qualifies as a "Serious Incident" in AI Supply Chains?

Art.73 defines a serious incident as any malfunction or unintended behavior of a high-risk AI system that results in, or could result in, any of the following:

1. Death or serious irreversible harm to health — physical or psychological
2. Serious disruption to management or operation of critical infrastructure — energy grids, hospitals, transport systems
3. Serious damage to property or the environment
4. Infringement of fundamental rights — discrimination, privacy violations, breach of human dignity

For SaaS developers integrating third-party AI APIs, the scope is narrower than it might seem — but not absent:

When Supply Chain Incidents Reach Art.73 Severity

Scenario 1: AI-assisted medical documentation — If your SaaS product is used in healthcare (Annex I, Section 5) and the integrated AI model starts recommending incorrect drug dosages due to a provider-side model update, this is a candidate Art.73 serious incident. Even if you did not build the model, your deployment of it in a high-risk context creates reporting obligations.

Scenario 2: AI-powered credit scoring — If your product uses a third-party AI API for creditworthiness assessment (Annex I, Section 5) and the provider's model update introduces systematic bias against a protected group, this is a fundamental rights infringement that triggers Art.73.

Scenario 3: AI in employment screening — HR tools using AI for CV screening (Annex I, Section 4) that receive a poisoned model update causing systematic discrimination must report serious incidents to the market surveillance authority.

Scenario 4: GPAI applications with broad reach — If your application is powered by a general-purpose AI model and the model begins generating content that violates Art.50 transparency requirements at scale, this may trigger notification requirements even outside the high-risk categories.

Art.26: Deployer Obligations During Vendor Incidents

Art.26 — "Obligations of deployers of high-risk AI systems" — is your primary compliance anchor during an AI supply chain incident. The key obligations triggered when a vendor incident occurs:

Immediate Response (Hour 0–4)

Art.26(1): Use AI according to instructions — If the vendor has issued emergency guidance about a faulty model version, follow it. Continuing to use a system outside its designated parameters can shift liability from the provider to you.

Art.26(5): Suspend the deployment if necessary — Art.26 explicitly recognizes that deployers may need to suspend use. Do not wait for the vendor to confirm the full scope — if you have credible evidence of a serious incident, suspend first and investigate after.

Art.26(6): Cooperate with competent authorities — If the national market surveillance authority contacts you as the deployer, full cooperation is mandatory, not optional.

Short-term Response (Hours 4–48)

Art.26(2): Maintain Art.12 logs — Art.12 requires providers to build automatic logging capability into high-risk AI systems. As a deployer, Art.26 requires you to retain those logs for at least 6 months (or longer if required by other regulations). During an incident, these logs are your primary evidence. Do not delete or rotate them.

Art.26(4): Inform affected natural persons — If you are using a high-risk AI system that makes or assists in making decisions affecting natural persons, and those persons may be adversely affected by an incident, you must inform them. This is separate from GDPR notification obligations.

Art.26(7): Notify the provider — You are required to notify the provider of the serious incident immediately. Your vendor contract (see Part 3 of this series) should specify how this notification must be made and within what time frame the provider must respond.

Art.73 Notification Decision (Day 1–2)

Based on your initial assessment, determine whether the incident meets the Art.73 serious incident threshold:

1. Has any person been harmed, or could harm occur if the deployment continues?
2. Has critical infrastructure been disrupted?
3. Have fundamental rights been infringed?

If yes to any: file an Art.73 notification to the relevant national market surveillance authority within 2 days (for life-threatening) or plan for a 10-day notification for other serious incidents.

Art.72: Post-Market Monitoring — The Pre-Incident Requirement

Art.72 — "Post-market monitoring by providers and post-market monitoring plan" — creates an obligation that should already be in place before any incident occurs. Providers must establish a post-market monitoring plan, and as a deployer you contribute to this by:

• Feeding anomalous behavior reports back to your AI vendor
• Tracking model performance metrics over time (not just at deployment)
• Maintaining a register of incidents, near-misses, and anomalies

If you are already running Art.72-compliant monitoring, you will detect serious incidents faster — which compresses the time between incident occurrence and your "becomes aware" moment that starts the Art.73 clock.

Practical implication for the AI supply chain: Your AI vendor should include a post-market monitoring API or dashboard in their service offering. If they do not, you must implement your own monitoring layer to satisfy Art.72 through the deployer's side. This should be a vendor evaluation criterion — documented in your Art.13 technical documentation review.

The Incident Response Gap in AI Supply Chains

Most SaaS developers have security incident response playbooks that cover data breaches, outages, and infrastructure failures. Almost none have an AI model incident response playbook that distinguishes between:

• Vendor outage (traditional SRE response — restore service ASAP)
• Model degradation (performance has dropped — investigate model drift)
• Serious incident under Art.73 (harm has occurred or could occur — legal notification + documentation + suspension)

The categories require fundamentally different responses. A vendor outage is an uptime problem. An Art.73 serious incident is a legal compliance event with mandatory notification timelines, documentation requirements, and potential liability consequences.

The Vendor Notification Dependency Problem

Your Art.73 obligation starts when you become aware of the incident — not when the vendor confirms it. But in most current AI API integrations, you are dependent on the vendor to tell you that something has gone wrong at the model level.

This creates a notification dependency gap:

• Your monitoring detects anomalous outputs → you investigate → you open a ticket with the vendor → vendor confirms a model issue → vendor notifies you of the severity → you determine Art.73 applicability → you file notification

Each step takes time. If the total chain is 3 days, you have already exceeded the 2-day window for life-threatening incidents.

The fix: Your vendor contract must include an SLA for vendor-initiated notification of incidents that affect your deployment — ideally within 1 hour, with a preliminary severity assessment within 4 hours. See Part 3 of this series for the complete contract language.

Practical AI Supply Chain Incident Response Playbook

Phase 1: Detection & Initial Assessment (Hour 0–4)

Phase 2: Severity Classification (Hour 4–24)

Phase 3: Regulatory Notification (Day 1–10)

National market surveillance authority identification — notifications go to the authority in the member state where the incident occurred or where affected users are located. For incidents affecting users across multiple EU member states, notify all relevant authorities.

Notification content (Art.73):

• Description of the AI system and its high-risk category
• Description of the serious incident: what happened, when, who was affected
• Preliminary root cause assessment (provider-side or deployer-side)
• Measures taken (suspension, user notification)
• Ongoing investigation status
• Contact information for follow-up

Vendor coordination: Your notification should reference whether the provider has been notified and whether they are conducting their own Art.73 notification (if they are the provider, this is their primary obligation). Document all vendor communications.

25-Item AI Supply Chain Incident Response Checklist

Pre-Incident Preparation (Must Complete Before August 2, 2026)

• Identify all high-risk AI systems in your product (Annex I categories)
• Map which vendor is the provider of each high-risk AI system
• Confirm vendor Art.13 documentation includes incident notification SLAs
• Configure Art.12 log retention (minimum 6 months, verify log completeness)
• Establish Art.72 post-market monitoring metrics and alert thresholds
• Identify the national market surveillance authority for each EU member state where you operate
• Draft Art.73 notification template (fill in blanks when incident occurs)
• Designate an Art.73 incident response team (legal + engineering + DPO)
• Test your AI monitoring layer — can you detect model degradation without vendor notification?

Immediate Response (Hour 0–4)

• Confirm AI-related root cause (not infrastructure)
• Pull and preserve Art.12 logs for the affected period
• Make suspension decision (err on the side of suspension)
• Notify vendor per contract SLA (document timestamp)
• Start incident documentation log (who/what/when/harm assessment)
• Activate Art.73 incident response team

Severity Classification (Hour 4–24)

• Assess harm: death, serious health harm, critical infrastructure disruption, fundamental rights infringement
• Determine reporting window: 2, 10, or 15 days
• Identify affected natural persons — initiate Art.26(4) notification if required
• Document preliminary root cause: provider-side model issue or deployer-side misconfiguration

Regulatory Notification (Day 1–10)

• Complete Art.73 notification document
• Identify all relevant national market surveillance authorities
• Submit Art.73 notification by deadline
• Retain copy of submission and timestamp
• Coordinate with vendor on their Art.73 obligations
• Document all vendor communications and response timelines

Post-Incident

• Root cause analysis complete, documented in Art.12 log supplement
• Vendor remediation confirmed (updated model, fixed configuration)
• Re-deployment decision documented
• Art.72 monitoring updated to detect recurrence
• Incident added to Art.12 records for 6-month retention period

What This Means for Your AI Vendor Selection

The incident response implications of EU AI Act Art.73 create two categories of AI vendors:

Category A vendors — providers who have invested in Art.73-compliant incident response infrastructure:

• Proactive incident notification with defined SLAs (e.g. 1 hour preliminary, 4 hours severity assessment)
• Art.13 documentation that includes incident response procedures
• EU-jurisdiction support teams who understand NCA notification requirements
• No CLOUD Act exposure (US-parent incident data stays in EU)

Category B vendors — providers operating without EU AI Act compliance infrastructure:

• Reactive communication (you find out when your monitoring alerts, or from HN)
• Generic incident communication through standard support tickets
• No structured Art.73 support
• CLOUD Act exposure means incident data may be accessible to US law enforcement, creating parallel compliance obligations

For deployers using Category B vendors in high-risk AI applications, the burden of Art.73 compliance falls almost entirely on your side — you must build the detection, classification, and notification capability that the vendor cannot provide.

Connecting to the Full AI Supply Chain Framework

This post completes the operational picture for AI supply chain incident response. Together with Parts 1–3:

• Part 1 mapped the Art.3/25/26 decision tree: when are you a provider vs. deployer?
• Part 2 covered Art.13/26 due diligence: what documentation must your vendor provide?
• Part 3 specified the contract language: what must your vendor commit to contractually?
• Part 4 (this post) covers incident response: what do Art.73 and Art.26 require when things go wrong?

The final post in this series will synthesize a complete AI supply chain compliance toolkit — a single-document framework you can adapt for every third-party AI API in your stack.

Summary

EU AI Act Art.73 is not a compliance checkbox — it is an operational requirement that demands pre-built incident response infrastructure. The key facts for SaaS developers integrating third-party AI:

1. The Art.73 clock starts when you become aware — not when the vendor confirms the incident. Your monitoring capability determines how much time you have.

2. Reporting windows are 2/10/15 calendar days — depending on severity. Not 24 or 72 hours. But this is still fast for a legal regulatory notification.

3. Art.26 requires immediate suspension if harm is possible — not after root cause is confirmed. Suspend first, investigate second.

4. Your vendor notification dependency is a liability — if your vendor does not proactively notify you within hours, you may miss the reporting window. This must be a contractual requirement.

5. Pre-incident preparation is the only path — you cannot build an Art.73-compliant incident response process in the 4 hours after an incident begins.

August 2, 2026 is 61 days away. If your AI supply chain incident response plan does not include Art.73, you have 61 days to build it.