Dataretention-Aware AI API Routing: Genomför ZDR-, uppehålls- och loggningspolicyer vid gatewayen

Säkerhetsteam behöver inte bara veta vilken modell som är billigast, snabbast eller mest kapabel. De behöver veta om en specifik begäran lagligt och operativt kan skickas till en specifik leverantör, slutpunkt, region, funktion och loggningsläge.

Det är svårare än det låter. En modell kan vara acceptabel för vanlig intern chatt, men inte för kund-PII. En leverantör kan erbjuda noll datalagring för en API-sökväg, medan en sökgrundningsfunktion lagrar uppmaningar och utdata under en bestämd period. En region kan ha stöd för lagringsresidency, men inte det bearbetningsläge du förväntade dig. Utvecklarägda loggar kan vara konfigurerbara, medan loggar för övervakning av missbruk av leverantörer följer en annan policy.

Det praktiska svaret är att flytta beslut om lagring från enskilda applikationer och till AI API-gatewayen. Gatewayen bör klassificera begäran, utvärdera den mot en leverantörskapacitetsmatris, blockera inkompatibla funktioner, dirigera endast till godkända modellprofiler och registrera ett policybeslut utan att lagra råuppmaningar som standard.

Läsarproblemet: leverantörens sekretessvillkor är inte körtidskontroller

De flesta team börjar med ett kalkylblad eller säkerhetsgranskning som säger vilka AI-leverantörer som är godkända. Det är användbart, men det räcker inte för produktionsdirigering.

Appar gör körtidsval:

• Vilket modell-ID ska hantera denna begäran?
• Bör begäran använda sökjordning, filuppladdning, kodexekvering, batchbearbetning, promptcache eller lagrade konversationer?
• Vilken region eller slutpunkt ska behandla begäran?
• Kan systemet logga råprompten för felsökning?
• Kan reservrutt skicka samma begäran till en annan leverantör?

Var och en av dessa val kan ändra lagringsprofilen. En begäran som var kompatibel i vanligt chattläge kan bli icke-kompatibel när utvecklaren aktiverar jordning eller beständig konversationslagring. En reservregel utformad för tillförlitlighet kan av misstag dirigera reglerad data till en leverantörssökväg som inte har godkänts för noll datalagring, datauppehållstillstånd eller kontroll av missbruksövervakning.

Rekommendation: behandla lagringsbeteende som en förstklassig routingbegränsning, inte som dokumentation kopplad till ett leverantörskonto.

Fakta att koda innan policy utformas

De exakta villkoren varierar beroende på leverantör, produkt, kontrakt, region, slutpunkt och funktion. Lita inte på minne eller en engångsrecension. Bygg en källägd matris och uppdatera den när villkoren ändras.

Flera aktuella offentliga leverantörsdokument illustrerar varför detta är nödvändigt:

• OpenAI: API-dataresidency dokumenteras som projektkonfigurerad, med regionala förfrågningar som kräver regionspecifika domänprefix. OpenAI skiljer också lagringsstöd från bearbetningsstöd per region och noterar ytterligare krav för regioner utanför USA. OpenAI anger att icke-amerikansk API-dataresidency kräver godkännande för kontroller av missbruksövervakning och en modifierad retentionstillägg.
• Anthropic: Anthropic dokumenterar noll datalagring för API-relaterade kommersiella användningsfall, samtidigt som det noteras att vissa relaterade produkter eller efterlevnadsflöden har separata lagringsmodeller, inklusive längre lagring för aktivitetsflöde och transkriptioner av fjärrsessioner.
• Google Gemini: Termer för Gemini API skiljer mellan obetalda och betalda tjänster. För obetalda tjänster kan Google använda inskickat innehåll och genererade svar för att förbättra produkter; för betaltjänster, säger Google att uppmaningar och svar inte används för att förbättra produkter. Gemini Developer API ZDR-dokumentation säger att betaltjänstloggar för missbruksövervakning normalt behåller uppmaningar och svar under en begränsad period, medan godkända ZDR-projekt rensar användarinnehåll och identifierbar metadata innan de loggas.
• Funktionsspecifik lagring: Tvillingdokumentationen anger att jordning med Google Sök och jordning med Google Maps lagrar uppmaningar, kontextuell information och genererad utdata i 30 dagar, utan något sätt att inaktivera den lagringen när dessa funktioner används.
• Utvecklarägda loggar: Gemini API-loggningsdokumentation säger att utvecklarägda API-loggar kan sparas i upp till 55 dagar som standard för faktureringsaktiverade projekt och att utvecklare kan välja kortare fönster som 7, 14 eller 28 dagar.
• Riskhantering: NIST:s Generativa AI-profil rekommenderar att man övervakar AI-genererat innehåll för sekretessrisker och kopplar generativa AI-policyer till befintliga data, programvara, juridiska, efterlevnads- och riskhanteringsprocesser.

