Çoklu Sağlayıcı LLM API'leri için Veri Saklama Politikası Yönlendiricisi Nasıl Oluşturulur

Çok sağlayıcılı bir Yüksek Lisans yönlendiricisi, önce bir model seçip daha sonra saklama soruları sormamalıdır. Bir destek iş akışı, saklama yok olarak etiketlendiyse ağ geçidinin, istek sınırınızdan ayrılmadan önce seçilen sağlayıcının, uç noktanın, bölgenin, hesap ayarının ve özellik kombinasyonunun bu sözü yerine getirip getiremeyeceğini bilmesi gerekir.

Başarısızlık modunun gözden kaçırılması kolaydır. Bir ekip durum bilgisi olmayan sohbetin tamamlanmasıyla başlar. Rota kabul edilebilir. Daha sonra birisi dosya yüklemeyi, saklanan konuşma geçmişini, web topraklamasını, toplu işlemeyi veya bir vektör deposunu ekler. Model adı aynı kalabilir ancak veri davranışı değişir. Basit bir gecikme veya maliyet yönlendiricisi, düzenlemeye tabi veya müşteri sözleşmesine bağlı istemleri, içeriği iş yükünün izin verdiğinden daha uzun süre depolayan bir yola sessizce gönderebilir.

Pratik çözüm, LLM veri saklama kontrollerini model yönlendirmenin önüne koymaktır. Yönlendiricinin isteği sınıflandırması, standart bir saklama politikasıyla eşleştirmesi, sağlayıcı yeteneklerini filtrelemesi, izin verilmeyen özellikleri engellemesi ve karar için denetlenebilir kanıtlar sunması gerekir.

Tasarım Kısıtlamaları Olarak Değerlendirilecek Gerçekler

Sağlayıcı verilerinin işlenmesi tek tip değildir ve nadiren yalnızca sağlayıcı adı tarafından yakalanır. Saklamaya duyarlı bir yönlendirici tasarlarken aşağıdaki gerçekler önemlidir:

• OpenAI, müşteri kabul etmedikçe API verilerinin modelleri eğitmek veya geliştirmek için kullanılmadığını belirtir. Uygun müşteriler, onaylandıktan sonra kuruluş veya proje düzeyinde Değiştirilmiş Kötüye Kullanım İzleme veya Sıfır Veri Saklamayı yapılandırabilir.
• OpenAI'ın Sıfır Veri Saklama özelliği, Yanıtlar ve Sohbet Tamamlamalar için store parametresinin yanlış olarak değerlendirilmesi de dahil olmak üzere uç nokta davranışını değiştirir, ancak bazı uç noktalar ve yetenekler hâlâ uygulama durumunu saklayabilir ve Sıfır Veri Saklamaya uygun değildir.
• Anthropic, Claude API için Sıfır Veri Saklamanın, API yanıtı döndürüldükten sonra müşteri istemlerini veya yanıtlarını beklemede olarak saklamadığını belgeliyor, ancak kapsam uç noktaya ve özellik uygunluğuna bağlıdır.
• Anthropic, bazı Claude özelliklerin veya kapsam dahilindeki modellerin saklama gerektirebileceğini ve özellikle izin verilmedikçe Sıfır Veri Saklama kapsamında kullanılamayabileceğini belirtir.
• Google Cloud, Gemini Enterprise Agent Platform verilerinin AI/ML modellerini önceden izin veya talimat olmadan eğitmek veya ince ayar yapmak için kullanılmadığını, ancak sıfır veri saklamanın belirli eylemler gerektirdiğini ve bazı gelişmiş özellikler için mümkün olmayabileceğini belgelemektedir.
• Google Bulut, Google Arama ile Temellendirmenin türetilmiş sorgu ve bağlam günlüklerini üç güne kadar sakladığını ve bu depolamayı bu özellik için devre dışı bırakamayacağını belgeler. Sıfır veri saklamanın gerekli olduğu durumlarda Kuruluşlar için Web Topraklaması önerilir.
• Microsoft, Azure tarafından satılan Azure'da barındırılan modellerin OpenAI veya diğer model sağlayıcılara bilgi istemleri ve tamamlamalar sunmadığını ve bunları izin veya talimat olmadan temel modelleri eğitmek için kullanmadığını belgeler.
• Microsoft, Azure dağıtım türünün işleme konumunu etkilediğini belgeler. Global dağıtımlar, modelin dağıtıldığı herhangi bir coğrafyadaki istemleri ve yanıtları işleyebilirken DataZone dağıtımları, işlemeyi seçilen bölgeyle sınırlandırır. Depolanan veriler müşterinin belirlediği coğrafyada kalır.
• Microsoft, bazı durum bilgisi olan Azure özelliklerinin, dosyalar, vektör depoları, Yanıt mesaj geçmişi, Asistan iş parçacıkları, toplu işleme girişleri ve depolanan tamamlamalar dahil olmak üzere verileri depoladığını belgeler.
• Onaylı müşterilerin kötüye kullanım izlemeyi değiştirebileceğini ve kötüye kullanım izleme veri depolama kapalıyken Azure portalının veya CLI'in ContentLogging=false gösterebileceğini gösteren Microsoft belgeleri.

