Data-retention-aware AI API-routing: håndhæv ZDR-, opholds- og logføringspolitikker ved gatewayen

Sikkerhedsteams behøver ikke kun at vide, hvilken model der er billigst, hurtigst eller bedst. De skal vide, om en specifik anmodning lovligt og operationelt kan sendes til en bestemt udbyder, slutpunkt, region, funktion og logningstilstand.

Det er sværere end det lyder. En model kan være acceptabel til almindelig intern chat, men ikke til kunde-PII. En udbyder kan tilbyde nul dataopbevaring for én API-sti, mens en søgebaseret funktion gemmer prompter og output i en fast periode. En region understøtter muligvis lagerophold, men ikke den behandlingstilstand, du forventede. Udviklerejede logfiler kan konfigureres, mens logfiler for overvågning af misbrug af udbydere følger en anden politik.

Det praktiske svar er at flytte beslutninger om opbevaring ud af individuelle applikationer og ind i AI API-gatewayen. Gatewayen bør klassificere anmodningen, evaluere den i forhold til en matrix for udbyderkapacitet, blokere inkompatible funktioner, kun rute til godkendte modelprofiler og registrere en politikbeslutning uden at lagre rå prompter som standard.

Læserproblemet: udbyderens privatlivsvilkår er ikke køretidskontrol

De fleste teams starter med et regneark eller sikkerhedsgennemgang, der siger, hvilke AI-udbydere der er godkendte. Det er nyttigt, men det er ikke nok til produktionsdirigering.

Applikationer foretager kørselstidsvalg:

• Hvilket model-id skal håndtere denne anmodning?
• Skal anmodningen bruge søgejording, filupload, kodekørsel, batchbehandling, prompt-caching eller lagrede samtaler?
• Hvilket område eller slutpunkt skal behandle anmodningen?
• Kan systemet logge den rå prompt for fejlretning?
• Kan reserveruting sende den samme anmodning til en anden udbyder?

Hvert af disse valg kan ændre opbevaringsprofilen. En anmodning, der var kompatibel i almindelig chattilstand, kan blive ikke-kompatibel, når udvikleren slår jordforbindelse eller vedvarende samtalelagring til. En reserveregel, der er designet til pålidelighed, kan ved et uheld dirigere regulerede data til en udbydersti, der ikke er blevet godkendt til nul dataopbevaring, dataophold eller kontrol af misbrugsovervågning.

Anbefaling: Behandl opbevaringsadfærd som en førsteklasses routingbegrænsning, ikke som dokumentation knyttet til en udbyderkonto.

Fakta, der skal kodes, før politik udformes

De nøjagtige vilkår varierer efter udbyder, produkt, kontrakt, område, slutpunkt og funktion. Stol ikke på hukommelse eller en engangsgennemgang. Byg en kildeejet matrix, og opdater den, når vilkårene ændres.

Flere aktuelle offentlige udbyderdokumenter illustrerer, hvorfor dette er nødvendigt:

• OpenAI: API-dataresidency er dokumenteret som projektkonfigureret, med regionale anmodninger, der kræver regionsspecifikke domænepræfikser. OpenAI skelner også lagringsunderstøttelse fra behandlingsunderstøttelse efter region og bemærker yderligere krav til ikke-amerikanske regioner. OpenAI oplyser, at ikke-amerikansk API-dataresidency kræver godkendelse til kontrol med misbrugsovervågning og en modificeret opbevaringstillæg.
• Anthropic: Anthropic dokumenterer nul dataopbevaring for API-relaterede kommercielle brugssager, mens det bemærkes, at nogle relaterede produkter eller overholdelsesfeeds har separate opbevaringsmodeller, herunder længere opbevaring for aktivitetsfeed og transskriptioner af fjernsessioner.
• Google Gemini: Gemini API-vilkår skelner mellem ubetalte og betalte tjenester. For ubetalte tjenester kan Google bruge indsendt indhold og genererede svar til at forbedre produkter; for betalte tjenester, siger Google, at prompter og svar ikke bruges til at forbedre produkter. Gemini Developer API ZDR-dokumentation siger, at overvågningslogfiler for misbrug af betalte tjenester normalt gemmer meddelelser og svar i en begrænset periode, mens godkendte ZDR-projekter rydder brugerindhold og identificerbare metadata, før de logges.
• Funktionsspecifik lagring: Gemini-dokumentationen angiver, at jordforbindelse med Google Søgning og jordforbindelse med Google Maps gemmer meddelelser, kontekstuelle oplysninger og genereret output i 30 dage, uden at det er muligt at deaktivere denne lagring, når disse funktioner bruges.
• Udviklerejede logfiler: Gemini API-logføringsdokumentation siger, at udvikler-ejede API-logfiler som standard kan opbevares i op til 55 dage for faktureringsaktiverede projekter, og at udviklere kan vælge kortere vinduer såsom 7, 14 eller 28 dage.
• Risikostyring: NISTs Generative AI Profile anbefaler overvågning af AI-genereret indhold for privatlivsrisici og forbinder generative AI-politikker til eksisterende data, software, juridiske, compliance- og risikostyringsprocesser.

