LLM Entegrasyonlarında Veri Güvenliği Nasıl Ele Alınmalı?

Bir destek temsilcisi, müşterinin uzun mesajını özetleten düğmeye basıyor. O mesajın nereye gittiği sorulduğunda çoğu ekibin cevabı tek kelimedir: sağlayıcıya.

Doğru, ama eksik. Mesaj bir yere gitmez — çoğalır.

Güvenlik tartışması genellikle bu çoğalmanın üzerinden atlayıp "hangi sağlayıcı daha güvenli" sorusuna geçer. Oysa pratikte belirleyici olan şey, aynı verinin sizin sisteminizde kaç kopyasının kaldığı ve o kopyaların her birine kimin karar verdiğidir.

Bir cümlenin kaç kopyası var?

Tek bir çağrıyı adım adım takip etmek, soyut bir güvenlik konuşmasından daha çok şey öğretir. Müşterinin mesajı özetlenirken tipik olarak şu kopyalar oluşur:

İstem gövdesi. Mesaj, çevresindeki talimatla birlikte sağlayıcıya gider. Görünen ve herkesin farkında olduğu kopya budur.

Sağlayıcının istek kaydı. İsteğin sağlayıcı tarafında ne kadar tutulduğu, hangi hesap türüyle çalıştığınıza ve yapılandırmaya bağlıdır. Varsayılan davranış her sağlayıcıda aynı değildir.

Kendi uygulama loglarınız. En sık atlanan kopya burasıdır. Hata ayıklamayı kolaylaştırmak için istem ve yanıt loglanır, bu satır kalıcı hâle gelir ve aylar sonra kimse orada müşteri verisi olduğunu hatırlamaz.

Hata izleme aracı. Çağrı sırasında bir istisna oluştuğunda, çoğu araç isteğin gövdesini otomatik olarak toplar. Kimse "müşteri mesajlarını hata izleme aracında saklayalım" diye karar vermemiştir; bir istisna yakalandığında öylece olur.

Önbellek. Aynı girdiyi tekrar işlememek için eklenen önbellek, tanımı gereği girdinin kendisini saklar.

Değerlendirme seti. Kaliteyi ölçmek için gerçek örnekler bir kenara ayrılır. Bu, çoğu zaman en uzun ömürlü kopyadır ve genellikle bir mühendisin dizininde durur.

Denetim arayüzü ve ekran görüntüleri. İnsanın incelediği her çıktı, bir ekranda görünür; destek konuşmalarında ekran görüntüsü olarak dolaşır.

Listenin uzunluğu sürpriz değil. Sürpriz olan, bu kopyaların çoğunun bir ürün kararı olarak değil, yan etki olarak ortaya çıkmasıdır. Güvenlik çalışmasının ilk adımı da bu yüzden bir önlem almak değil, sayımı yapmaktır: bu veri şu anda kaç yerde duruyor?

En ucuz güvenlik kararı: göndermemek

Sayım bittiğinde ortaya çıkan en etkili hamle genellikle teknik değildir. Gönderilmeyen alan hiçbir yerde saklanmaz, loglanmaz, sızmaz ve silinmesi gerekmez.

Bunun için istemi alan alan gözden geçirmek gerekir: modelin bu işi yapabilmesi için gerçekten hangi alana ihtiyacı var? Bir mesajı özetlemek için müşterinin adı, e-postası, telefon numarası ve hesap kimliği çoğu zaman gereksizdir — çünkü özet bu alanlara dayanmaz. Kayıt bütünüyle gönderilir, çünkü bütünüyle göndermek daha kolaydır.

İkinci hamle, gerekli olan alanları tanınabilir olmaktan çıkarmaktır. Model bir kimliğe ihtiyaç duyuyorsa, gerçek numara yerine yalnızca sizin sisteminizde anlamı olan bir yer tutucu gönderilebilir; yanıt geldiğinde yerine konur. Bu yaklaşım her senaryoda uygulanamaz, ama uygulanabildiği yerde tartışmayı bitirir.

Bu, bir güvenlik önleminden çok bir kapsam kararıdır ve ürüne yapay zekâ eklemenin gerekli olup olmadığı sorusunun devamıdır: modelin ihtiyaç duyduğu bağlamı belirlerken, o bağlamın maliyetine saklama ve erişim yükü de dâhildir.

Saklama kararı tek bir yerde verilmez

"Verileri doksan gün saklıyoruz" cümlesi kulağa net gelir. Uygulamada hangi kopyanın doksan gün saklandığı sorulduğunda cevap dağılır.

Log altyapısının saklama süresini genellikle bir altyapı mühendisi, yıllar önce, tamamen farklı bir gerekçeyle ayarlamıştır. Hata izleme aracının süresi satın alınan planla birlikte gelir. Önbelleğin ömrü performans düşünülerek seçilmiştir. Değerlendirme setinin ise çoğu zaman hiçbir ömrü yoktur; kimse silmeye karar vermemiştir.

