Bir katılımcı BES çağrı merkezine geliyor ya da daha sık görüldüğü üzere web sitesi üzerinden bir KVKK başvuru formu iletiyor ve kişisel verilerinin silinmesini talep ediyor. Operatör talebi kaydediyor. Uyum fonksiyonunun bir yerinde bir kayıt açılıyor. Ve asıl sorun burada başlıyor; çünkü BES katkı verilerini toplayan, zenginleştiren ve arşivleyen boru hattı, silme işlemini bir runtime operasyonu olarak ciddi biçimde düşünmekten çok önceki SPK ve EGM varsayımları altında tasarlandı.
Çelişki hiç de belirsiz değil. SPK, emeklilik kayıtlarının sözleşme ilişkisi sona erdikten sonra en az 10 yıl saklanmasını gerektiriyor. MASAK kapsamındaki AML yükümlülükleri kimlik bilgilerini, işlem geçmişini ve gerçek faydalanıcı belgelerini kapsıyor. Öte yandan KVKK'nın 7. maddesi, işleme için hukuki dayanak ortadan kalktığında veri sahibine silme talep etme hakkı tanıyor. Şirketler bunu, saklama istisnasına dayanarak silmeyi tümden reddederek çözüyor. Bu uyum değil. Bu, hukuki mütalaa kılığına bürünmüş bir kaçınma.
Gerçekte Ne Kırılıyor
Orta ölçekli bir Türk sigortacısındaki tipik bir BES boru hattı şöyle görünür:
- Kaynak sistemler: poliçe yönetimi (BES sözleşme), katkı defteri, devlet katkısı mutabakatı
- Entegrasyon katmanı: genellikle stored procedure'ler, SSIS veya Informatica işleri ve giderek artan şekilde Snowflake veya Exadata veri ambarını besleyen Kafka topic'leri karışımı
- Aşağı akış: aktüeryal modeller, MIS raporlaması, pazarlama segmentasyonu, EGM düzenleyici raporları, dolandırıcılık tespiti
Bir silme talebi geldiğinde, operasyon ekibi kimsenin hazırlıklı olmadığı bir soruyu sorar: Bu aşağı akış sistemlerinden hangileri katılımcının PII'sinin yeniden inşa edilebilir bir kopyasını hâlâ barındırıyor ve hangileri bunu saklamakla yasal olarak yükümlü?
Birlikte çalıştığım kurumların çoğunda dürüst cevap: kimse bilmiyor. Veri kökeni (lineage) hiçbir zaman bu ayrıntıda haritalanmadı. Saklama politikası tablo düzeyinde yazıldı, katılımcı düzeyinde değil. Pazarlamanın paylaşımlı bir sürücüde beş yıllık bir CSV dışa aktarımı duruyor. Dolandırıcılık ekibi 2021'de müşteri kayıtlarını almış ve silme API'si olmayan bir graph veritabanı kurmuş. Data lake, tasarımı gereği değişmez olan, alım tarihine göre bölümlenmiş parquet dosyalarıyla dolu.
Şirketlerin Gerçekte Uyguladığı Yarım Çözümler
Prodüksiyonda gördüklerim:
- Bayrakla soft delete: bir is_deleted sütunu 1'e çevrilir. Satır, SELECT erişimi olan herkese tam okunabilir kalır. Bu kimseyi tatmin etmez ve uyum illüzyonu yaratır.
- TCKN'yi hash'leyerek anonimleştirme: ancak isim, adres, doğum tarihi ve IBAN hâlâ oradadır. Yeniden kimliklendirme yaklaşık otuz saniye alır.
- Yalnızca OLTP'den silme: veri ambarı, yedekler, CDC stream'leri ve arşiv tape'leri her şeyi tutar. Katılımcının talebi teknik olarak gördüğü sistemde yerine getirilir, diğer her yerde göz ardı edilir.
- Hukuka bilet, aksiyon yok: talep kaydedilir, SPK saklamasına atıfta bulunan bir şablon yanıt gönderilir ve katılımcıya silmenin mümkün olmadığı söylenir. Bazen bu savunulabilir. Genellikle değildir, çünkü talep pazarlama verileri, davranışsal profiller ve düzenlemeye tabi olmayan türevler için kısmen yerine getirilebilirdi.
Doğru Bir Mimari Nasıl Görünür
Silme, hukuki bir eskalasyon değil, birinci sınıf bir boru hattı operasyonu olmalıdır. Somut olarak:
- Her sütunu alım aşamasında hukuki dayanağa göre sınıflandırın. MASAK amacıyla saklanan bir TCKN, pazarlama segmenti için saklanan aynı TCKN'den farklı bir saklama saatine sahiptir. Şemanız bunları tek bir tabloda tek bir alan olarak ele alıyorsa, zaten kaybetmişsinizdir.
- Düzenleyici zorunlu depolamayı analitik depolamadan ayırın. 10 yıllık SPK arşivi kilitli, minimal ve yalnızca ekleme yapılan bir depo olmalıdır. Bu, churn modellerini besleyen aynı veri ambarı olmamalıdır.
- Bir subject rights servisi kurun. Verilen bir TCKN için o katılımcının verilerini barındıran her sistemi listeleyebilen, her tutulan veriyi hukuki dayanağa göre sınıflandıran ve silmenin izin verildiği yerlerde silme veya takma adlaştırma işlemini yürüten tek bir API.
- Yedekleri kapsam dahilinde değerlendirin. Değişmez arşivler için işleyen tek yaklaşım, özne başına anahtar imhası (crypto-shredding) ile şifrelenmiş yedeklerdir. Bir Veeam snapshot'ından satır silmek diye bir şey yoktur.
- Sadece aksiyonu değil, kararı da loglayın. Silinmeyen her alan için, KVKK'yı geçersiz kılan spesifik düzenleyici atfı kaydedin. KVK Kurulu denetlediğinde — ki denetlemeye başladılar — her alan, her özne için gerekçe göstermeniz gerekir.
Rahatsız Edici Kısım
Bugün Türkiye'de çalışan BES boru hatlarının çoğu, yeniden inşa edilmeden bunların hiçbirini yapamaz. Devlet katkısı uygunluğunu hesaplayan stored procedure altı tabloyu join eder ve katılımcı kaydının mevcut ve eksiksiz olduğunu varsayar. Adresi silin, ikamet kontrolü başarısız olur. Doğum tarihini silin, hak ediş hesaplaması null döner. Boru hattı sonsuza kadar sürecek varsayımıyla yazıldı.
Önümüzdeki üç yılda bu işi iyi yönetecek şirketler, KVKK silmesini savuşturulacak bir hukuki sorun olarak değil, mühendislik gerektiren bir veri mimarisi gereksinimi olarak ele alanlar olacak. Bu, bütçe demektir, şema değişiklikleri demektir ve aktüerya ekibine tarihsel join'lerinden bazılarının takma adlaştırılmış anahtarlara karşı çalışması gerektiğini söylemek demektir.
Bu işi kötü yönetecek şirketler ise is_deleted bayraklarını çevirmeye devam edecek ve düzenleyicinin yakından bakmayacağını umacak. Bazıları KVK Kurulu'nun aslında yakından bakmaya başladığını ve cezaların artık sembolik olmadığını zor yoldan öğrenecek.
Seçim mimaridir. Son tarih dündü.