Yapay Zeka Projelerinde Veri Gizliliği ve KVKK: Müşteri Verisini Bir LLM'e Güvenle Nasıl Verirsin?

Bir müşterin ya da patronun sana şunu söylediği an geliyor: "Destek taleplerimizi, sipariş geçmişimizi bir yapay zeka aracına bağlayalım, otomatik yanıtlasın." Kulağa basit geliyor. Ama tam o noktada durup sorman gereken bir şey var: bu müşteri verisini üçüncü taraf bir yapay zeka servisine göndermek KVKK açısından ne anlama geliyor? Yapay zeka projesinde veri gizliliği ve KVKK meselesi genelde proje yarı yoldayken, bir hukuk danışmanının ya da dikkatli bir müşterinin "bu veri nereye gidiyor?" sorusuyla gündeme geliyor. Oysa en başta doğru kurulursa hem daha ucuza geliyor hem çok daha az can sıkıcı oluyor.

##KVKK, bir yapay zeka projesinde neden ayrı bir risk katmanı oluşturuyor?

Normal bir yazılım projesinde veri genelde kendi sunucunda ya da bildiğin bir bulut sağlayıcıda (AWS, kendi VPS'in) kalır. Bir yapay zeka projesinde ise işin doğası gereği veriyi bir LLM API'sine — OpenAI, Anthropic, Google gibi — prompt olarak gönderiyorsun. Bu tek adım, KVKK açısından yeni bir kategori açıyor: yurt dışına veri aktarımı. KVKK'nın 9. maddesi bunu ayrı bir rejime tabi tutuyor; şirketin "veri sorumlusu", AI sağlayıcısı ise genelde "veri işleyen" konumunda oluyor ve aranızda bir veri işleme sözleşmesi (DPA) olması gerekiyor. Çoğu ekip bunu proje bittikten sonra fark ediyor, o noktada da mimariyi değiştirmek başlangıçta yapmaktan çok daha pahalı oluyor.

İkinci fark, loglama. Bir LLM'e gönderdiğin her prompt bir yerde geçici ya da kalıcı olarak tutulabilir — hata ayıklama, kalite kontrolü ya da (bazı tüketici ürünlerinde) model geliştirme amacıyla. Burada kritik ayrım şu: ChatGPT'nin web arayüzü gibi tüketici ürünleriyle, kurumsal API anlaşmaları çok farklı koşullara sahip olabilir. Kurumsal API'lerde genelde "sıfır veri saklama" (zero data retention) seçeneği ve modelin eğitiminde kullanılmama garantisi alabiliyorsun; tüketici arayüzüne gerçek müşteri verisi yapıştırmak ise bambaşka bir risk seviyesi.

##Somut risk: LLM'e çıplak göndermemen gereken veri

KVKK'nın 6. maddesi bazı veri türlerini "özel nitelikli kişisel veri" sayıyor ve bunlar için bar çok daha yüksek — çoğu durumda açık rıza şart. Bir yapay zeka projesinde farkında olmadan bu kategoriye giren veriyi prompt'a gömmek kolay oluyor, özellikle destek talepleri ya da serbest metin alanları söz konusu olduğunda (müşteri "ameliyat olacağım için teslimatı erteleyin" yazabilir — bu artık sağlık verisi).

• ▸TC kimlik numarası, pasaport ya da vergi kimlik no
• ▸Sağlık, dini inanç, cinsel yönelim gibi özel nitelikli veriler
• ▸Ödeme kartı numarası ya da tam banka bilgisi
• ▸Biyometrik veri (yüz, parmak izi, ses örneği)
• ▸İsim + adres + telefon üçlüsünün birlikte, maskesiz gönderilmesi

Son madde önemli çünkü tek başına zararsız görünen veriler bir araya geldiğinde kişiyi yeniden tanımlanabilir (re-identification) hale getirebiliyor. Ayrıca prompt injection riskini de unutma: bir kullanıcı sisteme özel talimatlar sızdırmaya çalışırsa ve senin sistem prompt'un başka bir müşterinin verisini içeriyorsa, bu veri sızıntısına dönüşebilir. Bu yüzden "hangi veriyi gönderiyorum" sorusu kadar "modelin başka bir bağlamda bu veriyi geri sızdırabilir mi" sorusu da önemli.

##Veriyi güvenle kullanmanın beş pratik yolu

• ▸Veri minimizasyonu: LLM'e sadece görevi için gereken alanı gönder, tüm müşteri kaydını değil.
• ▸Maskeleme / pseudonimleştirme: gerçek isim yerine 'Müşteri #4821' gibi bir referans kodu gönder, eşleştirme tablosunu kendi sisteminde tut.
• ▸Sıfır veri saklama (zero retention) anlaşmalı kurumsal API kullan, tüketici arayüzü değil.
• ▸Gerçekten hassas veri (sağlık, finans) için self-hosted / on-prem bir modeli değerlendir — maliyeti yüksek ama tam kontrol sağlar.
• ▸Aydınlatma metnini güncelle: müşteri, verisinin yapay zeka ile işlenebileceğini açıkça görsün.

Bu beş yöntem tek başlarına değil, birlikte iş görüyor — savunma katmanları gibi düşün. Maskeleme, sağlayıcı bir hata yapıp veriyi loglasa bile gerçek kişiyi korur; sözleşme, hukuki sorumluluğu netleştirir; aydınlatma metni ise KVKK'nın en temel şartını (madde 10) karşılar. Çoğu SaaS ya da perakende projesi için on-prem model gerekmez — maskeleme + kurumsal API + doğru sözleşme kombinasyonu yeterli oluyor.

##Gerçek bir senaryo: online mobilya mağazasının destek asistanı

Orta ölçekli bir online mobilya mağazası, günde yüzlerce destek talebini otomatik yanıtlayan bir yapay zeka asistanı kurmak istiyor: 'siparişim nerede', 'ürünü değiştirmek istiyorum' gibi tekrar eden sorular. Mimari şöyle kuruluyor: sipariş verisi ve müşteri kaydı hep kendi veritabanlarında kalıyor. LLM'e gönderilmeden önce bir maskeleme katmanı devreye giriyor — isim, telefon, adres gibi alanlar otomatik olarak referans koduna çevriliyor. Model sadece şunu görüyor: 'Müşteri #4821, sipariş #98213, ürün: üç kişilik kanepe, şikayet: teslimat 5 gün gecikti.' Kişisel veri modelin gördüğü metinde hiç geçmiyor.

Modelin ürettiği yanıt, gönderilmeden önce kendi sisteminde gerçek isimle otomatik olarak birleştiriliyor — müşteri, cevabı normal şekilde alıyor, aradaki anonimleştirme adımını hiç görmüyor. Kullanılan API sağlayıcısıyla sıfır veri saklama maddesi içeren bir sözleşme imzalanmış durumda; aydınlatma metni güncellenmiş ve müşteri, destek sürecinde yapay zeka kullanılabileceği bilgisini görüyor. Sonuçta destek yanıt süresi kısalıyor ama hiçbir gerçek kişisel veri, sağlayıcının sunucularında çıplak halde durmuyor.

##Sık Sorulan Sorular

>ChatGPT ya da benzer bir araca müşteri verisi yapıştırmak KVKK'ya aykırı mı?

Otomatik olarak 'yasak' demek doğru değil ama yüksek riskli. Tüketici arayüzlerinin veri saklama ve kullanım koşulları genelde kurumsal API'lerden farklı ve daha az şeffaf olabiliyor. Gerçek müşteri verisini doğrudan yapıştırmak yerine, kurumsal API + sıfır veri saklama sözleşmesi + maskeleme kombinasyonunu kullanmak çok daha savunulabilir bir pozisyon.

>Maskeleme (pseudonimleştirme) tek başına yeterli mi, açık rıza da gerekir mi?

Pseudonimleştirme, eşleştirme tablosu elinde olduğu için tam anonimleştirme sayılmıyor — bu yüzden KVKK yükümlülüklerini tamamen ortadan kaldırmıyor, ama riski ciddi ölçüde azaltıyor. Özel nitelikli veri (sağlık, biyometrik vb.) söz konusuysa açık rıza ya da başka bir hukuki dayanak neredeyse her zaman gerekiyor.

>Yurt dışındaki bir yapay zeka sağlayıcısını kullanmak otomatik olarak veri aktarımı sayılır mı?

Evet. Veri, sağlayıcının sunucusuna ulaştığı an KVKK'nın yurt dışına aktarım hükümleri devreye giriyor ve uygun bir aktarım mekanizması (taahhütname, açık rıza ya da Kurul'un öngördüğü diğer yollar) gerekiyor. Bu yüzden sözleşme ve aydınlatma metni işi, proje canlıya çıkmadan önce bitmiş olmalı — sonradan eklemek çok daha zor.

>Küçük bir işletme için on-prem model çalıştırmak gerekli mi?

Çoğu zaman hayır. On-prem/self-hosted model; donanım, bakım ve uzmanlık gerektirdiği için maliyeti genelde kurumsal API kullanmaktan yüksek çıkıyor. Gerçekten çok hassas veri işleniyorsa (sağlık, kamu, finans) ya da müşteri sözleşmesi bunu açıkça şart koşuyorsa mantıklı; aksi halde maskeleme + doğru sözleşmeli kurumsal API çoğu proje için yeterli.

Bunu proje başlamadan önce netleştirmek, canlıya çıktıktan sonra mimariyi baştan kurmaktan her zaman daha ucuza geliyor. LLM'lerin token ve context window seviyesinde nasıl çalıştığını merak ediyorsan ilgili yazıya bakabilirsin; kendi projen için bu katmanı nasıl kuracağını konuşmak istersen buradayım.