Bir dil modeli kullandığınızda verileriniz nereye gider?

Bir yapay zeka asistanı kullanıldığında verinin nereye gittiğini sorduğunuzda alışılmış yanıt “model sağlayıcıya” olur. Oysa bu, daha uzun bir yolculuğun yalnızca bir durağıdır. Tek bir soru, sağlayıcının kayıtlarında, uygulama kayıtlarınızda, bir iz kaydı (trace) aracında, arama dizininde, önbellekte ve daha sonra da birinin gerçek vakalardan oluşturduğu bir test setinde kopya bırakabilir.

LLM veri gizliliğinde işe yarayan birim sağlayıcı değil, adımdır. Her adımı haritalayın, her biri için sözleşmeyi ve ayarları kontrol edin, tasarımı da en hassas veri hiç yola çıkmayacak şekilde kurun.

Biri bir soru sorduğunda sistemlerinizden ne çıkar?

Hasarlı bir teslimatla ilgili temsili bir müşteri e-postasının, yanıt taslağı hazırlayan bir asistandaki yolculuğunu izleyelim.

1. E-posta, müşterinin adı, adresi, sipariş numarası ve hasarın tarifiyle birlikte destek talebi sistemine düşer.
2. Asistan siparişi sipariş sisteminde sorgular: ürünler, tutarlar, teslimat durumu.
3. İade politikasında arama yapar ve üç bölüm getirir. Dizin geçmiş destek taleplerinden de oluşturulduysa başka müşterilerin yazdıklarını da getirebilir.
4. Talimatlarından, e-postadan, sipariş alanlarından ve bu bölümlerden bir prompt oluşturur ve onu sağlayıcının belirli bir bölgedeki uç noktasına gönderir.
5. Sağlayıcı bir taslak döndürür. Sözleşmeye bağlı olarak promptu ve taslağı bir süre, örneğin kötüye kullanım izlemesi için saklayabilir.
6. Uygulamanız tam promptu ve taslağı kaydeder; çoğu zaman başka bir şirketin hizmeti olan bir iz kaydı aracı da hata ayıklama için bir kopya alır.
7. Temsilci yanıtı düzenleyip gönderir. Daha sonra biri vakayı bir değerlendirme setine kopyalar.

Bunların hiçbiri olağan dışı değildir. Yalnızca sonradan fark edilmek yerine önceden kararlaştırılması gerekir. Her akışta aynı adımlar vardır:

Bir model sağlayıcı genellikle neyi, ne kadar süre saklar?

Yanıt ürüne, özelliğe ve sözleşmeye bağlıdır ve zamanla değişir. Bu yüzden her genel yanıtı, bu yanıt da dahil, kontrol etmeniz için bir işaret sayın. Karşılaşacağınız kalıplar şunlardır: kötüye kullanım izlemesi için sınırlı bir süre tutulan girdiler ve çıktılar, bazı kurumsal müşteriler için kısaltılmış ya da sıfır saklama ve siz silene kadar saklanan dosyalar, konuşma geçmişleri ve ince ayar verileri.

Her sağlayıcıya yazılı olarak sorun:

• Saklama: kullandığınız her özellik için ne, ne kadar süre saklanıyor ve bu süreyi kısaltabilir misiniz?
• Eğitimde kullanım: verilerinizin herhangi bir kısmı, varsayılan olarak ya da herhangi bir koşulda, bir modeli eğitmek veya iyileştirmek için kullanılıyor mu?
• Bölge: kötüye kullanım incelemesi ve destek dahil, istekler nerede işleniyor ve saklanıyor?
• Alt veri işleyenler: veriyi başka kimler, nerede işliyor ve değişikliklerden nasıl haberdar olacaksınız?
• Silme: saklanan veri nasıl silinir, bu ne kadar sürer ve silme nasıl teyit edilir?

Sistemlerinizin içinde kalan ama yine de korunması gereken ne var?

Kontrolü sizde olan adımlar çoğu zaman en zayıf halkadır, çünkü gizlilik için değil, hata ayıklama için kurulmuşlardır.

• Kayıtlar ve iz kayıtları çoğu zaman tam promptları ve çıktıları tutar; bunları destek talebi sisteminin kendisinden daha fazla kişi okuyabilir. Maskeleyebildiğinizi maskeleyin, mümkün olan yerde kopya yerine referans tutun ve bir saklama süresi belirleyin.
• Arama dizinleri metni ve embedding’leri, yani aramada kullanılan ve metnin anlamını sayılarla temsil eden vektörleri tutar. Embedding’ler metinden türetilir; onları metin kadar koruyun ve silmenin onlara da ulaştığından emin olun.
• Yanıtları saklayan önbellekler, kullanıcıya göre ayrılmamışsa bir kişinin yanıtını başka birine sunabilir; bu, yapay zeka asistanlarında erişim kontrolünün kapatması gereken türden bir açıktır.
• Değerlendirme setleri gerçek vakaların kopyalarıdır ve çoğu zaman hesap tablolarında durur. Onlara bir sahip ve erişim rolleri verin, mümkün olan yerde maskelenmiş sürümler kullanın.
• İnce ayar verisi geri alınması en zor olanıdır: birinin verisiyle eğitilmiş bir model onu öylece unutamaz.

