Sådan bygger du en dataopbevaringspolitikrouter til LLM API'er med flere udbydere

En LLM-router med flere udbydere bør ikke vælge en model først og stille spørgsmål om opbevaring senere. Hvis en support-workflow er tagget som ikke-retention, skal gatewayen vide, om den valgte udbyder, slutpunkt, region, kontoindstilling og funktionskombination kan overholde dette løfte, før anmodningen forlader din grænse.

Fejltilstanden er let at gå glip af. Et team starter med en statsløs chatafslutning. Ruten er acceptabel. Senere tilføjer nogen filupload, gemt samtalehistorik, webjording, batchbehandling eller en vektorbutik. Modelnavnet kan forblive det samme, men dataadfærden ændres. En simpel forsinkelses- eller omkostningsrouter kan lydløst sende regulerede eller kundekontraktbundne prompter til en sti, der gemmer indhold længere end arbejdsbelastningen tillader.

Den praktiske løsning er at placere LLM-dataretentionskontroller foran modelrouting. Routeren bør klassificere anmodningen, matche den mod en kanonisk opbevaringspolitik, filtrere udbyderens kapaciteter, blokere ikke-tilladte funktioner og udsende reviderbart bevis for beslutningen.

Fakta, der skal behandles som designbegrænsninger

Håndtering af udbyderens data er ikke ensartet, og den er sjældent fanget af udbyderens navn alene. Følgende fakta har betydning, når du designer en fastholdelsesbevidst router:

• OpenAI angiver, at API data ikke bruges til at træne eller forbedre modeller, medmindre kunden tilmelder sig. Kvalificerede kunder kan konfigurere Modified Abuse Monitoring eller Zero Data Retention på organisations- eller projektniveau efter godkendelse.
• OpenAIs nul dataopbevaring ændrer slutpunkts adfærd, herunder behandling af parameteren store for svar og chatafslutninger som falsk, men nogle slutpunkter og funktioner kan stadig gemme applikationstilstand og er ikke kvalificerede til nul dataopbevaring.
• Anthropic dokumenter Nul dataopbevaring for Claude API som ikke gemmer kundebeskeder eller svar i hvile, efter at API-svaret er returneret, men dækningen afhænger af slutpunkt og funktionsberettigelse.
• Anthropic angiver, at nogle Claude funktioner eller dækkede modeller kan kræve opbevaring og kan være utilgængelige under nul dataopbevaring, medmindre det er specifikt godkendt.
• Google Cloud-dokumenter, som Gemini Enterprise Agent Platform-data ikke bruges til at træne eller finjustere AI/ML-modeller uden forudgående tilladelse eller instruktion, men nul dataopbevaring kræver specifikke handlinger og er muligvis ikke muligt for nogle avancerede funktioner.
• Google Cloud-dokumenter, som Jording med Google Search gemmer afledte forespørgsels- og kontekstlogfiler i op til tre dage og kan ikke deaktivere denne lagring for den funktion. Det anbefaler Web Grounding for Enterprise, når der kræves ingen dataopbevaring.
• Microsoft-dokumenter, som Azure-hostede modeller, der sælges af Azure, gør ikke prompter og færdiggørelser tilgængelige for OpenAI eller andre modeludbydere og bruger dem ikke til at træne fundamentmodeller uden tilladelse eller instruktion.
• Microsoft-dokumenter, hvor Azure-implementeringstypen påvirker behandlingsplaceringen. Globale implementeringer kan behandle prompter og svar i enhver geografi, hvor modellen er implementeret, mens DataZone-implementeringer begrænser behandlingen til den valgte zone. Gemte data forbliver i den kundedefinerede geografi.
• Microsoft-dokumenter, som nogle stateful Azure-funktioner gemmer data, herunder filer, vektorlagre, svarmeddelelseshistorik, assistenttråde, batchbehandlingsinput og lagrede fuldførelser.
• Microsoft-dokumenter, som godkendte kunder kan ændre overvågning af misbrug, og som Azure-portalen eller CLI kan vise ContentLogging=false, når lagring af misbrugsovervågning er slået fra.

Dette er ikke kantdetaljer. De betyder, at routeren skal evaluere slutpunkt, funktion, kontogodkendelse og region sammen. En leverandørdækkende etiket såsom "ZDR enabled" er for grov til produktionspolitikken.

Referencearkitektur

En fastholdelsesbevidst multi-model AI API gateway har brug for fem komponenter i anmodningsstien:

