EU AI Act: What It Requires and Who It Applies To

What is EU AI Act?

Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, is a horizontal legal framework regulating the development, deployment, and use of artificial intelligence systems across the European Union. The European Parliament and the Council of the EU adopted it on June 13, 2024; it was published in the Official Journal on July 12, 2024, and entered into force on August 1, 2024. It is the world's first comprehensive, binding law specifically governing AI. The full text is available on EUR-Lex.

The regulation uses a four-tier risk structure. AI systems classified as unacceptable risk are prohibited outright. High-risk systems face extensive compliance obligations. Limited-risk systems must meet transparency requirements. Minimal-risk systems have no specific obligations. The prohibited category includes real-time remote biometric identification in public spaces, AI systems that exploit psychological vulnerabilities, and social scoring by public authorities. High-risk AI, defined in Annex III, covers credit scoring, insurance risk pricing, and biometric identification in regulated financial contexts. That's where most of the compliance work sits.

The Commission first proposed the legislation in April 2021. The trigger was documented harm: discriminatory mortgage approval models in the Netherlands, facial recognition errors contributing to wrongful police action, and opaque automated benefits-denial systems across Europe. Three years of negotiation produced a final text running to 144 Articles and 13 Annexes.

Implementation is phased. Prohibited AI provisions applied from February 2, 2025. General-purpose AI model obligations apply from August 2, 2025. High-risk AI obligations under Annex III apply from August 2, 2026. AI systems embedded in products governed by other EU safety law get an extra year: August 2, 2027. For banks and insurers, 2026 is the operative deadline for most obligations.

Who does EU AI Act apply to?

The regulation covers the full AI supply chain operating in or toward the European Union:

• Providers: Organizations that develop an AI system, or commission its development, and place it on the EU market. A U.S. fintech selling an AI credit decisioning engine to European banks is a provider with full Article 16 obligations, regardless of where its servers are located.
• Deployers: Organizations using a third-party AI system under their own authority in a professional context. A German bank deploying a vendor's transaction monitoring model is a deployer with independent obligations under Article 26.
• Importers: EU-based entities placing AI systems from third countries on the EU market.
• Distributors: Entities making AI systems available in the EU supply chain without material modification.

The extraterritorial reach matters. If a system's outputs are used in the EU, the law applies even when the provider has no EU presence. This mirrors the GDPR's territorial logic and carries the same practical consequence: non-EU vendors must appoint an EU representative if they have no local entity.

For financial services, Annex III classifies the following as high-risk:

• AI for creditworthiness assessment or credit scoring (Annex III, point 5(b))
• AI for risk assessment and pricing in life and health insurance (Annex III, point 5(c))
• AI used in Know Your Customer (KYC) identity verification in regulated sectors
• Biometric identification systems used in financial services contexts

General-purpose AI models with training compute exceeding 10^25 FLOPs face additional systemic risk obligations under Title VIII: mandatory adversarial testing, incident reporting to the European AI Office, and model evaluation transparency requirements.

What does EU AI Act require?

For high-risk AI, the Act divides responsibility between providers and deployers. Both carry obligations. Neither can transfer legal liability to the other by contract.

Provider obligations (Article 16):

1. Establish a documented risk management system covering the full AI system lifecycle, reviewed and updated whenever the system changes or the risk context shifts (Article 9).
2. Implement data governance for training, validation, and test datasets. Data must be relevant, representative, and reasonably free from errors. For systems with demographic impacts, conduct bias analysis across relevant population subgroups before deployment.
3. Prepare technical documentation before market placement (Article 11, Annex IV). Required content includes model architecture, training methodology, accuracy metrics broken down by relevant demographic subgroups, validation results, and defined intended purposes.
4. Build automatic event logging into the system. Logs must capture inputs, outputs, and operating conditions sufficient for post-incident analysis. Minimum retention is six months from last use, unless sector-specific law requires longer.
5. Provide deployers with written instructions covering known risks, performance limits, demographic accuracy gaps, and specific human oversight requirements.
6. Design human oversight into the system so a designated person can monitor outputs and override or halt system operation in real time.
7. Test the system against reasonably foreseeable misuse scenarios. Accuracy, robustness, and cybersecurity requirements in Article 15 apply on a continuous basis.
8. Complete a conformity assessment before market placement. Most Annex III systems may self-assess. Biometric identification systems require assessment by a third-party notified body (Article 43).
9. Register the system in the EU AI database before placing it on the market (Article 49).
10. Establish a post-market monitoring plan. Report serious incidents to national authorities within 15 working days, or within 2 working days when an incident involves death or serious harm.

