DORA and EU AI Act Incident Reporting: Separate Duties, One Evidence Record

Where the law stands as of November 2026

The EU AI Act (Regulation (EU) 2024/1689) is in force, and its text includes serious incident reporting duties for providers and deployers of high-risk AI systems. What has changed is timing. The Digital Omnibus on AI, which amends the Act, entered into force on 27 July 2026. It moves the application of the high-risk rules from the original date of 2 August 2026 to 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI embedded in products.

DORA (Regulation (EU) 2022/2554) requires financial entities to run an ICT-related incident management process and to report major ICT-related incidents to the relevant competent authority. No amendment to those provisions is reported.

Two practical points follow. First, record in your governance documents which AI Act application date you rely on for each system, and when you last checked it. Second, do not let the later AI Act dates delay incident process design. DORA incident duties already apply to AI-dependent ICT services, and the shared record described below serves both regimes.

DORA and the EU AI Act side by side

The two regimes differ on every dimension that determines who files what, and when. Triage each AI-related event against both definitions separately.

• Trigger: DORA: a major ICT-related incident. EU AI Act: a serious incident, defined as an incident or malfunctioning of an AI system that directly or indirectly leads to listed outcomes, such as death or serious damage to health, serious and irreversible disruption of critical infrastructure, infringements of obligations under Union law protecting fundamental rights, or serious damage to property or the environment.
• Who reports: DORA: the financial entity, directly. EU AI Act: the provider of the high-risk AI system. A deployer that identifies a serious incident must immediately inform the provider first.
• Recipient: DORA: the relevant competent authority. EU AI Act: market surveillance authorities of the Member States where the incident occurred. The deployer also informs the importer or distributor.
• Clock: DORA: the timelines set in its reporting provisions. EU AI Act: immediately after a causal link or its reasonable likelihood is established, and no later than 15 days after the provider or deployer becomes aware. For a widespread infringement or a serious incident under Article 3, point (49)(b), no later than two days.
• Underlying duty: DORA: record all ICT-related incidents and significant cyber threats, and identify, document and address root causes. EU AI Act: assess causal link between the AI system and the incident.
• Escalation: DORA: at least major incidents reach senior management, and the management body is informed of impact, response and added controls.

When one AI-related event can fall under both regimes

An AI system embedded in an ICT-dependent financial process can fail in a way that disrupts that process and also meets the AI Act definition of a serious incident. Consider an AI system whose malfunction disrupts a critical service. The same event may be a major ICT-related incident for the financial entity and, if the system is high-risk and the outcome is among those listed, a serious incident under the AI Act. The definitions are independent, so each must be assessed on its own.

The event can also trigger one regime and not the other. An AI output may cause a fundamental-rights harm without any ICT disruption that DORA would classify as major. Conversely, an ICT outage may involve an AI component without meeting the serious incident definition. Compliance teams should run two classification decisions on every AI-related event and record the reasoning for each.

The financial entity's role also matters. For each AI system it needs to establish whether it is the provider, the deployer, or both. That determines whether it files with market surveillance authorities itself or notifies the provider first. This guide does not constitute legal advice, and role and classification questions should be confirmed with counsel.

Assigning ownership across compliance, security and AI teams

Reports fail less often on content than on handoffs. DORA requires incident handling that is consistent and integrated, so the DORA report typically sits with the security and operational resilience function, with compliance owning the submission to the competent authority. The AI Act chain needs its own named owner, because the sequence matters: provider first, then importer or distributor and authorities when the entity is the deployer.

The AI team holds the facts about system behavior and must be obliged to supply them to the shared record on a defined schedule. Compliance should own the classification decisions and the notification log. Senior management escalation should be defined in advance, since DORA requires at least major incidents to be reported upward.

Also keep records beyond the incidents you judge reportable. DORA requires all ICT-related incidents to be recorded, and a later reclassification is only defensible if the original evidence was retained.

Closing the evidence gap with runtime enforcement

Both regimes ultimately depend on the same question: what was the AI system permitted to do, and what did it do? A root-cause statement under DORA and a causal-link assessment under the AI Act both need that factual basis. Reconstructing it afterward from scattered application logs, prompts and chat exports is slow and often incomplete. Evidence created at the moment of each decision is more reliable.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call can be allowed, redacted, blocked, rate limited, or escalated for human approval. That enforcement is applied at runtime, not reviewed after the fact, and it generates audit-ready evidence mapped to the EU AI Act, among other frameworks. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

When evaluating any approach, ask whether the records show the policy that applied, the decision taken, any human approval, and the tool calls made, and whether they can be retrieved quickly enough to meet the applicable clocks. Evidence supports your reports, but it does not by itself establish compliance. Classification, ownership and submission remain your decisions.