Key takeaways
- DORA (Regulation (EU) 2022/2554, applicable since January 2025) governs the operational resilience of ICT systems at EU financial entities. Agents acting in production are ICT-supported functions in every sense that matters.
- The five obligations that reach agent deployments: ICT risk management, logging and event reconstruction, resilience testing, third-party risk, and incident reporting.
- The agent-specific translation is concrete: identity per agent, complete action logs, a rehearsed stop drill, contract terms for model providers, and incident evidence that reconstructs without archaeology.
- DORA and the EU AI Act are complementary layers — resilience of the estate (DORA) and governance of the system (AI Act). Governed-agent architecture satisfies both from one control set.
The regulation that reaches agents without naming them
DORA’s drafting predates the agent boom and never uses the vocabulary. Its scope is “ICT systems” and “ICT-supported functions” at financial entities, with obligations on risk management, incident response, resilience testing and third-party dependencies. An agent deployed at an EU financial entity sits inside that scope from first principles: it accesses production systems, changes records, moves payments, and creates operational risk that the entity owns. When a supervisor asks how the entity manages ICT risk, the answer now includes the agents — whether or not anyone filed them under that heading.
The five obligations, translated to agents
ICT risk management (Articles 5–16). The entity’s risk framework must identify, assess and manage the risks its ICT estate creates. An agent acting in production needs: a documented risk assessment proportionate to the harm it could cause, defined boundaries on what it can reach (scoped permissions, not model promises), and named accountability — an owner, and an approver for its deployment. The registry entry with its risk tier is this artifact.
Logging and event reconstruction. DORA expects detailed logs allowing reconstruction of events affecting ICT-supported functions. For agents, the defensible log is the replayable run record: agent identity on every action, tool invocations with arguments and results, policy decisions, human approvals, timestamps that agree across systems, and tamper-evidence. Logs an auditor can edit are not logs for this purpose.
Resilience testing (Articles 24–27). The testing expectation reaches the functions agents support. The agent translation is the kill-switch drill: trigger the stop, verify zero actions after the stop decision, produce the complete write list with rollback paths or named owners for each, prove restart requires a different person’s recorded approval. Rehearse it, time it, document the scores. Teams discover in the drill what they would otherwise discover in the incident.
Third-party risk (Articles 28–44). Model API providers, agent-platform vendors and tool services are ICT third-party dependencies. The entity needs contractual terms (data use, audit rights, change notice, exit), an understanding of concentration risk, and — increasingly relevant — an answer for where the agent’s processing and evidence physically live. Deployment inside the entity’s own cloud converts the hardest third-party questions into the entity’s own controls.
Incident reporting (Articles 17–23). Major ICT incidents are classified and reported on regulator clocks. An agent taking a wrong consequential action is such an incident, and the report requires reconstruction: what happened, when, what the impact was, what was done. Entities with replayable runs produce this from the record; entities without produce it from memory and partial logs, under deadline.
How DORA and the EU AI Act divide the territory
They regulate different layers and both apply. The AI Act governs the AI system itself — classification, oversight, documentation, conformity. DORA governs the estate the system acts in — resilience, logging, testing, third parties. A bank deploying governed agents needs both answers, and the practical insight is that one control set serves both: the registry satisfies the AI Act’s documentation and DORA’s risk assessment; the approval gates satisfy the AI Act’s human oversight and DORA’s incident-prevention posture; the evidence trail satisfies the AI Act’s logging and DORA’s event reconstruction; the tested stop satisfies the AI Act’s intervention expectation and DORA’s resilience testing. Build the governance layer once; answer both regimes with it.
What to do this quarter
For an EU entity with agents (or vendor features acting like agents) in production: inventory them into the ICT estate with owners and risk tiers; verify the logging can actually reconstruct an agent action end-to-end; run and document the stop drill once; review model-provider contracts for the DORA terms; and close the residency question — where does the agent’s processing and evidence live? Each is a bounded task, and together they convert DORA from an abstract threat into a binder of evidence. The DORA answer page carries the requirement detail, the kill-switch drill is free to run, and the EU AI Act mapping covers the companion regime.
Sources
- Regulation (EU) 2022/2554 (DORA) — EUR-Lex. Accessed October 2026.
- ESAs/EIOPA/EBA supervisory expectations under DORA, 2025–2026.
- Regulation (EU) 2024/1689 (EU AI Act) for the companion-layer comparison.
Frequently asked questions
Do AI agents fall within DORA scope?
Yes, in practice. DORA regulates ICT systems and digital operational resilience, not AI by name — but an agent that acts inside production systems is part of the ICT estate: it accesses systems, changes records, and creates operational risk. Supervisors expect the same logging, risk assessment, incident response and third-party controls for agent activity as for any automated system.
What logging does DORA require for agent activity?
Logs sufficient to reconstruct events affecting ICT-supported functions: per-agent identity, every tool invocation and system change, the policy decision behind each action, human approvals for gated steps, and consistent timestamps. Logs that cannot attribute actions to a specific agent, or that can be tampered with, do not satisfy the requirement.
How do you test agent resilience under DORA?
Run the stop drill: trigger the stop control, verify zero actions after the stop decision, produce a complete list of what the agent wrote with rollback paths or named owners, and confirm restart requires recorded approval. DORA's resilience-testing expectation, applied to agents, is exactly this drill — rehearsed, timed, and documented.
Governing Autonomous AI Agents in Production
Moring provides the runtime control layer, identity verification, human-in-the-loop approvals, and audit records needed to deploy production-grade AI agents safely.
About the author
Arya SharanProduct Marketing & GTM, Moring AIChennai
Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.
LinkedIn profile
