Model çıktısı aşamasında kilitlendiği düşünülen yapay zeka destekli bir destek sistemi, CRM kayıtlarını isteme (prompt) besleyen "yan kapı" aracılığıyla müşteri verilerini sızdırıyordu. Oluşturucunun olay sonrası incelemesi (post-mortem), yalnızca modelin ürettiği metni korumanın yeterli olmadığını gösteriyor; gelen istek, dahili araçlardan çekilen veriler ve nihai çıktı (emission) tamamının bağımsız koruma önlemlerine ihtiyacı vardır, aksi takdirde bir işletme, model çıktısında hiçbir ihlal görmeden isimleri, e-postaları ve kimlikleri (ID) ifşa edebilir.

Üç sınır neden önemlidir

Çoğu operatör, bir sızıntının dil modelinin gördüğü bir sırrı tekrarlamasıyla gerçekleştiğini varsayar. Uygulamada ise en büyük risk, model veriyi henüz görmeden gerçekleşir. Bir yapay zeka ajanı üç bilgi akışı alır:

  • Giriş (Ingress) – müşterinin yazdığı ham sorgu.
  • Dönüş yolu (Return path) – ajanın bir CRM gibi alt sistemlerden çektiği bilgiler.
  • Çıktı (Emission) – modelin kullanıcıya döndürdüğü metin.

Bu akışlardan herhangi biri korunmayan tanımlayıcılar (identifiers) taşıyorsa, çıktı katmanı filtrelenmiş olsa bile ajan bunları yanlışlıkla yanıtına dahil edebilir.

Demodan üretime: zorlukla öğrenilen dersler

Bir prototipin canlı bir yardım masasına taşınması, basit bir "maskele ve gönder" (redact-then-send) yaklaşımının gözden kaçırdığı somut hataları ortaya çıkardı.

  • Maskelemek yerine tokenize edin – Bir ismin veya e-postanın modele ulaşmadan silinmesi, sistemin doğru bir yanıt oluşturmasını engeller. Orijinal değeri güvenli bir kasada (vault) saklayın, istemde (prompt) bunun yerine rastgele bir UUID kullanın ve model işini bitirdikten sonra UUID'yi geri değiştirin. Bu, işlevselliği korurken ham veriyi modelin bağlamı dışında tutar.

  • Tanımlayıcıları checksum (doğrulama toplamı) ile doğrulayın – Düzenli bir ifade (regular expression), hesap numarasına benzeyen bir diziyi tespit eder; bir checksum ise bunun gerçek bir kimlik olup olmadığını onaylar. Bir checksum filtresi, ajanın rastgele sayıları hassas veri olarak algılamasını engelleyerek, aksi takdirde gereksiz maskelemeleri tetikleyecek olan yanlış pozitifleri (false positives) azaltır.

  • Üst üste binen aralıkları birleştirin – Müşteri kayıtları genellikle ortak karakterler paylaşan bir isim ve ardından gelen bir e-posta adresi içerir (örneğin, “John Doe john.doe@example.com”). Sadece ismi tokenize etmek, e-posta parçasını açık metin olarak bırakır ve bu da çıktı olarak verilebilir. Tüm örtüşen bölgeyi tek bir token olarak ele alın.

  • Doğru sınırı test edin – Sadece çıktı (emission) katmanını kontrol ederek geçen bir test, yanlış bir güvenlik hissi verir. Dönüş yolundaki (return path) bir sızıntıyı yakalayan başarısız bir test, düzeltme yapılmasını sağlar. Üç sınırın her birini açıkça doğrulayan test paketleri tasarlayın.

  • Gerçek durumu (ground truth) takip edin – Bir insan, yapay zeka tarafından oluşturulan taslağı göndermeden önce düzenlediğinde, model zaten hatalı bir yanıt üretmiş demektir. Yapay zekanın taslağını, insan tarafından onaylanan nihai mesajla karşılaştırmak, güven boşluklarını ortaya çıkarır ve sistemin hataları tekrarlamayı öğrenmesini engeller.

İşletmeler için riskler

Müşteri hizmetleri yapay zeka ajanları, halkla etkileşim ile dahili veri depolarının kesişme noktasında yer alır.

Karşı argüman: neden bazıları hala maskelemeyi (redaction) tercih ediyor

Özet

Yapay zeka destekli bir müşteri hizmetleri ajanını güvence altına almak tek kapılı bir sorun değildir. Gelen isteği, dahili sistemlerden çekilen verileri ve giden metni ayrı duvarlar olarak ele alın; herhangi birine sızılması tüm hizmetin tehlikeye girmesi demektir. Hassas alanları tokenize etmek, tanımlayıcıları doğrulamak, örtüşen aralıkları birleştirmek, doğru sınırı test etmek ve yapay zeka taslaklarını sürekli olarak nihai insan mesajlarıyla karşılaştırmak, bir "yardımcı pilotu" (copilot) güvenilir, ajan tabanlı bir hizmete dönüştüren pratik adımlardır.