Veri Saklamaya Duyarlı AI API Yönlendirmesi: Ağ Geçidinde ZDR, Yerleşiklik ve Günlük Kaydı Politikalarını Zorunlu Hale Getirin
AI API trafiğini veri saklama politikasına göre yönlendirmek için pratik bir ağ geçidi mimarisi: istek hassasiyetini sınıflandırın, sağlayıcıyı saklama davranışını haritalayın, uyumsuz özellikleri engelleyin, güvenli analizleri koruyun ve her kararı denetleyin.
Güvenlik ekiplerinin yalnızca hangi modelin en ucuz, en hızlı veya en yetenekli olduğunu bilmesi gerekmez. Belirli bir isteğin yasal ve operasyonel olarak belirli bir sağlayıcıya, uç noktaya, bölgeye, özelliğe ve günlük moduna gönderilip gönderilemeyeceğini bilmeleri gerekir.
Bu göründüğünden daha zor. Bir model sıradan dahili sohbet için kabul edilebilir ancak müşteri PII'sı için kabul edilemez. Bir sağlayıcı, bir API yolu için sıfır veri saklama olanağı sunabilirken, arama temelli bir özellik, istemleri ve çıktıları sabit bir süre boyunca saklar. Bir bölge, depolama yerleşimini destekleyebilir ancak beklediğiniz işleme modunu desteklemeyebilir. Geliştiriciye ait günlükler yapılandırılabilirken, sağlayıcının kötüye kullanımı izleme günlükleri farklı bir politika izler.
Bunun pratik yanıtı, saklama kararlarını bireysel uygulamalardan AI API ağ geçidine taşımaktır. Ağ geçidi, isteği sınıflandırmalı, sağlayıcı yetenek matrisine göre değerlendirmeli, uyumsuz özellikleri engellemeli, yalnızca onaylanmış model profillerine yönlendirmeli ve varsayılan olarak ham istemleri depolamadan bir politika kararını kaydetmelidir.
Okuyucu sorunu: Sağlayıcı gizlilik şartları çalışma zamanı kontrolleri değildir
Çoğu ekip, hangi yapay zeka sağlayıcılarının onaylandığını belirten bir e-tablo veya güvenlik incelemesiyle başlar. Bu faydalıdır ancak üretim yönlendirmesi için yeterli değildir.
Uygulamalar çalışma zamanı seçimlerini yapar:
- Bu isteği hangi model kimliği işlemelidir?
- İstek, arama temellendirmeyi, dosya yüklemeyi, kod yürütmeyi, toplu işlemeyi, bilgi istemini önbelleğe almayı mı yoksa depolanan konuşmaları mı kullanmalı?
- İsteği hangi bölge veya uç nokta işlemelidir?
- Sistem hata ayıklama için ham istemi günlüğe kaydedebilir mi?
- Yedek yönlendirme aynı isteği başka bir sağlayıcıya gönderebilir mi?
Bu seçeneklerin her biri, elde tutma profilini değiştirebilir. Düz sohbet modunda uyumlu olan bir istek, geliştirici topraklamayı veya kalıcı konuşma depolamayı açtığında uyumsuz hale gelebilir. Güvenilirlik için tasarlanmış bir geri dönüş kuralı, düzenlenmiş verileri yanlışlıkla sıfır veri saklama, veri yerleşimi veya kötüye kullanım izleme kontrolleri için onaylanmamış bir sağlayıcı yoluna yönlendirebilir.
Öneri: Saklama davranışını, sağlayıcı hesabına eklenmiş belgeler olarak değil, birinci sınıf bir yönlendirme kısıtlaması olarak ele alın.
Politika tasarlamadan önce kodlanması gereken gerçekler
Tam şartlar sağlayıcıya, ürüne, sözleşmeye, bölgeye, uç noktaya ve özelliğe göre değişir. Belleğe veya tek seferlik incelemeye güvenmeyin. Kaynağa ait bir matris oluşturun ve şartlar değiştiğinde bunu güncelleyin.
Mevcut bazı kamu sağlayıcı belgeleri bunun neden gerekli olduğunu göstermektedir:
- OpenAI: API veri yerleşimi, bölgeye özgü alan önekleri gerektiren bölgesel isteklerle birlikte proje tarafından yapılandırılmış olarak belgelenmiştir. OpenAI ayrıca depolama desteğini işleme desteğinden bölgeye göre ayırıyor ve ABD dışındaki bölgeler için ek gereksinimlere dikkat çekiyor. OpenAI, ABD dışı API veri yerleşiminin kötüye kullanım izleme kontrolleri ve Değiştirilmiş Saklama değişikliği için onay gerektirdiğini belirtir.
- Anthropic: Anthropic, API ile ilgili ticari kullanım durumları için sıfır veri saklamayı belgeliyor ve bazı ilgili ürünlerin veya uyumluluk feed'lerinin, Etkinlik Akışı ve uzaktan oturum transkriptleri için daha uzun saklama dahil olmak üzere ayrı saklama modellerine sahip olduğunu belirtiyor.
- Google Gemini: Gemini API şartları, ücretsiz ve ücretli hizmetleri birbirinden ayırır. Ücretsiz hizmetler için Google, ürünleri iyileştirmek amacıyla gönderilen içeriği ve oluşturulan yanıtları kullanabilir; Ücretli hizmetler için Google, istemlerin ve yanıtların ürünleri iyileştirmek amacıyla kullanılmadığını söylüyor. Gemini Developer API ZDR belgeleri, ücretli hizmet kötüye kullanımı izleme günlüklerinin normalde istemleri ve yanıtları sınırlı bir süre boyunca sakladığını, onaylı ZDR projelerinin ise oturum açmadan önce kullanıcı içeriğini ve tanımlanabilir meta verileri temizlediğini söylüyor.
- Özelliğe özgü depolama: Gemini belgeleri, Google Arama ile Grounding ve Google Haritalar ile Grounding'in istemleri, bağlamsal bilgileri ve oluşturulan çıktıyı 30 gün boyunca sakladığını ve bu özellikler kullanıldığında bu depolamayı devre dışı bırakmanın hiçbir yolu olmadığını belirtir.
- Geliştiriciye ait günlükler: Gemini API günlük kaydı belgelerinde, geliştiriciye ait API günlüklerinin, faturalandırmanın etkin olduğu projeler için varsayılan olarak 55 güne kadar saklanabileceği ve geliştiricilerin 7, 14 veya 28 gün gibi daha kısa aralıklar seçebileceği belirtilmektedir.
- Risk yönetimi: NIST'in Üretken Yapay Zeka Profili, yapay zeka tarafından oluşturulan içeriğin gizlilik riskleri açısından izlenmesini ve üretken yapay zeka politikalarının mevcut veri, yazılım, hukuk, uyumluluk ve risk yönetimi süreçlerine bağlanmasını önerir.
Bunlar, kullanıma sunulmadan önce mevcut tedarikçi belgelerine göre doğrulanması gereken gerçeklerdir. Mimari ders sabittir: elde tutma, sağlayıcı düzeyinde tek bir Boole değeri değildir.
Mimari: istek yolundaki bir ağ geçidi politikası motoru
Saklamaya duyarlı bir ağ geçidinin beş temel bileşeni vardır:
- İstek duyarlılığı sınıflandırıcısı: yönlendirmeden önce iş yükünü etiketler.
- Sağlayıcı yetenek matrisi: sağlayıcıyı, modeli, uç noktayı, bölgeyi, saklamayı, günlüğe kaydetmeyi ve özellik davranışını açıklar.
- Kod olarak politika kuralları: güvenlik gereksinimlerini çalışma zamanı izin verme, reddetme veya inceleme kararlarına dönüştürün.
- Özellik geçiş katmanı: açıkça izin verilmediği sürece, saklamayı değiştiren özellikleri engeller.
- Denetim ve analiz katmanı: varsayılan olarak ham istemleri saklamadan yararlı meta verileri kaydeder.
Ağ geçidinin her yasal ayrıntıyı anlamasına gerek yoktur. Hukuk, güvenlik, uyumluluk ve platform ekiplerinizin onayladığı kararları uygulaması gerekir.
1. Adım: Bir model seçmeden önce istek hassasiyetini sınıflandırın
Küçük bir sınıflandırma sınıflandırmasıyla başlayın. Geliştiricilerin kullanabileceği kadar basit, aynı zamanda politikayı yönlendirecek kadar da anlamlı olmalıdır.
Örnek hassasiyet etiketleri:
genel: genel belgeler, pazarlama kopyası, genel web sitesi içeriği.dahili: düşük hassasiyete sahip, halka açık olmayan şirket bilgileri.gizli: strateji, sözleşmeler, müşteri bağlamı, yayınlanmamış ürün ayrıntıları.müşteri_pii: adlar, e-postalar, adresler, hesap tanımlayıcılar, destek transkriptleri.düzenlenmiş: sağlık hizmetleri, finans, hukuk, eğitim veya yargı alanına özgü korunan veriler.kaynak_kodu: özel kod, yapılandırma, mimari dosyaları.kimlik bilgileri: sırlar, belirteçler, şifreler, özel anahtarlar. Çoğu sistemde bunun yönlendirilmesi değil engellenmesi gerekir.
Sınıflandırma birden fazla kaynaktan gelebilir:
X-Data-Class: customer_piigibi uygulama tarafından sağlanan bir başlık.- Denetlenmeye tabi bir müşteriden gelen tüm trafiğin, onaylı bir kuralla düzeyi düşürülmediği sürece, düzenlemeye tabi olarak kabul edildiği kiracı politikası.
- Destek bildirimi özetinin varsayılan olarak
customer_piiolarak ayarlandığı uç nokta politikası. - Kimlik bilgileri, bariz kişisel bilgiler veya politika ihlalleri için hafif içerik taraması.
Öneri: tamamen otomatik algılamaya bağlı değildir. Uygulamaların amaçlanan veri sınıfını beyan etmesini zorunlu kılın, ardından belirgin uyumsuzlukları yakalamak veya daha güvenli bir sınıf oluşturmak için taramayı kullanın.
2. Adım: sağlayıcı yetenek matrisi oluşturun
Yetenek matrisi, yönlendiricinin değerlendirdiği gerçeğin kaynağıdır. Üretim yapılandırması gibi sürümlendirilmeli, incelenmeli ve test edilmelidir.
Örnek alanlar:
<ön>Ham model kimlikleri yerine model profillerini kullanın. Profil, modeli, sağlayıcıyı, uç noktayı, bölgeyi, özellik kümesini ve saklama duruşunu birleştirir. Geliştiriciler yalnızca model: fast-large-model değil, model_profile: uyumlu_summarization talebinde bulunur.
Öneri: sözleşmeye dayalı önkoşulları matrise ekleyin. Bir satıcının bir yerde ZDR sunması nedeniyle bir rota ZDR onaylı değildir. Yalnızca hesabınız, projeniz, bölgeniz ve uç noktanız gerekli koşulları karşıladığında onaylanır.
3. Adım: Kod olarak politika kurallarını yazın
Politika kuralları açık, test edilebilir ve güvenlik ve platform ekipleri tarafından okunabilir olmalıdır.
Sözde koddaki örnek kurallar:
reddet eğer data_class == "kimlik bilgileri"
nedeni "credentials_must_not_be_sent_to_model"
yalnızca ["düzenlenmiş", "müşteri_pii"] içindeki data_class'a izin ver
ve profile.zdr_eligible == doğru
ve profile.zdr_contract_required_satisfied == doğru
Reason_on_failure "model_profile_not_zdr_eligible"
residence_required == "eu" ise reddet
ve profile.processing_residency'de "eu" yok
nedeni "region_processing_not_supported"
["gizli", "müşteri_pii", "düzenlenmiş"] içindeki data_class'ı reddetve request.raw_prompt_logging == doğru
nedeni "raw_prompt_logging_not_allowed"
request.features.search_grounding == doğruysa reddet
ve politika.requires_zdr == doğru
ve profile.feature_storage.search_grounding_days > 0
neden "grounding_requires_retained_content"
fallback_profile.retention_level < birincil_profile.retention_level ise reddet
nedeni "fallback_weakens_retention_policy"Bu kurallar, sağlayıcı seçiminden önce ve geri dönüşten önce tekrar çalıştırılmalıdır. Yedek yönlendirme, kazara politika sapmalarının yaygın bir kaynağıdır: Birincil rota uyumlu olabilirken, yedek rota yalnızca kullanılabilir durumda olabilir.
4. Adım: Araçlara ve özelliklere, elde tutmayı değiştiren özellikler olarak davranın
Elde tutmayı yalnızca temel modelin bir özelliği olarak modellemeyin. Özellikler genellikle depolamayı, günlüğe kaydetmeyi veya inceleme davranışını değiştirir.
Her özelliğe kendi politika bayraklarını verin:
- Arama temeli: sağlayıcı şartlarına bağlı olarak istemleri, alınan bağlamı ve oluşturulan çıktıyı saklayabilir.
- Haritalar veya konum temeli: konuma özgü günlükler veya saklama kuralları sunabilir.
- Dosya yükleme:, dosyaları istemlerden ve yanıtlardan ayrı olarak depolayabilir.
- Kod yürütme: geçici dosyalar, yürütme günlükleri veya korumalı alan yapıları oluşturabilir.
- Toplu işler: eşzamanlı API çağrılarından farklı saklama, sıraya alma ve sonuç depolama davranışına sahip olabilir.
- Saklanan görüşmeler: kasıtlı olarak içeriğin kalıcı olmasını sağlar ve hiçbir zaman genel bir sohbet seçeneğinin arkasına gizlenmemelidir.
- Değerlendirme veya inceleme kontrol panelleri:, insan tarafından incelenen iş akışları veya daha uzun ömürlü veri kümeleri oluşturabilir.
Öneri: kiracı ve rota düzeyinde saklamayı değiştiren özelliklerin etkinleştirilmesini sağlayın. Bir geliştirici grounding_search=true'u etkinleştirirse, ağ geçidinin, isteği yukarı yönde göndermeden önce özellik depolama kurallarına göre yeniden değerlendirmesi gerekir.
5. Adım: Ham istemleri saklamadan analitiği koruyun
Saklamaya duyarlı yönlendirme, platform ekibinin gözünü kör etmemelidir. İçerik depolama alanını en aza indirirken yararlı AI kullanım analizlerini koruyabilirsiniz.
Güvenli varsayılan telemetri alanları:
- kiracı kimliği ve proje kimliği
- karma oluşturma veya dahili API anahtarı kimliği
- model profil kimliği ve sağlayıcı kimliği
- zaman damgası ve bölge isteğinde bulun
- varsa giriş, çıkış, önbelleğe alınmış ve akıl yürütme belirteci sayıları
- gecikme, durum kodu, yeniden deneme sayısı ve geri dönüş kararı
- tahmini ve sabit maliyet
- veri sınıflandırma etiketi
- politika sürümü ve politika kararının nedeni
- özellik bayrakları istendi ve özellik bayraklarına izin verildi
Gizli trafik için varsayılan olarak ham istemleri ve model çıktılarını depolamaktan kaçının. Hata ayıklama içerik gerektiriyorsa kontrollü bir iş akışı kullanın:
- müşteri veya kiracı onayı
- dar zaman aralığı
- örnekleme sınırı
- düzeltme geçişi
- ayrı erişim kontrolü
- kısa süre sonu
- kimin ve nedenini etkinleştirdiğine ilişkin denetim günlüğü
Bu bir takastır. Ham bilgi istemi günlüklerinin engellenmesi hata ayıklamayı, desteği, kalite incelemesini ve kötüye kullanım soruşturmasını zorlaştırır. Ancak her şeyin varsayılan olarak depolanması, daha geniş bir gizlilik, ihlal ve uyumluluk yüzeyi oluşturur.
6. Adım: dava edilebilir ret nedenlerini iade edin
Genel bir 403 yasak kodu geliştiricileri sinirlendirir ve geçici çözümleri teşvik eder. Makine tarafından okunabilen istikrarlı bir neden ve insan tarafından okunabilen bir açıklama döndürün.
Örnek yanıt:
<ön>Yararlı reddetme kodları şunları içerir:
model_profile_not_zdr_eligibleregion_processing_not_supportedstorage_residency_not_supportedraw_prompt_logging_not_allowedfeature_requires_content_storagefallback_weakens_retention_policycontract_prerequisite_missingcredentials_detected
7. Adım: Gizli atlama değil, istisna iş akışı ekleyin
Bazı istisnalar meşrudur: olaya müdahale, müşteri onaylı hata ayıklama, geçiş testi veya geçici sağlayıcı sınırlaması. Ağ geçidi, istisnaları kalıcı gölge politikasına dönüştürmeden desteklemelidir.
Her istisna şunları içermelidir:
- onaylayan kimliği
- talep eden ekip veya kiracı
- bilet veya risk inceleme bağlantısı
- iş gerekçesi
- izin verilen model profilleri ve özellikleri
- kapsanan veri sınıfları
- son kullanma tarihi
- ek günlük kaydı gereksinimleri
Öneri: istisnaları olağan politikadan daha dar hale getirin. disable_retention_policy=true gibi genel anahtarlardan kaçının. "Kiracı A, uç nokta B için 24 saat boyunca düzeltme ve güvenlik onayıyla hata ayıklama istemi günlüğe kaydetmeye izin ver" gibi kapsamlı geçersiz kılmaları tercih edin.
Operasyonel kontrol listesi
- Sürümlendirilmiş bir sağlayıcı yetenek matrisi oluşturun.
- Sağlayıcı şartları, sözleşme ön koşulları ve elde tutma incelemeleri için bir sahip atayın.
- Uygulamaların veri sınıfını, ikamet gerekliliğini ve istenen özellikleri beyan etmesini zorunlu kılın.
- Varsayılan olarak gizli ve düzenlenmiş trafiği, ham istem günlüğü kaydı olmayacak şekilde ayarlayın.
- Araçları, temel oluşturmayı, dosya yüklemeyi, toplu işlemleri ve depolanan görüşmeleri ayrı yetenek bayrakları olarak temsil edin.
- Birincil yönlendirmeden ve yedek yönlendirmeden önce politika kontrolleri çalıştırın.
- Günlük politikası sürümü, model profili, veri sınıfı, özellik işaretleri ve reddetme nedeni.
- Analitik meta verilerini bilgi istemi ve çıktı içeriğinden ayrı tutun.
- Test temsilcisi CI'da vakalara izin verir ve reddeder.
- Bir sağlayıcı şartları, bölgeleri, uç noktaları veya özellikleri değiştirdiğinde politika değişikliğini inceleyin.
Açık bir şekilde ifade etmek için ödünler
Katı yönlendirme seçenekleri azaltır. ZDR ve ikamet kısıtlamaları en yeni modelin, en düşük maliyetli rotanın veya zengin özelliklere sahip bir uç noktanın kullanılmasını engelleyebilir.
Bölgesel yönlendirme gecikmeyi veya maliyeti artırabilir. En yakın uyumlu bölge, istenilen işleme modunu desteklemeyebilir veya farklı bir sağlayıcı yolu gerektirebilir.
Özellik kapıları geliştiricileri şaşırtıyor. Bir geliştirici yalnızca aramayı etkinleştirdiğini düşünebilir, ancak güvenlik yeni bir saklama davranışı görüyor. Belgeleme ve ret mesajları anlaşmazlıkları azaltır.
İstemlerin en aza indirilmesi hata ayıklamayı karmaşık hale getirir. Ekiplerin, her şeyi saklamadan sorunları araştırmak için düzeltilmiş örneklere, kiracı tarafından onaylanmış hata ayıklama pencerelerine ve güçlü meta verilere ihtiyacı vardır.
Matris bakım gerektirir. Sağlayıcı şartları değişir. Yeni modeller piyasaya çıkıyor. Bölgeler genişliyor. Özellikler betadan üretime geçiyor. Eski bir matris, matris olmamasından daha kötüdür çünkü yanlış güven yaratır.
Öneri nedir ve tahmin nedir?
Öneriler: ağ geçidinde saklamayı zorunlu kılın, yönlendirmeden önce istekleri sınıflandırın, bir sağlayıcı yetenek matrisi oluşturun, saklamayı değiştiren özellikleri politikaya göre engelleyin, varsayılan olarak ham bilgi istemi günlüğe kaydetmeyi önleyin ve her politika kararını sürümlendirin.
Tahmin: Yapay zeka platform ekipleri, model seçiminin bir parçası olarak gizlilik tutumunu giderek daha fazla ele alacak. “Hangi modeli kullanmalıyız?” diye sormak yerine uygulamalar yetenek, maliyet, gecikme, ikamet ve saklama kısıtlamalarını karşılayan bir model profili isteyecektir.
Tahmin: Sağlayıcıya özel gizlilik özellikleri farklılık göstermeye devam edecek. Yalnızca istek ve yanıt formatlarını normalleştiren ağ geçitleri yeterli olmayacak; üretim ekiplerinin de politikanın normalleştirilmesine ihtiyacı olacak.
Harekete geçirilebilir sonuç
Veri saklamaya duyarlı yönlendirme, ayrı bir uyumluluk kontrol paneli değildir. İstek yoluna aittir.
Teslim edilebilecek üç şeyle başlayın: istek duyarlılığı sınıflandırması, sürümlendirilmiş bir sağlayıcı yetenek matrisi ve ZDR, ikamet, ham günlük kaydı, geri dönüş ve saklamayı değiştirme özelliklerine yönelik küçük bir kod olarak politika kuralları kümesi. Ardından ağ geçidinin net reddetme nedenleri döndürmesini sağlayın ve varsayılan olarak ham içeriği depolamadan analizleri koruyun.
Bu tasarım, normalde SDK seçeneklerine, ortam değişkenlerine, sağlayıcı konsollarına ve ekibe özgü kurallara dağılacak kararları merkezileştirir. Ayrıca güvenlik ve platform ekiplerine pratik bir denetim takibi sağlar: hangi isteğe izin verildi, hangi politika sürümü uygulandı, hangi model profili seçildi ve neden.