Detta är fakta att verifiera mot aktuell leverantörsdokumentation innan lansering. Den arkitektoniska lektionen är stabil: retention är inte en boolesk leverantörsnivå.

Arkitektur: en gateway-policymotor i sökvägen för begäran

En retention-medveten gateway har fem kärnkomponenter:

1. Begär känslighetsklassificerare: märker arbetsbelastningen före routing.
2. Provider-kapacitetsmatris: beskriver leverantör, modell, slutpunkt, region, retention, loggning och funktionsbeteende.
3. Policy-as-code-regler: konvertera säkerhetskraven till körtidsbeslut för att tillåta, neka eller granska.
4. Funktionsgrindlager: blockerar funktioner som ändrar kvarhållning om det inte uttryckligen tillåts.
5. Revisions- och analyslager: registrerar användbar metadata utan att lagra råuppmaningar som standard.

Gatewayen behöver inte förstå alla juridiska nyanser. Den måste genomdriva de beslut som dina juridiska, säkerhets-, efterlevnads- och plattformsteam har godkänt.

Steg 1: klassificera begärans känslighet innan du väljer en modell

Börja med en liten klassificeringstaxonomie. Det ska vara tillräckligt enkelt för utvecklare att använda, men tillräckligt uttrycksfullt för att driva policy.

Exempel på känslighetsetiketter:

• offentlig: offentlig dokumentation, marknadsföringsexemplar, offentlig webbplatsinnehåll.
• intern: icke-offentlig företagsinformation med låg känslighet.
• konfidentiellt: strategi, kontrakt, kundsammanhang, outgivna produktdetaljer.
• customer_pii: namn, e-postadresser, adresser, kontoidentifierare, supportavskrifter.
• reglerad: vård-, finansiell, juridisk, utbildnings- eller jurisdiktionsspecifik skyddad data.
• källkod: proprietär kod, konfiguration, arkitekturfiler.
• referenser: hemligheter, tokens, lösenord, privata nycklar. I de flesta system bör detta blockeras, inte dirigeras.

Klassificering kan komma från flera källor:

• En rubrik som tillhandahålls av programmet, till exempel X-Data-Class: customer_pii.
• Hyresgästpolicy, där all trafik från en reglerad kund behandlas som reglerad såvida den inte nedgraderas av en godkänd regel.
• Slutpunktspolicy, där sammanfattning av supportärenden är som standard customer_pii.
• Lättviktsinnehållssökning efter autentiseringsuppgifter, uppenbara PII eller policyöverträdelser.

Rekommendation: är inte helt beroende av automatisk upptäckt. Kräv att appar deklarerar den avsedda dataklassen, använd sedan skanning för att fånga uppenbara felmatchningar eller tvinga fram en säkrare klass.

Steg 2: Skapa en leverantörskapacitetsmatris

Förmågasmatrisen är källan till sanning som routern utvärderar. Den bör versioneras, granskas och testas som produktionskonfiguration.