Bunlar uç ayrıntılar değil. Bunlar, yönlendiricinin uç noktayı, özelliği, hesap onayını ve bölgeyi birlikte değerlendirmesi gerektiği anlamına gelir. "ZDR etkin" gibi sağlayıcı genelindeki bir etiket, üretim politikası için fazla kaba bir yaklaşımdır.

Referans Mimarisi

Saklamaya duyarlı bir çok modelli yapay zeka API ağ geçidi, istek yolunda beş bileşene ihtiyaç duyar:

1. İstek sınıflandırıcısı: veri hassasiyetini, kiracı sözleşmesini, bölge gereksinimlerini, özellik kullanımını, dosya girişlerini, araç kullanımını ve günlük kaydı izinlerini ayıklar.
2. Politika çözümleyici: isteği genellikle kiracı, proje, ortam, API anahtarı ve iş yükü meta verilerinden gelen standart bir saklama politikasıyla eşleştirir.
3. Sağlayıcı yetenek kaydı: tarihli kanıtlarla birlikte sağlayıcı, uç nokta, model, özellik, bölge ve hesap düzeyinde saklama yeteneklerini kaydeder.
4. Politika değerlendirici: aday rotaları filtreler ve onaylanmış bir rotayı veya bir neden koduyla birlikte politika reddini döndürür.
5. Denetim verici: seçilen rotayı, eşleşen politikayı, yetenek varsayımlarını, bölgeyi, depolama işaretlerini ve içerik günlüğü modunu kaydeder.

Bu mimari, saklama ve ikamet kararlarını maliyet, gecikme ve geri dönüşten ayrı tutar. Maliyet yönlendirme yine de gerçekleşebilir, ancak bu yalnızca saklama politikasını karşılayan yollar kümesi içinde gerçekleşir.

Kurallı bir Saklama Politikası Tanımlayın

Sağlayıcıdan bağımsız bir politika nesnesiyle başlayın. Tek bir sağlayıcının terminolojisini dahili sözleşmenize kopyalamayın. Dahili politikanız, belirli bir sağlayıcının kontrolü nasıl pazarladığını değil, iş yükünün ne yapmasına izin verildiğini açıklamalıdır.

{
  "policy_id": "support_no_retention_eu_v1",
  "max_content_retention": "none_after_response",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["EU"],
  "stateful_storage_allowed": false,
  "file_storage_allowed": false,
  "grounding_allowed": false,
  "batch_processing_allowed": false,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "route_decision_with_provider_evidence"
}

Daha az kısıtlı iş yükleri için, eksik alanlar yerine açık bir rahatlama kullanın:

