Yapay zeka müşteri hakkında ne hatırladı: Vault, veri sahibi talebi ve başkasının vektörleri

Google, Vault'a çalışanların Gemini ile yazışmalarını dışa aktarmayı öğretti; CustomerThink, “hakkımda tuttuğunuz her şeyi verin” talebinin ortak posta kutusuna habersiz düştüğünü hatırlattı; Directum'un metodoloğu İK uzmanının modele neyi verebileceğini inceledi; Weaviate ise başkasının vektörünü geri çıkarmaya izin veren açığı kapattı. Dört haber, tek konu: modelin müşteri ya da çalışan hakkında okuduğu her şey bir yerde duruyor ve bir gün gösterilmesi ya da silinmesi istenecek. İşletme sahibinin tam olarak nerede durduğunu bilmesi gerekir.

Neler yayımlandı

Google Workspace 22 Ekim'de Google Vault'un Workspace içindeki Gemini sohbetleri için filtreli dışa aktarmayı desteklediğini duyurdu. Yönetici kullanıcıları ya da birimleri seçiyor, en fazla 5000 hesap, dönemi belirliyor ve bir JSON alıyor: kullanıcının istekleri, modelin cevapları, oluşturulan ekler ve modelin başvurduğu Drive dosyaları ile Gmail mesajlarının bağlantıları. Bu veriler için saklama kurallarını ve yasal tutma özelliğini Google sonraki sürümlere bırakıyor; yönetici konsolunda ise geçmişin elle silinmesi şimdiden yasaklanabiliyor ya da belli bir süre hareketsizlikten sonra otomatik silme açılabiliyor. API, arayüzden sonraki 14 gün içinde geliyor.

CustomerThink 20 Ekim'de basit bir deneyle başladı: veri sahibi talebi salı öğleden sonra destek ekibinin ortak kutusuna geliyor, bütün kişisel verilerin verilmesi isteniyor. Bunu kim işler, hukukçular mı IT mi, cevabı kendiniz mi verirsiniz ve bunun için kaç gününüz var. Elimde yalnızca yazının duyurusu var, bu yüzden yazarın sonuçlarını değil, sorunun kuruluşunu aktarıyorum.

Habr'da 15 Ekim'de Directum'un metodolog-analisti Ruslan Nuriev aynı konuyu İK tarafından yazdı: İK, modelleri vardiya çizelgeleri, belge incelemesi ve standart dışı taleplere cevap için kullanmak istiyor, ama İK'daki verilerin çoğu kişisel ve ona göre ihlal cezaları 2025'te birkaç kat arttı. Bu yazının da elimde yalnızca girişi var.

Weaviate 15 Ekim'de nearObject operatöründeki orta önem dereceli bir açığı düzelten 1.39.3 sürümünü yayımladı. Arama, nesnenin vektörünü bir koleksiyondan alıp benzerini başka bir koleksiyonda arıyordu, yetkiyi ise yalnızca aradığı koleksiyon için kontrol ediyordu. Nesnenin kendisi cevaba girmiyordu, ama ona olan mesafeler giriyordu ve mesafelerden vektör geri çıkarılıyor: araştırmacı sekiz deneme nesnesiyle normalize edilmiş dört boyutlu vektörü 5e-9 hassasiyetle geri çıkardı. Saldırı için koleksiyon adı ve nesnenin UUID'si, koleksiyon tanımlarını okuma yetkisi ve herhangi bir kendi koleksiyonunda veri oluşturma yetkisi gerekiyor. Weaviate'te istismar belirtisi yok. Bu, tek kümeyi ekipler arasında RBAC ile paylaşanları ilgilendiriyor.

Örnek: araç kiralama ve “hakkımda ne tutuyorsunuz”

