When a team switches on an AI model inside a critical function, nothing about the paperwork announces it. No new template appears, no AI annex opens. DORA gives artificial intelligence no chapter of its own.
That is the good news and the catch in one sentence. There is no new machine to build. But the existing machine only acts on a tool once that tool has been classified, and classification is where the AI question quietly decides everything that follows.
Classification is an input, not a label
It is tempting to treat classifying an AI tool as an administrative step: assign a category, record it, move on. It is not.
Classify an AI tool as supporting a critical or important function and a chain of consequences follows. It has to appear in the ICT asset register, be covered by the risk assessment, and sit inside the business-continuity and incident-response plans.
Its failure then has to be assessed against the incident-reporting thresholds. And if it is supplied by a third party, it has to be tracked in the register of information and watched for concentration risk.
Classify it as non-critical and most of that chain does not fire. The tool still exists, still gets recorded, but it does not pull the full weight of the framework behind it.
So the classification decision is doing real regulatory work before any of the downstream obligations are even considered. It is the switch that decides which of them attach. The work of meeting each one still has to be done by hand, but which ones apply at all is settled here.
Where the switch sends each tool
It helps to follow the wiring, because "supports DORA" is vague until you see what the classification actually connects to.
The first destination is the asset register. A tool classified as critical is not an optional entry; it is an ICT asset the register is required to hold, with its dependencies and its owner. The classification is what earns it the place.
The second destination is incident reporting. DORA requires financial entities to detect, classify and report major ICT-related incidents against defined thresholds - duration, number of clients affected, geographic spread, data loss, the criticality of the service hit. Whether an AI failure clears the "major" threshold depends heavily on how critical the underlying tool was classified to be.
The third destination is third-party risk. If the AI tool is an externally supplied model, its classification feeds the register of information and the concentration-risk view. A critical external model is not just a contract; it is a dependency a supervisor may ask you to prove you could exit.
One decision, three destinations. That is what "classification supports DORA" means in practice.
A worked example: the same failure, two outcomes
Take two AI tools and the same kind of bad day, to see how much the classification decides.
A marketing team uses a language model to draft campaign copy. It is classified as non-critical, because nothing a customer depends on runs through it. One morning it is unavailable for hours. Under DORA this is a minor operational annoyance: logged, perhaps, but nowhere near an incident-reporting threshold, because the classification already established that the tool sits outside any critical function.
A fraud-operations team uses a model to score transactions for manual review during payment processing. It was classified as supporting a critical function. The same kind of outage - unavailable for hours, is now a live question rather than a shrug.
It does not become a reportable incident automatically; that still turns on the actual impact, judged against the thresholds on the day. But the critical classification is what puts it on the table to be judged at all, and makes "reportable" a plausible answer instead of an obvious no.
Same failure. One is a footnote; the other is a decision made against a regulatory clock. What moved it there was not the outage - outages look alike, but a classification set months earlier, when nobody was thinking about a bad morning. That is the quiet power of the classification: it pre-loads how seriously a future failure will be taken, long before the failure happens.
Why the switch cannot flip for a tool nobody found
Here is the limit that decides whether any of this works. The routing only happens for tools that have been classified, and a tool can only be classified if it is known. The switch cannot flip for a tool that never reached the board.
This is the specific danger with AI. An incident-classification process written before models were embedded in onboarding or transaction monitoring cannot pre-classify a model it has never heard of.
The tool that most needs routing into the incident machinery, the one quietly making decisions inside a critical function, is exactly the one most likely to have arrived without a procurement event, and so to be missing from the inventory the classification runs on. The framework is ready. It is pointed at the wrong list.
Classification software is genuinely useful here, once the tools are known. It applies a consistent criticality method, keeps classifications current as functions change, and connects each decision to the register and the incident plan so nothing marked critical falls through.
What it does not do is find the tools. That is discovery, a separate step, and for AI it is the step that decides whether the classification is running on the real estate or a partial one.
The division of labour is worth stating plainly, because it is where the honest limits are. Applying an obligation once the classification exists can be systematised, and good software does it reliably. The classification itself is informed judgement about what a tool is and what function it sits inside, which a person still has to make.
The discovery that has to come before either can be automated, but it has to actually be done. Skip it, and you have a well-wired machine acting faithfully on an incomplete list, which looks like compliance right up until the tool nobody classified is the one that fails.
Frequently asked questions
How does classifying an AI tool actually affect DORA compliance?
Montro's position is that the classification is the routing decision for everything else. Classifying an AI tool as supporting a critical or important function pulls it into the asset register, the risk assessment, the business-continuity and incident-response plans, and - if it is externally supplied, the register of information. Classify it as non-critical and most of those obligations do not apply. The classification is what decides which parts of DORA govern the tool.
Does an AI system's failure have to be reported under DORA?
It depends on the tool's classification and the incident's severity. DORA requires major ICT-related incidents to be classified against thresholds such as duration, clients affected, geographic spread and data loss, and reported to the competent authority on a tiered timeline. An AI failure inside a function classified as critical is far more likely to clear the major-incident threshold than the same failure in a tool classified as non-critical, which is why the earlier classification matters so much on the day.
Does DORA treat AI incidents differently from other ICT incidents?
No. DORA has no separate AI incident regime; an AI system is an ICT asset, and its failures are ICT-related incidents assessed through the same classification and reporting machinery as any other technology. The practical challenge is judging when an AI tool's anomalous behaviour constitutes a reportable incident, which again depends on how the tool was classified in the first place.
Can classification software make an AI tool DORA-compliant by itself?
No. Classification software supports the classification and routes the result into the right obligations, but it works only on tools it has been given. It does not discover the AI tools that entered the estate without a procurement event, the embedded features, internal scripts and external models that never generated a contract. Those have to be found first, and the classification itself remains a matter of informed judgement the software supports rather than replaces.