{
  "policy_id": "internal_analytics_standard_v1",
  "max_content_retention": "30_days",
  "training_allowed": false,
  "human_review_allowed": false,
  "allowed_regions": ["US", "EU"],
  "stateful_storage_allowed": true,
  "file_storage_allowed": true,
  "grounding_allowed": true,
  "batch_processing_allowed": true,
  "full_content_logging_allowed": false,
  "redacted_content_logging_allowed": true,
  "audit_level": "metadata_and_decision"
}

Önemli alanlar yalnızca saklama süresi değildir. Durum bilgisi olan özellikler, dosyalar, topraklama, toplu işleme ve günlük kaydı modunun tümü bir rotanın kabul edilebilir olup olmadığını etkiler.

Sağlayıcı Yetenek Kaydını Oluşturun

Yetenek kaydı, yönlendiricinin doğruluk kaynağıdır. Sağlayıcı bağdaştırıcılarına dağılmadan, kontrollü bir yapılandırma olarak sürdürülmelidir.

Yararlı bir kayıt şunları içerir:

• provider: sağlayıcı veya bulut platformu.
• account_scope: bir ayarın onaylandığı kuruluş, proje, dağıtım, abonelik veya kiracı.
• endpoint: sohbet, yanıtlar, mesajlar, toplu iş, dosyalar, asistanlar, yerleştirmeler, topraklama, vektör deposu veya diğer API yüzeyi.
• model_family ve isteğe bağlı model_id: çünkü model uygunluğu farklılık gösterebilir.
• region_mode: küresel, bölgesel, veri bölgesi, müşteri tarafından belirlenen coğrafya veya sağlayıcıya özel eşdeğeri.
• content_retention: yanıttan sonra depolama yok, kötüye kullanımı izleyen saklama, uygulama durumu saklama, sabit süreli türetilmiş günlükler veya bilinmiyor.
• training_use: varsayılan olarak devre dışı, etkinleştirildi veya bilinmiyor.
• human_review: etkin, değiştirildi, devre dışı bırakıldı veya bilinmiyor.
• stateful_storage: uç noktanın mı yoksa özelliğin mi konuşma durumunu, dosyaları, vektör verilerini, tamamlamaları veya toplu girişleri depolayıp depolamadığı.
• feature_flags: topraklama, dosyalar, araçlar, önbellek, depolanan çıktılar, toplu iş, yardımcılar veya eşdeğer yetenekler.
• evidence: kaynak belge adı, URL, alma tarihi ve sahibi inceleme tarihi.

Örnek:

{
  "capability_id": "azure-openai-gpt4o-datazone-chat-zdrlike-v3",
  "provider": "azure_openai",
  "account_scope": "prod-subscription-123",
  "endpoint": "chat_completions",
  "model_family": "gpt-4o",
  "region_mode": "datazone_eu",
  "content_retention": "abuse_monitoring_disabled_when_contentlogging_false",
  "training_use": "disabled_without_permission",
  "human_review": "modified_abuse_monitoring_approved",
  "stateful_storage": false,
  "features": {
    "files": false,
    "vector_store": false,
    "stored_completions": false,
    "grounding": false,
    "batch": false
  },
  "evidence": {
    "source": "provider_data_privacy_and_abuse_monitoring_docs",
    "retrieved_at": "2026-10-08",
    "review_owner": "security-architecture"
  }
}

Öneri, hassas iş yükleri için bilinmeyenin reddedilme olarak ele alınmasıdır. Bir yetenek kaydında saklama alanı, bölge modu veya özellik uygunluğu bulunmuyorsa katı politikaları karşılamamalıdır.

Yönlendirmeden Önce İsteği Sınıflandırın

Sınıflandırma model seçiminden önce yapılmalıdır. İyi bir sınıflandırıcı, statik meta verileri ve istek incelemesini birleştirir:

