KVKK Uyumlu PII Maskeleme
LLM Trafiğinde Veri Koruma

LLM Trafiği KVKK Açısından Neden Zor?

Klasik bir web uygulamasında kişisel veri belirli alanlarda durur. Bir kayıt formunda TCKN için ayrı bir alan vardır; veritabanında o sütunun adı bellidir, üzerinde erişim kontrolü kurulur, şifreleme uygulanır, denetim kayıtları tutulur. KVKK Madde 12 yükümlülükleri bu yapısal mimari üzerinde tasarlanmıştır ve uygulanması nispeten kolaydır.

Yapay zeka uygulamalarında durum kökten farklıdır. Veri her yerdedir; bir formun belli bir alanında değil, cümlenin tam içindedir. Kullanıcı asistana "IBAN'ım TR... olan hesaba transfer yapar mısın" diye yazar. Model cevabında aynı IBAN'ı tekrarlar. RAG sisteminden çekilmiş bir müşteri belgesi içinde TCKN listesi geçer. Agent bir araç çağrısı parametresine kart bilgisini iletir. Hiçbiri yapısal bir alanda durmaz; hepsi akış halinde serbest metin olarak dolaşır.

Bu durum KVKK denetimi için zorlu bir tabloya yol açar. İhlal tam olarak nerede gerçekleşti, hangi katman maskeleme yapmadı, sorumluluk kimde? Bu yazıda, LLM trafiğinde KVKK uyumlu kişisel veri maskelemesinin pratik mimarisini ele alacağız.

KVKK Yapay Zeka Bağlamında Nasıl Okunur?

6698 sayılı KVKK metni doğrudan "LLM" ya da "yapay zeka" maddesi içermez. Ancak temel ilkelerin tamamı bu bağlama doğrudan tercüme edilebilir.

Madde 4 (Genel İlkeler), kişisel verinin hukuka ve dürüstlüğe uygun, belirli ve meşru amaçlar için, ölçülü ve sınırlı süreyle işlenmesini şart koşar. LLM bağlamında bu, modelin gereksiz PII'yi loglamaması, gereksiz uzun süre saklamaması ve eğitim verisi olarak kullanmaması anlamına gelir.

Madde 6 (Özel Nitelikli Veriler), sağlık, cinsel hayat, ırk, etnik köken, siyasi düşünce, felsefi inanç, din ve mezhep, biyometrik ve genetik verileri ek koruma altına alır. Bir sağlık asistanına hastanın "şeker hastasıyım" demesi tam olarak bu kategoriye girer; bu içerik loglara maskeli olarak düşmeli, modelin eğitim setinde yer almamalıdır.

Madde 12 (Veri Güvenliği), veri sorumlusunun "uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbiri almasını" zorunlu kılar. Yapay zeka uygulamasında bu yükümlülüğün pratik karşılığı; prompt, çıktı, RAG ve log katmanlarının her birinde uygulanan maskeleme, şifreleme ve erişim denetimidir. Guardrail ve AI SOC mimarileri bu maddenin doğrudan teknik uygulamasıdır.

Son olarak veri ihlali bildirimi yükümlülüğü vardır. Bir kişisel veri ihlali tespit edildiğinde Kişisel Verileri Koruma Kurumu'na 72 saat içinde bildirim yapmak zorunludur. LLM sızıntıları, özellikle bir kullanıcının kişisel verisi modelin başka bir kullanıcıya verdiği cevapta belirdiğinde, bu yükümlülüğü doğrudan tetikler.

Türkiye'ye Özgü Kişisel Veri Tipleri

Genel amaçlı kişisel veri detektörleri (Microsoft Presidio, ticari muadilleri) Türkiye için kritik tipleri kapsamaz. ABD sosyal güvenlik numarasını bilir ama TCKN'i, Türk plakasının formatını ya da TR IBAN'ın MOD-97 doğrulamasını bilmez. Türkiye'de operasyon yapan bir uygulamanın kendine ait kişisel veri sözlüğünü kurması zorunludur.

Aşağıdaki tablo, Türk pazarında en sık karşılaşılan kişisel veri tiplerini ve her birinin doğrulama yöntemini özetliyor.

