Bankacılık ve Sigortacılıkta Mobil Asistanlar Neden Ayrı Bir Güvenlik Testi İster?

Kısa cevap: Mobil uygulamasında yapay zekâ asistanı çalıştıran bir banka ya da sigorta şirketi, tek değil iki ayrı saldırı yüzeyi barındırır. Klasik mobil sızma testi birincisini kapsar: istemci, taşıma katmanı ve API yetkilendirmesi. Asistan katmanı ise ikincisidir ve girdisi serbest metin olduğu için parametre doğrulayan yöntemlerle ölçülemediğinden, ayrı bir senaryo testinden geçirilmesi gerekmektedir.

Bu makalemizde, mobil uygulamasına asistan yerleştiren finans kurumlarının bu bileşeni neden ayrı bir kapsamda ele alması gerektiğinden bahsedeceğiz. Sızma testlerinde sıkça karşılaştığımız bir tablo var: mobil uygulama raporu tertemiz geliyor, fakat rapordaki hiçbir bulgu uygulamanın içindeki sohbet penceresine değinmiyor.

Son bir haftada ne oldu?

Eylül 2026'nın ilk haftası, bu katmanın artık istisna olmaktan çıkıp standart hale geldiğini gösteren birkaç gelişmeye sahne oldu. Aşağıdaki maddelerin hiçbiri güvenlik olayı değildir; hepsi ürün duyurusu veya kilometre taşıdır. Tabloyu, yaygınlaşmanın hızını göstermek amacıyla derledik.

Tablodaki ilk iki satır konumuz açısından en anlamlı olanıdır. Revolut'un asistanı Nisan 2026'da Birleşik Krallık'ta 13 milyon müşteriye açılmıştı; kurum Ağustos sonunda kendi temel modeli üzerine kurulu bir araştırma laboratuvarı kurduğunu da duyurdu. Türkiye Sigorta'nın asistanı ise Şubat 2025'ten beri sahada. Yani bu bileşen artık bir pilot çalışma değil, milyonlarca müşterinin günlük işlemlerini üzerinden gerçekleştirdiği, üretim yükü taşıyan bir kanaldır.

Asistan neden klasik mobil sızma testinin dışında kalıyor?

Klasik bir mobil sızma testinin girdisi bellidir: form alanları, API parametreleri, oturum belirteçleri. Test uzmanı bu alanların her birine beklenmedik değerler vererek uygulamanın davranışını gözlemler ve elde ettiği sapmaları raporlar. Yöntem olgundur, işini de iyi yapar.

Asistan katmanında ise girdi, müşterinin yazdığı her cümle olduğu için ortada doğrulanabilecek bir parametre yoktur. Dil modelleri kendilerine gelen metinde veriyi talimattan ayırmadığı için, bir poliçe açıklamasına ya da bir hesap hareketi notuna yerleştirilen cümle, modelin gözünde kurumun verdiği talimatla aynı ağırlığı taşır. Buna istem enjeksiyonu (prompt injection) diyoruz.

Sonuç şu oluyor: mobil uygulamanın kendisi sertifika sabitlemeden yetkilendirmeye kadar her başlıkta temiz çıkarken, aynı uygulamanın içinde çalışan ve müşteriyle doğrudan konuşan asistan hiç denenmemiş halde üretimde kalıyor.

Bankacılık ve sigortacılığa özgü üç risk

Genel amaçlı bir sohbet testi bu üç riskin hiçbirini görmez, çünkü üçü de sorulara doğru cevap veren bir asistanda ortaya çıkabilmektedir.

Müşteriler arası veri sızıntısı. Asistan, oturumu açan müşterinin verisiyle başka bir müşterininkini aynı bağlamda tutuyorsa, doğru sorulmuş bir soru yanlış kişiye cevap verdirir. Vektör veritabanı (vector database) ve önbellek katmanları, bu hatanın en sık görüldüğü yerlerdir.