• API anahtar kapsamı: kiracı, ekip, ortam, uygulama ve iş yükü türü.
• Sözleşme etiketleri: saklama yok, yalnızca AB'ye özel, HIPAA benzeri kontroller, mali veriler, müşteriye özel veya yalnızca dahili.
• Yük türü: serbest metin, belge, resim, dosya referansı, yerleştirme girişi, araç sonucu veya alınan bağlam.
• Özellik kullanımı: web topraklama, dosya yükleme, vektör depolama, toplu iş, saklanan konuşma geçmişi, araç çağrıları veya yanıt depolama.
• Günlüğe kaydetme modu: tam içeriğe izin verilir, düzenlenmiş içeriğe izin verilir, yalnızca meta verilere izin verilir veya uygulama günlüğü içeriğine izin verilmez.
• Bölgesel ipuçları: kullanıcı konumu, kiracı veri yerleşimi, proje bölgesi veya dağıtım bölgesi.

Yalnızca otomatik hassas veri algılamaya güvenmeyin. Birinci kaynak olarak API anahtarından veya projeden bildirilen iş yükü politikasını kullanın, ardından yük risk sinyalleri içerdiğinde politikayı sıkılaştırmak için sınıflandırıcıları kullanın.

function resolvePolicy(request) {
  const base = policyForApiKey(request.apiKeyId);
  const tenant = tenantContractPolicy(request.tenantId);
  const features = detectRequestedFeatures(request);
  const sensitivity = classifyPayload(request);

  return strictestApplicablePolicy([base, tenant, features, sensitivity]);
}

Uygulamada bu, müşteri destek anahtarının varsayılan olarak saklama gerektirmeyeceği, dahili deneme anahtarının ise daha geniş yönlendirmeye izin verebileceği anlamına gelir. Aynı destek anahtarı bir dosya yükleme girişiminde bulunursa, onaylanmış dosya özellikli bir yol mevcut olmadığı sürece etkili politika file_storage_allowed=false içermelidir.

Maliyet veya Gecikme Yönlendirmesinden Önce Politikayı Değerlendirin

Değerlendirici filtre görevi görmelidir. Bir politika, istek özellikleri ve aday sağlayıcı rotalarını alır. Yalnızca politikaya uyan rotaları döndürür.

function eligibleRoutes(request, policy, capabilities) {
  return capabilities.filter((route) => {
    if (!regionAllowed(route, policy.allowed_regions)) return false;
    if (!retentionAllowed(route, policy.max_content_retention)) return false;
    if (!trainingAllowed(route, policy.training_allowed)) return false;
    if (!humanReviewAllowed(route, policy.human_review_allowed)) return false;
    if (request.usesFiles && !policy.file_storage_allowed) return false;
    if (request.usesFiles && route.features.files !== true) return false;
    if (request.usesGrounding && !policy.grounding_allowed) return false;
    if (request.requiresState && !policy.stateful_storage_allowed) return false;
    if (route.content_retention === "unknown") return false;
    return true;
  });
}

function routeRequest(request) {
  const policy = resolvePolicy(request);
  const candidates = capabilityRegistry.findByModelIntent(request.modelIntent);
  const eligible = eligibleRoutes(request, policy, candidates);

  if (eligible.length === 0) {
    return deny("RETENTION_POLICY_NO_ELIGIBLE_ROUTE", policy.policy_id);
  }

  return chooseByCostLatencyAndHealth(eligible);
}

Bu sıralama önemlidir. Geri dönüş yönlendirmesi, kesinti sırasında uygun olmayan bir sağlayıcıya atlamamalıdır. Toplu yönlendirme, bekletme gerektirmeyen bir isteği eşzamansız bir iş deposuna taşımamalıdır. Politika yasakladığında, türetilmiş günlükleri kullanıma sunan bir özelliği topraklama açmamalıdır.

Platformunuz OpenAI uyumlu bir çoklu model API sunuyorsa uyumluluk katmanını dürüst tutun: aynı istek gövdesi farklı sağlayıcıya özgü özellikler için derlenebilir. Politika değerlendiricisinin yalnızca orijinal SDK şeklini değil, derlenmiş isteği de incelemesi gerekir.

Riskli Özellik Kombinasyonlarını Açıkça Engelleyin

