Enrutament de l'API d'IA sensible a la retenció de dades: apliqueu polítiques de ZDR, residència i registre a la passarel·la

Els equips de seguretat no només necessiten saber quin model és el més barat, el més ràpid o el més capaç. Han de saber si una sol·licitud específica es pot enviar legalment i operativament a un proveïdor, punt final, regió, funció i mode de registre concrets.

Això és més difícil del que sembla. Un model pot ser acceptable per al xat intern normal, però no per a la IPI del client. Un proveïdor pot oferir zero retenció de dades per a una ruta de l'API, mentre que una funció de cerca a terra emmagatzema sol·licituds i sortides durant un període determinat. És possible que una regió admeti la residència d'emmagatzematge, però no el mode de processament que esperàveu. Els registres propietat dels desenvolupadors es poden configurar, mentre que els registres de control d'abús dels proveïdors segueixen una política diferent.

La resposta pràctica és traslladar les decisions de retenció de les aplicacions individuals a la porta d'enllaç de l'API AI. La passarel·la hauria de classificar la sol·licitud, avaluar-la amb una matriu de capacitats del proveïdor, bloquejar funcions incompatibles, dirigir només als perfils de model aprovats i registrar una decisió de política sense emmagatzemar les sol·licituds sense emmagatzemar de manera predeterminada.

El problema del lector: els termes de privadesa del proveïdor no són controls en temps d'execució

La majoria dels equips comencen amb un full de càlcul o una revisió de seguretat que indica quins proveïdors d'IA estan aprovats. Això és útil, però no és suficient per a l'encaminament de producció.

Les aplicacions trien el temps d'execució:

• Quin ID de model hauria de gestionar aquesta sol·licitud?
• La sol·licitud hauria d'utilitzar la cerca a terra, la càrrega de fitxers, l'execució de codi, el processament per lots, la memòria cau d'indicacions o converses emmagatzemades?
• Quina regió o punt final hauria de processar la sol·licitud?
• El sistema pot registrar la sol·licitud en brut per a la depuració?
• L'encaminament alternatiu pot enviar la mateixa sol·licitud a un altre proveïdor?

Cadascuna d'aquestes opcions pot canviar el perfil de retenció. Una sol·licitud que complia en mode de xat normal pot no complir-la quan el desenvolupador activa l'emmagatzematge de converses a terra o persistent. Una regla alternativa dissenyada per a la fiabilitat pot encaminar accidentalment dades regulades a una ruta de proveïdor que no s'hagi aprovat per a la retenció de dades zero, la residència de les dades o els controls de seguiment d'abús.

Recomanació: tracteu el comportament de retenció com una restricció d'encaminament de primera classe, no com a documentació adjunta al compte d'un proveïdor.

Fets a codificar abans de dissenyar la política

Els termes exactes varien segons el proveïdor, el producte, el contracte, la regió, el punt final i la funció. No confieu en la memòria ni en una revisió puntual. Creeu una matriu propietat de la font i actualitzeu-la quan canviïn els termes.

Diversos documents actuals del proveïdor públic il·lustren per què és necessari:

• OpenAI: la residència de les dades de l'API es documenta com a configurada pel projecte, amb les sol·licituds regionals que requereixen prefixos de domini específics de la regió. OpenAI també distingeix el suport d'emmagatzematge del suport de processament per regió i assenyala requisits addicionals per a les regions que no són dels EUA. OpenAI afirma que la residència de les dades de l'API no dels Estats Units requereix l'aprovació dels controls de seguiment d'abús i una esmena de retenció modificada.
• Anthropic: Anthropic documenta la retenció de dades zero per a casos d'ús comercial relacionats amb l'API, tot i que assenyala que alguns productes relacionats o fonts de compliment tenen models de retenció separats, inclosa una retenció més llarga per al feed d'activitats i transcripcions de sessions remotes.
• Google Gemini: els termes de l'API Gemini distingeixen els serveis no pagats i de pagament. Per als serveis no pagats, Google pot utilitzar el contingut enviat i les respostes generades per millorar els productes; per als serveis de pagament, Google diu que les sol·licituds i les respostes no s'utilitzen per millorar els productes. La documentació ZDR de l'API Gemini Developer diu que els registres de seguiment d'abús de serveis de pagament solen conservar les sol·licituds i les respostes durant un període limitat, mentre que els projectes ZDR aprovats esborren el contingut d'usuari i les metadades identificables abans de registrar-se.
• Emgatzematge específic de la funció: la documentació de Gemini indica que Grounding with Google Search i Grounding with Google Maps emmagatzemen sol·licituds, informació contextual i resultats generats durant 30 dies, sense cap manera de desactivar aquest emmagatzematge quan s'utilitzen aquestes funcions.
• Registres propietat del desenvolupador: la documentació de registre de l'API Gemini diu que els registres de l'API propietat del desenvolupador es poden conservar fins a 55 dies de manera predeterminada per als projectes amb facturació activada i que els desenvolupadors poden triar períodes més curts com ara 7, 14 o 28 dies.
• Gestió de riscos: el perfil d'IA generativa del NIST recomana supervisar el contingut generat per IA per detectar riscos de privadesa i connectar les polítiques d'IA generativa amb dades, programari, legals, compliment i processos de gestió de riscos existents.