1. Request classifier: udtrækker datafølsomhed, lejerkontrakt, regionskrav, funktionsbrug, filinput, brug af værktøj og logføringstilladelser.
2. Politikløser: knytter anmodningen til en kanonisk opbevaringspolitik, normalt fra lejer, projekt, miljø, API nøgle og metadata for arbejdsbelastning.
3. Provider-kapacitetsregister: registrerer udbyder, slutpunkt, model, funktion, region og konto-niveau opbevaringsfunktioner med dateret bevis.
4. Politikevaluator: filtrerer kandidatruter og returnerer enten en godkendt rute eller en politikafvisning med en årsagskode.
5. Revisionsudsender: registrerer den valgte rute, matchet politik, kapacitetsantagelser, region, lagerflag og indholdslogningstilstand.

Denne arkitektur holder beslutninger om opbevaring og ophold adskilt fra omkostninger, forsinkelse og reserve. Omkostningsdirigering kan stadig ske, men kun inden for det sæt af ruter, der overholder opbevaringspolitikken.

Definer en kanonisk opbevaringspolitik

Start med et udbyderneutralt politikobjekt. Kopier ikke én udbyders terminologi ind i din interne kontrakt. Din interne politik bør beskrive, hvad arbejdsbyrden må gøre, ikke hvordan en specifik udbyder markedsfører en kontrol.

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

For mindre begrænsede arbejdsbelastninger, brug eksplicit lempelse i stedet for manglende felter:

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

De vigtige felter er ikke kun opbevaringsvarighed. Stateful-funktioner, filer, jordforbindelse, batchbehandling og logningstilstand påvirker alle, om en rute er acceptabel.

Byg udbyderkapacitetsregistret

Kompetenceregistret er routerens kilde til sandhed. Den skal vedligeholdes som kontrolleret konfiguration, ikke spredt gennem udbyderadaptere.

En nyttig registrering omfatter:

• provider: udbyder eller cloudplatform.
• account_scope: organisation, projekt, implementering, abonnement eller lejer, hvor en indstilling er godkendt.
• endpoint: chat, svar, beskeder, batch, filer, assistenter, indlejringer, jordforbindelse, vektorlager eller anden API overflade.
• model_family og valgfrit model_id: fordi modellens berettigelse kan variere.
• region_mode: global, regional, datazone, kundeudpeget geografi eller udbyderspecifik ækvivalent.
• content_retention: ingen lagerplads efter svar, tilbageholdelse af misbrugsovervågning, opbevaring af applikationstilstand, afledte logfiler med fast varighed eller ukendt.
• training_use: deaktiveret som standard, opt-in eller ukendt.
• human_review: aktiveret, ændret, deaktiveret eller ukendt.
• stateful_storage: om slutpunktet eller funktionen gemmer samtaletilstand, filer, vektordata, fuldførelser eller batch-input.
• feature_flags: jordforbindelse, filer, værktøjer, cache, lagrede output, batch, assistenter eller tilsvarende funktioner.
• evidence: kildedokumentnavn, webadresse, dato for hentning og dato for ejergennemgang.

Eksempel:

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

Anbefalingen er at behandle ukendt som afvisning for følsomme arbejdsbelastninger. Hvis en kapacitetsregistrering mangler et opbevaringsfelt, regionstilstand eller funktionskvalificering, bør den ikke overholde strenge politikker.

Klassificer anmodningen før routing

Klassificering bør ske før modelvalg. En god klassifikator kombinerer statiske metadata og anmoder om inspektion:

• API nøgleomfang: lejer, team, miljø, applikation og arbejdsbyrdetype.
• Kontrakttags: ingen opbevaring, kun EU, HIPAA-lignende kontroller, finansielle data, kundefortrolige eller kun internt.
• Lyttetype: fri tekst, dokument, billede, filreference, indlejringsinput, værktøjsresultat eller hentet kontekst.
• Anvendelse af funktioner: webjordforbindelse, filupload, vektorlagring, batchjob, gemt samtalehistorik, værktøjsopkald eller svarlagring.
• Logføringstilstand: fuldt indhold tilladt, redigeret indhold tilladt, kun metadata eller intet programlogindhold.
• Regionale tip: brugerplacering, lejerdata, projektregion eller implementeringsregion.

Bliv ikke kun afhængig af automatisk registrering af følsomme data. Brug den erklærede arbejdsbelastningspolitik fra API-nøglen eller projektet som den primære kilde, og brug derefter klassifikatorer til at stramme politikken, når nyttelasten indeholder risikosignaler.

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

I praksis betyder det, at en kundesupportnøgle som standard kan være ingen opbevaring, mens en intern eksperimenteringsnøgle kan tillade bredere routing. Hvis den samme supportnøgle forsøger at uploade en fil, bør den effektive politik omfatte file_storage_allowed=false, medmindre der findes en godkendt rute, der kan fil.

Evaluer politik før omkostnings- eller forsinkelsesrouting

Evaluatoren skal fungere som et filter. Den modtager en politik, anmodningsfunktioner og ruter for kandidatudbydere. Den returnerer kun ruter, der overholder politikken.

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

