AI Act Serious Incident Reporting

Skip key takeaways

Updated August 25, 2026

• Four limbs apply, not three; any one of them is enough Article 3, point (49) covers death or serious health harm, serious and irreversible disruption of critical infrastructure, infringement of obligations under Union law intended to protect fundamental rights and serious harm to property or the environment, joined by "any of the following".
• The limb selects the clock, and the shortest applicable clock wins Fifteen days is the general ceiling, two days applies to a widespread infringement or a point (49)(b) critical-infrastructure incident, and 10 days applies where a person died. Severity does not select the deadline, classification does.
• Article 73 did not change, but the recipient of the report did Regulation (EU) 2026/1744 replaced Article 75, and new Article 75(1a) routes serious incidents to the AI Office for providers inside its competence. The financial-institution carve-out from that competence is conditional on Article 74(6), which itself only reaches systems in direct connection with the provision of financial services.
• You cannot fix the system before you tell the authority Article 73(6) forbids any investigation that alters the system in a way which may affect a later evaluation of causes before the competent authorities have been informed, so mitigation and investigation need separate paths in the architecture.
• The obligations bite on 2 December 2027, not on 2 August 2026 Regulation (EU) 2026/1744 moved standalone Annex III high-risk applicability to 2 December 2027 and the Annex I route to 2 August 2028, with Article 6(5) carved out of the deferral.

Copy takeaways

A production model does something it should not have done, the alert fires and the runbook says notify the vendor. Under the AI Act that runbook is a legal instrument with a clock attached, and which clock runs depends on which limb of a single definition the event falls into. Teams that have worked through AI Act high risk classification usually treat Article 73 as a footnote to that conclusion. It is where the classification becomes an operational duty, and compressing four limbs into one deadline erases distinctions the Regulation makes on purpose. That makes it an engineering problem before it is an AI governance problem, because the classification has to happen inside the incident channel, in hours, by people who are mid-incident.

In short: the AI Act defines a serious incident in four alternative limbs, and any one of them is enough. Three deadlines attach to those limbs, 15 days as the general rule, two days for a critical-infrastructure incident or a widespread infringement, and 10 days where a person died, so the shortest applicable clock governs. Article 73 was not amended in 2026, but Regulation (EU) 2026/1744 replaced Article 75, and providers inside the AI Office's competence now report to the AI Office rather than to a national authority. The obligations themselves apply from 2 December 2027 for Annex III high-risk systems, not from 2 August 2026.

What counts as a serious incident under the AI Act

Article 73 never defines its own trigger. It borrows one, from Article 3, point (49), and that definition is easy to compress into fewer limbs than it has. Its chapeau says a serious incident means an incident or malfunctioning of an AI system that "directly or indirectly leads to any of the following", and four items follow, in Regulation (EU) 2024/1689. Two words in that phrase carry the weight. Indirectly pulls in downstream effects, so a scoring model that never touches a person can still be the cause of an incident that reaches one through a decision built on its output. Any makes the four items alternatives rather than a cumulative test.

The four are short enough to quote in full. The first is "the death of a person, or serious harm to a person’s health". Its second limb is "a serious and irreversible disruption of the management or operation of critical infrastructure". The third is "the infringement of obligations under Union law intended to protect fundamental rights". The fourth is "serious harm to property or the environment". All four, and the chapeau above them, are in Regulation (EU) 2024/1689 as published in the Official Journal, and Regulation (EU) 2026/1744 left Article 3, point (49) alone.

Why a compressed definition attaches the wrong clock

Content that summarizes point (49) as harm to health or fundamental rights has dropped two limbs, and one of them changes the deadline. The critical-infrastructure limb, point (49)(b), is the only one of the four that carries the two-day clock. A team working from a three-limb summary has no field in which to record that an incident was a point (49)(b) event, so it cannot compute the deadline it is on. That is the difference between a report filed on day two and one filed on day 15 against a duty that expired on day two.

Three reporting clocks and what starts each one

