Banking and Insurance: Preparing IT for High-Risk AI

Artificial Intelligence · 4 min

The AI Act classifies certain credit and insurance systems as high-risk AI. Learn how to prepare IT for data, logging and human oversight requirements.

Banking and Insurance: Preparing IT for High-Risk AI

TL;DR

The AI Act classifies as high-risk certain systems used to assess the creditworthiness of natural persons and to assess risk and price life and health insurance.
Following the AI Omnibus amendments, the specific rules for these systems apply from 2 December 2027, without prejudice to other obligations that already apply.
Classification must consider the purpose of each system, the exceptions provided for, and whether the system performs profiling of natural persons.
Responsibilities differ between providers and the entities that use the systems; contracts should reflect this distinction.
Logging, data governance, human oversight and fundamental rights impact assessments require technical and organisational preparation.

The timeline has changed, but the scope is defined

In banking and insurance, artificial intelligence already supports decisions that directly affect natural persons, from granting credit to assessing insurance risk. Regulation (EU) 2024/1689, known as the AI Act, classifies certain uses as high-risk AI systems, namely the assessment of creditworthiness or credit scoring of natural persons and the risk assessment and pricing of life and health insurance. With the amendments introduced by the AI Omnibus, in force since 27 July 2026, the specific requirements for the high-risk systems listed in Annex III apply from 2 December 2027. This postponement does not change the need to prepare, nor does it set aside other provisions of the regulation that already apply. For IT teams, the challenge is to identify the systems in scope and ensure that the architecture, data, logs and oversight mechanisms make it possible to meet the relevant obligations.

Defining the scope avoids unnecessary work

The first step is to inventory AI systems and classify them according to the purpose for which they were designed and are used. Annex III, point 5, of the AI Act covers certain credit assessment systems for natural persons, but under that provision it does not include credit assessment of companies. It also excludes systems intended to detect financial fraud. In insurance, the classification set out in point 5(c) refers specifically to risk assessment and pricing for life and health insurance; other lines, such as motor or multi-risk, are not covered by that point merely because they use AI. There are, however, other provisions to consider, as well as limited exceptions in Article 6(3) for certain tasks that do not materially influence the decision. Where the system performs profiling of natural persons, that exception does not apply. Each classification must be justified and documented.

Each entity's role determines its obligations

The AI Act distinguishes between providers, who are responsible for developing or making available AI systems under their own name or brand, and deployers, who use those systems under their own authority. A bank that develops a credit scoring system in-house for its own use may assume provider obligations. An insurer that acquires a solution from a third party will, as a rule, act as a deployer, without prejudice to other responsibilities that may arise. Providers are responsible for requirements such as risk management, data governance, technical documentation, conformity assessment and logging mechanisms. Entities that use the systems must ensure use in accordance with the instructions, appropriate human oversight, monitoring, and retention of the logs under their control, as applicable. For procurement and IT teams, this calls for clear contracts covering documentation, access to evidence, updates, incidents and the responsibilities of each party.

Logging, data and human oversight are architecture requirements

High-risk AI systems must have automatic event logging capabilities that make it possible to trace their operation and support the identification of risks. Article 12 sets out this principle, while Article 26 provides for obligations to retain the logs under the control of the entity using the system, with specific rules for financial institutions and without prejudice to applicable data protection law. In practice, it is important to define which events are logged, who can access them and how they are protected. Traceability can also benefit from identifying model versions, relevant changes and data sources, according to the purpose and risks of the system. Human oversight also requires technical conditions: providing understandable information about the outputs, enabling competent people to intervene, and supporting the identification of errors or unexpected results. These mechanisms must be planned into the architecture, not added only at the end of the project.

Existing sector governance is a starting point

Banks and insurers already have risk management, internal control, compliance and audit structures arising from financial regulation. The AI Act recognises this reality and allows certain obligations to be met through existing sector governance mechanisms, under the conditions set out in Articles 17 and 26. However, this alignment does not waive the other applicable requirements. For credit assessment systems for natural persons and for risk assessment and pricing systems for life and health insurance classified as high-risk, Article 27 also requires a fundamental rights impact assessment before first use, as provided for. This assessment must consider the people affected, the risks, human oversight and mitigation measures, and may draw on elements of data protection impact assessments already carried out. The IT team should work with the risk, compliance and data protection functions, providing evidence on how the systems work and the controls in place.

Prepare methodically, without assuming certainties

The 2 December 2027 deadline should be used to organise preparation in phases. Work can begin with the inventory and classification of systems, followed by the identification of contractual roles, the assessment of logging and human oversight capabilities, and the integration of the requirements into existing governance structures. It is also important to review supplier contracts, access policies, data protection, and monitoring and incident response procedures. Systems already placed on the market or put into service before the date of application should be assessed in light of the transitional rules in Article 111, avoiding the assumption that all of them automatically fall under the same regime. European Commission guidance will continue to support the interpretation and application of the regulation. For IT teams, the goal should be to reach the deadline with defined responsibilities, organised documentation and verifiable controls, without relying on last-minute fixes.