Bu listenin kritik noktası şudur: yalnızca biçim eşleşmesine güvenmek yanıltıcıdır. "12345678901" dizisi on bir hanelidir ama geçerli bir TCKN değildir; MERNİS algoritması bu dizide checksum hatası verir. Doğru yaklaşım, ancak doğrulamadan geçen değerleri kişisel veri olarak işaretlemektir. Bu yaklaşım, sadece regex'e dayalı bir tespitle karşılaştırıldığında yanlış pozitif oranını belirgin biçimde düşürür.

Akışın Hangi Noktalarında Maskeleme Yapılmalı?

Maskeleme tek bir noktada uygulanan bir filtre değildir; LLM akışının her geçtiği yerde tekrar tekrar devreye girmesi gereken bir disiplindir. Pratikte beş ayrı konumda bu kontrol uygulanır.

1. Kullanıcı Promptu Modele Ulaşmadan

İlk durak, kullanıcı isteğinin modele iletilmeden önce geçtiği süzgeçtir. Buradaki amaç, modelin (özellikle üçüncü taraf bir API ise) kişisel veriyi hiç görmemesidir. Tespit, regex ve algoritma doğrulamasının birleşimiyle yapılır; ardından aksiyon olarak ya yerinde belirteçleme uygulanır ("12345678901" değeri "[TCKN-A1B2]" gibi bir yer tutucuya dönüşür) ya da tam maskeleme yapılır. Belirteçleme tercih edildiğinde, orijinal değerle yer tutucu arasındaki eşleme şifreli bir kasada saklanır ve yalnızca arka uç iş mantığı gerçekten ihtiyaç duyduğunda geri çevrilir.

2. RAG Belgeleri Depolanırken

Vektör veritabanına eklenen sözleşmeler, müşteri kayıtları ve raporlar kişisel veri içerebilir. Bu içeriğin maskelenmemiş hali indeksleme katmanına girerse, sonradan yapılan her arama bu veriyi açığa çıkarma potansiyeli taşır. Doğru yaklaşım iki kopyalı bir politikadır: orijinal belge şifrelenmiş halde ana depoda durur, indekslenen versiyon maskelenmiş olur. Böylece embedding modeli kişisel veri üzerinden öğrenme yapmaz, arama da maskeli içerikten dönmüş olur.

3. Model Cevabı Kullanıcıya Dönmeden

Belki de en kritik nokta budur. Çünkü model halüsinasyonla, sistem promptu sızıntısıyla ya da farklı oturumlardan etkileşimle kişisel veri üretebilir. Modelin verdiği her çıktı, kullanıcıya iletilmeden önce kişisel veri detektöründen geçirilir. Algoritma doğrulamalı bir kişisel veri tespit edilirse çıktı sıkı reddetmeyle engellenir ve KVKK Madde 12 kapsamında olay kaydı tutulur. Belirsiz şüphe durumlarında ise içerik maskeli halde iletilir.

4. Log ve Telemetri Kayıtları Yazılırken

AI SOC için telemetri kritik; ama bu telemetrinin kişisel veriyi açık biçimde içermesi başlı başına bir uyumsuzluktur. Doğru mimari iki katmanlıdır: üretim logları yalnızca maskelenmiş kopyayı tutar, ham veri ise şifrelenmiş ve anahtar erişimi denetlenen bir adli kasada saklanır. Bu kasaya yalnızca olay araştırması sırasında, denetim kaydı tutularak erişilir.

5. Araç Çağrılarında

Agent mimarisiyle çalışan uygulamalarda model, kullandığı araca parametre olarak kişisel veri gönderebilir. Bu durumun denetlenmesi izin listesiyle yapılır: her aracın kabul edebileceği kişisel veri tipleri önceden tanımlanır. Örneğin "fatura_gonder" aracı IBAN parametresini alabilir, ama "hava_durumu" aracı için aynı içeriğin gelmesi anomalidir ve engellenir.

Farklı Maskeleme Stratejileri ve Kullanım Yerleri