The general rule sits in Article 73(2), and it has two halves. The report is made "immediately after the provider has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link", and in any event "not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident". Those are two different moments. Awareness starts the outer limit. The causal link, or its reasonable likelihood, starts the immediate duty. A team that only records the awareness timestamp has instrumented half of the provision. Article 73(2) adds a second subparagraph stating that the reporting period "shall take account of the severity of the serious incident", which means the 15 days is a ceiling and not an entitlement. All three passages are in Regulation (EU) 2024/1689, Article 73.

Article 73(3) cuts that down. "In the event of a widespread infringement or a serious incident as defined in Article 3, point (49)(b)", the report goes out immediately and "not later than two days after the provider or, where applicable, the deployer becomes aware of that incident". Article 73(4) sets the third clock, for the death of a person. There the report is due "immediately after the provider or the deployer has established, or as soon as it suspects, a causal relationship between the high-risk AI system and the serious incident", and at the outside "not later than 10 days after the date on which the provider or, where applicable, the deployer becomes aware of the serious incident". Note the word "suspects". The death clock starts earlier in the epistemic sequence than the general one does. All three paragraphs are in Regulation (EU) 2024/1689, unamended.

Widespread infringement is a defined term, and its two limbs are not the same

The two-day clock is usually reported as the critical-infrastructure deadline, which is half the trigger. "Widespread infringement" is defined at Article 3, point (61), and it too has alternative limbs with different thresholds. The first limb catches an act or omission contrary to Union law protecting the interest of individuals that "has harmed or is likely to harm the collective interests of individuals residing in at least two Member States" other than the state where the act originated, where the provider is located or where the deployer is established. The second limb requires more Member States and adds a similarity test: it catches an act or omission that "has common features, including the same unlawful practice or the same interest being infringed, and is occurring concurrently, committed by the same operator, in at least three Member States". Both are in Regulation (EU) 2024/1689, Article 3.

Two Member States against three, with a common-feature test on the higher one. For a system deployed across a European footprint that is a live question on the first morning of an incident. Answer it too generously and a routine defect becomes a two-day filing. Answer it too narrowly and a genuine multi-state harm gets 15 days it was never entitled to.

The incident taxonomy an engineering team has to implement

Everything above collapses into a data model. A triage record whose only classification field is a severity level cannot produce an AI Act deadline, because the Regulation selects the deadline by limb and by circumstance rather than by severity. Four fields have to be first class in the incident record, and each has to stay editable after creation, because all four routinely change as an investigation proceeds.

Limb classification comes first, as a set rather than a single value, because one event can satisfy more than one limb. Then the awareness timestamp, recorded per legal entity, since Article 73 names the provider and, where applicable, the deployer as separate subjects of awareness. Then causal-link status, with three states rather than two, because Article 73(2) turns on an established link or the reasonable likelihood of one while Article 73(4) turns on suspicion. Last, the widespread-infringement determination with its own Member State list, because the point (61) test cannot be derived from the limb classification at all.

The deadline is computed, never entered

Given those four fields the shortest applicable clock is a pure function, and it should be implemented as one rather than asserted by a human in a text box. A record carrying limb (b) alongside limb (a) is on the two-day clock, not the 10-day one, because two is shorter. The function should recompute on every field change, since Article 73(5) contemplates a moving picture. Either the provider or deployer "may submit an initial report that is incomplete, followed by a complete report", from Regulation (EU) 2024/1689. The Regulation would rather have a thin report on time than a complete one late, and a triage system built around a single final submission fights that design. An AI governance framework that stops at policy documents will not produce any of this, because none of it is a policy question.

Who receives the report, and why that changed on 27 July 2026

Article 73(1) still says what it always said. "Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred", in Regulation (EU) 2024/1689. Read on its own that sentence is now incomplete, because a different article moved underneath it.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, replaced Article 75 rather than editing it. The old article covered mutual assistance and the monitoring of general-purpose AI systems, and its first paragraph was a two-sentence grant of monitoring powers to the AI Office. The replacement is headed "Market surveillance and control of AI systems and mutual assistance" and opens with a rule that the AI Office "shall be exclusively competent for the supervision and enforcement of the obligations under this Regulation" over two categories of system. One category is systems "based on general-purpose AI models where the model and the system are developed by the same provider, or by providers forming part of the same undertaking as that provider", subject to four carve-outs. The second is systems "integrated into a very large online platform or very large online search engine designated in accordance with Regulation (EU) 2022/2065". Quoted from Regulation (EU) 2026/1744.

