A server sits still long enough to be classified. An AI tool rarely does - it spans three teams, turns a feature into a dependency, or arrives without anyone buying it. Classification methods written for stable infrastructure quietly miss exactly these traits, which is why AI tools are the ones most often misclassified or missed.
What follows is the classification checklist rewritten for AI specifically: seven things an approach has to get right before the register built on it can be trusted.
In short: classify by the function rather than the technology; find the tools before you classify them; reconcile the taxonomy across teams first; classify so the entry feeds the register; keep the incident threshold in mind; treat external models as third-party dependencies; and re-classify when the function changes. Each is worth a closer look.
1. Classify by the function, not the technology
The instinct with an AI tool is to classify the tool - its model, its vendor, its capability. DORA asks a different question: how critical is the function this tool supports?
The same model can be trivial in one place and critical in another, depending entirely on what depends on it. A summarisation feature drafting internal notes is not the summarisation feature reading transaction narratives inside payment authorisation. Classify the function first, and the tool inherits its criticality from where it sits, not from what it is.
2. You can only classify what you have found
Every classification method assumes a list to work from, and for AI tools that list is the weak point. The model wired into a spreadsheet, the assistant switched on inside a licensed platform, the automation a team built over a weekend - none generated a procurement event, so none reached the inventory the classification runs on.
A classification applied to a partial list produces a tidy result and a false sense of completeness. Discovery is not a step you can skip before classification; it is what decides whether the classification means anything at all.
3. Resolve the taxonomy before you classify
An AI tool rarely belongs to one team. The same feature can be seen by the ICT function as an application, by the data function as a processing activity, and by the business as a workflow, each with its own naming convention and its own idea of what "critical" means.
Left unreconciled, the same AI tool gets three classifications and no owner. Agree one taxonomy, and one definition of criticality, before the classifying starts, or the register fills with entries that quietly contradict each other.
4. Classify for the register it has to feed
A classification is not a standalone judgement; it is an entry the ICT asset register has to hold.
That means a classification for an AI tool has to carry what the register needs - the function it supports, its dependencies, who owns it, whether it is internal or third-party. A criticality label with none of that attached is not classification; it is a sticky note. Classify with the register's fields in mind, and the output lands where it is meant to. Classify in the abstract, and someone re-does the work later.
5. Classify with the incident threshold in mind
Classification decides, in advance, how an AI tool's failure will be judged. DORA assesses major incidents against defined criteria - clients affected, duration, geographic spread, data loss, the criticality of the service hit.
A tool supporting a critical function is one whose bad day is worth assessing against those criteria; a trivial one is not. The classification does not decide reportability on its own, the incident's actual impact does that on the day. But it decides whether a failure is taken seriously enough to be assessed at all, putting an AI outage on the table on a bad morning rather than letting it pass unremarked.
6. Classify external models as third-party dependencies
When the AI tool is an externally supplied model, its classification carries a second obligation. A critical external model is not just an asset, it is an ICT third-party dependency that feeds the register of information and the concentration-risk view.
The classification has to record not only how critical the model is, but that it is external, who provides it, and whether the firm could exit or replace it. An external model classified as critical without that dependency view is half-classified.
7. Classify again when the function changes
An AI tool's criticality is not fixed. A model added to a minor workflow becomes critical the day that workflow is wired into a critical function; a feature enabled by default grows into a dependency without anyone re-classifying it.
A classification reviewed once and left is a classification slowly drifting out of date. Set a review cadence, and make sure something feeds it new AI tools between reviews, because the classifications most likely to be wrong are the ones nobody has looked at since the estate changed underneath them.
Where this leaves you
Read back, the seven are really one idea in seven places: an AI classification is only as good as the completeness, coherence and currency of what feeds it.
The method itself, assigning criticality against a function - is not the hard part, and good software supports it well.
The hard part is making sure every AI tool that should be classified actually reaches the exercise, that the whole firm classifies it the same way, and that the classification keeps pace with an estate that changes faster than the annual review.
None of the seven is difficult in isolation. The difficulty is that they have to hold together, across teams and over time, for every AI tool in the estate rather than the handful anyone remembers to check.
Get those right and DORA classification for AI tools becomes ordinary, the same discipline applied to any ICT asset. Get them wrong and the register looks complete while missing exactly the tools most likely to matter.
Frequently asked questions
How do you classify an AI tool under DORA?
Montro's position is that you classify by the function the tool supports, not by the tool itself. Under DORA, an AI system is an ICT asset, and its criticality comes from how critical the business function it sits inside is, assessed against the same criteria as any other ICT asset.
The same model can be critical in one deployment and trivial in another, which is why the function, not the technology, is the unit of classification.
What makes an AI tool "critical" under DORA?
An AI tool is critical when the function it supports is a critical or important function - one whose disruption would materially impair the firm's ability to deliver its services or meet its obligations.
The tool's technical sophistication is not the test; what depends on it is. A simple model inside payment processing can be critical, while an advanced model in an internal experiment is not.
Do AI tools need to be classified separately from other ICT assets?
No. DORA treats an AI system as an ICT asset, so it is classified through the same criticality framework as everything else. The reason AI needs particular attention is not a separate rulebook but a practical one: AI tools are more likely to arrive without procurement, to span several functions with conflicting taxonomies, and to change criticality as they are wired into new workflows, all of which make them easy to misclassify or miss.
How often should AI tool classifications be reviewed?
At least annually, and whenever a significant change occurs.
For AI tools the trigger events matter as much as the calendar: a model moved into a new workflow, a feature enabled by default, or an integration added to a critical function can all change a tool's criticality between scheduled reviews, so the review process has to be fed by ongoing discovery rather than run once a year in isolation.
