Hvordan bygge en dataoppbevaringspolicyruter for LLM-API-er for flere leverandører

En LLM-ruter med flere leverandører bør ikke velge en modell først og stille oppbevaringsspørsmål senere. Hvis en støttearbeidsflyt er merket som ikke-oppbevaring, må gatewayen vite om den valgte leverandøren, endepunktet, regionen, kontoinnstillingen og funksjonskombinasjonen kan overholde dette løftet før forespørselen forlater grensen.

Feilmodusen er lett å gå glipp av. Et team starter med fullføring av statsløs chat. Ruten er akseptabel. Senere legger noen til filopplasting, lagret samtalehistorikk, nettjording, batchbehandling eller en vektorbutikk. Modellnavnet kan forbli det samme, men dataoppførselen endres. En enkel ventetid eller kostnadsruter kan stille regulerte eller kundekontraktbundne meldinger til en bane som lagrer innhold lenger enn arbeidsbelastningen tillater.

Den praktiske løsningen er å sette LLM-dataoppbevaringskontroller foran modellruting. Ruteren bør klassifisere forespørselen, matche den mot en kanonisk oppbevaringspolicy, filtrere leverandørfunksjoner, blokkere funksjoner som ikke er tillatt, og avgi reviderbart bevis for avgjørelsen.

Fakta å behandle som designbegrensninger

Håndtering av leverandørdata er ikke enhetlig, og den fanges sjelden opp av leverandørens navn alene. Følgende fakta er viktige når du designer en retensjonsbevisst ruter:

• OpenAI sier at API data ikke brukes til å trene eller forbedre modeller med mindre kunden velger å delta. Kvalifiserte kunder kan konfigurere Modified Abuse Monitoring eller Zero Data Retention på organisasjons- eller prosjektnivå etter godkjenning.
• OpenAIs Zero Data Retention endrer endepunktsatferden, inkludert å behandle store-parameteren for svar og chatfullføringer som falske, men noen endepunkter og funksjoner kan fortsatt lagre applikasjonsstatus og er ikke kvalifisert for Null datalagring.
• Anthropic dokumenter Null dataoppbevaring for Claude API som ikke lagrer kundeforespørsler eller svar i hvile etter at API-svaret er returnert, men dekningen avhenger av endepunkt og funksjonskvalifisering.
• Anthropic sier at noen Claude funksjoner eller dekkede modellene kan kreve oppbevaring og kan være utilgjengelige under Null dataoppbevaring med mindre de er spesifikt autorisert.
• Google Cloud-dokumenter som Gemini Enterprise Agent Platform-data ikke brukes til å trene eller finjustere AI/ML-modeller uten forutgående tillatelse eller instruksjon, men null datalagring krever spesifikke handlinger og er kanskje ikke mulig for enkelte avanserte funksjoner.
• Google Cloud-dokumenter som jording med Google Search lagrer avledede søke- og kontekstlogger i opptil tre dager og kan ikke deaktivere lagringen for den funksjonen. Den anbefaler Web Grounding for Enterprise når null datalagring er nødvendig.
• Microsoft-dokumenter som Azure-vertsbaserte modeller som selges av Azure, gjør ikke forespørsler og fullføringer tilgjengelige for OpenAI eller andre modellleverandører og bruker dem ikke til å trene grunnmodeller uten tillatelse eller instruksjoner.
• Microsoft-dokumenter som Azure-distribusjonstypen påvirker behandlingsplasseringen. Globale distribusjoner kan behandle forespørsler og svar i alle geografier der modellen er distribuert, mens DataZone-distribusjoner begrenser behandlingen til den valgte sonen. Lagrede data forblir i kundens angitte geografi.
• Microsoft-dokumenter som enkelte stateful Azure-funksjoner lagrer data, inkludert filer, vektorlagre, svarmeldingslogg, assistenttråder, batchbehandlingsinnganger og lagrede fullføringer.
• Microsoft-dokumenter som godkjente kunder kan endre overvåking av misbruk, og som Azure-portalen eller CLI kan vise ContentLogging=false når lagring av misbruksovervåking er av.

