The DORA register lists your AI without calling it AI

Every financial entity covered by DORA has to keep a register of information: a record of all its contractual arrangements for ICT services delivered by third-party providers. The word AI appears nowhere in that template. That is why the register holds more of a firm's AI than an inventory that goes looking for AI.

The obligation itself is EU law and applies across the union, minus the entities exempted by Article 2(3), among them the smallest insurance intermediaries and occupational pension schemes with no more than fifteen members. The filing is national: in Sweden the register goes to Finansinspektionen by 28 February each year, in the version reflecting the position at the end of the previous calendar year.

The register asks whether it is an ICT service, not whether it is AI

Article 28(3) of Regulation (EU) 2022/2554 requires financial entities to maintain and update a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers, at entity level and at sub-consolidated and consolidated levels, distinguishing arrangements that support critical or important functions from those that do not.

The scope is set by the definition in Article 3(21), which reads "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services which includes the provision of technical support via software or firmware updates by the hardware provider, excluding traditional analogue telephone services". The definition both includes and excludes, and it does so by type of service. What it never asks is which technology inside the service produces the outcome. A model that scores, prices or recommends, delivered on an ongoing basis through an ICT system, is therefore covered by virtue of being a data service.

Under the fourth subparagraph of the same article and section 4 of Finansinspektionen's regulations FFFS 2024:20, Swedish entities file the register with the supervisor by 28 February each year. In its supervisory priorities for 2026, published in February 2026, Finansinspektionen writes that it will specifically analyse data reported under DORA in order to identify risks and to ensure good compliance with the framework. That wording covers reported DORA data in general and does not single out the register of information.

What you run is usually someone else's solution, integrated into yours

Finansinspektionen's survey of AI use in the Swedish financial sector, published in December 2024, rests on a questionnaire sent in September 2024 to 278 selected firms, which returned 203 responses covering, through co-reporting within groups, 234 of those firms. Among the firms that described specific generative AI use cases, the majority mention having integrated external solutions into their own systems. The population for that finding is not all respondents but those that described a concrete case, which is precisely the group with something in operation to describe.

The ECB's annual data collection on innovative technologies points the same way for a different population. Reporting in February 2026, the ECB states that more than 85 percent of large banks under European supervision already use AI in some form, and that generative systems are often sourced from a small number of major third-party providers and rely heavily on cloud infrastructure. The number of banks and the field period are not given in that reporting, and the population is euro area banks.

A small number of providers sit behind much of the sector's AI, and the register is where that concentration shows.

Two measurements, using different instruments on different populations, point the same way about where the systems come from. For the register that means something concrete: the bought-in share of AI use is the share that already has a counterparty, a start date and a numbered row.

The row names the contract, not the function

That is where the register stops. The entry describes a contractual arrangement, a provider and the service supplied, plus whether the arrangement supports a critical or important function. It does not describe which function inside that service produces an outcome about an individual person.

The AI Act asks that question instead, and it asks it of the organisation using the system even when the system is owned and operated by the provider. Annex III names two financial use cases: creditworthiness assessment of natural persons, and risk assessment and pricing in life and health insurance. The requirements for those apply from 2 December 2027, following the amendment made by Regulation (EU) 2026/1744 of 8 July 2026. What moved and what did not is covered in our reading of the postponed high-risk deadline.

The register is updated once a year. What a system does to a customer can change any week.

The gap between the two questions shows most clearly in the register's own marking of critical and important functions. That marking answers whether a technical outage would disrupt the business. Classification under the AI Act answers whether an outcome can affect the individual. A system can be unimportant for operations and decisive for a customer, so the marking cannot be carried across from one framework to the other.

The register catches what you bought and misses what your people opened themselves

The argument has a limit heavy enough to write out. The register covers contractual arrangements. Generative AI that an employee opens in a browser on their own initiative has no contractual arrangement with the firm and will therefore never enter the register, however carefully it is kept. In Finansinspektionen's survey, 84 percent of responding firms said their employees use some form of generative AI, while 32 percent had produced a policy for how they may do so. That part of the usage is invisible to the register by construction, and shows up instead in licence and purchasing data, which is covered in Which AI tools are actually being used.

There is a second limit, and it concerns the condition of the register. Ahead of the rules applying in earnest, the European Supervisory Authorities ran a dry run with submission by 30 August 2024. In the summary reported in December 2024, 6.5 percent of the 947 registers that could be analysed passed all data quality checks, and 86 percent of the failed checks concerned missing mandatory information. The dry run measures readiness in 2024 and says nothing about the quality of what was filed in 2026, but it does set the expectation: a list to work from, not an answer to lean on.

A register measures contracts. A survey measures behaviour. The two instruments have different blind spots, and anyone who wants to know what the house actually runs needs to read both.

The question to put to every row

Take the register that has already been filed and go down it row by row with a single question: can this service produce an outcome about a named private individual that you then act on?

For a payment institution or an asset manager with no lending to private individuals, the answer is no on almost every row. For a consumer lender or a life insurer it is yes on a handful, and those are the rows Annex III is actually about. The question therefore gives different readers different answers, and that is the point of it: it separates the firms with a short, bounded task ahead of them from the firms with mostly a reassuring answer to collect.

The rows where the answer is yes are rarely many. They are, however, named, dated and tied to a provider you already hold a contract with. That is a different starting position from an empty template.