The AI Act and High-Risk AI in Finance: A Practical Roadmap

The AI Act is the EU’s first comprehensive horizontal regulation of artificial intelligence and applies to a range of actors across the AI value chain on the EU market, from those who develop AI systems to those who use, import or distribute them. It follows a risk-based approach where certain AI practices are outright prohibited, some AI systems are classified as high-risk and subject to detailed requirements, and the rest face lighter obligations. The AI Act is currently only partially in force, with the rules on high-risk AI systems taking effect from 2 December 2027 or 2 August 2028, depending on the specific system. This article cuts through the regulatory text and offers a hands-on guide to high-risk AI systems, including the specific obligations they trigger, and the division of responsibility between the categories of actors most relevant for FinTechs: those who develop AI systems and those who use them.

When is your AI system “High-risk”?

The AI Act takes a list-based approach in its classification of AI systems. Thus, an AI system is high-risk if its intended purpose falls within one of the use cases listed in Annex III to the Act, or if it is a safety component of a product covered by the harmonisation legislation listed in Annex I, and this applies regardless of how advanced the technology of the system is. For financial services, two examples are central: AI systems used to evaluate the creditworthiness of natural persons or establish their credit score (Annex III point 5(b)) and AI systems used for risk assessment and pricing in life and health insurance (Annex III point 5(c)). Other financial AI may also be caught, depending on its purpose, e.g. automated investment advice tools or AML/KYC systems that feed into decisions about an individual.

In practice, the rules can catch a wide range of FinTech use cases: automated lending platforms, buy-now-pay-later scoring engines, credit risk models, insurance pricing and underwriting systems, and AML or KYC screening that affects an individual’s access to financial services. If the system influences whether natural persons get credit, what they pay for insurance, or whether they can access a service, it may be in high-risk territory.

Article 6(3) provides an important exception. An AI system listed in Annex III will not be considered high-risk if it does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision-making. However, this exception never applies where the AI system performs profiling of natural persons. For most credit scoring and insurance pricing use cases, profiling is inherent, which means the exception is unlikely to be available in practice.

The compliance toolkit: what high-risk actually requires

Articles 8 to 15 of the AI Act set out the requirements for high-risk AI systems. Article 8 provides the overarching principle that compliance with these requirements must take into account the system’s intended purpose and the generally acknowledged state of the art on AI. Articles 9 to 15 then set out the specific requirements. They are detailed, but not unmanageable once you break them down. Here is what you are working with:

Risk management system (Article 9)

You need a documented, ongoing, iterative process for identifying, analysing, evaluating, and mitigating risks throughout the AI system’s lifecycle. The risk management system must be updated as the system evolves and as new risks emerge, and should be thought of as a living document, not a filing cabinet exercise.

Data and data governance (Article 10)

Training, validation, and testing data must be relevant, sufficiently representative, and as free from errors as reasonably achievable. You need processes for bias detection and mitigation. This matters across financial AI and the AI Act expects you to address these issues before deployment, not after.

Technical documentation (Article 11)

Technical documentation must be drawn up before the system is placed on the market or put into service, and kept up to date thereafter. It should be detailed enough for a competent authority to assess compliance.

Record-keeping and logging (Article 12)

High-risk AI systems must be designed to automatically log events during operation, enough to enable traceability and review after the fact. In practice, this means being able to reconstruct why a particular decision was reached, whether that decision was, for example, to deny a loan or flag a transaction.

Transparency and provision of information to deployers (Article 13)

The system must come with instructions for use that are clear enough for the deployer to understand the system’s capabilities, limitations, and intended purpose, and to interpret its outputs correctly. In plain terms, the user manual has to be genuinely useful.

Human oversight (Article 14)

The system must be designed so that it can be effectively overseen by natural persons, including the ability to override or disregard the AI’s output. In short, the system cannot be a black box that makes final calls on its own, there needs to be a real possibility for a qualified person to step in.

Accuracy, robustness, and cybersecurity (Article 15)

The system must achieve appropriate levels of accuracy, be resilient to errors and inconsistencies, and be protected against unauthorised third-party manipulation. For FinTechs already subject to e.g. DORA[1] or NIS2[2], the cybersecurity requirements should feel familiar. The trick is aligning them with what the AI Act adds rather than building parallel compliance workstreams.

