Bankacılıkta RAG ve Uyum Asistanları: KVKK + BDDK Uyumlu, Denetlenebilir AI Mimarisi (2026)

TL;DR — Bankacılıkta üretken yapay zekânın işe yaraması, modelin ne kadar "akıllı" olduğuna değil, cevabını hangi belgeye dayandırdığına, bu dayanağı gösterip gösteremediğine ve her etkileşimin denetlenebilir kalıp kalmadığına bağlı. RAG (Retrieval-Augmented Generation) tam da bunu sağlar: modeli bankanın kendi mevzuatına, prosedürüne ve müşteri verisine bağlar; cevabın altına kaynak iliştirir; rol bazlı erişimle KVKK'nın veri minimizasyonu ilkesine yaslanır; her sorgu-cevap-kaynak üçlüsünü loglayarak BDDK denetimine hazır bir iz bırakır. Bu yazıda sahadan use-case envanterini, dört katmanlı bir mimariyi ve 8 haftalık bir pilot reçetesini paylaşıyorum.

Bankalarla çalışırken en sık duyduğum cümle şu: "Biz aslında ChatGPT'yi denedik ama mevzuatı bilmiyor, uyduruyor." Haklılar. Genel amaçlı bir dil modeli, eğitim verisinde olmayan bir bankanın iç genelgesini, güncel bir BDDK tebliğini ya da o müşterinin sözleşme şartlarını bilemez. Bildiğini varsaydığında da en tehlikeli haliyle karşılaşırız: kendinden emin bir tonla yanlış cevap. Bankacılıkta yanlış cevabın faturası ağırdır; operasyonel ve hukuki risk doğurur.

RAG'in çözdüğü mesele tam burada. Model cevap üretmeden önce, sorunun ne olduğuna bakıp bankanın kendi bilgi kaynaklarından (genelgeler, ürün dokümanları, prosedürler, sıkça sorulan sorular, mevzuat metinleri) ilgili parçaları çekiyor; sonra cevabını bu parçalara dayandırıyor. Yani modelin "hafızası" yerine bankanın güncel ve doğrulanabilir bilgisi konuşuyor. Bu, RAG'in finans ve kamu gibi "doğruluğun ve uyumun kritik olduğu" alanlarda pratik olmasının başlıca nedeni: model, soru sorulduğu anda iç kaynaklardan ilgili içeriği çekip olgu temelli, bağlama duyarlı yanıt üretiyor.

Kendi danışmanlıklarımda bunu şöyle özetliyorum: Chatbot "bir şey söyler", RAG ise "şu belgeye göre şunu söyler". Aradaki fark, bankacılıkta yapay zekânın pilotta kalmasıyla üretime geçmesi arasındaki farktır.

Sahada gözlemlediğim üç temel fayda var ve hepsi de regülasyonla doğrudan örtüşüyor.

1. Kaynak gösterimi (citation / grounding). İyi kurulmuş bir RAG sistemi, ürettiği her cevabın altında hangi belgeden, hangi paragraftan beslendiğini söyler. Bu sadece kullanıcı güveni için değil; bir uyum biriminin, denetçinin ya da müşteri temsilcisinin cevabı doğrulayabilmesi için kritik. RAG'in hangi veri kaynaklarını kullandığını belirtebilmesi, çıktının doğruluğunu teyit etmeyi ve yanıltıcı olabilecek noktaları yakalamayı kolaylaştırır; bu, halüsinasyonu azaltmanın temel avantajıdır. Kaynak gösteremeyen bir AI sistemini bankaya tavsiye etmem; çünkü gösteremiyorsa denetlenemiyor demektir.

2. Güncellenebilirlik. Mevzuat değişir, ürün şartları değişir, kampanya biter. RAG'de modeli yeniden eğitmenize gerek yok; bilgi tabanını güncellersiniz, model bir sonraki sorguda yeni bilgiyle konuşur. Dolandırıcılık tarafında bu özellikle değerli: bir çağrı merkezi senaryosunda sistemin bankanın güncel politikasını çekip konuşma akışını buna göre kontrol etmesi, bilgi tabanının gerçek zamanlı güncellenebilmesi mümkün oluyor.

3. Erişim kontrolü. Doğru kurgulanmış bir RAG, sadece kullanıcının yetkili olduğu belge parçalarını getirir. Bu, KVKK'nın veri minimizasyonu ve amaçla sınırlılık ilkeleriyle birebir örtüşür. Buna mimari bölümünde döneceğim çünkü işin kalbi burada.

Türkiye'de bankacılık, finansal sektörler arasında en ağır düzenleyici yüke sahip olanlardan biri. İki ana eksen var.

