AI incident management: how to detect, respond and document

What is an AI incident?

Operationally, an incident is an unwanted event related to an AI system that calls for investigation of its operation or effects. Examples include incorrect outputs, leakage, significant bias, outage, use outside the intended purpose, unauthorised modification or failed human oversight. An internal response may address people, data, security, operations and compliance even where no authority notification is due.

Operational incident and serious incident are different

An operational incident can include a minor deviation corrected before harm occurs. Article 3(49) of the [consolidated AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:02024R1689-20260727) defines a serious incident as an incident or malfunction of an AI system that directly or indirectly results in (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; or (d) serious harm to property or the environment.

An internal “high” or “critical” rating does not itself satisfy the legal test. Nor does every incorrect output: examine the outcome and the direct or indirect causal link.

When notification is required

Article 73(1) requires providers of high-risk AI systems placed on the Union market to report serious incidents to the market surveillance authorities of the Member States in which they occur. Not every error in every AI tool is reportable. Sector-specific rules matter: Article 73(9) and (10) restrict reports to Article 3(49)(c) incidents for certain Annex III systems with equivalent Union reporting duties and relevant medical devices. Under Article 75(1a), some systems supervised by the AI Office are reported to that office. Check category and competent authority.

Timing of application: the Regulation generally applies from 2 August 2026, but Chapter III, Sections 1 to 3 on high-risk systems apply from 2 December 2027 for Article 6(2)/Annex III and 2 August 2028 for Article 6(1)/Annex I. Transitional provisions may matter. Setting up a response process now is sensible, while the enforceability of specific duties must be checked for the system and date.

Article 73 reporting deadlines

The two- and ten-day periods are special rules, not extra time. Article 73(5) allows an incomplete initial report followed by a full report where needed to meet a deadline. Record when each party first became aware.

Who detects, escalates and reports?

If the deployer cannot reach the provider, Article 26(5) makes Article 73 apply *mutatis mutandis*. Articles 16 and 20 impose specific provider duties on conformity and corrective action; merely using a system does not make an organisation its provider. Importers and distributors have their own roles and receive the deployer's communication described above.

From detection to closure: an operational workflow

This is an adaptable operational sequence. Post-deployment monitoring detects signals; incident management coordinates action: monitoring → signal → incident → investigation → action → improvement.

Detect, record and classify

Alerts, KPIs and KRIs, technical logs, audits, complaints, human interventions and provider notices can reveal an issue. Initially record when it was found, system, version, provider, process, reporter, description, potentially affected people and data, initial evidence and immediate measures. This form is good practice, not a universal AI Act template.

An internal low, medium, high or critical scale can reflect scope, duration, reversibility, human impact, security, data and continuity. Document separately whether Article 3(49) is met and who makes that decision. For a high-risk system, its classification and the organisation's role are decisive.

Contain and assess impact

Depending on risk, restrict a feature, increase human review, revert settings, isolate an integration, block certain outputs, use an alternative process or involve the provider. Shutting down everything is not always necessary. Protect people and preserve evidence before changes that could hinder investigation; under Article 73(6), the provider must inform authorities before altering the system in a manner that may affect subsequent evaluation of causes.

Assess decisions affected, rights, data, security, third parties, reputation and continuity. An existing AI impact assessment, FRIA or GDPR DPIA may need review depending on the context and requirements. An AI incident may overlap with a personal data breach or cybersecurity incident, but these are distinct categories with potentially separate reporting routes. Attacks, prompt injection, data manipulation and unauthorised access call for Security coordination.

Investigate causes, suppliers and traceability

A symptom is what happened, such as more wrong answers. A cause may involve a version, new data, drift, settings, prompt, integration, weak control or several factors together. A timeline, version comparison, data review and “five whys” can help test hypotheses; none is a universal legal method.

Logs and traceability help reconstruct input → output → version → time → human intervention → decision while respecting data protection and the actual logging duties. Check whether oversight existed, was used and enabled intervention, or whether automation bias led staff to ignore warnings. For third-party systems, contracts and AI vendor management should support contacts, escalation, evidence access, analysis, corrections and responsibilities.

Correct, reassess and learn

Immediate correction: revert defective settings. Corrective action: change version validation to prevent recurrence. Preventive improvement: add an alert for anomalous answers. Verify each measure against realistic cases.

A significant incident can trigger incident → [risk reassessment](/en/resources/ai-risk-management) → updated residual risk → revised controls. Review likelihood, impact, ownership and treatment. For high-risk systems, Article 9 provides a continuous and iterative process; following a report, Article 73(6) also requires the provider to investigate, assess risk and take corrective action, while Article 20 applies when it considers a system non-compliant or presenting risk under its conditions.

Possible indicators, without a universal statutory list: incident count and severity, detection and response time, recurrence, investigated causes, concentration by system or supplier and human interventions. Link these to governance KPIs and KRIs to refine thresholds.

What should be retained?

Depending on context, retain alerts or complaints, legally appropriate input/output samples, logs, version, timeline, initial assessment, internal and legal classification, escalation decision, communications, containment, investigation, causes, corrections, validation and closure. Restrict access, protect integrity and apply suitable retention periods.

These are recommended organisational records, not an identical statutory file for every company. Providers and deployers of high-risk systems have specific information, recordkeeping and cooperation duties according to role and situation; AI evidence helps explain what was done.

Business example: customer service assistant

A company uses an AI assistant to support customer service staff. Alerts and complaints reveal an increase in incorrect answers that could mislead customers. The company opens an incident, rates it “high” internally and temporarily restricts one feature while staff review affected answers.

It preserves relevant inputs where lawful, outputs, versions, settings and logs. Investigation identifies a recent configuration change. The team reverts it, validates with samples and adds a control before future changes. The owner, decisions, provider involvement and follow-up checks are recorded.

Separately, the company determines whether its system is high-risk, what role it plays and whether any Article 3(49) consequence occurred. More incorrect answers alone do not prove a serious incident or an Article 73 reporting duty. A personal data breach or sector-specific obligation is assessed through its own rules.

Incident management and ISO/IEC 42001

ISO/IEC 42001 offers a structure for ownership, deviations, performance review, corrective action and continuous improvement. ISO/IEC 23894 can help feed lessons into AI risk management. These frameworks support governance; a management system procedure does not replace the legal conditions, recipients or deadlines in Article 73.

Conclusion

An effective response connects facts, people, decisions and evidence. Defining the process before a problem supports proportionate action; checking the legal definition, role, system and application date separately prevents needless reporting and missed duties.