EU AI Act: Six Technology Implications for Financial Services Firms

A reading of the EU AI Act for financial services firms — what is in scope, when it applies, and the six technology implications firms now have to address alongside their DORA and GDPR work.

The EU AI Act entered into force on 1 August 2024 with phased application: prohibited practices from February 2025, general-purpose AI obligations from August 2025, high-risk AI systems from August 2026, and full application from August 2027. For financial services firms, most of the regulation’s substantive obligations have now begun to bite. The Act sits alongside DORA, GDPR, and sector-specific supervision rather than replacing any of them — and firms are expected to make all of these coexist coherently.

This is a reading of what the AI Act substantively does to financial services firms and the six technology implications that the CTO, CISO, and compliance function need to address.

What the Act covers

The Act takes a risk-based approach. AI systems are classified into four bands:

• Prohibited. Practices such as social scoring by public authorities, manipulative or exploitative systems, and certain biometric categorisation. Limited direct relevance to most FS firms but worth a confirmatory check.
• High-risk. Systems whose use creates significant risks to health, safety, or fundamental rights. Includes — explicitly — AI systems used for creditworthiness assessment and credit scoring of natural persons, and AI systems used for risk assessment and pricing in life and health insurance.
• Limited risk. Systems subject to transparency obligations — for example, chatbots must disclose that the user is interacting with an AI system.
• Minimal risk. The default category. No specific obligations beyond existing law.

For high-risk systems, the Act imposes substantive obligations: a risk management system across the lifecycle, data governance covering training and validation, technical documentation, record-keeping, transparency, human oversight, and accuracy, robustness, and cybersecurity. These obligations fall on providers (those who develop the system) and deployers (those who use it) with different cuts of responsibility.

Who this is for

• The CTO or CIO at a bank, investment firm, insurer, or fintech using AI in any customer-facing or operational capacity.
• The CISO whose ICT risk management framework now has to absorb AI-specific cybersecurity and robustness obligations.
• The compliance lead reconciling AI Act obligations with existing GDPR Article 22 automated-decision rules, DORA ICT risk requirements, and sector-specific supervision.

The six technology implications

1. Inventory every AI system in use. The firm needs a register of every AI system — developed internally, procured from vendors, or accessed via cloud APIs — with a classification of which Act band each falls in. Credit scoring models, insurance pricing models, fraud detection systems, customer onboarding analytics, chatbots, document analysis tools, and AI-augmented coding assistants all need to appear. The register is the foundation; without it, no further compliance work is meaningful.

2. Identify the high-risk systems specifically. The Act is most demanding on high-risk systems. The two FS-specific high-risk categories — creditworthiness assessment and life/health insurance risk assessment — capture a large share of what FS firms actually do with AI. Each high-risk system needs the full compliance treatment: risk management, data governance, documentation, human oversight, accuracy and cybersecurity.

3. Document the data governance for training and validation. The Act requires data sets used to train, validate, and test high-risk systems to be relevant, representative, free of errors, and complete. The provenance of training data, the steps taken to identify and mitigate bias, and the testing approach all need to be documented. Vendor-supplied systems force the question of what the firm can actually evidence about training data it never saw.

4. Build the human oversight that is actually meaningful. The Act requires effective human oversight of high-risk systems. A box-checking “human in the loop” that approves 99.9% of model outputs is not effective oversight. Meaningful oversight requires capability — the human needs to understand the system, see the relevant inputs, and have authority to intervene. The technology decisions about how outputs are presented and what override authority exists determine whether the oversight is real.

5. Reconcile with DORA, GDPR, and sector supervision. AI Act obligations sit alongside existing requirements. The firm’s ICT risk management framework under DORA needs to address AI-specific cybersecurity and robustness. GDPR’s automated-decision rules (Article 22) and the AI Act’s transparency requirements need a unified approach. CySEC, the FCA, the ECB, and other supervisors apply their own expectations on top. Treating these as separate compliance streams produces inconsistency and duplication.

6. Plan for the transparency obligations on limited-risk systems. Chatbots, deepfake-style content generation, and biometric categorisation systems carry transparency obligations even where they are not high-risk. The technology change is usually small (disclosure prompts, content labelling) but needs to be done systematically.

Where firms get this wrong

The AI inventory is incomplete. The firm has identified the obvious models — credit scoring, fraud detection — but missed the AI built into vendor SaaS, the GenAI tools the engineering team has adopted, and the experimental projects in business units.

The classification work has been done by compliance without technology input. Whether a system is high-risk depends on what it does and how it is used. Compliance reading the Act in isolation misses things; technology reading the systems in isolation misses things. Both functions need to do this together.

Vendor systems treated as the vendor’s compliance problem. Deployers have their own obligations. A vendor’s compliance does not satisfy the firm’s; the firm has to evidence its own controls.

Human oversight that exists on paper but not in practice. The most common deficiency. The oversight workflow is documented; the actual practice is rubber-stamping. Supervisors and auditors will examine the practice.

How we engage with this

We read AI Act readiness as part of a broader technology governance examination. As a Technology Control Review scoped to AI Act obligations, we read the AI system inventory, the classification work, the high-risk system documentation, and the integration with DORA and GDPR controls. The output is a written assessment of where the firm stands relative to the Act’s substantive expectations.

We do not certify AI systems. We do not represent firms to the European AI Office or national competent authorities. We do not produce the technical documentation itself. We read what is there, identify what is missing, and write it down.

Pricing is published at /pricing/. If your firm is working through AI Act readiness — alongside DORA, GDPR, and sector supervision — the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.