Com crear un encaminador de polítiques de retenció de dades per a API LLM de diversos proveïdors

Un encaminador LLM multiproveïdor no hauria de triar primer un model i fer preguntes de retenció després. Si un flux de treball d'assistència s'etiqueta com a sense retenció, la passarel·la ha de saber si el proveïdor, el punt final, la regió, la configuració del compte i la combinació de funcions seleccionats poden complir aquesta promesa abans que la sol·licitud surti del vostre límit.

El mode d'error és fàcil de perdre's. Un equip comença amb la finalització del xat sense estat. La ruta és acceptable. Més tard, algú afegeix la càrrega de fitxers, l'historial de converses emmagatzemat, la connexió a Internet, el processament per lots o una botiga de vectors. El nom del model pot seguir sent el mateix, però el comportament de les dades canvia. Un simple encaminador de latència o de cost pot enviar silenciosament sol·licituds regulades o vinculades al contracte del client a un camí que emmagatzema contingut més temps del que permet la càrrega de treball.

La solució pràctica és posar els controls de retenció de dades de LLM davant de l'encaminament del model. L'encaminador ha de classificar la sol·licitud, comparar-la amb una política de retenció canònica, filtrar les capacitats del proveïdor, bloquejar les funcions no permeses i emetre proves auditables per a la decisió.

Fets a tractar com a restriccions de disseny

La gestió de les dades del proveïdor no és uniforme i poques vegades es captura només pel nom del proveïdor. Els fets següents són importants a l'hora de dissenyar un encaminador conscient de la retenció:

• OpenAI estableix que les dades API no s'utilitzen per entrenar o millorar models tret que el client s'hi agradi. Els clients elegibles poden configurar el seguiment d'abús modificat o la retenció de dades zero a nivell d'organització o projecte després de l'aprovació.
La retenció de dades zero de
• OpenAI canvia el comportament dels punts finals, inclòs el tractament del paràmetre store per a les respostes i les finalitzacions de xat com a fals, però alguns punts finals i capacitats encara poden emmagatzemar l'estat de l'aplicació i no són elegibles per a la retenció de dades zero.
• Anthropic documenta la retenció de dades zero per al Claude API com a no emmagatzemar les sol·licituds del client o les respostes en repòs després de retornar la resposta API, però la cobertura depèn del punt final i de l'elegibilitat de les funcions.
• Anthropic estableix que algunes funcions Claude o models coberts poden requerir la conservació i poden no estar disponibles amb retenció de dades zero tret que s'autoritzi específicament.
• Google Cloud documenta que les dades de Gemini Enterprise Agent Platform no s'utilitzen per entrenar o ajustar models d'IA/ML sense permís o instruccions prèvies, però la retenció de dades zero requereix accions específiques i és possible que no sigui possible per a algunes funcions avançades.
• Google Cloud documenta que Grounding with Google Search emmagatzema les consultes derivades i els registres de context durant un màxim de tres dies i no pot desactivar aquest emmagatzematge per a aquesta funció. Recomana Web Grounding for Enterprise quan es requereix zero retenció de dades.
• Microsoft documenta que els models allotjats a Azure venuts per Azure no fan que les sol·licituds i les completes estiguin disponibles per a OpenAI o altres proveïdors de models i no els utilitzen per entrenar models de base sense permís o instruccions.
• Microsoft documenta que el tipus de desplegament d'Azure afecta la ubicació de processament. Els desplegaments globals poden processar sol·licituds i respostes a qualsevol geografia on es desplega el model, mentre que els desplegaments de DataZone restringeixen el processament a la zona seleccionada. Les dades emmagatzemades romanen a la geografia designada pel client.
• Microsoft documenta que algunes funcions d'Azure amb estat emmagatzemen dades, inclosos fitxers, magatzems de vectors, historial de missatges de Respostes, fils d'Assistent, entrades de processament per lots i finalitzacions emmagatzemades.
• Documents de Microsoft que els clients aprovats poden modificar la supervisió d'abús i que el portal Azure o CLI poden mostrar ContentLogging=false quan l'emmagatzematge de dades de supervisió d'abús està desactivat.

Aquests no són detalls de la vora. Vol dir que l'encaminador ha d'avaluar conjuntament el punt final, la funció, l'aprovació del compte i la regió. Una etiqueta per a tot el proveïdor com ara "ZDR activat" és massa grossa per a la política de producció.

Arquitectura de referència

Una passarel·la de AI multimodel API conscient de la retenció necessita cinc components al camí de sol·licitud:

1. Classificador de sol·licituds: extreu la sensibilitat de les dades, el contracte de l'inquilí, els requisits de la regió, l'ús de funcions, les entrades de fitxers, l'ús d'eines i els permisos de registre.
2. Resolució de polítiques: assigna la sol·licitud a una política de retenció canònica, normalment des de l'arrendatari, el projecte, l'entorn, la clau API i les metadades de càrrega de treball.
3. Registre de capacitat del proveïdor: registra les capacitats de retenció del proveïdor, el punt final, el model, la funció, la regió i el nivell de compte amb proves datades.
4. Avaluador de polítiques: filtra les rutes candidates i retorna una ruta aprovada o una denegació de polítiques amb un codi de motiu.
5. Emissor d'auditoria: registra la ruta escollida, la política coincident, els supòsits de capacitat, la regió, les marques d'emmagatzematge i el mode de registre de contingut.

Aquesta arquitectura manté les decisions de retenció i residència separades del cost, la latència i la alternativa. L'encaminament de costos encara es pot produir, però només dins del conjunt de rutes que compleixen la política de retenció.

Definiu una política de retenció canònica

Comenceu amb un objecte de política neutral per al proveïdor. No copieu la terminologia d'un proveïdor al vostre contracte intern. La vostra política interna hauria de descriure què pot fer la càrrega de treball, no com un proveïdor específic comercialitza 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"
}

Per a càrregues de treball menys restringides, utilitzeu una relaxació explícita en lloc de camps que falten:

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

Els camps importants no només són la durada de la retenció. Les funcions d'estat, els fitxers, la connexió a terra, el processament per lots i el mode de registre afecten si una ruta és acceptable.

Crear el registre de capacitat del proveïdor

El registre de capacitats és la font de veritat de l'encaminador. S'ha de mantenir com a configuració controlada, no dispersa a través d'adaptadors de proveïdors.

Un registre útil inclou:

• provider: proveïdor o plataforma al núvol.
• account_scope: organització, projecte, desplegament, subscripció o llogater on s'aprova una configuració.
• endpoint: xat, respostes, missatges, lots, fitxers, assistents, incrustacions, connexió a terra, botiga de vectors o una altra superfície API.
• model_family i opcional model_id: perquè l'elegibilitat del model pot ser diferent.
• region_mode: global, regional, zona de dades, geografia designada pel client o equivalent específic del proveïdor.
• content_retention: no hi ha emmagatzematge després de la resposta, retenció de control d'abús, retenció de l'estat de l'aplicació, registres derivats de durada fixa o desconegut.
• training_use: desactivat per defecte, activat o desconegut.
• human_review: activat, modificat, desactivat o desconegut.
• stateful_storage: si el punt final o la funció emmagatzema l'estat de la conversa, els fitxers, les dades vectorials, les finalitzacions o les entrades per lots.
• feature_flags: connexió a terra, fitxers, eines, memòria cau, sortides emmagatzemades, lots, assistents o capacitats equivalents.
• evidence: nom del document font, URL, data de recuperació i data de revisió del propietari.

Exemple:

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

La recomanació és tractar el desconegut com a denegació per a càrregues de treball sensibles. Si un registre de capacitat no té un camp de retenció, un mode de regió o una funció elegible, no hauria de complir polítiques estrictes.

Classifica la sol·licitud abans de l'encaminament

La classificació s'ha de fer abans de la selecció del model. Un bon classificador combina metadades estàtiques i inspecció de sol·licituds:

• API Àmbit clau: inquilí, equip, entorn, aplicació i tipus de càrrega de treball.
• Etiquetes de contracte: sense retenció, només per a la UE, controls semblants a HIPAA, dades financeres, confidencials del client o només interns.
• Tipus de càrrega útil: text lliure, document, imatge, referència de fitxer, entrada d'inserció, resultat de l'eina o context recuperat.
• Ús de les funcions: connexió a Internet, càrrega de fitxers, emmagatzematge de vectors, treball per lots, historial de converses emmagatzemat, trucades d'eines o emmagatzematge de respostes.
• Mode de registre: contingut complet permès, contingut redactat, només metadades o cap contingut del registre de l'aplicació.
• Consells regionals: ubicació de l'usuari, residència de les dades de l'arrendatari, regió del projecte o regió de desplegament.

No confieu només en la detecció automàtica de dades sensibles. Utilitzeu la política de càrrega de treball declarada de la clau o del projecte API com a font principal i, a continuació, utilitzeu classificadors per reforçar la política quan la càrrega útil conté senyals 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]);
}

A la pràctica, això vol dir que una clau d'assistència al client pot ser predeterminada sense retenció, mentre que una clau d'experimentació interna pot permetre un encaminament més ampli. Si la mateixa clau d'assistència intenta penjar un fitxer, la política efectiva hauria d'incloure file_storage_allowed=false tret que existeixi una ruta aprovada per a fitxers.

Avalueu la política abans de l'encaminament de costos o de latència

L'avaluador hauria de funcionar com a filtre. Rep una política, funcions de sol·licitud i rutes de proveïdor candidat. Només retorna rutes que compleixen la política.

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

