The AI Act is a risk-based product-safety law for AI. It does not regulate AI by sector, it regulates AI systems by the risk they pose, and layers obligations accordingly. For a financial entity the point is narrow and precise: know which of your AI systems fall into the high-risk tier, know whether you are a provider or a deployer of them, and treat the resulting obligations as controls.
The regime is Regulation (EU) 2024/1689, the world's first horizontal AI law, in force since 1 August 2024 and applying in phases. Almost everything a bank runs is minimal-risk and carries no obligations, so the exposure sits in a small number of use cases. This is a plain-language explainer; the binding text is on EUR-Lex.
The four risk tiers
The Act sorts every AI system into one of four tiers, and the tier decides the weight of obligation. Reading a system into the right tier is the first control, because everything downstream depends on it.
| Tier | What it means |
|---|---|
| Unacceptable, prohibited | Banned outright under Article 5: subliminal or manipulative techniques causing harm, exploiting vulnerabilities, social scoring, certain biometric categorisation and untargeted facial-image scraping, emotion recognition in work and education, and real-time remote biometric identification in public, with narrow law-enforcement exceptions |
| High-risk | Permitted but heavily regulated under Article 6 and Annex III. This is where a financial entity's exposure sits. Full obligations on providers, lighter ones on deployers |
| Limited, transparency risk | Disclosure only under Article 50: tell people they are interacting with AI, for example a chatbot, and label synthetic or manipulated content such as deepfakes |
| Minimal risk | No obligations. The vast majority of AI systems, including most internal tooling |
Timelines and penalties
The Act came into force on 1 August 2024 and applies in stages, so the compliance clock differs by obligation. The main body, including Annex III high-risk, applies from 2 August 2026.
| Stage | Applies from |
|---|---|
| In force | 1 August 2024, twenty days after publication |
| Prohibited practices (Art 5) and general provisions | 2 February 2025 |
| GPAI rules, governance, penalties | 2 August 2025 |
| Main application, including Annex III high-risk | 2 August 2026 |
| High-risk tied to regulated products (Art 6(1)) | 2 August 2027 |
Penalties under Article 99 are set as the higher of a fixed amount or a percentage of worldwide annual turnover.
| Breach | Maximum, whichever is higher |
|---|---|
| Prohibited practices | EUR 35,000,000 or 7% of total worldwide annual turnover |
| Most other obligations | EUR 15,000,000 or 3% of turnover |
| Incorrect information to authorities | EUR 7,500,000 or 1% of turnover |
Where it lands on a financial entity
Annex III, point 5, holds the two entries that touch finance directly. The classic exposure is a credit-scoring or an insurance-pricing model, and almost everything else a bank runs sits below the high-risk line.
| Use case | Status |
|---|---|
| Creditworthiness and credit scoring of natural persons | High-risk (Annex III, point 5) |
| Risk assessment and pricing for natural persons in life and health insurance | High-risk (Annex III, point 5) |
| AML transaction monitoring and financial fraud detection | Not high-risk, expressly carved out |
| Most other internal AI tooling | Minimal risk, no obligations |
AI used to detect financial fraud is expressly not high-risk. The exposure is a credit-scoring or insurance-pricing model, while AML transaction monitoring and fraud detection generally sit outside the high-risk tier. Reading your fraud tooling into the high-risk bracket is the common misclassification, and it pulls a heavy obligation set onto a system the Act deliberately left out.
Provider vs deployer, the distinction that decides what you owe
The obligations depend on your role, not just the system. A financial entity is usually a deployer of a bought-in model, with lighter duties. It becomes a provider, carrying the full weight, if it builds the system, substantially modifies it, or puts it on the market under its own name.
| Role | Core obligations |
|---|---|
| Provider (builds or substantially modifies) | Risk-management system, data governance and quality, technical documentation, logging, transparency and instructions for use, human-oversight design, accuracy, robustness and cybersecurity, a conformity assessment with CE marking, and registration in the EU database |
| Deployer (uses a high-risk system) | Use it per the provider's instructions, assign competent human oversight, monitor operation and suspend on serious risk, keep logs, cooperate with authorities, run a fundamental-rights impact assessment where required, and inform natural persons subject to high-risk decisions |
General-purpose AI (GPAI)
A separate regime covers foundation models. All GPAI providers owe transparency and documentation duties. A model is GPAI with systemic risk when training compute exceeds 10^25 floating-point operations under Article 51, which adds model evaluation, systemic-risk assessment, incident reporting and cybersecurity duties.
For a financial entity this matters mainly at procurement. If you build on a third-party foundation model, know which obligations sit with the model provider and which flow to you as you deploy it, and capture that split in the contract and the risk assessment rather than assuming it lands wholly on the vendor.
Where the AI Act connects
The Act does not stand alone. For a financial entity it overlaps two frameworks you already run, which is exactly the kind of intersection a GRC function has to map.
GDPR. Credit scoring and insurance pricing are automated decisions on personal data, so GDPR already applies: lawful basis, the Article 22 rules on automated decision-making, special-category limits, and a data-protection impact assessment. The AI Act layers on top, it does not replace GDPR. In practice the two impact assessments run together.
DORA. A high-risk AI system in a financial entity is also ICT, so it falls inside DORA's ICT risk-management and third-party pillars, and the AI vendor is an ICT third party under DORA. One credit-scoring model can carry AI Act, GDPR and DORA obligations at once.
Sectoral supervision. The Act lets high-risk obligations be integrated into existing financial-sector governance and internal-control frameworks, and the financial supervisor can act as the market-surveillance authority. For a regulated entity this is added to existing governance, not bolted on separately.
The GRC angle. In practice the Act becomes a classification and controls problem, which is where an IT-risk or GRC function earns its place:
- Classify each AI system against Annex III: whether it is high-risk, and on what basis.
- Fix the provider-or-deployer determination for every high-risk system, since it decides the entire obligation set.
- Map the overlap, running the AI Act, GDPR and DORA assessments together rather than in silos.
- Treat provider instructions, human-oversight assignment, logging and monitoring as evidenced controls, with an audit trail.
- Track the phased dates, with Annex III high-risk applying from 2 August 2026 and product-linked high-risk from 2 August 2027.