BDDK tarafı. Bankaların bilgi sistemleri yönetimi, BDDK'nın bilgi sistemleri ve iş süreçlerinin denetimine ilişkin düzenlemeleri çerçevesinde yürür. 2026'ya doğru tabloda dikkat çeken gelişme şu: BDDK ile Kredi Kayıt Bürosu (KKB) iş birliğinde, bankaların ve finansal kuruluşların yapay zekâ modellerini güvenilirlik, açıklanabilirlik, şeffaflık ve regülasyon uyumu kriterleri çerçevesinde test edebileceği bir "yapay zekâ güvenli test ve doğrulama ortamı" (AI Sandbox) yönünde çalışmalar öne çıkıyor. Amaç, modellerin üretime alınmadan önce denetlenebilir ve ölçülebilir bir çerçevede sınanması. Yine bu çalışmalarda yapay zekâ yönetişiminin ölçülebilir, denetlenebilir ve hesap verebilir olması gerektiği; bankalarda yapay zekâ komitelerinin, algoritmik denetimin ve risk bazlı düzenleme yaklaşımının öne çıktığı vurgulanıyor.

Bunu kişisel bir gözlemle bağlayayım: bir bankaya RAG projesi tasarlarken artık "çalışıyor mu" sorusu yetmiyor; "denetçiye nasıl anlatacağız" sorusu en az onun kadar önemli. Mimariyi bu soruyu cevaplayacak şekilde kurmak gerekiyor.

KVKK tarafı. Kişisel Verilerin Korunması Kanunu, müşteri verisinin işlenmesinde hukuki dayanak, amaçla sınırlılık, veri minimizasyonu ve saklama süreleri gibi ilkeler dayatır. RAG açısından bunun pratik karşılığı net: model çağrısından önce, uygulama ve veri erişim katmanında kullanıcının yetkisi kontrol edilmeli; retrieval (getirme) katmanı yalnızca kullanıcının rolüne, departmanına ve projesine uygun belge parçalarını taramalı. Bu yaklaşım KVKK'nın veri minimizasyonu ve amaçla sınırlılık ilkeleriyle çok daha uyumlu. Kısacası: yetki kontrolünü modele bırakamazsınız; mimariye gömmeniz gerekir.

"

Bankacılıkta benim altın kuralım şu: Model bir veri parçasını "görebiliyorsa" o veri zaten erişim katmanında o kullanıcı için filtrelenmiş olmalı. Maskeleme, anonimleştirme ve rol bazlı filtreleme model çağrısından önce gelir; sonra değil.

Bir bankayla başlarken ilk işim, RAG'in gerçekten katma değer üreteceği senaryoları haritalamak. Hepsi aynı risk ve getiri profiline sahip değil. Aşağıdaki tablo, sahada en sık önerdiğim use-case'leri risk ve hazır olma seviyesine göre özetliyor.

Use-case	Kullanıcı	Katma değer	Risk seviyesi	Pilota uygunluk
Mevzuat & uyum asistanı	Uyum, hukuk, iç denetim	Genelge/tebliğ yorumlama, hızlı dayanak	Orta	Yüksek
Çağrı merkezi copilot	Müşteri temsilcisi	Ürün/prosedür cevaplarını anında getirme	Orta	Yüksek
Şube personeli asistanı	Şube	İşlem adımları, ürün şartları	Düşük-Orta	Yüksek
KYC/onboarding desteği	Operasyon	Belge kontrol listesi, eksik tespiti	Orta	Orta
Dolandırıcılık politikası danışmanı	Fraud ekibi	Güncel politika ile senaryo eşleştirme	Yüksek	Orta
Kredi süreci dokümantasyonu	Krediler	Prosedür ve ön kontrol özetleri	Orta	Orta
İç bilgi tabanı arama	Tüm banka	"Bu konuda prosedür ne diyor?"	Düşük	Çok yüksek

Bu listede en sık önerdiğim başlangıç noktası iç bilgi tabanı arama ve uyum asistanı. İkisi de müşteri verisine doğrudan dokunmadan, ağırlıkla kurumsal doküman üzerinde çalıştığı için hem KVKK riski daha yönetilebilir hem de değer hızlı görünür hale geliyor.

Mevzuat ve uyum asistanı

En olgun use-case bu. Uyum ekipleri her gün onlarca "şu işlem şu tebliğe göre mümkün mü, hangi maddeye dayanıyor" sorusuyla boğuşuyor. RAG burada bankanın genelge arşivini, ilgili BDDK/KVKK metinlerini ve iç prosedürleri tarayıp dayanaklı bir taslak cevap üretiyor. Burada altını çizdiğim nokta şu: asistan karar vermez, taslak hazırlar; nihai yorum uzmana ait. Benzer alanlarda (örneğin telekom/enerji regülasyonlarının yorumlanması) RAG'in güvenilir yorum için kullanıldığı örnekler var; mantık aynı: regülasyon metnini getir, cevabı ona dayandır, kaynağı göster.

