Hur man bygger en datalagringspolicyrouter för LLM API:er för flera leverantörer

En LLM-router med flera leverantörer bör inte välja en modell först och ställa frågor om lagring senare. Om ett supportarbetsflöde är taggat som no-retention, måste gatewayen veta om den valda leverantören, slutpunkten, regionen, kontoinställningen och funktionskombinationen kan uppfylla det löftet innan begäran lämnar din gräns.

Fejlläget är lätt att missa. Ett team börjar med att slutföra en tillståndslös chatt. Rutten är acceptabel. Senare lägger någon till filuppladdning, lagrad konversationshistorik, webbjordning, batchbearbetning eller en vektorbutik. Modellnamnet kan förbli detsamma, men databeteendet ändras. En enkel fördröjnings- eller kostnadsrouter kan i tysthet skicka reglerade eller kundkontraktsbundna uppmaningar till en sökväg som lagrar innehåll längre än vad arbetsbelastningen tillåter.

Den praktiska lösningen är att sätta LLM-datalagringskontroller framför modellrouting. Routern bör klassificera begäran, matcha den mot en kanonisk lagringspolicy, filtrera leverantörens kapacitet, blockera otillåtna funktioner och avge granskningsbara bevis för beslutet.

Fakta att behandla som designbegränsningar

Hantering av leverantörsdata är inte enhetlig, och den fångas sällan enbart av leverantörens namn. Följande fakta är viktiga när du designar en retentionsmedveten router:

• OpenAI anger att API data inte används för att träna eller förbättra modeller om inte kunden väljer att delta. Kvalificerade kunder kan konfigurera Modified Abuse Monitoring eller Zero Data Retention på organisations- eller projektnivå efter godkännande.
• OpenAIs noll datalagring ändrar slutpunktens beteende, inklusive att behandla store-parametern för svar och chattslutföranden som falsk, men vissa slutpunkter och funktioner kan fortfarande lagra applikationstillstånd och är inte kvalificerade för noll datalagring.
• Anthropic dokument Noll datalagring för Claude API eftersom det inte lagrar kundmeddelanden eller svar i viloläge efter att API-svaret har returnerats, men täckningen beror på kvalificering för slutpunkter och funktioner.
• Anthropic anger att vissa Claude funktioner eller täckta modeller kan kräva lagring och kan vara otillgängliga under Noll datalagring om de inte är särskilt auktoriserade.
• Google Molndokument som Gemini Enterprise Agent Platform-data inte används för att träna eller finjustera AI/ML-modeller utan föregående tillstånd eller instruktioner, men noll datalagring kräver specifika åtgärder och kanske inte är möjligt för vissa avancerade funktioner.
• Google Molndokument som Grounding with Google Search lagrar härledda fråge- och sammanhangsloggar i upp till tre dagar och kan inte inaktivera lagringen för den funktionen. Den rekommenderar Web Grounding for Enterprise när ingen datalagring krävs.
• Microsoft-dokument som Azure-värdade modeller som säljs av Azure gör inte uppmaningar och kompletteringar tillgängliga för OpenAI eller andra modellleverantörer och använder dem inte för att träna grundmodeller utan tillstånd eller instruktioner.
• Microsoft-dokument vars Azure-distributionstyp påverkar bearbetningsplatsen. Globala distributioner kan bearbeta uppmaningar och svar i alla geografiska områden där modellen används, medan DataZone-distributioner begränsar bearbetningen till den valda zonen. Lagrad data finns kvar i kundens angivna geografi.
• Microsoft-dokument som vissa stateful Azure-funktioner lagrar data, inklusive filer, vektorlager, svarsmeddelandehistorik, assistenttrådar, indata för batchbearbetning och lagrade slutföranden.
• Microsoft-dokument som godkända kunder kan ändra övervakning av missbruk och som Azure-portalen eller CLI kan visa ContentLogging=false när lagring av missbruksövervakning är avstängd.

Det här är inte kantdetaljer. De innebär att routern måste utvärdera slutpunkt, funktion, kontogodkännande och region tillsammans. En leverantörsomfattande etikett som "ZDR enabled" är för grov för produktionspolicy.

Referensarkitektur

En retention-medveten multi-model AI API gateway behöver fem komponenter i sökvägen för begäran:

