Dataoppbevaringsbevisst AI API-ruting: håndhev ZDR-, residency- og loggingspolicyer ved gatewayen

Sikkerhetsteam trenger ikke bare å vite hvilken modell som er billigst, raskest eller best. De må vite om en spesifikk forespørsel juridisk og operativt kan sendes til en bestemt leverandør, endepunkt, region, funksjon og loggingsmodus.

Det er vanskeligere enn det høres ut. En modell kan være akseptabel for vanlig intern chat, men ikke for kunde-PII. En leverandør kan tilby null dataoppbevaring for én API-bane, mens en søkebasert funksjon lagrer forespørsler og utdata i en fast periode. En region kan støtte lagringsopphold, men ikke behandlingsmodusen du forventet. Utviklereide logger kan konfigureres, mens logger for overvåking av misbruk av leverandør følger en annen policy.

Det praktiske svaret er å flytte oppbevaringsbeslutninger ut av individuelle applikasjoner og inn i AI API-gatewayen. Gatewayen bør klassifisere forespørselen, evaluere den mot en leverandørkapasitetsmatrise, blokkere inkompatible funksjoner, rute kun til godkjente modellprofiler og registrere en policybeslutning uten å lagre rå meldinger som standard.

Leserproblemet: leverandørens personvernvilkår er ikke kjøretidskontroller

De fleste team starter med et regneark eller sikkerhetsgjennomgang som sier hvilke AI-leverandører som er godkjent. Det er nyttig, men det er ikke nok for produksjonsruting.

Apper foretar kjøretidsvalg:

• Hvilken modell-ID skal håndtere denne forespørselen?
• Bør forespørselen bruke søkejording, filopplasting, kodekjøring, batchbehandling, promptbufring eller lagrede samtaler?
• Hvilken region eller endepunkt skal behandle forespørselen?
• Kan systemet logge råmeldingen for feilsøking?
• Kan reserveruting sende den samme forespørselen til en annen leverandør?

Hvert av disse valgene kan endre oppbevaringsprofilen. En forespørsel som var kompatibel i vanlig chat-modus kan bli ikke-kompatibel når utvikleren slår på jording eller vedvarende samtalelagring. En reserveregel utviklet for pålitelighet kan ved et uhell rute regulerte data til en leverandørbane som ikke er godkjent for null dataoppbevaring, dataopphold eller misbruksovervåking.

Anbefaling: behandle oppbevaringsatferd som en førsteklasses rutingbegrensning, ikke som dokumentasjon knyttet til en leverandørkonto.

Fakta å kode før retningslinjer utformes

De nøyaktige vilkårene varierer etter leverandør, produkt, kontrakt, region, endepunkt og funksjon. Ikke stol på hukommelse eller en engangsgjennomgang. Bygg en kildeeid matrise og oppdater den når vilkårene endres.

Flere aktuelle offentlige leverandørdokumenter illustrerer hvorfor dette er nødvendig:

• OpenAI: API-dataresidency er dokumentert som prosjektkonfigurert, med regionale forespørsler som krever regionspesifikke domeneprefikser. OpenAI skiller også lagringsstøtte fra behandlingsstøtte etter region og merker seg tilleggskrav for ikke-amerikanske regioner. OpenAI sier at ikke-amerikansk API-dataresidency krever godkjenning for overvåking av misbruk og en modifisert oppbevaringstillegg.
• Anthropic: Anthropic dokumenterer null dataoppbevaring for API-relaterte kommersielle brukssaker, samtidig som det bemerkes at enkelte relaterte produkter eller samsvarsfeeder har separate oppbevaringsmodeller, inkludert lengre oppbevaring for aktivitetsfeed og transkripsjoner av eksterne økter.
• Google Gemini: Gemini API-vilkår skiller ubetalte og betalte tjenester. For ubetalte tjenester kan Google bruke innsendt innhold og genererte svar for å forbedre produktene; for betalte tjenester, sier Google at forespørsler og svar ikke brukes til å forbedre produktene. Gemini Developer API ZDR-dokumentasjon sier at logger for misbruksovervåking av betalte tjenester normalt beholder forespørsler og svar i en begrenset periode, mens godkjente ZDR-prosjekter sletter brukerinnhold og identifiserbare metadata før logging.
• Funksjonsspesifikk lagring: Gemini-dokumentasjonen sier at jording med Google Søk og jording med Google Maps lagrer forespørsler, kontekstuell informasjon og generert utdata i 30 dager, uten noen måte å deaktivere lagringen når disse funksjonene brukes.
• Utviklereide logger: Gemini API-loggingsdokumentasjon sier at utviklereide API-logger kan beholdes i opptil 55 dager som standard for faktureringsaktiverte prosjekter, og at utviklere kan velge kortere vinduer som 7, 14 eller 28 dager.
• Risikohåndtering: NISTs Generative AI Profile anbefaler overvåking av AI-generert innhold for personvernrisiko og koble generative AI-policyer til eksisterende data, programvare, juridiske, overholdelses- og risikostyringsprosesser.