Çağrı merkezi copilot

İkinci güçlü senaryo. Müşteri temsilcisi konuşurken, sistem arka planda ilgili ürün/prosedür bilgisini getiriyor ve temsilciye dayanaklı bir öneri sunuyor. Burada müşteriye giden son cevabı insan veriyor; bu, hem KVKK hem operasyonel risk açısından güvenli bir kurgu. Aynı altyapı, dolandırıcılık tarafında daha ileri kullanılabiliyor: RAG'in ses transkripsiyonu, kimlik doğrulama ve canlı politika getirmeyi birleştirerek gerçek zamanlı dolandırıcılık tespitinde kullanıldığı örnekler var.

Dolandırıcılık politikası danışmanı

Yüksek riskli ama yüksek değerli. Fraud ekibinin elindeki bir senaryoyu bankanın güncel dolandırıcılık politikalarıyla eşleştirmek, RAG'in güncellenebilirlik avantajını en iyi kullandığı yer. Politika dün değiştiyse, model bugün yeni politikayla konuşur. Yine de bu use-case'i ben genelde ilk faza koymam; önce daha düşük riskli senaryolarla mimariyi ve denetim izini sağlamlaştırmayı tercih ederim.

Gelelim işin kalbine. Bankacılıkta RAG'i diğer sektörlerden ayıran şey, mimarinin her katmanına denetlenebilirlik ve erişim kontrolünü gömmek zorunda olmanız. Ben mimariyi dört katmanda düşünmeyi seviyorum.

1. Veri ve erişim katmanı (data & access layer). Her şeyin temeli. Belgeler kaynağından alınıp indekslenirken, üzerlerine rol/departman/yetki etiketleri (metadata) işlenir. Müşteri verisi içeren alanlar maskelenir veya anonimleştirilir. Kritik kural: model çağrısından önce, kullanıcının yetkisi bu katmanda devreye girer ve retrieval yalnızca yetkili parçaları tarar. Bu, KVKK veri minimizasyonunun mimari karşılığıdır.

2. Getirme katmanı (retrieval layer). Sorunun anlamına göre ilgili belge parçalarını bulan katman. Burada hibrit getirme (anahtar kelime + anlamsal arama) ve yeniden sıralama (re-ranking) kalite için kritik. Sektör basit getir-üret hattından hibrit getirme motorları ve gelişmiş filtreleme katmanları içeren bir mimariye olgunlaştı. Bankacılıkta bu katmanın çıktısı sadece "hangi parçalar" değil, "bu parçalar hangi belgenin neresinden" bilgisini de taşımalı; çünkü kaynak gösterimi buradan doğar.

3. Üretim ve doğrulama katmanı (generation & guardrails). Modelin cevabı ürettiği yer. Ama tek başına değil: cevabın getirilen kaynaklara sadık kalıp kalmadığını kontrol eden guardrail'lar, kaynak dışına çıkıldığında "emin değilim" diyebilen mekanizmalar, ve hassas konularda insana yönlendirme burada devreye girer. Benim ısrarla savunduğum ilke: cevap, getirilen kaynaklarla desteklenemiyorsa sistem cevap vermemeli. Bu, halüsinasyonu engellemenin en sağlam yolu.

4. Denetim ve gözlemlenebilirlik katmanı (audit & observability). Bankacılıkta asıl farkı yaratan katman. Her etkileşim için kim sordu, ne sordu, hangi belge parçaları getirildi, model ne cevapladı, hangi kaynaklara dayandı, guardrail'lar tetiklendi mi — hepsi loglanır. Bu log, BDDK'nın aradığı "ölçülebilir, denetlenebilir, hesap verebilir" yönetişimin somut çıktısıdır. AI Sandbox mantığı da tam buna hizmet ediyor: modeli güvenilirlik, açıklanabilirlik ve uyum kriterlerinde üretime almadan test etmek.

"

Bir cümleyle: İlk üç katman cevabı üretir, dördüncü katman o cevabı denetime hazır hale getirir. Bankada dördüncüsü olmadan diğer üçü eksik kalır.

Bu soruyu her bankada konuşuyoruz. Cevap tek değil; veri sınıflandırmasına bağlı.

