Cum să construiți un router de politică de reținere a datelor pentru API-uri LLM cu mai mulți furnizori

Un router LLM cu furnizori multipli nu trebuie să aleagă mai întâi un model și să pună întrebări de reținere mai târziu. Dacă un flux de lucru de asistență este etichetat ca fără reținere, gateway-ul trebuie să știe dacă furnizorul selectat, punctul final, regiunea, setarea contului și combinația de caracteristici pot onora acea promisiune înainte ca solicitarea să părăsească granița dvs.

Modul de eșec este ușor de ratat. O echipă începe cu finalizarea chatului fără stat. Traseul este acceptabil. Mai târziu, cineva adaugă încărcare de fișiere, istoricul conversațiilor stocat, împământare web, procesare în loturi sau un magazin de vectori. Numele modelului poate rămâne același, dar comportamentul datelor se modifică. Un simplu router cu latență sau cost poate trimite în tăcere solicitări reglementate sau legate de contractul clientului către o cale care stochează conținut mai mult decât permite volumul de lucru.

Remedierea practică este să puneți controalele de păstrare a datelor LLM în fața rutării modelului. Routerul ar trebui să clasifice cererea, să o potrivească cu o politică canonică de păstrare, să filtreze capacitățile furnizorului, să blocheze funcțiile interzise și să emită dovezi auditabile pentru decizie.

Fapte de tratat ca constrângeri de proiectare

Gestionarea datelor de la furnizor nu este uniformă și rareori este capturată numai după numele furnizorului. Următoarele fapte contează atunci când proiectați un router care conștientizează reținerea:

• OpenAI afirmă că API datele nu sunt utilizate pentru instruirea sau îmbunătățirea modelelor decât dacă clientul acceptă. Clienții eligibili pot configura Monitorizarea abuzului modificat sau Reținerea zero a datelor la nivel de organizație sau proiect după aprobare.
Retenția de date zero a
• OpenAI modifică comportamentul punctelor finale, inclusiv tratarea parametrului store pentru răspunsuri și finalizări de chat ca fiind fals, dar unele puncte finale și capabilități pot stoca în continuare starea aplicației și nu sunt eligibile pentru retenția de date zero.
• Anthropic documentează Reținerea zero a datelor pentru Claude API ca nu stochează solicitările clienților sau răspunsurile în repaus după ce răspunsul API este returnat, dar acoperirea depinde de punctul final și de eligibilitatea funcției.
• Anthropic afirmă că unele Claude funcții sau modele acoperite pot necesita păstrare și pot fi indisponibile în condițiile zero păstrare a datelor, cu excepția cazului în care sunt autorizate în mod specific.
• Google Cloud documentează că Gemini Datele Enterprise Agent Platform nu sunt utilizate pentru a antrena sau a ajusta modelele AI/ML fără permisiunea sau instrucțiunile prealabile, dar păstrarea zero a datelor necesită acțiuni specifice și este posibil să nu fie posibilă pentru unele funcții avansate.
• Google Cloud documentează că Grounding with Google Search stochează interogări derivate și jurnalele de context timp de până la trei zile și nu poate dezactiva acea stocare pentru acea funcție. Recomanda Web Grounding for Enterprise atunci când nu este necesară păstrarea datelor.
• Documentele Microsoft conform cărora modelele găzduite de Azure vândute de Azure nu fac solicitări și completări disponibile pentru OpenAI sau pentru alți furnizori de modele și nu le utilizează pentru a instrui modele de fundație fără permisiune sau instrucțiuni.
• Microsoft documentează că tipul de implementare Azure afectează locația de procesare. Implementările globale pot procesa solicitări și răspunsuri în orice zonă geografică în care este implementat modelul, în timp ce implementările DataZone constrâng procesarea la zona selectată. Datele stocate rămân în zona geografică desemnată de client.
• Microsoft documentează că unele funcții Azure cu stare de stare stochează date, inclusiv fișiere, stocări de vectori, istoricul mesajelor de răspunsuri, fire de execuție a asistenților, intrări de procesare în lot și completări stocate.
• Documentele Microsoft prin care clienții aprobați pot modifica monitorizarea abuzurilor și pe care portalul Azure sau CLI le pot afișa ContentLogging=false când stocarea datelor de monitorizare a abuzurilor este dezactivată.

