Usmerjanje API-ja z umetno inteligenco, ki upošteva hrambo podatkov: uveljavite politike ZDR, rezidenčnosti in beleženja na prehodu

Varnostne ekipe ne potrebujejo samo vedeti, kateri model je najcenejši, najhitrejši ali najzmogljivejši. Vedeti morajo, ali je določeno zahtevo zakonito in operativno mogoče poslati določenemu ponudniku, končni točki, regiji, funkciji in načinu beleženja.

To je težje, kot se sliši. Model je lahko sprejemljiv za običajen interni klepet, ne pa tudi za PID stranke. Ponudnik lahko ponudi ničelno hrambo podatkov za eno pot API-ja, medtem ko funkcija ozemljitve iskanja shranjuje pozive in rezultate za določeno obdobje. Regija lahko podpira rezidenčnost shranjevanja, ne pa tudi načina obdelave, ki ste ga pričakovali. Dnevnike v lasti razvijalca je mogoče konfigurirati, medtem ko dnevniki spremljanja zlorab ponudnika sledijo drugačnemu pravilniku.

Praktični odgovor je, da odločitve o hrambi premaknete iz posameznih aplikacij v prehod AI API. Prehod mora razvrstiti zahtevo, jo ovrednotiti glede na matriko zmogljivosti ponudnika, blokirati nezdružljive funkcije, usmerjati le do odobrenih profilov modela in zabeležiti odločitev pravilnika brez privzetega shranjevanja neobdelanih pozivov.

Težava z bralnikom: pogoji zasebnosti ponudnika niso nadzor časa izvajanja

Večina ekip začne s preglednico ali varnostnim pregledom, ki pove, kateri ponudniki umetne inteligence so odobreni. To je uporabno, vendar ni dovolj za usmerjanje proizvodnje.

Aplikacije izbirajo čas izvajanja:

• Kateri ID modela naj obravnava to zahtevo?
• Ali naj zahteva uporablja ozemljitev iskanja, nalaganje datotek, izvajanje kode, paketno obdelavo, hitro predpomnjenje ali shranjene pogovore?
• Katera regija ali končna točka naj obdela zahtevo?
• Ali lahko sistem zabeleži neobdelani poziv za odpravljanje napak?
• Ali lahko nadomestno usmerjanje pošlje isto zahtevo drugemu ponudniku?

Vsaka od teh izbir lahko spremeni profil zadrževanja. Zahteva, ki je bila skladna v navadnem načinu klepeta, lahko postane neskladna, ko razvijalec vklopi prizemljeno ali trajno shranjevanje pogovorov. Nadomestno pravilo, zasnovano za zanesljivost, lahko po nesreči preusmeri regulirane podatke na pot ponudnika, ki ni bil odobren za ničelno hrambo podatkov, rezidenčnost podatkov ali nadzor nad zlorabami.

Priporočilo: obnašanje hrambe obravnavajte kot prvovrstno omejitev usmerjanja, ne kot dokumentacijo, priloženo računu ponudnika.

Dejstva, ki jih je treba kodirati pred oblikovanjem politike

Natančni pogoji se razlikujejo glede na ponudnika, izdelek, pogodbo, regijo, končno točko in funkcijo. Ne zanašajte se na spomin ali enkratni pregled. Zgradite matriko v lasti vira in jo posodobite, ko se pogoji spremenijo.

Več trenutnih dokumentov javnih ponudnikov ponazarja, zakaj je to potrebno:

• OpenAI: Rezidenca podatkov API-ja je dokumentirana kot projektno konfigurirana, pri čemer regionalne zahteve zahtevajo predpone domene, specifične za regijo. OpenAI tudi razlikuje podporo za shranjevanje od podpore za obdelavo po regijah in ugotavlja dodatne zahteve za regije zunaj ZDA. OpenAI navaja, da rezidenčnost podatkov API-ja zunaj ZDA zahteva odobritev nadzora nadziranja zlorab in spremembo spremenjene hrambe.
• Anthropic: Anthropic dokumentira ničelno hrambo podatkov za primere komercialne uporabe, povezane z API-jem, hkrati pa ugotavlja, da imajo nekateri sorodni izdelki ali viri skladnosti ločene modele hrambe, vključno z daljšo hrambo za vir dejavnosti in prepise oddaljenih sej.
• Google Gemini: Izrazi Gemini API razlikujejo neplačane in plačljive storitve. Za neplačane storitve lahko Google uporabi predloženo vsebino in ustvarjene odgovore za izboljšanje izdelkov; za plačljive storitve Google pravi, da se pozivi in ​​odgovori ne uporabljajo za izboljšanje izdelkov. V dokumentaciji API-ja za razvijalce Gemini ZDR piše, da dnevniki spremljanja zlorab plačljivih storitev običajno zadržijo pozive in odgovore za omejeno obdobje, medtem ko odobreni ZDR projektira jasno uporabniško vsebino in prepoznavne metapodatke pred beleženjem.
• Shranjevanje za posamezne funkcije: Dokumentacija Gemini navaja, da Grounding z Google Iskanje in Grounding z Google Zemljevidi shranjujeta pozive, kontekstualne informacije in ustvarjene rezultate za 30 dni, brez možnosti, da bi onemogočili to shrambo, ko se te funkcije uporabljajo.
• Dnevniki v lasti razvijalca: Dokumentacija o beleženju API-ja Gemini pravi, da se lahko dnevniki API-ja v lasti razvijalca privzeto hranijo do 55 dni za projekte, ki omogočajo obračunavanje, in da lahko razvijalci izberejo krajša okna, kot so 7, 14 ali 28 dni.
• Upravljanje s tveganji: Profil generativne umetne inteligence NIST priporoča spremljanje vsebine, ustvarjene z umetno inteligenco, glede tveganj glede zasebnosti in povezovanje politik generativne umetne inteligence z obstoječimi podatki, programsko opremo, pravnimi procesi, procesi skladnosti in obvladovanja tveganja.

To so dejstva, ki jih je treba pred uvedbo preveriti glede na trenutno dokumentacijo prodajalca. Arhitekturna lekcija je stabilna: zadrževanje ni ena logična vrednost na ravni ponudnika.

Arhitektura: mehanizem pravilnika prehoda na poti zahteve

Prehod, ki se zaveda zadrževanja, ima pet osnovnih komponent:

1. Razvrstilnik občutljivosti zahtev: označi delovno obremenitev pred usmerjanjem.
2. Matrika zmogljivosti ponudnika: opisuje ponudnika, model, končno točko, regijo, zadrževanje, beleženje in delovanje funkcij.
3. Pravila pravilnika kot kode: pretvorite varnostne zahteve v odločitve o dovoljevanju, zavrnitvi ali pregledu izvajalnega časa.
4. Sloj vrat funkcij: blokira funkcije, ki spreminjajo hrambo, razen če je to izrecno dovoljeno.
5. Sloj revizije in analitike: privzeto beleži uporabne metapodatke brez shranjevanja neobdelanih pozivov.

Prehodu ni treba razumeti vseh pravnih nians. Uveljaviti mora odločitve, ki so jih odobrile vaše pravne skupine, skupine za varnost, skladnost in platforme.

1. korak: pred izbiro modela razvrstite občutljivost zahteve

Začnite z majhno klasifikacijsko taksonomijo. Biti mora dovolj preprost, da ga lahko uporabljajo razvijalci, vendar dovolj izrazit, da vodi politiko.

Primeri oznak občutljivosti:

• javno: javna dokumentacija, tržna kopija, javna vsebina spletnega mesta.
• interno: nejavne informacije o podjetju z nizko občutljivostjo.
• zaupno: strategija, pogodbe, kontekst stranke, neobjavljene podrobnosti o izdelku.
• customer_pii: imena, e-pošta, naslovi, identifikatorji računov, podporni prepisi.
• regulirano: zdravstveni, finančni, pravni, izobraževalni ali zaščiteni podatki, specifični za jurisdikcijo.
• source_code: lastniška koda, konfiguracija, arhitekturne datoteke.
• poverilnice: skrivnosti, žetoni, gesla, zasebni ključi. V večini sistemov je to treba blokirati, ne pa usmerjati.

Razvrstitev lahko izvira iz več virov:

• Glava, ki jo zagotovi aplikacija, kot je X-Data-Class: customer_pii.
• Pravilnik najemnikov, kjer se ves promet regulirane stranke obravnava kot reguliran, razen če ga odobri odobreno pravilo.
• Politika končne točke, kjer je povzetek vstopnic za podporo privzeto nastavljen na customer_pii.
• Lahko skeniranje vsebine glede poverilnic, očitnih osebnih podatkov ali kršitev pravilnika.

