When does an AI failure become a reportable incident under DORA?

When it qualifies as a major ICT-related incident under the DORA classification criteria. Financial entities must classify incidents against criteria set in regulatory technical standards, covering clients and counterparts affected, duration and service downtime, geographical spread, data losses, the criticality of the services affected and economic impact, and must report major incidents to their competent authority on a strict clock. An AI failure is judged exactly like any other ICT failure.

The question matters in 2026 because DORA has been in force since 17 January 2025, AI now sits inside functions financial entities class as critical or important, and many AI failures happen in a vendor cloud, where the evidence needed to classify them on time is not in the entity's hands.

What makes an AI failure an ICT incident at all?

DORA does not carve AI out as a special category. An AI system supporting a critical or important function that produces wrong outputs, becomes unavailable or leaks data has caused an ICT-related incident like any other system failure. The failure modes differ: an outage announces itself, while wrong outputs can flow silently into downstream processes for days. The legal analysis is the same either way: identify the incident, classify it against the criteria, and report it if it is major. Silence is a property of the failure, not an exemption from the framework.

Which criteria decide whether an incident is major?

The classification criteria are set in regulatory technical standards, and they examine:

• the clients and financial counterparts affected;
• the duration of the incident and the downtime of services;
• the geographical spread;
• any data losses;
• the criticality of the services affected;
• the economic impact.

The thresholds sit in the technical standards and should be applied from the text, not from memory. The point for AI deployments is that the criteria most likely to be engaged, data losses and the criticality of services, are precisely where AI failures tend to land.

How fast does the reporting clock run?

In three stages: an initial notification within hours of classifying the incident as major, an intermediate report within 72 hours, and a final report within a month. The clock is unforgiving because it starts from classification, and classification requires facts: what happened, when it began, which services and clients were affected, what was lost. An entity that cannot assemble those facts quickly does not get a slower clock. It gets a weaker report, filed under pressure, that its supervisor will read closely.

Why is cloud AI the hard case?

Because detection and evidence live with the vendor. When the model runs in a vendor cloud, the entity often learns of degraded outputs from its own downstream errors rather than from the vendor. The start time, the scope and the cause sit in logs the entity cannot query. Classification becomes correspondence: emails to the vendor, status-page archaeology, waiting for an incident summary written for a general audience on the vendor's timetable. DORA's deadlines do not pause for any of it. The reporting duty is the entity's, whether or not the vendor has yet explained what happened.

What does a sealed local record change?

It turns classification from correspondence into a query. On Mickai, our Sovereign Intelligence Operating System, which runs offline on operator-owned hardware, every AI action, with its inputs, outputs, model version and approvals, is sealed to a post-quantum signed audit ledger bound to hardware-attested identity. When outputs go wrong, the entity can establish quickly what the system did, when the behaviour began, which processes consumed the outputs and which clients were touched. The record verifies offline, so the evidence handed to an authority does not rest on trust in anyone's network. Each classification criterion becomes a question the ledger can answer inside the clock.

What should a financial entity do before the first incident?

Rehearse the classification, not just the outage. Map every AI system to the functions it supports and mark which functions are critical or important. Define in advance what wrong output means for each system and who decides. For every AI dependency, confirm where the evidence for each classification criterion would come from and how long retrieval takes, because a criterion whose evidence takes a week to extract from a vendor is a criterion the entity cannot assess inside the clock. Then run the drill against a realistic scenario and time it honestly, including the vendor correspondence.

“An entity that owns the record of what its AI did can classify an incident by query; one that does not classifies by correspondence.”

How the sealed ledger sits inside the wider architecture is set out at /sovereign-ai, and the film at /film shows the system, and the record it keeps, in operation.

Frequently asked questions

Does DORA apply to my customer-service AI chatbot?

It depends on the function the system supports. The incident regime turns on the criticality of the services affected and the clients touched, so a system fronting a critical or important function can generate a reportable incident, while a purely internal drafting assistant is far less likely to. Map each AI system to its function before an incident, not during one.

Is a wrong AI output really an incident if nothing went down?

It can be. The classification criteria include data losses, the criticality of the services affected and economic impact, none of which requires an outage. Silently wrong outputs flowing into a critical function are in some ways the harder case, because the duration builds before anyone notices, and the affected population grows with it.

Our AI runs with a cloud vendor. Is the reporting duty theirs or ours?

The duty to classify and report to the competent authority is the financial entity's. Contracts should oblige the vendor to notify and assist promptly, but a vendor notification does not discharge the entity's own obligations or move its deadlines. The entity remains answerable for its incident, on its clock, with whatever evidence it can actually obtain.

What if we classify late because the vendor was slow with information?

The initial notification runs from classification but must land no later than 24 hours after the entity became aware of the incident, so slow classification does not stretch the clock, and an entity that cannot show it detected and assessed diligently invites supervisory questions about its wider ICT risk management. Slow vendor evidence is an argument for stronger contractual terms and for records the entity holds itself, not a defence the framework offers.

Is DORA incident reporting the same as NIS2 reporting?

No. NIS2 is a separate regime with its own reporting duties for essential and important entities, and the UK is outside NIS2. The clock described here is DORA's, applying to financial entities in scope of that regulation, and the two regimes should be tracked separately where both apply to a group.