KVKK ve üretken yapay zeka: geliştirici gözüyle kontrol listesi

Kişisel Verileri Koruma Kurumu, Kasım 2025'te "Üretken Yapay Zeka ve Kişisel Verilerin Korunması Rehberi (15 Soruda)" adlı bir rehber yayımladı. Rehber hukukçular tarafından ayrıntılı biçimde yorumlandı. Bu yazıda farklı bir şey yapmak istiyorum: rehberin söylediklerini, yapay zeka özelliği geliştiren bir yazılım ekibinin somut olarak ne yapması gerektiğine çevirmek.

Baştan belirteyim: bu yazı hukuki görüş değildir. Rehberin kendisi de bağlayıcı değil, tavsiye niteliğindedir; uyuşmazlıklarda 6698 sayılı Kanun ve ikincil mevzuat esas alınır. Bir projeye başlamadan önce mutlaka kurumunuzun hukuk birimi ya da veri koruma danışmanıyla birlikte değerlendirme yapın.

Rehber kısaca ne diyor?

Rehber, üretken yapay zekanın ne olduğundan başlayıp ebeveynlere önerilere kadar 15 soruyu ele alıyor. Yazılım ekibini en çok ilgilendiren noktalar şunlar:

• Kişisel veri, bir yapay zeka sisteminin eğitim, kullanım ve çıktı üretme aşamalarının her birinde işlenebilir.
• Hazır bir modeli kendi amaçları için kullanan kurum, bu işleme bakımından genellikle veri sorumlusudur. Roller sözleşmedeki ifadeye göre değil, fiili kontrole göre belirlenir.
• Her işleme faaliyeti için ayrı bir hukuki sebep belirlenmelidir. Başka bir hukuki sebep varsa açık rızaya başvurulmamalıdır.
• Yurt dışına aktarımda önce yeterlilik kararına bakılır; yoksa standart sözleşme gibi uygun güvencelerden biri kullanılır.
• Kullanıcıya bir yapay zekayla etkileşimde olduğu söylenmeli, aydınlatma arayüzde erişilebilir olmalıdır.
• Çıktılar her zaman doğru değildir; insan denetimi ve halüsinasyonların izlenmesi gerekir.
• Güvenlik için veri koruma etki değerlendirmesi, gizliliği artırıcı teknolojiler ve prompt injection gibi yapay zekaya özgü tehditlere karşı test önerilir.

Şimdi bunları mühendislik adımlarına çevirelim.

1. Veri akışını haritalayın

Her şey, kişisel verinin sistemde nereden girip nereye gittiğini bilmekle başlar. Bir yapay zeka özelliğinde veri genellikle beş noktada bulunur:

1. İstem (prompt): Kullanıcının yazdığı metin ya da yüklediği belge.
2. Bağlam: Sistemin modele eklediği veri; müşteri kaydı, geçmiş talepler, RAG ile bulunan belgeler.
3. Çıktı: Modelin ürettiği metin. Kişisel veri içerebilir, hatta yanlış kişisel veri üretebilir.
4. Kayıtlar (log): İstek ve cevapların hata ayıklama ya da denetim için saklanması.
5. Eğitim ve iyileştirme: Verilerin modeli eğitmek ya da ince ayar yapmak için kullanılması.

Her nokta için şu üç soruyu yazılı olarak cevaplayın: Hangi kişisel veri var? Nereye gidiyor (hangi ülke, hangi sağlayıcı)? Ne kadar süre saklanıyor?

2. Modelin görmediği veri sızamaz

Rehberin veri minimizasyonu ilkesi, mimaride en etkili tedbire dönüşür: kişisel verinin modele hiç gitmemesi.

• Gerekli mi diye sorun. Bir raporu özetlemek, bir metni sadeleştirmek ya da bir talebi sınıflandırmak için çoğu zaman kişinin adına, T.C. kimlik numarasına ya da telefonuna ihtiyaç yoktur.
• Göndermeden önce maskeleyin. Gerekli değilse kimlik numarası, telefon, e-posta ve isimleri modele göndermeden önce takma adlarla değiştirin; cevap geldiğinde gerekirse geri çevirin.
• Bağlamı daraltın. Modele bütün müşteri kaydını değil, iş için gereken alanları verin.
• Yetkiyi bağlamda da uygulayın. RAG kullanıyorsanız, kullanıcının zaten göremeyeceği bir belge bağlama girmemeli.