The consequence for incident reporting is in a new paragraph. Article 75(1a) provides that "By way of derogation from Article 73, providers of high-risk AI systems subject to the competence of the AI Office pursuant to paragraph 1 of this Article shall report any serious incidents to the AI Office", that Article 73(2) to (9) applies mutatis mutandis, and that the AI Office then transmits the information onward to the market surveillance authority of the provider's Member State, from Regulation (EU) 2026/1744. Every deadline in this article survives that reroute unchanged. Only the addressee moves.

The financial-institution carve-out is conditional, not a blanket exclusion

One of the four carve-outs from AI Office competence covers "AI systems provided by law enforcement authorities, border management authorities and financial institutions, insofar as those AI systems fall under Article 74(6)", from Regulation (EU) 2026/1744. The last clause is doing real work. Article 74(6) makes the national financial supervisor the market surveillance authority for a regulated firm's high-risk systems, but only "in so far as the placing on the market, putting into service, or the use of the AI system is in direct connection with the provision of those financial services", from Regulation (EU) 2024/1689. A bank system that is not in direct connection with a regulated financial service does not fall under Article 74(6), so the carve-out does not reach it, and where the system otherwise sits in AI Office competence the report goes to the AI Office. A FinTech that assumes its prudential supervisor receives everything has assumed away a condition the text spells out twice.

For most readers there is a cleaner answer than arguing about the carve-out. That competence is entered only through the two categories above, and it reaches deployers narrowly, applying to them "only when they are also the provider or form part of the same undertaking as the provider", from Regulation (EU) 2026/1744. A bank that fine-tunes a third-party foundation model into a credit decisioning system is neither that model's provider nor part of the same undertaking, so the class is never entered and Article 73(1) applies on its own terms. Test entry first and the carve-out second, and most firms stop at the first step.

After the report: investigation, corrective action and the change freeze

Filing does not close the obligation. Article 73(6) requires the provider, without delay, to "perform the necessary investigations in relation to the serious incident and the AI system concerned", and adds that "This shall include a risk assessment of the incident, and corrective action." The second subparagraph is the one that changes engineering practice. The provider "shall not perform any investigation which involves altering the AI system concerned in a way which may affect any subsequent evaluation of the causes of the incident, prior to informing the competent authorities of such action", from Regulation (EU) 2024/1689.

Read that against a normal incident response and the friction is obvious. The instinctive first move is to roll back the model version or retrain on corrected data, and either can affect a later evaluation of causes, so the Regulation puts a notification in front of them. That argues for keeping mitigation and investigation on separate paths, and for a design where traffic can be routed away from a model without destroying the state that produced the incident.

Two more clocks that are not the provider's

The authority has its own deadline. Article 73(8) requires the market surveillance authority to take appropriate measures under Article 19 of Regulation (EU) 2019/1020 "within seven days from the date it received the notification". A fourth clock comes from Article 79, which supplies the deployer's suspension trigger in its second paragraph. Article 79(1) does not define its risk threshold in AI Act terms at all, defining it instead by cross-reference to a product presenting a risk under Article 3, point 19 of Regulation (EU) 2019/1020, "in so far as they present risks to the health or safety, or to fundamental rights, of persons". Where the authority finds non-compliance it requires corrective action, withdrawal or recall "within the shorter of 15 working days, or as provided for in the relevant Union harmonisation legislation". Both from Regulation (EU) 2024/1689. Fifteen working days is not fifteen days, and a remediation plan built on the calendar reading is already late.

Deployers are inside the reporting chain