1. Request classifier: extraherar datakänslighet, hyresgästkontrakt, regionkrav, funktionsanvändning, filinmatning, verktygsanvändning och loggningsbehörigheter.
2. Policylösare: mappar begäran till en kanonisk lagringspolicy, vanligtvis från hyresgäst, projekt, miljö, API-nyckel och metadata för arbetsbelastning.
3. Provider-kapacitetsregister: registrerar leverantörs-, slutpunkt-, modell-, funktions-, region- och kontolagringsfunktioner med daterade bevis.
4. Policyutvärderare: filtrerar kandidatrutter och returnerar antingen en godkänd rutt eller ett policyavslag med en orsakskod.
5. Revisionssändare: registrerar vald rutt, matchad policy, kapacitetsantaganden, region, lagringsflaggor och innehållsloggningsläge.

Den här arkitekturen håller beslut om lagring och bosättning åtskilda från kostnad, latens och reserv. Kostnadsdirigering kan fortfarande ske, men bara inom den uppsättning rutter som uppfyller lagringspolicyn.

Definiera en kanonisk lagringspolicy

Börja med ett leverantörsneutralt policyobjekt. Kopiera inte en leverantörs terminologi till ditt interna avtal. Din interna policy bör beskriva vad arbetsbelastningen får göra, inte hur en specifik leverantör marknadsför 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"
}

För mindre begränsade arbetsbelastningar, använd explicit avslappning istället för att sakna fält:

{
  "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 viktiga fälten är inte bara lagringstid. Statliga funktioner, filer, jordning, batchbearbetning och loggningsläge påverkar alla om en rutt är acceptabel.

Bygg leverantörskapacitetsregistret

Förmågasregistret är routerns källa till sanning. Den ska behållas som kontrollerad konfiguration, inte spridd genom leverantörsadaptrar.

En användbar post inkluderar:

• provider: leverantör eller molnplattform.
• account_scope: organisation, projekt, implementering, prenumeration eller hyresgäst där en inställning är godkänd.
• endpoint: chatt, svar, meddelanden, batch, filer, assistenter, inbäddningar, jordning, vektorbutik eller annan API yta.
• model_family och valfritt model_id: eftersom modellens kvalificering kan skilja sig åt.
• region_mode: global, regional, datazon, kundutpekad geografi eller leverantörsspecifik motsvarighet.
• content_retention: ingen lagring efter svar, lagring av missbruksövervakning, lagring av applikationstillstånd, härledda loggar med fast varaktighet eller okända.
• training_use: inaktiverad som standard, opt-in eller okänd.
• human_review: aktiverad, modifierad, inaktiverad eller okänd.
• stateful_storage: om slutpunkten eller funktionen lagrar konversationsstatus, filer, vektordata, slutföranden eller batchinmatningar.
• feature_flags: jordning, filer, verktyg, cache, lagrade utdata, batch, assistenter eller motsvarande funktioner.
• evidence: källdokumentets namn, webbadress, hämtningsdatum och ägarens granskningsdatum.

Exempel:

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

Rekommendationen är att behandla okänt som nekat för känsliga arbetsbelastningar. Om en kapacitetspost saknar lagringsfält, regionläge eller funktionskvalificering bör den inte uppfylla strikta policyer.

Klassificera förfrågan före routing

Klassificering bör ske före modellval. En bra klassificerare kombinerar statisk metadata och begäran om inspektion:

• API nyckelomfattning: hyresgäst, team, miljö, applikation och typ av arbetsbelastning.
• Kontraktstaggar: ingen lagring, endast EU, HIPAA-liknande kontroller, finansiell data, kundkonfidentiell eller endast internt.
• Laddningstyp: fri text, dokument, bild, filreferens, inbäddningsdata, verktygsresultat eller hämtad kontext.
• Användning av funktioner: webbjordning, filuppladdning, vektorlagring, batchjobb, lagrad konversationshistorik, verktygsanrop eller svarslagring.
• Loggningsläge: fullständigt innehåll tillåtet, redigerat innehåll tillåtet, endast metadata eller inget programlogginnehåll.
• Regionala tips: användarens plats, hyresgästens datahem, projektregion eller distributionsregion.

Lita inte bara på automatisk identifiering av känsliga data. Använd deklarerad arbetsbelastningspolicy från API-nyckeln eller projektet som primär källa, använd sedan klassificerare för att skärpa policyn när nyttolasten innehåller risksignaler.

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 praktiken innebär detta att en kundsupportnyckel som standard inte kan behållas, medan en intern experimentnyckel kan tillåta bredare routing. Om samma supportnyckel försöker ladda upp en fil, bör den effektiva policyn inkludera file_storage_allowed=false såvida det inte finns en godkänd rutt med filkapacitet.

Utvärdera policy före kostnads- eller fördröjningsrutt

Utvärderaren bör fungera som ett filter. Den får en policy, begärande funktioner och rutter för kandidatleverantörer. Den returnerar endast rutter som uppfyller policyn.

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

Denna beställning är viktig. Reservrutt ska inte hoppa till en otillåten leverantör under ett avbrott. Batch routing bör inte flytta en begäran om ingen retention till en asynkron jobbbutik. Jordning bör inte aktivera en funktion som introducerar härledda loggar när policyn förbjuder det.

Om din plattform avslöjar en OpenAI-kompatibel multimodell API, håll kompatibilitetslagret ärligt: samma förfrågan kan kompilera till olika leverantörsbaserade funktioner. Policyutvärderaren måste inspektera den kompilerade begäran, inte bara den ursprungliga SDK-formen.

Blockera riskabla funktionskombinationer uttryckligen

Den säkraste implementeringen är att skapa uttryckliga förnekelsesregler för kända högriskkombinationer. Exempel:

• NO_RETENTION + FILE_UPLOAD: neka om inte den specifika filändpunkten och kontoinställningen är godkända för policyn.
• NO_RETENTION + VECTOR_STORE: neka såvida inte vektorlagringen finns i din egen kontrollerade lagring och leverantören aldrig får beständig filstatus.
• NO_RETENTION + STORED_RESPONSE: tvinga svarslagringsflaggor av eller neka om slutpunkten inte kan inaktivera lagring.
• EU_ONLY + GLOBAL_DEPLOYMENT: neka om bearbetning kan ske utanför den tillåtna regionen eller datazonen.
• NO_RETENTION + WEB_GROUNDING: neka om jordningsfunktionen lagrar härledda fråge- eller sammanhangsloggar bortom policyn.
• METADATA_ONLY_LOGGING + DEBUG_TRACE: undertryck uppmaning och slutförande innehåll från programloggar och spår.
• ZDR_REQUIRED + STATEFUL_ASSISTANT_THREAD: neka om inte funktionen är specifikt kvalificerad under kontots godkända kontroller.

Returnera specifika fel. Ett användbart förnekande talar om för utvecklaren vad som misslyckades och vilka godkända alternativ som finns.

{
  "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 inferensloggning från operationell telemetri

Retentionspolicy bör inte tvinga gatewayen att bli blind. Du kan vanligtvis behålla operativ telemetri utan att lagra meddelanden eller färdigställande innehåll.

För strikta arbetsbelastningar, bevara:

• request ID and Trace ID;
• identifierare för hyresgäst, projekt, API nyckel och arbetsbelastning;
• policy-ID och policyversion;
• leverantör, slutpunkt, modell, distribution och region som används;
• funktionsflaggor begärda och tillåtna;
• orsakskoder för beslut;
• tokenantal, latens, statuskod och kostnadsmetadata;
• hashar eller stabila fingeravtryck för deduplicering, om de godkänns av policyn.

Undertryck eller redigera:

• rå uppmaningar;
• råavslut;
• uppladdat filinnehåll;
• verktygsutdata som innehåller kunddata;
• hämtade sammanhang från känsliga system;
• leverantör felsöker nyttolaster som duplicerar innehåll.

Det är här retention routing ansluter till leverantörsneutral LLM observability. Observerbarhet bör bevisa vad som hände utan att utöka uppsättningen system som behåller känsligt innehåll.

Avlämna revisionsbevis för varje beslut

En granskningspost bör förklara varför en rutt tillåts eller nekades. Det behöver inte fullständigt innehåll för att vara användbart.

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

För nekade förfrågningar, behåll samma struktur med decision=deny och orsakskoder som REGION_NOT_ALLOWED, GROUNDING_RETENTION_EXCEEDS_POLICY eller STATEFUL_STORAGE_NOT_ALLOWED.

Använd kontraktstester för lagringsregler

Retentionsrouting bör ha automatiserade tester. De viktiga testerna är inte bara enhetstester för enskilda leverantörer; de är kontraktstester för policybeteende mellan olika leverantörskombinationer.

Testfall med högt värde inkluderar:

• Ingen lagringspolicy plus filuppladdning bör neka om det inte finns en specifik godkänd rutt med filkapacitet.
• policy för endast EU plus global implementering bör nekas även när modellen annars är tillgänglig.
• Nolllagringspolicy plus lagrad konversationshistorik bör neka eller tvinga bort lagring när det stöds.
• Jordningsfunktion med lagring av härledd logg bör nekas enligt policyn för ingen lagring.
• Policy för loggning av endast metadata bör förhindra uppmaning och slutförande innehåll från spår, loggar och felrapporter.
• Providerkapacitetspost med okänd lagring bör nekas för reglerade arbetsbelastningar.
• Tillbakagång efter leverantörsavbrott bör förbli inom den kvalificerade ruttuppsättningen.
• Batchbearbetning bör nekas när batchslutpunkten lagrar indatafiler längre än vad policyn tillåter.

Testa även drift. När en kapacitetspost ändras bör systemet visa vilka policyer och rutter som påverkas innan ändringen når produktion.

Operational Ownership

Det svåra är att inte skriva den första utvärderaren. Det håller registret aktuellt och förhindrar odokumenterade undantag.

Tilldela ägare för:

• provider documentation review kadens;
• godkännandestatus för kontroller på kontonivå som modifierad övervakning av missbruk eller noll datalagring;
• regional distributionslista;
• funktionsberättigande för filer, vektorlagringar, jordning, batch och lagrade svar;
• arbetsflöde för policyundantag;
• revisionspostlagring och åtkomstkontroll;
• felmeddelanden som vänder sig till utvecklaren och godkända alternativ.

Varje kapacitetspost bör ha ett granskningsdatum. Om den löper ut bör strikta policyer sluta lita på den eller kräva manuellt godkännande. Leverantörsdokument och funktionsbeteende ändras för ofta för att detta ska vara statisk konfiguration.

Avvägningar

En strikt retentionsrouter minskar tillgängliga modellval. Vissa förhandsgranskningsmodeller, stateful API:er, jordningsverktyg och filarbetsflöden kommer att vara otillgängliga för känsliga arbetsbelastningar. Det är poängen med kontrollen, men produktteam behöver tydliga alternativ.

Regional routing kan öka latensen eller kostnaden när den snabbaste implementeringen är global men arbetsbelastningen kräver en specifik geografi eller datazon. Gör detta synligt i telemetri så att teamen förstår varför en begäran använde en dyrare eller långsammare rutt.

Blockering av tillståndsfulla funktioner kan få team att bygga sitt eget minneslager. Det kan vara rätt arkitektur, men det behöver fortfarande lagringspolicy, raderingsarbetsflöden, kryptering, åtkomstkontroll och granskningsloggar. Att flytta staten från leverantören tar inte bort förvaltningsarbetet.

Snabb och slutförande redaktion skyddar känslig data, men det försvagar felsökning och kvalitetsgranskning. Använd reproducerbar begärandemetadata, deterministiska testfixturer, kontrollerad sampling för tillåtna arbetsbelastningar och dokumenterad brytglasåtkomst där policyn tillåter det.

Rekommendationer

• Tvinga upp retention och uppehållstillstånd före modelldirigering, inte som en efterbearbetningskontroll.
• Modellfunktioner på leverantörs-, slutpunkts-, funktions-, region- och kontogodkännandenivå.
• Använd deny-by-default-beteende för reglerade eller kundkontraktsbundna arbetsbelastningar.
• Behandla filuppladdning, vektorlagringar, webbjordning, batchbearbetning och lagrad konversationshistorik som separata policydimensioner.
• Behåll operativ telemetri även när uppmanings- och slutförandeinnehåll måste undertryckas.
• Skicka ut granskningsposter som inkluderar policy, rutt, kapacitetsbevis, region, lagringsflaggor och orsakskoder.
• Skriv kontraktstester för kombinationer av högriskfunktioner och reservbeteende.

Prognos: Retention Routing kommer att bli ett standardgatewaylager

Den troliga riktningen är att lagringsrouting blir ett standardlager i företags LLM-plattformar, liknande hastighetsgränser, budgetkontroller och observerbarhet. När leverantörer lägger till fler tillståndsfulla verktyg, jordningsalternativ, cachar, filer, agenter och hanterade minnesfunktioner kommer den säkra rutten att bero mindre på modellnamnet och mer på den fullständiga körvägen.

Det är en förutsägelse, inte ett aktuellt universellt krav. Det nuvarande kravet är enklare: om ditt team lovar ingen lagring, regional bearbetning, ingen utbildningsanvändning eller ingen mänsklig granskning, behöver din gateway tillräckligt med policylogik och bevis för att bevisa att varje begäran följde dessa begränsningar.

Aktiveringsbar slutsats

Bygg lagringsroutern som en policyport framför valet av leverantör. Definiera en kanonisk lagringspolicy, klassificera varje begäran före routning, underhåll ett daterat register för leverantörskapacitet, neka osäkra kombinationer som standard och logga granskningsbevis utan att behålla känsligt innehåll.

Designmålet är inte att hitta en leverantör som alltid är säker. Målet är att bevisa att en specifik begäran, med hjälp av en specifik slutpunkt och funktionsuppsättning, under ett specifikt konto och område, uppfyllde policyn innan den skickades.

Relaterad läsning

• leverantörsneutral LLM-observationsdesign