- DORA and NIS2 barely mention AI, but AI is ICT, and both laws govern ICT. The obligations attach whether or not the word appears in the text.
- The AI vendors and models you use are third parties in your ICT supply chain, which both regimes already require you to manage.
- If AI causes or contributes to an incident, the same reporting clocks start. Under NIS2 that can mean an early warning within 24 hours and a notification within 72 hours.
- NIS2 puts cyber risk on the management body, and DORA puts ICT risk on the board. "An employee used a chatbot" is not a defense when accountability sits at the top.
When I talk to security and risk leaders in banks, insurers, and the sort of infrastructure companies NIS2 now covers, AI and regulation usually come up as two separate worries. There is the AI conversation, which is exciting and a little chaotic, and there is the DORA or NIS2 conversation, which is heavy and full of deadlines. People treat them as different projects with different owners. I think that is the mistake, and it is an expensive one.
Here is the thing that reframes it. Neither DORA nor NIS2 has much to say about artificial intelligence specifically. You can read both and barely find the term. That leads a lot of people to assume AI sits outside them, in a gap the EU AI Act will fill later. It does not. Both laws govern your ICT, your information and communication technology, and an AI tool is ICT like any other system. The obligations you already carry do not politely wait for a rule with "AI" in the title. They attach the moment the technology touches a process they cover.
A quick note before we go on. DORA and NIS2 apply to specific sectors, mainly financial entities for DORA and a widening list of essential and important entities for NIS2. If your organization sits outside both, do not tune out. The three practical steps further down are not really about these two laws. They are what responsible AI adoption looks like anywhere, and they are close to what the EU AI Act and most other frameworks will ask of you next.
Neither law says much about AI. That does not let you off.
DORA has applied to the EU financial sector since January 2025. NIS2 widened the old network-and-information-security rules to a much larger set of essential and important entities, with member states transposing it from late 2024. Both are in force now. And both are written around outcomes rather than named technologies: manage your ICT risk, secure your supply chain, report your incidents, prove you can keep operating when something breaks.
Read that way, an AI system is not a special case. It is a new ICT asset that happens to be very capable, connects to a lot of your data, and in some forms acts on its own. The question the regulator will ask is not "did you have an AI policy." It is "did you manage this system the way you are required to manage any system that can affect a critical service." If the honest answer is that you did not know the system was there, you have a problem that predates AI entirely.
Your AI vendor is a third party in your supply chain
This is where the two regimes bite first, and it is the part most AI rollouts overlook. Both DORA and NIS2 care intensely about third-party and supply-chain risk. DORA requires financial entities to keep a register of their ICT third-party arrangements and to manage concentration and dependency, with a dedicated oversight regime for the providers deemed critical. NIS2, in its risk-management measures, requires entities to address security in their supply chain and in their relationships with direct suppliers.
An AI assistant, a hosted model, an API you call for inference, all of these are ICT third-party providers. When a team adopts one, they are adding a supplier to the chain that both laws expect you to have mapped. If that adoption happens informally, a developer signs up for an API, a department switches on a tool, then you have an unregistered third-party dependency processing your data. That is not a gray area. It is precisely the thing the third-party rules exist to prevent.
The incident clock does not care that it was AI
Both regimes run on incident reporting, and the timelines are unforgiving. Under NIS2, a significant incident can require an early warning to the authorities within 24 hours of becoming aware of it, a fuller notification within 72 hours, and a final report inside a month. DORA sets out its own staged reporting for major ICT-related incidents, with initial, intermediate, and final submissions.
Now picture an AI-shaped incident. Sensitive data flows into an external model and out again. An automated agent makes a cascade of wrong decisions before anyone notices. A sanctioned copilot surfaces records to the wrong people at scale. Any of these can meet the threshold for a reportable incident, and the clock starts when you become aware, not when you finish investigating. You cannot report inside 72 hours on activity you could not see, and you cannot reconstruct what an AI system did from memory. The reporting obligation quietly assumes you kept a record. If you did not, the deadline is the least of your worries.
The board is accountable now
The change people underestimate most is where responsibility landed. NIS2 pushes cybersecurity risk management onto the management body itself, which must approve the measures and oversee their implementation, and it makes clear that leaders can be held accountable. DORA is just as direct in placing the ICT risk framework in the hands of the board. This is deliberate. The lawmakers wanted these to be boardroom topics, not something buried three layers down in IT.
That is why the casual line you sometimes hear, "well, an employee just used a chatbot," falls apart under these laws. When accountability sits with the management body, the fact that the exposure came in through informal, unsanctioned AI use is not a mitigation. It is evidence that the oversight the law requires was not there. A board cannot govern a footprint it has never been shown.
What compliance looks like, one lane at a time
The good news is that you almost certainly have the machinery already: a third-party register, an incident process, a risk framework, and a board that signs off on it. The work is not to build a parallel AI regime. It is to make sure each kind of AI usage actually flows through that machinery. It helps to take them one at a time, because AI does not show up in your organization as a single thing. It shows up as three, and each carries a different compliance job. (I broke down these three lanes in Shadow AI Is Only a Third of the Problem.)
Shadow AI: the tools your people brought in
In DORA and NIS2 terms this is unregistered third-party ICT quietly processing your data, with no log behind it. You cannot list a supplier you cannot see, and you cannot make a 72-hour incident report on activity you never captured. What to do: get visibility into unsanctioned AI use first, then give people a sanctioned route so the work moves somewhere you can register, log, and manage. A blanket ban does not satisfy the obligation, it just pushes the exposure out of view, which is the opposite of what a regulator wants to see.
AI chat: the assistants you approved
An approved copilot belongs on your third-party register, but getting it registered is not the end of the job. It inherits the access of whoever is using it and reaches across your data estate, which makes it a privileged system. What to do: record what data it can actually reach and what it actually did, retain those logs so they are there when an incident clock starts, and review its access the way you would any other privileged account. Approved is the start of oversight, not a substitute for it.
Programmatic AI: agents and API calls
Agents and service accounts are ICT dependencies that act on their own, usually with long-lived credentials and no human watching. That is exactly the concentration and resilience risk DORA testing exists to probe. What to do: inventory every key, agent, and service account as a third-party dependency, log what they do, and put them in scope for your resilience testing and incident playbooks rather than treating them as invisible plumbing.
Across all three, one obligation repeats: you have to be able to show what happened. The register, the incident clock, and the board report all assume a durable record of AI activity rather than a reconstruction after the fact. That is why the inventory is not just good hygiene here. Under DORA and NIS2 it is the thing the rest of your compliance rests on.
Where this leaves you
None of this is an argument to slow down on AI, and in regulated sectors the pressure to adopt it is real and reasonable. The point is narrower and, I think, freeing. You do not need a brand new compliance program to roll out AI responsibly under DORA and NIS2. You need to treat AI as what it is, a powerful new class of ICT, and route it through the risk, third-party, incident, and governance processes you are already required to run. The organizations that get this right will not be the ones with the thickest AI policy. They will be the ones who can show, on any given day, what AI is in use, who supplied it, and what it did.
Make AI visible to the processes you already run
Unseen gives regulated organizations a live inventory of AI usage and a durable record of what it did, so third-party, incident, and board reporting have something real to stand on.
See a Demo