Acestea nu sunt detalii de margine. Ele înseamnă că routerul trebuie să evalueze împreună punctul final, caracteristica, aprobarea contului și regiunea. O etichetă la nivelul întregului furnizor, cum ar fi „ZDR activat” este prea grosieră pentru politica de producție.

Arhitectură de referință

Un gateway multi-model AI API care conștientizează reținerea are nevoie de cinci componente în calea solicitării:

1. Clasificator de solicitări: extrage sensibilitatea datelor, contractul chiriașului, cerințele regiunii, utilizarea caracteristicilor, introducerea fișierelor, utilizarea instrumentelor și permisiunile de înregistrare.
2. Rezolvarea politicii: mapează cererea la o politică canonică de păstrare, de obicei de la chiriaș, proiect, mediu, API cheie și metadatele încărcăturii de lucru.
3. Registrul de capabilități ale furnizorului: înregistrează capabilitățile de păstrare ale furnizorului, punctului final, modelului, caracteristicilor, regiunii și la nivel de cont cu dovezi datate.
4. Evaluator de politici: filtrează rutele candidate și returnează fie o rută aprobată, fie o respingere a politicii cu un cod motiv.
5. Emițător de audit: înregistrează ruta aleasă, politica potrivită, ipotezele privind capacitatea, regiunea, indicatoarele de stocare și modul de înregistrare a conținutului.

Această arhitectură menține deciziile de păstrare și rezidență separate de cost, latență și rezervă. Dirijarea costurilor poate avea loc în continuare, dar numai în setul de rute care îndeplinesc politica de păstrare.

Definiți o politică canonică de păstrare

Începeți cu un obiect de politică neutru pentru furnizor. Nu copiați terminologia unui furnizor în contractul dvs. intern. Politica dvs. internă ar trebui să descrie ceea ce este permis să facă volumul de muncă, nu modul în care un anumit furnizor comercializează un control.

{
  "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"
}

Pentru sarcini de lucru mai puțin restricționate, utilizați relaxarea explicită în loc de câmpurile lipsă:

{
  "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"
}

Câmpurile importante nu sunt doar durata de păstrare. Caracteristicile cu stare, fișierele, împământarea, procesarea în lot și modul de înregistrare toate afectează dacă o rută este acceptabilă.

Construiți registrul de capabilități ale furnizorului

Registrul de capabilități este sursa de adevăr a routerului. Ar trebui să fie menținută ca configurație controlată, nu împrăștiată prin adaptoarele furnizorului.

O înregistrare utilă include:

• provider: furnizor sau platformă cloud.
• account_scope: organizație, proiect, implementare, abonament sau chiriaș în care o setare este aprobată.
• endpoint: chat, răspunsuri, mesaje, lot, fișiere, asistenți, încorporare, împământare, stocare vector sau altă API suprafață.
• model_family și opțional model_id: deoarece eligibilitatea modelului poate fi diferită.
• region_mode: global, regional, zonă de date, geografie desemnată de client sau echivalent specific furnizorului.
• content_retention: fără stocare după răspuns, păstrarea monitorizării abuzului, păstrarea stării aplicației, jurnalele derivate cu durată fixă sau necunoscut.
• training_use: dezactivat implicit, înscriere sau necunoscut.
• human_review: activat, modificat, dezactivat sau necunoscut.
• stateful_storage: dacă punctul final sau caracteristica stochează starea conversației, fișiere, date vectoriale, completări sau intrări în lot.
• feature_flags: împământare, fișiere, instrumente, cache, ieșiri stocate, lot, asistenți sau capabilități echivalente.
• evidence: numele documentului sursă, adresa URL, data preluării și data examinării proprietarului.

Exemplu:

{
  "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"
  }
}

Recomandarea este să tratați necunoscutul ca refuz pentru sarcinile de lucru sensibile. Dacă o înregistrare a capacității nu are un câmp de păstrare, un mod de regiune sau eligibilitate pentru caracteristici, nu ar trebui să îndeplinească politici stricte.

