Türk bankasına ya da sigorta şirketine GDPR el kitabıyla giren her yabancı danışman, eninde sonunda bir düzeltme notu yazmak zorunda kalıyor. İki düzenleme kağıt üstünde benzer görünüyor — hukuki sebep, ilgili kişi hakları, ihlal bildirimi, DPO muadilleri — ve çoğu hukuki görüş orada duruyor. Pipeline sahiplerinin böyle bir lüksü yok.
Aynı anda KVKK, GDPR, BDDK, SPK ve Sigortacılık ve Özel Emeklilik Düzenleme ve Denetleme Kurumu'nu (SEDDK) tatmin etmesi gereken veri mimarileri tasarladığım birkaç yılın ardından açıkça söyleyebilirim: farklar kozmetik değil. Storage yerleşiminde, CDC topolojisinde, vendor seçiminde ve consent akışlarının metninde kendini gösteriyorlar. Aşağıdakiler gerçekten önemli olan açıklar.
Açık Rıza, GDPR Consent'i Değildir
GDPR altı hukuki sebebe izin verir ve pratikte finansal işlemelerin çoğu sözleşmenin ifası ya da meşru menfaate dayanır. KVKK'nın 5. maddesi de istisnalar listeler, ancak KVKK Kurulu açık rıza yolu dışındaki uygulamalarda istikrarlı biçimde dar bir yorum benimsemiştir — özellikle özel nitelikli kişisel verilere dokunan her şeyde. KVKK kapsamında özel nitelikli veri, GDPR'ın aynı şekilde ayrıştırmadığı bazı kategorileri içerir: dini inanç, dernek üyelikleri, ceza kayıtları, biyometrik ve genetik veri ve kritik olarak sağlık verisi.
Bunun pipeline seviyesinde anlamı:
- Bir sağlık sigortacısındaki hasar veri seti, her satıra bağlı açık rıza kayıtları olmadan sıradan poliçe sahibi verisiyle aynı Kafka topic'ini, aynı S3 prefix'ini ya da aynı Snowflake şemasını paylaşamaz. GDPR ekipleri rutin olarak bu verileri bir arada tutar ve column-level erişime güvenir. KVKK Kurulu kararları tam olarak bu deseni cezalandırmıştır.
- Mevcut müşteriler üzerinde pazarlama analitiği için meşru menfaate dayanmak — normal bir GDPR duruşu — tekrar tekrar sorgulanmıştır. Ayrı açık rıza almadan işlem verisi üzerinde propensity modeli çalıştıran bankalara ceza kesilmiştir.
- Rıza geri çekme, türetilmiş veri setlerine yayılmalıdır. Müşteri rızasını geri çektiğinde feature store kayıtları, model eğitim snapshot'ları ve BI extract'leri erişilebilir olmalıdır. Devraldığım lakehouse tasarımlarının çoğu bunu tam yeniden inşa olmadan başaramaz.
Veri Yerleşimi Bir Tercih Değil, Sert Bir Kısıttır
GDPR sınır ötesi aktarımlara SCC, yeterlilik kararları ve BCR aracılığıyla izin verir. KVKK'nın 9. maddesi teknik olarak açık rıza ya da Kurul izniyle yurt dışına aktarıma izin verir, ancak finansal hizmetlerde pratik gerçeklik bir yerleşim zorunluluğuna çok daha yakındır.
BDDK'nın bilgi sistemleri yönetmeliği (2020'den beri yürürlükte, o tarihten beri sıkılaştı), bankaların birincil ve ikincil sistemlerinin Türkiye'de işletilmesini gerektirir. Sigorta tarafında paralel kurallar var. KVKK ile birleştiğinde bu, en kolay cloud mimarilerini öldürür:
eu-central-1üzerindeki Snowflake, GDPR'a bağlı diğer her Avrupa bankası için uygun olsa bile düzenlemeye tabi finansal veri için birincil depo olarak kabul edilemez.- Türkiye bölgesi olmayan managed servisler — Databricks'in büyük kısmı, pek çok SaaS observability aracı, neredeyse her ABD merkezli MLOps platformu — production verisi için masada değildir veya anonim extract ve on-prem inference içeren akrobatik çözümler gerektirir.
- Yedek hedefleri bile önemlidir. Felaket kurtarma katmanı Hollanda'daki bir Azure bölgesi olan ve örtük aktarım için Kurul onayı bulunmayan bir bankanın denetimden kaldığını gördüm.
Mimari sonuç, Türk finansal veri platformlarının zorunluluktan hibrit olma eğilimidir: birincil depolama için on-prem ya da Turkcell/Türk Telekom egemen bulutu, gerçekten yerel olarak yapılamayan şeyler için uluslararası araçlara giden dikkatle kapsamlanmış extract'ler.
İhlal Bildirimi: 72 Saat Kolay Olan Kısım
GDPR'ın 72 saatlik saati iyi anlaşılmıştır. KVKK'nın muadili — 2019/10 sayılı Kurul kararıyla belirlenen — teknik olarak "en kısa sürede"dir ve 72 saat tavanı vardır. Sancılı olan farklar:
- KVKK hem Kurul'a hem de etkilenen ilgili kişilere doğrudan bildirim yapılmasını gerektirir ve içerik gereksinimleri spesifiktir. GDPR denetim otoritesine bildirime izin verir ve ilgili kişi bildirimini yalnızca yüksek risk olduğunda zorunlu kılar. Pratikte KVKK doğrudan müşteri bildirimini çok daha sık zorlar.
- Kurul, ihlal bildirimlerini şirket adıyla birlikte kamuya açık web sitesinde yayımlar. Bu tasarım gereği itibar hasarıdır ve hızlı gerçekleşir. GDPR uygulamasının çoğunda buna benzer otomatik bir yayımlama yoktur.
- GDPR için işleyen — kapsam belirlemek için 72 saat alabildiğiniz — adli zaman çizelgeleri, Kurul daha erken bildiğinize hükmederse KVKK altında cezalandırılır. Bu nedenle loglama ve olay tespit kabiliyeti yalnızca operasyonel bir incelik değildir; yatırım yapılmamış SIEM bir uyum yükümlülüğüdür.
Veri Sorumluları Sicili (VERBİS) GDPR'da Karşılığı Olmayan Bir Yapıdır
VERBİS kaydı, belirli eşiklerin üzerindeki her veri sorumlusunu işleme amaçlarını, veri kategorilerini, saklama sürelerini, alıcı gruplarını ve güvenlik tedbirlerini kamuya açık olarak beyan etmeye zorlar. Bu kırtasiye değildir — Kurul'un soruşturma sırasında baseline olarak kullandığı kamusal bir taahhüttür.
Bu pipeline'ları nerede vurur:
- VERBİS kaydınız işlem verisinin hukuki yükümlülük nedeniyle 10 yıl saklandığını söylüyorsa ve data lake'inizde 2008'den hâlâ ad-hoc analitik istek için sorgulanabilir bir partition varsa, GDPR muadilinin üretmediği bir sorununuz var demektir.
- Yeni veri ürünleri lansman öncesi VERBİS güncellemesi gerektirir. GDPR'ın iç doküman olan Madde 30 işleme kayıtlarına alışkın ekipler bunu sonraya bırakılacak iş gibi görür. Değildir. VERBİS'te beyan edilmemiş bir veri kategorisini işleyen bir ürün özelliği daha ilk gün uyumsuzdur.
- Saklama uygulaması otomatikleştirilmiş olmalıdır. GDPR'ın hesap verebilirlik ilkesi için işe yarayan manuel purge job'ları, kamuya açık VERBİS kaydınızı çekip warehouse'unuzdakiyle karşılaştırabilen bir düzenleyiciyi tatmin etmez.
Sektörel Çakışma Yüzey Alanını Çoğaltır
GDPR büyük ölçüde kendi kendine yeterlidir. KVKK ise BDDK, SPK, MASAK, SEDDK ve Bankacılık Kanunu'nun sır saklama hükümlerini içeren bir yığının bir katmanıdır. Bunlar yalnızca kural eklemekle kalmaz — aynı veri noktasında bazen KVKK ile çatışırlar.
Somut örnek: Bir müşteri işlem geçmişi üzerinde KVKK silme hakkını kullanır. Bankacılık Kanunu ve MASAK aynı verinin on yıl saklanmasını gerektirir. Çözüm iyi bilinir — hukuki yükümlülük silme talebini geçersiz kılar — ancak pipeline yine de (a) talebi tanımak, (b) hukuki yükümlülük dışındaki amaçlar için işlemeyi kısıtlamak, (c) çatışmayı belgelemek ve (d) kısıtlanmış verinin analitiğe, pazarlama modellerine ya da herhangi bir downstream sisteme akmadığından emin olmak zorundadır. GDPR ekipleri bunu bir tombstone flag ile yönetir. KVKK uygulaması, tombstone'un verinin her tüketicisinde fiilen çalışmasını ve talep üzerine denetlenebilir olmasını bekler.
Mimaride Gerçekte Ne Değişir
Bunu, saf bir GDPR build'i ile KVKK uyumlu Türk finansal build'i arasında istikrarlı biçimde farklılaşan tasarım seçimlerine sıkıştırmam gerekirse:
- Bir CRM alanı değil, her downstream pipeline tarafından satır seviyesinde sorgulanan birinci sınıf bir sistem olarak consent ledger.
- Yalnızca erişim kontrollü değil, fiziksel olarak ayrıştırılmış özel nitelikli kişisel veri — ayrı depolama, ayrı anahtarlar, ayrı denetim.
- Türkiye içinde birincil depolama; model artifact'leri ve feature vektörleri dahil sınırı geçen her byte için belgelenmiş gerekçe.
- VERBİS'te beyan edilen sürelere bağlı, otomatik silme kanıtı içeren, pipeline DAG'larında kodlanmış saklama uygulaması.
- GDPR'dan daha hızlı ve daha kamusal bir bildirim rejimine göre boyutlandırılmış olay tespiti.
- "Bu kişinin verisi türevleri dahil şu anda nerede" sorusunu saatler içinde yanıtlayabilen lineage, çünkü Kurul soracak.
Bunların hiçbiri egzotik değil. Tamamı GDPR muadili build'den daha pahalı ve büyük kısmı lakehouse'u yeniden yazmadan sonradan eklenemez. KVKK'nın Türkçe metinli GDPR olduğu varsayımıyla başlayan ekipler, ilk Kurul yazışmalarının civarında kaçınılmaz olarak şunu keşfeder: hata, varsayımın kendisiydi.