Müşteri kişisel verisi ve hassas içeriğin işlendiği senaryolarda, modern RAG hatları cihaz üstü/yerinde işleme, şifreli veri getirme ve güçlü erişim kontrolü içerecek şekilde kurulabiliyor; bu da finansal uyum standartlarına uyum açısından önemli. Türkiye bağlamında ben genelde şu ayrımı öneriyorum: müşteri kişisel verisine dokunan ve mevzuatın yurt içinde tutulmasını gerektirdiği iş yükleri için on-prem veya egemen (yerinde/yurt içi) kurulum; hassasiyeti düşük, kurumsal dokümana dayalı iş yükleri içinse maliyet-performans dengesine göre değerlendirme.

Finans sektöründe maliyeti düşürmek için yapay zekâ ve bulutta ortak/standartlaştırılmış altyapı yönündeki çalışmalar da dikkat çekici. Bu, tek başına her bankanın ağır altyapı maliyetine girmeden, denetlenebilir ve standartlaşmış bir zeminde RAG yürütebilmesi açısından önemli bir yön. Yine de mimari kararı verirken benim önceliğim her zaman aynı: veri nerede, kim erişebiliyor, iz nerede tutuluyor.

Danışmanlıklarımda bankalara önerdiğim yaklaşım, büyük bir "AI dönüşümü" vaadiyle değil, dar kapsamlı ve ölçülebilir bir pilotla başlamak. İşte tipik bir 8 haftalık akış.

Hafta 1-2 — Kapsam ve veri. Tek bir use-case seçilir (genelde iç bilgi tabanı arama veya uyum asistanı). İlgili 200-500 belge belirlenir, erişim etiketleri ve maskeleme kuralları çıkarılır. KVKK açısından veri envanteri ve hukuki dayanak netleştirilir.

Hafta 3-4 — Mimari iskelet. Dört katman kurulur; getirme ve kaynak gösterimi çalışır hale getirilir. Bu aşamada amaç mükemmellik değil, uçtan uca "soru → kaynaklı cevap → log" akışını ayağa kaldırmak.

Hafta 5-6 — Kalite ve guardrail. Gerçek sorularla test edilir. Cevapların kaynaklara sadakati, yanlış cevap oranı, "emin değilim" davranışı ölçülür. Uzmanlardan geri bildirimle getirme ve guardrail'lar iyileştirilir.

Hafta 7-8 — Denetim ve sunum. Audit logları, açıklanabilirlik çıktıları ve metrikler bir araya getirilir; iç denetim ve uyum birimine sunulur. Burada hedefim her zaman aynı: pilotu, BDDK'nın beklediği denetlenebilirlik diliyle anlatabilmek.

Bu pilotun sonunda banka, üç soruya net cevap verebilir hale gelir: Sistem doğru cevap veriyor mu? Cevaplarını kaynaklandırabiliyor mu? Her şey denetime hazır loglanıyor mu? Bu üç "evet" olmadan üretime geçmeyi ben de önermem.

Sahadan birkaç tuzak paylaşayım, çünkü aynı hataları farklı bankalarda görüyorum.

• Erişim kontrolünü modele bırakmak. "Model nasılsa yetkisiz veriyi söylemez" yaklaşımı KVKK açısından risklidir. Filtreleme retrieval'dan önce, mimaride olmalı.
• Kaynak gösterimini sonradan eklemeye çalışmak. Citation, mimariye baştan gömülmezse güvenilir olmuyor. Getirme katmanı kaynak konumunu taşımalı.
• Denetim izini ihmal etmek. En çok bunu görüyorum. Sistem güzel çalışıyor ama denetçiye gösterilecek iz yok. Bankada bu, projeyi durdurur.
• Çok geniş başlamak. "Tüm bankaya AI" hedefiyle başlayan projeler pilotta boğuluyor. Dar başlayıp genişletmek çok daha sağlıklı.
• İnsanı devreden çıkarmak. Yüksek riskli senaryolarda asistanın karar verici değil, taslak hazırlayıcı olması gerekir. Nihai sorumluluk uzmanda kalmalı.

Bankacılıkta RAG'i doğru kurmanın özü aslında basit bir cümlede toplanıyor: zeki bir asistan değil, dayanağını gösterebilen ve denetlenebilen bir asistan kurmak. 2026 itibarıyla Türkiye'deki regülatif yönelim de tam bu noktaya işaret ediyor; BDDK ve KKB'nin güvenilirlik, açıklanabilirlik ve denetlenebilirlik etrafında şekillenen yol haritası, aslında iyi bir RAG mimarisinin zaten yapması gereken şeyleri kurumsallaştırıyor. Doğru kurguyla bu bir kısıt değil, rekabet avantajı haline geliyor — çünkü denetime hazır bir sistem, üretime de hazır bir sistemdir.