Aquests són fets que cal verificar amb la documentació actual del proveïdor abans del llançament. La lliçó d'arquitectura és estable: la retenció no és un booleà a nivell de proveïdor.

Arquitectura: un motor de polítiques de passarel·la al camí de sol·licitud

Una passarel·la sensible a la retenció té cinc components bàsics:

1. Classificador de sensibilitat de la sol·licitud: etiqueta la càrrega de treball abans de l'encaminament.
2. Matriu de capacitat del proveïdor: descriu el proveïdor, el model, el punt final, la regió, la retenció, el registre i el comportament de les funcions.
3. Regles de política com a codi: converteix els requisits de seguretat en decisions de permetre, denegar o revisar en temps d'execució.
4. Capa de la porta de funcions: bloqueja les funcions que canvien la retenció tret que es permeti explícitament.
5. Capa d'auditoria i anàlisi: registra metadades útils sense emmagatzemar sol·licituds en brut de manera predeterminada.

La passarel·la no ha d'entendre tots els matisos legals. Ha de fer complir les decisions que els vostres equips legals, de seguretat, de compliment i de plataforma han aprovat.

Pas 1: classifiqueu la sensibilitat de la sol·licitud abans de seleccionar un model

Comenceu amb una petita taxonomia de classificació. Hauria de ser prou senzill perquè l'utilitzin els desenvolupadors, però prou expressiu per impulsar la política.

Exemple d'etiquetes de sensibilitat:

• públic: documentació pública, còpia de màrqueting, contingut del lloc web públic.
• interna: informació de l'empresa no pública amb poca sensibilitat.
• confidencial: estratègia, contractes, context del client, detalls del producte no publicats.
• customer_pii: noms, correus electrònics, adreces, identificadors de comptes, transcripcions d'assistència.
• regulat: dades protegides sanitàries, financeres, legals, educatives o específiques d'una jurisdicció.
• codi_font: codi propietari, fitxers de configuració, arquitectura.
• credencials: secrets, testimonis, contrasenyes, claus privades. A la majoria de sistemes, això s'hauria de bloquejar, no d'encaminar.

La classificació pot provenir de diverses fonts:

• Una capçalera subministrada per l'aplicació, com ara X-Data-Class: customer_pii.
• Política d'inquilí, en què tot el trànsit d'un client regulat es tracta com a regulat, tret que es redueixi una norma aprovada.
• Política de punt final, on el resum del bitllet d'assistència per defecte és customer_pii.
• Escaneig de contingut lleuger per detectar credencials, IPI evidents o infraccions de polítiques.

Recomanació: no depenen completament de la detecció automàtica. Demaneu que les aplicacions declarin la classe de dades prevista i, a continuació, utilitzeu l'escaneig per detectar desajustos evidents o forçar una classe més segura.

Pas 2: creeu una matriu de capacitat del proveïdor

La matriu de capacitats és la font de veritat que avalua l'encaminador. S'ha de versionar, revisar i provar com la configuració de producció.

Camps d'exemple:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "proveïdor": "proveïdor_x",
  "model": "model-gran",
  "api_family": "chat_completions",
  "punt final": "https://eu.example-provider.com/v1",
  "region": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": cert,
  "zdr_contract_required": cert,
  "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": cert,
    "streaming": cert,
    "tool_calls": cert,
    "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"]
}

Utilitzeu perfils de model en lloc d'ID de model en brut. Un perfil combina model, proveïdor, punt final, regió, conjunt de funcions i postura de retenció. Els desenvolupadors sol·liciten model_profile: compliant_summarization, no només model: fastest-large-model.

Recomanació: incloure requisits contractuals previs a la matriu. Una ruta no està aprovada per ZDR només perquè un venedor ofereix ZDR en algun lloc. Només s'aprova quan el vostre compte, projecte, regió i punt final compleixen les condicions requerides.

Pas 3: escriviu regles de política com a codi

Les regles de la política han de ser explícites, comprovables i llegibles pels equips de seguretat i de plataforma.

Exemple de regles en pseudocodi:

deny if data_class == "credencials"
  motiu "no s'han d'enviar_al_model les credencials"
permet només si data_class a ["regulated", "customer_pii"]
  i profile.zdr_eligible == true
  i profile.zdr_contract_required_satisfied == true
  reason_on_failure "model_profile_not_zdr_eligible"
