Yapay Zekâda Veri Gizliliği ve KVKK Uyumu: Müşteri Verisi Modele Giderken Neler Yapılmalı?

Yapay zekâ özelliği eklediğinizde müşteri verisi, modeli sunan sağlayıcıya giden metnin içinde yolculuk eder; KVKK açısından asıl soru da bu yolculuğun hukuki ve teknik olarak kontrol altında olup olmadığıdır. Bu yazıda hangi verinin dışarı çıktığını, KVKK'nın hangi yükümlülüklerinin devreye girdiğini ve bunu üretimde nasıl güvenceye aldığımızı sırayla anlatıyoruz.

Yapay zekâya gönderilen veri tam olarak nereye gider?

Bir LLM'e (büyük dil modeli, yani metni anlayıp metin üreten yapay zekâ) soru sorduğunuzda, soru ve eklediğiniz bağlam bir API (yazılımların birbiriyle konuştuğu arayüz) üzerinden sağlayıcının sunucularına gönderilir, işlenir ve cevap geri döner. Yani verdiğiniz her metin parçası, o anlık da olsa üçüncü bir tarafın altyapısında işlenir.

Burada akılda tutulması gereken ayrım şudur: işlenmek, saklanmak ve eğitimde kullanılmak üç ayrı şeydir. Kurumsal API planlarında girdilerin model eğitiminde kullanılmaması genellikle sözleşmeyle güvence altındadır; ancak bunu varsaymak yerine sağlayıcının güncel şartlarından teyit etmek gerekir. Ücretsiz tüketici sohbet uygulamalarında ise koşullar çok farklı olabilir.

Son satır sık atlanır: sağlayıcı hiçbir şey saklamasa bile kendi uygulamanızın günlükleri ham müşteri yazışmalarını yıllarca tutabilir. Bu da ayrı bir KVKK yükümlülüğüdür.

KVKK yapay zekâ kullanımında hangi yükümlülükleri getiriyor?

6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), yapay zekâya özel bir bölüm içermez; ama kişisel veri işleyen her sistem gibi yapay zekâ özelliği de aynı çekirdek yükümlülüklere tabidir. Pratikte dört tanesi öne çıkar:

• Aydınlatma: Kullanıcıya verisinin hangi amaçla, kimlere aktarılarak işlendiğini söylemek. Yapay zekâ sağlayıcısı alıcı grubu olarak metinde yer almalıdır.
• Hukuki sebep ve amaçla sınırlılık: Veriyi yalnızca toplandığı amaçla, gerektiği kadar işlemek. Destek talebi için alınan veriyi sessizce başka bir yapay zekâ projesine beslemek bu ilkeyle çelişir.
• Güvenlik: Erişim kontrolü, şifreleme ve yetki ayrımı gibi makul teknik ve idari tedbirler. Sağlayıcıyla yapılan sözleşme bu tedbirleri de kapsamalıdır.
• Yurt dışına aktarım: Çoğu model sağlayıcısı Türkiye dışında çalıştığı için, 2024'te yenilenen aktarım rejimi (yeterlilik kararı, uygun güvenceler ve istisnalar) bu noktada doğrudan devreye girer.

Veri sorumlusu olarak ilgili yükümlülüklerin sahibi sizsiniz; sağlayıcı veri işleyen konumundadır. Sorumluluğu sağlayıcıya devrettiğinizi düşünmek en yaygın yanlıştır. Hukuki yorum gerektiren noktalarda mutlaka KVKK konusunda uzman bir avukattan görüş alın; bu yazı hukuki danışmanlık değildir.

Hangi veriyi yapay zekâya hiç göndermemelisiniz?

Gönderilmeyecek veri sınıfını baştan tanımlamak, sonradan yama yapmaktan çok daha kolaydır. Kanunda 'özel nitelikli' sayılan sağlık, biyometrik, din, sendika üyeliği ve ceza mahkûmiyeti gibi veriler daha sıkı korunur; bunları dış bir modele göndermeden önce çok daha güçlü bir gerekçeniz ve sözleşme güvenceniz olmalıdır.

Bunun dışında kimlik numarası, tam adres, IBAN ve kart bilgisi gibi alanlar çoğu yapay zekâ işi için zaten gereksizdir. Bir destek yazışmasını özetlemek için müşterinin T.C. kimlik numarasına ihtiyaç yoktur. Soru şu olmalı: bu iş, bu alan olmadan yapılabilir mi? Çoğu zaman cevap evettir.

Kişisel veri yapay zekâya gitmeden önce nasıl maskelenir?

Maskeleme (anonimleştirme), kişisel alanların modele gitmeden önce yer tutucularla değiştirilmesidir. Örneğin 'Ayşe Yılmaz, 0532...' ifadesi 'KİŞİ_1, TELEFON_1' olarak gönderilir; cevap döndüğünde yer tutucular kendi sisteminizde gerçek değerlerle geri doldurulur. Model gerçek kimliği hiç görmez, ama cevabın anlamı bozulmaz.

