Under DORA, an AI system that fails is an ICT-related incident, and if it degrades a critical or important function past the classification thresholds it becomes a major incident with a reporting clock: an initial notification, an intermediate report, and a final report to your competent authority. The awkward part is that AI fails quietly. A model can keep answering while its answers get worse, and DORA counts that too. So the real work is detection and classification, not the reporting form.
Most incident processes in a bank were built around things that stop: a payment rail goes down, a database refuses connections, a batch job throws. AI gives you a category those runbooks do not handle. The scoring service is up, latency is normal, the dashboard is green, and the false-positive rate on your transaction-monitoring model has doubled since the last feature-store refresh. Nobody paged. Under DORA that is still an ICT incident if it hits a critical or important function, and the fact that you did not notice for three days is itself the finding.
Detection has to reach the parts of the model that fail silently
You cannot classify what you never detected, so detection is where the money goes. For an AI system, uptime and error rates are the easy signals and the least useful ones. The failures that matter to a fraud model, a credit decision engine, or a KYC entity-resolution service are drops in output quality that leave every infrastructure metric untouched.
We wire detection at three layers and treat all three as first-class incident sources:
- Infrastructure and serving. The ordinary stuff: latency, throughput, HTTP errors, timeouts on the inference endpoint and its upstream feature lookups. A feature store that starts returning stale values is an incident even when the model returns 200s.
- Input and output distributions. Drift on the incoming feature vectors, and drift on the score distribution the model emits. A sudden collapse toward one class, a shifting population stability index, a spike in null features from a broken upstream join. These are the tripwires for silent degradation.
- Decision-quality proxies. Where ground truth is delayed, watch the proxies you can measure now: alert volume against the false-positive budget, straight-through-processing rate, manual-override rate, the fraction of cases sent to human review. When the override rate jumps, something changed upstream even if you cannot yet name it.
The lineage layer is what turns a signal into an incident you can act on. When drift fires, you need to walk backward from the score to the exact feature version, the training data snapshot, and the upstream source that moved. Without that lineage, the incident report reads “model got worse, cause unknown,” which does not survive a supervisor asking what you changed.
Classification is the decision that starts the clock
DORA does not ask you to report everything. It asks you to classify against the criteria in Article 18 and the Commission Delegated Regulation on the classification of major incidents: clients and transactions affected, data losses, service downtime, geographical spread, reputational impact, economic cost. Cross the thresholds and it is a major incident with mandatory reporting. Below them it goes in your register.
For AI this mapping needs translation, and doing that translation live during an incident is too late. Decide it in advance:
- Map each model to the critical or important function it serves, and the client-facing service downstream of it. A drifting sanctions-screening model touches a critical function; a marketing propensity model usually does not. The classification follows the function, not the technology.
- Define what “affected” means for a degraded model, not a dead one. If a scoring service returns confident wrong answers for six hours, the affected clients are everyone who received a decision in that window, whether or not the endpoint ever returned an error.
- Set the quality thresholds that flip a degradation into an incident before you are in one. A false-positive rate above X for longer than Y minutes on a monitoring model is an incident with a severity, written down, agreed with the second line.
The reason to fix these numbers ahead of time is the clock. Classifying an incident as major starts three deadlines under the reporting RTS: an initial notification within four hours of that classification and no later than 24 hours from when you first became aware, an intermediate report within 72 hours of the notification, and a final report within one month of the intermediate one. If your team spends the first day arguing whether a doubled override rate “counts,” classification slips, and every downstream deadline slips with it. That is an hour of definitional work you could have done in a calm room.
The reporting workflow, and the audit trail underneath it
The three DORA reports are cumulative, so the incident record has to accrete detail cleanly from detection through root cause. We build the workflow so the same underlying event log feeds all three, and every entry is timestamped and immutable.
- Initial notification. Detection time, the function affected, a first-cut severity, and what you know. For an AI incident this includes which model, which version, and the signal that fired, not just “service degraded.”
- Intermediate report. Impact quantified against the classification criteria, the containment applied (fell back to rules, rolled the model to the previous version, throttled straight-through processing to force human review), and current status.
- Final report. Root cause with the lineage attached: the upstream source that shifted, the feature that went stale, the retraining that moved the boundary. This is where drift detection and model monitoring stop being nice dashboards and become the evidence a supervisor reads.
Two things make this survive contact with an examiner. First, the audit trail has to show detection-to-classification-to-report timing, because DORA is as interested in whether your process worked as in what broke. A gap between when drift crossed the threshold and when a human classified it is a control weakness on its own. Second, when the failing component sits at a cloud provider or a model vendor, the accountability still lands on you, so your monitoring and your contractual reach have to cross that boundary. An incident you cannot see inside your vendor’s stack is an incident you cannot report on time.
The pattern that holds up is unglamorous. Instrument the model’s inputs, outputs, and decision proxies as carefully as its uptime. Decide the classification thresholds while nothing is on fire. Keep lineage so root cause is a query, not an archaeology project. The reporting deadlines are then a formality on top of a system that already knew.
FAQ
Does silent model drift count as a DORA incident?
It can. If drift degrades a service enough to hit the classification thresholds in Article 18 and the Commission Delegated Regulation on major incidents, it is a major ICT-related incident and the reporting clock applies, even if nothing crashed.
Who reports when the failing model runs at a cloud or vendor?
You do. DORA holds the financial entity accountable for incidents affecting its services regardless of where the component runs, so your contracts and monitoring have to reach into the vendor's boundary.
What is the first DORA reporting deadline for a major incident?
Under the reporting RTS, the initial notification to your competent authority is due as soon as possible and within four hours of classifying the incident as major, and in any case no later than 24 hours from the moment you became aware of it.