3. Hukuki sebebi faaliyet bazında belirleyin

Rehber, eğitim, kullanım, çıktı üretme ve geliştirme gibi her faaliyet için ayrı bir hukuki sebep belirlenmesini istiyor. Yazılım tarafında bunun pratik karşılığı şu:

• Kullanıcı verisini modeli iyileştirmek için kullanmak, aynı veriyi kullanıcıya hizmet vermek için işlemekten farklı bir faaliyettir. Bu ikisini ayrı tutun; varsayılan olarak hizmet verisini eğitimde kullanmayın.
• İnternette açıkça erişilebilir veri, rehbere göre kendiliğinden "alenileştirilmiş" sayılmaz. Web'den toplanan verilerle model eğitecekseniz ayrıca değerlendirme gerekir.
• Açık rıza "her şeyi çözen" bir düğme değildir. Hukuki sebebi hukuk biriminizle belirleyin, arayüze rıza kutusu eklemeyi varsayılan çözüm olarak görmeyin.

4. Yurt dışı aktarımı sağlayıcı seçiminde çözün

Yaygın kullanılan büyük dil modellerinin çoğu yurt dışında çalışıyor. Bu yüzden model sağlayıcı seçimi, aynı zamanda bir veri aktarımı kararıdır.

• Sağlayıcının veriyi hangi bölgede işlediğini ve sakladığını öğrenin.
• API üzerinden gönderilen verilerin model eğitiminde kullanılıp kullanılmadığını ve ne kadar süre saklandığını sözleşmeden ve ayarlardan kontrol edin. Kurumsal API ile tüketiciye yönelik sohbet uygulamalarının koşulları genellikle farklıdır.
• Yeterlilik kararı yoksa Kanun'un 9. maddesindeki uygun güvencelerden biri (örneğin standart sözleşme) gerekir. Bu süreç hukuk biriminizin işidir, ama sağlayıcının bu belgeleri sağlayıp sağlayamadığını teknik seçim aşamasında sormak sizin işinizdir.
• Kişisel verinin gerçekten gerektiği işlerde, Türkiye'de ya da kendi sunucunuzda çalışan bir model seçeneğini değerlendirin.

5. Aydınlatmayı arayüze koyun

• Kullanıcıya bir yapay zekayla konuştuğunu ya da bir içeriğin yapay zeka ile üretildiğini açıkça gösterin.
• Aydınlatma metninde yapay zeka kullanımını ayrıca anlatın: hangi veri, hangi amaçla, hangi sağlayıcıya gidiyor.
• Aydınlatmaya, yapay zeka özelliğinin bulunduğu ekrandan tek tıkla ulaşılabilsin.

6. İlgili kişi haklarını teknik olarak mümkün kılın

İlgili kişi, verisinin işlenip işlenmediğini öğrenme, düzeltilmesini ya da silinmesini isteme hakkına sahip. Rehber bu hakların yapay zeka sisteminin her aşamasında geçerli olduğunu hatırlatıyor. Bu, mimaride şu soruların cevabını gerektirir:

• Bir kişinin verisini kayıtlarda, önbellekte ve RAG için oluşturulan vektör veritabanında bulabiliyor musunuz?
• Silme talebi geldiğinde bu kopyaların hepsini silebiliyor musunuz?
• Yapay zekanın analizi bir kişi aleyhine bir sonuca yol açıyorsa, bu karara bir insanın bakmasını ve kişinin itiraz edebilmesini sağlayan bir akış var mı?

Bu soruların cevabı sonradan eklenemez; veri modelini tasarlarken düşünülmelidir.

7. Çıktıyı doğrulayın

Üretken modeller ikna edici ama yanlış bilgi üretebilir. Kişisel veri söz konusu olduğunda bu, bir kişi hakkında yanlış bilgi üretmek anlamına gelir.

• Kişiler hakkında karar veren çıktılarda mutlaka bir insan onayı olsun.
• RAG kullanıyorsanız cevabın hangi kaynağa dayandığını gösterin.
• Gerçek örneklerden bir test seti hazırlayın ve model ya da istem değiştiğinde tekrar çalıştırın.

8. Yapay zekaya özgü güvenlik açıklarını test edin

Klasik güvenlik tedbirleri (yetkilendirme, çok faktörlü kimlik doğrulama, güvenli loglama, yama yönetimi) burada da geçerli. Bunlara ek olarak:

• Prompt injection: Model dışarıdan gelen bir içeriği (e-posta, belge, web sayfası) okuyorsa, içine gizlenmiş talimatlarla yönlendirilebilir. Modelin erişebildiği araçları ve verileri en aza indirin.
• Jailbreak: Kullanıcının, modelin kurallarını aşmaya çalışan istemlerine karşı test edin.
• Anahtar güvenliği: Model API anahtarları istemci tarafında (mobil uygulama, tarayıcı) bulunmamalı. Örneğin Lullai uygulamasında tüm yapay zeka çağrıları sunucuda çalışıyor; uygulamanın içinde anahtar yok.
• Etki değerlendirmesi: Yüksek riskli işlemelerde, canlıya almadan önce bir veri koruma etki değerlendirmesi yapın.

9. Çalışanların kullanımını unutmayın

Kurumların çoğunda ilk KVKK riski, geliştirilen bir yapay zeka ürününden değil, çalışanların müşteri verisini tüketiciye yönelik sohbet uygulamalarına yapıştırmasından geliyor. Bunu yasaklamak genellikle işe yaramıyor; daha etkili olan:

• Hangi araçların, hangi veriyle kullanılabileceğini anlatan kısa bir kurum içi politika.
• Çalışanlara, veri koşulları netleştirilmiş kurumsal bir araç sunmak.
• Kişisel verinin nasıl maskeleneceğine dair basit örnekler.

Kontrol listesi

1. Veri akışı haritası çıkarıldı: istem, bağlam, çıktı, kayıtlar, eğitim.
2. Modele giden kişisel veri en aza indirildi; gerekmeyen alanlar maskeleniyor.
3. Her faaliyet için hukuki sebep hukuk birimiyle belirlendi.
4. Model sağlayıcının veri işleme yeri, saklama süresi ve eğitim koşulları biliniyor; yurt dışı aktarım için güvence sağlandı.
5. Arayüzde yapay zeka kullanımı belirtiliyor, aydınlatmaya ulaşılabiliyor.
6. Kayıtlar, önbellek ve vektör veritabanı dahil verinin bulunup silinebildiği doğrulandı.
7. Kişiler hakkında sonuç doğuran çıktılarda insan onayı var.
8. Prompt injection ve jailbreak testleri yapıldı; API anahtarları sunucuda.
9. Gerekiyorsa veri koruma etki değerlendirmesi yapıldı.
10. Çalışanlar için yapay zeka kullanım politikası yayımlandı.

Sık sorulan sorular

Çalışanlar ChatGPT'ye müşteri verisi yapıştırabilir mi?

Bu, kurumun veri sorumlusu olarak yapacağı bir değerlendirmeye bağlı ve çoğu durumda yurt dışı aktarım sorusunu doğurur. Pratikte en güvenli yol, kişisel veriyi maskelemeden tüketiciye yönelik araçlara girmemek ve çalışanlara koşulları netleştirilmiş kurumsal bir araç sunmaktır.

Kullanıcıdan açık rıza almak yeterli mi?

Rehber, başka bir hukuki sebep varsa açık rızaya başvurulmaması gerektiğini söylüyor. Açık rıza, hukuki sebep değerlendirmesinin yerine geçen bir kısayol değildir; hangi sebebin uygun olduğunu hukuk biriminizle belirleyin.

Kişisel veri işleyen her yapay zeka projesi için yerli model mi kullanmak gerekir?

Zorunlu değil, ama en sade çözüm olabilir. Kişisel verinin modele gitmediği bir tasarım, yurt dışındaki güçlü modelleri kullanmanın önünü açar. Kişisel verinin gerçekten gerektiği işlerde ise Türkiye'de ya da kurumun kendi sunucusunda çalışan bir model değerlendirmeye değer.

Sonuç

KVKK rehberi, yapay zeka projelerini durdurmak için değil, doğru kurulmaları için yazılmış. Mimari açıdan çoğu tedbir aynı fikre dayanıyor: veriyi bil, gereğinden fazlasını gönderme, her adımı kaydet ve kişiler hakkında son kararı bir insana bırak.

Kamuda bu ilkelerin nasıl uygulanabileceğini kamuda yapay zeka entegrasyonu yazısında, ajanların getirdiği ek riskleri ise yapay zeka ajanları yazısında anlattım. Kendi projenizin veri akışını birlikte gözden geçirmek isterseniz yapay zeka ve otomasyon hizmetine göz atabilir ya da bana yazabilirsiniz.