KVKK Uyumlu Yapay Zeka: Kişisel Veriyle AI Kullanım Rehberi

Sorun: AI kullanmak istiyoruz, verimiz kişisel

Türkiye'de kurumsal yapay zeka projelerinin önündeki bir numaralı tereddüt teknik değil, hukuki: "Müşteri verimizi bir AI modeline verirsek KVKK'ya aykırı mı davranmış oluruz?" Sorunun cevabı "evet" ya da "hayır" değil; hangi verinin, hangi mimariyle, hangi güvencelerle işlendiğine bağlı. Bu rehber; veri sınıflandırmadan yurt dışına aktarıma, on-premise mimariden uyum kontrol listesine, kararı verilebilir hale getiren pratik çerçeveyi veriyor.

Not: Bu yazı bilgilendirme amaçlıdır ve hukuki danışmanlık yerine geçmez; somut durumlar için KVKK uzmanı bir hukukçuyla çalışılmalıdır. Dayanak: 6698 sayılı Kişisel Verilerin Korunması Kanunu ↗

1. adım: Veriyi sınıflandırın — ne buluta çıkabilir, ne kurumda kalmalı?

KVKK uyumlu AI mimarisinin temeli, modele hangi verinin gideceğini baştan sınıflandırmaktır. Tipik bir sınıflandırma şöyle görünür:

Bu sınıflandırma yalnız AI projesi için değil, genel veri güvenliği için de gereklidir; teknik tarafını DLP ve veri sınıflandırma çözüm sayfasında ele alıyoruz. Ana sayfadaki dört adımlı kurumsal AI yol haritasının 2. adımı da tam olarak budur: senaryonun verisini envantere alın, hangi veri hassas — KVKK gözüyle baştan sınıflandırın.

2. adım: Bulut AI = çoğu zaman yurt dışına veri aktarımı

Gözden kaçan gerçek şudur: ChatGPT, Gemini veya benzeri bir bulut AI API'sine kişisel veri gönderdiğinizde, bu veri çoğu durumda yurt dışındaki sunucularda işlenir — yani KVKK m.9'daki yurt dışına veri aktarımı rejimine girersiniz. 2024'te yenilenen m.9'a göre aktarım üç mekanizmadan biriyle yapılabilir:

• Yeterlilik kararı: Kurulun, ilgili ülke/sektör için yeterli koruma bulunduğuna karar vermiş olması.
• Uygun güvenceler: Pratikte en yaygın yol — Kurumca ilan edilen standart sözleşmenin imzalanması (ve süresinde Kuruma bildirilmesi), bağlayıcı şirket kuralları veya taahhütname.
• Arızi (istisnai) haller: Açık rıza dahil, yalnızca tek seferlik/istisnai durumlar için öngörülen haller.

Bunun pratikteki anlamı: "API anahtarı aldık, bağladık" bir uyum stratejisi değildir. Sağlayıcı sözleşmenizde verinin nerede işlendiği, eğitimde kullanılıp kullanılmadığı ve aktarım güvencesi maddelerinin bulunması gerekir. KVKK Kurumunun kendi yayınları da bu çerçeveyi esas alır: Yapay Zekâ Alanında Kişisel Verilerin Korunmasına Dair Tavsiyeler (Kaynak: KVKK Kurumu ↗) ve üretken AI'a özel Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi — 15 Soruda (Kaynak: KVKK Kurumu ↗). Tavsiyelerin ortak ilkeleri: veri minimizasyonu, tasarımdan itibaren gizlilik (privacy by design), amaçla sınırlılık ve hesap verebilirlik.

3. adım: Mimari çözüm — on-premise ve hibrit

Aktarım sorununun en kestirme mimari çözümü, modeli verinin ayağına getirmektir: açık kaynak bir LLM (Llama, Qwen, Mistral vb.) kurumun kendi sunucusunda, vLLM gibi bir çıkarım motoruyla çalıştırılır; vektör veritabanı (pgvector/Qdrant) kurum içinde tutulur; uygulama katmanı OpenAI-uyumlu bir ağ geçidi (LiteLLM vb.) üzerinden konuşur. Böylece veri ağ sınırından dışarı çıkmaz.

Çoğu kurum için gerçekçi cevap ise hibrittir: KVKK-hassas akışlar kurum içi modelle, hassas olmayan genel işler bulut API ile işlenir; yönlendirmeyi veri sınıfı belirler. Bu mimarinin kurulumunu kurumsal LLM & RAG çözüm sayfasında, donanım ve işletme maliyetini ise on-premise LLM maliyet analizinde ayrıntılı anlattık. RAG mimarisinin KVKK açısından önemli bir yan faydası vardır: belgeler modele gömülmez, sorguyla ilgili pasajlar anlık bağlam olarak verilir — erişim kontrolü belge düzeyinde uygulanabilir ve "kim neye erişti" loglanabilir.

Uyum kontrol listesi

Bir AI projesini KVKK gözüyle yayına hazırlarken asgari kontrol listesi:

1. Veri sınıflandırması: Modele giden her alanın sınıfı belli mi? Özel nitelikli veri akışta var mı?
2. Hukuki dayanak: İşleme m.5/m.6'daki hangi şarta dayanıyor? "Herkes kullanıyor" bir dayanak değildir.
3. Aydınlatma: Aydınlatma metni AI ile işlemeyi, amaçları ve varsa yurt dışına aktarımı kapsıyor mu? Kullanıcı bir AI ile etkileşimde olduğunu biliyor mu?
4. Envanter ve VERBİS: Yeni işleme faaliyeti kişisel veri envanterine ve (yükümlüyseniz) VERBİS kaydına yansıdı mı?
5. Aktarım mekanizması: Bulut API kullanılıyorsa standart sözleşme/uygun güvence kurulup bildirimi yapıldı mı?
6. Veri işleyen sözleşmesi: Sağlayıcıyla verinin eğitime kullanılmaması (zero-retention), saklama süresi ve silme taahhütleri sözleşmede mi?
7. Ön risk değerlendirmesi: Yüksek riskli işleme için proje öncesi etki değerlendirmesi (DPIA benzeri) yapıldı mı?
8. Erişim ve log: Kim hangi veriye/yanıta erişti — denetlenebilir iz kaydı (audit log) tutuluyor mu? Saklama süresi dolan veri siliniyor mu?

Sonuç: KVKK engel değil, mimari gereksinim

KVKK, yapay zeka kullanmanın önünde bir duvar değil; mimariyi baştan doğru kurduran bir gereksinim setidir. Veri sınıflandırması yapılmış, aktarım mekanizması kurulmuş, hassas akışları kurum içinde tutan bir sistem hem hukuken savunulabilir hem de operasyonel olarak sürdürülebilirdir. Biz geliştirdiğimiz her sistemde bu yaklaşımı baştan kurarız: kaynak kodu, model kurgusu ve veri sizin — veriniz nerede işleneceğine siz karar verirsiniz. Kendi senaryonuzu konuşmak için talep formunu kullanabilirsiniz.