Exempelfält:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "provider": "provider_x",
  "model": "modell-stor",
  "api_family": "chat_completions",
  "endpoint": "https://eu.example-provider.com/v1",
  "region": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": sant,
  "zdr_contract_required": sant,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": false,
  "supported_features": {
    "plain_chat": sant,
    "streaming": sant,
    "tool_calls": sant,
    "search_grounding": false,
    "maps_grounding": false,
    "file_uppladdning": false,
    "batch": falskt,
    "stored_conversations": false
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Använd modellprofiler snarare än råmodell-ID:n. En profil kombinerar modell, leverantör, slutpunkt, region, funktionsuppsättning och retentionsställning. Utvecklare begär model_profile: compliant_summarization, inte bara model: fastest-large-model.

Rekommendation: inkludera kontraktsförutsättningar i matrisen. En rutt är inte ZDR-godkänd bara för att en leverantör erbjuder ZDR någonstans. Det godkänns endast när ditt konto, projekt, region och slutpunkt uppfyller de obligatoriska villkoren.

Steg 3: skriv policy-as-code-regler

Policyregler bör vara tydliga, testbara och läsbara av säkerhets- och plattformsteam.

Exempel på regler i pseudokod:

neka om data_class == "referenser"
  anledningen "referenser_måste_inte_sändas_till_modell"
tillåt endast om data_class i ["regulated", "customer_pii"]
  och profile.zdr_eligible == sant
  och profile.zdr_contract_required_satisfied == sant
  reason_on_failure "model_profile_not_zdr_eligible"
neka om residency_required == "eu"
  och "eu" inte i profile.processing_residency
  anledningen "region_processing_not_supported"
neka om data_klass i ["konfidentiell", "kund_pii", "reglerad"]och request.raw_prompt_logging == sant
  anledningen "raw_prompt_logging_not_allowed"
neka om request.features.search_grounding == sant
  och policy.requires_zdr == sant
  och profile.feature_storage.search_grounding_days > 0
  anledning "grounding_requires_retained_content"
neka om fallback_profile.retention_level < primary_profile.retention_level
  anledning "fallback_weakens_retention_policy"

Dessa regler bör köras före valet av leverantör och igen före reserv. Reservrutt är en vanlig källa till oavsiktlig policyavvikelse: den primära rutten kan vara kompatibel, medan reservrutten bara är tillgänglig.

Steg 4: Betrakta verktyg och funktioner som funktioner för att ändra kvarhållning

Modellerretention är inte enbart en egenskap hos basmodellen. Funktioner ändrar ofta beteendet för lagring, loggning eller granskning.

Ge varje funktion sina egna policyflaggor:

• Sökjordning: kan lagra uppmaningar, hämtad kontext och genererad utdata beroende på leverantörsvillkor.
• Kartor eller platsjordning: kan införa platsspecifika loggar eller lagringsregler.
• Filuppladdning: kan lagra filer separat från uppmaningar och svar.
• Kodkörning: kan skapa tillfälliga filer, körningsloggar eller sandlådeartefakter.
• Batchjobb: kan ha andra beteenden för kvarhållning, köbildning och resultatlagring än synkrona API-anrop.
• Lagrade konversationer: innehåll avsiktligt kvarstår och bör aldrig döljas bakom ett allmänt chattalternativ.
• Instrumentpaneler för utvärdering eller granskning: kan skapa arbetsflöden för mänsklig granskning eller datauppsättningar med längre livslängd.

Rekommendation: gör att funktioner som ändrar behållningen ska väljas på hyresgäst- och ruttnivå. Om en utvecklare aktiverar grounding_search=true, bör gatewayen omvärdera begäran mot funktionslagringsregler innan den skickas uppströms.

Steg 5: bevara analyser utan att lagra råa uppmaningar

Retentionsmedveten routing bör inte blinda plattformsteamet. Du kan behålla användbar AI-användningsanalys samtidigt som du minimerar innehållslagring.

Säkra standardtelemetrifält:

• gäst-ID och projekt-ID
• hashat eller internt API-nyckel-ID
• modellprofil-ID och leverantörs-ID
• begär tidsstämpel och region
• antalet indata, utdata, cachelagrade och resonemangstoken när det är tillgängligt
• latens, statuskod, antal försök igen och reservbeslut
• uppskattad och avräknad kostnad
• dataklassificeringsetikett
• policyversion och skäl för policybeslut
• funktionsflaggor begärda och funktionsflaggor tillåtna

Undvik att lagra råuppmaningar och modellutdata som standard för konfidentiell trafik. Om felsökning kräver innehåll, använd ett kontrollerat arbetsflöde:

• godkännande av kund eller hyresgäst
• smalt tidsfönster
• provtagningsgräns
• redigeringspass
• separat åtkomstkontroll
• kort utgångsdatum
• revisionslogg över vem som aktiverade det och varför

Detta är en avvägning. Blockering av råa promptloggar gör felsökning, support, kvalitetsgranskning och missbruksutredning svårare. Men att lagra allt som standard skapar en större sekretess-, intrångs- och efterlevnadsyta.

Steg 6: returnera skäl för avslag som kan åtgärdas

En generisk 403 förbjuden frustrerar utvecklare och uppmuntrar till lösningar. Returnera en stabil maskinläsbar orsak och en förklaring som kan läsas av människor.

Exempel på svar:

{
  "error": {
    "type": "policy_denied",
    "code": "grounding_requires_30_day_storage",
    "message": "Sökjordning är inte tillåten för arbetsbelastningar märkta requires_zdr eftersom denna leverantörsfunktion lagrar prompt, sammanhang och utdatainnehåll.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "choose_profile:zdr_plain_chat",
      "request_exception"
    ]
  }
}

Användbara avslagskoder inkluderar:

• model_profile_not_zdr_eligible
• region_processing_not_supported
• storage_residency_not_supported
• raw_prompt_logging_not_allowed
• feature_requires_content_storage
• fallback_weakens_retention_policy
• contract_prerequisite_missing
• credentials_detected

Steg 7: lägg till ett undantagsarbetsflöde, inte en dold bypass