Yani tek bir saklama politikası değil, birbirinden habersiz beş ayrı politika vardır. Bu, bir müşteri kayıtlarının silinmesini istediğinde görünür hâle gelir: ana veritabanından silmek kolaydır, geri kalanı ise ancak baştan planlanmışsa mümkündür.

Pratik yaklaşım, saklama süresini kopya bazında yazılı hâle getirmektir. Uzun bir doküman gerekmez; her kopya için üç satır yeter: ne kadar duruyor, kim siliyor, silinmediğinde ne olur.

Erişim, saklamadan daha çok gözden kaçar

Bir verinin ne kadar durduğu kadar önemli olan, dururken kimin görebildiğidir.

Sık rastlanan tablo şudur: müşteri verisi ürün içinde rol bazlı yetkilerle korunur, ama aynı veri log arayüzünde düz metin olarak, tüm mühendislik ekibinin erişimine açık biçimde durur. Ürün tarafındaki titiz yetkilendirme, arka kapıdan gelen erişimle anlamsızlaşır.

Buradaki soru bir araç sorusu değil: hangi kopyaya kimin eriştiği yazılabiliyor mu? Yazılamıyorsa, erişim kontrolü fiilen yoktur.

Sağlayıcıyla ilişki bir yapılandırma sorusudur

Sağlayıcı seçimi çoğu zaman model kalitesi üzerinden konuşulur; oysa veri açısından belirleyici olan, hesabın nasıl yapılandırıldığıdır. Sözleşmeyi okumadan önce netleşmesi gereken sorular şunlardır: verileriniz model eğitimi için kullanılıyor mu ve bu davranış varsayılan olarak hangi yönde; istekler sağlayıcı tarafında ne kadar süreyle tutuluyor; işlem hangi bölgede gerçekleşiyor; sağlayıcı kendi altında başka hizmetler kullanıyor mu.

Bu sorular hukuki yükümlülüklerin yerini tutmaz — mevzuatın ne gerektirdiği ayrı bir uzmanlık alanıdır ve hukuk danışmanınıza aittir. Buradaki amaç daha mütevazı: bu maddeleri konuşmadan bir entegrasyona başlanmaması gerektiğini bilmek.

Pratikte en sık karşılaşılan hata ise teknik değil, idari olanıdır: prototip aşamasında bir geliştiricinin kişisel hesabıyla alınan anahtarın, aceleye gelip üretime taşınması. O andan itibaren şirket verisi, kurumsal ayarların hiçbirinin geçerli olmadığı bir hesap üzerinden akmaya başlar.

Sızıntı yalnızca girişten olmaz

Tartışma genellikle modele ne gönderdiğiniz üzerine kuruludur. Modelin ne döndürdüğü de aynı ölçüde bir veri yoludur.

Bağlam getiren sistemlerde — yani soruyu cevaplamak için kendi kayıtlarınızdan parça toplayan kurgularda — asıl risk, yetki filtresinin yanlış katmana konmasıdır. Modelden "yalnızca bu kullanıcının görebileceği kayıtları kullan" diye rica etmek bir güvenlik önlemi değildir. Yetki, veriyi getiren sorguda uygulanmalıdır; model, kendisine verilmemiş bir kaydı sızdıramaz.

İkinci nokta, kullanıcının istem içeriğini yönlendirebildiği durumlardır. Serbest metin alan her özellikte, gelen metnin bir talimat gibi davranma ihtimali vardır. Bunun tam çözümü yoktur; ama çıktının yetkisini sınırlamak — yani modele doğrudan işlem yaptırmamak — riski somut biçimde küçültür. Bu, insan denetiminin nerede duracağı sorusuyla aynı yerden çıkar.

Kullanıcıya ne söylüyorsunuz?

Son ve en çok ertelenen soru: kullanıcı, mesajının bir modele gittiğini biliyor mu?

Bunu söylemek çoğu ekibin sandığından daha az maliyetlidir. Bir cümlelik açık bir ifade, sonradan fark edilmesinden çok daha iyi karşılanır — ve güvenin nasıl kurulduğu yazısındaki mantık burada da geçerlidir: kurumsal güven, iddia edilerek değil, doğrulanabilir davranışla kurulur.

Sonuç

LLM entegrasyonlarında veri güvenliği, bir sağlayıcı seçme kararına indirgenemeyecek kadar dağınık bir konudur. Riski oluşturan şey genellikle sağlayıcının kendisi değil, verinin yol boyunca bıraktığı ve kimsenin karar vermediği kopyalardır.

Bu yüzden en verimli başlangıç, güvenlik araçları eklemek değil sayım yapmaktır: bu veri kaç yerde duruyor, ne kadar duruyor, kim görüyor. Sayım bittiğinde alınacak önlemlerin çoğu zaten kendini gösterir — ve büyük bölümü, gereksiz alanı hiç göndermemekten ibarettir.

Bu çerçeveyi bir sonraki adımla, prototipin üretime taşınmasıyla birlikte ele almak faydalıdır; çünkü kopyaların çoğu tam olarak o geçiş sırasında oluşur. Yapay zekâ entegrasyonu çalışmalarımızda veri akışının çıkarılması, model seçiminden önce gelen adımdır.