Building DORA Compliance for Banking AI Agents in 2026

Banks did not wait for a rulebook before putting AI agents to work. Agents now screen credit applications, score transactions for fraud, draft trades, and handle customer queries, often acting across several systems without a human in the loop for every step. Which regulation will eventually govern them is the obvious question. For operational resilience, one already does.

The Digital Operational Resilience Act (DORA) took effect on 17 January 2025 and applies to virtually every EU financial entity. It does not single out AI, and it does not need to. An agent that accesses data, takes actions, and talks to other systems is an ICT system within the meaning of DORA, so the ICT risk obligations in Chapter II cover it the same way they cover a core banking platform. In January 2026, Germany's BaFin made this explicit, issuing non-binding guidance that AI systems, including generative AI and large language models, are not a separate regime and must be embedded into existing DORA risk management, testing, and third-party frameworks.

The timing matters. 2026 is widely described as DORA's enforcement phase, where supervisors have shifted from accepting policy documents to expecting real, data-driven evidence of resilience. A bank that cannot show how its credit-scoring agent behaves, what data it read, and what it is allowed to touch is not DORA-ready, no matter how good the model is.

An agent acts, where a report only informs, and that shift is what DORA cares about. When a traditional report shows a wrong number, a human reviews it before anything happens. When an agent reads the wrong number, it can decline a loan, freeze a payment, or place a trade, and propagate that action across systems before anyone notices. Operational resilience now has to account for what the agent does, not just whether the server is up.

This is where the quality of the data underneath the agent becomes a resilience question rather than a tidiness one. If the agent computes "exposure" or "high-risk customer" from a definition that drifted, or reads a field it should never have been able to see, the failure is operational and it is fast. DORA's incident reporting then demands that you reconstruct what happened: which data the agent used, where it came from, and who was accountable. Without governed lineage, that reconstruction is a manual scramble during the exact window when the clock is running.

Most banking agents do not run on infrastructure the bank fully owns. They call foundation models, vector stores, and cloud services, often layered through subcontractors. DORA's fourth pillar, ICT third-party risk, was written for exactly this, and 2025 made it concrete. On 18 November 2025 the European Supervisory Authorities named the first Critical ICT Third-Party Providers for direct oversight, a list of 19 led by the major cloud platforms, AWS, Microsoft, and Google Cloud among them. These are precisely the platforms most enterprise AI agents depend on.

That puts a sharp edge on a requirement banks already find hard. DORA's Register of Information asks you to document your ICT dependency chain, including subcontractors, and Deloitte research found financial entities rank it as the single most challenging DORA requirement, usually because vendor metadata is inconsistent and ownership is unclear. An agent adds new dependencies, a model provider, an embedding service, a hosting region, that all have to land in that register with accurate ownership and contracts. You cannot govern a dependency you have not inventoried.

DORA is, underneath the cybersecurity language, a data and ICT governance mandate. Our companion piece on DORA data governance for financial institutions walks the full five pillars. For an agent specifically, four governed foundations turn "we deployed an agent" into "we can prove the agent is resilient."

• A governed inventory of the agent and what it touches. A data catalog that records the agent, the data sources it reads, and the third-party models it calls is the start of both ICT risk management and the Register of Information.
• End-to-end lineage for the audit trail. When an incident hits, lineage answers which data fed which decision, in minutes rather than days. It is the evidence DORA's incident reporting and resilience testing both rely on.
• Classification and access metadata. Tagging PII and sensitive fields and attaching policy is how you keep an agent from reading or acting on data it should never see, the boundary that makes autonomous action safe.
• Documented ownership and accountability. Every definition, dataset, and agent needs a named owner. DORA holds the financial entity accountable even when the ICT runs on a third party, so accountability cannot live only in the vendor's console.

DORA is not the only regulation reaching for a banking agent. The EU AI Act governs the same agent as an AI system, and several core banking uses sit in its high-risk tier with obligations for data governance, record-keeping, and human oversight, credit scoring among them. Fraud detection is the notable carve-out: Annex III classifies creditworthiness and credit-scoring systems as high-risk but explicitly excludes AI used to detect financial fraud. DORA asks whether the agent is operationally resilient. The AI Act asks whether it is governed, fair, and accountable. A bank running agents has to answer both.

The evidence overlaps. Lineage, classification, an inventory of systems, and documented ownership are what both regimes want to see. Build that foundation once and it serves DORA's resilience case and the AI Act's governance case together, rather than standing up two parallel compliance projects. We lay out the AI Act side in our guide to getting AI Act-ready.

Dawiso builds the governed data foundation a banking agent needs to be resilient and provable. It connects to more than 40 platforms and assembles one view across them: a Data Catalog of what exists and what the agent touches, a Business Glossary so "exposure" or "high-risk customer" means one agreed thing, classification of what is sensitive, and Interactive Data Lineage that turns an incident question into a traceable answer.

Through its MCP Server, Dawiso serves that governed context to any MCP-compatible agent, so the agent reads definitions, classifications, and lineage from a layer the bank owns rather than inferring them. The result is the thing 2026 supervisors are asking for: not a policy document, but evidence. You can show what an agent is allowed to touch, what it read, and who is accountable. Our AI Governance solution brings these capabilities together for financial institutions putting agents into production.

DORA is not red tape for its own sake. Operational resilience is now a data problem, and AI agents only sharpen it. Govern the data the agents read, and compliance becomes a property of how you already work rather than a project you run after the fact.