AI in finance works best where analysts read hundreds of pages to find a handful of relevant facts: in reports, KYC documents and AML alerts. In the financial sector, though, every such tool is an ICT service under DORA, with a register entry, an exit strategy and testing. Here is how to reconcile the two.
This article is for CIOs and the people responsible for ICT risk and compliance at banks, investment firms, payment institutions and insurers. DORA has applied since 17 January 2025, so this is not about preparing for it, but about fitting AI into a framework that is already in force. Legal position as of November 2026. This article is for information only and is not legal advice.
AI in finance use cases that stand up to an audit
The common thread: the model prepares the material, and a person who can see the sources makes the decision.
Report and document analysis
Counterparty financial statements, annual reports, prospectuses, loan agreements. The model extracts ratios and key clauses, compares periods, flags changes in risk disclosures and drafts a summary with references to source pages. The analyst starts from a briefing note rather than a 200-page PDF.
KYC: extracting data from documents
Registry extracts, articles of association, ownership structures, statements. The model identifies the document type, extracts fields (names, registration numbers, beneficial owners, dates) into a structured form and points out gaps or inconsistencies between documents. A staff member verifies the result before it goes into the system.
AML: alert triage
Transaction monitoring systems generate many alerts, most of which turn out to be false positives. An LLM can pull the context of an alert (customer history, related transactions, previous cases) into one note and suggest a priority. The decision to close an alert or file a report with the financial intelligence unit stays with the analyst; the model never closes alerts on its own.
| Use case | Data | AI Act | Human oversight |
|---|---|---|---|
| Report analysis | Mostly company data, sometimes personal data | Usually minimal risk | Analyst checks conclusions against sources |
| KYC extraction | Personal data of customers and beneficial owners | Usually outside Annex III | Staff approve every field |
| AML alert triage | Transaction and personal data | Usually outside Annex III (AML monitoring is not listed there) | Analyst decides on every alert |
| Creditworthiness assessment of individuals | Personal and financial data | High-risk (Annex III, point 5(b)) | Full AI Act requirements from 2 December 2027 |
The line is drawn at creditworthiness assessment of individuals, and at risk assessment and pricing in life and health insurance. These are high-risk systems, with obligations applying from 2 December 2027 following Regulation (EU) 2026/1744. Separately from the AI Act, decisions based solely on automated processing fall under Article 22 GDPR. For the wider picture, see self-hosted AI and EU compliance: GDPR, the AI Act, NIS2 and DORA.
DORA and your AI model provider: register, exit, concentration
DORA does not care that a service is called “AI”. A public language model API is an ICT service provided by a third party, so the full ICT risk management regime applies:
- Register of information. The contract with the model provider, including its subcontractors, goes into the register of ICT third-party arrangements.
- Contractual provisions. If the service supports critical or important functions, the contract must cover, among other things, processing locations, audit rights, termination rights and exit assistance. Standard public API terms rarely do.
- Exit strategy. Providers retire model versions on their own schedule. A new version may extract fields and summarise differently. You need to know how you will move the process to another model before that happens.
- Concentration risk. A handful of model vendors serve a large share of the market, often on the same few clouds. Making a key process depend on one API is a risk you have to assess and document.
- Incidents. An outage or leak at the provider is an ICT incident you classify and, where required, report. Without access to the provider’s logs, establishing the scope can be hard.
Resilience does not mean abandoning the cloud, but it does mean having a plan B. We discuss multi-provider architecture in multi-cloud and hybrid cloud for resilient infrastructure.
Testing and model risk management
DORA requires a digital operational resilience testing programme covering ICT systems that support critical functions. An AI system is an application with an inference server, a vector database and integrations, so it is in scope for vulnerability scanning and scenario testing and, at selected entities, threat-led penetration testing (TLPT).
The quality of the model itself is a separate question. Banks are usually subject to supervisory expectations on model risk management (in Poland, KNF Recommendation W). For LLMs, in practice that means:
- A reference set. A few hundred documents with manually verified results, used to measure extraction and summary accuracy.
- Regression tests on every change to the model, prompt, quantisation or serving software version.
- Source citations. Every conclusion links to a page in the document so the analyst can check it quickly.
- Monitoring. The rate of corrections made by staff, as a signal that quality is slipping.
We cover these practices in more depth in MLOps for secure AI model deployments.
Why a dedicated GPU cluster in a Polish data centre
For AI in finance, an open-weight model on a dedicated cluster solves several DORA problems at once. You change the model version when it passes your tests, not when the vendor retires it. The exit strategy is concrete: model weights, configuration and indexes are yours and can be rebuilt on other hardware. Customer data stays in the EU, and the logs are under your control.
To be fair, the infrastructure provider is also an ICT third-party provider and goes into the register. The difference is that it is a single company in Poland, with a contract covering audit rights, location and exit assistance. You also take on responsibility for operations (patching, high availability, monitoring), or outsource them as 24/7 managed administration. For serving software, see our comparison of Ollama, vLLM, SGLang and NVIDIA NIM; for hardware options, see GPU servers.
FAQ: frequently asked questions
Can a bank use ChatGPT or another public AI API under DORA?
Yes, but as an ICT third-party service: with a register of information entry, a risk assessment, the required contractual provisions and an exit strategy. For critical or important functions, the contractual requirements go beyond the standard terms of most public APIs.
Is AI for AML high-risk under the AI Act?
Annex III excludes systems used to detect financial fraud from the creditworthiness category, and AML transaction monitoring is not listed explicitly. Decisions affecting customers are still subject to the GDPR, including Article 22, and to AML rules.
Is AI credit scoring allowed in the EU?
Yes, but it is a high-risk system. From 2 December 2027, deployers must ensure human oversight, keep logs and inform customers, among other things, and the system provider must complete a conformity assessment.
How does DORA affect choosing an AI vendor?
It requires a vendor risk assessment before signing, specific contractual provisions, an exit strategy and a concentration risk analysis. In practice it favours set-ups where the model and data can be moved without the vendor’s involvement.
Planning AI in financial processes and want it DORA-compliant from the start? Begin with a DORA audit, look at our GPU servers and clusters in a Tier III, ISO 27001 certified data centre, and contact us.