KVKK ve LLM Güvenliği:
Yapay Zekâ Projelerinde Kişisel Veri Uyumluluğu

KVKK ve LLM güvenliği ilişkisi nedir?

KVKK ve LLM güvenliği ilişkisi, kısaca şudur: bir büyük dil modeli (LLM) uygulaması kullanıcıdan gelen metni işlediği, bu metni saklayıp geri getirdiği veya modeli gerçek kayıtlarla eğittiği anda kişisel veri işleme faaliyeti başlar ve 6698 sayılı Kişisel Verilerin Korunması Kanunu devreye girer. Yani "yapay zekâ" olması, bir sistemi KVKK'nin dışında bırakmaz; aksine, verinin nereye aktığı klasik yazılımlara göre daha bulanık olduğu için uyum yükü genellikle daha ağırdır.

Fark şurada yatar: geleneksel bir uygulamada geliştirici, hangi alanın veritabanına yazıldığını satır satır bilir. Bir LLM'de ise girdi doğal dildir; kullanıcı bir cümlenin içine TCKN, sağlık bilgisi ya da IBAN gömebilir, model bunu bağlamına alır, log'a düşürür, benzer bir soruda geri üretir. Bu yapısal belirsizlik, KVKK açısından iki temel yükümlülüğü öne çıkarır: veri güvenliği (Madde 12) ve amaçla sınırlı, ölçülü işleme (Madde 4). LLM güvenliği bu iki yükümlülüğün teknik karşılığıdır.

Bu rehber boyunca "yapay zekâ KVKK uyumu" derken kastedilen, bir uyum belgesi hazırlamaktan çok, modelin gerçek veri yollarında kişisel verinin nereye gittiğini görünür kılmak ve kontrol altına almaktır. Uyum, sözleşmede değil, veri akışında kazanılır.

LLM projelerinde kişisel veri nerede işlenir?

Bir LLM sisteminde kişisel veri tek bir yerde durmaz; sistemin dört ayrı yüzeyinde dolaşır. Her yüzey ayrı bir sızıntı vektörü ve ayrı bir kontrol noktasıdır. KVKK uyumunu değerlendirirken bu dört yüzeyi tek tek denetlemek gerekir.

1. Prompt ve girdi katmanı

Kullanıcı promptu, en görünür ama en hafife alınan yüzeydir. Bir müşteri destek asistanına "Babamın TCKN'si 1XXXXXXXXXX, poliçesini iptal edin" yazıldığında, bu cümle o an kişisel — hatta bazen özel nitelikli — veri içerir. Sistem promptunun içine gömülen örnek müşteri kayıtları da aynı kapsamdadır. Girdi katmanında kontrol, verinin modele ulaşmadan önce maskelenmesi veya işleme amacının dışındaysa reddedilmesi demektir.

2. Log ve telemetri katmanı

LLM sistemleri hata ayıklama, kalite ölçümü ve gözlemlenebilirlik için konuşmaları loglar. Bu loglar çoğu zaman ham promptu ve ham cevabı — dolayısıyla içindeki kişisel veriyi — olduğu gibi saklar. Üçüncü taraf gözlemleme (observability) ve LLMOps araçları devreye girdiğinde veri, farkında olmadan yurt dışındaki bir hizmete de aktarılıyor olabilir. KVKK açısından log'lar çift risk taşır: hem saklama süresi hem yurt dışı aktarım yükümlülüğü. Logları maskelenmiş biçimde tutmak, çoğu projede en hızlı kazanılan uyum adımıdır.

3. RAG ve vektör veritabanı katmanı

Retrieval-Augmented Generation (RAG) mimarilerinde kurum belgeleri parçalara bölünüp embedding'e dönüştürülür ve bir vektör veritabanında indekslenir. Bu belgeler içinde müşteri kayıtları, sağlık raporları veya İK verileri varsa, kişisel veri artık kalıcı olarak indekste durur. İki risk vardır: yetkisiz bir sorgunun ilgisiz bir kişinin verisini geri getirmesi ve embedding'lerden içerik çıkarımı (inversion). Bu konuyu RAG güvenliği nedir yazısında ayrıntılı ele alıyoruz; KVKK açısından kritik nokta, indekslenen belgelerin de bir "işleme" olduğu ve erişim kontrolüne tabi tutulması gerektiğidir.

4. Fine-tune ve eğitim verisi katmanı

