KVKK ve kişisel veri

Altay Kargo'nun destek botu müşterinin adını okur. İade asistanı sipariş geçmişini özetler. İnsan kaynakları asistanı da başvuru formundaki bilgiyi işler. Üç örnekte de model kişisel veriye dokunur ve bu dokunuş bir yerde kayıt bırakır.

Mühendis olarak sorman gereken sorular hukuki değil pratiktir. Bu veri neden gerekiyor? Nereye gidiyor? Ne kadar kalıyor?

Kim görebiliyor? Bu soruların cevabını kodda ve yapılandırmada gösterebilmen gerekir. Hukukçu ilkeyi yorumlar, ilkeyi sisteme işleyen kişi ise sensin.

Kişisel veri, kimliği belirli veya belirlenebilir bir gerçek kişiye ilişkin her türlü bilgidir. Ad ve TC kimlik numarası açık örnektir. Ama sipariş geçmişi, konum, IP adresi ve serbest metinde geçen bir ayrıntı da kişiyi belirlenebilir kılabilir. LLM akışında en çok serbest metin sorun çıkarır.

Müşteri sohbet kutusuna kendi adresini, hastalığını ya da komşusunun adını yazabilir. Sen bu alanı bu veri için tasarlamadın, ama veri artık senin sistemindedir. Sağlık bilgisi gibi özel nitelikli bir veri de bu yoldan, kimse istemeden sisteme girebilir. Kanun bu verileri ayrı ve daha sıkı şartlara bağlar.

Türkiye'de kişisel verilerin işlenmesini 6698 sayılı Kişisel Verilerin Korunması Kanunu düzenler. Denetim ve ikincil düzenleme yetkisi Kişisel Verileri Koruma Kurumundadır. Kanunun 4. maddesi işlemenin genel ilkelerini sayar: hukuka ve dürüstlük kurallarına uygunluk, doğruluk, belirli ve meşru amaç, amaçla bağlantılı, sınırlı ve ölçülü olma, gerekli süre kadar saklama.

Kurumun 2025 sonunda yayımladığı üretken yapay zekâ rehberi, bu ilkelerin yapay zekâ sistemlerinde de aynen geçerli olduğunu vurgular. Her ilke LLM akışında somut bir karara dönüşür. Amaç, prompt şablonunun ne içereceğini belirler.

Sınırlılık, modele hangi alanın gideceğini belirler. Saklama ilkesi de kayıtların ne zaman silineceğini belirler.

Bir LLM akışında kişisel verinin durduğu yerleri tek tek say. Kullanıcının mesajı ilk duraktır. İkinci durak bağlamdır: araçların ya da arama katmanının prompta eklediği kayıtlar ve belgeler. Üçüncü durak model sağlayıcısıdır, çünkü istek ağ üzerinden kurumun dışına çıkar.

Dördüncü durak modelin cevabıdır ve cevap da kişisel veri taşıyabilir. Son duraklar kayıt sistemi, gözlemlenebilirlik aracı, önbellek ve yedektir. Her durak için aynı üç soruyu sorarsın.

Veri neden burada? Ne kadar kalıyor? Kim görebiliyor?

Birinci ilke amaçla sınırlılıktır. Veriyi ancak belirli, açık ve meşru bir amaç için işlersin. Destek botuna müşterinin sipariş bilgisini vermen makul olabilir, aynı kişinin kredi notunu vermen değildir. Amaç dışına çıkan her alan gereksiz risktir.

Amacı prompt şablonunun yanına tek bir cümle olarak yaz ve şablona eklenen her alanı o cümleye karşı sına. Ekip yeni bir alan istediğinde soru basittir: bu alan yazılı amaca hizmet ediyor mu? Cevap hayırsa alan şablona girmez.

İkinci ilke veri minimizasyonudur. Kanundaki karşılığı, verinin amaçla bağlantılı, sınırlı ve ölçülü olmasıdır. Kısaca modele gereken en az veriyi verirsin.

Tüm müşteri kaydını prompta gömmek kolaydır. Ama model yalnız son siparişin durumunu söyleyecekse kayıttaki her ek alan bir sızıntı yüzeyidir. Enjeksiyonla kandırılan bir model, bağlamında ne varsa onu sızdırabilir.

Bağlamında olmayan veriyi ise sızdıramaz. Minimizasyon bu yüzden hem hukuki hem teknik bir savunmadır. OWASP'ın 2026 listesi de dış sağlayıcıya yalnız görevin gerektirdiği alanların gönderilmesini önerir.