Denne bestilling er vigtig. Fallback-routing bør ikke springe til en ikke-kvalificeret udbyder under et afbrydelse. Batch-routing bør ikke flytte en anmodning om ikke-tilbageholdelse til en async-jobbutik. Jordforbindelse bør ikke aktivere en funktion, der introducerer afledte logfiler, når politikken forbyder det.

Hvis din platform afslører en OpenAI-kompatibel multimodel API, skal du holde kompatibilitetslaget ærligt: Den samme anmodningstekst kan kompilere til forskellige udbyderindbyggede funktioner. Politikevaluatoren skal inspicere den kompilerede anmodning, ikke kun den originale SDK-form.

Bloker eksplicit kombinationer af risikable funktioner

Den sikreste implementering er at skabe eksplicitte benægtelsesregler for kendte højrisikokombinationer. Eksempler:

• NO_RETENTION + FILE_UPLOAD: afvis, medmindre det specifikke filslutpunkt og kontoindstilling er godkendt til politikken.
• NO_RETENTION + VECTOR_STORE: afvis, medmindre vektorlageret er inde i dit eget kontrollerede lager, og udbyderen aldrig modtager vedvarende filtilstand.
• NO_RETENTION + STORED_RESPONSE: tvinge responslagerflag fra eller afvise, hvis slutpunktet ikke kan deaktivere lager.
• EU_ONLY + GLOBAL_DEPLOYMENT: afvis, hvis behandling kan finde sted uden for den tilladte region eller datazone.
• NO_RETENTION + WEB_GROUNDING: afvis, hvis jordforbindelsesfunktionen gemmer afledte forespørgsels- eller kontekstlogfiler ud over politik.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: undertrykke prompt- og færdiggørelsesindhold fra applikationslogfiler og spor.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: afvis, medmindre funktionen er specifikt kvalificeret under kontoens godkendte kontrolelementer.

Returner specifikke fejl. En nyttig afvisning fortæller udvikleren, hvad der fejlede, og hvilke godkendte alternativer der findes.

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

Separat inferenslogning fra operationel telemetri

Retentionspolitik bør ikke tvinge gatewayen til at blive blind. Du kan normalt beholde operationel telemetri uden at gemme prompt- eller færdiggørelsesindhold.

For strenge arbejdsbelastninger, bevar:

• anmodnings-id og sporings-id;
• lejer-, projekt-, API-nøgle- og arbejdsbelastnings-id'er;
• politik-id og politikversion;
• anvendt udbyder, slutpunkt, model, implementering og region;
• funktionsflag anmodet og tilladt;
• årsagskoder til beslutning;
• tokenantal, forsinkelse, statuskode og metadata om omkostninger;
• hashes eller stabile fingeraftryk til deduplikering, hvis det er godkendt af politikken.

Undertrykke eller redigere:

• rå prompts;
• rå fuldførelser;
• uploadet filindhold;
• værktøjsoutput, der indeholder kundedata;
• hentet kontekst fra følsomme systemer;
• provider debug payloads, der duplikerer indhold.

Det er her, tilbageholdelsesruting forbindes med udbyderneutral LLM-observerbarhed. Observerbarhed bør bevise, hvad der skete uden at udvide det sæt af systemer, der bevarer følsomt indhold.

Udsend revisionsbevis for hver beslutning

En revisionspost skal forklare, hvorfor en rute blev tilladt eller afvist. Det behøver ikke fuldt indhold for at være nyttigt.

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

For afviste anmodninger skal du beholde den samme struktur med decision=deny og årsagskoder såsom REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY eller STATEFUL_STORAGE_NOT_ALLOWED.

Brug kontrakttest til opbevaringsregler

Retentionsruting bør have automatiske tests. De vigtige tests er ikke kun enhedstests for individuelle udbydere; de er kontrakttests for politikadfærd på tværs af udbyderkombinationer.

Testsager af høj værdi omfatter:

• Ingen opbevaringspolitik plus filupload bør afvise, medmindre der findes en specifik godkendt rute, der kan fil.
• Politik kun for EU plus global implementering bør afvise, selv når modellen ellers er tilgængelig.
• Politik for nulopbevaring plus gemt samtalehistorik bør nægte eller tvinge lagring fra, når det understøttes.
• Grounding-funktion med afledt logopbevaring bør afvise under ingen-retentionspolitik.
• Politik for logning af kun metadata bør undertrykke prompt- og færdiggørelsesindhold fra spor, logfiler og fejlrapporter.
• Udbyderkapacitetsregistrering med ukendt opbevaring bør afvise for regulerede arbejdsbelastninger.
• Tilbagegang efter udbyderafbrydelse bør forblive inden for det kvalificerede rutesæt.
• Batchbehandling bør afvise, når batchendepunktet gemmer inputfiler længere end politikken tillader.