Yetkisiz işlem tetikleme. Asistan yalnızca bilgi veriyorsa zarar sınırlı kalır, ancak para transferi, limit değişikliği veya talimat iptali gibi bir aracı çağırabiliyorsa aynı açıklık teknik bir bulgu olmaktan çıkar ve doğrudan operasyon ekibini ilgilendiren bir finansal olaya dönüşür. Buna aşırı yetki (excessive agency) diyoruz.

Bağlayıcı beyan üretimi. Var olmayan bir teminatı, faiz oranını ya da iade koşulunu müşteriye yazan bir asistan, kurumu tüketici hukuku önünde savunmasız bırakır. 2024 yılında bir havayolunun, sohbet botunun uydurduğu iade politikasından sorumlu tutulması, bu riskin teorik bir tartışma olmadığını açıkça göstermiştir.

Test neyi ölçmeli?

Bu katmanın testi iki eksende yürütülür. Yalnızca birincisini ölçerek gerçekleştirilen bir çalışma, gereğinden fazla reddeden bir asistanı güvenli sayacaktır.

Dördüncü satır, birlikte çalıştığımız kurumların büyük bölümünde eksik kalıyor. Asistanın hangi aracı çağırabildiğini yazılı olarak çıkarmayan bir ekip, o asistanın risk sınırını da bilmiyor demektir. Bu envanter, testin kendisinden önce tamamlanması gereken ilk adım olarak ele alınmalıdır.

Üçüncü satır ise Türkiye'ye özgü bir başlıktır. Koruma katmanları (guardrail) çoğunlukla İngilizce örneklerle yazıldığından, aynı kuralın Türkçe girdiyle hiç denenmemiş olması sık karşılaştığımız bir durumdur.

Düzenleyici taraf ne bekliyor?

Türkiye'de yapay zekâya özgü bir çerçeve kanun henüz yürürlüğe girmedi. Ancak KVKK'nın 12. maddesindeki teknik ve idari tedbir yükümlülüğü, kişisel veri işlendiği andan itibaren zaten işlemektedir ve müşteri verisini okuyan bir asistan da bu kapsama giriyor. Kurumun Kasım 2025 tarihli Üretken Yapay Zekâ Rehberi de istem enjeksiyonuna karşı teknik kontrolleri ve red teaming (kırmızı takım) çalışmalarını açıkça saymaktadır.

Avrupa tarafında ise AB Yapay Zekâ Tüzüğü'nün 50. maddesindeki şeffaflık yükümlülükleri 2 Ağustos 2026'da uygulanmaya başladı. Yüksek riskli sistemlere ilişkin takvim, (AB) 2026/1744 sayılı Tüzük ile Ek III için 2 Aralık 2027'ye ötelenmiştir. Takvimin Türkiye'de yerleşik bir kuruluşu bağlayıp bağlamadığı, Tüzük'ün 2. maddesi kapsamında ayrıca değerlendirilmelidir.

Sonuç

Toparlayacak olursak, mobil uygulamadaki asistan yeni bir teknoloji tartışması değil, kapsamı güncellenmemiş bir test meselesidir. Uygulamanın kendisi test ediliyor, içindeki en yeni bileşen ise test edilmiyor.

Yapılması gereken üç şey nettir. Önce asistanın çağırabildiği araçların envanteri çıkarılır, ardından bu araçlardan işlem yapabilenler bir onay adımının arkasına alınır. Son aşamada katman, iki eksenli ve Türkçe girdi içeren bir senaryo testiyle ölçülür.

Bir de kayıt tutmak gerekiyor: asistanın hangi aracı hangi girdiyle çağırdığını göremiyorsanız, bir olay yaşandığında müdahale süreciniz de eksik kalacaktır.

Mobil uygulamasında asistan çalıştıran kurumlarda bu üç başlığı ayrı ayrı ele alıyor ve bulguları denetime sunulabilir kanıt biçiminde raporluyoruz. Bu blog yazısıyla ilgili sorularınız olursa bizlere ulaşabilirsiniz.