What the EU AI Act means for financial services.

The EU AI Act is the first horizontal law that regulates artificial intelligence by the risk it carries rather than the sector it sits in. For a bank, a payments firm, or an insurer, the tier that matters is high-risk, and the obligations that attach to high-risk systems begin applying on 2 August 2026. That date is close enough that the work to meet it should already be scoped.

This is a practical reading of the Act for a compliance or model-risk audience, not a legal one. It covers what counts as high-risk in finance, the obligations that attach, the split between building a system and buying one, and how the requirements map to controls a mature model-risk function already runs.

Key facts

01: High-risk obligations apply from 2 August 2026. The Act entered into force on 1 August 2024 and applies in phases. Prohibited practices applied from February 2025 and general-purpose model rules from August 2025. The obligations for the high-risk systems listed in Annex III, the tier most financial use cases fall into, apply from 2 August 2026.
02: Credit scoring and insurance pricing are named high-risk. Annex III classifies AI used to evaluate the creditworthiness of natural persons, and AI used for risk assessment and pricing in life and health insurance, as high-risk. Detecting financial fraud is carved out. A system that does not make or materially inform those decisions is treated differently.
03: The obligations read like model risk management. Risk management, data governance, technical documentation, logging, human oversight, accuracy and robustness, and a quality management system. A firm running a working SR 11-7 or SS1/23 model-risk function already performs most of these. The Act formalises them and adds conformity assessment and registration.
04: The deployer has duties too, not just the provider. A bank that buys a high-risk system is a deployer, not just a user. Deployers must run the system per its instructions, keep logs, assign competent human oversight, and monitor it in use. Building the system in-house, or putting your name on it, makes you the provider, with the fuller set of obligations.

Which financial AI is high-risk

The Act sorts systems into four tiers: prohibited, high-risk, limited-risk (transparency obligations), and minimal-risk. Most of a financial firm's AI sits in the bottom two tiers and carries light obligations. The weight falls on the high-risk tier, and for finance that tier is defined by two entries in Annex III.

The first is creditworthiness. AI used to evaluate the creditworthiness of natural persons or to establish their credit score is high-risk. The Act carves out systems used to detect financial fraud, which is a meaningful exception for transaction monitoring and screening. The second is insurance. AI used for risk assessment and pricing in life and health insurance is high-risk.

Two qualifications matter. A system that appears in Annex III is not automatically high-risk if it performs a narrow procedural task, improves the result of a previously completed human activity, or otherwise does not materially influence the outcome of a decision. That exemption has to be documented, not assumed. And general-purpose AI models sit on a separate track with their own obligations, described at the end of this post.

The practical consequence is that the classification step is a use-case-by-use-case exercise, not a blanket judgment about the firm. A credit decision engine is in scope. A model that drafts an internal memo is not. The boundary runs through what the system decides or materially informs.

Provider or deployer

The Act assigns obligations by role, and the same firm can hold different roles for different systems. A provider develops a high-risk system, or has one developed, and places it on the market or puts it into service under its own name. A deployer uses a high-risk system under its authority. A bank that licenses a credit-scoring model from a vendor is a deployer. A bank that builds one is a provider.

Deployer obligations are the lighter set. Use the system in line with the provider's instructions. Assign human oversight to people who are competent and have the authority to act. Keep the logs the system generates. Monitor the system in operation and tell the provider or the authority when you see a risk or a serious incident. Where the system makes or informs decisions about people, there are duties to inform the people affected.

Provider obligations are the fuller set. A quality management system, the technical documentation, conformity assessment before the system goes to market, registration in the EU database, and post-market monitoring once it is live. The trap for a buyer is that substantially modifying a high-risk system, or placing it on the market under your own name, can turn a deployer into a provider and pull the fuller obligations across with it.

The obligations, mapped to controls you may already run

The core requirements for a high-risk system live in a block of the Act usually cited as Articles 9 to 15. Read them next to a model-risk framework and most lines have a counterpart.

A risk management system that runs across the lifecycle maps to the model risk framework. Data and data governance, covering quality, relevance, and representativeness, maps to the data-quality and bias work a validation function already does. Technical documentation maps to the model documentation or model cards a firm keeps for each model. Record-keeping and automatic logging maps to the audit trail, though the Act is specific about traceability over the system's lifetime, which is where logging granularity often falls short. Transparency and instructions for use map to the documentation a provider hands a deployer. Human oversight maps to four-eyes review and named sign-off. Accuracy, robustness, and cybersecurity map to validation, ongoing monitoring, and security testing.

On top of the per-system requirements sit a quality management system for providers, a conformity assessment before the system is placed on the market, and registration in the EU database. A firm with a mature model-risk function tends to find that the substance is already there. The gaps are usually the formal conformity assessment, the registration step, the logging detail, and the instructions-for-use documentation that the Act treats as a deliverable rather than an internal note.

What to do before August 2026

The sequence is the same one a use-case register supports.

Inventory every AI system and classify each against Annex III, recording why a system is or is not high-risk. Decide whether the firm is the provider or the deployer for each high-risk system. Gap-assess each high-risk system against the Article 9 to 15 requirements. Fix logging so it meets the traceability standard rather than the convenience standard. Assign and document human oversight for each system, naming the people and their authority. Prepare the technical documentation and the instructions for use. Track the general-purpose model obligations separately if the firm builds on a foundation model.

Guidance and harmonised standards are still settling, and some detail will move through delegated acts. That is a reason to build the controls now and leave room to adjust, not a reason to wait. A firm that sequenced governance before deployment finds most of this is bookkeeping on work it already did. A firm that bolted AI on first finds it is a build. The difference is the order the work was done in, which is the argument we have made about why governance arrives before the technology does.

FAQ

Questions readers ask

When does the EU AI Act apply to financial services?

The Act entered into force on 1 August 2024 and applies in phases. Prohibited practices applied from February 2025 and general-purpose model obligations from August 2025. The obligations for the high-risk systems in Annex III, the tier that captures most financial use cases such as credit scoring, apply from 2 August 2026.

Is credit scoring high-risk under the EU AI Act?

Yes. AI used to evaluate the creditworthiness of natural persons or to establish a credit score is classified as high-risk in Annex III. Systems used solely to detect financial fraud are carved out. AI used for risk assessment and pricing in life and health insurance is also high-risk.

What is the difference between a provider and a deployer?

A provider develops a high-risk system and places it on the market under its own name, carrying the full obligations including conformity assessment and registration. A deployer uses a high-risk system and must run it per instructions, keep logs, assign human oversight, and monitor it. Substantially modifying or rebranding a system can turn a deployer into a provider.

Does a bank with model risk management already comply?

Largely in substance. The Article 9 to 15 requirements overlap with an SR 11-7 or SS1/23 model-risk framework: risk management, data governance, documentation, logging, human oversight, and robustness. The gaps tend to be the formal conformity assessment, the EU database registration, the lifecycle logging standard, and the instructions-for-use documentation.

What about general-purpose AI models?

General-purpose AI models sit on a separate track. Their obligations, covering technical documentation, transparency, and a copyright policy, with additional evaluation duties for models judged to carry systemic risk, applied from 2 August 2025 and attach to the model provider. A financial firm using such a model is usually a downstream deployer, not the provider of the model itself.