Short answer. Under DORA, a financial entity has 4 hours from the moment it classifies an AI-related failure as a major ICT incident to submit an initial notification, and no more than 24 hours from first becoming aware of the incident, whichever comes first. An intermediate report follows within 72 hours, and a final report is due within one month. An AI model does not get a separate incident regime. If it supports a critical or important function and it breaks, misfires, or gets manipulated in a way that meets the DORA thresholds, it runs through the same 4-hour, 72-hour, 1-month clock as a payment outage or a data breach.
DORA (Regulation (EU) 2022/2554) does not carve out a separate chapter for artificial intelligence. It regulates ICT risk, and since August 2024 an LLM-based underwriting assistant, a fraud-scoring model, or an agentic workflow that touches a critical function is an ICT system like any other. That has a direct, practical consequence for banks and insurers building AI in 2026: the incident desk that already handles core banking outages now has to recognize an AI failure fast enough to hit a 4-hour clock.
In practice this shows up in three recurring situations:
None of these are hypothetical. The European Supervisory Authorities’ first joint report on DORA major ICT-related incidents, published in 2026, already flags that highly capable AI-driven tools raise the bar on how fast financial entities need to detect and classify failures, not just prevent them.
DORA applies directly to banks, insurers, investment firms, and their critical ICT third-party providers across the EU, including Slovakia and Czechia. Since 17 January 2025, every in-scope financial entity has had to operate a functioning ICT incident management process, and since August 2024 the EU AI Act has added its own obligations for high-risk AI systems on top of that. The two regimes now overlap directly: an AI system that is both “high-risk” under the AI Act and supports a “critical or important function” under DORA can trigger reporting duties under both frameworks from a single failure.
For a CIO or Head of Operations at a mid-market CEE bank, this is not an abstract compliance exercise. A missed 4-hour window is itself a supervisory finding, independent of how serious the underlying AI failure was. Regulators read a slow or missing notification as evidence that the institution does not actually understand its own AI estate, which is precisely the gap DORA was written to close.
DORA gives financial entities 4 hours from classification (24 hours from awareness) for an initial incident notification, 72 hours for an intermediate report, and 1 month for the final report.
Classification runs against the criteria in Commission Delegated Regulation (EU) 2024/1772, the DORA technical standard on incident classification: client and transaction impact, duration, geographical spread, data losses, economic impact, and whether a critical or important function is affected. An AI system trips these thresholds the same way any other ICT system does. A model that silently degrades and misprices 200 transactions before anyone notices can meet the materiality threshold on data integrity and economic impact without a single minute of downtime, a different failure mode than the outages that trigger most classic ICT incidents.
The practical difficulty is that AI failures are often gradual rather than binary: a model drifts, a retrieval pipeline returns stale documents, an agent’s tool-calling accuracy slips. Banks need monitoring thresholds mapped to the DORA classification criteria before the incident happens, not a judgment call made at hour three of the clock.
Three steps, three clocks, set out in Commission Delegated Regulation (EU) 2025/301. The initial notification is due within 4 hours of classifying the incident as major, and in any case no later than 24 hours after the entity became aware of it. The intermediate report follows within 72 hours of the initial notification, even if nothing has changed. The final report, including root cause analysis, is due within one month. For an AI incident, the 4-hour clock is the hard part: classification requires someone with both AI and ICT-incident expertise available around the clock, because a false negative (missing a major incident) and a false positive (reporting every model hiccup) both carry cost.
DORA does not name a role, so this defaults to whatever the bank has already built for ICT incident management, extended to cover AI. The workable pattern is a joint call between the ICT incident manager, who owns the classification process and the regulatory clock, and an AI or model risk owner, who can say within minutes whether an anomaly is a genuine failure or expected model variance. Leaving classification entirely to the ICT team risks under-reporting failures it does not recognize as failures. Leaving it entirely to the data science team risks missing the 4-hour clock because nobody connected the anomaly to the DORA process. The incident runbook has to name both roles explicitly, before the first real incident, not during it.
A model monitoring dashboard flags drift, latency, or accuracy drops constantly, and most of those alerts resolve through normal retraining or tuning without ever becoming a regulatory matter. A DORA major incident is a narrower, higher bar: it requires meeting the materiality thresholds on client impact, economic loss, data integrity, or critical-function disruption. Feeding every model alert into the DORA process buries genuine incidents in noise and burns out the compliance team. Treating DORA reporting as a separate track from model monitoring means the signal that should trigger the 4-hour clock sits unnoticed in a data science dashboard until someone escalates it manually, hours too late.
Four things, built before go-live, not after: a documented severity matrix that maps AI-specific failure modes (bias drift, hallucination, unauthorized agent action, data poisoning) to the DORA classification criteria; an on-call rotation that includes someone who can assess an AI failure technically, not just an ICT generalist; a pre-drafted initial notification template so the 4-hour clock is a fill-in exercise, not a first draft under pressure; and a register entry (per DORA Article 28) for every AI system and its underlying ICT provider, so the criticality and third-party questions are already answered when the incident hits. Banks that build this alongside the AI system, rather than after the pilot succeeds, are the ones that hit the clock reliably.
Incident readiness is an operating capability designed into the AI system from the first architecture decision, the same discipline that gets a pilot to production in the first place. Ableneo shipped 34 production AI projects in 2025 across banking and insurance clients in Slovakia, Czechia, Austria, and the US, with roughly 4 of 5 reaching production and staying there under real monitoring, not just a demo. That production discipline is what makes a DORA severity matrix workable instead of theoretical: mapping AI failure modes to incident thresholds requires a system that has actually run under load. Our AI transformation work builds this monitoring and classification layer alongside the model, connecting directly to the governance question covered in who signs off on an AI system in a DORA audit.
Key takeaways
Planning AI in a regulated business? Ableneo takes systems from classification to governed production.