Rutarea API AI conștientă de păstrarea datelor: Aplicați politicile ZDR, de rezidență și de înregistrare la gateway

Echipele de securitate nu trebuie doar să știe care model este cel mai ieftin, cel mai rapid sau cel mai capabil. Aceștia trebuie să știe dacă o anumită solicitare poate fi trimisă din punct de vedere legal și operațional unui anumit furnizor, punct final, regiune, caracteristică și mod de înregistrare.

Este mai greu decât pare. Un model poate fi acceptabil pentru chatul intern obișnuit, dar nu și pentru PII client. Un furnizor poate oferi zero reținere a datelor pentru o cale API, în timp ce o caracteristică de căutare la sol stochează solicitări și rezultate pentru o perioadă fixă. O regiune poate accepta rezidența de stocare, dar nu modul de procesare la care te așteptai. Jurnalele deținute de dezvoltatori pot fi configurabile, în timp ce jurnalele de monitorizare a abuzurilor furnizorilor urmează o politică diferită.

Răspunsul practic este mutarea deciziilor de reținere din aplicații individuale și în gateway API AI. Gateway-ul ar trebui să clasifice cererea, să o evalueze în raport cu o matrice de capabilități ale furnizorului, să blocheze caracteristicile incompatibile, să direcționeze numai către profiluri de model aprobate și să înregistreze o decizie de politică fără a stoca în mod implicit solicitările brute.

Problema cititorului: termenii de confidențialitate ale furnizorului nu sunt controale de rulare

Majoritatea echipelor încep cu o foaie de calcul sau o analiză de securitate care spune ce furnizori de AI sunt aprobați. Acest lucru este util, dar nu este suficient pentru rutarea producției.

Aplicațiile fac alegeri de rulare:

• Ce model de ID ar trebui să gestioneze această solicitare?
• Solicitarea ar trebui să utilizeze baza căutării, încărcarea fișierelor, execuția codului, procesarea în lot, memorarea în cache promptă sau conversațiile stocate?
• Ce regiune sau punct final ar trebui să proceseze solicitarea?
• Poate sistemul să înregistreze promptul brut pentru depanare?
• Poate rutarea alternativă să trimită aceeași solicitare către alt furnizor?

Fiecare dintre aceste opțiuni poate modifica profilul de păstrare. O solicitare care a fost conformă în modul de chat simplu poate deveni neconformă atunci când dezvoltatorul activează stocarea de conversație la pământ sau persistentă. O regulă de rezervă concepută pentru fiabilitate poate direcționa accidental datele reglementate către o cale de furnizor care nu a fost aprobată pentru reținerea datelor, rezidența datelor sau controale de monitorizare a abuzului.

Recomandare: tratați comportamentul de păstrare ca o constrângere de rutare de primă clasă, nu ca documentație atașată unui cont de furnizor.

Fapte de codat înainte de a proiecta politica

Termenii exacti variază în funcție de furnizor, produs, contract, regiune, punct final și funcție. Nu vă bazați pe memorie sau pe o recenzie unică. Creați o matrice deținută de sursă și actualizați-o când se schimbă termenii.

Mai multe documente curente ale furnizorilor publici ilustrează de ce este necesar acest lucru:

