The reporting clock: Article 3(49), Article 73, and the logs
Monitoring, incidents and audit · 10 min read
In this module
Incident reporting is the one area where governance quality is measured in hours. A missed deadline cannot be improved next quarter, and deadlines are rarely missed through ignorance of the rule. They are missed because the organisation spent the available time deciding whether the rule applied.
What counts as a serious incident
Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads to any of: the death of a person or serious harm to a person's health; a serious and irreversible disruption of the management or operation of critical infrastructure; infringement of obligations under Union law intended to protect fundamental rights; or serious harm to property or the environment.
The third limb is the one that reaches financial services hardest and is least anticipated. An infringement of Union law protecting fundamental rights includes discrimination. A pricing or claims system producing systematically worse outcomes for a protected group is not only a fairness finding; it is potentially a reportable serious incident, and the people who find it are usually in a model validation team with no reason to know that.
Write the definition into your own severity taxonomy before you need it, with worked examples from your own business. A taxonomy that maps your internal severity levels onto the statutory categories converts a two-hour argument into a lookup.
Three deadlines, and when the clock starts
Article 73 sets reporting to the market surveillance authority:
- 15 days generally, after the provider establishes a causal link, or the reasonable likelihood of one, between the AI system and the serious incident;
- 10 days where the incident involves the death of a person;
- 2 days in the event of a widespread infringement or a serious and irreversible disruption of the management or operation of critical infrastructure.
An initial, incomplete report followed by a complete one is expressly permitted. Use that. The common failure is holding the report while the investigation completes, on the reasonable-sounding basis that a partial report is unhelpful. The deadline does not wait for certainty, and the permission to report incompletely exists precisely to remove that excuse.
Note the trigger: establishing a causal link or its reasonable likelihood. The clock does not start when the investigation concludes. It starts when a reasonable likelihood is established, which is often the moment the analyst who found the pattern sends the message. Record that moment. If you cannot say when you established reasonable likelihood, you cannot demonstrate you met the deadline, and the authority will pick the earliest date in your own logs.
Deployers sit in this chain too. A deployer who identifies a serious incident informs the provider, and Article 26 requires suspension of use and notification where a risk is identified. The practical sequence is: stop, tell the provider, then the distributor and the market surveillance authority as applicable.
Other clocks that run at the same time
Do not run a single incident process against the AI Act alone. California SB 53, effective 1 January 2026, requires critical safety incident reporting to Cal OES within 15 days, or 24 hours where there is imminent risk of death or serious physical injury. The EU Cyber Resilience Act requires, from 11 September 2026, a 24-hour early warning and 72-hour notification. Swiss Article 24 revFADP requires breach notification to the FDPIC as soon as possible, and there is no 72-hour deadline in Swiss law.
Build one intake and one triage that fans out to the right clocks. Parallel processes owned by different functions guarantee that the shortest deadline is discovered by the team that does not own it.
Logs are what make the report possible
Article 12 requires automatic recording of events over the system's lifetime, and specifies that logs should enable the identification of situations that may present a risk or lead to a substantial modification. Articles 19 and 26(6) set a floor of at least six months for providers and deployers respectively, subject to data protection law.
Six months is a floor, not a target, and for many financial services records it is shorter than the retention you already owe. What matters more is the test: can you reconstruct one decision end to end from the logs. Run that as a drill and fix what fails. Over-retention is its own exposure, so decide the period deliberately.
Worked example: an insurer starts the clock correctly
On a Tuesday, a validation analyst at a health insurer notices that a claims-triage model has been routing claims from a particular postal region to investigation at roughly three times the rate of comparable regions, for about five weeks. The region correlates with a protected characteristic.
The severity taxonomy maps this to the Article 3(49) third limb: potential infringement of Union law protecting fundamental rights. That mapping was written a year earlier, so it takes minutes rather than a meeting.
The analyst's message on Tuesday is recorded as the point at which reasonable likelihood of a causal link was established, and the fifteen-day clock is started from it. Nobody argues that the clock should start later, because the taxonomy and the intake procedure already decided that question.
Three things happen in parallel. Operations suspends automatic routing for the affected segment and reverts to manual assessment. Compliance files an initial report inside the deadline, stating what is known and what is not, with the complete report to follow. And the investigation runs, finding that a data quality issue in an address-matching step had been mislabelling a set of claims, which is neither a model failure nor an excuse.
The record that matters afterwards has five items: when the pattern was found, when reasonable likelihood was established and by whom, what was suspended and when, what was reported and when, and what changed as a result. An insurer that can produce those five items has demonstrated a functioning control. One that can produce a thorough root cause analysis and no timeline has demonstrated the opposite.
As of 24 September 2026.
You can read every lesson without an account. Signing in keeps your place and unlocks the assessment.