Dette er fakta, der skal verificeres i forhold til den aktuelle leverandørdokumentation før udrulning. Den arkitektoniske lektion er stabil: Fastholdelse er ikke et boolesk niveau på udbyderniveau.

Arkitektur: en gateway-politikmotor i anmodningsstien

En opbevaringsbevidst gateway har fem kernekomponenter:

1. Request sensitivity classifier: mærker arbejdsbyrden før routing.
2. Matrix for udbyderkapacitet: beskriver udbyder, model, slutpunkt, region, fastholdelse, logning og funktionsadfærd.
3. Politik-som-kode-regler: Konverter sikkerhedskrav til kørselstidstilladelse, afvisning eller gennemgang af beslutninger.
4. Funktionsgatelag: blokerer funktioner, der ændrer fastholdelse, medmindre det udtrykkeligt er tilladt.
5. Revisions- og analyselag: registrerer nyttige metadata uden at lagre rå prompter som standard.

Gatewayen behøver ikke at forstå alle juridiske nuancer. Den skal håndhæve de beslutninger, som dine juridiske, sikkerheds-, compliance- og platformsteam har godkendt.

Trin 1: klassificer anmodningsfølsomhed, før du vælger en model

Start med en lille klassifikationstaksonomi. Det skal være enkelt nok for udviklere at bruge, men udtryksfuldt nok til at drive politik.

Eksempler på følsomhedsetiketter:

• offentlig: offentlig dokumentation, markedsføringskopi, offentligt webstedsindhold.
• intern: ikke-offentlige virksomhedsoplysninger med lav følsomhed.
• fortroligt: strategi, kontrakter, kundekontekst, ikke-frigivne produktdetaljer.
• customer_pii: navne, e-mails, adresser, konto-id'er, supportudskrifter.
• reguleret: sundhedspleje, finansielle, juridiske, uddannelses- eller jurisdiktionsspecifikke beskyttede data.
• kildekode: proprietær kode, konfiguration, arkitekturfiler.
• legitimationsoplysninger: hemmeligheder, tokens, adgangskoder, private nøgler. I de fleste systemer bør dette blokeres, ikke omdirigeres.

Klassificering kan komme fra flere kilder:

• En applikationsleveret header, såsom X-Data-Class: customer_pii.
• Lejerpolitik, hvor al trafik fra en reguleret kunde behandles som reguleret, medmindre den nedgraderes af en godkendt regel.
• Endpunktspolitik, hvor support-ticket-opsummering som standard er customer_pii.
• Letvægtsindholdsscanning for legitimationsoplysninger, åbenlyse PII eller politikovertrædelser.

Anbefaling: er ikke helt afhængig af automatisk registrering. Kræv, at applikationer erklærer den tilsigtede dataklasse, og brug derefter scanning til at fange åbenlyse uoverensstemmelser eller tvinge en sikrere klasse.

Trin 2: Byg en matrix for udbyderkapacitet

Kompetencematricen er kilden til sandhed, som routeren vurderer. Den skal versioneres, gennemgås og testes ligesom produktionskonfiguration.

Eksempel på felter:

afvis hvis data_class == "legitimationsoplysninger"
  årsag til "legitimationsoplysninger_må_ikke_sendes_til_model"
tillad kun, hvis data_class i ["regulated", "customer_pii"]
  og profile.zdr_eligible == sand
  og profile.zdr_contract_required_satisfied == sand
  reason_on_failure "model_profile_not_zdr_eligible"
afvis hvis residency_required == "eu"
  og "eu" ikke i profile.processing_residency
  årsag til "region_processing_not_supported"
afvis hvis data_klasse i ["fortroligt", "kunde_pii", "reguleret"]og request.raw_prompt_logging == sand
  årsag til "raw_prompt_logging_not_allowed"
afvis hvis request.features.search_grounding == sand
  og policy.requires_zdr == sand
  og profile.feature_storage.search_grounding_days > 0
  årsag "grounding_requires_retained_content"
afvis hvis fallback_profile.retention_level < primary_profile.retention_level
  årsag til "fallback_weakens_retention_policy"