DORA and the EU AI Act require banks to control their AI infrastructure. Learn why on-premise small language models are the most practical path to compliance before August 2026.
Banks using API-based AI services are running out of time. Two overlapping EU regulations, the Digital Operational Resilience Act (DORA) and the EU AI Act, are creating a compliance environment where sending sensitive financial data to third-party AI providers is becoming a strategic liability, not just a technical choice.
This article explains what DORA and the EU AI Act require from financial institutions deploying AI, why these regulations make on-premise small language models (SLMs) the most practical path to compliance, and what banks should do now before the August 2026 enforcement deadline.
The Digital Operational Resilience Act (DORA) is an EU regulation that requires financial institutions to demonstrate they can withstand, respond to, and recover from ICT-related disruptions. DORA entered full enforcement on January 17, 2025, and applies to banks, insurers, investment firms, payment providers, and, critically ,their third-party ICT service providers.
DORA is not a directive that member states interpret individually. It is a regulation, meaning it is binding in its entirety and directly applicable across all EU member states.
For banks using AI, DORA introduces three requirements that directly impact how AI systems are deployed and managed.
DORA mandates that financial institutions maintain comprehensive risk management frameworks covering all ICT services they depend on. When a bank routes customer data through an external AI API, whether for compliance screening, document processing, or customer advisory, that API becomes part of the bank's ICT risk surface.
The institution must continuously assess the risks posed by this dependency, including latency, availability, data integrity, and the operational impact of service disruption. For AI systems processing sensitive financial data, this creates a significant governance burden that grows with every external dependency.
DORA requires active monitoring of third-party ICT providers, not just contractual due diligence at the point of procurement. Financial institutions must negotiate specific contractual clauses covering audit rights, security testing participation, incident notification timelines, data portability, and exit strategies.
For banks relying on external large language model (LLM) APIs, this means the AI provider must submit to the same oversight regime as any critical ICT vendor. In practice, hyperscale AI providers rarely accommodate the level of audit access and contractual flexibility that DORA demands, particularly for mid-market institutions with limited negotiating leverage.
DORA requires consistent classification and reporting of ICT incidents, along with regular resilience testing to prove systems can withstand disruptions. If an AI service experiences downtime or produces unreliable outputs, the institution must classify, document, and potentially report the incident to regulators.
Banks that run AI on their own infrastructure can conduct resilience testing directly. Banks that depend on third-party AI APIs must rely on their provider's willingness to participate in testing exercises, a dependency that DORA was explicitly designed to address.
The EU AI Act (Regulation EU 2024/1689) is the world's first comprehensive legal framework for artificial intelligence. It applies a risk-based classification system: the higher the potential harm an AI system could cause, the more stringent the compliance obligations.
The most critical deadline for financial institutions is August 2, 2026, when requirements for high-risk AI systems under Annex III become enforceable.
The EU AI Act classifies several financial AI applications as high-risk by default under Annex III. These include AI systems used to evaluate the creditworthiness of individuals or establish credit scores, AI systems used for risk assessment and pricing in life and health insurance, and AI systems used to evaluate eligibility for essential public services or benefits.
In practical terms, this means that AI-powered credit scoring, loan application screening, insurance underwriting, and customer eligibility assessment all fall within the high-risk classification. These are exactly the use cases where banks are increasingly deploying language models.
High-risk AI systems must meet requirements spanning risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness, and cybersecurity. Financial institutions deploying these systems must complete conformity assessments, maintain quality management systems, and register in the EU database before the August 2026 deadline.
One requirement has particular implications for AI architecture: the EU AI Act requires complete audit trails for high-risk AI systems, including proof of where training data originated, who accessed it, and how models were validated. This level of infrastructure-level provenance is extremely difficult to achieve when AI processing happens on third-party infrastructure.
Non-compliance with the EU AI Act carries penalties of up to €35 million or 7% of global annual revenue, whichever is higher. For high-risk AI systems, penalties can apply not only to the AI provider but also to the deployer, meaning the bank itself, not just its AI vendor.
Each regulation alone creates pressure toward greater control over AI infrastructure. Together, they create a compliance environment where on-premise deployment is the most straightforward path to meeting both sets of requirements simultaneously.
When a bank sends customer data to a third-party AI API, the data leaves the institution's infrastructure. Under DORA, this creates a third-party dependency that must be continuously monitored, contractually governed, and regularly tested. Under the EU AI Act, it creates an audit trail gap: the institution cannot fully demonstrate where data was processed, how it interacted with the model, or whether it was retained by the provider.
On-premise AI eliminates both problems. The data never leaves the bank's infrastructure. The institution controls the model, the data pipeline, and the complete audit trail from input to output.
API-based AI pricing follows a per-token or per-request model. As usage scales, costs become unpredictable and can spiral significantly. A compliance screening system processing millions of transactions monthly can generate API costs that exceed the cost of running a dedicated on-premise model within months.
On-premise small language models (SLMs) operate on fixed infrastructure costs. A purpose-built 1-2 billion parameter model running on a single GPU delivers predictable monthly costs regardless of query volume. For financial institutions that need to forecast AI operational expenses, a requirement that both DORA's risk management framework and standard financial planning demand, this predictability is essential.
DORA requires institutions to demonstrate operational resilience, meaning the ability to maintain critical operations during disruptions. If a bank's compliance screening, customer advisory, or document processing depends on an external AI API, an outage at the API provider directly impacts the bank's operational continuity.
An on-premise SLM runs on infrastructure the bank controls. It can be included in the institution's disaster recovery planning, tested under the institution's resilience framework, and maintained independently of any third-party provider's availability.
A small language model (SLM) is a purpose-built AI model typically containing 1-2 billion parameters, designed and fine-tuned for specific tasks within a defined domain. Unlike general-purpose large language models (LLMs) with hundreds of billions of parameters, SLMs are small enough to run on a single GPU, fast enough to deliver real-time responses, and specialized enough to achieve higher accuracy on domain-specific tasks.
For financial services, SLMs offer three advantages that directly address DORA and EU AI Act compliance requirements.
A small language model fine-tuned on financial compliance data, including regulatory texts, internal policies, and transaction patterns, typically achieves 90-95% accuracy on domain-specific tasks. A general-purpose LLM applied to the same tasks without fine-tuning typically achieves 60-75% accuracy. This accuracy gap matters because the EU AI Act requires high-risk AI systems to meet defined standards of accuracy and robustness.
Running an SLM on-premise means the financial institution owns the model weights, controls the training data, manages the inference infrastructure, and maintains the complete audit trail. This directly satisfies DORA's ICT risk management requirements and the EU AI Act's data governance and documentation obligations.
SLMs deliver 10-50x faster response times compared to API-based LLMs because inference happens locally without network round-trips. For real-time compliance screening, transaction monitoring, and customer-facing advisory systems, this performance advantage is operationally significant.
Financial institutions that have not yet started planning for the combined impact of DORA and the EU AI Act on their AI deployments should take three immediate steps.
Map every AI system in your organization, including the ones embedded in vendor products that your teams may not think of as "AI." For each system, identify whether it processes data externally, what data it handles, and whether it falls within the EU AI Act's high-risk classification. Under DORA, also identify whether the AI provider constitutes a critical ICT third-party dependency.
For any AI system classified as high-risk under Annex III (credit scoring, loan screening, insurance risk assessment, eligibility evaluation) assess whether a purpose-built SLM deployed on your own infrastructure could replace the current solution. In many cases, a domain-specific SLM delivers better accuracy, lower latency, and predictable costs compared to a general-purpose LLM API, while simultaneously solving the compliance requirements.
The EU AI Act requires conformity assessments, quality management systems, technical documentation, and ongoing monitoring for high-risk systems. These frameworks take months to build and test. Institutions that wait until mid-2026 will face a compressed timeline that increases both compliance risk and implementation cost.
DORA and the EU AI Act are creating a regulatory environment where financial institutions must demonstrate full control over their AI systems: from data governance and audit trails to operational resilience and third-party risk management. On-premise small language models provide the most direct path to meeting these requirements because they keep data sovereign, costs predictable, and infrastructure under the institution's control.
The August 2, 2026 deadline for EU AI Act high-risk system compliance is approaching fast. For banks still routing sensitive data through external AI APIs, the time to evaluate on-premise alternatives is now.
If your institution is evaluating how to deploy AI that meets both DORA and EU AI Act requirements, we can help you assess your options.
Related reading:
Stop renting generic models. Start building specialized AI that runs on your infrastructure, knows your business, and stays under your control.
