Originally published on the Dromeas blog.
In short: DORA doesn't care who wrote a change, human or AI. It wants proof that every ICT change was assessed, tested and approved, and that vulnerabilities are tracked to closure. For teams shipping AI-generated code, that means a review and release record you can show a supervisor.
DORA has applied since January 2025. For a lot of engineering teams at EU banks, insurers and payment companies, 2025 felt like a warm-up year. Compliance advisors are now describing 2026 as the year supervisors actually start using their powers: reviews, findings, and eventually penalties.
At the same time, a growing share of the code going into those systems is written by AI. Those two things meet in your release pipeline, and I think it's worth being clear on what DORA really asks for there.
The parts of DORA that land on engineering
DORA (the Digital Operational Resilience Act, Regulation 2022/2554) gets called a cybersecurity law, but it's really about resilience. It wants financial firms to be able to handle ICT disruptions, and to be able to show it. Three parts matter most for a software team.
ICT risk management. You need a documented framework, owned by the board. The detailed technical standards get specific. There's an article on vulnerability and patch management, and another, Article 17, simply called "ICT change management." It asks for documented procedures for how changes get approved, tested and recorded. In practice: have a real review and release process, and keep evidence that you followed it.
Third-party risk. This is the one people tend to underestimate. You keep a register of every ICT third-party arrangement (what it does, what data it touches, where, and under what contract). You look at concentration risk. And your exit plans have to be ones you could actually carry out. In November 2025 the European supervisors published their first list of 19 "critical" ICT providers, the big cloud and infrastructure names, which are now overseen directly at EU level. That list gets updated every year.
Penalties. A lot of explainers get this part wrong. For those critical providers, DORA sets the penalty itself: up to 1% of average daily worldwide turnover, charged daily for up to six months. For financial firms, each country sets its own maximums, and they vary a lot. A DLA Piper briefing from last November found turnover-based caps from 5% in Spain to 10% in Sweden, and fixed caps from €2 million in Czechia to €20 million in Italy. If you've seen a neat "2% or €1 million" figure somewhere, it doesn't match how DORA works.
Why AI-generated code makes this harder
DORA doesn't mention AI. It doesn't need to. A change to a production system is a change, whether a senior engineer wrote it or a coding assistant did. The obligations stay the same. The volume and speed of change don't.
I see two separate problems here.
Evidence isn't keeping up. Tricentis published their 2026 Quality Transformation Report in June, based on 2,501 people across six countries. Six in ten organizations said they deploy untested code to production. Financial services came out worst at 64%. And 30% said the sheer volume of AI-generated code is more than their teams can fully test. For a firm covered by DORA, "we shipped an AI-assisted change we didn't fully test" isn't just a quality issue. It's a hole in exactly the change management evidence Article 17 asks you to keep.
The AI tool is a third party too. If your engineers use a coding assistant, or you've wired a model into your review or release pipeline, that vendor usually belongs in your register like any other ICT provider. What does it do, what data can it see, where is that data processed, and could you switch if you had to? A handful of model providers dominate this market, which is exactly the concentration question DORA asks. The regulation doesn't spell this out. It's how the compliance advisors I've read apply DORA's existing third-party rules to AI vendors.
Put simply: AI-assisted development doesn't change what DORA asks of you. It makes the paper trail a lot harder to keep by hand. An approval from someone who didn't write most of the diff isn't strong evidence on its own.
Where Dromeas fits
Dromeas sits between AI-assisted coding and production, and a lot of what it produces happens to be the evidence DORA-covered teams need anyway. Every PR, trunk commit and local diff gets reviewed by a council of models from different providers that cross-check each other, and each verdict comes with the evidence behind it. Every tagged release gets a verdict across six checks, plus a changelog grounded in the real diff. See release management for how that works, and compliance for the frameworks we cover.
It doesn't replace your compliance team's reading of DORA. It means the evidence exists when they need it, instead of being pieced together afterwards.
— Manos
Sources: EIOPA, DORA overview · RTS 2024/1774 via Springlex · Morgan Lewis, critical ICT providers · DORA Article 35 · DLA Piper, DORA penalties · Tricentis 2026 Quality Transformation Report
Top comments (0)