Maskeleme tek bir tekniğin adı değildir; kullanım amacına göre seçilen bir strateji ailesidir. Hangisinin doğru olduğu, içeriğin sonraki adımlarda nasıl kullanılacağına bağlıdır.

Tam silme, en muhafazakâr yaklaşımdır. "12345678901" değeri "[TCKN-MASKED]" yer tutucusuna dönüşür ve geri çevrilemez. Yüksek güvenlik sağlar ama bağlam kaybı en yüksek olan tekniktir. Loglar, eğitim verisi ve yedeklerde uygulanır.

Belirteçleme (tokenization), daha esnek bir yaklaşımdır. Aynı değer "[TCKN-9F3A]" gibi geri dönüştürülebilir bir yer tutucuyla değiştirilir; orijinal değer ile yer tutucu arasındaki eşleme şifreli bir kasada saklanır. Eğer arka uç iş mantığı gerçekten orijinal değere ihtiyaç duyuyorsa (örneğin bir transfer işlemi) geri çevirme mümkündür; ama model bu süreçte ham veriyi hiç görmez. KVKK uyumlu çözümlerin en sık tercih ettiği yaklaşımdır.

Kısmi maskeleme, daha çok kullanıcı arayüzü için kullanılır: "5412-XXXX-XXXX-1234" örneğindeki gibi bilginin son birkaç hanesi tanıma için bırakılır, geri kalanı gizlenir. Model bu kısmi versiyonu görmez; sadece kullanıcı ekranında geri tanıma yapılır.

Format koruyan şifreleme, test verisi üretiminde tercih edilen bir yöntemdir. Şifrelenmiş ama format korunmuş bir değer üretir; örneğin "12345678901" yerine "98372615428" gelir. Bu, modelin "her on bir haneli sayı TCKN'dir" örüntüsünü öğrenmemesi gerektiğinde işe yarar.

Sentetik değiştirme, eğitim verisi anonimleştirme süreçlerinde kullanılır. "Ahmet Yılmaz, 0532 555 11 22" bilgisi "Burak Demir, 0535 333 44 55" gibi sentetik ama gerçekçi bir kombinasyonla yer değiştirir. Veri yapı olarak korunur, gerçek kişi açığa çıkmaz.

Diferansiyel mahremiyet gürültüsü, toplu istatistiklerde bireysel tanımlamayı engellemek için kullanılır. "Kaç kullanıcı belli bir soruyu sordu" gibi metriklere kontrollü gürültü eklenir; agregat değer hâlâ anlamlıdır ama tek bir kullanıcının davranışı geri çıkarılamaz. Analitik dashboard'larda tercih edilir.

Üretim Sınıfı Maskeleme Akışı

Tipik bir kurumsal LLM gateway'inde kişisel veri pipeline'ı şu adımlarla işler. Kullanıcının yazdığı prompt önce parçalara ayrılır ve her parçanın konum bilgisi saklanır. Ardından Türkiye'ye özgü tüm regex desenleri paralel biçimde tarama yapar; eşleşen adaylar MERNİS, Luhn ve MOD-97 gibi algoritmalar üzerinden doğrulama filtresinden geçer. Eğer Madde 6 kapsamında bir anlamsal tespit gerekiyorsa NLU sınıflandırıcısı bu noktada devreye girer.

Bütün bu kanıtlar toplandıktan sonra politika kararı verilir: tenant, tespit edilen kişisel veri tipi ve bağlam bir araya geldiğinde içeriğin tam silineceği, belirteçleneceği, kısmen maskeleneceği ya da değiştirilmeden iletileceği belirlenir. Belirteçleme tercih edildiyse orijinal değer şifreli kasaya yazılır, eşleme bilgisi saklanır. Sonunda modele iletilen prompt yalnızca maskelenmiş halidir; denetim kayıtlarına ise "bu istekte bir TCKN ve bir IBAN tespit edildi, her ikisi de belirteçlendi" gibi bir özet düşer.

