DORA already applies to the AI agent you want in operations. If the agent can issue a refund, release a payout or change a customer account, it is an ICT system, and the company that supplies it is an ICT third-party service provider. Your firm stays fully responsible for that risk. Before the agent acts, you must be able to show the register entry, the contract and the rule it runs under. After it acts, you must be able to show who approved each action, in a record your auditor can check.

Why DORA is the rule that applies today

DORA, the Digital Operational Resilience Act, is Regulation (EU) 2022/2554. It has applied since 17 January 2025 (Article 64)[1]. It is a regulation, so it applies directly in every Member State. Article 2(1) lists the financial entities in scope. Payment institutions are in point (b) and electronic money institutions in point (d). In both cases this includes firms exempted under the payment services and e-money directives. Crypto-asset service providers authorised under MiCA are in point (f).

MiCA, Regulation (EU) 2023/1114, points back to DORA. Its Article 68(7) requires a crypto-asset service provider to use resilient and secure ICT systems as DORA requires. The MiCA transitional period for firms operating under national law ended on 1 July 2026 at the latest, and several Member States chose a shorter one (Article 143(3))[2]. If you hold a MiCA authorisation, you are a DORA financial entity.

Smaller firms get lighter treatment in some areas, not an exemption. Article 16 sets a simplified ICT risk management framework for a closed list of entities, including payment and e-money institutions that are exempted under their directives. The detail is in Delegated Regulation (EU) 2024/1774[3]. Microenterprises, with fewer than 10 staff and no more than EUR 2 million in turnover or balance sheet, are relieved of some further duties. A licensed firm of 20 to 200 people is usually neither. Check which provisions apply to your licence.

The EU AI Act runs on a later clock. After the 2026 AI Omnibus, Regulation (EU) 2026/1744, its high-risk rules for Annex III uses apply from 2 December 2027[4]. Whether an operations agent is high-risk under that Act depends on its intended purpose. See what changed in the EU AI Act in 2026. DORA does not wait for that classification. It applies to the agent now, because the agent is an ICT system.

An AI agent is an ICT system, and its supplier is an ICT third party

DORA defines ICT services broadly: "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis" (Article 3(21)). An ICT third-party service provider is "an undertaking providing ICT services" (Article 3(19)). The Commission has said, in its Q&A 2999, that this definition is meant to be broad. Each financial entity must assess whether the services it relies on fall within it[5].

An agent that executes refunds, payouts or case actions is delivered through ICT systems, on an ongoing basis. The vendor that supplies it fits the definition. So may the model provider and the hosting underneath, either as direct providers or as subcontractors, depending on who holds the contract.

The responsibility does not move with the software. Under Article 28(1)(a), a financial entity that uses ICT services from a third party remains fully responsible at all times for its obligations under DORA and financial services law. Article 5(2) gives the management body the ultimate responsibility for ICT risk. It must also approve and periodically review the policy on using ICT third-party services (Article 5(2)(h)).

Some suppliers argue that licensed software running in your own environment is not an ICT service. That assessment is yours, and supervisory practice on the edge cases varies. The responsibility question has one answer either way. The agent acts on your systems and your customers' money, so the ICT risk is yours.

What the register of information needs from you

Article 28(3) requires a register of information on all contractual arrangements for ICT services from third parties. You keep it at entity level and, in a group, at sub-consolidated and consolidated level. It must separate arrangements that support critical or important functions from those that do not. You make the full register available to your competent authority on request. You also inform the authority in a timely manner about planned arrangements for critical or important functions.

The format is set by Commission Implementing Regulation (EU) 2024/2956[6]. The first EU-wide collection ran in 2025, and national authorities passed the registers to the ESAs by 30 April 2025[7][9]. Reporting is now annual. Your national authority sets its own submission date.

For an agent vendor, these entries matter most:

  • The provider: legal entity, identifier (LEI or EUID) and parent company.
  • The service: what the agent does, the type of ICT service, and the contract that covers it.
  • The function: which business function it supports, and whether that function is critical or important.
  • Data location: the countries where data is stored and where it is processed.
  • Subcontractors: each provider in the supply chain, ranked by position, such as a model provider or a hosting provider.
  • Your assessment: how easily the provider can be replaced, whether an exit plan exists, and the impact of stopping the service.

You decide what is critical or important, not the vendor. Article 3(22) defines a critical or important function as one whose disruption would materially impair the firm's financial performance or the soundness or continuity of its services. In practice the compliance or risk function proposes the classification and management approves it. An agent that executes payouts will often support such a function. One that drafts internal summaries usually will not.

Prepare before you sign. Article 28(4) asks you, before contracting, to assess whether the service supports a critical or important function and to identify the risks. That includes concentration risk under Article 29: a provider that is hard to replace, or several critical arrangements with the same provider. You must also do due diligence on the provider and check for conflicts of interest. Ask the vendor for an answer to each register entry above. If it cannot say where data sits or which subcontractors it uses, you cannot complete the entry.

The contract terms DORA expects