Dette er fakta som skal verifiseres mot gjeldende leverandørdokumentasjon før utrulling. Den arkitektoniske leksjonen er stabil: oppbevaring er ikke ett boolsk leverandørnivå.

Arkitektur: en gateway-policymotor i forespørselsbanen

En oppbevaringsbevisst gateway har fem kjernekomponenter:

1. Request sensitivity classifier: merker arbeidsbelastningen før ruting.
2. Matrise for leverandørkapasitet: beskriver leverandør, modell, endepunkt, region, oppbevaring, logging og funksjonsadferd.
3. Policy-as-code-regler: konverter sikkerhetskrav til kjøretidstillat, avslå eller gjennomgå beslutninger.
4. Funksjonsportlag: blokkerer funksjoner som endrer oppbevaring med mindre det er eksplisitt tillatt.
5. Revisjons- og analyselag: registrerer nyttige metadata uten å lagre rå forespørsler som standard.

Porten trenger ikke å forstå alle juridiske nyanser. Den må håndheve avgjørelsene dine juridiske, sikkerhets-, compliance- og plattformteam har godkjent.

Trinn 1: klassifiser forespørselsfølsomhet før du velger en modell

Start med en liten klassifiseringstaksonomi. Det skal være enkelt nok for utviklere å bruke, men uttrykksfullt nok til å drive policy.

Eksempler på følsomhetsetiketter:

• offentlig: offentlig dokumentasjon, markedsføringskopi, offentlig nettstedinnhold.
• intern: ikke-offentlig selskapsinformasjon med lav sensitivitet.
• konfidensielt: strategi, kontrakter, kundekontekst, ufrigitte produktdetaljer.
• customer_pii: navn, e-postadresser, adresser, kontoidentifikatorer, støttetranskripsjoner.
• regulert: helsetjenester, økonomiske, juridiske, utdannings- eller jurisdiksjonsspesifikke beskyttede data.
• kildekode: proprietær kode, konfigurasjon, arkitekturfiler.
• legitimasjon: hemmeligheter, tokens, passord, private nøkler. I de fleste systemer bør dette blokkeres, ikke rutes.

Klassifisering kan komme fra flere kilder:

• En applikasjonsoverskrift, for eksempel X-Data-Class: customer_pii.
• Retningslinjer for leietakere, der all trafikk fra en regulert kunde behandles som regulert med mindre den nedgraderes av en godkjent regel.
• Endepunktpolicy, der oppsummering av støttebilletter er standard til customer_pii.
• Lettvektsinnhold skanning etter legitimasjon, åpenbare PII eller brudd på retningslinjene.

Anbefaling: er ikke helt avhengig av automatisk gjenkjenning. Krev at apper deklarerer den tiltenkte dataklassen, og bruk deretter skanning for å fange opp åpenbare uoverensstemmelser eller tvinge frem en sikrere klasse.

Trinn 2: Bygg en leverandørkapasitetsmatrise

Kanskapsmatrisen er kilden til sannheten ruteren vurderer. Den bør versjoneres, gjennomgås og testes som produksjonskonfigurasjon.

Eksempelfelt:

{
  "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": "ikke_brukt_til_trening_på_betalt_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": usant,
  "supported_features": {
    "plain_chat": sant,
    "streaming": sant,
    "tool_calls": sant,
    "search_grounding": usant,
    "maps_grounding": usant,
    "file_opplasting": usant,
    "batch": usant,
    "stored_conversations": usant
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Bruk modellprofiler i stedet for rå modell-ID-er. En profil kombinerer modell, leverandør, endepunkt, region, funksjonssett og oppbevaringsstilling. Utviklere ber om model_profile: compliant_summarization, ikke bare model: fastest-large-model.

Anbefaling: inkludere kontraktsmessige forutsetninger i matrisen. En rute er ikke ZDR-godkjent bare fordi en leverandør tilbyr ZDR et sted. Den godkjennes bare når kontoen, prosjektet, regionen og endepunktet oppfyller de nødvendige betingelsene.

Trinn 3: Skriv policy-as-code-regler

Retningslinjer bør være eksplisitte, testbare og lesbare av sikkerhets- og plattformteam.

Eksempel på regler i pseudokode:

deny if data_class == "legitimasjon"
  årsak "legitimasjon_må_ikke_sendes_til_modell"
tillat bare hvis dataklasse i ["regulated", "customer_pii"]
  og profile.zdr_eligible == sant
  og profile.zdr_contract_required_satisfied == sant
  reason_on_failure "model_profile_not_zdr_eligible"
avslå hvis residency_required == "eu"
  og "eu" ikke i profile.processing_residency
  grunn "region_processing_not_supported"
avslå hvis dataklasse i ["konfidensielt", "kunde_pii", "regulert"]og request.raw_prompt_logging == sant
  årsak "raw_prompt_logging_not_allowed"
avslå hvis request.features.search_grounding == sant
  og policy.requires_zdr == sant
  og profile.feature_storage.search_grounding_days > 0
  grunn "grounding_requires_retained_content"
avslå hvis fallback_profile.retention_level < primary_profile.retention_level
  årsak "fallback_weakens_retention_policy"

Disse reglene bør kjøres før leverandørvalg og igjen før fallback. Reserveruting er en vanlig kilde til utilsiktet policyavvik: den primære ruten kan være kompatibel, mens reserveruten bare er tilgjengelig.

Trinn 4: Betrakt verktøy og funksjoner som evner som endrer oppbevaring

Ikke modeller oppbevaring som en egenskap for basismodellen alene. Funksjoner endrer ofte atferd for lagring, logging eller gjennomgang.

Gi hver funksjon sine egne policy-flagg:

• Søkejording: kan lagre forespørsler, hentet kontekst og generert utdata avhengig av leverandørens vilkår.
• Kart eller posisjonsjording: kan introdusere posisjonsspesifikke logger eller oppbevaringsregler.
• Filopplasting: kan lagre filer separat fra forespørsler og svar.
• Kodekjøring: kan opprette midlertidige filer, utførelseslogger eller sandkasseartefakter.
• Batchjobber: kan ha annen oppbevaring, kødannelse og resultatlagringsadferd enn synkrone API-kall.
• Lagrede samtaler: med vilje vedvarer innhold og bør aldri skjules bak et generisk chattealternativ.
• Dashboards for evaluering eller gjennomgang: kan skape arbeidsflyter for menneskelig vurdering eller datasett med lengre levetid.

Anbefaling: la funksjoner som endrer oppbevaring velges på leietaker- og rutenivå. Hvis en utvikler aktiverer grounding_search=true, bør gatewayen revurdere forespørselen mot funksjonslagringsregler før den sendes oppstrøms.

Trinn 5: bevar statistikk uten å lagre rå meldinger

Retensjonsbevisst ruting bør ikke blinde plattformteamet. Du kan beholde nyttig AI-bruksanalyse samtidig som du minimerer innholdslagring.

Sikker standard telemetrifelt:

• leietaker-ID og prosjekt-ID
• hashed eller intern API-nøkkel-ID
• modellprofil-ID og leverandør-ID
• be om tidsstempel og region
• antall for inndata, utdata, bufrede og resonnementstokener når tilgjengelig
• forsinkelse, statuskode, antall forsøk på nytt og reservebeslutning
• estimert og avgjort kostnad
• dataklassifiseringsetikett
• policyversjon og policybeslutning
• funksjonsflagg forespurt og funksjonsflagg tillatt

Unngå å lagre rå meldinger og modellutdata som standard for konfidensiell trafikk. Hvis feilsøking krever innhold, bruk en kontrollert arbeidsflyt:

• godkjenning fra kunde eller leietaker
• smalt tidsvindu
• prøvetakingsgrense
• redaksjonspass
• separat tilgangskontroll
• kort utløp
• revisjonslogg over hvem som har aktivert det og hvorfor

Dette er en avveining. Blokkering av rå meldingslogger gjør feilsøking, støtte, kvalitetsgjennomgang og misbruksundersøkelse vanskeligere. Men lagring av alt som standard skaper en større overflate for personvern, brudd og samsvar.

Trinn 6: returner mulige avslagsgrunner

En generisk 403 forbidden frustrerer utviklere og oppmuntrer til løsninger. Returner en stabil maskinlesbar årsak og en menneskelesbar forklaring.

Eksempel på svar:

{
  "feil": {
    "type": "policy_denied",
    "code": "jording_requires_30_day_storage",
    "message": "Søkejording er ikke tillatt for arbeidsbelastninger merket requires_zdr fordi denne leverandørfunksjonen lagrer ledetekst, kontekst og utdatainnhold.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "choose_profile:zdr_plain_chat",
      "request_exception"
    ]
  }
}

Nyttige avslagskoder inkluderer:

• 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
• legitimasjonsoppdaget

Trinn 7: legg til en arbeidsflyt for unntak, ikke en skjult bypass

Noen unntak er legitime: hendelsesrespons, kundegodkjent feilsøking, migrasjonstesting eller en midlertidig leverandørbegrensning. Gatewayen skal støtte unntak uten å gjøre dem om til permanent skyggepolicy.

Hvert unntak bør inkludere:

• godkjenneridentitet
• anmodende team eller leietaker
• link til billett eller risikovurdering
• forretningsbegrunnelse
• tillatte modellprofiler og funksjoner
• dataklasser dekket
• utløpsdato
• ytterligere loggingskrav

Anbefaling: gjør unntak smalere enn ordinære retningslinjer. Unngå globale brytere som disable_retention_policy=true. Foretrekk overstyringer med omfang, for eksempel «tillat logging av feilsøkingsforespørsel for leietaker A, endepunkt B, i 24 timer, med redaksjon og sikkerhetsgodkjenning.»

Operasjonssjekkliste

• Opprett en versjonsbasert leverandørfunksjonsmatrise.
• Tildel en eier for leverandørvilkår, kontraktsforutsetninger og oppbevaringsvurderinger.
• Krev at apper skal deklarere dataklasse, bostedskrav og forespurte funksjoner.
• Standard konfidensiell og regulert trafikk uten ubehandlet logging.
• Representer verktøy, jording, filopplasting, batch og lagrede samtaler som separate funksjonsflagg.
• Kjør policysjekker før primær ruting og før reserveruting.
• Loggpolicyversjon, modellprofil, dataklasse, funksjonsflagg og årsak til avslag.
• Hold analysemetadata atskilt fra forespørsler og utdatainnhold.
• Testrepresentant tillater og avslår saker i CI.
• Gjennomgå retningslinjene hver gang en leverandør endrer vilkår, regioner, endepunkter eller funksjoner.

Avveininger å gjøre eksplisitt

Streng ruting reduserer valgmulighetene. ZDR- og bostedsbegrensninger kan forhindre bruk av den nyeste modellen, den billigste ruten eller et funksjonsrikt endepunkt.

Regional ruting kan øke ventetiden eller kostnadene. Det kan hende den nærmeste kompatible regionen ikke støtter ønsket behandlingsmodus, eller kan kreve en annen leverandørbane.

Funksjonsporter overrasker utviklere. En utvikler tror kanskje de bare aktiverer søk, men sikkerheten ser en ny oppbevaringsatferd. Dokumentasjon og avslagsmeldinger reduserer friksjonen.

Rask minimering kompliserer feilsøking. Team trenger redigerte prøver, leietakergodkjente feilsøkingsvinduer og sterke metadata for å undersøke problemer uten å lagre alt.

Matrisen krever vedlikehold. Leverandørvilkårene endres. Nye modeller lanseres. Regioner utvides. Funksjoner går fra beta til produksjon. En foreldet matrise er verre enn ingen matrise fordi den skaper falsk tillit.

Hva er en anbefaling, og hva er en prediksjon?

Anbefalinger: håndhev oppbevaring ved gatewayen, klassifiser forespørsler før ruting, bygg en leverandørkapasitetsmatrise, blokker oppbevaringsendrende funksjoner etter policy, unngå rå loggføring som standard, og versjoner hver policybeslutning.

Prediksjon: AI-plattformteam vil i økende grad behandle personvernstilling som en del av modellvalget. I stedet for å spørre "hvilken modell skal vi bruke?" applikasjoner vil be om en modellprofil som tilfredsstiller begrensninger for kapasitet, kostnader, ventetid, residency og oppbevaring.

Prediksjon: leverandørspesifikke personvernfunksjoner vil fortsette å variere. Gatewayer som bare normaliserer forespørsels- og svarformater vil ikke være nok; produksjonsteam vil også trenge policynormalisering.

Aktiv konklusjon

Dataoppbevaringsbevisst ruting er ikke et separat overholdelseskontrollpanel. Den hører hjemme i forespørselsbanen.

Begynn med tre leveranser: en taksonomi for sensitivitet for forespørsel, en versjonsbasert leverandørkapasitetsmatrise og et lite sett med policy-as-code-regler for ZDR-, residency-, rålogging, reserve- og oppbevaringsendrende funksjoner. Få deretter gatewayen til å returnere klare fornektelsesgrunner og bevar statistikk uten å lagre råinnhold som standard.

Denne utformingen sentraliserer beslutninger som ellers ville vært spredt over SDK-alternativer, miljøvariabler, leverandørkonsoller og teamspesifikke konvensjoner. Det gir også sikkerhets- og plattformteam et praktisk revisjonsspor: hvilken forespørsel som ble tillatt, hvilken policyversjon som ble brukt, hvilken modellprofil som ble valgt, og hvorfor.

Relatert lesing

• bygge en leverandørkapasitetsmatrise under en OpenAI-kompatibel API-migrering
• styringsagentverktøy med omfang, godkjenninger og revisjonsspor