Banks and insurers have justified concerns about artificial intelligence: where the data goes, who is accountable for the output and what the supervisor will say. At the same time they run many routine processes built on documents and text, where language models can save time. This article is for architects, CTOs and compliance teams deciding what can be done now and where a first pilot should not start. It reflects the position in October 2026 and is not legal advice. Assess any specific use with your own legal and compliance function.

What applies under the AI Act in October 2026

Regulation (EU) 2024/1689 (the AI Act) entered into force on 1 August 2024 and applies in stages. The timetable was changed by Regulation (EU) 2026/1744, the so-called Digital Omnibus on AI. The Commission proposed it on 19 November 2025, it was published in the Official Journal on 24 July 2026 and has been in force since 27 July 2026. Instead of the originally proposed postponement linked to the availability of technical standards, it set fixed dates.

  • From 2 February 2025: prohibited practices under Article 5, such as social scoring or emotion recognition in the workplace, and AI literacy under Article 4. The Omnibus softened the literacy duty: providers and deployers must take measures to reach a sufficient level of AI literacy among their staff, but the duty does not guarantee a particular level for any individual.
  • From 2 August 2025: obligations for providers of general-purpose AI (GPAI) models, i.e. those who develop and place models on the market. They do not directly apply to a bank or insurer that only uses a model.
  • From 2 August 2026: transparency under Article 50, including the duty to ensure that people know they are interacting with an AI system where this is not obvious. Systems placed on the market before that date have until 2 December 2026 to add machine-readable marking of generated content.
  • From 2 December 2027 (originally 2 August 2026): obligations for high-risk systems under Annex III, which includes the banking and insurance uses described below. For AI embedded in regulated products under Annex I the date is 2 August 2028.

The delay is not a reason to wait. A high-risk system you intend to run in 2028 is being designed and procured now, and logging, documentation or human oversight are hard and expensive to retrofit into a finished solution.

Provider or deployer

Your obligations under the AI Act depend on your role. A provider develops a system, or has it developed, and places it on the market or puts it into service under its own name. A deployer uses it in the course of its own activity. A bank that buys an off-the-shelf creditworthiness tool is usually a deployer. If it builds its own system on top of a third-party language model and runs it under its own name, it is the provider of that system, even though it did not develop the model.

Under Article 25 a deployer also becomes the provider of a high-risk system if it puts its name on it, substantially modifies it or changes the purpose of an ordinary system so that it becomes high-risk. A typical example is a general assistant, approved for working with text, that starts being used for preliminary assessment of loan applications. That is why every new use, not only every new tool, should go through approval.

Which banking and insurance uses are high-risk

Point 5 of Annex III lists two financial uses: evaluating the creditworthiness of natural persons or establishing their credit score, with an explicit exception for systems used to detect financial fraud, and risk assessment and pricing in relation to natural persons in life and health insurance. Non-life insurance, such as motor or property cover, and lending to legal entities are not in this point. Point 4 matters just as much for both sectors: recruitment and selection of candidates and decisions on work relationships, including evaluating employee performance.

Article 6(3) allows an Annex III system not to be high-risk if it performs a narrow procedural or preparatory task and does not materially influence the outcome of a decision. A system that profiles natural persons, however, is always high-risk, and a provider relying on the exception must document its assessment and register the system.

Deployer obligations for high-risk use

Human oversight under Article 14 is one of the obligations, not their sum. The provider must design the system so that a person can understand it, recognise the tendency to over-rely on its output, disregard the output or stop the system. Under Article 26 the deployer must, among other things:

  • use the system in line with the provider’s instructions and assign oversight to people with the necessary competence, training, authority and support,
  • ensure that input data under its control is relevant and sufficiently representative for the intended purpose,
  • monitor operation and risks and report serious incidents to the provider and the supervisory authority,
  • keep automatically generated logs for at least six months (financial institutions keep them as part of the documentation required by sectoral law),
  • inform workers’ representatives and affected workers before deploying the system in the workplace,
  • inform people about whom the system makes or assists decisions, and use the provider’s information when carrying out a data protection impact assessment.

For creditworthiness assessment and for pricing in life and health insurance, Article 27 adds a fundamental rights impact assessment, which can build on the DPIA, and Article 86 gives the affected person the right to an explanation of the role of AI in the decision. For financial institutions the monitoring duty is deemed fulfilled by complying with the internal governance rules of sectoral law, and under Article 74(6) the market surveillance authority is, by default, the financial supervisor.