A firm that buys a high-risk system rather than building one is not a bystander. Article 26(5) requires that "Deployers shall monitor the operation of the high-risk AI system on the basis of the instructions for use", and where use in accordance with those instructions may result in an Article 79(1) risk they must "inform the provider or distributor and the relevant market surveillance authority, and shall suspend the use of that system". On a serious incident the same paragraph prescribes an order rather than a set of recipients. Deployers "shall also immediately inform first the provider, and then the importer or distributor and the relevant market surveillance authorities of that incident", and where the deployer cannot reach the provider, Article 73 applies mutatis mutandis. From Regulation (EU) 2024/1689.

What the financial-services deeming provision does and does not cover

Regulated firms get one concession here and it is narrower than it is usually described. For deployers that are financial institutions already subject to internal governance requirements under Union financial services law, "the monitoring obligation set out in the first subparagraph shall be deemed to be fulfilled by complying with the rules on internal governance arrangements, processes and mechanisms pursuant to the relevant financial service law". That covers monitoring. It does not cover the suspension duty, the escalation duty or the serious-incident notification, none of which are deemed fulfilled by anything. Logs work the same way. Article 26(6) requires deployers to keep automatically generated logs under their control "of at least six months", and a financial institution "shall maintain the logs as part of the documentation kept pursuant to the relevant Union financial service law". That is a filing rule, not a waiver. Both from Regulation (EU) 2024/1689.

When the duty narrows to fundamental rights alone

Article 73(9) is the most commercially significant sentence in the article for a regulated firm, and it is routinely misquoted. For Annex III high-risk systems placed on the market or put into service by providers "that are subject to Union legislative instruments laying down reporting obligations equivalent to those set out in this Regulation, the notification of serious incidents shall be limited to those referred to in Article 3, point (49)(c)", from Regulation (EU) 2024/1689. Point (49)(c) is the fundamental-rights limb, so the narrowing drops the other three limbs out of the AI Act notification for those providers and leaves one standing.

The AI Act names a category, never an instrument

Nothing in Article 73(9) identifies which Union legislative instruments qualify. It describes a class by its effect, reporting obligations equivalent to those set out in the AI Act, and stops there. Financial firms often assume their existing major incident reporting regime satisfies it. That regime exists under the Digital Operational Resilience Act, Regulation (EU) 2022/2554, and the architecture behind it is the subject of our note on DORA compliance software architecture. Whether it is equivalent for Article 73(9) purposes is a judgment the AI Act leaves open, so the safe posture is to keep the full four-limb classification in the record even where notification is narrowed. The narrowing applies to what you send, not to what you have to know, and that distinction is the design brief for compliance and regtech solutions here.

When these obligations actually bite

Material saying that high-risk obligations applied from 2 August 2026 was written before the amendment, or was not updated after it. Regulation (EU) 2026/1744 replaced point (c) of the third paragraph of Article 113, and the current text applies "Chapter III, Sections 1, 2, and 3, with the exception of Article 6(5)" from "2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III" and from "2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I", quoted from Regulation (EU) 2026/1744. Article 73 sits in Chapter III, Section 3, so the incident duty moves with it. The EU AI Act compliance timeline covers the dates that did not move.

What the carve-out and the grandfathering rule do

Article 6(5) is expressly excluded from the deferral, keeping the Commission's classification guidelines on their original 2 February 2026 date, unamended in Regulation (EU) 2024/1689. Legacy systems moved too: Article 111(2) grandfathering now moves with the Article 113 dates above, with public authority deployments still due "by 2 August 2030", from Regulation (EU) 2026/1744. The deadline for building the pipeline is not the deadline for using it. A firm procuring a high-risk system in 2027 will be asked for its incident process during due diligence, long before December.

How Pharos Production builds AI incident reporting pipelines

We build FinTech and insurance systems where the model sits inside a regulated product, and we treat incident reporting as a data path rather than a policy. The incident record carries the four classification fields as structured data, the deadline is computed from them on every change, and the report payload is assembled from that record rather than retyped into a form.

The test we apply is a cold clock read. Take an incident from six months ago, hand it to an engineer who was not on the call and ask which limb it fell into, when awareness was established, when the causal link was, which deadline applied and whether it was met. Our AI governance team works on that record alongside the build, because retrofitting a taxonomy after the first reportable event is expensive.

