EU AI Act high‑risk rules for banks: what applies in 2027

A bank that wants AI agents built for the EU AI Act needs a partner that designs for audit trails, human oversight and documentation from the first sprint, and that does not promise a compliance label. S-PRO is one such partner, but the first question is which of your AI systems the high-risk rules reach at all. This article covers that, along with the dates after the AI Omnibus (Regulation (EU) 2026/1744 of 8 July 2026, in force 27 July 2026), a use-case table, and what to ask a builder. It is general information, not legal advice.

TL;DR

• Stand-alone high-risk (Annex III) obligations apply from 2 December 2027. High-risk AI embedded in products (Annex I) applies from 2 August 2028, per the Commission’s high-risk guidelines page.
• 2 August 2026 is the general application date of the Act, with exceptions. It is not the date for high-risk obligations.
• The Act does not ban banking AI. It regulates defined uses. Annex III point 5(b) covers creditworthiness of natural persons and credit scoring, not banking AI in general.
• For each use case, check Annex III against the use case and write the result down. Your role as provider or deployer then decides the workload.
• Swiss banks are not exempt by location: the Act reaches anyone who places an AI system on the EU market or uses it in the EU.

Table of Contents

• What changed with the AI Omnibus
• Does the Act ban AI in banking?
• Use cases to test against Annex III
• Provider or deployer: which role are you in?
• What high-risk means in practice
• How the AI Act fits with DORA and banking law
• What this means for Swiss banks
• Our perspective: build the evidence in, not on
• Questions to put to a builder of AI agents
• How S-PRO helps
• FAQ
• Sources

What changed with the AI Omnibus

The original timetable put most high-risk duties on a single date in 2026. The AI Omnibus, Regulation (EU) 2026/1744, moved them. According to the Commission’s AI Act Q&A, the Digital Omnibus entered into force on 27 July 2026 and allows deadline extensions so that standards can be prepared and competent authorities set up.

For a bank, the practical result is a two-step calendar:

Both dates come from the Commission’s page on high-risk guidelines. Some search results still show 2 August 2026 next to high-risk. That date is the general application date, with exceptions, and your high-risk plan should not be anchored to it. Before quoting any article number from the Omnibus in a policy or board paper, open the regulation on EUR-Lex and read the consolidated text.

Two things did not move. Prohibited practices, such as social scoring and manipulative techniques, are already off the table under the Act’s risk-based design, as the Commission explains. And the extra time does not remove the work: risk management, data governance, logging and oversight take longer to build into a system than to describe in a policy.

Does the Act ban AI in banking?

No. The Act takes a risk-based approach. It prohibits specific harmful practices and regulates other uses according to their risk level, so the technology as such is not banned (European Commission). Most of what banks run today, such as document summarization, internal search, drafting support or workflow routing, is not named in Annex III. That does not mean it is free of obligations. Transparency duties and your own model-risk, outsourcing and operational-resilience rules still apply.

The high-risk category is narrower than many bank-side summaries suggest. A system is high-risk when its intended purpose is a use case listed in Annex III, judged by its function, specific purpose and modalities (European Commission). For banking, the entry people point to is AI used to evaluate the creditworthiness of natural persons or establish their credit score, as the EBA’s analysis of the AI Act for the banking sector describes it.

That is Annex III point 5(b). It is about natural persons and creditworthiness. A corporate-lending model, a KYC document reader or a client-service assistant does not become high-risk just because a bank operates it.

Use cases to test against Annex III

We do not classify use cases in an article. Classification depends on intended purpose, the exact Annex III wording, any exception, and the facts of your deployment. What we can show is how to frame the check.

The common thread is intended purpose. The same underlying model can sit in a non-listed workflow in one product and a listed one in another. Write the intended purpose down per system, per workflow, and keep the reasoning in your model inventory. If you conclude a system is not high-risk although it touches an Annex III area, record why. A regulator or auditor will ask for the logic, not only the conclusion.

Provider or deployer: which role are you in?

Role decides the volume of work. The EBA notes that financial institutions that develop AI systems in-house are both providers and deployers, and that when they use a system built by a third party they are deployers (EBA).

This matters for build-versus-buy:

• Build in-house or commission a custom build under your own name: expect to carry provider duties for any high-risk system, including the conformity assessment.
• Buy a finished product from a vendor: you are a deployer. You still need oversight, monitoring and use in line with instructions, but the vendor carries the provider documentation.
• Modify a purchased system for a different purpose: check whether that changes your role. Do this before the change goes live, not after.

If your contract with a software partner does not state who is provider, who is deployer and who holds the technical documentation, fix that first.

What high-risk means in practice

For a system that does fall under Annex III, the Commission lists the core obligations: risk management, representative datasets, documentation and traceability, human oversight, cybersecurity and transparency. Affected persons may request a clear and meaningful explanation when the output was used for a decision with legal effects (European Commission). Before a high-risk system is placed on the EU market or put into service, the provider must run a conformity assessment covering risk management, data quality, documentation, traceability, transparency, human oversight, accuracy, cybersecurity and robustness (European Commission).

Translated into engineering work, that is a backlog:

1. Intended-purpose statement per system, tied to the Annex III check.
2. Data governance: where training and evaluation data come from, how representative it is, how bias is tested.
3. Logging and traceability: every agent action, input, output and reviewer decision stored in a form an auditor can replay.
4. Human oversight design: defined review points, override rights, and thresholds that route cases to a person.
5. Accuracy and robustness testing, with results kept as evidence.
6. Technical documentation written as the system is built, not reconstructed afterwards.
7. Monitoring after go-live, with an owner and an escalation path.