Vissa undantag är legitima: incidentrespons, kundgodkänd felsökning, migreringstestning eller en tillfällig leverantörsbegränsning. Gatewayen bör stödja undantag utan att förvandla dem till permanent skuggpolicy.

Varje undantag bör innehålla:

• godkännares identitet
• begärande team eller hyresgäst
• länk för biljett eller riskgranskning
• affärsmotivering
• tillåtna modellprofiler och funktioner
• dataklasser omfattas
• utgångsdatum
• ytterligare loggningskrav

Rekommendation: gör undantagen snävare än vanlig policy. Undvik globala växlar som disable_retention_policy=true. Föredrar omfångade åsidosättningar som "tillåt loggning av felsökningsmeddelanden för klient A, slutpunkt B, under 24 timmar, med redaktion och säkerhetsgodkännande."

Operativ checklista

• Skapa en versionerad leverantörskapacitetsmatris.
• Tilldela en ägare för leverantörsvillkor, kontraktsförutsättningar och granskningar av kvarhållande.
• Kräv att applikationer deklarerar dataklass, bosättningskrav och begärda funktioner.
• Standard konfidentiell och reglerad trafik utan obearbetad loggning.
• Representera verktyg, jordning, filuppladdning, batch och lagrade konversationer som separata funktionsflaggor.
• Kör policykontroller före primär routing och före reservrutt.
• Loggpolicyversion, modellprofil, dataklass, funktionsflaggor och orsak till avslag.
• Håll analysmetadata åtskilda från meddelanden och utdatainnehåll.
• Testrepresentanten tillåter och nekar fall i CI.
• Granska policydrift närhelst en leverantör ändrar termer, regioner, slutpunkter eller funktioner.

Avvägningar att tydliggöra

Strikt routing minskar valmöjligheterna. ZDR- och uppehållsbegränsningar kan förhindra användning av den senaste modellen, den billigaste rutten eller en funktionsrik slutpunkt.

Regional routing kan öka latensen eller kostnaden. Den närmaste kompatibla regionen kanske inte stöder det önskade bearbetningsläget eller kan kräva en annan leverantörsväg.

Funktionsportar överraskar utvecklare. En utvecklare kanske tror att de bara aktiverar sökning, men säkerheten ser ett nytt lagringsbeteende. Dokumentation och förnekande meddelanden minskar friktionen.

Snabb minimering komplicerar felsökning. Team behöver redigerade exempel, hyresgästens godkända felsökningsfönster och stark metadata för att undersöka problem utan att lagra allt.

Matrisen kräver underhåll. Leverantörsvillkor ändras. Nya modeller lanseras. Regionerna expanderar. Funktioner går från beta till produktion. En inaktuell matris är värre än ingen matris eftersom den skapar falskt förtroende.

Vad är en rekommendation och vad är en förutsägelse?

Rekommendationer: framtvinga lagring vid gatewayen, klassificera förfrågningar före routning, bygg en leverantörskapacitetsmatris, blockera lagringsförändrande funktioner enligt policy, undvik obearbetad promptloggning som standard och versionera varje policybeslut.

Prognos: AI-plattformsteam kommer i allt högre grad att behandla sekretessställning som en del av modellvalet. Istället för att fråga "vilken modell ska vi använda?" applikationer kommer att fråga efter en modellprofil som uppfyller kapacitets-, kostnads-, latens-, uppehålls- och retentionsbegränsningar.

Prognos: leverantörsspecifika sekretessfunktioner kommer att fortsätta att skilja sig åt. Gateways som endast normaliserar förfrågnings- och svarsformat kommer inte att räcka; produktionsteam kommer också att behöva policynormalisering.

Aktiv slutsats

Datalagringsmedveten routing är inte en separat överensstämmelseinstrumentpanel. Den hör hemma i sökvägen för begäran.

Börja med tre leveranser: en taxonomi för förfrågningskänslighet, en versionerad leverantörskapacitetsmatris och en liten uppsättning policy-as-code-regler för ZDR, uppehållstillstånd, råloggning, reservfunktioner och bibehållsförändrande funktioner. Se sedan till att gatewayen returnerar tydliga förnekelseskäl och bevara analyser utan att lagra råinnehåll som standard.

Den designen centraliserar beslut som annars skulle vara utspridda över SDK-alternativ, miljövariabler, leverantörskonsoler och teamspecifika konventioner. Det ger också säkerhets- och plattformsteam ett praktiskt granskningsspår: vilken begäran var tillåten, vilken policyversion som tillämpades, vilken modellprofil som valdes och varför.

Relaterad läsning

• gateway-nivå användningsanalys
• bygga en leverantörskapacitetsmatris under en OpenAI-kompatibel API-migrering
• styrande agentverktyg med omfattningar, godkännanden och revisionsspår