DORA NIS2 AI Act compliance as one job, analysis

A bank deploying AI in Europe can now hold three compliance meetings about the same system before lunch. One team calls it operational resilience. Another calls it cybersecurity. A third calls it AI governance. The model, inconveniently, does not care which register it lives in. Marco Eggerling, Field CISO at UiPath, is making a more practical argument: treat DORA, NIS2 and the EU AI Act as one governance job. In written answers reported by The Fintech Times, he says the common question is whether an institution can prove control over a system it does not fully understand end to end. That is not a philosophical prompt. It is a procurement, logging, incident response and board reporting problem wearing three different badges.

The overlap is the point,

according to The Fintech Times and Digital Chiefs The Fintech Times frames the problem plainly: banks deploying AI in Europe are operating under DORA, the NIS2 cybersecurity directive and the EU AI Act at the same time. It also notes the familiar institutional reflex, giving each regime its own programme, owner and register. Eggerling argues that this is where the trouble starts, because the frameworks converge on proof of resilience and control rather than on separate paperwork aesthetics. Translation: if your AI system fails, leaks, drifts or misbehaves in production, the supervisor will not be impressed that the incident was beautifully duplicated across three spreadsheets. Digital Chiefs puts the convergence on a calendar, stating that DORA has been active since January 2025, EU AI Act high risk obligations start in August 2026 and NIS2 enforcement begins in October 2026. The exact deadlines matter less than the operating reality they create. Financial institutions do not get three clean implementation seasons. They get overlapping obligations landing on the same systems, suppliers and decision makers.

One controls map beats three registers,

according to The Fintech Times The Fintech Times reports that Eggerling sees governance beyond box ticking once a model is in production. That phrase is doing useful work. The legal departments may maintain separate citations, but engineering and risk teams need one map of systems, dependencies, model behavior, access rights, audit logs, incident paths and vendor responsibilities. Otherwise the same outage or model failure is investigated three times, usually by people asking nearly identical questions in slightly different fonts. The practical version is not to merge the laws into one imaginary super regulation. DORA still speaks to digital operational resilience, NIS2 to cybersecurity obligations and the EU AI Act to AI governance. The point is to build shared evidence once and attach it to each obligation where relevant. For a production AI workflow, that means one inventory entry, one risk assessment lineage, one supplier file, one monitoring plan and one incident trail that can answer several regulators without improvisation.

The board is in scope too,

according to The Fintech Times and Digital Chiefs The Fintech Times says Eggerling would prepare now for board level AI literacy as a supervisory expectation. That is the part many organizations file under training and forget until the annual deck. A board does not need to fine tune a model, but it does need to understand what the system does, where it sits in critical operations and what failure would look like. If the only person who can explain the AI control environment is the vendor solution architect, that is not governance. It is outsourcing with nicer stationery. Digital Chiefs adds a sharper edge, saying both NIS2 and DORA hold executives and board members personally liable for cybersecurity failures in cases of gross negligence. That does not mean every bad alert becomes a board crisis. It does mean directors should ask for evidence they can understand before the incident, not after counsel has started using the word posture in every sentence. Board AI literacy, in this reading, is not a webinar certificate. It is the ability to ask whether the control stack matches the operational risk.

What builders should change now,

according to The Fintech Times For builders, the boring answer is the correct one: make compliance an architecture requirement. The Fintech Times reports that Eggerling is focused on what control looks like once a model is in production, which is where many AI governance programmes stop being slideware and start touching logs, alerts and contracts. If a bank uses automation or AI inside a regulated workflow, the product team should know which evidence is generated automatically and which evidence still depends on someone remembering to update a register on a Friday. The useful checklist is short enough to survive contact with engineering. Identify the AI system and its business function. Map its operational dependencies, cybersecurity controls, model governance controls and third party responsibilities. Decide which evidence can support DORA, NIS2 and AI Act obligations together. Then test the incident path, because the first real audit often arrives disguised as an outage. The counterintuitive lesson from UiPath’s Field CISO is not that Europe has made compliance simple. It has not. The lesson is that overlapping rules punish siloed operations more than they punish careful mapping. For readers building or buying AI in regulated sectors, the next useful question is not which law owns the problem. It is whether your evidence trail can survive being asked the same question three ways.