Providers vs. deployers: who does what?

In addition to the requirements set out in Articles 8 to 15, the high-risk classification triggers a set of procedural and organisational obligations that are split between providers (those who develop or commission an AI system and place it on the market or put it into service under their own name) and deployers (those who use an AI system under their own authority in a professional capacity).

The provider carries the heaviest burden. This includes conducting the conformity assessment, affixing the CE marking, establishing a quality management system, maintaining technical documentation, registering the system in the EU database, and running post-market monitoring. The provider is, in effect, the party that vouches for the system’s compliance before it reaches the market.

The deployer’s obligations are lighter but far from trivial. Deployers must use the system in accordance with the provider’s instructions, ensure human oversight is actually exercised (not just theoretically possible), monitor the system for risks during operation, keep logs as required, and, where applicable, carry out a fundamental rights impact assessment before putting the system to use. Deployers must also inform individuals when a decision affecting them has been made with the assistance of a high-risk AI system. In practice, this means that if your system is involved in, for example, denying a loan application, the person affected needs to know that AI was part of the process.

Here is where it gets interesting for FinTechs: many of you are both. If you develop your own credit scoring model and deploy it in your lending operations, you wear both hats simultaneously. That means the full stack of obligations applies. Even if you start as a deployer, say, licensing an off-the-shelf model from a vendor, you can be reclassified as a provider if you substantially modify the system or put it on the market under your own name or trademark. The key takeaway is to understand your role clearly, and to reassess it if your use of the system changes.

A practical roadmap: where to start

The requirements under the AI Act are detailed, but workable if you approach them methodically. The following steps are a sensible starting point, and while they do not cover every obligation under the AI Act, they address the groundwork that needs to be in place before the more formal compliance steps come into play.

1. Inventory your AI systems and classify them. A good starting point is to map every AI system in your organisation against the AI Act’s risk categories. Focus on what your systems actually do, not what the marketing materials say.
2. Assign roles. For each high-risk system, work out whether you are a provider, deployer, or both. If you license AI from a third party but fine-tune or substantially modify it, you may have crossed into provider territory.
3. Conduct a gap analysis. For providers, this means mapping not only the technical requirements in Articles 8 to 15, but also the procedural obligations such as quality management, conformity assessment, registration, and post-market monitoring obligations. For deployers, map your operational practices against Article 26, including the potential obligation to carry out a fundamental rights impact assessment and to inform individuals subject to decisions assisted by a high-risk AI system. For both, the gap analysis should also cover baseline obligations such as transparency towards individuals who interact with certain AI systems and ensuring adequate AI literacy among staff involved in operating them.
4. Build or update your risk management and data governance frameworks. If your risk management process is not yet iterative and lifecycle-oriented, this is the time to develop it. The same goes for training data governance.
5. Establish human oversight procedures and train the people who will exercise them. For providers, this means designing the system so that effective oversight is possible. For deployers, it means ensuring oversight actually happens in practice, assigning individuals with the necessary competence and authority, and making sure they understand the system’s logic, its limitations, and when to step in.
6. Prepare your technical documentation and logging infrastructure. Documentation needs to be in place before the system goes live, and logging should be built in from the start. Adding traceability at a later stage tends to be significantly harder and more costly.
7. Integrate AI Act compliance into existing structures. Rather than building a standalone AI Act compliance programme alongside your GDPR[3], DORA, and financial regulation functions, consider integrating AI compliance into what you already have. Many of the AI Act’s requirements overlap with existing obligations on data governance, risk management, cybersecurity, documentation, and oversight. Where they do, one coherent process will likely serve you better than many parallel ones.

Conclusions

For FinTechs operating in the EU, the AI Act introduces a new paradigm of accountability. Whether you are developing AI tools or deploying them, the first step is to determine your role and understand the corresponding obligations. For providers, the focus is on robust design, data quality, and transparency from the outset. For deployers, the emphasis is on responsible implementation, human oversight, and continuous monitoring. Ultimately, the AI Act mandates a partnership between providers and deployers to ensure that innovation in finance remains trustworthy, safe, and fair.

[1] Regulation (EU) 2022/2554 on digital operational resilience for the financial sector.

[2] Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union.

[3] General Data Protection Regulation (EU) 2016/679.