Appropriate processes must be defined for the operation of ICT systems. Ideally, these processes take into account the specifics of AI systems, e.g. whether they involve connecting an LLM from a cloud service provider or software developed internally in the entity’s own data centre.
When defining operating processes, it is necessary to cover the entire AI system lifecycle. This includes requirements for the development, installation, operation and deinstallation of AI systems, as well as the documentation of all operating activities, such as log files from model inference processes (Article 8 of the RTS RMF).
Identification and documentation. DORA requires a policy as well as procedures for managing information and ICT assets (Article 8(4) of DORA in conjunction with Articles 4 and 5 of the RTS RMF). Information and ICT assets (including components of AI systems) must be identified, classified, documented and continuously monitored. This also applies, for example, to training data sets, model implementations, software libraries, hardware, and internally and externally developed software. Clear criteria regarding the criticality of these assets provide additional support for classification.
Documenting information and ICT assets makes it possible to clearly trace where e.g. training data comes from, where it is stored within the lifecycle, who owns it and who is responsible for it (Article 4(2)(b) of the RTS RMF).
Capacity and performance. Entities are encouraged to regularly review AI systems in terms of their resource requirements and performance in order to avoid capacity bottlenecks and safeguard their stable availability. Automated monitoring procedures must be used to ensure the efficiency and scalability of the AI infrastructure (Article 9 of the RTS RMF).
Deinstallation. Entities are encouraged to include specifications for deinstalling AI systems in their policies and procedures, to irretrievably remove AI models after deletion, and to govern the deactivation of obsolete model versions in order to prevent misuse (Article 8(2)(a)(i) of the RTS RMF).
Attacks. During operation, AI systems must be protected against common cyber threats such as adversarial attacks, model poisoning and inference attacks. Appropriate technical security measures are required to counter these threats (Article 9(3) of DORA). This is explored in greater detail in the case study on the use of AI assistants.
Role-based access rights for AI models and training data are also an effective tool. These must be regularly verified and documented (Article 21 of the RTS RMF).
Detection. Continuous monitoring of AI systems has proven useful for the early detection of anomalies (Article 10 of DORA). This makes it possible to identify deviations from expected behaviour at an early stage.
Regular, automated vulnerability scanning and assessments are part of early detection. This includes examining software libraries, frameworks and the source code of AI software developed in house or obtained from third parties. Setting clear deadlines and escalation processes for implementing patches is also helpful (Article 10 of the RTS RMF).
Furthermore, entities are encouraged to ensure comprehensive, risk-based logging of AI decisions, model versions and training data (to the extent permitted by data protection law), depending on the criticality and area of application of the relevant AI systems. For AI systems that support critical or important functions, it is advantageous to define thresholds and indicators for misconduct. It is also recommended to test them regularly for effectiveness (Article 10(1) second subparagraph in conjunction with paragraph (2) of DORA).
Response and recovery, backup. The failure of AI systems, for example due to ICT-related incidents, can have serious consequences for financial entities.
Depending on their criticality, it makes sense to include AI systems accordingly in ICT business continuity management and, in particular, in the above-mentioned plans. Recovery times and points (Article 12(6) of DORA) must also be taken into account.
To ensure their functionality in an emergency, these plans must be tested and documented regularly (at least annually) (Article 11(6)(a) of DORA and Article 25 of the RTS RMF).
Financial entities must also include ICT third-party service providers that they have obtained AI systems from in their ICT business continuity management (Article 11(4) and Article 28 of DORA).
In addition, restoration and recovery procedures and methods, as well as policies and procedures for backing up AI systems and their data (e.g. regular backups of model artefacts and data sets), should be considered (Article 12(1) to (3) and (7) of DORA). Their scope is largely determined by the criticality of the information and the confidentiality of the data. The security of network and information systems and the protection objectives of the data may not be compromised. Where AI systems provided by third-party providers (e.g. through API access) are used, this role is usually assumed by the provider. Specifics for AI systems provided by third parties can be found in the next section.
It is also advisable to maintain adequate redundant capacities for AI systems, consistent with the relevant business needs (Article 12(4) of DORA).
Lessons learned from ICT-related incidents and from challenges in activating ICT business continuity plans and ICT response and recovery plans must be systematically assessed and integrated into the refinement of systems, models and processes (Article 13(3) of DORA). This also applies to the ICT risk assessment process for AI systems.