Clasificați solicitarea înainte de rutare

Clasificarea ar trebui să aibă loc înainte de selectarea modelului. Un clasificator bun combină metadatele statice și inspecția solicitărilor:

• API domeniu cheie: chiriaș, echipă, mediu, aplicație și tip de sarcină de lucru.
• Etichete de contract: fără reținere, numai în UE, controale asemănătoare HIPAA, date financiare, confidențiale clienților sau numai interne.
• Tip de încărcare utilă: text liber, document, imagine, referință la fișier, intrare încorporată, rezultat instrument sau context preluat.
• Utilizarea caracteristicilor: conectare pe web, încărcare de fișiere, stocare vector, operație în lot, istoric de conversații stocat, apeluri de instrumente sau stocare răspunsuri.
• Mod de înregistrare: conținut complet permis, conținut redactat permis, numai metadate sau fără conținut de jurnal de aplicație.
• Sugestii regionale: locația utilizatorului, rezidența datelor chiriașilor, regiunea proiectului sau regiunea de implementare.

Nu vă bazați doar pe detectarea automată a datelor sensibile. Utilizați politica de încărcare de lucru declarată din cheia API sau din proiect ca sursă principală, apoi utilizați clasificatori pentru a înăspri politica atunci când sarcina utilă conține semnale de risc.

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]);
}

În practică, aceasta înseamnă că o cheie de asistență pentru clienți poate fi implicit fără reținere, în timp ce o cheie de experimentare internă poate permite o rutare mai largă. Dacă aceeași cheie de asistență încearcă să încarce un fișier, politica efectivă ar trebui să includă file_storage_allowed=false, cu excepția cazului în care există o rută aprobată capabilă de fișiere.

Evaluați politica înainte de rutarea costului sau latenței

Evaluatorul ar trebui să funcționeze ca un filtru. Primește o politică, funcții de solicitare și rute de furnizor candidat. Returnează numai rutele care îndeplinesc politica.

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);
}

Această comandă contează. Rutarea de rezervă nu ar trebui să treacă la un furnizor neeligibil în timpul unei întreruperi. Rutarea în lot nu ar trebui să mute o solicitare fără reținere într-un depozit de joburi asincron. Conectarea la pământ nu ar trebui să activeze o funcție care introduce jurnalele derivate atunci când politica o interzice.

Dacă platforma dvs. expune un model multiplu compatibil OpenAIAPI, păstrați nivelul de compatibilitate sincer: același corp de solicitare se poate compila pentru diferite caracteristici native ale furnizorului. Evaluatorul de politici trebuie să inspecteze solicitarea compilată, nu doar forma originală SDK.

Blocați în mod explicit combinațiile de caracteristici riscante

Cea mai sigură implementare este crearea unor reguli explicite de refuz pentru combinațiile cunoscute cu risc ridicat. Exemple:

• NO_RETENTION + FILE_UPLOAD: refuzați, cu excepția cazului în care punctul final al fișierului și setarea contului sunt aprobate pentru politică.
• NO_RETENTION + VECTOR_STORE: refuză, cu excepția cazului în care magazinul de vectori se află în interiorul propriului spațiu de stocare controlat și furnizorul nu primește niciodată starea fișierului persistent.
• NO_RETENTION + STORED_RESPONSE: forțați semnalizările de stocare a răspunsului dezactivate sau respinse dacă punctul final nu poate dezactiva stocarea.
• EU_ONLY + GLOBAL_DEPLOYMENT: refuzați dacă procesarea poate avea loc în afara regiunii sau zonei de date permise.
• NO_RETENTION + WEB_GROUNDING: refuzați dacă caracteristica de împământare stochează interogări derivate sau jurnalele de context dincolo de politică.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: suprimați conținutul de solicitare și finalizare din jurnalele și urmele aplicației.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: respinge, cu excepția cazului în care funcția este eligibilă în mod specific conform controalelor aprobate ale contului.

Return anumite erori. O refuz util îi spune dezvoltatorului ce a eșuat și ce alternative aprobate există.

