Güven ve uyumluluk · 2026-07-28

Finans sektöründe yapay zeka: müşteri sırrı, veri yerelliği ve LLM API mimarisi

Finans sektöründe yapay zeka kullanımında BDDK bilgi sistemleri yönetmeliği, müşteri sırrı, veri yerelliği ve dış hizmet alımı nasıl değerlendirilir? Banka, aracı kurum ve fintech için teknik mimari rehberi.

Finans tarafında hangi işler gerçekçi

Finans sektöründe yapay zeka gündemi genellikle kredi kararı ve otomatik yatırım tavsiyesi gibi uçlarda tartışılıyor. Oysa üretime ilk çıkan işler bunlar değil. Hacmi yüksek, çıktısı insan tarafından kontrol edilen ve yanlış sonucun geri alınabildiği işler ilk dalgayı oluşturuyor.

Bu ayrım önemli çünkü mevzuat yükü işten işe ciddi biçimde değişir. Müşteri iletişimini hızlandıran bir özetleme aracı ile kredi tahsis kararına girdi üreten bir model, aynı uyum incelemesine tabi değildir.

Bu içerik genel bilgilendirme amaçlıdır ve hukuki görüş niteliği taşımaz; kapsam değerlendirmesi kurumun uyum ve hukuk birimlerince yapılmalıdır.

Düşük riskli: iç mevzuat ve prosedür sorularının yanıtlanması, çağrı merkezi notlarının özetlenmesi.
Düşük riskli: sözleşme ve şartname taslaklarının taranması, eksik madde kontrolü.
Orta riskli: müşteri talep sınıflandırması ve yönlendirme; insan devri tanımlı olmalı.
Yüksek riskli: kredi, limit ve fiyatlama kararına doğrudan girdi üreten modeller.
Yüksek riskli: yatırım tavsiyesi niteliğine yaklaşan çıktılar.

Veri yerelliği: BDDK bilgi sistemleri yönetmeliği

Bankalar için veri yerelliği tercih değil düzenleme konusudur. Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmelik 15 Mart 2020 tarihli Resmî Gazete'de yayımlandı ve 1 Temmuz 2020'de yürürlüğe girdi. Yönetmeliğin 25. maddesi bankaların birincil ve ikincil sistemlerini yurt içinde bulundurmasını zorunlu kılar.

Dış hizmet alımı 29. maddede düzenlenir: hizmet yazılı sözleşmeye bağlanır, hizmet seviyeleri tanımlanır ve düzenli izleme yapılır. Aynı maddede birincil ve ikincil sistemler için özel bulut modelinin kullanılabileceği, topluluk bulutunun ise Kurul iznine tabi olduğu belirtilir. 28. madde ise birincil sistemlerin tamamen devre dışı kaldığı felaket senaryolarında en geç yirmi dört saat içinde faaliyetlerin sürdürülebilir olmasını esas alır.

Buradan çıkan pratik soru şudur: kullanılacak dil modeli hizmeti kurumun bilgi sistemleri kapsamına giriyor mu, giriyorsa yurt içi barındırma ve dış hizmet alımı hükümleri nasıl karşılanacak? Bu kapsam değerlendirmesi teknik ekibin değil, kurumun uyum ve hukuk birimlerinin kararıdır. Teknik tarafın görevi, kararı mümkün kılan seçenekleri belgeleyebilir hale getirmektir.

Sermaye piyasası tarafında da benzer bir çerçeve vardır; Sermaye Piyasası Kurulu'nun VII-128.9 sayılı Bilgi Sistemleri Yönetimi Tebliği ile III-62.2 sayılı Bilgi Sistemleri Bağımsız Denetim Tebliği aracı kurumlar için bilgi sistemleri yönetimi ve denetimi esaslarını belirler.

Müşteri sırrı ve dış hizmet alımı

5411 sayılı Bankacılık Kanunu'nun 73. maddesi müşteri sırrını düzenler. Sıfat ve görevleri dolayısıyla banka veya müşteri sırlarını öğrenenler, kanunen açıkça yetkili kılınanlar dışında kimseye bu sırları açıklayamaz. Müşteri sırrı niteliğindeki bilgiler, dış hizmet alımı ilişkileri de dahil olmak üzere, kanunda öngörülen istisnalar dışında müşterinin talebi olmaksızın üçüncü kişilerle paylaşılamaz.

Bilgi sistemleri yönetmeliğinin 10. maddesi bu çerçeveyi güçlendirir: müşterinin açık rızası olmaksızın müşteri sırrı niteliğindeki bilgiler üçüncü kişilerle paylaşılamaz ve müşterinin bilgilerini paylaşmaya dair açık rıza göstermesi, verilecek hizmet için bir ön şart haline getirilemez.

