DORA and AI Workloads: What Regulation (EU) 2022/2554 Requires

Article 2(1) lists the entities in scope, from credit institutions, payment institutions, and account information service providers through investment firms, crypto-asset service providers, insurance and reinsurance undertakings, and crowdfunding service providers, with ICT third-party service providers as the final point. Points (a) to (t) are collectively the financial entities. Article 2(3) carves out several categories, including occupational pension schemes with fifteen or fewer members and insurance intermediaries that are microenterprises or small or medium-sized enterprises.

Article 3 supplies the definitions that pull AI into scope. An ICT asset is a software or hardware asset in the network and information systems used by the financial entity (Article 3(7)). ICT services are 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)).

• Governance and organisation (Article 5) and a sound, comprehensive, and well-documented ICT risk management framework as part of the overall risk management system (Article 6).
• Identification (Article 8): identify, classify, and document all ICT-supported business functions and the information and ICT assets supporting them; identify all processes dependent on ICT third-party service providers; maintain inventories and update them periodically and on every major change.
• Protection and prevention (Article 9): continuously monitor and control the security and functioning of ICT systems, and maintain high standards of availability, authenticity, integrity, and confidentiality of data at rest, in use, and in transit.
• Detection (Article 10): mechanisms to promptly detect anomalous activities, with alert thresholds and criteria that trigger the incident response process.
• Incident management (Articles 17 to 19): a process to detect, manage, and notify ICT-related incidents; a record of all ICT-related incidents and significant cyber threats; and reporting of major incidents to the competent authority as an initial notification, an intermediate report, and a final report once the root cause analysis is complete.
• Testing (Article 24): a digital operational resilience testing programme.
• Third-party risk (Articles 28 and 30): ICT third-party risk managed as an integral component of ICT risk, a register of information covering all contractual arrangements on the use of ICT services, an annual report to the competent authority on new arrangements, and contracts whose rights and obligations are allocated in writing.

A model endpoint called from a firm's applications is an ICT service, the calling system is an ICT asset, and the provider behind the endpoint is an ICT third-party service provider. Each of the runtime obligations then attaches to that traffic:

• Article 8(4) to (6): the AI systems in use, and the processes that depend on external model providers, belong in the asset and dependency inventories, updated on every major change.
• Article 9(2): prompts and responses are data in transit; their confidentiality and integrity are the entity's to maintain wherever the data goes.
• Article 10(1) and (2): anomalous activity in AI systems, including changes to their configuration, needs a detection mechanism with defined alert thresholds.
• Article 17(2): an incident involving an AI system is an ICT-related incident and must be recorded; if major, Article 19(4) reporting follows.
• Article 28(3): the contractual arrangement with each model provider is an entry in the register of information, distinguished by whether it supports a critical or important function, and reported annually.
• Article 30(2): the contract with a model provider is expected to cover the description of services and any subcontracting, the locations where data is processed, data protection, access and return of data on termination, assistance during incidents, and cooperation with competent authorities.

Governance accountability (Article 5), the risk management framework (Article 6), resilience testing (Article 24), incident classification and authority reporting (Articles 18 and 19), and contractual provisions (Article 30) are organisational acts. Evidence drawn from AI traffic substantiates the AI/LLM workload slice of the identification, protection, detection, incident-recording, and register obligations. The rest of DORA is answered elsewhere in the entity's programme, and no runtime record makes an entity DORA compliant on its own.