En güvenli uygulama, bilinen yüksek riskli kombinasyonlar için açık reddetme kuralları oluşturmaktır. Örnekler:

• NO_RETENTION + FILE_UPLOAD: belirli dosya uç noktası ve hesap ayarı politika için onaylanmadıkça reddet.
• NO_RETENTION + VECTOR_STORE: vektör deposu kendi kontrollü depolama alanınızda olmadığı ve sağlayıcı hiçbir zaman kalıcı dosya durumu almadığı sürece reddet.
• NO_RETENTION + STORED_RESPONSE: yanıt depolama işaretlerini kapatmaya zorla veya uç nokta depolamayı devre dışı bırakamazsa reddet.
• EU_ONLY + GLOBAL_DEPLOYMENT: İşlemenin izin verilen bölge veya veri bölgesi dışında gerçekleşip gerçekleşmeyeceğini reddet.
• NO_RETENTION + WEB_GROUNDING: temellendirme özelliğinin türetilmiş sorgu veya bağlam günlüklerini politikanın ötesinde depolayıp depolamadığını reddet.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: uygulama günlüklerinden ve izlemelerinden bilgi istemi ve tamamlama içeriğini gizler.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: Özellik, hesabın onaylı kontrolleri kapsamında özellikle uygun olmadığı sürece reddet.

Belirli hataları döndür. Yararlı bir reddetme, geliştiriciye neyin başarısız olduğunu ve hangi onaylanmış alternatiflerin mevcut olduğunu bildirir.

{
  "error": {
    "code": "RETENTION_POLICY_DENIED",
    "reason": "NO_RETENTION_POLICY_DISALLOWS_FILE_STORAGE",
    "policy_id": "support_no_retention_eu_v1",
    "requested_feature": "file_upload",
    "approved_alternatives": [
      "send extracted text without provider file storage",
      "use internal document retrieval with metadata-only provider call",
      "request policy approval for controlled file processing"
    ]
  }
}

Çıkarım Günlüğünü Operasyonel Telemetriden Ayırın

Saklama politikası, ağ geçidini kör olmaya zorlamamalıdır. Genellikle istem veya tamamlama içeriğini depolamadan operasyonel telemetriyi sürdürebilirsiniz.

Katı iş yükleri için şunu koruyun:

• istek kimliği ve izleme kimliği;
• kiracı, proje, API anahtar ve iş yükü tanımlayıcıları;
• politika kimliği ve politika sürümü;
• kullanılan sağlayıcı, uç nokta, model, dağıtım ve bölge;
• istenen ve izin verilen özellik işaretleri;
• karar nedeni kodları;
• jeton sayıları, gecikme, durum kodu ve maliyet meta verileri;
• politika tarafından onaylanması durumunda tekilleştirme için karmalar veya kararlı parmak izleri.

Bastır veya reddet:

• ham istemler;
• ham tamamlamalar;
• yüklenen dosya içeriği;
• müşteri verilerini içeren araç çıktıları;
• hassas sistemlerden bağlam alındı;
• sağlayıcı içeriği kopyalayan yüklerde hata ayıklama yapar.

Bu, saklama yönlendirmesinin sağlayıcıdan bağımsız LLM gözlemlenebilirliğine bağlandığı yerdir. Gözlemlenebilirlik, hassas içeriği koruyan sistem kümesini genişletmeden, olanları kanıtlamalıdır.

Her Karar İçin Denetim Kanıtı Yayınlayın

Denetim kaydı, bir rotaya neden izin verildiğini veya reddedildiğini açıklamalıdır. Yararlı olması için tam içeriğe ihtiyacı yoktur.

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_42",
  "policy_id": "support_no_retention_eu_v1",
  "policy_version": 7,
  "decision": "allow",
  "provider": "anthropic",
  "endpoint": "messages",
  "model_family": "claude",
  "region_mode": "approved_region",
  "features": {
    "files": false,
    "grounding": false,
    "stateful_storage": false,
    "batch": false
  },
  "logging_mode": "metadata_only",
  "capability_record_id": "anthropic-claude-messages-zdr-v5",
  "capability_evidence_date": "2026-10-08",
  "reason_codes": [
    "POLICY_MATCHED_NO_RETENTION",
    "REGION_ALLOWED",
    "STATELESS_ENDPOINT",
    "CONTENT_LOGGING_SUPPRESSED"
  ]
}