Dette er ikke kantdetaljer. De betyr at ruteren må evaluere endepunkt, funksjon, kontogodkjenning og region sammen. En leverandøromfattende etikett som "ZDR-aktivert" er for grov for produksjonspolicy.

Referansearkitektur

En oppbevaringsbevisst multi-model AI API gateway trenger fem komponenter i forespørselsbanen:

1. Request classifier: trekker ut datasensitivitet, leietakerkontrakt, regionkrav, funksjonsbruk, filinndata, verktøybruk og loggingstillatelser.
2. Retningslinjeløser: tilordner forespørselen til en kanonisk oppbevaringspolicy, vanligvis fra leietaker, prosjekt, miljø, API-nøkkel og metadata for arbeidsbelastning.
3. Leverandørkapasitetsregister: registrerer leverandør-, endepunkt-, modell-, funksjons-, region- og kontonivåoppbevaringsfunksjoner med datert bevis.
4. Retningslinjeevaluator: filtrerer kandidatruter og returnerer enten en godkjent rute eller en policyavvisning med en årsakskode.
5. Revisjonsutsender: registrerer den valgte ruten, samsvarende retningslinjer, evneforutsetninger, region, lagringsflagg og innholdsloggingsmodus.

Denne arkitekturen holder beslutninger om oppbevaring og opphold atskilt fra kostnader, ventetid og reserve. Kostnadsruting kan fortsatt skje, men bare innenfor settet med ruter som tilfredsstiller retningslinjene for oppbevaring.

Definer en kanonisk oppbevaringspolicy

Start med et leverandørnøytralt policyobjekt. Ikke kopier én leverandørs terminologi inn i din interne kontrakt. Den interne policyen din bør beskrive hva arbeidsbelastningen har lov til å gjøre, ikke hvordan en spesifikk leverandør markedsfører en kontroll.