Sources: Regulation (EU) 2024/1689 (AI Act), base Official Journal text, Articles 3, 26, 72, 73, 74 and 79, via Regulation (EU) 2024/1689; Regulation (EU) 2026/1744 (Digital Omnibus on AI) of 8 July 2026, in force 27 July 2026, as the amending instrument for Articles 75, 111 and 113, via Regulation (EU) 2026/1744. Read on 25 August 2026. Provisions the Digital Omnibus replaced are quoted from the amending instrument, provisions it left alone from the base text. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.

FAQ

Last updated: August 25, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. What is a serious incident under the EU AI Act?

  Copy link Copies a direct link to this answer to your clipboard.

  An incident or malfunctioning of an AI system that directly or indirectly leads to any one of four things: the death of a person or serious harm to health, a serious and irreversible disruption of the management or operation of critical infrastructure, the infringement of obligations under Union law intended to protect fundamental rights or serious harm to property or the environment. The four are alternatives under Article 3, point (49), so one limb is enough, and the word indirectly pulls in downstream effects rather than only immediate ones.

• How quickly must a serious incident be reported?

  Copy link Copies a direct link to this answer to your clipboard.

  Three deadlines apply and the shortest applicable one governs. The general rule in Article 73(2) is immediately after establishing a causal link between the system and the incident or the reasonable likelihood of one, and in any event not later than 15 days after becoming aware.

  Article 73(3) cuts that to two days for a widespread infringement or a critical-infrastructure incident under point (49)(b). Article 73(4) sets 10 days from awareness where a person died, with the duty starting as soon as a causal relationship is suspected.

• Who do you report an AI Act serious incident to?

  Copy link Copies a direct link to this answer to your clipboard.

  Article 73(1) points to the market surveillance authorities of the Member State where the incident occurred. Since 27 July 2026 the replaced Article 75 adds a derogation: providers of high-risk systems subject to the competence of the AI Office report serious incidents to the AI Office instead, with Article 73(2) to (9) applying mutatis mutandis, and the AI Office then transmits the information onward.

  That competence is entered only through systems based on a general-purpose AI model where the model and the system share a provider or undertaking, or systems in a designated very large online platform or search engine. AI systems provided by financial institutions are carved out of it only insofar as they fall under Article 74(6), which itself reaches a system only in so far as it is in direct connection with the provision of those financial services.

• Does the two-day deadline apply to every serious incident?

  Copy link Copies a direct link to this answer to your clipboard.

  No. Article 73(3) attaches it to a widespread infringement or to a serious incident as defined in Article 3, point (49)(b), which is the critical-infrastructure limb. Widespread infringement is itself a defined term at Article 3, point (61), with two alternative limbs, one requiring harm in at least two Member States other than the state of origin and the other requiring at least three Member States plus common features such as the same unlawful practice or the same interest infringed.

  Attaching the two-day clock to every incident type is the most common error in summaries of Article 73.

• Do banks and insurers report every kind of serious incident?

  Copy link Copies a direct link to this answer to your clipboard.

  Not necessarily. Article 73(9) provides that for Annex III systems placed on the market by providers subject to Union legislative instruments laying down reporting obligations equivalent to those in the AI Act, notification is limited to point (49)(c) incidents, the fundamental-rights limb.

  The AI Act names a category of instruments rather than any specific one, so whether an existing sectoral regime qualifies is a judgment the text leaves open. The narrowing applies to what is notified, not to what has to be classified and recorded.

• When do these reporting obligations actually apply?

  Copy link Copies a direct link to this answer to your clipboard.

  Chapter III Sections 1, 2 and 3, with the exception of Article 6(5), apply from 2 December 2027 for systems classified as high risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified as high risk under Article 6(1) and Annex I, following the amendment made by Regulation (EU) 2026/1744. Article 73 sits in Section 3, so the incident duty moves with those dates.

  Material citing 2 August 2026 was written before the amendment, or was not updated after it. Article 6(5) is carved out of the deferral, so the Commission's high-risk classification guidelines keep their 2 February 2026 date.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.