LLM API'leri ve yurt dışına veri aktarımı: kurumsal karar çerçevesi

Kurumsal yapay zekâ görüşmelerinin belirli bir anında aynı soru gelir: "Biz bu verileri OpenAI'ın ya da bir başkasının sunucusuna göndermiş olmuyor muyuz?" Cevap çoğu zaman evet — ve sorunun kendisi doğrudur. Ama arkasından gelen "o zaman kullanamayız" sonucu, kararın yalnızca yarısıdır.

Bu yazıda konuyu hukuki bir metin olarak değil, mimari karar çerçevesi olarak ele alıyoruz: veri tam olarak nereye gidiyor, hangi zeminler mevcut, hangi mimari hangi senaryoda doğru.

Bir LLM API çağrısında yurt dışına tam olarak ne gidiyor?

Soruyu doğru kurmak için önce teknik gerçeği görmek gerekir. Bulut tabanlı bir büyük dil modeline yapılan istek şunları taşır:

1. İstem (prompt) metninin tamamı — kullanıcının yazdığı her şey.
2. Sistem talimatı — uygulamanın modele verdiği bağlam; içinde kurum politikaları, rol tanımları, bazen örnek veriler bulunur.
3. Bağlam olarak eklenen belgeler — RAG mimarisinde arama sonucu bulunan doküman parçaları istekle birlikte gider. Bu, çoğu kurumun gözden kaçırdığı kalemdir: asıl hacimli kişisel veri burada taşınır.
4. Konuşma geçmişi — çok turlu senaryolarda önceki mesajlar her turda yeniden gönderilir.
5. Meta veri — istek zamanı, kullanılan model, token sayıları, çoğu zaman bir kullanıcı ya da oturum tanımlayıcısı.

Bu listede kişisel veri varsa — bir çalışan adı, bir müşteri numarası, bir epikriz metni, bir sözleşmedeki taraf bilgisi — o çağrı KVKK anlamında yurt dışına veri aktarımıdır. Aracın "sohbet" gibi görünmesi bu niteliği değiştirmez.

Gözden kaçan iki nokta:

• RAG kurulumlarında aktarım hacmi beklenenden büyüktür. Kullanıcı tek cümlelik bir soru sorar; sistem arka planda beş belge parçasını isteğe ekler. Aktarılan veri, kullanıcının yazdığının onlarca katıdır.
• Gölge kullanım ölçülemez. Kurumsal bir kanal yoksa çalışanlar bireysel hesaplarla aynı işi yapar. Bu durumda aktarım yine gerçekleşir, ama kurum ne olduğunu bilmez ve denetleyemez. Yasak, gölge kullanımı ortadan kaldırmaz; yalnızca görünmez yapar.

KVKK yurt dışına aktarımı hangi zeminlerde mümkün kılıyor?

Kişisel verilerin yurt dışına aktarımı 6698 sayılı Kanun'un 9. maddesinde düzenlenir ve 2024'teki değişiklikle kademeli bir yapıya kavuşmuştur. Kabaca üç katman vardır:

Açık rızaya dayanmanın sorunu, hukuken geçersiz olması değil, sürdürülemez olmasıdır. Rıza her zaman geri alınabilir; geri alındığında o kişinin verisiyle çalışan sistemin ne yapacağı önceden tasarlanmış olmalıdır. Binlerce çalışan ya da müşteri için rıza yönetmek, üstelik rızası olmayanlar için ayrı bir akış işletmek, çoğu kurumda operasyonel olarak çöker. Bu yüzden sürekli çalışan sistemlerde rıza, ana zemin değil tamamlayıcı zemindir.

Özel nitelikli veride neden farklı davranmak gerekir?

Sağlık verisi, biyometrik veri, ceza mahkûmiyeti, sendika üyeliği gibi özel nitelikli veriler daha dar bir işleme rejimine tabidir. Yurt dışına aktarımda bu darlık katlanarak artar: hem aktarım zemini hem de veri güvenliğine ilişkin ek tedbirler gerekir.

Pratikte bu, şu ayrımı doğurur:

• Genel nitelikli kişisel veri için maskeleme + uygun güvence temelli bir bulut mimarisi çoğu zaman kurulabilir.
• Özel nitelikli veri için varsayılan tercih kurum içi ya da kontrollü özel bulut olmalıdır. Bulut API'si üzerinden aktarım, ancak veri gerçekten anonimleştirilmişse ya da güçlü bir zemin ve ek tedbir seti varsa masaya gelir.

Aynı mantık, kişisel veri olmasa bile meslek sırrı niteliğindeki içerik için de geçerlidir: hukuk bürolarında müvekkil dosyası, sağlıkta hasta kaydı, savunma sanayiinde teknik doküman. KVKK dışında ayrı gizlilik yükümlülükleri devrededir ve bunlar "kişisel veri değil" argümanıyla aşılamaz.

"Verinizi eğitimde kullanmıyoruz" taahhüdü nereye kadar yeter?

Kurumsal API planlarında model sağlayıcıları genellikle isteklerin model eğitiminde kullanılmayacağını taahhüt eder. Bu anlamlı bir taahhüttür ve riski azaltır — ama üç şeyi çözmez:

1. Aktarımın kendisini ortadan kaldırmaz. Veri yine sınır dışındaki bir sunucuda işlenmiştir. KVKK'nın ilgilendiği an, eğitim anı değil işleme anıdır.
2. Saklama süresini kendiliğinden sıfırlamaz. Kötüye kullanım denetimi için isteklerin bir süre saklandığı yaygın bir uygulamadır; süre ve koşullar sözleşmeden okunmalıdır.
3. Alt işleyicileri görünür kılmaz. Sağlayıcının kendi altyapı tedarikçileri de zincire dahildir; veri hangi ülkelerde işleniyor sorusunun cevabı çoğu zaman tek bir ülke değildir.

Doğru okuma şudur: bu taahhüt, aktarım zemininizi destekleyen bir güvencedir; zeminin yerine geçen bir şey değildir.

Dört mimari seçenek ve hangisi ne zaman doğru?

Kararı hukuk masasından mimari masasına taşıdığınızda seçenek dörde iner.

Uygulamada en sık kurduğumuz yapı üçüncüsüdür ve nedeni pragmatiktir: bir kurumun tüm senaryoları aynı hassasiyette değildir. Pazarlama metni yazan kullanıcıyla bordro itirazı inceleyen kullanıcı aynı modele gitmek zorunda değildir.

Hibrit mimarinin çalışması için üç bileşen gerekir:

1. Sınıflandırma — istek, kişisel veri içerip içermediğine göre etiketlenir. Bu, kullanıcıya sorularak değil, otomatik yapılır; kullanıcı doğru kararı vermek zorunda bırakılmaz.
2. Yönlendirme — etikete göre model seçilir. Kurum içi model daha küçük olabilir; bu senaryolarda gereken çoğu zaman en büyük model değildir.
3. Kayıt — hangi isteğin hangi modele gittiği denetlenebilir biçimde tutulur. "Hassas veri dışarı çıkmadı" bir iddia değil, raporlanabilir bir olgu hâline gelir.

Aktarımı azaltan altı teknik önlem

Zemin tartışmasından bağımsız olarak, aktarılan kişisel veri miktarını düşüren her önlem riski doğrudan düşürür. Veri minimizasyonu ilkesinin mimarideki karşılığı budur:

1. Alan bazlı maskeleme — ad, TCKN, telefon, adres gibi alanlar isteğe girmeden önce yer tutucuyla değiştirilir; cevap dönerken geri yazılır.
2. Bağlam budama — RAG'de bulunan belge parçalarından soruyla ilgisiz kişisel alanlar temizlenir. En büyük kazanç genellikle buradadır.
3. Alan seçimi — modele tüm kayıt değil, işi görecek alanlar gönderilir. "Her ihtimale karşı hepsini gönderelim" en pahalı alışkanlıktır.
4. Özetleme öncesi yerel işlem — hacimli belgelerde ilk indirgeme kurum içinde yapılır; dışarıya yalnız özet gider.
5. Konuşma geçmişinin sınırlanması — her turda tüm geçmişi göndermek yerine ilgili bölüm taşınır.
6. Kullanıcı tanımlayıcılarının vekilleştirilmesi — sağlayıcıya gönderilen kimlik, gerçek kullanıcı kimliği değil bir vekil değişken olur.

Karar verirken sorulacak sekiz soru

Bir senaryoyu masaya koyduğunuzda sırayla şunları cevaplayın. Cevaplar mimariyi kendiliğinden daraltır:

1. Bu senaryoda modele giden içerikte kişisel veri var mı — ve hangi alanlarda?
2. Bu veri özel nitelikli mi?
3. Kişisel veri, işi bozmadan maskelenebilir mi? Maskelenirse cevabın kalitesi ne kadar düşüyor?
4. Hangi aktarım zeminine dayanacağız; o zeminin gerektirdiği belgeler hazır mı?
5. Sağlayıcının saklama süresi, alt işleyicileri ve işleme lokasyonları sözleşmede yazılı mı?
6. Bu senaryoda gerçekten en büyük model mi gerekli, yoksa kurum içinde çalışabilecek bir model yeterli mi? (Cevap ölçümle verilir, kanıyla değil.)
7. Aktarımın gerçekleştiğini ve kapsamını sonradan kanıtlayabilecek bir kaydımız olacak mı?
8. Rıza zeminine dayanıyorsak, rıza geri alındığında sistem ne yapacak?

Bu sekiz sorunun altısına net cevap veremiyorsanız sorun mimaride değil, veri envanterindedir — ve oradan başlamak gerekir.

Toparlarken

"LLM API'si kullanmak KVKK'ya aykırı mı?" sorusunun cevabı evet ya da hayır değil, hangi veriyle, hangi zeminle ve hangi mimariyle sorusudur. Kurumların çoğu için en sağlam yol, tek bir hukuki zemine tüm ağırlığı yüklemek yerine aktarılan kişisel veriyi mimariyle azaltmak, hassas senaryoları kurum içinde tutmak ve olan biteni denetlenebilir kılmaktır.

Verinin hiç çıkmaması gereken senaryolarda kurulum mantığını KVKK'ya uygun yapay zekâ yazımızda, kurum içi bilgiyle çalışan asistan mimarisini ise RAG yazımızda ayrıntılandırdık.

On-premise ve KVKK uyumlu AI hizmetimizi inceleyin