TL;DR "AI risk classification" means two different things, and the software marketed under the phrase does not always mean the one DORA requires. The AI Act sorts an AI system by risk tier. DORA asks a different question: how critical is this asset to a function that matters? For DORA, the AI tool is an ICT asset first and an AI system second, and no software can classify a tool it has never been told exists.
Search for AI risk classification software and you will find two different products under one label. One sorts AI systems into the EU AI Act's risk tiers. The other classifies ICT assets by how critical they are to the business. For a financial entity under DORA, only the second is the job.
So the short answer is this. AI risk classification software for DORA is tooling that helps a financial entity assess each AI system as an ICT asset and record how critical it is to the functions it supports - where it belongs in the asset register, what its failure would mean, and what the firm must be able to show a supervisor.
It is ICT asset classification applied to a tool that happens to be AI. It is not the AI Act's risk-tiering exercise, though the two are easily confused, and the confusion is worth clearing up before you evaluate anything sold under the name.
Two questions that sound like one
The AI Act asks what type of AI system this is, and how much risk it carries as an AI system. Its answer is a tier - unacceptable, high, limited or minimal - driven largely by the use case. Credit scoring and insurance pricing sit high; a lot of operational AI sits lower.
DORA asks something else entirely: how critical is this asset to a function that matters, and what happens to the firm if it fails? The answer is not a tier drawn from the use case. It is a judgement about the function the tool sits inside, the same question the firm asks of a database, a network link or a payment gateway.
These two questions can give opposite answers about the same tool. An AI feature that the AI Act treats as low-risk can be highly critical under DORA if it sits inside a function the firm cannot operate without.
The reverse holds too. The two are not unrelated - a use case that makes an AI system high-risk under the AI Act, like credit scoring, often makes it critical under DORA as well, but the AI Act tier does not determine the DORA criticality, because the frameworks are answering different questions. One asks what the system is; the other asks what depends on it.
Under DORA, the AI tool is an ICT asset first
This is the point the definitional confusion hides. DORA does not have a separate regime for AI. An AI system deployed by a financial entity is an ICT asset within DORA's meaning, and it inherits the entire ICT risk-management framework - identification, classification, protection, incident handling, third-party oversight - whether or not the AI Act says anything about it.
So "AI risk classification for DORA" is really ICT asset classification applied to a tool that happens to be AI. The classification decides real things downstream: whether the tool belongs in the asset register as supporting a critical or important function, how its failure would be assessed against incident-reporting thresholds, and what the firm has to show a supervisor about it.
Software that only tells you an AI system's AI Act tier has answered a question DORA did not ask. Useful for AI Act compliance, but it does not populate the DORA asset picture.
The same technique, two very different classifications
The distinction stops being abstract the moment you classify two real tools.
Take two uses of the same underlying AI capability, text summarisation by a language model. In one team, it drafts summaries of internal customer-service tickets so agents can triage a queue faster. In another, it summarises transaction narratives that feed a payment-authorisation decision. Same technique, similar-looking feature, bought or enabled the same way.
Under DORA they classify nowhere near each other. The ticket-triage summariser supports a useful but non-essential workflow; if it failed, agents would read the tickets themselves and the function would carry on.
The transaction-narrative summariser sits inside payment authorisation - a function the firm cannot stop performing - so its failure, its bias, or its unavailability becomes a live operational-resilience question. One is low criticality; the other may be critical or important, with everything that follows for the register and the incident plan.
Notice what did the work. Not the model, not the AI Act tier, not the vendor, the function the tool sits inside. That is what DORA classification turns on, and it is why two tools that look identical on a purchase order can belong in completely different places in the register.
Why classification software cannot start the job
Here is the limit that the category label glosses over. Classification software classifies what it is given. It takes a list of assets and helps you assess, tier and document them against the framework. What it does not do is find the assets in the first place, that is a different tool doing a different job.
For AI tools, that gap is the whole problem. The AI tools most likely to be mis-tiered are the ones nobody entered - the model wired into a spreadsheet, the assistant switched on inside a licensed platform, the automation a team built to clear a backlog. None of these arrives with a classification request attached.
If the tool never reaches the software, the software never classifies it, and it sits inside a critical function at whatever risk it carries, unclassified and unseen.
So the category is narrower than the marketing suggests. Classification software supports the classification step. The discovery step that has to come first is a separate capability - sometimes in the same platform, often not - and for AI tools discovery is where most of the exposure actually lives. When a product sells "classification" as if it covered both, that is the seam to check.
What classification software genuinely does help with
None of this makes the software pointless. Once the tools are known, good classification support does real work.
It gives you a consistent criticality method, so two analysts apply the same criteria rather than their own instincts. It keeps the classification current, flagging assets for reassessment when the function around them changes. It produces the record a supervisor asks for - who classified what, on what basis, when. And it links the classification to the downstream obligations, so a tool marked critical flows into the register and the incident-response plan.
That is genuine value. It is just value that begins after the tool has been discovered, not before.
What to actually look for
If you are evaluating anything sold as AI risk classification software for DORA, the question is not whether it tiers AI systems. It is whether it helps you do the DORA job - classify ICT assets by criticality, and whether it is honest about where its job starts.
Ask whether it classifies by criticality to a function, or only by AI Act tier. Ask what feeds it, and where that asset list comes from. Ask whether its output lands in the register and the incident-response process, or stops at a report. And ask what happens to the AI tools nobody entered, the set that decides whether your classification is complete or merely tidy.
This is where the software question actually lands. The classification method can be systematised, and good tools systematise it well. The discovery that has to precede it can be automated too - that is precisely the separate capability the classification category leaves out.
But deciding what a given AI tool is, what function it truly sits inside, and how its failure should be judged remains a matter of informed judgement - the software supports that decision, it does not make it. Treated as support, it earns its place. Treated as the whole answer, it classifies a list that was incomplete before the software ever saw it.
Frequently asked questions
Is AI risk classification for DORA the same as the EU AI Act's risk tiers?
No. Montro's position is that they answer different questions. The AI Act classifies an AI system by risk tier based largely on its use case; DORA classifies an ICT asset by how critical it is to a function that matters. The same AI tool can be low-risk under the AI Act and highly critical under DORA, or the reverse, because the two frameworks measure different things. For DORA, the AI tool is an ICT asset first.
Does DORA have separate rules for AI systems?
No. Montro reads DORA as technology-neutral: it does not impose AI-specific governance, and an AI system is treated as an ICT asset subject to the full ICT risk-management framework. That means an AI tool supporting a critical or important function carries the same identification, classification, incident and third-party obligations as any other ICT asset.
Can classification software make my AI tools DORA-compliant on its own?
No. Classification software supports the classification step; it works from a list of known assets. It does not discover the AI tools that never entered the inventory - the features, scripts and integrations that arrived without a procurement event, and those are frequently the ones closest to a critical function. Discovery has to come first, and classification remains informed judgement that the software supports rather than replaces.
What does classifying an AI tool under DORA actually decide?
Its criticality classification determines whether it belongs in the ICT asset register as supporting a critical or important function, how its failure is assessed against DORA's incident-reporting thresholds, and what evidence a supervisor can expect about it. This is why the classification is a substantive governance step, not a labelling exercise.
