Banks are among the industries that stand to gain most from generative AI: customer service, document processing, credit analysis, regulatory tracking, employee support assistants. But banking is also one of the industries where data is most tightly protected. So the first and most critical question in a bank's GenAI project is usually: where will the model run?
The regulatory framework in Türkiye
In Türkiye, banks' information systems are governed by the banking regulator BDDK's Regulation on Banks' Information Systems and Electronic Banking Services. The regulation requires banks to keep their primary and secondary systems in-country. Where cloud services are used for these systems, the provider's systems and backups must also be in Türkiye.
Add the data protection law's rules on cross-border transfers and banking secrecy obligations, and in most scenarios sending customer data to public cloud LLM services abroad isn't an option. According to industry sources, BDDK is also working on additional AI-specific rules.
Three options
1. On-premise: the model runs in the bank's data centre
An open-weight language model runs on the bank's own GPU infrastructure.
- Pros: data never leaves the organisation, full control, easiest regulatory fit, low cost per use at high volume
- Cons: GPU investment, requires deployment and operations expertise, no access to the strongest closed models
2. Cloud: managed LLM services
The model is used through a cloud provider's managed service.
- Pros: fast access to the strongest models, no infrastructure investment, quick start
- Cons: data localisation and transfer constraints, vendor dependency, rising cost at high volume
The AWS Local Zone opened in Istanbul in May 2026 offers a new option for data residency requirements. However, the Local Zone currently provides core infrastructure services (such as EC2, S3 and EKS), not managed GenAI services. You can run your own model there, but it isn't enough to use managed LLM services in-country.
3. Hybrid: the right place for each type of data
In practice, the most sensible approach for many banks is to decide by data class:
- Customer data, credit files, internal documents → on-premise open models
- Public information, anonymised data, general productivity tasks → cloud, with appropriate safeguards
Decision criteria
| Criterion | On-premise | Cloud | Hybrid |
|---|---|---|---|
| Data privacy and regulation | ✅ Strongest | ⚠️ Constrained | ✅ By data class |
| Model quality | Good (open models) | Best (closed models) | Both |
| Speed to start | Slow | Fast | Medium |
| Upfront investment | High | Low | Medium |
| Cost at high volume | Low | High | Medium |
| Operational burden | High | Low | Medium |
The rise of open models
Until a few years ago, model quality was the main drawback of on-premise deployment. Today, thanks to high-performing open-weight models and efficient serving software such as vLLM, many banking scenarios, including document analysis, summarisation and enterprise knowledge assistants, can run successfully in-house. Economically, too, there's a threshold of high, sustained usage beyond which owning infrastructure can beat API pricing.
Which use case goes where?
| Use case | Recommended approach |
|---|---|
| Credit file and financial statement analysis | On-premise |
| Customer complaint classification | On-premise |
| Internal policy and procedure assistant | On-premise |
| Tracking public regulations and news | Cloud or on-premise |
| Marketing copy drafts (no customer data) | Cloud |
| Software development assistants | Depends on policy and code |
Conclusion
There's no single answer to "cloud or on-premise" for GenAI in banking. The right answer depends on the class of data, regulation, usage volume and the organisation's capabilities. For most banks, the way forward is a hybrid architecture in which critical data stays in-house.
Drawing on our experience building GenAI solutions on-premise and in the cloud for the banking sector, we offer On-Premise AI Infrastructure, Generative AI & LLM Solutions and AWS Consulting.
Sources