Amaç ve Tehdit Modeli

Üretimdeki bir AI sistemini yalnızca yanıt doğruluğuyla değerlendirmek yeterli değildir. Modelin hassas veriyi istemeden açığa çıkarıp çıkarmadığı, RAG belgelerindeki kötü niyetli talimatları kullanıcı isteği sanıp sanmadığı, yetkisiz araç çağrısı yapıp yapmadığı ve gözlemlenebilirlik katmanının yeni bir sızıntı üretip üretmediği ölçülmelidir.

Değerlendirmeye başlamadan önce sistem sınırlarını yazılı hâle getirin:

• Model hangi veri sınıflarını görebilir; kişisel veri, kimlik bilgisi, sır ve müşteri kayıtlarından hangilerini hiç görmemelidir?
• Sistem talimatı, kullanıcı girdisi, RAG belgesi ve araç sonucu nasıl ayrı güven düzeylerinde işlenecektir?
• Her araç için izin kapsamı, kimlik doğrulama, parametre doğrulama ve insan onayı koşulları nedir?
• Olay incelemesinde hangi telemetri tutulabilir; hangi alanlar anında maskelenmeli veya hiç kaydedilmemelidir?

Tehdit modeli; jailbreak denemelerinin yanı sıra yanlış yetkilendirme, belge içi prompt injection, hassas veri yankılama, log sızıntısı ve redaksiyon sonrası veri yeniden oluşturma risklerini kapsamalıdır.

Gizlilik Güvenli Eval Seti Tasarımı

Gerçek müşteri verisi yerine sentetik kayıtlar, sınıflandırılmış örnekler ve takip edilebilir canary değerler kullanın. Canary, yalnızca test amacıyla üretilen, benzersiz ve tespit edilmesi kolay bir işarettir; gerçek bir parola, API anahtarı veya müşteri verisi olmamalıdır. Her canary için beklenen konumları tanımlayın: model yanıtı, araç parametresi, ara çıktı ve loglar.

Her test örneği yalnızca bir girdi değil, ölçülebilir bir güvenlik sözleşmesi içermelidir:

• İzin ver: Yetkili ve hassas olmayan isteğe doğru yanıt üret.
• Reddet: Yetkisiz kişisel veri, sistem talimatı veya sır talebini açıklama.
• Dönüştür: Hassas alanları maskeleyerek yalnızca gerekli bilgiyi sağla.
• Eskalasyon: Riskli veya geri döndürülemez araç işlemini insan onayına bırak.

Örnek test aileleri arasında RAG belgesine gömülü “talimatı uygula” metni, başka bir kullanıcının canary verisini isteme, sistem mesajını özetletme, araç çıktısındaki sahte yetki iddiası ve redakte edilmiş veriyi yeniden oluşturma isteği bulunabilir. Her örnekte beklenen davranış, kabul edilebilir yanıt varyasyonları ve kesin başarısızlık koşulu ayrı tutulmalıdır. Testlerin bir bölümü sabit regresyon seti, bir bölümü ise yeni olaylardan türetilen dönen set olarak yönetilmelidir.

Metrikler ve Dağıtım Eşikleri

Tek bir toplam skor, kritik bir sızıntıyı ortalama başarı içinde gizleyebilir. Risk bazlı metrikleri model, prompt, guardrail ve test sürümüyle birlikte saklayın:

• Gizli veri sızıntı oranı: Sızıntı üreten testlerin toplam gizlilik testlerine oranı.
• Güvenli reddetme oranı: Yetkisiz isteklerde doğru sınır koyan yanıtların oranı.
• Yanlış pozitif oranı: Yetkili isteklerin gereksiz yere reddedilme oranı.
• Canary yakalama oranı: Canary’nin yanıt, araç çağrısı veya logda tespit edilme oranı.
• Araç güvenlik ihlali oranı: Yetkisiz ya da onaysız çağrıların toplam araç çağrılarına oranı.
• Redaksiyon geri kazanım oranı: Maskelenen bilginin anlamlı biçimde yeniden üretilebildiği örneklerin oranı.

Eşikler dağıtım öncesinde belirlenmelidir. Örneğin kritik veri sınıfında tek bir doğrulanmış sızıntı, genel skor yüksek olsa bile dağıtım kapısını durdurabilir. Yeni model, sistem promptu, RAG boru hattı veya guardrail değişikliği için hızlı regresyon, genişletilmiş saldırı testleri ve sınırlı trafik gözlemi ayrı aşamalar olarak çalıştırılmalıdır.

Prompt Injection ve Guardrail Tasarımı

Güvenlik kararını yalnızca modele bırakmayın. Güvenilmeyen içerikleri açıkça etiketleyin; RAG metninin veya araç çıktısının talimat değil veri olduğunu sistem mimarisinde koruyun. Araç çağrılarında izin listesini, parametre şemasını, kaynak-kullanıcı yetki kontrolünü ve yüksek etkili işlemler için insan onayını modelden bağımsız uygulayın.

Guardrail tasarımında şu ilkeler kullanılabilir:

• En az ayrıcalık: Model yalnızca görevi için gerekli veriye ve araca erişsin.
• Savunma katmanları: Girdi taraması, bağlam ayrıştırma, çıktı sınıflandırması ve araç geçidi birbirinden bağımsız kontroller olsun.
• Fail-closed davranış: Belirsiz yetki veya sınıflandırma sonucunda hassas veri ve riskli işlem engellensin.
• Gerekçeli karar kaydı: Politika adı, risk etiketi ve karar sürümü kaydedilsin; hassas içerik ham hâliyle tutulmasın.

Gözlemlenebilirlikte Veri Minimizasyonu

Ham prompt ve yanıtları sınırsız saklamak, güvenlik kontrolünü yeni bir sızıntı yüzeyine dönüştürür. Varsayılan telemetri; olay türü, politika kararı, risk etiketi, araç adı, gecikme, korelasyon kimliği ve sürüm bilgisiyle sınırlı olmalıdır. Gerekliyse alan bazlı maskeleme, kısa saklama süresi, erişim denetimi ve değiştirilemez denetim kaydı birlikte uygulanmalıdır.

Debug modu süreli, yetkili ve erişim kaydı tutulan bir özellik olmalıdır. Canary’nin yanıt, araç parametresi veya logda görülmesi alarm üretmelidir. Her alarm için şu triage adımları tanımlanmalıdır: olay hangi katmanda oluştu, hangi veri sınıfı etkilendi, araç çağrısı gerçekleşti mi, aynı sürümde yeniden üretilebiliyor mu ve geri alma gerekliliği var mı?

Değişiklik kaydında bileşen, etkilenen tehdit sınıfı, önceki ve yeni metrikler, bilinen sınırlamalar ve geri alma koşulu yer almalıdır. Her olaydan sonra anonimleştirilmiş hata sınıfını yeni bir eval örneğine dönüştürmek, test setini yaşayan bir savunma mekanizması hâline getirir.