Aquesta ordre és important. L'encaminament de reserva no hauria de saltar a un proveïdor no apte durant una interrupció. L'encaminament per lots no hauria de moure una sol·licitud sense retenció a un magatzem de treball asíncron. La connexió a terra no hauria d'activar una funció que introdueixi registres derivats quan la política ho prohibeix.

Si la vostra plataforma exposa un OpenAImultimodel compatible amb API, mantingueu la capa de compatibilitat honesta: el mateix cos de sol·licitud pot compilar-se amb diferents funcions natives del proveïdor. L'avaluador de polítiques ha d'inspeccionar la sol·licitud compilada, no només la forma SDK original.

Bloqueja explícitament les combinacions de funcions arriscades

La implementació més segura és crear regles de denegació explícites per a combinacions conegudes d'alt risc. Exemples:

• NO_RETENTION + FILE_UPLOAD: denegar tret que s'aprovi el punt final del fitxer i la configuració del compte per a la política.
• NO_RETENTION + VECTOR_STORE: denegueu tret que el magatzem de vectors estigui dins del vostre propi emmagatzematge controlat i el proveïdor mai no rep l'estat del fitxer persistent.
• NO_RETENTION + STORED_RESPONSE: força les marques d'emmagatzematge de resposta desactivades o denegades si el punt final no pot desactivar l'emmagatzematge.
• EU_ONLY + GLOBAL_DEPLOYMENT: denegueu si el processament es pot produir fora de la regió o zona de dades permesa.
• NO_RETENTION + WEB_GROUNDING: denegueu si la funció de connexió a terra emmagatzema consultes derivades o registres de context més enllà de la política.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: suprimiu el contingut d'indicacions i de finalització dels registres i traces de l'aplicació.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: denegar tret que la funció sigui específicament apta sota els controls aprovats del compte.

Retorna errors específics. Una denegació útil indica al desenvolupador què ha fallat i quines alternatives aprovades existeixen.