Üretimde bunu üç katmanla kurarız:

1. Kural tabanlı yakalama: Telefon, e-posta, IBAN ve kimlik numarası gibi biçimi belli alanlar düzenli ifadelerle yakalanır. Hızlıdır ve öngörülebilirdir.
2. Kişi ve kurum adı tespiti: Serbest metindeki adlar için ayrı bir tanıma adımı çalışır. Kural tabanlıdan daha az kesindir, bu yüzden örnek bir veri kümesiyle ölçülür.
3. Çıkış kontrolü: Modelin cevabında maskelenmemiş veri sızıp sızmadığına bakılır ve şüpheli cevaplar insan onayına düşer.

Maskeleme kusursuz değildir; bu yüzden tek başına güvence sayılmaz. Sözleşme, erişim kontrolü ve kayıt politikasıyla birlikte çalışan bir katmandır. Özellikle serbest metin alanlarında tespit kaçabilir; bu nedenle maskeleme başarısını da diğer her şey gibi düzenli ölçmek gerekir, tıpkı yapay zekâ çıktısının kalitesini ölçtüğümüz gibi.

Sağlayıcıyla sözleşmede neyi kontrol etmelisiniz?

Sözleşme ve veri işleme ekini imzalamadan önce beş başlığa bakmak yeterli bir ilk eleme sağlar. Aşağıdaki tablo, kontrol listemizin özetidir.

Hassas senaryolarda bir alternatif daha vardır: açık ağırlıklı bir modeli kendi altyapınızda çalıştırmak. Bu durumda veri hiçbir üçüncü tarafa çıkmaz, karşılığında model kalitesi, işletme yükü ve donanım gereksinimi sizin tarafınızda olur. Karar çoğu zaman veri hassasiyeti ile kalite arasında bir denge meselesidir; her iş için en küçük yeterli modeli seçme yaklaşımı burada da geçerlidir.

Kendi verinizle çalışan sistemlerde yetki nasıl korunur?

Şirket dokümanları üzerinde arama yapan yapay zekâ sistemleri (RAG) için ek bir risk vardır: yetkisiz kullanıcının, yetkisi olmadığı belgeden cevap alması. Maaş tablosu ve genel izin politikası aynı arama indeksinde duruyorsa, model ikisini de bulabilir.

Çözüm, yetki kontrolünü modele bırakmamaktır. Her doküman parçası, kimin görebileceği bilgisiyle indekslenir ve arama kullanıcının yetkisine göre filtrelenir; model yalnızca zaten görmeye hakkı olan parçaları görür. Bu mantık, web uygulamalarındaki rol tabanlı yetkilendirme ile birebir aynı ilkeye dayanır. Vektör veritabanı tarafındaki seçenekleri pgvector yazımızda anlattık.

Silme talepleri de aynı yerden çıkar: bir kullanıcı verisinin silinmesini istediğinde, o kişiye ait parçaların hem ana tablodan hem arama indeksinden hem de önbellekten kaldırılabildiğinden emin olmalısınız. Yalnızca ana kaydı silmek, veriyi indekste yaşatmaya devam eder.

Bir yapay zekâ projesine başlamadan önce kontrol listesi

Aşağıdaki sorulara cevap veremiyorsanız, proje kodlamaya geçmeden önce veri akışının çizilmesi gerekir:

• Modele hangi alanlar gidiyor ve hangileri gerçekten gerekli?
• Aydınlatma metniniz yapay zekâ sağlayıcısını alıcı olarak anıyor mu?
• Sağlayıcı sözleşmesinde eğitim, saklama ve konum maddeleri net mi?
• Yurt dışına aktarım için dayanağınız belirlendi mi?
• Uygulama günlükleri ham kişisel veri tutuyor mu, ne kadar süreyle?
• Silme talebi geldiğinde indeks ve önbellekten de temizleniyor mu?
• Kritik çıktılar insan onayından geçiyor mu?

Bu liste bir hukuk görüşünün yerine geçmez; ama teknik tarafın hazırlığını hızla ortaya çıkarır. Aynı başlıkların büyük kısmını mobil tarafta da yaşarsınız: mobil uygulamada KVKK ve veri beyanı yazımız, aydınlatma ve izin akışı için tamamlayıcı bir okumadır.

Nereden başlamalı?

Önce tek bir kullanım senaryosu seçin ve o senaryoda hangi verinin modele gittiğini bir sayfaya çizin. Ardından gereksiz alanları çıkarın, kalanları maskeleyin, sözleşmeyi kontrol edin ve kayıt politikasını belirleyin. Bu sıra, projeyi sonradan durduracak sürprizlerin çoğunu en başta ortaya çıkarır.

Sürecin tamamını, veri hazırlığından değerlendirme setine kadar yapay zekâ entegrasyonu hizmetimiz kapsamında yürütüyoruz. Kendi senaryonuzu konuşmak için bizimle iletişime geçebilirsiniz. Kapsamın maliyete etkisini merak ediyorsanız yazılım projesi maliyeti yazımıza göz atın.