Bir araç kiralama şirketini ele alalım. Şirketin müşteri hakkında elinde rezervasyon, ehliyet taraması, teslimdeki araç fotoğrafı, ödeme ekran görüntüsü ve imzalı sözleşme var. Şimdi buna yöneticilerin “bu müşteride durum ne” sorusuna cevap veren model tabanlı bir asistan ve arama için sözleşmelerle yazışmaların konduğu bir vektör veritabanı ekleyelim. Talep geliyor: her şeyi verin. Rezervasyonu ve belgeleri çıkarmak kolay. Yöneticilerin modele bu kişi hakkında sorduğu soruların geçmişini ve arama dizininin içindeki verilerini birinin hatırlaması ve bulması gerekecek.

Modelli her yeni araç, insanlara dair verilerin durduğu bir yer daha ekliyor. O yer listeye yazılmamışsa, veri sahibi talebi bir soruşturmaya dönüşür.

Bende nasıl çalışıyor

Başkalarına ait kişisel verilerin en yoğun akışı bende ABD'deki PDR şirketi için yaptığım ayrıştırıcılardan geçiyor. 2023'ten beri sigorta hasar tahminlerini, tutanakları ve VIN'li fotoğrafları okuyorlar; sigorta belgeleri 60-70 sayfaya çıkabiliyor. 2026'da yapay zeka doğrulayıcılarını bağladım ve sürüm halinde yayımladım: belgelerin yaklaşık %99,9'u elle düzeltme olmadan geçiyor, son kontrolü insan yapıyor. Doğrulama için üç ayrı servis kullanıyorum, Anthropic, OpenAI ve Gemini, her biri kendi görevi için. Kontrolün içeride nasıl kurulduğunu açıklamıyorum.

Ayrıştırmadan sonra verilerin nereye dağıldığını her belge için biliyorum: şirketin süper uygulaması, CRM, hasar tahminleri, kısmen leaderboard ve TV ekranları. Her “gösterin” ya da “silin” talebi bu haritadan başlar. Veri sahibi talebiyle silme senaryosunu ayrıca kendimde denemedim. Böyle bir talep gelirse sunucuda aramayla değil, haritayla başlarım.

Ben ne yapardım

İnsanlara dair verilerin durduğu yerlerin listesini yapardım, modellerle sohbet geçmişi ve vektör dizinleri dahil. Workspace için artık Vault dışa aktarımı var, kendi sistemleriniz için listeyi kendiniz tutmanız gerekecek.

Dış model servisine neyin gideceğine, sunucuda neyin kalacağına önceden karar verirdim. Hasar tahminini kontrol etmek için doğrulayıcıya kalemler ve tutarlar gerekir, araç sahibinin adı ve adresi ona gerekmez. Bunlar gönderimden önce karara bağlanır.

Model geçmişi için e-postayla aynı saklama kurallarını açardım: süre, otomatik silme, iş gerektiriyorsa elle silme yasağı.

Vektör veritabanındaki yetkileri Weaviate'in önerdiği gibi kontrol ederdim: koleksiyon tanımlarını kim okuyabiliyor, herhangi bir yerde veri kimler oluşturabiliyor. Weaviate kullanıyorsanız 1.39.3'e güncelleyin.

Ortak kutudan gelen veri sahibi talebini alan ve kime ileteceğini bilen tek bir kişi belirlerdim.

İlgili yazılar

Modelin belgeleri çözmede nerede yardım ettiğini ve sonucun nasıl kontrol edileceğini Veri işlemede yapay zeka: çıkarma ve doğrulama yazısında inceledim; yaklaşımı sonucun kontrol edilebildiği süreçte yapay zeka sayfasında anlattım. Ayrıştırıcıların kendisi: ABD'deki PDR şirketi haftada yaklaşık 60 saat tasarruf ediyor. Komşu yazılarım: Decisions API ve ajan hafızası ve 2026'da belgelerden veri çıkarma; daha önce mesajlarda ve loglarda veri maskeleme ve yapay zekanın çoktan hatırladığı müşteri hafızası hakkında yazmıştım. Modelleriniz zaten müşteri belgelerini okuyorsa ve bunların nerede durduğundan emin değilseniz, hangi belgeler ve hangi sistemler olduğunu anlatın. Görevi konuşalım.