Bir modeli gerçek kurum verileriyle fine-tune etmek, kişisel veriyi modelin ağırlıklarına gömer. Akademik literatürde gösterildiği gibi (ör. Carlini ve diğ., 2020), diller modelleri eğitim verisindeki nadir ve benzersiz dizileri — telefon numaraları, kimlik numaraları — ezberleyip (memorization) uygun bir promptla geri üretebilir. Bu, KVKK açısından geri döndürülmesi en zor sızıntıdır: veriyi log'dan silebilirsiniz, ama modelin ağırlıklarından silmek pratikte yeniden eğitim gerektirir. Bu yüzden fine-tune öncesi verinin anonimleştirilmesi veya maskelenmesi temel bir tedbirdir.

KVKK'nin üretken yapay zekâya bakışı nedir?

Kişisel Verileri Koruma Kurumu, yapay zekâ alanında kişisel verilerin korunmasına yönelik tavsiye niteliğinde ilkeler yayımlamıştır. Bu ilkeler yeni bir "yapay zekâ kanunu" değil; mevcut KVKK ilkelerinin yapay zekâ bağlamına uyarlanmış halidir. Özetle vurgulanan başlıklar şunlardır:

• Baştan itibaren gizlilik (privacy by design): Veri koruması, sistem canlıya alındıktan sonra eklenen bir katman değil, tasarım aşamasından itibaren gömülü olmalı.
• Amaçla sınırlılık: Model yalnızca belirtilen amaç için gerekli veriyle çalışmalı; "belki lazım olur" mantığıyla veri biriktirilmemeli.
• Veri minimizasyonu: Amaç için gerekmeyen kişisel veri ne prompta, ne log'a, ne de eğitim setine girmeli.
• Şeffaflık ve aydınlatma: İlgili kişiler, verilerinin bir yapay zekâ sisteminde işlendiğinden ve nasıl işlendiğinden haberdar edilmeli.
• Olası ayrımcılık ve önyargı: Otomatik değerlendirme yapan sistemlerde çıktının ayrımcı sonuç doğurmaması gözetilmeli.

Pratikte bu ilkeler, yukarıda sayılan dört yüzeydeki teknik kontrollere çevrilir: minimizasyon → girdi maskeleme; amaçla sınırlılık → RAG erişim kontrolü; şeffaflık → aydınlatma metni ve gerektiğinde açık rıza; gizlilik-by-design → sistem promptuna gerçek PII gömmemek. Regülasyon soyut, uygulama somuttur; ikisi arasındaki köprüyü kuran şey mimaridir.

Türkiye'ye özel PII nasıl korunur? (TCKN, IBAN, VKN)

Yapay zekâ KVKK uyumunda en sık gözden kaçan nokta budur: yabancı tedarikçilerin PII tespit araçları, ABD ve AB formatlarına göre eğitilmiştir. ABD sosyal güvenlik numarasını (SSN) tanır, ama TCKN'yi sıradan bir 11 haneli sayı sanır. Bu, Türkçe dağıtımlarda yerel kimlikleyicilerin filtreden kaçması anlamına gelir. Türkiye'ye özgü kişisel veri türleri ve doğru tespit yöntemi şöyledir:

Tablonun son satırı ayrı bir başlığı hak eder. TCKN veya IBAN'ı algoritmayla yakalayabilirsiniz; ancak "hipertansiyon ilaçlarımı yeniledim" cümlesindeki sağlık verisini yakalamak, format eşleştirmeyle mümkün değildir — bağlam anlayan bir katman gerekir. Bu, KVKK'nin özel nitelikli veri kategorisine (Madde 6) girer ve daha ağır bir koruma rejimi ister. Bu kategoriyi ve LLM'lerdeki on somut sızıntı vektörünü KVKK Madde 6 ve LLM sızıntı vektörleri yazısında ayrıntılı inceliyoruz.

Yalnızca regex ile yerel PII aramak yüksek yanlış-pozitif üretir: rastgele her 11 haneli sayı TCKN sanılır, her uzun rakam dizisi kart sanılır. Algoritmik doğrulama (basamak kontrolü, MOD-97, Luhn) bu gürültüyü ayıklar — regex "aday"ı bulur, algoritma "gerçek mi" sorusunu yanıtlar. Bu iki aşamalı yaklaşım, Türkçe LLM dağıtımlarında pratik tespitin temelidir.

KVKK ilkeleri LLM veri işleme sürecine nasıl uygulanır?

KVKK Madde 4, kişisel veri işlemenin genel ilkelerini sıralar. Bu ilkelerin her biri, bir LLM projesinde somut bir mühendislik kararına karşılık gelir:

• Hukuka ve dürüstlük kurallarına uygunluk: Modele verilen ve modelden alınan verinin işleme amacı belgelenmeli; "gölge yapay zekâ" (shadow AI) — onaysız araçlara veri girilmesi — engellenmeli.
• Doğru ve güncel olma: Modelin ürettiği kişisel veriye ilişkin iddialar doğrulanabilir olmalı; halüsinasyonla üretilen yanlış kişisel bilgi de bir işleme sorunudur.
• Belirli, açık ve meşru amaç: Bir sohbet asistanı için toplanan veri, sonradan pazarlama veya profilleme için yeniden kullanılmamalı.
• Amaçla bağlantılı, sınırlı ve ölçülü: Prompt, log ve eğitim setine yalnızca amaç için gerekli olan veri girmeli — bu, teknik olarak maskeleme ve minimizasyon demektir.
• Öngörülen süre kadar saklama: Konuşma logları süresiz tutulmamalı; saklama süresi tanımlanmalı ve otomatik silme uygulanmalı.

Bu ilkeleri denetlemenin en somut yolu, sistemi düşmanca test etmektir: modelin bir kişinin verisini başka bir kullanıcıya sızdırıp sızdırmadığı, sistem promptunu açığa çıkarıp çıkarmadığı ancak LLM sızma testiyle görülür. Uyum bir kez kurulup unutulan bir durum değil; her model, her prompt değişikliği ve her yeni veri kaynağıyla yeniden doğrulanması gereken bir süreçtir.

LLM verilerini yurt içinde tutmak gerekli mi?

KVKK yurt dışına veri aktarımını yasaklamaz; 9. madde kapsamında koşula bağlar. Aktarım için ya açık rıza, ya Kurul'un yeterli koruma sağladığını ilan ettiği bir ülkeye aktarım, ya da uygun güvenceler (taahhütname veya standart sözleşme hükümleri) gerekir. Sorun, bulut tabanlı üçüncü taraf LLM API'lerinde bu koşulları sağlamanın ve belgelemenin karmaşık olmasıdır: veri fiilen nereye gidiyor, ne kadar saklanıyor, alt-işleyiciler kimler — bu sorular çoğu zaman net yanıtlanamaz.

Bu nedenle özellikle özel nitelikli veri işleyen sektörlerde — bankacılık, sigorta, sağlık, kamu — giderek yaygınlaşan tercih, açık kaynak modelleri (ör. Llama, Mistral, DeepSeek ailesi) kurum altyapısında barındırmaktır. Yurt içinde self-host, veriyi sınır dışına hiç çıkarmadığı için 9. maddenin aktarım yükümlülüğünü büyük ölçüde ortadan kaldırır; ayrıca log ve RAG verisi üzerinde tam kontrol sağlar.

Yerli düzenleyici çerçeve de bu yönde gelişmektedir. 2025'te yürürlüğe giren 7545 sayılı Siber Güvenlik Kanunu, kritik altyapı ve kamu tarafında yerli çözüm ve veri kontrolü beklentisini güçlendirmiş; AB tarafında EU AI Act, yüksek riskli yapay zekâ sistemleri için veri yönetişimi ve kayıt yükümlülükleri getirmiştir. Türkiye'de faaliyet gösterip AB pazarına da dokunan kurumlar için iki çerçeveyi birlikte okumak gerekir.

Yapay zekâ KVKK uyum kontrol listesi

Aşağıdaki liste, bir LLM projesini canlıya almadan önce geçilmesi gereken asgari uyum adımlarını özetler. Her madde, yukarıda anlatılan yüzeylerden birine dayanır.

• Veri envanteri: Modele hangi kişisel verinin girdiği (prompt, RAG, fine-tune) ve modelden hangi verinin çıkabileceği kayıt altına alındı mı?
• Hukuki dayanak: Her işleme amacı için açık rıza veya kanuni sebep belirlendi mi? Özel nitelikli veri için ek şart karşılandı mı?
• Girdi maskeleme: TCKN, IBAN, VKN, kart ve telefon algoritmik olarak tespit edilip modele ulaşmadan maskeleniyor mu?
• Çıktı kontrolü: Modelin cevabı, başka bir kullanıcının verisini veya sistem promptunu sızdırmadan önce denetleniyor mu?
• Log hijyeni: Loglar maskelenmiş mi, saklama süresi tanımlı mı, erişim yetkilendirmeye bağlı mı?
• RAG erişim kontrolü: Vektör indeksindeki belgeler kullanıcı yetkisine göre filtreleniyor mu?
• Yurt dışı aktarım: Üçüncü taraf API kullanılıyorsa 9. madde dayanağı ve alt-işleyici zinciri belgelendi mi?
• Aydınlatma ve şeffaflık: İlgili kişiler yapay zekâ ile veri işlendiğinden haberdar edildi mi?
• Özel nitelikli veri: Sağlık, inanç, cinsel hayat gibi Madde 6 verileri için ayrı tespit ve daha sıkı kontrol var mı?
• İhlal müdahalesi: Bir sızıntı durumunda 72 saat içinde bildirim yapacak süreç tanımlı mı?
• Düzenli test: Model, PII sızdırma ve prompt injection açısından periyodik olarak kırmızı takım testiyle deneniyor mu?

