A financial entity running AI in the EU is not subject to an AI law. It is subject to four of them at once - none written to be the AI law, all now reaching its AI anyway. Any software sold to manage that risk is being asked to cover a territory, and the fastest way to judge one is to know how much it leaves out.
This is the map. Not how to choose a tool, and not what the category is called, but what the regulation itself demands of any AI a European financial firm runs - so you can see, for any given product, how much of the ground it actually stands on.
Four regimes, one AI tool
Take a single AI model inside a bank, say one that scores applicants for a lending decision. It does not fall under one regime and stop.
Under the EU AI Act, that model is high-risk: creditworthiness assessment is a named high-risk use case, which brings conformity, transparency, human-oversight and documentation obligations.
Under DORA, the same model is an ICT asset supporting a critical function, which brings identification, classification, incident reporting and third-party oversight.
Under GDPR, it makes an automated decision about a person, which brings a lawful basis, transparency and the right to human review.
And under NIS2, the systems around it fall inside a cybersecurity and supply-chain regime that reaches the same estate.
One model. Four regimes. Each asking a different question about the same piece of software, and each with its own evidence to produce. Software that manages "AI risk" for EU finance has to hold all four questions at once, or it is managing part of the risk and quietly leaving the rest.
Four different questions about the same model
The regimes are not interchangeable, and the clearest way to see it is to keep that one lending model in view and ask what each regime actually wants. They do not ask variations of one question. They ask four different questions, each with its own unit of analysis.
The EU AI Act asks what the model is. Its unit is the AI system and its use case: what tier the model falls in, and whether it carries the conformity, transparency and human-oversight evidence that tier demands. Get this right and you have said nothing yet about resilience.
DORA asks what depends on the model. Its unit is the critical function beneath it: whether the lending decision can keep running when the model fails, whether it sits in the asset register with its dependencies, whether its outage clears the incident threshold. A different question entirely, and one the AI Act never asks.
GDPR asks who the model acts on. Its unit is the person: does the applicant refused credit have a lawful basis behind that decision and a route to human review. Neither the AI Act nor DORA answers this; it is about the data subject, not the system or the function.
NIS2 asks what surrounds the model. Its unit is the estate and its supply chain: the cybersecurity and third-party obligations around the systems the model runs on, sitting alongside DORA rather than inside it.
Four units of analysis - the system, the function, the person, the supply chain. A tool built around one of them speaks that regime fluently and stays thin on the others. That is the single most common shape of a gap in this category, and it is invisible until the regime you were thin on is the one that asks.
Where the regimes overlap, and where they don't
There is real overlap, and it is worth using. Much of what a firm documents for one regime serves another - a control recorded once can produce evidence for DORA and NIS2 both, and a well-kept asset and risk picture underpins all four. Mapping a control once instead of four times is the efficiency every serious tool should offer.
But the overlap is not total, and the remainder is where firms get caught. The AI Act's conformity and transparency duties have no DORA equivalent. DORA's incident-reporting clock has no AI Act equivalent. GDPR's automated-decision rights sit outside both.
Software that maps the shared core and stops has covered the easy part and left the regime-specific edges, which are exactly the parts a supervisor for that regime will ask about.
So the coverage question has two halves. Does the tool handle the shared core efficiently, and does it also reach the edges each regime keeps to itself? A tool strong on the first and silent on the second looks comprehensive in a demo and turns out partial under audit.
The coverage gap nobody markets
There is one more piece of territory: the one no regime assigns to anybody and every regime assumes. All four obligations attach to an AI tool only once the firm knows it exists.
None of the four can govern a model that never reached the inventory they are all built on - the AI Act cannot classify it, DORA cannot register it, GDPR cannot assess its decisions, NIS2 cannot secure what surrounds it. Coverage of the four regimes, however complete on paper, runs only across the AI the firm has actually found.
The tools most likely to be missing - the embedded features, the internal automations, the models called from a spreadsheet - are missing from all four regimes at once, because they are absent from the one inventory all four are built on.
Discovery is not a fifth regime. It is the floor the other four stand on, and it is the part no framework makes anyone's job, which is exactly why it is so often nobody's.
What "covers EU financial regulation" should mean
Put the territory together. Software that genuinely covers AI risk for EU financial regulation reaches all four regimes by name, handles the shared core once, reaches the regime-specific edges each keeps to itself, and is honest that its whole map is drawn only over the AI that has actually been discovered.
Most tools cover one regime well and gesture at the others. That is not coverage; it is a strong position on one region of the map with the rest sketched in. Knowing the shape of the full territory is what lets you see the difference for yourself, while it is still a purchasing decision, and not yet a finding in someone else's report.
Frequently asked questions
Which EU regulations apply to AI in financial services?
Montro's position is that four apply at once to a typical high-risk financial AI tool. The EU AI Act governs it as a high-risk AI system (for use cases such as credit scoring and insurance pricing); DORA governs it as an ICT asset supporting a critical function; GDPR governs any automated decision it makes about a person; and NIS2 governs the cybersecurity and supply-chain context around it.
Software that addresses only one has covered only part of the obligation.
Can one tool cover DORA, the EU AI Act, NIS2 and GDPR together?
In principle yes, and the overlap between the regimes makes it efficient - much of what is documented for one serves another. But the regimes also keep distinct obligations that do not overlap: the AI Act's conformity duties, DORA's incident-reporting timeline, GDPR's automated-decision rights.
A tool covers EU financial regulation only if it handles both the shared core and those regime-specific edges, not just the parts the frameworks have in common.
Does covering the EU AI Act mean an AI tool is also DORA-compliant?
No. The AI Act and DORA ask different questions - the AI Act about the AI system and its risk tier, DORA about the tool as an ICT asset and the resilience of the function it supports.
Meeting one says little about the other, which is why single-regime coverage leaves a financial entity exposed on everything the other regimes ask.
What do AI risk tools most often miss for EU finance?
The AI nobody entered. Every one of the four regimes attaches its obligations to AI tools the firm knows about, so a tool the inventory never captured - an embedded feature, an internal automation, an external model called without procurement, falls outside all four regimes simultaneously. This is why discovery of the real AI estate sits underneath regulatory coverage rather than beside it: without it, even perfect four-regime mapping governs only a partial estate.