denegar si residency_required == "eu"
  i "eu" no a profile.processing_residency
  motiu "region_processing_not_supported"
denegar si data_class a ["confidencial", "client_pii", "regulat"]i request.raw_prompt_logging == true
  motiu "raw_prompt_logging_not_allowed"
denegar si request.features.search_grounding == és cert
  i policy.requires_zdr == true
  i profile.feature_storage.search_grounding_days > 0
  motiu "grounding_requires_retained_content"
denegar si fallback_profile.retention_level < primary_profile.retention_level
  motiu "fallback_weakens_retention_policy"

Aquestes regles s'han d'executar abans de la selecció del proveïdor i de nou abans de la alternativa. L'encaminament de reserva és una font habitual de deriva de la política accidental: la ruta principal pot ser compatible, mentre que la ruta alternativa només està disponible.

Pas 4: tracteu les eines i les funcions com a capacitats de canvi de retenció

No modeleu la retenció com a propietat només del model base. Les funcions sovint canvien el comportament d'emmagatzematge, registre o revisió.

Doneu a cada característica les seves pròpies marques de política:

• Basament de la cerca: pot emmagatzemar sol·licituds, context recuperat i resultats generats en funció dels termes del proveïdor.
• Mapes o ubicacions a terra: poden introduir registres o regles de retenció específiques de la ubicació.
• Càrrega de fitxers: pot emmagatzemar fitxers per separat de les sol·licituds i les respostes.
• Execució de codi: pot crear fitxers temporals, registres d'execució o artefactes de prova.
• Les feines per lots: poden tenir un comportament de retenció, cua i emmagatzematge de resultats diferent de les trucades d'API síncrones.
• Converses emmagatzemades: el contingut persisteix intencionadament i mai s'ha d'amagar darrere d'una opció de xat genèrica.
• Taulers d'avaluació o revisió: poden crear fluxos de treball de revisions humanes o conjunts de dades de vida més llarga.

Recomanació: feu que les funcions de canvi de retenció s'activin al nivell de l'inquilí i de la ruta. Si un desenvolupador activa grounding_search=true, la passarel·la hauria de tornar a avaluar la sol·licitud amb les regles d'emmagatzematge de funcions abans d'enviar-la amunt.

Pas 5: conserveu les analítiques sense emmagatzemar les sol·licituds en brut

L'encaminament conscient de la retenció no hauria de cegar l'equip de la plataforma. Podeu mantenir analíticas d'ús de l'IA útils alhora que minimitzeu l'emmagatzematge de contingut.

Camps de telemetria predeterminats segurs:

• Identificador de llogater i identificador del projecte
• identificador de clau de l'API interna o hash
• ID del perfil del model i ID del proveïdor
• demaneu marca de temps i regió
• Recomptes d'entrada, sortida, memòria cau i testimonis de raonament quan estiguin disponibles
• latència, codi d'estat, recompte de reintents i decisió alternativa
• cost estimat i liquidat
• etiqueta de classificació de dades
• Versió de la política i motiu de la decisió de la política
• S'han sol·licitat les marques de funcions i les de funcions permeses

Eviteu emmagatzemar les sol·licituds sense processar i les sortides del model de manera predeterminada per al trànsit confidencial. Si la depuració requereix contingut, utilitzeu un flux de treball controlat:

• aprovació del client o llogater
• finestra de temps estreta
• límit de mostreig
• Passa de redacció
• control d'accés independent
• caducitat curta
• Registre d'auditoria de qui l'ha activat i per què

Aquesta és una compensació. El bloqueig dels registres d'indicacions en brut fa que la depuració, el suport, la revisió de qualitat i la investigació d'abús siguin més difícils. Però emmagatzemar-ho tot de manera predeterminada crea una superfície de privadesa, incompliment i compliment més gran.

Pas 6: retorneu els motius de denegació accionables

Un 403 prohibit genèric frustra els desenvolupadors i fomenta solucions alternatives. Retorna un motiu estable llegible per màquina i una explicació llegible per l'home.

Exemple de resposta:

{
  "error": {
    "type": "política_denegada",
    "codi": "la connexió a terra requereix_emmagatzematge_de_30_dies",
    "message": "La cerca a terra no està permesa per a les càrregues de treball marcades requires_zdr perquè aquesta funció del proveïdor emmagatzema contingut d'indicacions, context i sortida.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "choose_profile:zdr_plain_chat",
      "request_exception"
    ]
  }
}

Els codis de denegació útils inclouen:

• model_profile_not_zdr_eligible
• region_processing_not_supported
• storage_residency_not_supported
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• la política_de_retenció_debilita_de_fallback
• contract_prerequisite_missing
• credentials_detected

Pas 7: afegiu un flux de treball d'excepció, no un bypass ocult

