DORA's Enforcement Phase Wants Evidence, Not Policy PDFs.
For most of its early life, financial-sector compliance rewarded good documentation. You wrote the policy, you mapped the controls, you kept the binder current, and when the supervisor came you handed over a well-organized set of PDFs. The document was the deliverable. An organization that could describe its resilience convincingly was, for regulatory purposes, resilient.
However, that era is closing. DORA, the EU's Digital Operational Resilience Act, has been in force since 17 January 2025, and in 2026 it entered its enforcement phase. As reported in the Dawiso analysis of AI agents in banking under DORA, and echoed across the Auriga and ATM Marketplace coverage of AI governance for financial institutions, supervisors have shifted what they will accept. They have moved from taking policy documents at face value to expecting data-driven evidence of resilience. The binder is no longer the deliverable. The proof is.
That shift lands hardest on exactly the systems banks are now rushing to deploy. Because a policy PDF describing how your agents behave and an evidence trail proving how they behaved are two entirely different artifacts, and the second one is the only one that survives an enforcement-phase review.
The gap the enforcement phase exposes
A policy is a description of intended behavior. Evidence is a record of actual behavior. In the pre-enforcement world those could stand in for each other, because no one was checking the second against the first. The enforcement phase closes that substitution.
The reason this matters now, and not five years ago, is what banks are deploying. The Dawiso reporting projects that around 44% of finance teams will be using agentic AI in 2026, a large jump. That is the collision at the center of this story. A supervisory regime that has just started demanding evidence of actual behavior is meeting a wave of systems whose actual behavior is probabilistic, changes with every model update, and, in most deployments, is barely recorded at all.
The named risks in that coverage are specific, and they are not abstract. Uncontrolled agent access to internal systems. Inadequate logging that makes incident reconstruction impossible. Read those two together and you have the precise failure mode DORA's enforcement phase is built to catch: a system that can act on your core platforms, and cannot afterward tell you what it did or why. The policy PDF said it was governed. The review asks you to prove it, and there is nothing to show.
An agent that cannot reconstruct what it did cannot pass a DORA review
This is the sentence to internalize, because it converts a vague compliance anxiety into a concrete architectural requirement.
DORA's resilience expectations assume that when something goes wrong, you can reconstruct it. Incident reporting, root-cause analysis, and the whole operational-resilience posture rest on the ability to answer, after the fact, what happened, in what order, and on what basis. For deterministic software that is a solved problem: the logs are the story, and the code that produced them does not change between the incident and the investigation.
An agent breaks that assumption in two ways. First, it acts on live context and reasons probabilistically, so "what would it have done" is not recoverable by re-running the code. Second, if the logging is inadequate, as the coverage explicitly names it, then even "what did it actually do" is unrecoverable. An agent that read a dossier, reasoned over it, and posted a decision, but left no inspectable record of the inputs it saw, the policy it applied, and the verdict it reached, has produced an outcome no one can reconstruct.
Under the old regime that was survivable, because you could point at the policy. Under enforcement, it is disqualifying. An agent whose decisions cannot be reconstructed cannot be shown to be resilient, and a system that cannot be shown to be resilient does not pass. The absence of evidence is not a documentation gap you fix later. It is a permanent hole, because you cannot retroactively record decisions the system already made without capturing them.
Compliance as executable policy, evidence as a byproduct
The way out is not to write a better policy PDF. It is to build an architecture where the policy is executable and the evidence is produced automatically, as a condition of the system running at all.
Two properties do the work, and they map directly onto what "evidence, not policies" demands.
Compliance as executable policy. Instead of a document that describes the rules, the rules are code your compliance team owns, versions, and signs, evaluated at the moment of each decision. Every consequential action passes through a policy decision point that returns a machine-readable verdict: allow, allow with documented conditions, deny, or require a human. The regulatory weight that cannot be delegated resolves to a human by policy; the agent only analyzes. The policy is no longer a claim about behavior. It is the mechanism that produces the behavior, and it can be tested, re-approved, and proven.
An append-only, hash-chained evidence trail. Every decision writes an immutable record, before the decision commits, of the inputs the agent saw, the policy version it ran against, and the verdict it reached. Hash-chaining the entries makes the trail tamper-evident: you can prove not only what happened but that the record was not altered afterward. And it fails closed. No evidence store, no decision. The system physically cannot act without leaving the record a supervisor will ask for.
Put those together and reconstruction stops being a hope and becomes a query. When the enforcement-phase question arrives, what did this agent do, on what basis, and can you prove the record is intact, the answer is a report you run, not an investigation you launch. The evidence exists because the architecture could not have produced the decision without creating it.
That is the difference between describing resilience and demonstrating it, and it is exactly the difference DORA's enforcement phase was built to test.
The reframe
The question banks are still asking, the one that produces another binder, is "do we have a policy that covers our AI agents?" In the enforcement phase that question is answering a test no one is giving anymore. Having the policy is table stakes. Proving the behavior is the exam.
The better question is this. When a supervisor asks us to reconstruct exactly what one of our agents did, on what data, under which rule, and to prove the record was not touched, can we run that as a report, or do we have to admit we did not capture it? If the honest answer is the second one, no policy PDF closes the gap, because the gap is not in your documentation. It is in your architecture, and the enforcement phase reads architecture, not intentions.
The supervisors changed what they accept. The systems being deployed made the change urgent. And the organizations that build the evidence trail into the agent, rather than writing a policy about it, are the only ones who will pass the review they are now certain to face.
If you want to test whether your agentic processes could produce a reconstruction a DORA supervisor would accept, book a meeting and bring us the one that touches the most internal systems.