• OpenAI: rezidența datelor API este documentată ca fiind configurată de proiect, cu solicitări regionale care necesită prefixe de domeniu specifice regiunii. OpenAI distinge, de asemenea, suportul de stocare de suportul de procesare în funcție de regiune și notează cerințe suplimentare pentru regiunile din afara SUA. OpenAI afirmă că rezidența datelor API din afara SUA necesită aprobare pentru controalele de monitorizare a abuzului și o modificare privind păstrarea modificată.
• Anthropic: Anthropic documentează reținerea zero a datelor pentru cazurile de utilizare comercială legate de API, menționând în același timp că unele produse conexe sau feeduri de conformitate au modele de păstrare separate, inclusiv reținerea mai lungă pentru Feed-ul de activități și transcrierile sesiunilor de la distanță.
• Google Gemini: termenii API Gemini fac distincție între serviciile neplătite și cele plătite. Pentru serviciile neplătite, Google poate folosi conținutul trimis și răspunsurile generate pentru a îmbunătăți produsele; pentru serviciile plătite, Google spune că solicitările și răspunsurile nu sunt folosite pentru a îmbunătăți produsele. Documentația ZDR Gemini Developer API spune că jurnalele de monitorizare a abuzurilor de servicii plătite rețin în mod normal solicitările și răspunsurile pentru o perioadă limitată, în timp ce proiectele ZDR aprobate șterg conținutul utilizatorului și metadatele identificabile înainte de a le înregistra.
• Stocare specifică funcției: documentația Gemini afirmă că Grounding with Google Search și Grounding with Google Maps stochează solicitări, informații contextuale și rezultate generate timp de 30 de zile, fără nicio modalitate de a dezactiva stocarea atunci când aceste funcții sunt utilizate.
• Jurnalele deținute de dezvoltatori: documentația de înregistrare a jurnalelor API Gemini spune că jurnalele API deținute de dezvoltatori pot fi păstrate până la 55 de zile în mod implicit pentru proiectele cu facturare și că dezvoltatorii pot alege ferestre mai scurte, cum ar fi 7, 14 sau 28 de zile.
• Gestionarea riscurilor: Profilul AI generativ al NIST recomandă monitorizarea conținutului generat de AI pentru riscurile de confidențialitate și conectarea politicilor AI generative la procesele existente de date, software, juridice, de conformitate și de gestionare a riscurilor.

Aceste fapte trebuie verificate în raport cu documentația curentă a furnizorului înainte de lansare. Lecția de arhitectură este stabilă: retenția nu este booleană la nivel de furnizor.

Arhitectură: un motor de politică gateway în calea cererii

Un gateway care ține cont de reținere are cinci componente principale:

1. Clasificator de sensibilitate la solicitare: etichetează volumul de lucru înainte de rutare.
2. Matricea capacităților furnizorului: descrie furnizorul, modelul, punctul final, regiunea, păstrarea, înregistrarea în jurnal și comportamentul caracteristicilor.
3. Reguli de politică ca cod: convertiți cerințele de securitate în decizii de autorizare, respingere sau revizuire în timpul execuției.
4. Stratul de poartă de funcții: blochează caracteristicile care modifică reținerea, cu excepția cazului în care este permis în mod explicit.
5. Stratul de audit și analiză: înregistrează metadate utile fără a stoca în mod prestabilit solicitările brute.

Poarta de acces nu trebuie să înțeleagă fiecare nuanță legală. Trebuie să impună deciziile aprobate de echipele dvs. juridice, de securitate, de conformitate și de platformă.

Pasul 1: clasificați sensibilitatea cererii înainte de a selecta un model

Începeți cu o mică taxonomie de clasificare. Ar trebui să fie suficient de simplu de utilizat pentru dezvoltatori, dar suficient de expresiv pentru a genera politici.

Exemple de etichete de sensibilitate:

• public: documentație publică, copie de marketing, conținut de site-uri publice.
• intern: informații nepublice ale companiei, cu sensibilitate redusă.
• confidențial: strategie, contracte, contextul clientului, detalii nelansate despre produse.
• customer_pii: nume, e-mailuri, adrese, identificatori de cont, transcrieri de asistență.
• reglementat: date protejate de asistență medicală, financiare, juridice, educaționale sau specifice unei jurisdicții.
• source_code: cod proprietar, configurare, fișiere de arhitectură.
• acreditări: secrete, simboluri, parole, chei private. În majoritatea sistemelor, acest lucru ar trebui să fie blocat, nu direcționat.

Clasificarea poate proveni din mai multe surse:

• Un antet furnizat de aplicație, cum ar fi X-Data-Class: customer_pii.
• Politica chiriașilor, în care tot traficul de la un client reglementat este tratat ca reglementat, cu excepția cazului în care este retrogradat de o regulă aprobată.
• Politica punctului final, unde rezumatul biletelor de asistență este implicit customer_pii.
• Scanare ușoară a conținutului pentru acreditări, PII evidente sau încălcări ale politicii.