Deployer obligations (Article 26):

1. Use the system only within the scope described in the provider's written instructions.
2. Assign human oversight to persons who have both the competence and the practical authority to intervene on outputs.
3. Conduct a Data Protection Impact Assessment under GDPR when the high-risk AI processes personal data. The two frameworks are deliberately linked: AI Act compliance for most financial services AI requires concurrent GDPR compliance.
4. Inform individuals when they are subject to a decision materially influenced by high-risk AI, and explain the logic behind that decision on request.

Technical documentation must be retained for 10 years after the system is placed on the market.

What evidence do regulators expect?

Financial services regulators, including the European Banking Authority for banks and EIOPA for insurers, act as national market surveillance authorities under the Act. Based on the regulation's text and published guidance from the European AI Office, examiners will want the following on audit day:

• Risk management documentation: A written, updated risk management system. Reviewers want evidence of initial risk identification, residual risk assessments, and decision records showing how risks were weighed against expected benefits at each review cycle.
• Technical documentation (Annex IV): Full model cards covering intended purpose, training data description, accuracy metrics per demographic subgroup, validation methodology, and known limitations. A vague summary of training data does not satisfy this requirement.
• Event logs: Retrievable logs covering at least the previous six months, showing inputs, outputs, and operating parameters for each significant operation. Logs recording only system outputs are not sufficient under Article 12.
• Human oversight records: Named individuals in oversight roles, their training records, documented evidence of any interventions or overrides, and clear organizational authority allowing them to halt system operation.
• Instructions for use: The written instructions received from the AI provider, plus evidence that deployer staff were trained on those instructions and that use stayed within the defined scope.
• Bias testing results: Pre-deployment demographic analysis with records of corrective steps taken, plus records of ongoing monitoring after deployment.
• Conformity assessment documentation: Self-assessment records or third-party notified body certificates, plus the EU AI database registration number.
• Incident reports: Any notifications made to national authorities, with root cause analysis and remediation timelines attached.

Institutions building mature AI governance in financial services will find that regulators cross-reference AI Act documentation against existing model validation records. A functioning model governance program is a head start.

Common failure modes

Several failure patterns are predictable from the Act's specific requirements and early supervisory communications. These are the most likely citation areas in 2026 and 2027 examinations:

• Input logging gaps: Many deployed AI systems log only their outputs, not input features or operating context. Article 12 requires the full chain. A transaction monitoring model that records only "flagged / not flagged" without logging the input variables used for that decision is non-compliant.
• Nominal human oversight: Assigning a person to "oversee" an AI system but giving them no practical mechanism to halt it does not meet Article 26. The FCA flagged this exact failure mode in its DP5/22 AI Discussion Paper: oversight roles that carry no operational authority are the most common design failure in AI governance. EU supervisors are watching the same thing.
• Vendor delegation without accountability: A bank that deploys a third-party AI model and treats AI Act compliance as the vendor's problem will be cited. Deployers carry independent obligations under Article 26. A contract clause transferring liability doesn't change the legal position.
• Scope creep beyond intended purpose: A credit risk model validated for mortgage applications, then repurposed for card limit decisions without re-running conformity assessment, has left its compliant scope. Article 9 requires a new assessment before extending use.
• One-time bias testing: Running a demographic bias check once before deployment and treating it as a permanent result doesn't satisfy Article 9's continuous monitoring requirement. Bias profiles shift as input data distributions change over time.
• Incomplete data provenance: Annex IV requires full documentation of training data sources, collection methodology, and preprocessing steps. Institutions using models built on undocumented historical data will have gaps they can't easily close retroactively.

