Banks deploying AI in Europe are doing so under three regimes at once: the Digital Operational Resilience Act, the NIS2 directive on cybersecurity and the EU AI Act. The instinct inside a large institution is to give each its own programme, its own owner and its own register.
Marco Eggerling, Field CISO at UiPath, thinks that is the mistake that leads to most of the others. In written answers to The Fintech Times he sets out how far the three frameworks overlap, what governance beyond box-ticking looks like once a model is in production, and why board-level AI literacy is the supervisory expectation he would prepare for now.
Three frameworks, one question
“They complement each other more than most banks realise as they are all converging on the same underlying question: can you prove operational resilience and control over a system you do not fully understand end-to-end?” Eggerling says. “DORA, NIS2 and the AI Act may have different requirements, but they all rely on the same core information about your systems and third parties.”
In his view the overlap is large enough to put a number on. “If you have mapped your critical ICT services for DORA, you already have 70 per cent of what you need for the AI Act provider, deployer classification and NIS2 supply-chain risk.”
Where firms go wrong, he says, is in treating the three as separate programmes with separate owners. “Operational risk owns DORA, IT security owns NIS2, a new “AI governance’ team owns the AI Act and its registers. That can quickly lead to duplicate vendor assessments, conflicting incident-reporting clocks, and, in the worst-case scenario, a critical AI vendor that is assessed as ‘compliant’ in one register and flagged as high-risk in another.” His fix is to “use one shared set of controls, one list of third parties and AI systems across all three frameworks”.
Beyond the spreadsheet
Asked what moving beyond checkbox compliance looks like for a bank deploying AI at scale, he starts by describing the checkbox. “Checkbox compliance looks like a model inventory spreadsheet, a signed-off risk assessment template, and an annual audit. The reality of these static processes is that the information provided is often outdated and inaccurate.”
The alternative is continuous. “Moving beyond that means continuously monitoring how AI models behave in production, so looking out for things like drift, bias creep and unexpected inputs. It requires having a kill switch and rollback capability that has been tested. And it enables business owners to explain in plain language what the model can decide on its own and where a human needs to step in.” Timing matters as much as content: AI risk assessment, he says, should take place “before procurement or build sign-off, rather than as a retrospective audit exercise bolted onto a system that is already in production”.
A name against every decision
Eggerling has argued that accountability is becoming the cornerstone of AI security. Inside a large institution, he would structure it “around a named, accountable executive for each material AI use case and not for every individual model, but for each decision domain, such as credit decisioning, AML alerting or trade surveillance”. The risk team sets guardrails and challenges the teams using AI, while a board-level committee “should understand AI well enough to ask the right questions rather than simply approve decisions”.
The failure pattern he sees is diffusion. “A common error is when accountability is spread across a ‘committee’ without a single person clearly attached to the decision. That becomes a real problem when there is an incident and you are trying to work out who was responsible.”
The cultural change he rates most important is about where security sits in the process. “Security and compliance cannot be the teams that just say no at the end of the pipeline. The significant cultural shift is getting engineering, risk, and business teams to see controls as part of the design from the outset, rather than a final gate to get through.” In practice that means risk and compliance people inside product teams early, while there is still time to shape how a system is designed, and, he says, “rewarding people for raising AI risk issues early rather than creating a culture where teams are reluctant to be the bearer of bad news”. AI literacy, in his view, should be a baseline expectation for anyone deploying or overseeing these systems, senior leaders and boards included. “They do not need to be technical experts, but they should understand AI well enough to spot risks, challenge assumptions and ask the right questions.”
Automate the evidence, not the decision
UiPath sells automation, and Eggerling’s answer on where automation helps governance is a bounded one. “Automation works best for repeatable tasks like monitoring controls, gathering evidence and tracking changes in risk. This gives firms more continuous oversight and frees people to focus on decisions that need human judgement.” The line he draws is explicit. “The key is not to automate those decisions. Automation should flag risks and gather evidence, but people should make the call when the risk is significant.”
The most common mistake he sees in AI governance frameworks is starting from scratch. “One of the biggest mistakes is treating AI governance as something entirely new. Banks should build on the model risk, third-party risk and operational resilience processes they already have, adding AI-specific requirements like explainability, bias testing and human oversight where needed. This avoids creating duplicate processes and gaps in governance.”
The next 12 to 18 months
On what security and compliance leaders should prepare for, he is wary of forecasting. “Given how much the EU timeline has moved around, I would be cautious about making too many firm predictions. But there is one development I would particularly expect to see: board-level AI literacy becoming a supervisory expectation.” Boards, he says, will increasingly need to understand the risks well enough to ask the right questions and challenge decisions about how AI is being used, and “that level of understanding will become an important part of effective oversight”.
He names three other shifts. “The delay to the EU AI Act’s high-risk obligations gives firms more time, but those that pause risk a compressed sprint later. We are also likely to see greater regulatory convergence, with supervisors asking for more AI-specific evidence through existing DORA and operational resilience reviews, while third-party AI risk grows as vendors embed AI into products firms already use.”
Marco Eggerling is Field CISO at UiPath, with more than 25 years of experience in information security, governance, risk and compliance. He advises organisations on AI security, governance and building trust in agentic automation.
The post DORA, NIS2 and the AI Act are One Job, Says UiPath’s Field CISO appeared first on The Fintech Times.