Recomandare: nu depind în totalitate de detectarea automată. Solicitați aplicațiilor să declare clasa de date dorită, apoi utilizați scanarea pentru a detecta nepotrivirile evidente sau pentru a forța o clasă mai sigură.

Pasul 2: construiți o matrice a capacităților furnizorului

Matricea de capabilități este sursa adevărului pe care routerul o evaluează. Ar trebui să fie versiunea, revizuită și testată ca configurația de producție.

Exemple de câmpuri:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "provider": "provider_x",
  "model": "model-mare",
  "api_family": "chat_completions",
  „endpoint”: „https://eu.example-provider.com/v1”,
  "regiune": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  „zdr_eligible”: adevărat,
  „zdr_contract_required”: adevărat,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  „developer_log_retention_days”: 0,
  „raw_prompt_logging_allowed”: fals,
  „supported_features”: {
    „plain_chat”: adevărat,
    „streaming”: adevărat,
    „tool_calls”: adevărat,
    „search_grounding”: fals,
    „maps_grounding”: fals,
    „file_upload”: fals,
    „lot”: fals,
    „stored_conversations”: fals
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Utilizați profiluri de model în loc de ID-uri brute de model. Un profil combină modelul, furnizorul, punctul final, regiunea, setul de caracteristici și postura de reținere. Dezvoltatorii solicită model_profile: compliant_summarization, nu doar model: fastest-large-model.

Recomandare: includeți cerințele contractuale prealabile în matrice. O rută nu este aprobată de ZDR doar pentru că un furnizor oferă ZDR undeva. Este aprobat numai atunci când contul, proiectul, regiunea și punctul final îndeplinesc condițiile necesare.

Pasul 3: scrieți regulile de politică ca cod

Regulile politicii trebuie să fie explicite, testabile și lizibile de către echipele de securitate și platformă.

Exemple de reguli în pseudocod:

deny if data_class == „acreditări”
  motivul „credentials_must_nut_be_be_sent_to_model”
permiteți numai dacă data_class în ["regulated", "customer_pii"]
  și profile.zdr_eligible == adevărat
  și profile.zdr_contract_required_satisfied == adevărat
  reason_on_failure „model_profile_not_zdr_eligible”
deny if residency_required == "eu"
  și „eu” nu în profile.processing_residency
  motivul „region_processing_not_supported”
deny if data_class in ["confidential", "customer_pii", "regulated"]și request.raw_prompt_logging == adevărat
  motivul „raw_prompt_logging_not_allowed”
deny dacă request.features.search_grounding == adevărat
  și policy.requires_zdr == adevărat
  și profile.feature_storage.search_grounding_days > 0
  motivul „grounding_requires_retained_content”
deny if fallback_profile.retention_level < primary_profile.retention_level
  motivul „politica_de_reținere”

Aceste reguli ar trebui să ruleze înainte de selectarea furnizorului și din nou înainte de alternativă. Rutarea de rezervă este o sursă comună de deviere accidentală a politicii: ruta principală poate fi conformă, în timp ce ruta de rezervă este doar disponibilă.

Pasul 4: tratați instrumentele și funcțiile ca capabilități de schimbare a reținerii

Nu modelați reținerea doar ca proprietate a modelului de bază. Funcțiile modifică adesea comportamentul de stocare, de înregistrare sau de examinare.

Oferiți fiecărei caracteristici propriile semne de politică:

• Încercarea căutării: poate stoca solicitări, contextul preluat și rezultatul generat, în funcție de termenii furnizorului.
• Hărți sau stabilirea locației: pot introduce jurnalele specifice locației sau reguli de păstrare.
• Încărcarea fișierelor: poate stoca fișiere separat de solicitări și răspunsuri.
• Execuția codului: poate crea fișiere temporare, jurnale de execuție sau artefacte sandbox.
• Locuri de muncă: pot avea un comportament diferit de reținere, coadă și stocare a rezultatelor față de apelurile API sincrone.
• Conversații stocate: persistă în mod intenționat conținutul și nu ar trebui niciodată ascuns în spatele unei opțiuni generice de chat.
• Tablouri de bord de evaluare sau de revizuire: pot crea fluxuri de lucru pentru recenzii umane sau seturi de date cu durată mai lungă de viață.

Recomandare: activați funcțiile de modificare a reținerii la nivel de chiriaș și de rută. Dacă un dezvoltator activează grounding_search=true, gateway-ul ar trebui să reevalueze cererea în raport cu regulile de stocare a caracteristicilor înainte de a o trimite în amonte.

Pasul 5: păstrați analizele fără a stoca solicitări brute

Rutarea care ține cont de reținere nu ar trebui să orbească echipa platformei. Puteți păstra analitice utile privind utilizarea AI, minimizând în același timp stocarea de conținut.

Câmpuri de telemetrie implicite sigure:

• ID-ul locatarului și ID-ul proiectului
• ID cheie internă sau codificată API
• ID-ul profilului modelului și ID-ul furnizorului
• solicitați marca temporală și regiune
• numărările de intrare, de ieșire, stocate în cache și de raționament, atunci când sunt disponibile
• latența, codul de stare, numărul de reîncercări și decizia de rezervă
• costul estimat și decontat
• eticheta de clasificare a datelor
• versiunea politicii și motivul deciziei politicii
• semnalele de caracteristică solicitate și semnalizatoarele de caracteristică permise

Evitați stocarea în mod implicit a solicitărilor brute și a rezultatelor modelului pentru trafic confidențial. Dacă depanarea necesită conținut, utilizați un flux de lucru controlat:

• aprobarea clientului sau a chiriașului
• fereastră de timp restrânsă
• limită de eșantionare
• pas de redactare
• control separat al accesului
• expirare scurtă
• jurnalul de audit al cine l-a activat și de ce

Acesta este un compromis. Blocarea jurnalelor de prompte brute îngreunează depanarea, asistența, evaluarea calității și investigarea abuzurilor. Dar stocarea totul în mod implicit creează o suprafață mai mare de confidențialitate, încălcare și conformitate.

Pasul 6: returnați motivele de respingere acționabile

Un 403 interzis generic frustrează dezvoltatorii și încurajează soluțiile alternative. Returnați un motiv stabil care poate fi citit de mașină și o explicație care poate fi citită de om.

Exemplu de răspuns:

{
  „eroare”: {
    "type": "policy_denied",
    "code": "împământare_necesită_stocare_30_zi",
    „message”: „Încărcarea căutării nu este permisă pentru sarcinile de lucru marcate requires_zdr, deoarece această caracteristică a furnizorului stochează prompt, context și conținut de ieșire.”,
    "request_id": "req_123",
    „policy_version”: „politica-de-reținere-2026-08-01”,
    „allowed_actions”: [
      "disable_search_grounding",
      „alege_profil:zdr_plain_chat”,
      "request_exception"
    ]
  }
}

Codurile de refuz utile includ:

• model_profile_not_zdr_eligible
• region_processing_not_supported
• storage_residency_not_supported
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• politica_de_reținere_slăbită
• contract_prerequisite_missing
• credentials_detected

Pasul 7: adăugați un flux de lucru cu excepții, nu o ocolire ascunsă

Unele excepții sunt legitime: răspuns la incident, depanare aprobată de client, testare de migrare sau o limitare temporară a furnizorului. Gateway-ul ar trebui să accepte excepții fără a le transforma într-o politică umbră permanentă.

Fiecare excepție ar trebui să includă:

• identitatea aprobatorului
• echipă sau chiriaș care solicită
• biletul sau linkul de evaluare a riscurilor
• justificarea afacerii
• profilurile și funcțiile de model permise
• clasele de date acoperite
• data de expirare
• cerințe suplimentare de înregistrare

Recomandare: faceți excepții mai restrânse decât politica obișnuită. Evitați comutatoarele globale, cum ar fi disable_retention_policy=true. Preferați suprascrierile în domeniul de aplicare, cum ar fi „permiteți înregistrarea promptului de depanare pentru chiriașul A, punctul final B, timp de 24 de ore, cu redactare și aprobare de securitate.”

Lista de verificare operațională

• Creați o matrice de capabilități de furnizor cu versiunea.
• Atribuiți un proprietar pentru termenii furnizorului, cerințele prealabile ale contractului și recenziile privind păstrarea.
• Solicită aplicațiilor să declare clasa de date, cerințele de rezidență și funcțiile solicitate.
• Trafic confidențial și reglementat implicit nu înregistrează prompt.
• Reprezentați instrumentele, împământarea, încărcarea fișierelor, lotul și conversațiile stocate ca semnalizatoare de capacitate separate.
• Executați verificări ale politicii înainte de rutarea principală și înainte de rutarea alternativă.
• Versiunea politicii de jurnal, profilul modelului, clasa de date, semnalizatoarele de caracteristică și motivul respingerii.
• Păstrați metadatele analitice separate de conținutul prompt și de rezultat.
• Reprezentantul de testare permite și respinge cazuri în CI.
• Examinați evoluția politicii ori de câte ori un furnizor modifică termenii, regiunile, punctele finale sau caracteristicile.

Compromisii de făcut explicit

Dirijarea strictă reduce alegerea. ZDR și constrângerile de rezidență pot împiedica utilizarea celui mai nou model, a rutei cu cel mai mic cost sau a unui punct final bogat în funcții.

Rutarea regională poate crește latența sau costul. Este posibil ca cea mai apropiată regiune compatibilă să nu accepte modul de procesare dorit sau poate necesita o cale diferită a furnizorului.

Funcțiile surprind dezvoltatorii. Un dezvoltator poate crede că activează doar căutarea, dar securitatea vede un nou comportament de păstrare. Mesajele de documentare și de respingere reduc frecarea.

Minimizarea promptă complică depanarea. Echipele au nevoie de mostre redactate, ferestre de depanare aprobate de chiriași și metadate puternice pentru a investiga problemele fără a stoca totul.

Matricea necesită întreținere. Termenii furnizorului se modifică. Lansare modele noi. Regiunile se extind. Funcțiile trec de la beta la producție. O matrice învechită este mai rea decât nicio matrice, deoarece creează încredere falsă.

Ce este o recomandare și ce este o predicție?

Recomandări: impuneți păstrarea la gateway, clasificați cererile înainte de rutare, construiți o matrice de capabilități ale furnizorului, blocați funcțiile de modificare a retenției în funcție de politică, evitați în mod implicit înregistrarea promptă brută și versiunea fiecărei decizii de politică.

Predicție: echipele platformei AI vor trata din ce în ce mai mult postura de confidențialitate ca parte a selecției modelului. În loc să întrebăm „ce model ar trebui să folosim?” aplicațiile vor solicita un profil de model care să satisfacă constrângerile de capacitate, cost, latență, rezidență și reținere.

Predicție: caracteristicile de confidențialitate specifice furnizorului vor continua să difere. Gateway-urile care normalizează doar formatele de cerere și răspuns nu vor fi suficiente; echipele de producție vor avea nevoie și de normalizarea politicilor.

Concluzie acționabilă

Dirutarea în funcție de păstrarea datelor nu este un tablou de bord separat pentru conformitate. Acesta aparține căii de solicitare.

Începeți cu trei rezultate: o taxonomie de sensibilitate la solicitare, o matrice de capabilități a furnizorului cu versiuni și un mic set de reguli de politică ca cod pentru ZDR, rezidență, jurnalizare brută, funcții de rezervă și de modificare a retenției. Apoi, faceți ca gateway-ul să returneze motive clare de refuz și păstrați analizele fără a stoca conținut brut în mod implicit.

Acest design centralizează deciziile care altfel ar fi împrăștiate în opțiunile SDK, variabilele de mediu, consolele furnizorilor și convențiile specifice echipei. De asemenea, oferă echipelor de securitate și platformă o pistă practică de audit: ce solicitare a fost permisă, ce versiune de politică aplicată, ce profil de model a fost selectat și de ce.

Lectură similară

• construirea unei matrice de capabilități a furnizorului în timpul unei migrări API compatibile cu OpenAI
• instrumente pentru agenți de guvernare cu domenii, aprobări și piste de audit