EU AI Act · Article 73 · GDPR Article 33
An AI system returns a wrong result. At what point is that a reportable incident, who has to be told, and how long do you have? Three questions, two bodies of law, two clocks running independently.
Incident management is the obligation nobody cares about in calm conditions and that decides everything when it matters. It is also the one compliance task where preparation does not merely reduce effort but changes the outcome: a missed reporting deadline cannot be made up later.
The uncomfortable part is that the hardest decision cannot be delegated. It is taken under time pressure, on incomplete facts, and it reads: is this a reportable incident under the regulation, or a malfunction we fix internally?
Not every error is an incident
The AI Act defines a serious incident narrowly. What is meant are malfunctions or incidents that directly or indirectly lead to one of the following: the death of a person or serious damage to their health, a serious and irreversible disruption of the management or operation of critical infrastructure, an infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment.
That threshold is higher than it looks on first reading. A chatbot giving incorrect product information is not a serious incident. A classification system mis-sorting a batch is not. Both are quality problems that belong in quality management — and possibly grounds for re-assessing the system, but not for a report.
Conversely, the third category — infringement of fundamental rights obligations — is routinely underestimated, because it presupposes no visible damage. A system systematically filtering out applications on a protected characteristic causes no personal injury and no operational disruption. It infringes fundamental rights obligations nonetheless, in every single case in which it was used.
The mistake that gets expensive
The judgement "just a software bug" is usually made by whoever finds the bug — typically someone in the business unit or in support who does not know the regulation's categories and does not need to. Which is exactly why the classification does not belong at the point of discovery but with a named office. What is needed at the point of discovery is only the duty to report it onward — not the ability to assess it.
Who reports what to whom
The reporting routes differ by role, and they do not all run in the same direction. Deployers do not report to market surveillance alone but first to the provider — because the provider has to perform the analysis and correct the system.
The first row contains an obligation that tends to queue behind the others in the rush and is in practice the fastest-acting one: suspending use. Reporting a serious incident while leaving the system running means the actual containment has not happened — and it documents at the same time that human oversight had no authority to intervene.
The deadlines, and why a table here would mislead
Article 73 graduates the reporting deadlines by type of incident. The general rule requires reporting immediately after the provider has established, or could reasonably have established, a causal link between the system and the incident, subject to an outer limit. For particularly grave cases — a widespread infringement, say, or a serious disruption of critical infrastructure — that limit shortens considerably; where a death has occurred, a separate deadline applies.
We deliberately give no table of deadlines here. Which deadline applies depends on how the incident is classified, and that classification is precisely the part that is contested when it matters. A table conveys a calculability that does not exist — and invites starting the clock only once the classification is settled.
The working rule that holds: the clock runs from awareness, not from certainty. In practice: record the time of awareness, classify and report in parallel, and supplement the report as the picture firms up. An incomplete report inside the deadline is foreseen by both regimes; a complete one after it has expired is not.
The GDPR is more precise here and therefore the better guide for the process: 72 hours from awareness, reporting in stages permitted, and a documentation duty even where you decide against reporting. That last duty is worth adopting into your own process regardless of whether you formally owe it: the reasoning for why an event was not reportable is exactly the record you need at a later review.
Two clocks running independently
One event can trigger both reporting duties, only one, or neither. The duties examine different things, so inferring one from the other does not work. Three constellations show the difference.
AI Act only
A high-risk system systematically disadvantages a group of people. The data was processed correctly, nothing leaked, there is no personal data breach — but there is an infringement of fundamental rights obligations. Reportable under the AI Act, not under Art. 33 GDPR.
GDPR only
A misconfiguration leaves an AI system's log file publicly reachable. The system works flawlessly, nobody was harmed — but personal inputs and outputs were exposed. A data breach, not a serious incident under the AI Act.
Both
A clinical decision support system gives a wrong recommendation because patient records were swapped, and the recommendation is acted on. Damage to health and a data breach at once — two reports to two authorities, on two differently running deadlines.
The practical conclusion is inconvenient: you need an office wearing both pairs of glasses. A process that ends at the data protection officer will not recognise the first constellation. One that runs only through the AI lead will not recognise the second.
What has to be settled beforehand
Five decisions determine whether an incident is acted on or discussed. All five cost an hour in calm conditions.
Who classifies — and who does not
A named person with a deputy, reachable outside office hours too. The business unit reports inward and does not classify. This separation is the single most effective point in the whole process, because it removes the most common source of error: the reassuring first assessment made by the person involved.
Three to five worked examples
From your own field, with the classification reached and the reasoning. Not as training material but as a yardstick: the question in an incident is then not "is this serious" but "is this closer to example two or example four". That question can be answered in minutes.
The contact routes, concretely
Name and availability of the contact at the provider, the route to the competent market surveillance authority, the route to the data protection supervisor. For providers outside the EU, the authorised representative belongs on that list. These are details you obtain at procurement and do not research during an incident.
Who may switch the system off
By name, and with authority to do it without asking. If shutdown depends on an approval only reachable the next working day, the system keeps running straight through the incident — and every hour of that ends up in the file.
Preserving evidence before the routine runs
Secure the logs and the inputs and outputs for the period concerned before an automatic deletion routine reaches them. This is where the deletion policy and incident management touch: what is scheduled for deletion may be exactly the evidence the provider and the authority need. Without an exception for this case, you delete your own exoneration.
The actual point
Incident management is usually understood as a reporting process and is in practice a decision process. The report itself is a form; the difficulty lies before it, in the question of whether a report is owed — and that question is answered badly when it is first posed under pressure.
That settling it in advance pays off is not only a matter of risk. In setting fines it expressly counts whether a company reported the infringement itself and to what extent it cooperated with the authority. Self-reporting mitigates; discovery by a third party does not. The ability to report cleanly within hours is therefore not an end in itself but an item in the same calculation.
And the rest is unspectacular: a named person, five worked examples, three phone numbers, an authority to switch off, and an exception in the deletion routine. None of it needs a project. It only needs somebody to write it down before it is needed.
With SimpleAct
In an incident, lose no time searching.
EU AI Act and GDPR in one platform: register AI systems centrally, classify them rule-based, assign responsibilities and export audit-ready evidence at any time. Made in Germany, hosted in Germany.
Start your AI inventory →This article is for general information only and does not constitute legal advice. Last updated: 4 October 2026.
Tags
Ready to put EU AI Act compliance on autopilot?
SimpleAct helps you inventory AI systems, classify risk, and structure and keep the required documentation up to date.
Kamill Jarzebowski | SimpleAct
Author · SimpleAct Team