Algunes excepcions són legítimes: resposta a incidents, depuració aprovada pel client, proves de migració o una limitació temporal del proveïdor. La passarel·la hauria de suportar excepcions sense convertir-les en una política d'ombra permanent.

Cada excepció hauria d'incloure:

• identitat de l'aprovador
• equip o llogater sol·licitant
• tiquet o enllaç de revisió del risc
• justificació empresarial
• perfils i funcions de model permesos
• classes de dades cobertes
• data de caducitat
• requisits addicionals de registre

Recomanació: feu que les excepcions siguin més limitades que la política normal. Eviteu canvis globals com ara disable_retention_policy=true. Preferiu substitucions d'àmbit com ara "permetre el registre de sol·licituds de depuració per a l'inquilí A, punt final B, durant 24 hores, amb redacció i aprovació de seguretat".

Llista de comprovació operativa

• Creeu una matriu de capacitat del proveïdor versionada.
• Assigneu un propietari per a les condicions del proveïdor, els requisits previs del contracte i les revisions de retenció.
• Exigir que les aplicacions declarin la classe de dades, el requisit de residència i les funcions sol·licitades.
• Trànsit confidencial i regulat predeterminat sense registre d'avís en brut.
• Representeu les eines, la connexió a terra, la càrrega de fitxers, les converses per lots i les converses emmagatzemades com a indicadors de capacitat independents.
• Executeu comprovacions de polítiques abans de l'encaminament principal i abans de l'encaminament alternatiu.
• Registreu la versió de la política, el perfil del model, la classe de dades, els indicadors de funció i el motiu de la denegació.
• Mantingueu les metadades d'analítica separades del contingut de la sol·licitud i de la sortida.
• El representant de la prova permet i denega casos a CI.
• Reviseu la deriva de les polítiques sempre que un proveïdor canviï termes, regions, punts finals o funcions.

Compartiments per fer explícits

L'encaminament estricte redueix l'elecció. Les restriccions de ZDR i de residència poden impedir l'ús del model més nou, la ruta de menor cost o un punt final ric en funcions.

L'encaminament regional pot augmentar la latència o el cost. És possible que la regió compatible més propera no admeti el mode de processament desitjat o pot requerir una ruta de proveïdor diferent.

La funció sorprèn als desenvolupadors. Un desenvolupador pot pensar que només està habilitant la cerca, però la seguretat veu un nou comportament de retenció. La documentació i els missatges de denegació redueixen la fricció.

La minimització ràpida complica la depuració. Els equips necessiten mostres redactades, finestres de depuració aprovades pels inquilins i metadades sòlides per investigar problemes sense emmagatzemar-ho tot.

La matriu requereix manteniment. Els termes del proveïdor canvien. Llançament de nous models. Les regions s'expandeixen. Les funcions passen de la versió beta a la producció. Una matriu obsoleta és pitjor que cap matriu perquè crea una confiança falsa.

Què és una recomanació i què és una predicció?

Recomanacions: apliqueu la retenció a la passarel·la, classifiqueu les sol·licituds abans de l'encaminament, creeu una matriu de capacitats del proveïdor, bloquegeu les funcions de canvi de retenció per política, eviteu el registre d'indicacions en brut per defecte i versioneu totes les decisions de política.

Predicció: els equips de la plataforma d'IA tractaran cada cop més la postura de privadesa com a part de la selecció de models. En lloc de preguntar-nos "quin model hem d'utilitzar?" les aplicacions demanaran un perfil de model que compleixi les limitacions de capacitat, cost, latència, residència i retenció.

Predicció: les funcions de privadesa específiques del proveïdor continuaran divergent. Les passarel·les que normalitzin només els formats de sol·licitud i resposta no seran suficients; els equips de producció també necessitaran una normalització de polítiques.

Conclusió accionable

L'encaminament conscient de la retenció de dades no és un tauler de control a part. Pertany al camí de la sol·licitud.

Comenceu amb tres resultats: una taxonomia de sensibilitat a la sol·licitud, una matriu de capacitats del proveïdor versionada i un petit conjunt de regles de política com a codi per a funcions de ZDR, residència, registre en brut, alternativa i canvi de retenció. A continuació, feu que la passarel·la torni motius clars de la denegació i preserveu les analítiques sense emmagatzemar contingut en brut de manera predeterminada.

Aquest disseny centralitza les decisions que, d'una altra manera, es repartirien entre les opcions de l'SDK, les variables d'entorn, les consoles del proveïdor i les convencions específiques de l'equip. També ofereix als equips de seguretat i de plataforma un seguiment pràctic d'auditoria: quina sol·licitud es va permetre, quina versió de la política s'ha aplicat, quin perfil del model es va seleccionar i per què.

Lectura relacionada

• creació d'una matriu de capacitat del proveïdor durant una migració d'API compatible amb OpenAI
• eines d'agent de govern amb àmbits, aprovacions i pistes d'auditoria