{
  "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"
    ]
  }
}

Separați înregistrarea inferenței de telemetria operațională

Politica de păstrare nu ar trebui să forțeze gateway-ul să devină oarbă. De obicei, puteți păstra telemetria operațională fără a stoca conținut de solicitare sau finalizare.

Pentru sarcini de lucru stricte, păstrați:

• ID de solicitare și ID de urmărire;
• identificatori de chiriaș, proiect, API cheie și încărcătură de lucru;
• ID-ul politicii și versiunea politicii;
• furnizorul, punctul final, modelul, implementarea și regiunea utilizate;
• semnalele de caracteristică solicitate și permise;
• coduri de motiv pentru decizii;
• numărările de simboluri, latența, codul de stare și metadatele costurilor;
• hash-uri sau amprente stabile pentru deduplicare, dacă sunt aprobate prin politică.

Suprimați sau eliminați:

• solicitari brute;
• finalizări brute;
• conținutul fișierului încărcat;
• ieșiri de instrumente care conțin date despre clienți;
• context preluat din sisteme sensibile;
• încărcături utile de depanare a furnizorului care dublează conținut.

Aici este locul în care rutarea retenției se conectează la observabilitate LLM neutră pentru furnizor. Observabilitatea ar trebui să dovedească ceea ce s-a întâmplat fără a extinde setul de sisteme care păstrează conținut sensibil.

Emite probe de audit pentru fiecare decizie

O înregistrare de audit ar trebui să explice de ce a fost permisă sau refuzată o rută. Nu are nevoie de conținut complet pentru a fi util.

{
  "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"
  ]
}

Pentru solicitările refuzate, păstrați aceeași structură cu decision=deny și codurile motiv, cum ar fi REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY sau STATEFUL_STORAGE_NOT_ALLOWED.

Utilizați teste de contract pentru regulile de păstrare

Rutarea de păstrare ar trebui să aibă teste automate. Testele importante nu sunt doar teste unitare pentru furnizorii individuali; sunt teste de contract pentru comportamentul politicilor între combinații de furnizori.

Cazurile de testare de mare valoare includ:

• Politica de interzicere a reținerii plus încărcarea fișierelor ar trebui să fie respinse, cu excepția cazului în care există o anumită rută aprobată capabilă de fișiere.
• Politica numai pentru UE și implementarea globală ar trebui să respingă chiar și atunci când modelul este disponibil altfel.
• Politica de reținere zero și istoricul conversațiilor stocat ar trebui să refuze sau să forțeze stocarea atunci când este acceptată.
• Funcția de împământare cu păstrarea jurnalelor derivate ar trebui să fie refuzată conform politicii de interzicere a reținerii.
• Politica de înregistrare numai a metadatelor ar trebui să elimine conținutul de solicitare și finalizare din urme, jurnale și rapoarte de eroare.
• Înregistrarea capacității furnizorului cu păstrare necunoscută ar trebui să respingă pentru sarcinile de lucru reglementate.
• Fallback după întreruperea furnizorului ar trebui să rămână în setul de rute eligibile.
• Procesarea în loturi ar trebui să respingă atunci când punctul final de loturi stochează fișiere de intrare mai mult decât permite politica.

Testează și deriva. Când o înregistrare a capacității se modifică, sistemul ar trebui să arate ce politici și rute sunt afectate înainte ca modificarea să ajungă la producție.

Proprietate operațională

Partea grea este să nu scrieți primul evaluator. Menține registrul la zi și previne excepțiile nedocumentate.

Atribuiți proprietari pentru:

• cadența examinării documentației furnizorului;
• starea de aprobare pentru controalele la nivel de cont, cum ar fi monitorizarea abuzului modificat sau reținerea datelor zero;
• inventarul de implementare regională;
• eligibilitatea pentru funcții pentru fișiere, stocări de vectori, răspunsuri legate de împământare, lot și răspunsuri stocate;
• flux de lucru cu excepția politicii;
• păstrarea înregistrărilor de audit și controlul accesului;
• mesaje de eroare adresate dezvoltatorului și alternative aprobate.

