Financial entities keep a register of every ICT third-party contract. Most of the AI they use arrives as a third-party service. So the question is rarely whether AI belongs in the register — it is whether the register and the AI inventory describe the same reality. Usually they do not, and the gap is cheap to find.
If it is an ICT service provided by a third party under a contract, it belongs in the register — and most AI a financial entity uses is exactly that: a SaaS subscription, or an AI feature switched on inside a SaaS product that was already under contract. The practical problem is that the DORA register and the AI inventory are kept by different teams, from different angles, and almost never compared. Comparing them takes an afternoon and produces findings you would rather make yourself than receive. What the AI side of that comparison should contain is set out field by field in our AI model inventory guide.
Under DORA — Regulation (EU) 2022/2554 — a financial entity maintains a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers, and distinguishes the arrangements that support critical or important functions from those that do not (Article 28(3)). The register follows the templates in Commission Implementing Regulation (EU) 2024/2956, drafted by the European Supervisory Authorities, and competent authorities collect it. The entity also informs its authority in good time when a function becomes critical or important, and before it contracts ICT services that support one. It is not a policy document. It is a set of tables with one row per arrangement, and the supervisor reads it as such.
Now look at how AI actually enters a bank, an insurer or a payment firm. Very little of it is built in-house on infrastructure the entity controls. It arrives as a subscription to a hosted tool, as a model behind an API, or — most often and least visibly — as a feature the vendor switched on inside a product the entity already licensed: the ticketing system that now drafts replies, the document platform that now summarises, the CRM that now scores. Each of those is a service delivered by a third party under a contract. In the register’s terms, that is an ICT service, and the question of whether it supports a critical or important function has to be answered for it like for any other.
Which means the AI question, for a DORA entity, is not a new obligation. It is the old obligation applied to a category of service that changes faster than the register is refreshed.
Most financial entities that have started on AI governance now keep two lists that describe the same tools.
| AI inventory | DORA register of information | |
|---|---|---|
| Angle | What the system does, who owns it, how it is classified (AI Act, model risk) | Which provider, which contract, which function it supports, how critical |
| Unit of record | A system or a use case | A contractual arrangement |
| Kept by | Model risk, data science, compliance, or whoever picked up “AI” | ICT risk, outsourcing, procurement |
| Refreshed when | When someone remembers, or when an assessment is due | Kept up to date as arrangements change; reported to the authority on request and on a fixed cycle |
| Reader | Internal audit, the AI committee, a certification assessor | The competent authority, the outsourcing committee |
Neither list is wrong. They are different projections of the same set of vendor relationships, and each is fit for its reader. The trouble is that nothing in the normal course of work forces them to agree. The team that adds a row to the AI inventory rarely knows the register exists; the team that maintains the register classifies a contract by what the vendor sells, not by what the vendor quietly added last quarter. Two departments, two spreadsheets, one reality — and a reconciliation that nobody owns.
The finding is the difference. An auditor or a supervisor does not need to know which list is right. The observation that the two disagree is already a finding about control over third-party ICT, and it is one you can make yourself, first, with an export and a join.
Reconciliations of this kind turn up the same three patterns. The names of the tools change; the shapes do not.
A team adopted a hosted AI assistant a year ago. There are forty single sign-on logins to it every day and a monthly invoice under a cost centre. It was never treated as ICT outsourcing because it was bought like software, on a card or a small purchase order, and the person who approved it did not think of a text assistant as an ICT service. The AI inventory knows about it, because the team was honest when asked. The register does not, because nobody asked the register.
The opposite case. A document management platform has been in the register for years, correctly, with a contract, a provider identifier and a criticality rating. Eighteen months ago the vendor added an AI layer that summarises, classifies and answers questions over the documents stored in it, and an administrator enabled it because the release notes recommended it. The contract is registered. The AI use has never been assessed — not for what data it processes, not for whether staff act on its outputs, not for whether the entry’s description of the service is still accurate. The register is complete on paper and stale in substance.
A scoring or routing feature sits inside a process the entity has classified as critical or important — payments, claims, onboarding, collections. The feature came with a vendor product filed in the register as a minor tool, with a criticality rating chosen when the product did nothing but hold records. The process is critical; the tool feeding a decision into it is filed as not. Whether that is a wrong rating or a wrong scope is a judgement, but it is a judgement nobody has been asked to make, and the two lists are the only place the tension is visible.
This is less work than it sounds, because the hard part is not technical.
The join is mechanical. The answers are human, and they cannot be inferred from either list — only the owner knows whether the tool is still in use and what it touches. What the exercise produces is the difference between what people declared and what the systems show, dated, with names on it. That is the whole point.
The EU AI Act compliance checklist takes one system through classification and lists the obligations that follow, with the evidence each one expects. Run it on the entries the reconciliation flagged as sitting inside a critical or important function — those are the ones where the AI Act question and the DORA question tend to arrive together. One caution: a system that supports a DORA critical or important function is not thereby a high-risk AI system. The AI Act’s high-risk list is closed — Annex III and Article 6 — and a tool can be critical to your operations while sitting outside it, or the reverse.
Open the checklistNot a merged system, and not one team taking over the other’s list. Reconciled means that for every third-party AI tool there is one row both registers agree on:
| Field | Which list it comes from |
|---|---|
| Provider (legal name, identifier) | DORA register |
| Contract reference | DORA register |
| Supported function and its criticality | DORA register, checked against the process the AI inventory names |
| AI use — what it does, what data it sees | AI inventory |
| Owner who would answer for it | AI inventory |
| Date last confirmed by that owner | The reconciliation itself |
The last row is the one that matters most and is most often missing. A register entry created three years ago and never re-confirmed is a statement about three years ago. A date of last confirmation, with the name of the person who confirmed it, turns the row from a claim into evidence — and it answers the question that sits behind every supervisory review of a register: “How do you know your register is complete?” Because it was compared against what the systems show, on this date, and here is what was found and fixed.
In Model Inventory for Jira, each AI system is a Jira work item: owner, purpose, classification and status on the item, the provider and the process it supports as fields, and an immutable change history behind all of it. The register stays where ICT risk keeps it; what changes is that the AI side of the row has a dated owner and a record of the last time somebody confirmed it was still true.
See how it worksIf it is an ICT service provided by a third party under a contractual arrangement, yes. The register covers such arrangements and distinguishes those supporting critical or important functions, so the entry needs the function the tool supports, not just the provider and the contract. Whether a specific tool is in your entity’s scope is a judgement for your ICT risk and outsourcing functions — the point is to ask it per tool rather than assume.
Often. The contract may be registered, but the entry describes the service as it was when assessed. An AI feature that reads your data, produces outputs staff act on, or reaches into a critical or important process changes the service consumed even if the contract is unchanged. At minimum, assess the AI use and re-check the entry’s description and criticality.
At least each time the register is refreshed for the competent authority, and whenever a new AI feature is enabled or a new AI tool is contracted. Once the export and the join are set up, re-running them costs little; chasing the differences with owners is where the time and the findings both go.
This page is a practical explanation, not legal advice. Confirm obligations against the official text of Regulation (EU) 2022/2554, the technical standards and guidance that apply to your entity, and where the stakes warrant it, qualified counsel.