Reddedilen istekler için decision=deny ile aynı yapıyı ve REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY veya STATEFUL_STORAGE_NOT_ALLOWED gibi neden kodlarını koruyun.

Saklama Kuralları için Sözleşme Testlerini Kullanın

Saklama yönlendirmesinde otomatik testler bulunmalıdır. Önemli testler yalnızca bireysel sağlayıcılara yönelik birim testleri değildir; sağlayıcı kombinasyonları genelinde politika davranışına yönelik sözleşme testleridir.

Yüksek değerli test senaryoları şunları içerir:

• Saklamama politikası ve dosya yükleme, onaylanmış belirli bir dosya özellikli yol mevcut olmadığı sürece reddedilmelidir.
• Yalnızca AB politikası ve küresel dağıtım, model başka şekilde mevcut olsa bile reddedilmelidir.
• Sıfır saklama politikası ve depolanan konuşma geçmişi, desteklendiğinde depolamayı reddetmeli veya zorla kapatılmalıdır.
• Türetilmiş günlük saklama özelliğine sahip temellendirme özelliği, saklamama politikası kapsamında reddedilmelidir.
• Yalnızca meta veri günlük kaydı politikası, izlemelerden, günlüklerden ve hata raporlarından bilgi istemi ve tamamlama içeriğini bastırmalıdır.
• Bilinmeyen saklama süresine sahip sağlayıcı yetenek kaydı, düzenlemeye tabi iş yükleri için reddedilmelidir.
• Sağlayıcı kesintisinden sonra yedek, uygun rota kümesinin içinde kalmalıdır.
• Toplu uç nokta giriş dosyalarını politikanın izin verdiğinden daha uzun süre depoladığında toplu işleme reddedilmelidir.

Ayrıca kaymayı da test edin. Bir yetenek kaydı değiştiğinde sistem, değişiklik üretime ulaşmadan önce hangi politikaların ve rotaların etkilendiğini göstermelidir.

Operasyonel Sahiplik

Zor kısmı ilk değerlendiriciyi yazmak değil. Kayıt defterini güncel tutuyor ve belgelenmemiş istisnaları engelliyor.

Şunların sahiplerini atayın:

• sağlayıcı dokümantasyonu inceleme temposu;
• değiştirilmiş kötüye kullanım izleme veya sıfır veri saklama gibi hesap düzeyindeki kontroller için onay durumu;
• bölgesel dağıtım envanteri;
• dosyalar, vektör depoları, temellendirme, toplu ve depolanan yanıtlar için özellik uygunluğu;
• politika istisnası iş akışı;
• kayıt saklama ve erişim kontrolünü denetleme;
• geliştiricinin karşılaştığı hata mesajları ve onaylanmış alternatifler.

Her yetenek kaydının bir inceleme tarihi olmalıdır. Süresi dolarsa, katı politikalar ona güvenmeyi bırakmalı veya manuel onay gerektirmelidir. Sağlayıcı belgeleri ve özellik davranışı, bunun statik bir yapılandırma olamayacak kadar sık değişmesine neden olur.

Ödünleşmeler

Katı bir saklama yönlendiricisi, mevcut model seçeneklerini azaltır. Bazı önizleme modelleri, durum bilgisi olan API'ler, temel oluşturma araçları ve dosya iş akışları hassas iş yükleri için kullanılamayacaktır. Kontrolün amacı budur ancak ürün ekiplerinin net alternatiflere ihtiyacı vardır.