Fiecare înregistrare de capacitate ar trebui să aibă o dată de revizuire. Dacă expiră, politicile stricte ar trebui să nu mai aibă încredere în el sau să necesite aprobare manuală. Documentele furnizorului și comportamentul caracteristicilor se modifică prea des pentru ca aceasta să fie o configurație statică.

Compartimente

Un router de retenție strict reduce opțiunile de model disponibile. Unele modele de previzualizare, API-uri stateful, instrumente de împământare și fluxuri de lucru pentru fișiere vor fi indisponibile pentru sarcinile de lucru sensibile. Acesta este punctul de control, dar echipele de produse au nevoie de alternative clare.

Rutarea regională poate crește latența sau costul atunci când cea mai rapidă implementare este globală, dar volumul de lucru necesită o anumită zonă geografică sau de date. Faceți acest lucru vizibil în telemetrie, astfel încât echipele să înțeleagă de ce o solicitare a folosit o rută mai scumpă sau mai lentă.

Blocarea funcțiilor cu stare poate împinge echipele să-și construiască propriul strat de memorie. Aceasta poate fi arhitectura potrivită, dar mai are nevoie de politică de stocare, fluxuri de lucru de ștergere, criptare, control acces și jurnale de audit. Mutarea statului din furnizor nu elimină munca de guvernare.

Redacția promptă și finalizată protejează datele sensibile, dar slăbește depanarea și evaluarea calității. Folosiți metadate de solicitare reproductibile, dispozitive de testare deterministe, eșantionare controlată pentru sarcinile de lucru permise și acces documentat la spargerea sticlei acolo unde politica o permite.

Recomandări

• Implementați păstrarea și rezidența înainte de rutarea modelului, nu ca verificare ulterioară procesării.
• Capacitățile modelului la nivel de furnizor, punct final, caracteristică, regiune și aprobare a contului.
• Utilizați comportamentul de refuzare implicit pentru sarcinile de lucru reglementate sau legate de contractul clientului.
• Tratați încărcarea fișierelor, stocarea vectorului, conectarea web, procesarea în lot și istoricul conversațiilor stocate ca dimensiuni separate ale politicii.
• Păstrați telemetria operațională chiar și atunci când conținutul de solicitare și finalizare trebuie suprimat.
• Emiteți înregistrări de audit care includ politica, traseul, dovezile privind capacitatea, regiunea, semnalizatoarele de stocare și codurile motiv.
• Scrieți teste de contract pentru combinații de caracteristici cu risc ridicat și comportament de rezervă.

Predicție: rutarea de retenție va deveni un nivel standard de gateway

Directia probabilă este aceea că rutarea de retenție devine un nivel standard în platformele LLM pentru întreprinderi, similar cu limitele ratelor, controalele bugetare și observabilitatea. Pe măsură ce furnizorii adaugă mai multe instrumente cu stare, opțiuni de împământare, cache-uri, fișiere, agenți și funcții de memorie gestionată, ruta sigură va depinde mai puțin de numele modelului și mai mult de calea completă de execuție.

Aceasta este o predicție, nu o cerință universală actuală. Cerința actuală este mai simplă: dacă echipa dvs. promite că nu se păstrează, nu promite procesare regională, nicio utilizare a instruirii sau nicio examinare umană, gateway-ul dvs. are nevoie de suficientă logică politică și dovezi pentru a demonstra că fiecare solicitare a respectat aceste constrângeri.

Concluzie acționabilă

Construiți routerul de reținere ca o poartă de politică în fața selectării furnizorului. Definiți o politică canonică de păstrare, clasificați fiecare solicitare înainte de rutare, mențineți un registru datat de capabilități ale furnizorului, interziceți combinațiile nesigure în mod implicit și înregistrați dovezile de audit fără a păstra conținut sensibil.

Obiectivul de proiectare nu este de a găsi un furnizor care să fie întotdeauna în siguranță. Scopul este de a demonstra că o anumită solicitare, folosind un anumit punct final și un set de caracteristici, într-un anumit cont și regiune, a îndeplinit politica înainte de a fi trimisă.

Lectură asociată

• Design de observabilitate LLM neutru pentru furnizor