Your AI-Generated Code Has a DORA Problem. And the Clock Is Running.

The Digital Operational Resilience Act entered into force on January 16, 2023, and became fully applicable on January 17, 2025. It applies to approximately 22,000 financial entities across the European Union: banks, insurers, investment firms, payment institutions, crypto asset service providers. It sets binding requirements for ICT risk management, incident reporting, and digital resilience testing. → DORA Scope

Most compliance teams read DORA as an infrastructure story. Firewall configurations. Backup procedures. Third-party vendor assessments.

It isn’t. It’s a software quality story. And if your organization is producing code with AI tools (which, statistically, it almost certainly is), the compliance exposure is already live.

What DORA Actually Requires That Most CTOs Aren’t Measuring

DORA’s Article 8 requires financial entities to identify, classify, and continuously monitor all ICT risk sources. Article 9 mandates protection and prevention controls. Article 10 requires detection capabilities. Article 11 sets response and recovery obligations. → DORA Full Text, EUR-Lex

None of this is new in spirit. What changed is the scope of what it covers, and AI-assisted development falls squarely inside that scope.

Consider what AI tooling actually produces. Not just faster code. Faster unknown code. Code whose behavior under edge cases, load conditions, or error states was never explicitly specified by a human, never validated against original intent, and in many cases was never reviewed by anyone who understood the business rule it was implementing.

Under DORA, “did we test it?” is no longer a sufficient answer. The question regulators will ask is: can you demonstrate that your ICT risk management processes governed the quality of what you shipped, from requirements through production?

That’s a documentation question. An audit trail question. For most organizations building with AI tooling, the honest answer is no.

The Gap Between Velocity and Governance

Here’s the pattern emerging across regulated industries.

An organization adopts AI-assisted development. Cycle times drop. Feature velocity climbs. Leadership reports the numbers to the board and the numbers look good.

Then an incident happens. Post-mortem reveals the same finding every time: a code path no human explicitly designed, tested for, or documented. The AI generated it. Tests passed. No one flagged it. The customer found it.

Under a pre-AI compliance framework, that’s an operational failure. Under DORA, it may also be a reportable ICT-related incident, with mandatory notification timelines, root-cause reporting requirements, and audit exposure that compounds with each subsequent occurrence.

Speed without governance doesn’t just create operational risk. In regulated industries, it creates regulatory risk. And unlike production incidents, regulatory findings accumulate on a record.

The compliance gap at enforcement was significant: Deloitte estimated that only 50% of in-scope organizations were fully compliant when DORA became applicable. The consequences for non-compliance are material, with fines of up to 2% of global annual turnover and personal liability for senior management reaching up to 1 million euros.

Why a Testing Gate at the End Doesn’t Solve This

The natural response is to add a QA checkpoint: run more tests, add a sign-off step before deployment.

That response addresses the symptom rather than the requirement.

DORA doesn’t ask whether you tested before shipping. It asks whether you managed ICT risk throughout the development lifecycle. That’s a span question, not a gate question.

Empirical research consistently places the majority of software defects in the requirements phase, before any code is written and long before any test runs. A gate at the end of development cannot catch a risk that was introduced when a requirement was ambiguously written three sprints ago. It can only confirm that the software does what it was built to do. Not whether it was built to do the right thing.

For DORA compliance, this distinction is material. A test report showing 98% coverage against wrong or incomplete requirements is not evidence of ICT risk management. It’s evidence that you measured the wrong thing carefully.

What NIS2 Adds to the Picture

DORA is financial-sector specific. NIS2 is not.

The Network and Information Systems Directive 2, which entered into force in January 2023 and required transposition into national law by October 17, 2024, extends binding cybersecurity and resilience requirements to essential and important entities across energy, transport, health, digital infrastructure, manufacturing, and beyond.