Penalties for non-compliance

Article 99 sets three penalty tiers, with fines calculated as whichever is higher: an absolute cap or a percentage of global annual turnover.

1. Prohibited AI violations: Up to €35 million or 7% of total worldwide annual turnover. Applies to banned practices including real-time biometric surveillance in public spaces, AI exploiting psychological vulnerabilities, and social scoring by public authorities.

2. High-risk AI violations: Up to €15 million or 3% of global annual turnover. Covers failures in risk management documentation, data governance, event logging, human oversight design, conformity assessment, and registration under Articles 9 to 16.

3. Incorrect information to authorities: Up to €7.5 million or 1.5% of global annual turnover.

4. General-purpose AI model violations (Article 101): Up to €15 million or 3% of global annual turnover.

A proportionality clause applies to SMEs and startups: national authorities must impose penalties that are "effective, proportionate, and dissuasive" while taking the company's financial capacity into account explicitly.

Enforcement sits with national market surveillance authorities. For regulated financial institutions, the existing sectoral regulator acts in that role: BaFin for German banks, the AMF for French institutions, De Nederlandsche Bank for Dutch entities, and so on. The European AI Office handles enforcement for general-purpose AI models and coordinates cross-border cases. There is no single EU-level financial AI enforcement body.

As of May 2026, no enforcement decisions against financial institutions had been published under the AI Act. The 2026 compliance deadline for Annex III systems means the first wave of examinations is likely to begin in late 2026 and into 2027.

Related regulations and frameworks

The EU AI Act sits within a wider regulatory architecture. For financial institutions, several frameworks apply simultaneously:

GDPR (EU) 2016/679: GDPR Article 22 already restricts fully automated decisions with significant legal effects on individuals. The AI Act builds on this: deployer obligations under Article 26 explicitly require a DPIA when high-risk AI processes personal data. For AI-driven credit decisions and Customer Due Diligence processes, the two frameworks must be read together.

DORA (EU) 2022/2554: Banks and insurers must manage ICT risk from third-party tools under the Digital Operational Resilience Act. Third-party AI systems fall under DORA's ICT risk register at the same time as the AI Act's provider/deployer framework. The documentation requirements overlap: a DORA-compliant ICT contract register should already capture much of what the AI Act's Annex IV asks for.

EU AMLR 2024: The new Anti-Money Laundering Regulation requires obliged entities to apply strict CDD and transaction monitoring standards. When AI automates those processes, both the EU AMLR and the AI Act's high-risk obligations apply at the same time.

FATF Recommendation 15: FATF Rec 15 addresses new technology risks in AML/CFT contexts, including AI in transaction monitoring. Banks using AI for suspicious activity detection must satisfy FATF standards and AI Act transparency requirements simultaneously. The explainability obligations in Article 13 map directly onto FATF's expectation that AI outputs are auditable.

SR 11-7 / EBA Model Risk Guidance: The SR 11-7 model risk management framework, and its European equivalents in EBA guidelines on internal models, are the closest precursor frameworks. Institutions with a mature model governance program have a structural head start: model inventory, validation records, and performance monitoring processes translate directly into AI Act documentation requirements.

How FluxForce supports EU AI Act compliance

FluxForce agents operate with configurable autonomy and a kill switch at every stage. For high-risk AI use cases in financial services, including AI-powered fraud detection and transaction monitoring, the platform generates full decision explanations and audit-ready logs covering inputs, outputs, and operating context, directly satisfying Article 12 and Article 13 obligations. Documentation packages are available on demand for regulator review. To see how FluxForce operates within EU AI Act compliance requirements in a regulated environment, schedule a demo.