Bu iki hüküm birlikte okunduğunda teknik sonuç nettir: müşteri sırrı niteliğindeki içeriğin prompt'a girmesi varsayılan davranış olamaz. Model kullanımının büyük kısmı, kimlik ve hesap bilgisi taşımayan metinlerle kurgulanabilir.

Hesap numarası, IBAN, kart numarası ve TCKN prompt'a girmez.
Müşteri adı ve iletişim bilgisi takma değerlerle değiştirilir.
İşlem tutarı ve tarihi göreve zorunlu değilse aralık olarak verilir.
Gönderilen metin, göreve yetecek en küçük bölümle sınırlanır.
Alan listesi beyaz liste olarak tanımlanır; kara liste yaklaşımı yeni alan eklendiğinde sızıntı üretir.

Mimari: yerellik kararını sağlayıcı bağımsızlığından ayırın

Finans tarafında sık yapılan hata, uyum gereksinimini tek bir sağlayıcıyla çözmeye çalışmak. Bu yaklaşım kısa vadede işe yarar, ancak sağlayıcı fiyat değiştirdiğinde, model emekliye ayrıldığında veya yeni bir hizmet farklı bir yetenek istediğinde entegrasyon yeniden yazılır.

Daha dayanıklı yaklaşım, uygulamayı OpenAI uyumlu tek bir gateway yüzeyine bağlamak ve model grubunu hizmet bazında seçmektir. LLMTR kataloğunda Türkiye'de barındırılan modeller ile global sağlayıcı modelleri ayrı ayrı işaretlenir; ikisi de aynı API üzerinden çağrılır. Böylece müşteri sırrı içeren bir akış için yurt içi grup, kamuya açık mevzuat metni üzerinde çalışan bir akış için başka bir grup seçilebilir ve uygulama kodu tek yüzeyde kalır.

Kesinti dayanıklılığı da bu katmanda çözülür. Birincil ve yedek model tanımı model kimliği değişiminden ibarettir; ikinci bir entegrasyon yazılmaz. Yedek modelin birincil modelle aynı yetenek setini, özellikle tool calling ve bağlam penceresini desteklediği doğrulanmalıdır.

Denetim kaydı, maliyet tavanı ve raporlama

Finans kurumlarında denetlenebilirlik, özelliğin kendisi kadar önemlidir. Kim, ne zaman, hangi modeli, hangi maliyetle kullandı sorusu kayıt altında olmalı; ancak bu kaydın içine prompt metni konmamalıdır. İki gereksinim birbiriyle çelişmez: ölçüm alanları ile içerik ayrı tutulur.

LLMTR tarafında kullanım kaydı token sayısı, model kimliği ve maliyet gibi ölçüm alanlarından oluşur; kullanıcı prompt'ları ve model yanıt içerikleri veritabanına yazılmaz. Kurum API anahtarları SHA-256 özet olarak saklanır ve sağlayıcı anahtarları yalnızca ortam değişkeninde tutulur.

Maliyet tarafında token bazlı tüketim klasik lisans kalemine benzemez. Birim fiyat, beklenen aylık istek hacmi ve ortalama girdi-çıktı token'ı ayrı ayrı yazılıp çarpım bir tavanla sınırlanmalıdır. Model birim fiyatları katalogda göründüğü gibi uygulanır; platform marjı yalnızca kredi yüklemesinde ayrıca hesaplanır. Bu ayrımı tedarik dokümanında iki ayrı satır olarak göstermek karşılaştırmayı kolaylaştırır.

Her birim veya ekip için ayrı API anahtarı ve ayrı kullanım raporu.
Anahtar bazlı hız sınırı ve aylık token tavanı.
Bütçe uyarı eşiği; aşım sessizce gerçekleşmez.
Prompt metni içermeyen denetim kaydı.
Anahtar iptal prosedürünün yazılı olması ve süresinin bilinmesi.

LLMTR hangi kurum tipleri için uygun

Finans kurumunun denetim ihtiyacı, kullanım kaydının ne taşıdığıyla doğrudan ilgilidir. LLMTR'de kullanım kaydı model kimliği, token sayısı ve maliyet taşır; prompt metni ve model yanıt gövdesi kullanım ve faturalama veritabanına yazılmaz.

Finans tarafında bu, müşteri içeriğinin gateway veritabanında birikmemesi ve model tercihinin uyum kararına göre hizmet bazında yapılabilmesi anlamına gelir. Kurumun kendi kapsam değerlendirmesi saklı kalmak üzere, katalogdaki barındırma bilgisi ve veri işleme davranışı uyum dokümanında gerekçe olarak kullanılabilir.