Bireysel ve kurumsal kullanım koşulları nasıl farklılaşır?

Bir sohbet asistanındaki kişisel hesap, sağlayıcıyla birey arasında yapılmış bir sözleşmedir. Koşullar tüketiciler için yazılmıştır. Saklama ve eğitimde kullanıma ilişkin varsayılanları sağlayıcı belirler ve değiştirir. Konuşma geçmişi bireye aittir; şirketin yönetici denetimleri, denetim kaydı ya da işten ayrılan çalışanın erişimini kapatma olanağı yoktur.

Kurumsal sözleşme ise şirketi müşteri yapar ve beraberinde veri işleme şartlarını, yönetici denetimlerini, saklama ayarlarını, eğitimde kullanıma ilişkin taahhütleri ve alt veri işleyenlerin listesini getirir. Alttaki model aynı olabilir. Farklı olan, veriyi kimin kontrol ettiği ve bu konuda neyin kararlaştırıldığıdır. Ürün birebir aynı görünse bile kişisel hesabın farklı bir risk olmasının nedeni budur.

Hangi tasarım tercihleri hassas veriyi içeride tutar?

En gizli veri, hiç göndermediğiniz veridir.

• Daha az gönderin. Yalnızca görevin ihtiyaç duyduğu alanları iletin. Bir teslimat sorusu müşterinin ödeme geçmişini gerektirmez.
• Göndermeden önce maskeleyin. Adları, hesap numaralarını ve benzeri tanımlayıcıları yer tutucularla değiştirin, sonra geri koyun. Kişisel veriyi maskeleme notumuz maskelemenin nerede yetersiz kaldığını anlatıyor.
• Bölgesel işleyin. Verinin kalması gereken yere uyan sağlayıcı bölgelerini seçin ve bölgeyi sözleşmeye yazdırın.
• Kendi bulutunuzda barındırın. Modelin çevresinde kendi denetimlerinize ihtiyaç duyduğunuzda bu yolu seçin.
• En hassas akışlarda açık ağırlıklı modelleri kendi sunucularınızda (şirket içi kurulum) çalıştırın. Sağlık, İK ya da hukuk dosyaları bu akışlara örnektir. Bunun bedeli, modelleri işletme maliyeti ve kaliteyi kendi vakalarınızda test etme gereğidir.
• Hassasiyete göre yönlendirin. Bir kural rutin vakaları barındırılan bir modele, hassas olanları kendi sunucularınızdaki modele ya da bir insana göndersin.

İmzalamadan önce neleri doğrulamalı?

• Model eğitiminde kullanım, özellik bazında saklama, işleme bölgeleri, alt veri işleyenler ve silme ürün sayfasında değil, sözleşmenin kendisinde yer alıyor.
• Hesabınızdaki ayarlar sözleşmeyle uyuşuyor; saklanan konuşma geçmişleri gibi ihtiyaç duymadığınız özellikler kapalı.
• Silme işe yarıyor: bir test kaydını silin ve sizinkiler dahil her adımdan silindiğini doğrulayın.
• Kendi kayıtlarınızın, iz kayıtlarınızın ve test setlerinizin sahipleri, saklama süreleri ve erişim rolleri var.
• Veri koruma görevliniz (DPO) ya da hukuk danışmanınız aktarımları ve hukuki sebebi inceledi; KVKK ve GDPR sorularını sıralayan notumuz bunları listeliyor.
• Sistem hiç kimseye kendi başına açamayacağı veriyi göstermiyor; bu, koruma önlemlerimizden biridir.

Veri ve yapay zeka altyapısı çalışmamız işin kurulum tarafını ele alır: her akışı, verisinin kalması gereken yerde tutmak.

Bu not genel bilgi amaçlıdır; hukuki tavsiye değildir.

Kaynaklar

1. 6698 sayılı Kişisel Verilerin Korunması Kanunu Mevzuat Bilgi Sistemi www.mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf
2. Tüzük (AB) 2016/679 (Genel Veri Koruma Tüzüğü, GDPR), resmi metin EUR-Lex eur-lex.europa.eu/eli/reg/2016/679/oj
3. Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda) Kişisel Verileri Koruma Kurumu (KVKK) www.kvkk.gov.tr/Icerik/8547/uretken-yapay-zeka-ve-kisisel-verilerin-korunmasi-rehberi-15-soruda