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. What harm occurred or could have occurred?

   • death
   • serious harm to health
   • serious property damage
   • serious environmental damage
   • serious and irreversible disruption of critical infrastructure management

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 cause or plausibly contribute to death or serious 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.

For practical purposes, treat the event as a serious incident if it directly or indirectly led, might have led, or plausibly contributed to one of the following:

• death of a person
• serious damage to the health of a person
• serious and irreversible disruption of the management and operation of critical infrastructure
• breach of obligations under Union law intended to protect fundamental rights, where the breach is serious in effect
• for operational triage, also treat severe damage to property or the environment as requiring immediate legal review and likely notification planning where the facts align with the statutory serious-harm threshold or adjacent sector rules

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. Is there actual harm, or a sufficiently evidenced near-term harm scenario, connected to the system?

   • if no → record as non-serious incident / post-market issue unless facts change
   • if yes → continue

3. Does the harm fall into a severe category?

   • death
   • serious health harm
   • serious fundamental-rights impact
   • critical-infrastructure disruption
   • potentially equivalent severe sectoral harm requiring parallel reporting

4. Is there a causal link or at least a reasonable likelihood of one?

   • if yes → reportable timeline 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. Article 73(2) is triggered once the provider has established a causal link or the reasonable likelihood of such a link.

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. Article 62 reference

Article 62 ("Channels for reporting breaches and protection of reporting persons") requires Member States to establish channels for reporting breaches. In practice, these channels also serve as entry points for incident-related questions and operational guidance. The AI Office is expected to provide templates and information tooling. Article 62 is not itself the incident reporting rule, but it matters operationally for identifying the right contact point.

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. Does the event fit a serious-incident harm category?

• No → record and monitor
• Yes / maybe → Q3

Q3. Is there a causal link or reasonable likelihood?

• No → document and reassess as facts develop
• Yes / plausible → 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 (Commission proposal December 2025) progressed to a Council/Parliament provisional political agreement on 7 May 2026. That agreement would shift the application date for Annex III high-risk obligations to 2 December 2027 and Annex I high-risk obligations to 2 August 2028 if formally adopted. It is not yet adopted law — pending formal adoption and Official Journal publication. For now, do not rewrite the legal substance based on the provisional agreement alone.

Practical rule:

• note the provisional agreement as context where timing matters
• apply the current law as enacted unless and until amendments are adopted and in force

---

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.