# Once: butun musteri kaydi baglama giriyor
baglam = json.dumps(musteri_kaydi_getir(musteri_id))
# {"ad": "...", "tckn": "...", "adres": "...", "telefon": "...",
#  "dogum_tarihi": "...", "siparisler": [38 kayit], "notlar": "..."}

# Sonra: gorev icin gereken iki alan
siparis = son_siparis_getir(musteri_id)
baglam = json.dumps({"siparis_numarasi": siparis.numara,
                     "kargo_durumu": siparis.durum})
# {"siparis_numarasi": "AK-48213", "kargo_durumu": "dagitimda"}

Kodu satır satır oku. İlk sürüm müşteri kaydını olduğu gibi JSON'a çevirip bağlama koyar. Kayıtta kimlik numarası, adres, doğum tarihi, otuz sekiz sipariş ve çağrı merkezi notları var. Soru ise yalnız kargonun nerede olduğu.

İkinci sürüm önce son siparişi çeker, sonra bağlama yalnız iki alan koyar. Model iki durumda da aynı cevabı verir. Fark saldırı anında ortaya çıkar.

Birinci sürümde sızdırılan bağlam bütün profili verir, ikincide yalnız bir sipariş numarası ve bir durum gider. Sık hata, kolaylık için kurulan otomatik bağlam eklentileridir. Bu eklentiler her isteğe bütün profili ekler ve kimse fark etmez.

Minimizasyon modele giden veriyi azaltır. Kayda giden veriyi azaltmanın yolu ise maskelemedir. Metni saklamadan önce örüntüleri yakalar ve yerine sabit bir etiket koyarsın. TC kimlik numarası, telefon, e-posta, kart numarası ve IBAN en sık maskelenen alanlardır.

Maskeleme kayıt yazılmadan önce çalışmalı. Sonradan temizlemek geç kalmak demektir, çünkü ham metin o arada yedeğe, arama dizinine ve gözlemlenebilirlik aracına kopyalanmıştır. Aşağıdaki işlev dört desenle basit bir maskeleme yapar.

import re

DESENLER = [
    (re.compile(r"\b\d{11}\b"), "[TCKN]"),
    (re.compile(r"\b0?5\d{9}\b"), "[TELEFON]"),
    (re.compile(r"[\w.-]+@[\w.-]+\.\w+"), "[EPOSTA]"),
    (re.compile(r"\bTR\d{24}\b"), "[IBAN]"),
]

def maskele(metin: str) -> str:
    for desen, etiket in DESENLER:
        metin = desen.sub(etiket, metin)
    return metin

>>> maskele("TCKN 10000000146, tel 05321234567, posta [email protected]")
'TCKN [TCKN], tel [TCKN], posta [EPOSTA]'
>>> maskele("Siparis 20245512345 gecikti")
'Siparis [TCKN] gecikti'
>>> maskele("Ara: 0532 123 45 67")
'Ara: 0532 123 45 67'

Çıktıyı satır satır oku. Kimlik numarası ve e-posta doğru maskelendi. Ama telefon numarası da [TCKN] etiketi aldı.

Sebep sıralamadır. Sıfırla başlayan on bir haneli telefon, ilk sıradaki on bir hane desenine uyar ve telefon desenine sıra gelmeden değişir. İkinci örnekte on bir haneli bir sipariş numarası kimlik numarası sanıldı. Bu yanlış pozitif, olay incelemesinde siparişi bulmanı zorlaştırır.

Üçüncü örnekte boşluklu yazılan telefon hiç yakalanmadı. Düzeltme üç adımdır: telefon desenini öne al, on bir haneli adayı kimlik numarasının sağlama haneleriyle doğrula, boşluklu yazım için ayrı bir desen ekle. Presidio gibi açık kaynak araçlar bu işi desen, sağlama hanesi, bağlam kelimesi ve varlık tanıma modelini birleştirerek yapar.

Modeli bir sağlayıcı üzerinden çağırıyorsan kullanıcı verisi kurumunun dışına çıkar. Bu durumda sağlayıcı çoğu zaman senin adına veri işleyen konumundadır. Sağlayıcı veriyi kendi amacı için, örneğin kendi modelini eğitmek için kullanmaya başlarsa bu rol değişebilir. Verinin nerede işlendiği, ne kadar saklandığı ve model eğitiminde kullanılıp kullanılmadığı sözleşmede yazılı olmalı.