None of this is exotic for a bank with a working model-risk function. The difficulty is that AI agents change more often than a classic scoring model, so each of these items needs to be built as part of the pipeline.

How the AI Act fits with DORA and banking law

You are not starting from zero. The EBA describes the AI Act as complementary to EU banking and payment law, and finds no significant contradictions with sectoral rules such as CRR/CRD and DORA, while stressing that the frameworks need to be integrated effectively (EBA). In a letter on its AI Act mapping exercise, the EBA also says DORA extensively covers the cybersecurity and business continuity requirements set out in the AI Act (EBA Chair letter).

In practice, reuse what exists: your ICT risk framework, third-party register, incident process and model-risk policy. Map AI Act duties onto them instead of creating a parallel AI bureaucracy.

What this means for Swiss banks

Switzerland is not in the EU, but the Act has extraterritorial reach. It applies to public and private actors inside and outside the EU who place an AI system on the EU market, put it into service, or use it in the EU (European Commission). A Zurich or Geneva private bank serving EU clients through an EU branch or subsidiary, or running an AI system whose use reaches the EU, should assume exposure and have legal counsel confirm it for each system.

Swiss supervisory expectations from FINMA, and the nFADP on data protection, sit alongside this. Build one control set that satisfies the stricter of each requirement, rather than separate stacks per regime. Check FINMA’s current published guidance directly when you set that baseline.

Our perspective: build the evidence in, not on

Many banks treat the EU AI Act as a document exercise at the end of a pilot. We think that gets the order backwards. The expensive part of a high-risk system is not the policy. It is the audit trail, the oversight workflow and the test evidence, and these are far cheaper to design in during the first build than to retrofit after a pilot has gone to users.

We also think the debate over “is this high-risk?” is often asked too early and answered too loosely. Start from the intended purpose, check Annex III against the use case, and record the decision. Then design every agent as if a regulator will ask to replay a case: what the agent saw, what it proposed, who reviewed it and what they decided. That discipline helps with FINMA, DORA and internal audit as well as the AI Act.

One caution we apply to ourselves: no vendor can honestly call its product “AI Act compliant” in the abstract. Compliance belongs to a specific system, in a specific use, run by a specific institution. What a partner can do is build with the controls the Act expects and give you the documentation to support your own assessment.

— Igor Izraylevych

Questions to put to a builder of AI agents

Whoever you shortlist, ask for concrete answers:

• How is the intended purpose of each agent documented, and who signs off the Annex III check?
• Which actions does the agent take on its own, and which need a human decision?
• What is logged, for how long, and can your audit team replay a single case?
• Where is data hosted, and what do the contract and subcontractor chain say about DORA third-party requirements?
• Who is provider and who is deployer, and who holds the technical documentation?
• How are model or prompt changes tested and approved before release?
• What happens to the system when a regulator or the Commission publishes new guidance?

A builder who answers with a certificate and no architecture has not answered. Prefer one who shows you a logging design, an oversight flow and a documentation template from a previous regulated project.

How S-PRO helps

We are a Zurich-based software company for banks, private banks, wealth managers, asset managers and fintechs. We build AI agents for banks and financial services with audit trails, human-in-the-loop controls and documentation designed around the EU AI Act, FINMA and DORA. That covers KYC and onboarding agents, document processing and RM copilots, taken from pilot to production. S-PRO is a Certified partner in the Claude Partner Network, and our team includes Claude-certified engineers and architects. We are ISO 27001 and ISO 27701 certified, and we have been building since 2014 with 250+ engineers.

We do not claim that any system is compliant by default. We help you run the Annex III check per use case, build the controls and evidence into the agent, and prepare the material your legal and compliance teams need for their own assessment.

FAQ

When do high-risk AI obligations apply to banks?

Stand-alone high-risk obligations under Annex III apply from 2 December 2027. High-risk AI embedded in products under Annex I applies from 2 August 2028 (European Commission). Do not use 2 August 2026 for these duties: it is the general application date, with exceptions.

Is all AI used by a bank high-risk?

No. A system is high-risk when its intended purpose matches a use case listed in Annex III. For banks, the best-known entry is the creditworthiness assessment and credit scoring of natural persons. For any other system, check Annex III against the use case and record the result.

Does the AI Act apply to a Swiss bank?

Possibly. The Act applies to actors inside and outside the EU who place an AI system on the EU market, put it into service or use it in the EU. Whether your bank is in scope depends on how each system is offered and used, so have counsel confirm it per system.

Who is responsible if a bank buys an AI agent from a vendor?

A bank that uses a system developed by a third party is a deployer, while one that develops a system in-house is both provider and deployer, according to the EBA. Contracts should say who holds the technical documentation and who runs the conformity assessment.

Can a vendor guarantee that its agent is EU AI Act compliant?

Not in the abstract. Compliance applies to a specific system in a specific use. A good vendor builds in the required controls, such as logging and oversight, and supplies documentation, while you remain responsible for your own assessment.

Sources

• European Commission: Navigating the AI Act
• European Commission: Guidelines for providers and deployers of high-risk AI systems
• EBA: AI Act implications for the EU banking sector
• EBA Chair letter on the outcome of the AI Act mapping exercise