Bu liste bir uyum belgesinin yerini tutmaz; ancak teknik ekibin uyumu kod ve mimari düzeyinde nereye oturtacağını gösterir. Hukuki metin ile çalışan sistem arasındaki boşluk, çoğu ihlalin doğduğu yerdir.

Hangi standartlarla eşleşir?

KVKK-LLM uyumu tek başına durmaz; uluslararası çerçevelerle birlikte okunduğunda daha sağlam bir zemine oturur. Başlıca eşlemeler:

OWASP LLM Top 10'un Türkçe okunuşu ve her maddenin savunma karşılığı için OWASP LLM Top 10 Türkçe rehberine bakabilirsiniz. Bu çerçeveler birbirini dışlamaz; KVKK "ne" yükümlülük olduğunu, OWASP ve NIST ise "nasıl" korunacağını anlatır.

Maskeleme ve teknik önlemler nasıl uygulanır?

Uyumu koda çeviren en pratik teknik, maskelemedir: kişisel veriyi işlemenin öncesinde veya loglamanın öncesinde geri döndürülemez ya da yetkiyle geri döndürülebilir bir yer tutucuyla değiştirmek. Örneğin bir TCKN, modele "[TCKN]" olarak geçebilir; model işini bağlamla yapar, gerçek numarayı hiç görmez. Katmanlı bir mimaride üç kontrol noktası bulunur:

• Girdi katmanı: Regex + algoritmik doğrulama ile TCKN/IBAN/VKN/kart/telefon tespiti; tespit halinde maskele veya reddet.
• Bağlam katmanı: Serbest metindeki özel nitelikli veriyi (sağlık, inanç, cinsel hayat) bağlamsal sınıflandırma ile yakalama.
• Çıktı katmanı: Modelin cevabını, PII veya sistem promptu sızıntısı açısından son kez denetleme.

AltaySec'in geliştirdiği Guardian ürünü, bu üç katmanı tek bir savunma hattında birleştiren yerli bir çözümdür; PII modülü, Türkçe dağıtımların ihtiyacı olan TCKN/IBAN/VKN algoritmik tespitini ve KVKK Madde 6 kategorilerini ilk satırdan hedefleyecek şekilde tasarlanmıştır. Buradaki amaç bir ürünü öne çıkarmak değil, yabancı araçların Türkçe ve KVKK bağlamında bıraktığı boşluğun somut biçimde kapatılabilir olduğunu göstermektir. Aynı yaklaşımı açık kaynak kütüphaneler ve kendi geliştirdiğiniz kontrollerle de kurmak mümkündür; kritik olan, üç katmanın da yerinde olmasıdır.

Sonuç

KVKK ve LLM güvenliği ayrı iki başlık değil, aynı sorunun iki yüzüdür. Bir dil modeli projesi, kişisel veriyi dört yüzeyde — prompt, log, RAG, fine-tune — işler ve her yüzey ayrı bir uyum kararı ister. Türkçe dağıtımların kendine özgü zorluğu, yabancı araçların TCKN, IBAN ve VKN gibi yerel kimlikleyicileri tanımaması ve özel nitelikli veriyi bağlamdan okuyamamasıdır. Bu boşluk, yerel kurallar, algoritmik doğrulama ve katmanlı maskeleme ile kapatılabilir.

Uyum, bir belgede değil çalışan sistemin veri akışında kazanılır. Bu nedenle en sağlam yaklaşım, uyumu tasarım aşamasında gömmek, veriyi mümkün olan yerde yurt içinde tutmak ve modeli düzenli olarak PII sızdırma açısından test etmektir. Yapay zekâ projelerini hız uğruna denetimsiz canlıya almak, 2026'nın büyüyen uyum dalgasında en pahalıya mal olan hatadır.

Geri bildirim, kurumsal değerlendirme veya proje bazlı görüşme için: [email protected]

Sık Sorulan Sorular