Sağlayıcının yönetim panelindeki bir ayar yetmez, çünkü ayarlar değişir. Mühendis olarak senin işin, verinin gerçek yolculuğunu çıkarmaktır. Hangi istek hangi bölgeye gidiyor, kayıtlar nerede tutuluyor, yedekler hangi ülkede duruyor? Bu harita olmadan uyum ekibi doğru karar veremez.

Sağlayıcı yurt dışındaysa ayrı bir hukuki başlık açılır. 2024'te 7499 sayılı Kanun, 6698'in aktarım maddesini değiştirdi ve yeni kurallar 1 Haziran 2024'te yürürlüğe girdi. Artık yurt dışına aktarım üç yoldan birine dayanır.

Birincisi, Kurulun bir ülke ya da sektör için verdiği yeterlilik kararıdır. İkincisi uygun güvencedir. Standart sözleşme, Kurulun onayladığı bağlayıcı şirket kuralları ve Kurulun izin verdiği yazılı taahhütname bu güvencelerdendir.

Standart sözleşme imzalandıktan sonra beş iş günü içinde Kuruma bildirilir. Üçüncüsü arızi hâllerdir. "Veri şifreli gidiyor" cümlesi bu dayanakların hiçbirinin yerine geçmez.

Arızi hâl, mühendislerin en sık yanlış anladığı yoldur. Temmuz 2024'te yayımlanan aktarım yönetmeliği bu hâli dar tanımlar. Arızi aktarım düzenli değildir, tek ya da birkaç sefer gerçekleşir, süreklilik taşımaz ve olağan faaliyet akışının dışında kalır. Her müşteri mesajını yurt dışındaki bir modele gönderen asistan bu tanıma uymaz.

Kurumun üretken yapay zekâ rehberi de yurt dışındaki bir sağlayıcı üzerinden yapılan işlemenin aktarım kurallarına tabi olduğunu açıkça yazar. Hangi yolun seçileceğine uyum ekibi karar verir. Sen ona akış haritasını, veri türlerini ve hacmi verirsin.

Saklama ilkesi, veriyi ancak amaç için gerekli süre kadar tutmanı ister. Sınırsız saklama savunulamaz. İstek ve yanıt kayıtları için bir süre belirle ve süre dolunca sil.

Silme işini el emeğine bırakma; otomatik çalışsın ve yedekleri de kapsasın. Süreyi seçerken iki ihtiyacı tart: olay incelemesi için kayda dönebilmek ve gereksiz birikimi önlemek. Çoğu ekip ham sohbet için kısa, maskelenmiş özet için daha uzun bir süre seçer.

LLM sistemlerinde verinin durduğu yer tek değildir. Sohbet kaydı, gözlemlenebilirlik aracındaki iz, önbellek ve vektör veritabanındaki gömme vektörleri ayrı ayrı sayılır. Kaynak belge silindiğinde ondan üretilen parçalar ve vektörler de belirli bir süre içinde silinmelidir.

Aydınlatma, kişinin verisi hakkında bilgi almasıdır. Kanunun 10. maddesi, veriyi toplarken kişiye şunları söylemeni ister: veri sorumlusunun kimliği, işleme amacı, verinin kimlere aktarılabileceği, toplama yöntemi, hukuki sebep ve kişinin hakları.

LLM akışında buna yapay zekânın rolü de eklenir. Kullanıcı karşısında bir model olduğunu ve yazdığının nereye gittiğini anlaşılır bir dille öğrenmeli.

Sohbet penceresinin altına küçük puntoyla gizlenmiş bir cümle bu işi görmez. 11. madde de kişiye haklar tanır. Bunlardan biri, yalnız otomatik sistemlerle yapılan bir analizin kendi aleyhine sonuç doğurmasına itiraz hakkıdır.

Son başlık ihlaldir. Kanun, işlenen verinin hukuka aykırı yollarla başkalarınca elde edilmesi hâlinde veri sorumlusunun bunu en kısa sürede kişiye ve Kurula bildirmesini ister. Kurul, kendisine yapılacak bildirim için en geç 72 saat bekler. LLM tarafında ihlal bazen beklenmedik bir yerden gelir.

Bir enjeksiyon, başka bir müşterinin sipariş adresini cevaba taşıyabilir. Bu da bir sızıntıdır ve bildirim değerlendirmesi gerektirir. Aynı ilkeler başka akışlarda da geçerlidir. Bir insan kaynakları asistanı özgeçmiş işlerken de önce amacı yaz, sonra alanı daralt, sonra süre koy ve kişiyi bilgilendir.