Incident handling should provide a single intake route for AI incidents and concerns, triage each report against the serious incident definition and the risk to health, safety and fundamental rights, escalate serious incidents to the provider, the market surveillance authority and, for general-purpose models, the AI Office as the Act requires, take corrective action, and record the learning. Providers and deployers have distinct reporting duties, and the handover between them must be defined before an incident occurs.
What counts as an incident for handling purposes?
For handling purposes, an incident includes any event where an AI system malfunctions, produces an unexpected or harmful output, fails to perform as intended, or creates a risk to health, safety or fundamental rights, as well as complaints, near misses, and patterns in logs or feedback that suggest a systemic problem. The Act defines a serious incident by reference to serious outcomes, including death or serious harm to health, serious disruption of critical infrastructure, infringement of fundamental rights, and serious harm to property or the environment, and providers must report serious incidents under Article 73, while general-purpose model providers have a parallel duty under Article 55. A handling system should therefore record every report, triage it against the serious incident definition, and treat near misses and patterns as learning inputs even where they do not meet the reporting threshold. A system that records only reported serious incidents, without near misses, will miss the early warnings that could prevent a serious incident.
How should intake and triage work?
Intake should be a single, known route that staff, deployers, downstream providers, and affected people can use, with a clear form that captures the system, version, date, context, output, harm or risk, and evidence. Triage should be carried out promptly by a named owner, who assesses severity, urgency, and whether the serious incident threshold may be met, and who assigns the incident to an investigator. Triage should not be delayed while the full facts are gathered: an initial assessment, with a timetable for investigation, should be recorded on receipt, and the incident should be escalated immediately where a serious outcome is possible. The intake and triage records should be linked to the system inventory, the risk file, and the log entries for the incident, so that the investigation can follow the evidence without searching across unrelated systems.
For the broader regulatory framework, see AI governance planning checklist.
What reporting duties apply, and to whom?
Providers of high-risk systems must report serious incidents to the market surveillance authority of the Member State where the incident occurred, without undue delay after establishing a causal link or a reasonable likelihood of such a link, as Article 73 provides, and must investigate and take corrective action. Deployers must inform the provider, the importer or distributor, and the relevant market surveillance authority where they become aware of a serious incident, as Article 26 provides, and must suspend use where appropriate. Providers of general-purpose models with systemic risk must track, document and report serious incidents to the AI Office and relevant national authorities under Article 55. The reporting workflow should name the owner for each report, the authority to be notified, the timetable, and the information to be included, and should record the notification date and reference. A report that is drafted but never sent, or sent to the wrong authority, does not meet the duty.
How should investigation and corrective action work?
Investigation should establish what happened, why, and what the consequences were, using logs, documentation, testing, and interviews with the people involved, and should record the findings, the root cause, and the corrective action. Corrective action can include a design or data change, a limitation on use, an update to instructions, additional oversight, or withdrawal or recall of the system, depending on the risk. The action should have an owner, a timetable, and a check that it worked, and should be linked to the risk management file and, where the change is substantial, to a new conformity assessment. Deployers and providers should cooperate on investigation, sharing the information each holds, through the channel agreed for the system. An investigation that identifies a cause but takes no corrective action, or that takes action without checking it worked, leaves the risk unaddressed.
How should escalation and learning be organised?
Escalation should follow the governance route, with triggers for senior management, legal, and board notification where the incident is serious, widespread, or likely to attract authority attention. Learning should be captured in a dated incident review, shared with the teams that operate similar systems, and fed into risk management, testing, training, and supplier management. The review should ask whether the incident reveals a gap in design, data, oversight, instructions, or monitoring, and should assign actions for each gap found. Incident records should be retained for the period the organisation sets for governance records, with access controls that protect personal data and confidential information. A handling system that resolves individual incidents without learning will repeat the same failure in a different system or deployment.
Continue with AI governance operating model.
What does this guide not decide?
This guide does not decide whether a particular event is a serious incident, whether a causal link exists, whether a report was made in time, or what corrective action is required. It does not assess an investigation or a reporting decision. Those questions depend on the event facts, the logs and evidence, the system and deployment, and the consolidated legal text, including Articles 26, 55 and 73. A provider or deployer facing a possible serious incident should seek qualified advice promptly, preserve logs and evidence, notify as the Act requires, and record the triage, investigation, and corrective action with dates and owners.
Frequently asked questions
Must every malfunction be reported to an authority?
No. Reporting duties apply to serious incidents as defined in the Act, where the threshold and causal link conditions in Articles 73 and 55 are met. Every malfunction, near miss and complaint should still be recorded, triaged, investigated and learned from, even where it does not meet the reporting threshold.
Who reports: provider or deployer?
Both have duties. Deployers must inform the provider and the relevant authority where they become aware of a serious incident, and providers must report to the market surveillance authority and investigate. The handover, timetable and information flow should be agreed before an incident occurs and recorded for each system.
Should use be suspended after a serious incident?
Deployers should consider suspension where continued use would create an unacceptable risk, and providers should consider corrective action including withdrawal or recall where needed. The decision, the reasoning, and the date should be recorded, and the authority should be informed as the Act requires.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗Commission AI Act Service Desk timeline ↗European Commission AI Act overview ↗