EU AI Act and DORA for AI agents: two regimes, one evidence pack
A bank or an insurer that puts an AI agent in front of customers, or behind a claims, KYC or underwriting process, answers to two regulations that describe the same object in two vocabularies. DORA, Regulation (EU) 2022/2554, has applied to financial entities since 17 January 2025 and treats the agent as ICT. The EU AI Act, Regulation (EU) 2024/1689, treats it as an AI system: Article 50 transparency duties apply now, and the high-risk chapter reaches Annex III systems on 2 December 2027. The AI Act DORA overlap is real: both regimes want events logged, incidents classified and reported, and the third parties behind the agent under contract. This article sets out what each regime asks of an agent, where the two meet, and what one dossier that answers both looks like. It is written for the head of AI governance, the CISO and the risk officer.
What DORA already requires of an AI agent
DORA does not mention artificial intelligence. It does not need to. Four of its definitions catch an agent on the day it is switched on.
(7) ‘ICT asset’ means a software or hardware asset in the network and information systems used by the financial entity; (8) ‘ICT-related incident’ means a single event or a series of linked events unplanned by the financial entity that compromises the security of the network and information systems, and have an adverse impact on the availability, authenticity, integrity or confidentiality of data, or on the services provided by the financial entity; ... (19) ‘ICT third-party service provider’ means an undertaking providing ICT services; ... (22) ‘critical or important function’ means a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law (Article 3, points (7), (8), (19) and (22))
Read them against a live agent. The agent is software running in your network and information systems, so it is an ICT asset. The model vendor, the hosting platform and the observability tool each provide ICT services, so each is an ICT third-party service provider. An outage, a leaked record or an action the agent should not have taken is an ICT-related incident. If the agent supports claims handling, customer onboarding, underwriting or payments, your entity will usually have classified that process as a critical or important function. That classification is yours to make and to document, not the vendor's.
Once those labels attach, the rest of DORA follows. Article 8 asks you to identify, classify and document every ICT-supported function and the ICT assets behind it, to map their interdependencies, and to identify every process that depends on an ICT third-party service provider. Article 9(4)(e) asks for documented change management, so that every change to an ICT system is recorded, tested, assessed, approved, implemented and verified. A new model version, a new tool the agent can call, or a rewritten system prompt is a change to an ICT system. Articles 11 and 12 ask for continuity and recovery plans, with recovery time and recovery point objectives set per function according to its criticality. Article 24(6) asks for appropriate tests, at least yearly, on all ICT systems and applications supporting critical or important functions. Article 28 asks for a register of information covering every ICT third-party arrangement, and Article 30 lists the clauses those contracts must carry.
None of this waits for the AI Act. A supervisor reviewing your ICT risk management framework today can ask where the agent sits in it.
What the AI Act adds
The AI Act classifies by intended purpose, not by the criticality of the function. A customer-facing assistant is typically not high-risk, but Article 50(1) requires that the people talking to it are told they are interacting with an AI system, and that duty has applied since 2 August 2026. An agent that supports creditworthiness assessment of natural persons, or risk assessment and pricing in life and health insurance, falls under Annex III. For those systems, Chapter III Sections 1 to 3 apply from 2 December 2027 under Article 113, point (c)(i).
The high-risk chapter adds duties that DORA has no equivalent for. Article 9 asks for a risk management system aimed at health, safety and fundamental rights, not at the security of the network. Articles 10 and 11 ask for data governance and for technical documentation containing the elements of Annex IV. Article 15 asks for accuracy, robustness and cybersecurity, and names the attacks the system must resist: data poisoning, model poisoning, adversarial examples, model evasion. Articles 72 and 73 ask for post-market monitoring and serious incident reporting.
Two of these articles matter most for an agent already governed under DORA. The first is record-keeping.
High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. (Article 12(1))
Article 12(2) says what those logs are for: identifying situations where the system may present a risk, facilitating post-market monitoring, and supporting the deployer's monitoring duty under Article 26(5). The second is human oversight. Article 14(4) lists what the persons assigned to oversight must be able to do, including to understand the system's limitations, to detect anomalies, to disregard or reverse its output, and:
to intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state. (Article 14(4)(e))
The AI Act expects financial institutions to reuse existing frameworks. Article 9(10) allows a provider subject to risk management requirements under other Union law to fold the Article 9 process into those procedures. Article 72(4) extends the same choice to post-market monitoring for Annex III point 5 systems placed on the market by financial institutions already subject to Union financial services law on internal governance. For an agent in a bank, that framework is DORA.
Where they overlap: logging, incidents, third parties
The overlap has three parts, and each one can be designed once.
Logging. DORA wants logs for incidents and for recovery: Article 17(3)(b) asks for procedures to identify, track, log, categorise and classify ICT-related incidents, and Article 11(8) for readily accessible records of activities before and during disruption events. The AI Act wants logs for traceability and post-market monitoring under Article 12. One record per interaction serves both: the timestamp, the model version, the prompt that reached the model, the tools the agent called and with which arguments, the output, and any human intervention. If that record cannot be produced for a given exchange, neither regime is satisfied.
Incidents. DORA sets the process and the clock for the financial entity.
Financial entities shall record all ICT-related incidents and significant cyber threats. Financial entities shall establish appropriate procedures and processes to ensure a consistent and integrated monitoring, handling and follow-up of ICT-related incidents, to ensure that root causes are identified, documented and addressed in order to prevent the occurrence of such incidents. (Article 17(2))
Article 18(1) gives the classification criteria: clients and counterparts affected, duration, geographical spread, data losses, criticality of the services affected, and economic impact. Article 19 requires major ICT-related incidents to be reported to the competent authority in an initial notification, an intermediate report and a final report, and clients to be informed when their financial interests are affected. The AI Act runs a second clock for high-risk systems. Under Article 73, the provider reports a serious incident to the market surveillance authority not later than 15 days after becoming aware of it, within two days for a widespread infringement, and within 10 days in the event of a death. One event involving an agent can therefore start two notifications, to two authorities, on two timelines. The root cause analysis should be done once, and the incident classification thresholds should name the agent so that the right path triggers.
Third parties. Under DORA, the responsibility never moves. Article 28(1)(a) keeps the financial entity fully responsible for compliance whatever it contracts out. The register is the instrument that makes that responsibility visible.
As part of their ICT risk management framework, financial entities shall maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. (Article 28(3))
Every provider behind the agent belongs in it, with the function it supports and its criticality. Article 28(4) requires due diligence before contracting and an assessment of concentration risk, which for an agent means asking whether the model vendor is easily substitutable. Article 28(8) requires an exit strategy for services supporting critical or important functions. Article 30(2)(b) requires the contract to name the regions or countries where data is processed and stored, Article 30(3)(d) requires the provider to take part in your threat-led penetration testing, and Article 30(3)(e) gives you and the competent authority rights of access, inspection and audit. The AI Act adds a different relationship with the same vendor: under Article 13 the provider owes the deployer instructions for use, and under Article 15(5) it owes a system that resists attempts to alter its outputs through adversarial inputs.
What a single dossier looks like
A dossier that answers both regimes is organised around the agent, not around the regulation. It opens with the agent's identity: the owner, the function it supports and its criticality, the model, the hosting, the observability tooling and the data stores. For DORA, it holds a control checklist across five families, ICT risk management, third-party risk, incident management, resilience testing, and continuity and recovery, each control carrying a status, the evidence relied on and the reasoning. It holds the register of information rows for each provider behind the agent, ready to export, the incident thresholds and reporting path that apply to the agent, its place in the resilience testing programme and in the agreed threat-led penetration testing scope, and its recovery objectives. For the AI Act, it holds the results of behavioural tests written from the regulation text: the prompt sent, the tool calls the agent made, the answer, the verdict, and the reviewer's confirmation.
Two caveats belong in the dossier itself. No harmonised standard for the AI Act has been cited in the Official Journal, so no vendor can certify compliance, and the dossier is a set of indicative assessments pending human review, not a certificate. And the dossier is evidence, not legal advice: the qualification of a function as critical or important, and the decision to notify an incident, stay with your entity and its counsel.
Vidimus builds that dossier for one agent at a time. It turns each applicable article into tests, runs them against the live agent, records the tool calls the agent makes, grades every answer with a separate grading model, and has a human reviewer confirm before it issues a versioned, signed evidence pack. For DORA, it evaluates fifteen controls in five families against your declaration and your evidence, adds behavioural tests drawn from the DORA text, and exports the register of information rows for the providers behind the agent. A pilot takes about two weeks for one agent. See how the DORA evaluation works on the DORA solution page.