PrymeIntelligence

Agent governance·Regulation

DORA management body accountability for AI agents

DORA makes a financial entity's management body answer for ICT risk, and AI agents running ICT-dependent processes sit squarely inside that accountability.

DORA puts ultimate responsibility for ICT risk on a financial entity's management body. AI agents are ICT systems, usually built on third-party models, and increasingly support critical functions. The board must answer for them: whether they sit inside the ICT risk framework, what depends on them, which third parties they use, how incidents are handled and whether directors understand them.

What does DORA require of the management body?

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) applies from 17 January 2025. It covers ICT risk management, ICT incident reporting, digital operational resilience testing and ICT third-party risk. Our explainer on what DORA is gives the overview.

DORA is unusually direct about the board. In substance, the management body must:

  • define, approve, oversee and be responsible for the ICT risk management framework, and bear ultimate responsibility for managing ICT risk;
  • set clear roles and responsibilities for ICT-related functions;
  • approve the digital operational resilience strategy and the appropriate risk tolerance for ICT risk;
  • approve and periodically review ICT business continuity arrangements and response and recovery plans;
  • approve and review internal ICT audit plans and material changes to them;
  • allocate an appropriate budget for operational resilience, including training;
  • approve and review the policy on using ICT third-party services, and be informed of key arrangements;
  • keep its own knowledge and skills current enough to understand and assess ICT risk.

This is personal accountability at board level. Directors cannot delegate it away to an IT committee.

Who does it apply to?

A wide range of EU financial entities: credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, insurers and reinsurers, fund managers, trading venues and others, with lighter regimes for some smaller firms. Critical ICT third-party providers designated under DORA also come under direct EU oversight.

What must the board answer for when agents run processes?

Agents change the board's exposure in five concrete ways. Each is a question directors should be able to answer.

Are agents inside the ICT risk framework? An agent is an ICT system that reads data, calls other systems and takes actions. If the framework lists servers and applications but not agents, the board has approved a framework with a gap.

Which critical or important functions rely on agents? An agent that handles payment exceptions, customer authentication support or claims intake may support a critical or important function. That raises the bar for continuity planning, testing and third-party contracts.

Which third parties do agents depend on? Most agents run on a model from a model provider, often through an agent platform. Both are ICT third-party service providers. They belong in the register of information, with contracts that meet DORA's requirements and an exit strategy where the function is critical or important.

What happens when an agent fails? An agent that takes wrong actions at scale, or stops working, may cause an ICT-related incident. The board should know how agent incidents are classified, and that major ones must be reported.

Do directors understand agents well enough? DORA expects the management body to keep sufficient knowledge to understand ICT risk. For agents, that means understanding what they may do, how their authority is bounded and how they fail.

The governance point beneath all of this is that accountability needs a bound, not just a policy. Our guide argues agent governance is a bound, not a model: a board can only answer for agents whose authority is defined and enforced.

How does a board meet these duties for agents?

Requirement Control Evidence it leaves
Framework covers agents ICT risk framework explicitly includes agents, their tools and connections Approved framework with agent section
Roles assigned Each agent has a named owner within the ICT and business functions Ownership register
Risk tolerance set Board approves limits on what agents may do in critical functions Board-approved tolerance statement
Continuity planned Business continuity plans cover agent failure and fallback to people Plans and test results
Third-party risk managed Model providers and agent platforms in the register, with compliant contracts and exit plans Register entries and contracts
Incidents classified and reported Agent failures classified under the incident framework Incident records and reports
Resilience tested Agents included in resilience testing Test reports
Board knowledge current Directors trained on agents and their risks Training records

What will a supervisor ask the board?

  • Which of your critical or important functions depend on AI agents?
  • Who owns each agent, and what is it permitted to do?
  • Which model providers and platforms do your agents rely on, and what is your exit plan?
  • Show us how an agent failure would be classified and reported.
  • How have directors been trained to understand agent risk?
  • What risk tolerance has the board set for agents acting in critical functions?

What does DORA not cover for agents?

DORA governs digital operational resilience. It does not judge whether an agent's decisions are fair or accurate, which falls under conduct rules, the EU AI Act and data protection law. It does not set model risk standards. It does not assign individual accountability the way some national regimes do, such as the UK's Senior Managers and Certification Regime. Other frameworks frame accountability differently; compare NIST AI RMF accountability roles and MAS FEAT accountability for agent owners. For the concept itself, see what AI accountability is.

This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.

Where Pryme fits

Pryme gives a board a defined bound to answer for: every agent action meets five bounds at once, and the verdict names which one decided. The record of verdicts supports incident classification and testing evidence. Because Pryme does not update model weights for a customer, a change in an agent's behaviour traces to a recorded change in its brief, sources or bounds.

Questions people ask

Is an AI agent an ICT system under DORA?

Yes, in substance. It runs on software and infrastructure, processes data and connects to other systems, so it falls within ICT risk management.

Is a model provider an ICT third-party service provider?

Where a financial entity uses its services through an agent, it provides ICT services and should be treated as such, including in the register of information.

Does the board need to approve every agent?

Not individually. The board approves the framework, risk tolerance and policies; agents are approved within them. But agents supporting critical or important functions deserve board visibility.

Decide what your agents may do. Prove it. Enforce it.

Pryme Intelligence certifies each agent on your own cases, checks every action against five bounds at the moment it happens, and files every verdict.