NIS2 Article 21 requires entities to implement appropriate and proportionate technical and organisational measures to manage cybersecurity risks, including measures that address the security of software development processes. For organizations under NIS2, the same governance gap that creates DORA exposure creates NIS2 exposure: AI-generated code that was never systematically validated represents an undocumented risk surface that no test report can retrospectively close. → NIS2 Article 21, Mayer Brown

Germany’s NIS2 implementation law (NIS2UmsuCG) was passed by the Bundestag on November 13, 2025, and entered into force on December 6, 2025, with no transition period. For any organization operating in the DACH market, this is the sharpest NIS2 compliance enforcement moment to date. It covers approximately 29,500 companies across 18 sectors; prior to its passage, only around 2,000 companies were subject to BSI oversight. The regulated population grew fifteen-fold overnight.

The provision with the highest board-level impact is personal liability. Under NIS2UmsuCG, board members and senior executives can be held personally accountable for cybersecurity governance failures, elevating software quality governance from an IT risk discussion to a direct boardroom financial risk.

Taken together, DORA and NIS2 cover the majority of enterprise organizations operating in or with the EU. If you are in scope for either, the question is not whether quality governance is a compliance requirement. It is whether yours is auditable.

What Compliance-Grade Quality Governance Actually Looks Like

Three characteristics separate auditable quality governance from a compliance ritual.

It produces evidence, not opinions. “We reviewed it” is not a DORA artifact. “Here is what was flagged at the requirement stage, what risk was identified, what decision was made, by whom, when, and how that decision was reflected in test coverage downstream” is. The audit trail runs from intent to outcome, and it exists independent of the individuals who made the decisions.

It spans the full lifecycle. DORA’s ICT risk management framework is continuous, not episodic. A quality process that activates only at the testing gate leaves the majority of the development lifecycle ungoverned and undocumented, which is precisely where most AI-generated defects originate.

It runs at the speed of the pipeline it governs. A compliance process that takes three days cannot govern a pipeline that ships weekly. When governance is slower than delivery, it becomes a bottleneck. When it becomes a bottleneck, it becomes optional. When it becomes optional, it becomes theater. And at audit time, the theater is clearly visible in the gap between what was documented and what was shipped.

How RabbitQA Creates an Auditable Quality Trail

RabbitQA is a multi-agentic AI platform for digital product quality. It was built to address the governance problem that regulations like DORA and NIS2 now make explicit: quality assurance that spans the full lifecycle, operates at pipeline speed, and produces traceable evidence rather than point-in-time test results.

The platform runs on three commitments: Predict Risk. Prevent Failure. Protect Revenue.

Business Agent validates every requirement before it enters development. It flags ambiguity, stakeholder conflicts, missing error states, and untestable acceptance criteria. Every flag is logged. Every decision is recorded. When an auditor asks why a feature was built a particular way, or why a risk was accepted, the answer exists in the system and not in someone’s memory.

Planning Agent turns validated requirements into test coverage. It generates test cases, manages test plans, and prepares test data. Because it shares a knowledge layer with the Business Agent, risks flagged at the requirement stage remain visible when tests are designed. Coverage decisions are traceable to the requirements that drove them, which is what a DORA-aligned audit trail requires.

Technical Agent proves it in the real world. It executes tests across platforms, validates APIs, and monitors production health continuously. What production teaches, the system records, creating a feedback loop that not only catches failures early but strengthens the evidence base for future compliance reviews.

Throughout, every output is reviewable, explainable, and audit-ready. The agents surface findings. Humans decide. That accountability chain, visible, logged, and traceable, is precisely what DORA’s ICT risk management requirements are asking for.

When DORA asks “how did you manage quality risk throughout your development process?”, RabbitQA’s answer is a ledger. Not a gate.

The Question to Ask Before Your Next Audit

If your organization received a DORA audit request this week, how far back could you trace the quality governance decisions on your last major release?

Not the test results. The decisions. Who validated the requirements. What risks were flagged. How coverage was determined. What production taught you, and whether that learning changed anything upstream.

For most organizations building with AI tooling, the audit trail ends at “tests passed.” DORA’s questions don’t end there.