Model cevap döndürdüğünde aynı pipeline ters yönde işler. Çıktıda algoritma doğrulamalı bir kişisel veri bulunursa engellenir ya da maskelenir. Ek gecikme mümkün olduğunca düşük tutulmalı; regex ve algoritma doğrulaması paralel çalıştığında kullanıcı algısı için ihmal edilebilir seviyede kalır. Madde 6 anlamsal tespiti daha pahalı olduğundan yalnızca gerektiğinde eskalasyon olarak devreye alınır.

Sık Yapılan Hatalar

Kişisel veri maskeleme katmanı kurulurken sıkça düşülen tuzakların başında sadece regex'e güvenmek gelir. "On bir hane gördüm, demek ki TCKN" yaklaşımı doğrulanmamış değerleri de yakalar ve yanlış pozitif sayısı patlar. Algoritma doğrulaması ihmal edilmemelidir.

Bir diğer yaygın hata yabancı kişisel veri detektörlerine güvenmektir. Genel amaçlı çözümler TCKN, VKN, TR IBAN doğrulaması ya da plaka formatı gibi Türkiye'ye özgü tipleri açık biçimde desteklemez. Türkiye için bu tipleri özel olarak ele alan bir detektör katmanı kurmak şarttır.

Yalnızca girdi tarafını maskelemek de tehlikeli bir kısırdır. Model halüsinasyonla, sistem promptu sızıntısıyla ya da RAG yan etkileriyle çıktıda kişisel veri üretebilir. Çıkış tarafı denetlenmediğinde KVKK ihlal yolu açık kalır. Belirteçleme kasasının basit bir veritabanı olarak tasarlanması da ayrı bir tuzaktır; kasa şifrelenmiş, erişimi denetlenen ve denetim kaydı tutan bir yapı olmalıdır. Anahtar yönetim sistemiyle entegre edilmemiş bir kasa kişisel veriyi korumaz, aksine onu tek bir yerde toplar.

Belirteçleme eşlemesinin süresiz tutulması, Madde 4'teki "ölçülü saklama" ilkesini ihlal eder; saklama süresi politikası net olarak belirlenmelidir. Bir başka kritik hata eğitim verisinde maskelemeyi atlamaktır; model ham kişisel veriyle eğitildiğinde bu içerik parametrelere sızar ve sonradan çıkarılması neredeyse imkânsız hale gelir. Son olarak Madde 6 verisini yalnızca regex ile aramak ciddi bir körlüktür; "diyabet hastasıyım" cümlesi regex'e yakalanmaz, anlamsal tespit gerektirir.

KVKK ve EU AI Act Çift Uyumu

Türkiye'de operasyon yürüten bir LLM uygulaması AB pazarına da hizmet veriyorsa EU AI Act yükümlülüklerine de tabidir. İki düzenleme arasında büyük bir örtüşme alanı vardır.

Pratikte bu örtüşmenin anlamı şudur: KVKK uyumlu bir kişisel veri pipeline'ı, EU AI Act'in büyük kısmını zaten karşılar. Açık kalan iki ana alan, insan denetim mekanizması ve risk yönetim sistemine ilişkin yazılı dokümantasyondur. Bu iki başlık kurum bünyesinde ek bir çalışma gerektirir.

Sonuç

Yapay zeka uygulamalarında KVKK uyumlu kişisel veri maskelemesi tek bir filtreyle çözülecek bir problem değildir; akışın beş ayrı noktasında işleyen bir pipeline gerektirir. Promptun modele ulaşması, RAG belgesinin depolanması, modelin cevap üretmesi, telemetrinin kayda alınması ve araç çağrılarının yapılması. Türkiye'ye özgü kişisel veri tipleri algoritma doğrulamalı tespit gerektirir, Madde 6 kapsamındaki özel nitelikli veriler ise anlamsal sınıflandırıcılarla yakalanır.

AltaySec olarak Guardian ürünüyle bu mimarinin yerli ve KVKK + EU AI Act bağlamında yapılandırılmış bir versiyonu üzerine çalışıyoruz. Türkiye'nin yapay zeka uygulamaları, yabancı kişisel veri detektörlerinin kör noktalarına bırakılmamalı; Türkiye'ye özgü tipleri açıkça destekleyen savunma çözümleriyle korunmalıdır.