TL;DR: Your DORA ICT asset register catches the AI that arrived with a contract. It misses the AI your teams built, connected or switched on without one, the automation inside month-end, the model wired up over a weekend, the assistant that appeared as a feature update. That second category is often the larger one, and discovery, not another policy, is what closes it.
Two kinds of AI are running in your firm today. One is in the ICT asset register. The other is doing the same work, on the same data, and the register has never heard of it.
The first kind arrived the way everything used to. Someone raised a request, procurement ran its process, a contract was signed, and a line appeared in the register with a vendor name, a renewal date and an owner. This is the AI most firms have already accounted for - it has a paper trail, and when a supervisor asks what it is and what it touches, there is a document to point to.
The second kind arrived because someone had a deadline. It is the one that will not survive a review.
What the asset register is meant to catch
Under DORA Article 8, a financial entity has to identify and classify every ICT asset supporting a critical or important function, map how those assets depend on one another, and review the whole picture at least once a year. On paper the duty is broad. It does not say "the assets you have contracts for" - it says the assets that support the functions that matter, wherever they came from.
The gap is not in the obligation. It is in how the register gets populated.
In practice, the asset inventory is built from the data the firm already has - the procurement system, the contract store, the vendor list, the SSO directory. Those sources are complete for anything that arrived with a supplier and a signature. They are silent on everything that did not.
That was a workable shortcut for most of the last decade, because ICT assets did come with contracts. The procurement trail was a good enough proxy for the asset map.
AI broke the proxy. A risk analyst turns a manual reconciliation into a running automation with an AI coding assistant in an afternoon. A finance controller wires a reporting tool to an external model over a weekend. A team switches on the assistant already sitting inside a platform the firm has paid for since 2022.
None of these generate a procurement event. There is no new vendor to call, no contract to file, no purchase order to match against. So none of them reach the register through the channels that populate it, even though Article 8's own definition of an asset is wide enough to include them. The obligation covers them. The plumbing does not.
What a procurement-built register gets right
It is worth being fair to the register before pulling it apart, because most of it works.
The procurement-fed inventory is genuinely good at the things procurement touches. It knows the licensed platforms, the hosting arrangements, the named vendors and their renewal dates.
For anything that arrived through a contract, it gives the firm a clean line from asset to supplier to owner - which is exactly what a supervisor wants to see first, and exactly what the Article 28(3) Register of Information is built to consume. A firm that has done this work has done real work, and it should not be told otherwise.
The trouble is that "good at what procurement touches" quietly became "good enough" for the whole asset picture, at precisely the moment the asset picture stopped being defined by procurement. The register did not get worse. The estate changed underneath it.
A firm can run a disciplined, audit-ready inventory of everything it bought and still be blind to half of what its critical functions actually depend on, not because the inventory is careless, but because the new dependencies never passed through the one gate the inventory watches.
The same person, governed and ungoverned in the same afternoon
Take one controller in the finance function. They cannot upload a client file to a public chatbot; that was blocked eighteen months ago and IT can prove it. They can, and do, run the same client data through an AI feature inside the workflow tool their team has used for years, because nobody wrote a rule about a feature that did not exist when the tool was bought.
Same data, same person, same afternoon. One use is logged, access-controlled and evidenced for a supervisor. The other leaves no trace, and it is the one touching client data at volume.
That is the gap in a single picture. The register knows what the firm bought, because buying leaves a trail it was built to follow. It does not know what the firm's teams built, connected or switched on, because none of that leaves the same trail - and that is increasingly where the AI actually lives.
One critical function, two registers
The clearest way to see the gap is to take a single critical function and look at it through both what the register records and what is actually running underneath.
Take retail payment initiation - a function, in DORA's language, not an application.
Ask the register what supports it, and you get a clean list: the core payments platform, the hosting provider, the fraud-screening vendor, the messaging gateway. Each has a contract, an owner, a place in the inventory. On this view the function is well-documented and well-governed.
Now walk the same function through the teams that run it. The fraud analysts have a spreadsheet that calls an external model to score edge cases the main engine flags as ambiguous. The operations team built a reconciliation assistant on top of an AI coding tool to clear breaks faster at month-end.
The vendor's own platform switched on an embedded AI feature in its last release, enabled by default, now summarising transaction narratives the analysts read. None of these three has a contract line of its own. All three now sit inside the critical function.
Same function, two registers. One is the documented list of what the firm procured to support retail payment initiation. The other is the real dependency map, the procured systems plus the models, scripts and features that attached themselves to the function afterwards. Article 8 asks for the second. Most firms can only produce the first.
The distance between those two registers is not a rounding error. It is the fraud model no one has assessed for bias or availability, the reconciliation assistant with no owner if it breaks during close, the vendor feature processing transaction data under terms nobody re-read.
Each is a live dependency of a critical function, and each is invisible to the document that is supposed to list exactly that.
Why this is not a diligence failure
It would be easy to read this as sloppy register-keeping. It is not. The teams maintaining these registers are careful people doing careful work against a definition of "asset" that assumed a vendor on the other end.
The tools that broke the definition did not announce themselves as tools. They arrived as a feature update, a script, a workflow someone was proud of. A register that starts from contracts will keep finding contracts and keep missing the rest, however diligently it is kept. The problem is structural, and structural problems do not yield to trying harder at the old method.
Why the usual answers do not reach
The instinct is to tighten procurement and send round a policy. Both are worth doing. Neither closes the gap.
Procurement governs the AI that asks permission. This category did not ask. A policy reaches the people who were already going to comply and misses the ones who reached for the tool precisely because there was no time to ask.
And the register inherits whatever procurement and the vendor list already know - so it cannot document an asset that never generated a record in either. Through the channels that populate it, it never will.
What reaches these tools is discovery: reading across the systems the firm already runs, finding which ones have quietly become AI processing data that matters, and getting them into the register before a supervisory review does it first.
The end game is not discovery for its own sake. It is discovery for the sake of a register that is actually true - one that survives being told, cold and with no notice, to show everything that touches a given critical function.
Where to start, before the next review
A full programme is not the first move. A narrower question is.
Take the five systems your critical functions could not run without for a week. For each one, find what it switched on in the last year that nobody put in the register - the feature, the connector, the integration, the automation. That is a smaller task than DORA asks in full, it can be finished before the next review, and the answer tells you how far the gap runs.
If you want to test the register directly rather than start from the systems, five questions tend to expose the gap quickly:
Ask for every ICT asset supporting your top critical function, then ask which of them has no contract behind it. The register that can only answer the contracted half is the register with the gap.
Ask when each entry was last reviewed, and what would have flagged an AI feature switched on since. Annual review only works if something feeds it new assets between reviews.
Ask which entries are internally built rather than bought. A register that lists only vendors has quietly narrowed Article 8 down to Article 28's contractual scope.
For each critical function, ask who owns the AI running inside it, including the models and scripts nobody procured. An asset with no owner has no one to answer for it under review.
Ask how the dependency map of one critical function would be produced for a supervisor today, cold. The share of the answer that comes from asking around, rather than from the register, is the share that is not really governed.
I will be honest about the limit of this. Discovery finds the tools; it does not, on its own, tell you how each one classifies under DORA, and that classification is still substantially a matter of judgement rather than something a scan hands you finished.
Finding the reconciliation assistant is the easy part. Deciding what it is, what it touches, and what the framework then asks of it is the work that follows, and it is work a person still has to do.
Frequently asked questions
What does DORA's Article 8 asset register have to include for AI tools?
Montro's position is that Article 8's asset-identification duty already covers them. The obligation is to identify and classify every ICT asset supporting a critical or important function - including AI that entered the estate as a feature, a script or an integration rather than a procured product. The practical test is not whether something came with a contract, but whether it now supports a function that matters.
How is shadow AI different from shadow IT for DORA purposes?
They are different units of analysis. Shadow IT is an unregistered application; shadow AI is often a capability switched on inside an application the firm already has and already trusts. Discovery methods built for shadow IT - SSO log analysis, new-domain alerts - catch the first and miss the second, because the second is not a new login or a new vendor. It is a feature.
Can procurement controls alone keep the register accurate?
No. Procurement governs the AI that asks permission; it does nothing about the AI that arrived as a version update or a weekend integration. Keeping the register accurate needs continuous discovery across the existing estate, not only a tighter gate at the point of purchase.
