AI incident management under ISO 42001 and the EU AI Act: from detection to reporting duty

A customer service chatbot that makes a commitment that costs the organization money. A screening model that systematically scores one group of candidates lower. A vendor that updates its model, after which the error rate quietly increases. These are AI incidents, and they have one thing in common: a classic incident process often does not even recognize them. No system goes down, there is no data breach, and yet there is damage or a real risk of it. ISO 42001 expects organizations to be prepared for this, and the EU AI Act adds legal reporting obligations with hard deadlines. In this article we explain what an AI incident is, what the standard and the law require, and how to set up a process that works in practice.

## What is an AI incident?

An AI incident is broader than a security incident. In practice we distinguish five categories. First, incorrect or harmful output: fabricated answers, wrong advice or decisions with consequences for customers or the organization. Second, bias and discrimination: outcomes that systematically disadvantage certain groups, for example in recruitment or credit scoring. Third, privacy incidents: personal data ending up in prompts, output that discloses other people's personal data, or data unintentionally reused for training. Fourth, security incidents specific to AI: prompt injection, jailbreaks, data poisoning or compromised API keys of model providers. Fifth, degradation: model drift or a behavioral change after a vendor update, causing output quality to deteriorate gradually.

What these categories have in common: there is usually no technical failure. Monitoring that only looks at availability and error messages sees nothing. In practice, the signal often comes from people: an employee noticing strange output, a customer complaining, a journalist calling. That has direct consequences for how you set up detection.

## What ISO 42001 expects

ISO 42001 follows the familiar management system logic. The standard expects you to monitor AI systems, identify nonconformities and take corrective action (clause 10), and Annex A contains controls around responding to incidents and informing interested parties. More important than the text of the standard is what a certification auditor wants to see: a definition of what your organization considers an AI incident, reporting channels that employees actually know, assigned roles with a mandate, registration of incidents and their handling, and demonstrable learning. The latter means root cause analysis and, where needed, updating the risk assessment, the policy or the training.

Mind the difference between design and operating effectiveness. A playbook that has never been used or exercised does not convince an auditor. A registered incident with a thorough follow-up and an adjusted control is strong evidence that the management system actually works.

## What reporting duties the EU AI Act adds

For providers of high-risk AI systems, Article 73 of the EU AI Act introduces an obligation to report serious incidents to the market surveillance authority. A serious incident is, in short, an incident that leads to death or serious harm to health, a serious and irreversible disruption of critical infrastructure, an infringement of obligations protecting fundamental rights, or serious harm to property or the environment.

The deadlines are tight. Reporting must happen immediately after a causal link between the AI system and the incident has been established (or is reasonably likely), and no later than fifteen days after becoming aware. In the event of death, the limit is ten days, and in the event of a widespread infringement or a serious disruption of critical infrastructure, two days. Deployers who identify a serious incident must inform the provider without delay.

Also account for overlap. The same event can simultaneously be a data breach under the GDPR (reportable within 72 hours) and a significant incident under NIS2. Deadlines and authorities differ, so your triage must assess reporting duties in parallel rather than one after the other.

## A workable AI incident process in five steps

### Step 1: define and classify

Include a definition of AI incidents with concrete examples per category, and link the process to your AI register so that the potential impact of an incident is clear for each system. Work with severity levels and explicitly mark the category "potentially legally reportable", so that this assessment never depends on one employee's judgment.

### Step 2: set up detection and reporting channels

Combine technical monitoring (output quality, drift, abuse patterns, error rates) with human channels: an accessible internal reporting point, structural analysis of customer complaints, and contractual agreements with vendors about reporting their incidents and model changes. With AI, the human channels matter at least as much as the technical ones.

### Step 3: determine the response in advance

Containment looks different for AI than for a hacked server. Think of temporarily switching off a system and falling back on human handling, rolling back to a previous model version, or adjusting a prompt or configuration. Decide in advance who has the authority to take an AI system offline, even if that affects a primary process. During an incident there is no time for that discussion.

### Step 4: arrange reporting and communication

Work out the escalation lines: who assesses whether a legal reporting duty applies, who reports to which authority, and who informs customers and affected individuals. Prepare contact points and draft texts. You will not meet the two-day deadline from the AI Act if you still have to figure out where to file during the incident.

### Step 5: learn and correct

Perform a root cause analysis: was it the data, the model, the configuration or the usage? Update the risk assessment, the policy and, where needed, the training, test the adjustment and record everything. That record is also your evidence for the certification audit.

## Connect to your existing incident process

Do not build a parallel process next to your existing incident management from ISO 27001 or ITIL. Extend the existing process: AI categories in the triage, the additional reporting duties in the escalation matrix and AI expertise in the response team. One registration system prevents incidents from falling through the cracks because it is unclear whether something is a security or an AI incident.

## Common mistakes

The mistakes we see most in practice: counting only security incidents so that bias and output incidents remain invisible, no reporting channel for employees who notice strange output, looking up legal deadlines only during the incident, keeping vendor incidents out of scope because a contractual reporting obligation is missing, and recording nothing, so that no operating effectiveness can be demonstrated at the certification audit.

A registered and well-handled incident is not a sign of failure. It is precisely the evidence that your AI management system does what it is meant to do.