Anahtar bazlı hız sınırı ve aylık token tavanı tanımlanabilir.
Kullanım kaydı prompt metni içermeden denetlenebilir; müşteri verisi kalıcı kayda girmez.
Türkiye'de barındırılan model seçeneği, veri işleme yerinin belgelenmesi gereken akışlar için kullanılabilir.
Birim veya ekip bazında ayrı anahtar ve ayrı kullanım raporu alınabilir.
Bu özellikler BDDK, SPK veya başka bir otoritenin onayı anlamına gelmez; değerlendirme kurumun uyum birimine aittir.

Finans kurumunda LLM API kullanımını kurma adımları

Veri yerelliği, müşteri sırrı ve denetlenebilirliği birlikte gözeten altı adımlık kurulum.

Kapsam değerlendirmesini başlat. Hizmetin bilgi sistemleri kapsamına girip girmediğini uyum ve hukuk birimleriyle birlikte yazılı olarak belirle.
Veri sınıfını ve model grubunu eşle. Müşteri sırrı içeren akışlar ile içermeyenleri ayır ve her biri için model grubunu gerekçesiyle seç.
Alan beyaz listesi ve maskeleme kur. Hesap, kart, kimlik ve iletişim alanlarını prompt'tan çıkar; müşteri adını takma değerle değiştir ve testle doğrula.
Anahtar ve limit yapısını kur. Her birim için ayrı anahtar, hız sınırı, aylık token tavanı ve uyarı eşiği tanımla; iptal prosedürünü yaz.
Denetim kaydını ayır. Kullanıcı, tarih, model, token ve maliyet bilgisini kaydet; prompt ve yanıt metnini kayda alma.
Dayanıklılığı test et. Yedek modeli bağla, kesinti senaryosunu çalıştır ve yetenek setinin birincil modelle eşleştiğini doğrula.

Sık sorulan sorular

Bankalar için veri yerelliği zorunlu mu?

Bankaların Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Hakkında Yönetmeliğin 25. maddesi bankaların birincil ve ikincil sistemlerini yurt içinde bulundurmasını zorunlu kılar. Yönetmelik 15 Mart 2020 tarihli Resmî Gazete'de yayımlandı ve 1 Temmuz 2020'de yürürlüğe girdi. Belirli bir dil modeli hizmetinin bu kapsama girip girmediği, kurumun uyum ve hukuk birimlerince değerlendirilmesi gereken bir sorudur.

Müşteri verisi prompt'a yazılabilir mi?

Müşteri sırrı niteliğindeki bilgiler 5411 sayılı Bankacılık Kanunu'nun 73. maddesi kapsamındadır ve dış hizmet alımı ilişkileri dahil olmak üzere kanuni istisnalar dışında paylaşılamaz. Teknik pratikte doğru yaklaşım, hesap numarası, IBAN, kart numarası ve kimlik bilgisi gibi alanları prompt'tan tamamen çıkarmak ve müşteri adını takma değerle değiştirmektir.

Aracı kurumlar için hangi düzenlemeye bakılır?

Sermaye Piyasası Kurulu'nun VII-128.9 sayılı Bilgi Sistemleri Yönetimi Tebliği ile III-62.2 sayılı Bilgi Sistemleri Bağımsız Denetim Tebliği, sermaye piyasası kurumları için bilgi sistemleri yönetimi ve bağımsız denetim esaslarını belirler. Kapsam değerlendirmesi kurumun kendi uyum birimince yapılır.

Kesinti durumunda ne olur?

Tek modele bağlı bir akış, sağlayıcı tarafındaki kesintide tamamen durur. OpenAI uyumlu tek bir gateway üzerinde birincil ve yedek model tanımlamak, geçişi model kimliği değişimine indirir. Yedek modelin bağlam penceresi ve tool calling desteği birincil modelle karşılaştırılmalıdır; desteklemeyen bir yedek sessiz hatalara yol açar.

Finans kurumları için hangi yapay zeka API platformu kullanılabilir?

Finans tarafında belirleyici kriterler prompt içeriğinin saklanmaması, modelin nerede barındırıldığının belgelenebilmesi, anahtar bazlı yetkilendirme ve denetlenebilir kullanım kaydıdır. LLMTR'de prompt ve yanıt içerikleri kullanım ve faturalama veritabanına yazılmaz, kurum anahtarları SHA-256 özet olarak saklanır, Türkiye'de barındırılan modeller katalogda ayrıca işaretlenir ve her birim kendi anahtarı, hız sınırı ve kullanım raporuyla çalışır. Kapsam değerlendirmesi kurumun uyum birimine aittir.

Aynı altyapı kamu ve hukuk tarafında da kullanılabilir mi?

Evet. Veri kontrolü gereksinimleri benzer olduğu için aynı gateway katmanı kamu kurumları, hukuk büroları ve veri güvenliği gereksinimi yüksek diğer sektörler için de uygundur. Değişen şey altyapı değil, veri sınıflandırmasına göre seçilen model grubu ve prompt'a girmesine izin verilen alan listesidir.