Test også drift. Når en kapacitetsregistrering ændres, bør systemet vise, hvilke politikker og ruter der er berørt, før ændringen når produktion.

Operational Ownership

Den svære del er ikke at skrive den første evaluator. Det holder registreringsdatabasen opdateret og forhindrer udokumenterede undtagelser.

Tildel ejere til:

• provider documentation review kadence;
• godkendelsesstatus for kontroller på kontoniveau, såsom ændret overvågning af misbrug eller nul dataopbevaring;
• regional implementeringsbeholdning;
• funktionsberettigelse til filer, vektorlagre, jordforbindelse, batch og lagrede svar;
• workflow for politikundtagelse;
• opbevaring af revisionsposter og adgangskontrol;
• udviklervendte fejlmeddelelser og godkendte alternativer.

Hver kapacitetspost bør have en gennemgangsdato. Hvis den udløber, bør strenge politikker stoppe med at stole på den eller kræve manuel godkendelse. Udbyderens dokumenter og funktionsadfærd ændres for ofte til, at dette kan være statisk konfiguration.

Trade-offs

En streng fastholdelsesrouter reducerer de tilgængelige modelvalg. Nogle forhåndsvisningsmodeller, stateful API'er, jordforbindelsesværktøjer og filarbejdsgange vil ikke være tilgængelige for følsomme arbejdsbelastninger. Det er pointen med kontrollen, men produktteams har brug for klare alternativer.

Regional routing kan øge ventetiden eller omkostningerne, når den hurtigste implementering er global, men arbejdsbyrden kræver en specifik geografi eller datazone. Gør dette synligt i telemetri, så teams forstår, hvorfor en anmodning brugte en dyrere eller langsommere rute.

Blokering af stateful-funktioner kan presse teams til at bygge deres eget hukommelseslag. Det kan være den rigtige arkitektur, men det kræver stadig opbevaringspolitik, sletningsarbejdsgange, kryptering, adgangskontrol og revisionslogfiler. At flytte staten ud af udbyderen fjerner ikke styringsarbejde.

Prompt- og færdigredigering beskytter følsomme data, men det svækker fejlfinding og kvalitetsgennemgang. Brug reproducerbare anmodningsmetadata, deterministiske testarmaturer, kontrolleret sampling for tilladte arbejdsbelastninger og dokumenteret brilleadgang, hvor politikken tillader det.

Anbefalinger

• Håndhæv fastholdelse og ophold før modeldirigering, ikke som en efterbehandlingskontrol.
• Modelfunktioner på udbyder-, slutpunkt-, funktions-, regions- og kontogodkendelsesniveau.
• Brug deny-by-default-adfærd til regulerede eller kundekontraktbundne arbejdsbelastninger.
• Behandl filupload, vektorlagre, webjording, batchbehandling og gemt samtalehistorik som separate politikdimensioner.
• Behold operativ telemetri, selv når prompt- og færdiggørelsesindhold skal undertrykkes.
• Send revisionsregistreringer, der inkluderer politik, rute, kapacitetsbevis, region, lagerflag og årsagskoder.
• Skriv kontrakttest for højrisikofunktionskombinationer og reserveadfærd.

Forudsigelse: Retentionsrouting bliver et standardgateway-lag

Den sandsynlige retning er, at fastholdelsesruting bliver et standardlag i virksomhedens LLM-platforme, svarende til hastighedsgrænser, budgetkontrol og observerbarhed. Efterhånden som udbydere tilføjer flere stateful værktøjer, jordforbindelsesmuligheder, caches, filer, agenter og administrerede hukommelsesfunktioner, vil den sikre rute afhænge mindre af modelnavnet og mere af den fulde udførelsessti.

Det er en forudsigelse, ikke et aktuelt universelt krav. Det nuværende krav er enklere: Hvis dit team lover ingen fastholdelse, regional behandling, ingen brug af træning eller ingen menneskelig gennemgang, har din gateway brug for nok politiklogik og beviser til at bevise, at hver anmodning fulgte disse begrænsninger.

Handlingsbar konklusion

Byg fastholdelsesrouteren som en politikport foran valg af udbyder. Definer en kanonisk opbevaringspolitik, klassificer hver anmodning før routing, vedligehold et dateret udbyderkapacitetsregister, afvis usikre kombinationer som standard, og log revisionsbevis uden at bevare følsomt indhold.

Designmålet er ikke at finde en udbyder, der altid er sikker. Målet er at bevise, at en specifik anmodning, ved hjælp af et specifikt slutpunkt og funktionssæt under en bestemt konto og område, opfyldte politikken, før den blev sendt.

Relateret læsning

• udbyderneutralt LLM-observationsdesign