En hızlı dağıtımın küresel olduğu ancak iş yükünün belirli bir coğrafya veya veri bölgesi gerektirdiği durumlarda, bölgesel yönlendirme gecikmeyi veya maliyeti artırabilir. Ekiplerin bir isteğin neden daha pahalı veya daha yavaş bir rota kullandığını anlayabilmesi için bunu telemetride görünür hale getirin.

Durum bilgisi olan özelliklerin engellenmesi ekipleri kendi bellek katmanlarını oluşturmaya itebilir. Bu doğru mimari olabilir ancak yine de depolama politikasına, silme iş akışlarına, şifrelemeye, erişim kontrolüne ve denetim günlüklerine ihtiyaç duyar. Durumu sağlayıcının dışına taşımak yönetim işini ortadan kaldırmaz.

İstem ve tamamlama düzeltmesi hassas verileri korur, ancak hata ayıklamayı ve kalite incelemesini zayıflatır. Tekrarlanabilir istek meta verilerini, deterministik test düzeneklerini, izin verilen iş yükleri için kontrollü örneklemeyi ve politikanın izin verdiği durumlarda belgelenmiş kırılmaya karşı erişimi kullanın.

Öneriler

• Saklama ve yerleşimi, işleme sonrası kontrol olarak değil, model yönlendirmeden önce zorunlu kılın.
• Sağlayıcı, uç nokta, özellik, bölge ve hesap onayı düzeyinde model yetenekleri.
• Düzenlemeye tabi veya müşteri sözleşmesine bağlı iş yükleri için varsayılan olarak reddetme davranışını kullanın.
• Dosya yüklemeyi, vektör depolarını, web topraklamayı, toplu işlemeyi ve depolanan görüşme geçmişini ayrı politika boyutları olarak ele alın.
• İstem ve tamamlama içeriğinin bastırılması gerektiğinde bile operasyonel telemetriyi koruyun.
• Politikayı, rotayı, yetenek kanıtlarını, bölgeyi, depolama işaretlerini ve neden kodlarını içeren denetim kayıtlarını yayınlayın.
• Yüksek riskli özellik kombinasyonları ve yedek davranışlar için sözleşme testleri yazın.

Tahmin: Saklama Yönlendirmesi Standart Bir Ağ Geçidi Katmanı Olacak

Muhtemelen gidişat, saklama yönlendirmesinin kurumsal LLM platformlarında oran sınırlarına, bütçe kontrollerine ve gözlemlenebilirliğe benzer şekilde standart bir katman haline gelmesidir. Sağlayıcılar daha fazla durum bilgisi olan araçlar, topraklama seçenekleri, önbellekler, dosyalar, aracılar ve yönetilen bellek özellikleri ekledikçe, güvenli rota model adına daha az, tam yürütme yoluna daha fazla bağlı olacaktır.

Bu bir tahmindir, mevcut evrensel bir gereklilik değildir. Mevcut gereksinim daha basittir: Ekibiniz saklama, bölgesel işleme, eğitim kullanmama veya insan incelemesi yapmama sözü verirse, ağ geçidinizin her isteğin bu kısıtlamalara uyduğunu kanıtlayacak yeterli politika mantığına ve kanıta ihtiyacı vardır.

Uygulanabilir Sonuç

Sağlayıcı seçiminin önünde bir politika kapısı olarak saklama yönlendiricisini oluşturun. Kurallı bir saklama politikası tanımlayın, yönlendirmeden önce her isteği sınıflandırın, tarihli bir sağlayıcı yetenek kaydı tutun, güvenli olmayan kombinasyonları varsayılan olarak reddedin ve hassas içeriği saklamadan denetim kanıtlarını günlüğe kaydedin.

Tasarım hedefi her zaman güvenli olan bir sağlayıcı bulmak değildir. Amaç, belirli bir hesap ve bölge kapsamındaki belirli bir uç nokta ve özellik kümesini kullanan belirli bir isteğin, gönderilmeden önce politikayı karşıladığını kanıtlamaktır.

İlgili okuma

• sağlayıcıdan bağımsız LLM gözlemlenebilirlik tasarımı