By Jinal Shah, Co-Founder & CEO of Regulativ.ai
On 17 January 2025, DORA entered into application across the EU, closing two years of preparation that left most financial entities still working through what compliance required. Over a year later, many of those same teams manage record volumes of regulatory change through the tools they used before DORA existed: spreadsheets and shared inboxes.
Reading the rules is not usually where organizations struggle. The harder gap is monitoring several regulatory regimes at once and turning that monitoring into something that runs day to day rather than living in someone’s inbox.
This is where compliance now sits in financial services and technology. The EU AI Act’s phased high-risk obligations, NIS2 Directive, and the UK’s ongoing divergence under the Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) are all landing around the same time, hitting many of the same business units, and continuing to generate technical standards and supervisory guidance long after their headline dates have passed. Most teams have by now read each of these frameworks closely. What is missing is the connective infrastructure to run obligations from all of them without anything falling through the cracks.
The breakdown happens because horizon scanning, obligation mapping, and evidence collection are run as three disconnected steps instead of one continuous process. Ask a compliance manager to describe their horizon scanning and the answer is almost always the same: relevant messages from the European Banking Authority (EBA), European Securities and Markets Authority, the Information Commissioner’s Office (ICO), and the AI Office land in a shared inbox or document, get assigned manually by email, get tracked in a project management tool that wasn’t built for regulatory work, and the evidence of completion ends up in a folder somewhere.
This holds up well enough at low volume. But as soon as one quarter brings DORA technical standards, revised guidance on Article 9 of the AI Act, an FCA operational resilience consultation, and updated NIS2 transposition from three member states all at once, it stops working. Things get forgotten. Obligations sit without an owner. Evidence gaps surface weeks before a supervisory review, the worst time to find them.
The most common failure points are horizon scanning, obligation mapping, and evidence collection, and they compound each other. If something is not logged as an obligation, it is not fulfilled. If it is not fulfilled, nobody is gathering evidence against it. That gap is typically spotted by someone outside the team, not inside it.
Case study: DORA Article 30 in action
Under Article 30 of DORA, financial entities must have written contractual arrangements with their information and communication technology (ICT) third-party providers that cover, at minimum, service descriptions, data locations, incident notification procedures, and termination rights. In a mid-sized institution with 40 to 50 active ICT providers, that is 40 to 50 separate assessments to run, document, and update, each with its own evidence trail.
In practice, this usually runs from a spreadsheet: columns for each Article 30 requirement, rows for each provider, and a traffic light status updated by whichever happens last, the institution’s own review or the provider’s input. That holds until the guidance changes faster than anyone updates the spreadsheet. When the EBA later clarified the scope of Article 30 through its Q&A process, no spreadsheet updates followed automatically. Someone had to read the clarification, work out which provider assessments it touched, and manually cascade the change through each row. The institution’s record of that obligation stayed wrong for every day the cascade took.
An automated workflow instead runs a classification step, flags the obligation records affected by the EBA update, and sends task assignments to the obligation owners with the obligation, the EBA guidance, and the deadline attached. The record updates once the owner closes the task, and the audit trail is complete. Regulatory compliance automation platforms are built for exactly this kind of obligation-level workflow, where a regulatory update flows straight through to assigned tasks and evidence collection without manual handling.
The difference is real. When a regulatory change affects every provider’s record, it updates each one individually, rather than waiting for someone to recognize the change and update the corresponding row by hand.
The AI Act is the next stress test
The EU AI Act will be more demanding than DORA. Bans on AI systems with unacceptable risk have applied since 2 February 2025. Under the Omnibus timeline agreed on 7 May 2026, high-risk obligations under Annex III, covering AI used in employment, critical infrastructure and financial services credit assessment, apply from 2 August 2026 for newly placed systems and from 2 December 2027 for systems already in use. Obligations for general-purpose AI models under Article 53 have applied since 2 August 2025.
Under the Omnibus timeline agreed on 7 May 2026, obligations for Annex III high-risk AI systems, including AI used in employment, critical infrastructure, and creditworthiness assessment, apply from 2 December 2027. Obligations for Annex I high-risk AI systems embedded in regulated products apply from 2 August 2028. Obligations for general-purpose AI models under Article 53 have applied since 2 August 2025.
For the latest timeline and implementation details, see the Council of the European Union’s announcement on the Omnibus agreement.
For financial services compliance teams, this is not adjacent to DORA, it overlaps with it directly. An AI system used for credit decisioning can be a high-risk system under the AI Act and an ICT third-party service under DORA at the same time, which makes mapping the obligation across both frameworks genuinely complex. The cost of getting it wrong is real: the AI Act allows penalties of up to €15 million or 3% of global annual turnover for failing to meet high-risk system requirements.
Compliance teams usually have the expertise to handle this complexity. Finding the time to apply it is the hardest problem.
Automating that tracking starts with a process diagnosis, not a technology purchase. Teams that understand where their manual process breaks down, and approach automation with that in mind, get far more out of it than teams that buy a platform first and work out the process afterwards.
For many teams, the gaps are the same three. Regulatory updates land in an unsorted feed, which makes them easy to lose or miss. Obligation records are not tied to the source requirements that created them, so a change in guidance does not automatically flag which obligations it affects. And evidence lives in folders rather than tied to the obligation record it supports, which means proving compliance means piecing together a picture after the fact instead of pulling up a trail that already exists.
The judgement involved here goes well beyond what automation can do: how much an EBA Q&A affects a firm’s assessment of an existing obligation, whether an ICO enforcement notice changes a firm’s risk position under UK GDPR, whether an updated AI use case changes its risk classification under Annex III. That analysis stays with the compliance team. What automation handles is everything around those judgements: picking up the update, routing it to the right person, tracking the response, and keeping the audit trail current.
Now what?
The teams that handled the DORA January 2025 deadline well were not always the biggest ones. They were the ones that had spent the months before the deadline building their obligations tracking down to a granular level: named owners, obligations mapped to specific articles, clear lines of accountability. That is what separates a program that is compliant from one that is still catching up.
The deadline for high-risk systems under the EU AI Act is 2 December 2027. If your current method of tracking obligations across DORA, the AI Act, NIS2 and UK requirements under the FCA and PRA still runs on spreadsheets and shared inboxes, ask yourself one question: Will your program catch the failure before your regulator does?
About the author
Jinal Shah is the Co-Founder and CEO of Regulativ.ai, an advanced AI platform transforming how enterprises manage regulatory compliance, risk, and audit readiness. The platform enables organisations to navigate complex frameworks, including the EU AI Act, DORA, ISO 27001, GDPR, and over 40 others, through intelligent automation that replaces manual, error-prone processes with scalable, AI-driven precision.
With over three decades of experience in financial services, Jinal brings deep domain expertise across regulated markets, data governance, and enterprise risk management. He founded Regulativ.ai to address the growing complexity of global regulation, empowering organisations to achieve compliance with greater speed, accuracy, and efficiency delivering up to 80% reductions in time and cost.
A multi-award-winning technologist, Jinal has led large-scale transformation initiatives across data, infrastructure, and strategic delivery. He is widely recognised for his expertise in governance and his ability to bridge regulatory requirements with cutting-edge technology to drive meaningful business outcomes.