{
  "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 el registre d'inferències de la telemetria operativa

La política de retenció no hauria de forçar la passarel·la a quedar-se cega. Normalment podeu mantenir la telemetria operativa sense emmagatzemar contingut d'indicacions o de finalització.

Per a càrregues de treball estrictes, preserveu:

• ID de sol·licitud i identificador de traça;
• identificadors de l'arrendatari, del projecte, de la API clau i de la càrrega de treball;
• ID de política i versió de la política;
• proveïdor, punt final, model, desplegament i regió utilitzats;
• indicadors de funció sol·licitats i permesos;
• codis de motiu de decisió;
• recomptes de testimonis, latència, codi d'estat i metadades de cost;
• hash o empremtes dactilars estables per a la desduplicació, si la política s'aprova.

Suprimeix o elimina:

• indicacions en brut;
• finalitzacions en brut;
• contingut del fitxer penjat;
• sortides de l'eina que contenen dades del client;
• context recuperat de sistemes sensibles;
• càrregues útils de depuració del proveïdor que dupliquen contingut.

Aquí és on l'encaminament de retenció es connecta a l'observabilitat LLM neutra per al proveïdor. L'observabilitat hauria de demostrar el que va passar sense ampliar el conjunt de sistemes que conserven contingut sensible.

Emetre proves d'auditoria per a cada decisió

Un registre d'auditoria hauria d'explicar per què es va permetre o denegar una ruta. No necessita contingut complet per ser útil.

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

Per a les sol·licituds denegades, manteniu la mateixa estructura amb decision=deny i codis de motiu com ara REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY o STATEFUL_STORAGE_NOT_ALLOWED.

Utilitzar proves de contracte per a les regles de retenció

L'encaminament de retenció hauria de tenir proves automatitzades. Les proves importants no són només proves unitàries per a proveïdors individuals; són proves de contracte per al comportament de les polítiques entre combinacions de proveïdors.

Els casos de prova d'alt valor inclouen:

• La política de no retenció i la càrrega de fitxers s'han de denegar tret que existeixi una ruta específica aprovada per a fitxers.
• La política només per a la UE i el desplegament global s'han de negar fins i tot quan el model estigui disponible d'una altra manera.
• La política de retenció zero i l'historial de converses emmagatzemat haurien de denegar o forçar l'emmagatzematge quan sigui compatible.
• La funció de connexió a terra amb retenció de registres derivats s'ha de denegar segons la política de no retenció.
• La política de registre només de metadades hauria de suprimir el contingut d'indicacions i de finalització de traces, registres i informes d'errors.
• El registre de capacitat del proveïdor amb retenció desconeguda s'ha de denegar per a càrregues de treball regulades.
• La recuperació després d'una interrupció del proveïdor hauria de romandre dins del conjunt de rutes elegibles.
• El processament per lots hauria de denegar quan el punt final de lots emmagatzema els fitxers d'entrada més temps del que permet la política.

També prova la deriva. Quan canvia un registre de capacitat, el sistema hauria de mostrar quines polítiques i rutes es veuen afectades abans que el canvi arribi a la producció.

Propietat operacional

La part difícil és no escriure el primer avaluador. Manté actualitzat el registre i evita excepcions no documentades.

Assigna propietaris per a:

• cadència de revisió de la documentació del proveïdor;
• estat d'aprovació dels controls a nivell de compte, com ara la supervisió d'abús modificat o la retenció de dades zero;
• inventari de desplegament regional;
• Elegibilitat de les funcions per a fitxers, magatzems de vectors, connexió a terra, lots i respostes emmagatzemades;
• flux de treball d'excepció de la política;
• retenció de registres d'auditoria i control d'accés;
• missatges d'error per a desenvolupadors i alternatives aprovades.

Cada registre de capacitat ha de tenir una data de revisió. Si caduca, les polítiques estrictes haurien de deixar de confiar-hi o requerir l'aprovació manual. Els documents del proveïdor i el comportament de les funcions canvien massa sovint perquè aquesta sigui una configuració estàtica.

Compartiments

Un encaminador de retenció estricte redueix les opcions de models disponibles. Alguns models de vista prèvia, API amb estat, eines de connexió a terra i fluxos de treball de fitxers no estaran disponibles per a càrregues de treball sensibles. Aquest és el punt del control, però els equips de producte necessiten alternatives clares.

L'encaminament regional pot augmentar la latència o el cost quan el desplegament més ràpid és global, però la càrrega de treball requereix una zona geogràfica o de dades específica. Feu que això sigui visible a la telemetria perquè els equips entenguin per què una sol·licitud utilitzava una ruta més cara o més lenta.

El bloqueig de funcions amb estat pot impulsar els equips a crear la seva pròpia capa de memòria. Aquesta pot ser l'arquitectura adequada, però encara necessita una política d'emmagatzematge, fluxos de treball de supressió, xifratge, control d'accés i registres d'auditoria. El fet de moure l'estat fora del proveïdor no elimina el treball de govern.

La redacció d'avís i finalització protegeix les dades sensibles, però debilita la depuració i la revisió de qualitat. Utilitzeu metadades de sol·licitud reproduïbles, accessoris de proves deterministes, mostreig controlat per a les càrregues de treball permeses i accés documentat a trencaclosques quan la política ho permet.

Recomanacions

• Aplica la retenció i la residència abans de l'encaminament del model, no com a comprovació posterior al processament.
• Capacitats de model a nivell de proveïdor, punt final, funció, regió i aprovació del compte.
• Utilitzeu el comportament de denegació per defecte per a càrregues de treball regulades o vinculades al contracte del client.
• Traiteu la càrrega de fitxers, les botigues de vectors, la connexió a Internet, el processament per lots i l'historial de converses emmagatzemats com a dimensions de política separades.
• Mantingueu la telemetria operativa fins i tot quan s'hagi de suprimir el contingut de sol·licitud i finalització.
• Emet registres d'auditoria que incloguin la política, la ruta, les proves de capacitat, la regió, les marques d'emmagatzematge i els codis de motiu.
• Escriu proves de contracte per a combinacions de funcions d'alt risc i comportament alternatiu.

Predicció: l'encaminament de retenció es convertirà en una capa de passarel·la estàndard

La direcció probable és que l'encaminament de retenció es converteixi en una capa estàndard a les plataformes de LLM empresarial, de manera similar als límits de tarifes, controls pressupostaris i observabilitat. A mesura que els proveïdors afegeixen més eines amb estat, opcions de connexió a terra, memòria cau, fitxers, agents i funcions de memòria gestionada, la ruta segura dependrà menys del nom del model i més de la ruta d'execució completa.

Això és una predicció, no un requisit universal actual. El requisit actual és més senzill: si el vostre equip promet cap retenció, processament regional, cap ús de formació o cap revisió humana, la vostra passarel·la necessita prou lògica política i proves per demostrar que cada sol·licitud seguia aquestes limitacions.

Conclusió accionable

Creeu l'encaminador de retenció com a porta de política davant la selecció del proveïdor. Definiu una política de retenció canònica, classifiqueu cada sol·licitud abans de l'encaminament, mantingueu un registre de capacitat del proveïdor datat, negueu combinacions no segures de manera predeterminada i registreu proves d'auditoria sense retenir contingut sensible.

L'objectiu del disseny no és trobar un proveïdor sempre segur. L'objectiu és demostrar que una sol·licitud específica, utilitzant un punt final i un conjunt de funcions específics, en un compte i una regió concrets, compleix la política abans d'enviar-la.

Lectura relacionada

• Disseny d'observabilitat de LLM neutre per al proveïdor