GDPR, DORA and outsourcing rules

The AI Act does not replace the GDPR. Where a decision with legal or similarly significant effects is based solely on automated processing, Article 22 GDPR applies. In the SCHUFA judgment (C-634/21, December 2023) the Court of Justice held that calculating a score can itself be such a decision if the lender’s decision depends on it to a decisive extent. An employee who merely clicks through the output therefore does not solve the problem. In addition, Directive (EU) 2023/2225 on consumer credit agreements, due to apply from 20 November 2026, gives consumers the right to request human intervention where creditworthiness assessment involves automated processing. Systematic evaluation of people, including profiling, is a typical trigger for a data protection impact assessment (DPIA) under Article 35 GDPR, to be done before any pilot with personal data.

Regulation (EU) 2022/2554 (DORA) has applied since 17 January 2025, and a language model delivered as a cloud service is an ICT service provided by a third party. It belongs in the register of information and in the pre-contract risk assessment, and the contract must contain the elements of Article 30, including the regions where data is processed and stored with advance notice of changes, access to and return of data on termination, and cooperation with supervisors. If the service supports a critical or important function, unrestricted audit rights, continuity testing and a transition period on exit are added.

For non-ICT services, banks follow the 2019 EBA Guidelines on outsourcing arrangements. The EBA’s new guidelines on third-party risk for non-ICT services, published in September 2026, will replace them once they apply (the application date has not yet been set). For insurers, EIOPA issued an Opinion on AI governance in August 2025, which interprets existing sectoral legislation for systems that are neither prohibited nor high-risk.

The contract for an enterprise AI tool

Enterprise editions are usually much better on data handling than free ones, and large providers state in their documentation that customer inputs and outputs are not used to train models. The details behind that statement usually matter more:

  • Training: does the commitment also cover fine-tuning, quality evaluation and service improvement? Is it in the contract or only on a web page?
  • Location: where data is stored and where it is processed. For example, Microsoft’s documentation for models in Azure states that with the global deployment type prompts may be processed in any geography where the model is available, while stored data stays in the chosen geography.
  • Retention: abuse monitoring, conversation history, uploaded files and preview features may follow different rules from the model call itself. Find out what is stored, for how long, who can access it and whether it can be switched off.
  • Sub-processors and model changes: who processes the data further, and how much notice you get before a model is replaced in a way that can change the behaviour of your process.
  • Exit: export of prompts, configuration, logs and outputs in a format you can use without the supplier.

How to choose the first pilot

A good first pilot has many repetitions, a clearly verifiable correct result and a person who checks the output before it has any external effect. Outside Annex III and without decisions about clients there is plenty of room: triaging incoming mail and documents, drafting customer-support replies that an employee edits and sends, searching internal policies with a reference to the source document, and pre-filling forms from attached documents with a check before saving. Note, however, that a customer-facing chatbot is subject to the transparency rules of Article 50, and analysing employees’ emotions in a call centre would run into the ban on emotion recognition in the workplace.

Usage rules and the pilot metric

Before the pilot a short internal policy is enough: which categories of data may be entered into a tool and which may not (for example client personal data, banking secrecy, internally classified information), a list of approved tools and company accounts, who approves a new use and who is accountable for the topic. Without such a policy AI is used in the company anyway, just through private accounts and without control.

The metric is agreed before the start and measured against the current state: handling time per case, the share of outputs accepted without edits and the error rate in a random sample checked by someone outside the pilot team. The threshold below which the pilot ends and its duration, in weeks rather than months, are also fixed in advance. If errors cannot be measured because nobody can say what the correct result is, the case is not suitable for a first pilot.

When not to start

  • The first project would be decisions about clients or employees (lending, pricing in life and health insurance, recruitment), where the AI Act, Article 22 GDPR and sectoral rules meet and the benefit is hardest to prove.
  • It is unclear who owns the process and who is accountable for a wrong output.
  • The supplier cannot answer in writing where data is processed and how long it is retained.
  • The data the model needs is inconsistent, and the pilot would turn into a data-cleansing project.

Recommendation

A regulated environment does not prohibit AI, but it requires you to know in which role you use a system, which category it falls into and who is accountable for its output. Start with a supporting process where a person checks the output, a contract that answers the data questions and a metric agreed in advance. Experience from such a pilot is a sound basis for any later high-risk use.