{
  "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 begrensede arbeidsbelastninger, bruk eksplisitt avslapping i stedet for manglende felt:

{
  "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 viktige feltene er ikke bare oppbevaringsvarighet. Stateful funksjoner, filer, jording, batchbehandling og loggingsmodus påvirker alle om en rute er akseptabel.

Bygg leverandørkapasitetsregisteret

Kunnskapsregisteret er ruterens kilde til sannhet. Den skal opprettholdes som kontrollert konfigurasjon, ikke spredt gjennom leverandøradaptere.

En nyttig post inkluderer:

• provider: leverandør eller skyplattform.
• account_scope: organisasjon, prosjekt, distribusjon, abonnement eller leietaker der en innstilling er godkjent.
• endpoint: chat, svar, meldinger, batch, filer, assistenter, innebygginger, jording, vektorlager eller annen API overflate.
• model_family og valgfritt model_id: fordi modellens kvalifisering kan variere.
• region_mode: globalt, regionalt, datasone, kundedefinert geografi eller leverandørspesifikk ekvivalent.
• content_retention: ingen lagring etter respons, oppbevaring av misbruksovervåking, oppbevaring av applikasjonstilstand, avledede logger med fast varighet eller ukjent.
• training_use: deaktivert som standard, opt-in eller ukjent.
• human_review: aktivert, modifisert, deaktivert eller ukjent.
• stateful_storage: om endepunktet eller funksjonen lagrer samtaletilstand, filer, vektordata, fullføringer eller batch-inndata.
• feature_flags: jording, filer, verktøy, hurtigbuffer, lagrede utdata, batch, assistenter eller tilsvarende funksjoner.
• evidence: kildedokumentnavn, nettadresse, hentedato og eiervurderingsdato.

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 å behandle ukjent som avvisning for sensitive arbeidsbelastninger. Hvis en kapasitetspost mangler et oppbevaringsfelt, regionmodus eller funksjonskvalifisering, bør den ikke tilfredsstille strenge retningslinjer.

Klassifiser forespørselen før ruting

Klassifisering bør skje før modellvalg. En god klassifikator kombinerer statiske metadata og ber om inspeksjon:

• API nøkkelomfang: leietaker, team, miljø, applikasjon og arbeidsbelastningstype.
• Kontraktetiketter: ingen oppbevaring, kun for EU, HIPAA-lignende kontroller, økonomiske data, kundekonfidensielle eller kun internt.
• Nyttelasttype: fri tekst, dokument, bilde, filreferanse, innebyggingsinndata, verktøyresultat eller hentet kontekst.
• Bruk av funksjoner: nettjording, filopplasting, vektorlagring, batchjobb, lagret samtalehistorikk, verktøyanrop eller svarlagring.
• Loggingsmodus: fullstendig innhold tillatt, redigert innhold tillatt, bare metadata eller ikke innhold i applikasjonslogg.
• Regionale hint: brukerplassering, leietakerdataresidens, prosjektregion eller distribusjonsregion.

Ikke stol bare på automatisk gjenkjenning av sensitive data. Bruk erklært arbeidsbelastningspolicy fra API-nøkkelen eller prosjektet som primærkilde, og bruk deretter klassifiserere for å stramme inn retningslinjene når nyttelasten inneholder 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 betyr dette at en kundestøttenøkkel som standard kan brukes uten oppbevaring, mens en intern eksperimenteringsnøkkel kan tillate bredere ruting. Hvis den samme støttenøkkelen forsøker å laste opp en fil, bør den effektive policyen inkludere file_storage_allowed=false med mindre det finnes en godkjent rute med filkompatibilitet.

Evaluer policy før kostnads- eller latensruting

Evaluatoren skal fungere som et filter. Den mottar en policy, forespørselsfunksjoner og ruter for kandidatleverandører. Den returnerer bare ruter som tilfredsstiller retningslinjene.

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 bestillingen er viktig. Reserveruting bør ikke hoppe til en ikke-kvalifisert leverandør under et strømbrudd. Batch-ruting bør ikke flytte en forespørsel om ikke-oppbevaring til en asynkron jobbbutikk. Jording skal ikke slå på en funksjon som introduserer avledede logger når retningslinjene forbyr det.

Hvis plattformen din avslører en OpenAI-kompatibel multimodell API, hold kompatibilitetslaget ærlig: den samme forespørselsteksten kan kompilere til forskjellige leverandørbaserte funksjoner. Policyevaluatoren må inspisere den kompilerte forespørselen, ikke bare den opprinnelige SDK-formen.

Blokkér risikofylte funksjonskombinasjoner eksplisitt

Den sikreste implementeringen er å lage eksplisitte avvisningsregler for kjente høyrisikokombinasjoner. Eksempler:

• NO_RETENTION + FILE_UPLOAD: avslå med mindre det spesifikke filendepunktet og kontoinnstillingen er godkjent for retningslinjene.
• NO_RETENTION + VECTOR_STORE: avslå med mindre vektorlageret er inne i din egen kontrollerte lagring og leverandøren aldri mottar vedvarende filtilstand.
• NO_RETENTION + STORED_RESPONSE: tvinge responslagringsflagg av eller avslå hvis endepunktet ikke kan deaktivere lagring.
• EU_ONLY + GLOBAL_DEPLOYMENT: avvis hvis behandling kan skje utenfor den tillatte regionen eller datasonen.
• NO_RETENTION + WEB_GROUNDING: avvis om jordingsfunksjonen lagrer avledede søke- eller kontekstlogger utover policy.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: undertrykk forespørsler og fullføringsinnhold fra programlogger og spor.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: avslå med mindre funksjonen er spesifikt kvalifisert under kontoens godkjente kontroller.

Returner spesifikke feil. En nyttig fornektelse forteller utvikleren hva som mislyktes og hvilke godkjente alternativer som finnes.

{
  "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 inferenslogging fra operasjonell telemetri

Retningslinjer for oppbevaring bør ikke tvinge gatewayen til å bli blind. Du kan vanligvis beholde operativ telemetri uten å lagre forespørsler eller fullføringsinnhold.

For strenge arbeidsbelastninger, bevar:

• forespørsels-ID og sporings-ID;
• identifikatorer for leietaker, prosjekt, API nøkkel og arbeidsbelastning;
• policy-ID og policyversjon;
• leverandør, endepunkt, modell, distribusjon og region brukt;
• funksjonsflagg forespurt og tillatt;
• årsakskoder for beslutning;
• tokenantall, ventetid, statuskode og kostnadsmetadata;
• hasher eller stabile fingeravtrykk for deduplisering, hvis godkjent av retningslinjer.

Undertrykk eller redakter:

• rå meldinger;
• råfullføringer;
• opplastet filinnhold;
• verktøyutdata som inneholder kundedata;
• hentet kontekst fra sensitive systemer;
• provider feilsøker nyttelaster som dupliserer innhold.

Det er her oppbevaringsruting kobles til leverandørnøytral LLM-observerbarhet. Observerbarhet bør bevise hva som skjedde uten å utvide settet med systemer som beholder sensitivt innhold.

Legg ut revisjonsbevis for hver beslutning

En revisjonspost skal forklare hvorfor en rute ble tillatt eller avslått. Den trenger ikke fullstendig innhold for å være nyttig.

{
  "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 avslåtte forespørsler, behold den samme strukturen med decision=deny og årsakskoder som REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY eller STATEFUL_STORAGE_NOT_ALLOWED.

Bruk kontraktstester for oppbevaringsregler

Oppbevaringsruting bør ha automatiserte tester. De viktige testene er ikke bare enhetstester for individuelle tilbydere; de er kontraktstester for policyatferd på tvers av leverandørkombinasjoner.

Testtilfeller med høy verdi inkluderer:

• Retningslinjer for ikke-oppbevaring pluss filopplasting bør avvises med mindre det finnes en spesifikk godkjent rute med filkompatibilitet.
• Retningslinjer for bare EU pluss global distribusjon bør nekte selv når modellen ellers er tilgjengelig.
• Retningslinjer for nulloppbevaring pluss lagret samtalelogg bør nekte eller tvinge lagring av når det støttes.
• Jordingsfunksjon med oppbevaring av avledet logg bør nekte under retningslinjer for ikke-oppbevaring.
• Retningslinjer for kun metadata-logging bør undertrykke spørsmål og fullføringsinnhold fra spor, logger og feilrapporter.
• Personal for leverandørkapasitet med ukjent oppbevaring bør nekte for regulerte arbeidsbelastninger.
• Tilbakefall etter leverandørbrudd bør forbli innenfor det kvalifiserte rutesettet.
• Batchbehandling bør nekte når batchendepunktet lagrer inndatafiler lenger enn policyen tillater.

Test også drift. Når en kapasitetspost endres, bør systemet vise hvilke retningslinjer og ruter som påvirkes før endringen når produksjon.

Operasjonelt eierskap

Den vanskelige delen er ikke å skrive den første evaluatoren. Det holder registeret oppdatert og forhindrer udokumenterte unntak.

Tildel eiere for:

• provider documentation review cadence;
• godkjenningsstatus for kontroller på kontonivå som modifisert overvåking av misbruk eller null datalagring;
• regional distribusjonsbeholdning;
• funksjonskvalifisering for filer, vektorlagre, jording, batch og lagrede svar;
• arbeidsflyt for policy-unntak;
• oppbevaring av revisjonsposter og tilgangskontroll;
• feilmeldinger til utvikleren og godkjente alternativer.

Hver kapasitetspost bør ha en gjennomgangsdato. Hvis den utløper, bør strenge retningslinjer slutte å stole på den eller kreve manuell godkjenning. Leverandørdokumenter og funksjonsadferd endres for ofte til at dette kan være statisk konfigurasjon.

Trade-off

En streng retensjonsruter reduserer tilgjengelige modellvalg. Noen forhåndsvisningsmodeller, stateful APIer, jordingsverktøy og filarbeidsflyter vil være utilgjengelige for sensitive arbeidsbelastninger. Det er poenget med kontrollen, men produktteam trenger klare alternativer.

Regional ruting kan øke ventetiden eller kostnadene når den raskeste distribusjonen er global, men arbeidsbelastningen krever en spesifikk geografi eller datasone. Gjør dette synlig i telemetri slik at teamene forstår hvorfor en forespørsel brukte en dyrere eller langsommere rute.

Blokkering av stateful funksjoner kan presse team til å bygge sitt eget minnelag. Det kan være den riktige arkitekturen, men den trenger fortsatt lagringspolicy, slettingsarbeidsflyter, kryptering, tilgangskontroll og revisjonslogger. Å flytte staten ut av leverandøren fjerner ikke styringsarbeid.

Redigering av spørsmål og fullføring beskytter sensitive data, men det svekker feilsøking og kvalitetsvurdering. Bruk reproduserbare forespørsels-metadata, deterministiske testarmaturer, kontrollert sampling for tillatte arbeidsbelastninger og dokumentert glass-tilgang der policyen tillater det.

Anbefalinger

• Håndhev oppbevaring og opphold før modellruting, ikke som en etterbehandlingssjekk.
• Modellfunksjoner på leverandør-, endepunkt-, funksjons-, region- og kontogodkjenningsnivå.
• Bruk deny-by-default-atferd for regulerte eller kundekontraktbundne arbeidsbelastninger.
• Behandle filopplasting, vektorlagre, nettjording, batchbehandling og lagret samtalehistorikk som separate policydimensjoner.
• Behold operativ telemetri selv når forespørsler og fullføringsinnhold må undertrykkes.
• Send ut revisjonsposter som inkluderer policy, rute, kapasitetsbevis, region, lagringsflagg og årsakskoder.
• Skriv kontraktstester for funksjonskombinasjoner med høy risiko og reserveatferd.

Prediksjon: Oppbevaringsruting vil bli et standard gateway-lag

Den sannsynlige retningen er at oppbevaringsruting blir et standardlag i bedrifts LLM-plattformer, i likhet med hastighetsgrenser, budsjettkontroller og observerbarhet. Etter hvert som leverandører legger til flere stateful verktøy, jordingsalternativer, cacher, filer, agenter og administrerte minnefunksjoner, vil den sikre ruten avhenge mindre av modellnavnet og mer av den fullstendige utførelsesbanen.

Dette er en prediksjon, ikke et gjeldende universelt krav. Det nåværende kravet er enklere: Hvis teamet ditt lover ingen oppbevaring, regional behandling, ingen opplæringsbruk eller ingen menneskelig vurdering, trenger gatewayen din nok policylogikk og bevis for å bevise at hver forespørsel fulgte disse begrensningene.

Handlingsbar konklusjon

Bygg oppbevaringsruteren som en policy-gate foran valg av leverandør. Definer en kanonisk oppbevaringspolicy, klassifiser hver forespørsel før ruting, oppretthold et datert register for leverandørkapasitet, avslå usikre kombinasjoner som standard, og logg revisjonsbevis uten å beholde sensitivt innhold.

Designmålet er ikke å finne en leverandør som alltid er trygg. Målet er å bevise at en spesifikk forespørsel, ved hjelp av et spesifikt endepunkt og funksjonssett, under en bestemt konto og region, tilfredsstilte retningslinjene før den ble sendt.

Relatert lesing

• leverandørnøytralt LLM-observasjonsdesign