Article 30 sets the minimum contents. Every ICT services contract needs, in writing:

  • A clear and complete description of the services, including whether subcontracting is allowed.
  • Where the service is provided and where data is processed and stored, with advance notice of any change.
  • Provisions on the availability, authenticity, integrity and confidentiality of data.
  • Access to your data, and its recovery and return, if the provider fails or the contract ends.
  • Service level descriptions.
  • Help when an ICT incident relates to the service, at no extra cost or at a cost agreed in advance.
  • Full cooperation with your competent authority.
  • Termination rights and minimum notice periods.

For services that support critical or important functions, Article 30(3) adds more. The contract needs precise service levels and notice of developments that could affect the service. It needs tested contingency plans and participation in threat-led penetration testing where that applies to you. It needs unrestricted rights of access, inspection and audit for you, for a third party you appoint, and for your competent authority. It needs an exit strategy with a mandatory transition period. Subcontracting of these services is further specified in Delegated Regulation (EU) 2025/532[8].

A small vendor may not hold certifications. It can still answer in writing. Ask for a contract annex mapped to Article 30, clause by clause. Ask for its subcontractors and data locations, its incident notification path and times, how you and your supervisor can audit it, and what happens to your data and records when you leave.

Five questions the auditor will ask about an agent's action

The register and the contract cover the supplier. An auditor will also pick single actions and ask about each one.

  1. Who approved it? A named person or a named rule, not "the agent".
  2. Under which rule, and which version? Rules change. The record must show the one in force at the time.
  3. What limits applied? The amount, the scope and the spend limit at the moment of the action.
  4. Could it have exceeded its mandate? Show that actions outside the rule were blocked, not only logged.
  5. Can the record be verified without the vendor? If only the vendor's dashboard can confirm it, your evidence depends on the supplier you are meant to oversee.

DORA does not prescribe a record format for agents. These questions follow from its ICT risk management and third-party duties. What a record must contain to answer them is set out in AI agent audit trails: what proof actually requires.

Map it to before, during and after

DORA theme What you must be able to show Where it comes from What remains yours
Management body responsibility (Article 5) A named owner and an approved rule for what the agent may do. Checked before it runs. FeirOS checks each action against your rules. Anything not allowed is denied. Writing and approving the rule, the third-party policy and the risk appetite.
ICT risk management framework (Chapter II) The agent cannot reach keys or systems beyond its mandate, and it can be stopped. Credentials the agent never holds. FeirOS holds them. A spend limit applies, with a small overshoot stated up front. One switch stops the agent. Closing every path around FeirOS, and the rest of your ICT framework.
ICT-related incidents (Chapter III) What the agent did, when, and who approved it. Signed record after. Every action routed through FeirOS is recorded with who approved it. Classifying incidents and reporting major ones to your authority.
ICT third-party risk (Articles 28 to 30) The vendor cannot act on its own, and you can audit it without its help. FeirOS runs in your environment. FeirAI has no standing access. Records verify offline with the open-source Averin verifier. The register entry, the contract, the concentration assessment and the exit strategy.
Resilience testing (Chapter IV) The agent path holds up under your testing programme. Not provided by FeirOS. Your testing programme, including the agent path.

What remains yours. Incident classification and reporting, resilience testing, the exit strategy, the register itself and the compliance function stay with your firm. FeirOS can only check and record actions routed through it. A direct database write or an unmanaged API key stays outside its record.

What to prepare before the first agent goes live

  1. A named owner. One person who approves the rule and answers for the agent's actions.
  2. The rule, in whatever form it exists. A procedure, a limit table or an approval matrix. It must be written down before it can be enforced.
  3. The one system it touches. Start with one system and a short list of actions there.
  4. The register entry for the vendor. Provider, service, function, data locations, subcontractors and your critical or important decision.
  5. Where records live and who can verify them. Retention, storage, and a way for your auditor to check them without the vendor.
  6. The exit path. How you stop the agent, end the contract and keep your records.

Where FeirOS fits: FeirAI deploys agents on FeirOS, which runs in your environment, checks each action against your rules before it runs, and keeps credentials away from the agent. Every action gets a signed record of who approved it, which your auditor can verify without FeirAI. FeirOS does not make anyone compliant on its own. See AI agents for crypto operations, AI agents for payment operations, or start with a free readiness check.

Sources

  1. Regulation (EU) 2022/2554 (DORA), Articles 2(1), 3(19), 3(21), 3(22), 5(2), 16, 28(1), 28(3), 28(4), 29, 30 and 64; Chapters II to V.
  2. Regulation (EU) 2023/1114 (MiCA), Articles 68(7) and 143(3).
  3. Commission Delegated Regulation (EU) 2024/1774 on ICT risk management tools and the simplified ICT risk management framework.
  4. Regulation (EU) 2026/1744 (AI Omnibus) amending Regulation (EU) 2024/1689.
  5. European Commission answer to DORA Q&A 2999 on the definition of ICT services.
  6. Commission Implementing Regulation (EU) 2024/2956 on standard templates for the register of information.
  7. EBA, DORA register of information reporting FAQ, 19 March 2025.
  8. Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services supporting critical or important functions.
  9. ESAs, Timeline to collect information for the designation of critical ICT third-party service providers (registers of information due to the ESAs by 30 April 2025), 15 November 2024.

This article provides general information, not legal advice. Check the official texts for your licence and entity type. Your obligations depend on your facts, and supervisory practice varies between Member States.