The European Union’s AI Act has already been called many things: historic, ambitious, complicated, and, depending on who is reading it at 11:47 p.m. with cold coffee, “a lot.” Now the European Commission has added an important new piece to the compliance puzzle: draft guidance on serious incident reporting for high-risk AI systems.
In plain English, the Commission is telling AI providers: if your high-risk AI system causes or contributes to serious harm, do not quietly sweep the digital crumbs under the server rack. Report it, investigate it, cooperate with authorities, and fix what went wrong.
The draft guidance focuses on Article 73 of the EU AI Act, which creates reporting obligations for serious incidents involving high-risk AI systems. Although the obligation is expected to apply from August 2026, the guidance gives companies a valuable preview of what regulators will expect. For businesses building, selling, or deploying AI in Europe, this is not a “future problem.” It is a “start preparing now before your compliance team starts stress-eating pastries” problem.
What Did the European Commission Issue?
On September 26, 2025, the European Commission published draft guidance and a draft reporting template for serious incidents under the EU AI Act. The consultation period invited stakeholders to comment on how the reporting process should work, how key terms should be interpreted, and how the AI Act should interact with other EU reporting regimes such as GDPR, NIS2, DORA, the Critical Entities Resilience Directive, and medical device rules.
The goal is not simply to generate more paperwork. The Commission’s approach is designed to create an early warning system for dangerous patterns, improve accountability, help regulators intervene quickly, and increase public trust in high-risk AI technologies. In other words, the EU wants AI incident reporting to work less like a dusty filing cabinet and more like a smoke alarm.
Why Serious AI Incident Reporting Matters
AI systems are no longer limited to playlist recommendations and chatbots that politely apologize while being wrong. High-risk AI can influence medical decisions, credit access, hiring, education, law enforcement, border control, critical infrastructure, and essential public services. When these systems fail, the consequences can be serious, widespread, and difficult to reverse.
The EU AI Act’s incident reporting rules recognize a practical truth: no model is perfect after launch. Real-world use exposes edge cases, data drift, unexpected human behavior, and system interactions that testing may miss. A hiring algorithm might perform well in a lab but filter out qualified applicants from a protected group once used at scale. A medical triage system might misclassify patients if local hospital data differs from its training environment. A predictive maintenance model might help a utility company until a bad signal causes the wrong infrastructure to be prioritized.
Incident reporting forces organizations to treat AI safety as a lifecycle responsibility. The job does not end when the system goes live. That is when the most interesting, and sometimes most uncomfortable, evidence begins to appear.
What Counts as a “Serious Incident” Under the EU AI Act?
The AI Act defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to one of four serious outcomes:
- Death of a person or serious harm to a person’s health
- Serious and irreversible disruption of the management or operation of critical infrastructure
- Infringement of obligations under EU law intended to protect fundamental rights
- Serious harm to property or the environment
This definition is intentionally broader than a traditional software outage. A simple bug, awkward chatbot response, or minor dashboard glitch will not automatically qualify. But if an AI system contributes to real-world harm, especially in a high-risk setting, the organization may need to report it.
Direct and Indirect Causation
One of the most important points in the draft guidance is that causation may be direct or indirect. That matters because AI often does not harm people in isolation. It usually influences a decision, ranking, recommendation, score, alert, or workflow.
For example, suppose an AI medical imaging tool incorrectly flags a scan as low risk. A doctor relies partly on that output, treatment is delayed, and the patient suffers serious harm. The AI system may not have acted alone, but it could still be part of the causal chain. The same logic can apply to a recruitment tool that ranks candidates unfairly, a credit scoring system that denies access to essential services, or a risk model that leads to discriminatory insurance outcomes.
The message is clear: companies cannot avoid scrutiny by saying, “A human made the final decision.” If the AI output materially shaped that decision, regulators may still ask hard questions.
Not Every AI Mistake Is a Reportable Incident
The draft guidance also helps separate ordinary technical issues from serious incidents. A chatbot that recommends pineapple on pizza may offend culinary purists, but it is not automatically an Article 73 event. A high-risk AI system that misclassifies patients, excludes protected groups from jobs, disrupts infrastructure, or causes serious environmental damage is a different matter entirely.
The key is impact. Regulators will look at the severity of harm, whether the AI system was used as intended or in a reasonably foreseeable way, whether fundamental rights were affected, and whether the consequences were serious enough to trigger reporting.
Who Must Report Serious AI Incidents?
Article 73 mainly focuses on providers of high-risk AI systems. A provider is generally the organization that develops an AI system, has one developed, places it on the EU market, or puts it into service under its own name or trademark.
That definition can matter for U.S. companies. A business does not need to be physically headquartered in Paris, Berlin, or Rome to care about the AI Act. If it offers a high-risk AI system in the EU market, supplies it to EU customers, or integrates it into regulated products used in Europe, the law may become highly relevant.
Deployers also have responsibilities. A deployer is an organization using an AI system under its authority, such as a hospital, employer, bank, public agency, or infrastructure operator. If a deployer identifies a serious incident, it may need to inform the provider and other relevant parties quickly. If the provider cannot be reached, the deployer may have to step further into the reporting process.
Reporting Deadlines: The Clock Ticks Fast
The AI Act creates tiered reporting timelines based on the seriousness and type of incident. In general, a serious incident must be reported immediately after the provider establishes a causal link, or a reasonable likelihood of a causal link, between the AI system and the incident. In any event, the standard outside deadline is 15 days after the provider or deployer becomes aware of the serious incident.
Some incidents move faster. If the incident involves a widespread infringement or a serious and irreversible disruption of critical infrastructure, the report must be made immediately and no later than two days after awareness. If the incident results in the death of a person, the report must be made immediately after a causal relationship is established or suspected, and no later than 10 days after awareness.
The law also allows an initial incomplete report when necessary. That is sensible because the first hours after a major incident are usually messy. Logs are being pulled, engineers are squinting at dashboards, legal teams are asking precise questions, and someone is probably saying, “Can we please get one timeline everyone agrees on?” The EU AI Act recognizes that companies may need to submit what they know first and complete the report later.
What the Draft Reporting Template Is Likely to Change
The reporting template is important because it moves companies from abstract obligation to practical checklist. A serious AI incident report will likely need details about the provider, the AI system, where and when the incident occurred, who was affected, what harm resulted, what evidence supports a causal link, and what corrective measures have been taken or planned.
The template also asks organizations to consider other reporting obligations. This is a big deal because AI incidents rarely stay in one neat legal box. An AI-powered medical device incident may raise medical device reporting issues. A cyber-related AI failure may trigger NIS2. A personal data breach may trigger GDPR. A financial services technology outage may trigger DORA. A critical infrastructure failure may raise CER obligations.
For companies, the lesson is simple: AI incident response cannot live in a lonely spreadsheet owned by one team. It needs to connect legal, privacy, cybersecurity, product safety, compliance, engineering, and business operations.
How the Guidance Interacts With Other EU Laws
The Commission’s draft guidance pays close attention to overlapping reporting regimes. This is welcome because without coordination, companies could face a notification maze worthy of a medieval castle.
For certain high-risk AI systems already covered by equivalent EU reporting duties, the AI Act reporting obligation may be limited to serious incidents involving fundamental rights. This can matter for systems subject to sector-specific rules such as medical device regulations, NIS2, DORA, and critical infrastructure laws.
However, “limited” does not mean “ignore.” A company may still need to report the same underlying event under another legal framework while separately assessing whether the AI Act adds a fundamental-rights notification. For example, a bank using AI for loan decisions may need to examine whether a model failure created discriminatory outcomes. A hospital using AI diagnostics may need to consider medical device obligations as well as AI-related rights and safety concerns.
Examples of Serious AI Incidents
Examples make the rules easier to understand. Consider an AI recruitment system that rejects qualified candidates because a proxy variable correlates with gender, ethnicity, disability, or age. If the system causes a serious infringement of equal treatment rights, the incident may fall within the AI Act’s reporting framework.
Another example is a hospital triage tool that incorrectly classifies a patient as low risk, contributing to delayed care and serious harm. Even if clinicians remain involved, the AI system’s indirect role may be enough to require reporting.
In critical infrastructure, imagine an AI system managing power distribution that uses a flawed prioritization model during an emergency. If the malfunction causes serious and irreversible disruption, especially where human safety is threatened, the reporting clock may move extremely quickly.
Environmental examples are also possible. If an AI system controlling industrial processes misreads risk signals and contributes to serious contamination of water, soil, or air, the event may raise reporting duties under the AI Act and environmental rules.
Why U.S. Companies Should Pay Attention
For U.S. technology companies, the EU AI Act is not merely a European policy curiosity. It can affect vendors, developers, cloud providers, medical technology firms, HR software companies, fintech platforms, insurance technology providers, and enterprise AI companies serving EU customers.
The practical challenge is that many organizations do not yet have AI-specific incident response processes. They may have cybersecurity playbooks, privacy breach procedures, product safety escalation paths, and customer support workflows. But AI incidents can cut across all of them at once.
A model failure might involve bias, safety, data protection, explainability, contractual liability, and sector regulation. If every team waits for another team to decide whether the incident is “theirs,” the company may lose precious time. Under the AI Act, slow confusion is not a strategy.
How Companies Can Prepare Now
1. Map High-Risk AI Systems
Companies should begin by identifying which AI systems may qualify as high-risk under the EU AI Act. This includes systems used in regulated products and systems listed in Annex III categories such as employment, education, essential services, critical infrastructure, law enforcement, migration, and democratic processes.
2. Define AI Incident Triggers
Organizations should create clear internal definitions for AI incidents, serious incidents, malfunctions, near misses, and escalations. The goal is not to over-report every hiccup, but to ensure serious events do not disappear inside ordinary bug tracking.
3. Build a Cross-Functional Response Team
An AI incident response team should include engineering, product, legal, privacy, security, compliance, risk, communications, and business owners. For high-risk systems, the team should know who contacts regulators, who preserves evidence, who coordinates with deployers, and who approves corrective action.
4. Preserve Evidence Before Changing the System
The draft guidance emphasizes investigation and cooperation with authorities. Providers should avoid altering the AI system in ways that could affect later evaluation of the incident before informing competent authorities. This means logs, model versions, prompts, outputs, data inputs, configurations, monitoring records, and human review notes may all become important evidence.
5. Connect AI Reporting With Existing Compliance Programs
AI incident reporting should not be built from scratch in a corner. Companies should integrate it with privacy breach response, cybersecurity incident response, product safety reporting, medical device vigilance, financial services resilience, and enterprise risk management. The best compliance program is not the one with the most binders. It is the one people can actually use under pressure.
Business Impact: More Than a Legal Checkbox
The draft guidance signals that AI governance is becoming operational. Companies will need documentation, monitoring, escalation rules, training, and technical tools that can detect when an AI system may be causing serious harm.
This may increase compliance costs, especially for startups and smaller providers. But it can also improve product quality. Incident reporting creates feedback loops. Feedback loops create safer systems. Safer systems create trust. And trust, unlike a surprise regulatory investigation, is good for business.
The companies that prepare early will likely have an advantage. They will be able to answer customer questions, negotiate enterprise contracts, respond to audits, and demonstrate mature AI governance. The companies that wait until the first serious incident occurs may discover that building a reporting system during a crisis is like installing smoke detectors while the toaster is already on fire.
Experience-Based Lessons for Organizations Preparing for the EU AI Act
From a practical compliance perspective, the most useful way to think about the European Commission’s draft guidance is not as a legal memo but as an operational stress test. Many organizations already have incident response procedures, but those procedures were built for familiar categories: cybersecurity, privacy breaches, product defects, outages, or workplace complaints. AI incidents often refuse to fit neatly into one of those boxes.
In real organizational settings, the first problem is usually ownership. A model starts behaving strangely. The product team sees declining performance. Customer support receives complaints. The legal team hears about possible discrimination. Security wonders whether the issue is adversarial manipulation. Meanwhile, business leadership wants to know whether the product must be paused. Without a clear AI incident playbook, everyone has a piece of the puzzle, but nobody owns the table.
The second lesson is that evidence disappears quickly unless teams plan ahead. AI systems can be dynamic. Inputs change, prompts vary, model versions update, logs rotate, and downstream users make decisions outside the system. If a company has not decided what to preserve before an incident, it may struggle to reconstruct what happened. For high-risk AI, good logging is not just a technical luxury. It is the memory of the system.
The third lesson is that legal thresholds require technical translation. Engineers may understand accuracy drops, false positives, drift, latency, and model confidence. Lawyers may understand fundamental rights, serious harm, reporting timelines, and regulatory authorities. The organization needs a shared language between those worlds. For example, a “model performance issue” in an employment screening tool may also be a potential equal treatment issue. A “temporary system disruption” in critical infrastructure may become more serious if it affects public safety or essential services.
The fourth lesson is that deployer-provider coordination must be tested before launch. Many AI providers rely on customers to detect real-world problems. Many customers rely on vendors to understand the model. That split can create dangerous delays. Contracts should define notification paths, escalation contacts, evidence-sharing obligations, and cooperation duties. A 2-day reporting deadline leaves little room for “Who has the right email address?” drama.
Finally, companies should treat incident reporting as a trust-building function, not only a regulatory burden. When users, regulators, and customers see that an organization can identify problems, report them responsibly, and take corrective action, confidence grows. AI will fail sometimes. The real test is whether the organization fails gracefully, learns quickly, and protects people when the technology does something unexpected.
Conclusion
The European Commission’s draft guidance on serious AI incident reporting is a warning bell and a roadmap. It tells providers of high-risk AI systems that safety, accountability, and post-market monitoring will be central to AI compliance in Europe. It also gives businesses time to prepare before the rules fully apply.
The smartest move now is to identify high-risk AI systems, create escalation procedures, connect AI governance with existing incident response programs, and train teams to recognize when an AI issue may become a legal reporting event. The EU AI Act is not asking companies to predict every possible failure. It is asking them to pay attention, act quickly, and take responsibility when high-risk AI causes serious harm.