Priporočilo: ne zanašajte se v celoti na samodejno zaznavanje. Od aplikacij zahtevajte, da deklarirajo želeni podatkovni razred, nato uporabite skeniranje, da odkrijete očitna neujemanja, ali vsilite varnejši razred.

2. korak: zgradite matriko zmogljivosti ponudnika

Matrika zmogljivosti je vir resnice, ki jo ocenjuje usmerjevalnik. Treba ga je spreminjati, pregledati in preizkusiti kot produkcijsko konfiguracijo.

Primeri polj:

{
  "profile_id": "ponudnik_x.chat.eu.zdr",
  "ponudnik": "ponudnik_x",
  "model": "model-velik",
  "api_family": "chat_completions",
  "endpoint": "https://eu.example-provider.com/v1",
  "regija": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": drži,
  "zdr_contract_required": drži,
  "training_use": "ne_uporabljen_za_usposabljanje_on_paid_api",
  "abuse_monitoring": "odobreno_modificirano_retention_required",
  "dnevi_zadrževanja dnevnika razvijalcev": 0,
  "raw_prompt_logging_allowed": false,
  "podprte_funkcije": {
    "plain_chat": drži,
    "streaming": res,
    "tool_calls": drži,
    "search_grounding": false,
    "maps_grounding": napačno,
    "file_upload": false,
    "serija": napačno,
    "shranjeni_pogovori": napačno
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Uporabite profile modelov namesto neobdelanih ID-jev modelov. Profil združuje model, ponudnika, končno točko, regijo, nabor funkcij in zadrževalno držo. Razvijalci zahtevajo model_profile: compliant_summarization, ne samo model: fastest-large-model.

Priporočilo: v matriko vključite pogodbene predpogoje. Pot ni odobrena z ZDR samo zato, ker prodajalec nekje ponuja ZDR. Odobren je le, če vaš račun, projekt, regija in končna točka izpolnjujejo zahtevane pogoje.

3. korak: napišite pravila pravilnika kot kode

Pravila pravilnika morajo biti eksplicitna, preizkušena in berljiva skupinam za varnost in platformo.

Primer pravil v psevdokodi:

zavrni, če data_class == "poverilnice"
  razlog "poverilnic_ne_sme_biti_poslano_modelu"
dovoli samo, če data_class v ["regulated", "customer_pii"]
  in profile.zdr_eligible == true
  in profile.zdr_contract_required_satisfied == true
  reason_on_failure "model_profile_not_zdr_eligible"
deny if residency_required == "eu"
  in "eu" ni v profile.processing_residency
  razlog "region_processing_not_supported"
zavrni, če data_class v ["confidential", "customer_pii", "regulated"]in request.raw_prompt_logging == res
  razlog "raw_prompt_logging_not_allowed"
zavrni, če je request.features.search_grounding == true
  in policy.requires_zdr == res
  in profile.feature_storage.search_grounding_days > 0
  razlog "grounding_requires_retained_content"
zavrni, če je fallback_profile.retention_level < primarni_profil.retention_level
  razlog "fallback_weakens_retention_policy"

Ta pravila bi se morala izvajati pred izbiro ponudnika in znova pred nadomestnim. Nadomestno usmerjanje je pogost vir nenamernega odstopanja pravilnika: primarna pot je morda skladna, medtem ko je nadomestna pot le na voljo.

4. korak: orodja in funkcije obravnavajte kot zmožnosti za spreminjanje zadrževanja

Zadrževanja ne modelirajte samo kot lastnost osnovnega modela. Funkcije pogosto spremenijo shranjevanje, beleženje ali pregledovanje.

Dajte vsaki funkciji lastne oznake pravilnika:

• Ozemljitev iskanja: lahko shrani pozive, pridobljeni kontekst in ustvarjene rezultate, odvisno od pogojev ponudnika.
• Zemljevidi ali ozemljitev lokacije: lahko uvedejo dnevnike, specifične za lokacijo, ali pravila hrambe.
• Nalaganje datotek: lahko shrani datoteke ločeno od pozivov in odgovorov.
• Izvajanje kode: lahko ustvari začasne datoteke, dnevnike izvajanja ali artefakte peskovnika.
• Paketna opravila: imajo lahko drugačno obnašanje glede hrambe, čakalne vrste in shranjevanja rezultatov kot sinhroni klici API-ja.
• Shranjeni pogovori: namenoma ohranjajo vsebino in nikoli ne smejo biti skriti za splošno možnostjo klepeta.
• Nadzorne plošče za vrednotenje ali pregled: lahko ustvarijo delovne tokove človeških pregledov ali dolgotrajnejše nize podatkov.

Priporočilo: vključite funkcije za spreminjanje zadrževanja na ravni najemnika in poti. Če razvijalec omogoči grounding_search=true, mora prehod ponovno oceniti zahtevo glede na pravila za shranjevanje funkcij, preden jo pošlje navzgor.

5. korak: ohranite analitiko brez shranjevanja neobdelanih pozivov

Usmerjanje z upoštevanjem zadrževanja ne sme zaslepiti ekipe platforme. Obdržite lahko uporabno analitiko uporabe umetne inteligence in hkrati zmanjšate prostor za shranjevanje vsebine.

Varna privzeta telemetrična polja:

• ID najemnika in ID projekta
• zgoščeni ali interni ID ključa API
• ID profila modela in ID ponudnika
• zahtevaj časovni žig in regijo
• vhodni, izhodni, predpomnjeni in sklepni žeton se štejejo, ko so na voljo
• zakasnitev, statusna koda, število ponovnih poskusov in nadomestna odločitev
• ocenjeni in poravnani stroški
• oznaka klasifikacije podatkov
• različica pravilnika in razlog za odločitev o pravilniku
• zahtevane in dovoljene zastavice funkcij

Izogibajte se privzetemu shranjevanju neobdelanih pozivov in izhodov modela za zaupni promet. Če odpravljanje napak zahteva vsebino, uporabite nadzorovan potek dela:

• odobritev stranke ali najemnika
• ozko časovno okno
• omejitev vzorčenja
• prepustnica za urejanje
• ločen nadzor dostopa
• kratek iztek
• revizijski dnevnik, kdo ga je omogočil in zakaj

To je kompromis. Blokiranje neobdelanih dnevnikov pozivov oteži odpravljanje napak, podporo, pregled kakovosti in preiskavo zlorabe. Toda privzeto shranjevanje vsega ustvari večjo površino za zasebnost, kršitve in skladnost.

6. korak: vrnite utemeljene razloge za zavrnitev

Generični 403 forbidden frustrira razvijalce in spodbuja rešitve. Vrni stabilen strojno berljiv razlog in človeku berljivo razlago.

Primer odgovora:

{
  "napaka": {
    "vrsta": "pravilnik_zavrnjen",
    "koda": "ozemljitev_zahteva_30_dnevno_shranjevanje",
    "message": "Prizemljitev iskanja ni dovoljena za delovne obremenitve, označene z requires_zdr, ker ta funkcija ponudnika shranjuje poziv, kontekst in izhodno vsebino.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "dovoljena_dejanja": [
      "disable_search_grounding",
      "izberite_profil:zdr_plain_chat",
      "request_exception"
    ]
  }
}

Uporabne kode za zavrnitev vključujejo:

• 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

7. korak: dodajte potek dela izjem, ne skritega obvoda

Nekatere izjeme so upravičene: odziv na incident, odpravljanje napak, ki ga odobri stranka, testiranje selitve ali začasna omejitev ponudnika. Prehod mora podpirati izjeme, ne da bi jih spremenil v trajno politiko sence.

Vsaka izjema mora vsebovati:

• identiteta odobritelja
• zahtevajoča ekipa ali najemnik
• povezava za vstopnico ali pregled tveganja
• poslovna utemeljitev
• dovoljeni profili in funkcije modela
• zajeti podatkovni razredi
• datum poteka
• dodatne zahteve za beleženje

Priporočilo: naredite izjeme ožje od običajne politike. Izogibajte se globalnim stikalom, kot je disable_retention_policy=true. Dajte prednost preglasitvam v obsegu, kot je »dovoli beleženje poziva za odpravljanje napak za najemnika A, končno točko B, za 24 ur, z redakcijo in varnostno odobritvijo.«

Operativni kontrolni seznam

• Ustvarite matriko zmogljivosti ponudnika z različicami.
• Določite lastnika za ponudnikove pogoje, pogodbene predpogoje in preglede zadrževanja.
• Zahtevajte, da aplikacije navedejo podatkovni razred, zahtevo glede stalnega prebivališča in zahtevane funkcije.
• Privzeto zaupen in reguliran promet brez neobdelanega hitrega beleženja.
• Predstavi orodja, ozemljitev, nalaganje datotek, paketne in shranjene pogovore kot ločene zastavice zmogljivosti.
• Izvedite preverjanja pravilnika pred primarnim usmerjanjem in pred nadomestnim usmerjanjem.
• Različica pravilnika dnevnika, profil modela, razred podatkov, zastavice funkcij in razlog za zavrnitev.
• Hranite analitične metapodatke ločene od pozivne in izhodne vsebine.
• Preizkusni predstavnik dovoljuje in zavrača primere v CI.
• Preglejte spremembo pravilnika vsakič, ko ponudnik spremeni pogoje, regije, končne točke ali funkcije.

Kompromisi, ki naj bodo eksplicitni

Strogo usmerjanje zmanjšuje izbiro. ZDR in omejitve stalnega prebivališča lahko preprečijo uporabo najnovejšega modela, najcenejše poti ali končne točke z bogatimi funkcijami.

Regionalno usmerjanje lahko poveča zakasnitev ali stroške. Najbližja združljiva regija morda ne podpira želenega načina obdelave ali pa zahteva drugo pot ponudnika.

Vrata funkcij presenetijo razvijalce. Razvijalec morda misli, da omogoča le iskanje, vendar varnost vidi novo vedenje pri zadrževanju. Dokumentacija in sporočila o zavrnitvi zmanjšajo trenje.

Takojšnje minimiziranje oteži odpravljanje napak. Ekipe potrebujejo redigirane vzorce, okna za odpravljanje napak, ki jih odobrijo najemniki, in močne metapodatke za raziskovanje težav brez shranjevanja vsega.

Matrika zahteva vzdrževanje. Sprememba pogojev ponudnika. Lansiranje novih modelov. Regije se širijo. Funkcije se premaknejo iz beta v produkcijo. Zastarela matrica je slabša kot brez matrice, ker ustvarja lažno zaupanje.

Kaj je priporočilo in kaj napoved?

Priporočila: uveljavite zadrževanje na prehodu, razvrstite zahteve pred usmerjanjem, zgradite matriko zmogljivosti ponudnika, blokirajte funkcije, ki spreminjajo zadrževanje, s pravilnikom, privzeto se izogibajte neobdelanemu hitremu beleženju in različico vsake odločitve pravilnika.

Napoved: Ekipe platforme AI bodo vedno bolj obravnavale držo zasebnosti kot del izbire modela. Namesto vprašanja "kateri model naj uporabimo?" aplikacije bodo zahtevale profil modela, ki ustreza omejitvam zmogljivosti, stroškov, zakasnitve, stalnega prebivališča in zadrževanja.

Napoved: funkcije zasebnosti, specifične za ponudnika, se bodo še naprej razlikovale. Prehodi, ki normalizirajo samo formate zahtev in odgovorov, ne bodo dovolj; produkcijske ekipe bodo potrebovale tudi normalizacijo pravilnika.

Dejanski sklep

Usmerjanje, ki upošteva hrambo podatkov, ni ločena nadzorna plošča za skladnost. Spada na pot zahteve.

Začnite s tremi izsledki: taksonomija občutljivosti zahtev, matrika zmogljivosti ponudnika z različicami in majhen nabor pravil pravilnika kot kode za ZDR, rezidenčnost, neobdelano beleženje, nadomestne funkcije in funkcije za spreminjanje hrambe. Nato naj prehod vrne jasne razloge za zavrnitev in ohrani analitiko brez privzetega shranjevanja neobdelane vsebine.

Ta zasnova centralizira odločitve, ki bi bile sicer razpršene po možnostih SDK, spremenljivkah okolja, konzolah ponudnikov in konvencijah, specifičnih za ekipo. Prav tako daje ekipam za varnost in platformo praktično revizijsko sled: katera zahteva je bila dovoljena, katera različica pravilnika je bila uporabljena, kateri profil modela je bil izbran in zakaj.

Sorodno branje

• varen poziv beleženje in analitika uporabe na ravni prehoda
• izdelava matrike zmogljivosti ponudnika med migracijo API-ja, združljivega z OpenAI
• orodja upravljavskega agenta z obsegi, odobritvami in revizijskimi sledmi