# Serious Incident Reporting > Assess, report, and manage serious incidents involving high-risk AI systems under Article 73 EU AI Act. Covers incident qualification, deadline buckets (2/10/15 days), authority notification, deployer duties (Art. 26(5)), cross-regulation mapping (GDPR/NIS2/MDR), corrective measures, and DACH-specific routing. Use when asked to evaluate whether an AI incident is reportable, draft an Article 73 notification, identify the right authority, or build an AI incident response process. - Skill: `gabrielmoreira/serious-incident-reporting` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add gabrielmoreira/serious-incident-reporting` - Raw SKILL.md: https://api.skillmd.com/api/skills/gabrielmoreira/serious-incident-reporting/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: gabrielmoreira (https://skillmd.com/u/gabrielmoreira) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/gabrielmoreira/serious-incident-reporting --- # Serious Incident Reporting under the EU AI Act (Article 73) This skill helps assess whether an event involving an AI system triggers serious-incident reporting duties under **Article 73 EU AI Act**, and then turns that legal analysis into a practical response plan, draft notification, and internal action list. It is designed for providers, deployers, legal/compliance teams, product leads, and incident-response teams that need a usable process rather than abstract commentary. ## When to Use This Skill Use this skill when the user wants to: - assess whether an AI-related event qualifies as a **serious incident** under the EU AI Act - decide whether a system is in scope because it is actually **high-risk** - determine **when** reporting must happen and under which deadline bucket - identify the **market surveillance authority** to notify - prepare a practical **Article 73 report** - understand **deployer notification duties** under **Article 26(5)** - coordinate Article 73 with **GDPR**, **NIS2**, **medical device**, **machinery**, or **product safety** reporting - create an internal **incident playbook**, escalation matrix, or management briefing ## Quick Reality Check Before You Start This workflow only applies if the system is actually a **high-risk AI system** under the EU AI Act. That means: 1. it is high-risk under **Article 6(1)** because it is a safety component of an Annex I product or is itself such a product subject to third-party conformity assessment; **or** 2. it falls under **Annex III** and is not carved out by the **Article 6(3)** exception. If the system is only assumed to be high-risk because it sits near a regulated workflow, stop and confirm classification first. If **Article 6(3)** plausibly applies, incident reporting under Article 73 may not be triggered because the system is not in-scope as high-risk in the first place. ## What This Skill Produces Depending on the request, produce some or all of the following: - a **qualification memo**: in scope / out of scope / uncertain - a **deadline assessment**: 2-day / 10-day / 15-day / follow-up reporting - a **recipient map** by Member State - a draft **Article 73 incident report** - a **cross-regulation notification matrix** - an **internal action checklist** for legal, product, security, and management - a short **management briefing** in plain business language --- ## Quick Questions to Ask First Keep the first intake short and practical. Ask only what is needed to classify and triage. ### Minimum Intake Questions 1. **What AI system is involved?** - product name - version/build - provider legal entity - intended purpose 2. **Why do you think it is high-risk?** - Annex I safety component/product? - Annex III use case? - any prior classification memo? - any **Article 6(3)** non-high-risk assessment? 3. **What happened?** - date/time discovered - date/time incident occurred if different - what the system did or failed to do - causal chain as currently understood 4. **Which Art. 3(49) outcome occurred?** (The outcome must have materialised, directly or indirectly; potential harm alone goes to post-market monitoring, not Art. 73.) - (a) death, or serious harm to a person's health - (b) serious and irreversible disruption of the management or operation of critical infrastructure - (c) infringement of obligations under Union law intended to protect fundamental rights - (d) serious harm to property or the environment 5. **Where did the incident occur?** - Member State(s) - customer/deployer location - cross-border impact? 6. **Who identified it first?** - provider - deployer - distributor/importer - end user / affected person - authority / media / whistleblower 7. **What has already been done?** - system suspended? - users/deployers informed? - rollback / kill switch / access restriction? - internal investigation started? 8. **Any overlapping regimes?** - personal data breach? - NIS2/cyber incident? - medical device or in vitro diagnostic? - machinery / product safety? - labour / workplace impact? ### If Time Is Extremely Short Ask only these four: - Is the system definitely **high-risk**? - Did the event **directly or indirectly lead to** an Art. 3(49) outcome (death or serious health harm, irreversible critical-infrastructure disruption, fundamental-rights infringement, serious property or environmental harm)? - In which **Member State** did it occur? - When did the provider or deployer first become **aware**? --- ## Core Workflow Follow this sequence. ### Step 1 - Confirm Scope: Is the System Actually High-Risk? Do not jump straight to reporting. #### 1A. High-risk gateway Check whether the system is high-risk under **Article 6**: - **Article 6(1)**: annexed sector product / safety-component route - **Article 6(2)**: **Annex III** route - **Article 6(3)**: possible exception for certain Annex III systems that do not pose a significant risk of harm and do not materially influence decision-making, except profiling cases #### 1B. Decision - **Yes, clearly high-risk** → continue to Step 2 - **No, clearly not high-risk** → Article 73 does not apply; still assess other regimes - **Unclear** → state that classification uncertainty itself is material and proceed with a precautionary triage while classification is verified urgently #### Practical instruction If the user cannot produce a prior classification memo, ask for: - intended purpose - user group - sector/context - whether outputs materially influence decisions about persons or safety - whether the system is a safety component or regulated product If there is genuine ambiguity and potential severe harm, recommend a conservative incident-response posture while classification is clarified. For deeper logic, use `references/incident-qualification.md`. --- ### Step 2 - Qualify the Event: Is It a "Serious Incident"? Under **Article 3(49)**, this is the legal thresholding step. Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that **directly or indirectly leads to** any of the following: - **(a) the death of a person, or serious harm to a person's health** - **(b) a serious and irreversible disruption of the management or operation of critical infrastructure** - **(c) the infringement of obligations under Union law intended to protect fundamental rights** (no additional severity qualifier: the text does not require the breach to be "serious in effect") - **(d) serious harm to property or the environment** All four categories are full statutory categories. An event that *might have* caused one of these outcomes but did not is **not** a serious incident under Art. 3(49); route near misses to post-market monitoring (Art. 72) and the risk management system (Art. 9), and check whether another regime (product safety, NIS2, GDPR) has its own near-miss duty. #### Decision Tree 1. Did the event involve a high-risk AI system in operation, output, failure, misuse, or foreseeable misuse? - if **no** → not Article 73 - if **yes** → continue 2. Did an incident or malfunctioning actually occur, and did an Art. 3(49) outcome actually materialise (directly or indirectly)? - if **no** → not a serious incident; record under post-market monitoring / risk management, and re-qualify if facts change - if **yes** → continue 3. Which Art. 3(49) category does the outcome fall into? - (a) death or serious harm to health - (b) serious and irreversible disruption of critical infrastructure - (c) infringement of fundamental-rights-protecting Union law obligations - (d) serious harm to property or the environment 4. Is there a causal link between the AI system and the serious incident, or at least a **reasonable likelihood** of one? - if **yes** → the Art. 73 reporting clock starts running - if **uncertain but plausible** → treat as escalation case; preserve evidence and decide quickly - if **clearly no** → document why and monitor #### Practical rule Do not wait for perfect forensic proof of causation. **Article 73(2)** starts the reporting clock once the provider has established the causal link between the AI system and the serious incident **or the reasonable likelihood of such a link**. Note what this standard governs: the **causal-link** question in step 4. It does not lower the step 2 threshold, which still requires an Art. 3(49) outcome to have occurred. Use `references/incident-qualification.md` for examples and edge cases. --- ### Step 3 - Put the Incident Into the Correct Deadline Bucket Once there is a causal link or reasonable likelihood, determine the reporting deadline. | Scenario | Deadline | Article | Trigger | |----------|----------|---------|---------| | Standard serious incident | Immediately, max **15 days** | Art. 73(2) | Causal link or reasonable likelihood established | | Widespread infringement or Art. 3(49)(b) type | Immediately, max **2 days** | Art. 73(3) | Awareness of incident | | Death of a person | Immediately, max **10 days** | Art. 73(4) | Causal relationship established or suspected | #### Standard rule - Article 73(2) - report **immediately** after establishing causal link or reasonable likelihood - and **no later than 15 days** after the provider or, where applicable, the deployer became aware of the serious incident #### Accelerated rule - Article 73(3) If there is: - a **widespread infringement**, or - a serious incident of the type covered by **Article 3(49)(b)** then report: - **immediately**, and - **no later than 2 days** after awareness #### Death rule - Article 73(4) If the incident involves **death of a person**: - report immediately once causal relationship is established or even **suspected** - and **no later than 10 days** after awareness #### Incomplete initial report - Article 73(5) If facts are still developing: - send an **initial incomplete report** on time - follow with a more complete report as soon as possible #### Follow-up investigation - Article 73(6) After reporting: - investigate without delay - conduct risk assessment - take corrective action - cooperate with authorities - avoid altering the system in a way that could compromise causal analysis before informing authorities Use `references/reporting-requirements.md` for the deadline logic. --- ### Step 4 - Identify the Right Recipient Authority The baseline rule is simple: - notify the **market surveillance authority of the Member State where the incident occurred** But implementation is operationally messy, especially in cross-border or sector-specific cases. #### 4A. Core recipient logic - incident in one Member State → notify that State's market surveillance authority - incident in multiple Member States → prepare a lead-state map and parallel notifications where appropriate - uncertain location → identify where harm materialised, where the system was deployed, and where the affected persons or infrastructure were located #### 4B. Germany For Germany, use **Bundesnetzagentur (BNetzA)** as the primary practical entry point for AI Act market-surveillance routing, while checking whether a **sector-specific competent authority** also needs involvement. Common examples: - medical device context → national medical device authority chain - machinery / product safety context → sector product-safety channel may also matter - critical infrastructure or cyber context → NIS2 / BSI or sector-specific channels may run in parallel - employment context → add labour, works council, and data-protection analysis #### 4C. Where the report goes, and what Art. 87 is not Serious-incident reports are routed under **Art. 73** (to the market surveillance authority of the Member State where the incident occurred), with **Art. 74** governing market surveillance generally and the new **Art. 75(1a)** redirecting reports to the **AI Office** for systems under its exclusive competence. (Article 62, sometimes miscited here, is "Measures for providers and deployers, in particular SMEs, including start-ups" and has nothing to do with incident reporting. **Art. 87** covers reporting of infringements and protection of reporting persons under Directive (EU) 2019/1937; it is a whistleblowing channel, not the statutory serious-incident route.) Use `references/dach-specific.md` and `references/reporting-requirements.md`. --- ### Step 5 - Build the Reporting Package At minimum, assemble the package around the fields authorities will expect, even if the first report is incomplete. #### Essential content 1. **Provider identification** - legal entity - address / contact details - authorised representative if relevant - key incident contact person 2. **AI system identification** - name/model/version - CE / conformity / registration identifiers where relevant - high-risk category and legal basis - intended purpose and deployment setting 3. **Incident facts** - date/time of incident - date/time of awareness - location / Member State - affected deployer/customer - factual narrative of what happened 4. **Impact and affected parties** - number and type of persons affected - nature and severity of harm - whether harm is ongoing - critical infrastructure / public service implications - whether workers or vulnerable persons were affected 5. **Causation assessment** - confirmed causal link / reasonable likelihood / under investigation - known failure mode or suspected root cause - whether incident involved foreseeable misuse, input data issue, model drift, human oversight failure, or integration failure 6. **Containment and corrective measures** - system suspension or rollback - warnings to deployers - patch / hotfix / model disablement - human review measures - customer communication 7. **Evidence preservation** - logs retained - screenshots / prompts / outputs preserved - configuration and model version frozen - relevant third-party components identified 8. **Parallel notifications** - GDPR / NIS2 / MDR / product safety / insurer / contractual notices sent or pending 9. **Planned follow-up** - investigation owner - next reporting milestone - expected timing for supplementary report Use `references/templates.md` for a practical report template. --- ### Step 6 - Handle Deployer Duties Under Article 26(5) If the user is a **deployer**, or if the provider learned of the issue through a deployer, apply **Article 26(5)** explicitly. Under Article 26(5), deployers of high-risk AI systems must: - monitor operation based on instructions for use - where they believe use may result in a risk, inform the provider/distributor and relevant market-surveillance authority without undue delay and suspend use - where they identify a **serious incident**, **immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities** - if unable to reach the provider, Article 73 applies **mutatis mutandis** #### Practical meaning If the user is a deployer: - do not wait for the provider to "take over" before preserving evidence and preparing authority notification - suspend use where risk is live - document attempts to contact provider - preserve logs for at least the applicable retention period, noting **Article 26(6)** requires at least six months where logs are under the deployer's control If the user is a provider: - ask when and how the deployer first noticed the event - ask whether the deployer already informed authorities - align messaging fast to avoid contradictory reports Use `references/corrective-measures.md`. --- ### Step 7 - Map Overlapping Legal Regimes Article 73 rarely sits alone. Run a parallel obligations check. #### 7A. GDPR Ask: - did the incident involve personal data? - was there unauthorised access, loss, corruption, exposure, or unfair/automated decision impact? - does the event trigger **Article 33 GDPR** breach notification to the supervisory authority? - are **Article 34 GDPR** notifications to data subjects required? - does the incident expose a flawed or outdated **DPIA**? #### 7B. NIS2 / cyber security Ask: - is the entity an essential or important entity? - did the incident impair availability, authenticity, integrity, or confidentiality of network/information systems? - are early warning / incident notification duties triggered under the applicable national NIS2 implementation? #### 7C. Medical devices / IVD / machinery / product safety For AI systems embedded in regulated products: - check whether the incident must also be reported under MDR/IVDR vigilance rules - check whether machinery or general product safety incident channels apply - note **Article 73(9) and (10)**: where equivalent Union reporting regimes exist, AI Act incident notification may be limited to certain types of incidents, especially those affecting fundamental rights under Article 3(49)(c), and medical-device route incidents go to the designated national competent authority #### 7D. Employment and German works council issues If the incident occurred in employment or workplace monitoring context: - assess whether workers' representatives / works council need to be informed - in Germany, remember **BetrVG** co-determination and information implications may be live, especially where the system monitors behaviour or performance or affects personnel decisions Use `references/cross-regulation-mapping.md` and `references/dach-specific.md`. --- ### Step 8 - Drive Corrective Measures and Investigation Discipline The report is not the end. The operational response matters just as much. #### Provider checklist under Article 73(6) - start investigation **without delay** - perform risk assessment of incident and system - identify corrective action - cooperate with authorities and notified body where relevant - preserve evidence and avoid uncontrolled changes to the system before authority coordination #### Good practice actions - freeze model/version identifiers - snapshot configurations, prompts, training/fine-tune references, and deployment environment - document whether human oversight failed because of design, workload, UI, instructions, or user workarounds - assess whether incident suggests a broader field-corrective action across customers - review whether the post-market monitoring system and complaint-handling process worked as designed #### Outputs for the user - immediate containment actions - stakeholder communication map - field correction / patch / rollback plan - legal reporting matrix - board or management briefing Use `references/corrective-measures.md` and `references/templates.md`. --- ## Decision Logic Summary ### Fast Triage Tree **Q1. Is the system actually high-risk?** - No → Article 73 out, check other regimes - Yes / likely yes → Q2 **Q2. Did an Art. 3(49)(a)-(d) outcome actually materialise, directly or indirectly?** - No → not a serious incident; record under post-market monitoring and reassess if facts change - Yes → Q3 **Q3. Is there a causal link between the AI system and that incident, or a reasonable likelihood of one (Art. 73(2))?** - No → document why and monitor - Yes, or reasonably likely → Q4 **Q4. Which deadline bucket applies?** - death → immediate / max 10 days - widespread / Article 3(49)(b) type → immediate / max 2 days - otherwise → immediate / max 15 days **Q5. Who reports?** - provider by default under Article 73 - deployer also has duties under Article 26(5) **Q6. Where?** - market surveillance authority of Member State where incident occurred - Germany: start with BNetzA routing plus sector overlays --- ## Practical Drafting Guidance When preparing an answer, avoid vague legalese. Structure the response like this: 1. **Bottom line** - report now / likely report / monitor only 2. **Why** - high-risk basis + serious-incident basis + causation status 3. **Deadline** - 2 / 10 / 15 days and when the clock started 4. **Who to notify** - authority map + provider/deployer split 5. **What to send now** - minimum report contents 6. **What to do today** - suspend, preserve logs, inform deployers, assign owner 7. **What else may be triggered** - GDPR, NIS2, MDR, etc. --- ## DACH-Specific Notes ### Germany - Treat **BNetzA** as the primary practical AI Act market-surveillance entry point for routing/reporting questions in Germany. - Check whether a sector authority also needs notification. - If employees are affected, consider **BetrVG**, internal investigation protocols, and communication with workers' representatives. - If personal data is involved, identify the competent German supervisory authority under GDPR in parallel. ### Austria - Verify the competent national authority for the specific AI Act and sector context. - Where facts are time-critical, prepare a report package first and finalise recipient confirmation in parallel. ### Switzerland - Switzerland is not an EU Member State, so Article 73 itself is not an EU Member State reporting route there. - But Swiss incidents may still matter contractually, for product safety, data protection, and for EU reporting if the same AI system caused or contributed to incidents within the EU or affected EU deployments. Use `references/dach-specific.md`. --- ## Omnibus / Timing Caveat The Digital Omnibus simplification package amending the EU AI Act was adopted on 8 July 2026 and published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744, entering into force on 27 July 2026. It defers the application date for Annex III high-risk obligations (which include the Article 73 serious-incident reporting obligation) to **2 December 2027** and Annex I high-risk obligations to **2 August 2028**. Article 50 transparency obligations and the start of Commission GPAI enforcement powers were not deferred and continue to apply from 2 August 2026. Article 73 itself was not amended, **but who you report to can now be a different authority**: see the section below. ## Where to report: the AI Office derogation (Article 75(1a)) The same regulation inserted Article 75(1a), which overrides the default reporting route for one class of systems. Determine this **before** drafting the notification, because it changes the addressee. **By way of derogation from Article 73**, a provider of a high-risk AI system that falls under the AI Office's exclusive competence reports serious incidents **to the AI Office**, not to the national market surveillance authority. Article 73(2) to (9) still apply in the same way, so the timelines, content and follow-up duties are unchanged. The AI Office then promptly passes the relevant information to the market surveillance authority of the Member State where the provider or its legal representative is located. The AI Office is exclusively competent, under the replaced Article 75(1), for: 1. **AI systems built on a general-purpose AI model where the model and the system come from the same provider, or from providers within the same undertaking.** Four carve-outs stay with national authorities: systems related to Annex I products; systems under Annex III point 2; systems provided by law-enforcement authorities, border-management authorities and financial institutions, in so far as they fall under Article 74(6); and Annex III point 8 systems in the administration of justice. 2. **AI systems that constitute, or are integrated into, a very large online platform or very large online search engine** designated under the Digital Services Act. The competence covers providers of those systems. It reaches deployers only where the deployer is also the provider or belongs to the same undertaking; every other deployer stays under national supervision. Add one question to the intake: *is this system built on a general-purpose model from the same provider or undertaking, or embedded in a designated VLOP or VLOSE?* If yes, and none of the four carve-outs applies, the notification goes to the AI Office. Two further points worth knowing when advising on exposure. The AI Office gained its own investigation and enforcement powers in the new Articles 75a to 75d, including on-site inspections, binding commitments, fines applied mutatis mutandis from Article 99(3) to (7), and periodic penalty payments not exceeding 5% of the average daily income or worldwide annual turnover in the preceding financial year per day (Art. 75c(5)). Its decisions are reviewable by the Court of Justice, and a five-year limitation period applies. Practical rule: - apply the Act as amended by Regulation (EU) 2026/1744; the deferred dates above are the binding timeline - where timing matters, cite the amended application dates, not the pre-amendment ones --- ## Output Format When using this skill, tailor the response into these deliverables. ### Deliverable 1 - Qualification Snapshot - system classification: high-risk / not high-risk / uncertain - Article 6 basis - Article 6(3) exception assessment if relevant - serious incident: yes / no / uncertain - causal link: established / reasonably likely / not established ### Deliverable 2 - Reporting Recommendation - report required: yes / likely yes / not yet - deadline bucket: 2 / 10 / 15 days - awareness date - clock-start rationale - initial incomplete report needed: yes / no ### Deliverable 3 - Recipient Map - Member State(s) - primary market surveillance authority - sector-specific authority overlap - provider vs deployer notification split ### Deliverable 4 - Action Plan - next 4 hours - next 24 hours - next 7 days ### Deliverable 5 - Drafts If requested, provide: - draft Article 73 notification - deployer notice to provider - management briefing - cross-regulation notification matrix --- ## Reference Files Use these for deeper analysis and practical drafting: - `references/incident-qualification.md` - `references/reporting-requirements.md` - `references/corrective-measures.md` - `references/cross-regulation-mapping.md` - `references/dach-specific.md` - `references/templates.md` --- ## Disclaimer This skill provides a structured legal-operations workflow for EU AI Act serious-incident handling. It is not a substitute for case-specific legal advice, sector-specific regulatory advice, or forensic fact-finding. Important limits: - Article 73 only applies to **high-risk AI systems** that are actually in scope. - Serious-incident analysis is **fact-sensitive** and may change quickly as evidence develops. - Sector-specific product, cyber, labour, and data-protection rules may impose **parallel or stricter** duties. - Where death, critical infrastructure, medical-device safety, or multi-state harm is involved, escalate to specialist counsel immediately.