AI API usmjeravanje s obzirom na zadržavanje podataka: nametnite pravila ZDR-a, prebivališta i zapisivanja na pristupniku

Sigurnosni timovi ne trebaju samo znati koji je model najjeftiniji, najbrži ili najsposobniji. Moraju znati može li se određeni zahtjev legalno i operativno poslati određenom pružatelju, krajnjoj točki, regiji, značajki i načinu zapisivanja.

To je teže nego što zvuči. Model može biti prihvatljiv za obični interni chat, ali ne i za PII korisnika. Davatelj može ponuditi nulto zadržavanje podataka za jedan put API-ja, dok značajka uzemljenja pretraživanja pohranjuje upite i izlaze na određeno razdoblje. Regija može podržavati boravišnu pohranu, ali ne i način obrade koji ste očekivali. Dnevnici u vlasništvu programera mogu se konfigurirati, dok dnevnici praćenja zlouporabe pružatelja slijede drugačija pravila.

Praktični odgovor je premjestiti odluke o zadržavanju iz pojedinačnih aplikacija na AI API pristupnik. Gateway bi trebao klasificirati zahtjev, procijeniti ga u odnosu na matricu mogućnosti pružatelja usluga, blokirati nekompatibilne značajke, usmjeriti samo na odobrene profile modela i zabilježiti odluku o politici bez pohranjivanja neobrađenih upita prema zadanim postavkama.

Problem s čitačem: uvjeti privatnosti pružatelja usluga nisu kontrole vremena izvođenja

Većina timova počinje s proračunskom tablicom ili sigurnosnim pregledom koji govori koji su pružatelji AI odobreni. To je korisno, ali nije dovoljno za usmjeravanje proizvodnje.

Aplikacije biraju vrijeme izvođenja:

• Koji bi ID modela trebao obraditi ovaj zahtjev?
• Treba li zahtjev koristiti temeljenje pretraživanja, učitavanje datoteke, izvršavanje koda, skupnu obradu, brzo predmemoriju ili pohranjene razgovore?
• Koja bi regija ili krajnja točka trebala obraditi zahtjev?
• Može li sustav zabilježiti neobrađeni upit za otklanjanje pogrešaka?
• Može li rezervno usmjeravanje poslati isti zahtjev drugom pružatelju?

Svaki od tih izbora može promijeniti profil zadržavanja. Zahtjev koji je bio usklađen u običnom načinu chata može postati neusklađen kada programer uključi uzemljenje ili trajno pohranjivanje razgovora. Zamjensko pravilo osmišljeno za pouzdanost može slučajno usmjeriti regulirane podatke na put pružatelja koji nije odobren za nulto zadržavanje podataka, rezidentnost podataka ili kontrole nadziranja zlouporabe.

Preporuka: ponašanje zadržavanja tretirajte kao prvorazredno ograničenje usmjeravanja, a ne kao dokumentaciju priloženu uz račun pružatelja usluga.

Činjenice koje treba kodirati prije dizajniranja pravila

Točni uvjeti ovise o pružatelju, proizvodu, ugovoru, regiji, krajnjoj točki i značajci. Nemojte se oslanjati na pamćenje ili jednokratni pregled. Izgradite matricu u vlasništvu izvora i ažurirajte je kada se uvjeti promijene.

Nekoliko trenutačnih javnih dokumenata pružatelja ilustrira zašto je ovo potrebno:

• OpenAI: prebivalište API podataka dokumentirano je kao projektno konfigurirano, s regionalnim zahtjevima koji zahtijevaju prefikse domene specifične za regiju. OpenAI također razlikuje podršku za pohranu od podrške za obradu po regijama i bilježi dodatne zahtjeve za regije izvan SAD-a. OpenAI navodi da boravište podataka API-ja izvan SAD-a zahtijeva odobrenje za kontrole nadgledanja zlouporabe i amandman o modificiranom zadržavanju.
• Anthropic: Anthropic dokumentira nulto zadržavanje podataka za slučajeve komercijalne upotrebe povezane s API-jem, uz napomenu da neki povezani proizvodi ili feedovi usklađenosti imaju zasebne modele zadržavanja, uključujući duže zadržavanje za feedove aktivnosti i transkripte udaljenih sesija.
• Google Gemini: Gemini API uvjeti razlikuju neplaćene i plaćene usluge. Za neplaćene usluge, Google može koristiti poslani sadržaj i generirane odgovore za poboljšanje proizvoda; za plaćene usluge, Google kaže da se upute i odgovori ne koriste za poboljšanje proizvoda. Gemini Developer API ZDR dokumentacija kaže da zapisnici praćenja zloupotrebe plaćenih usluga obično zadržavaju upite i odgovore tijekom ograničenog razdoblja, dok odobreni ZDR projektira jasan korisnički sadržaj i metapodatke koji se mogu identificirati prije zapisivanja.
• Pohrana specifična za značajku: Gemini dokumentacija navodi da Grounding s Google pretraživanjem i Grounding s Google kartama pohranjuju upute, kontekstualne informacije i generirane rezultate 30 dana, bez načina da se ta pohrana onemogući kada se te značajke koriste.
• Zapisi u vlasništvu razvojnog programera: Gemini API dokumentacija za bilježenje API-ja kaže da se API dnevnici u vlasništvu razvojnog programera prema zadanim postavkama mogu zadržati do 55 dana za projekte s omogućenom naplatom i da programeri mogu odabrati kraće prozore kao što su 7, 14 ili 28 dana.
• Upravljanje rizikom: Generativni AI profil NIST-a preporučuje praćenje sadržaja generiranog umjetnom inteligencijom radi rizika po privatnost i povezivanje pravila generativne umjetne inteligencije s postojećim podacima, softverom, pravnim procesima, procesima usklađenosti i upravljanja rizikom.

Ovo su činjenice koje treba provjeriti u odnosu na trenutnu dokumentaciju dobavljača prije pokretanja. Arhitektonska lekcija je stabilna: zadržavanje nije jedna Booleova vrijednost na razini pružatelja usluga.

Arhitektura: mehanizam pravila pristupnika u putu zahtjeva

Gateway svjestan zadržavanja ima pet osnovnih komponenti:

1. Klasifikator osjetljivosti zahtjeva: označava radno opterećenje prije usmjeravanja.
2. Matrika mogućnosti pružatelja: opisuje pružatelja, model, krajnju točku, regiju, zadržavanje, bilježenje i ponašanje značajki.
3. Pravila politike kao koda: pretvaraju sigurnosne zahtjeve u odluke o dopuštanju, odbijanju ili pregledu vremena izvođenja.
4. Sloj vrata značajki: blokira značajke koje mijenjaju zadržavanje osim ako nije izričito dopušteno.
5. Sloj revizije i analitike: bilježi korisne metapodatke bez pohranjivanja neobrađenih upita prema zadanim postavkama.

Gateway ne mora razumjeti svaku pravnu nijansu. Mora provoditi odluke koje su odobrili vaši pravni, sigurnosni, usklađeni i platformski timovi.

1. korak: klasificirajte osjetljivost zahtjeva prije odabira modela

Počnite s malom klasifikacijskom taksonomijom. Trebao bi biti dovoljno jednostavan da ga programeri mogu koristiti, ali dovoljno izražajan da vodi politiku.

Primjeri oznaka osjetljivosti:

• javno: javna dokumentacija, marketinški tekst, sadržaj javne web stranice.
• interno: informacije o tvrtki koje nisu javne s niskom osjetljivošću.
• povjerljivo: strategija, ugovori, korisnički kontekst, neobjavljeni detalji o proizvodu.
• customer_pii: imena, adrese e-pošte, adrese, identifikatori računa, transkripti podrške.
• regulirano: zdravstveni, financijski, pravni, obrazovni ili zaštićeni podaci specifični za jurisdikciju.
• source_code: vlasnički kod, konfiguracija, datoteke arhitekture.
• vjerodajnice: tajne, tokeni, lozinke, privatni ključevi. U većini sustava ovo bi trebalo biti blokirano, a ne usmjeravano.

Klasifikacija može doći iz više izvora:

• Zaglavlje koje dobiva aplikacija, kao što je X-Data-Class: customer_pii.
• Pravila zakupca, prema kojima se sav promet reguliranog korisnika tretira kao reguliran osim ako odobrenim pravilom nije smanjen.
• Pravila krajnje točke, gdje je sažetak ulaznica za podršku zadano customer_pii.
• Lagano skeniranje sadržaja u potrazi za vjerodajnicama, očitim podacima koji otkrivaju identitet ili kršenjima pravila.

Preporuka: nemojte u potpunosti ovisiti o automatskom otkrivanju. Zahtijejte od aplikacija da deklariraju željenu klasu podataka, a zatim upotrijebite skeniranje za otkrivanje očitih nepodudarnosti ili forsirajte sigurniju klasu.

Korak 2: izgradite matricu mogućnosti pružatelja

Matrika mogućnosti je izvor istine koju usmjerivač procjenjuje. Trebalo bi ga verzirati, pregledati i testirati kao proizvodnu konfiguraciju.

Primjeri polja:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "provider": "provider_x",
  "model": "model-veliki",
  "api_family": "chat_completions",
  "endpoint": "https://eu.example-provider.com/v1",
  "regija": "eu",
  "procesing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": točno,
  "zdr_contract_required": točno,
  "training_use": "ne_korišteno_za_obuku_na_plaćenom_api-ju",
  "abuse_monitoring": "odobreno_modificirano_zadržavanje_potrebno",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": netočno,
  "podržane_značajke": {
    "plain_chat": točno,
    "streaming": točno,
    "tool_calls": točno,
    "search_grounding": netočno,
    "maps_grounding": netočno,
    "file_upload": netočno,
    "serija": netočno,
    "pohranjeni_razgovori": netočno
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Koristite profile modela radije nego neobrađene ID-ove modela. Profil kombinira model, pružatelja usluga, krajnju točku, regiju, skup značajki i položaj zadržavanja. Programeri zahtijevaju model_profile: compliant_summarization, a ne samo model: fastest-large-model.

Preporuka: uključite ugovorne preduvjete u matricu. Ruta nije odobrena od ZDR-a samo zato što dobavljač negdje nudi ZDR. Odobren je samo kada vaš račun, projekt, regija i krajnja točka ispunjavaju potrebne uvjete.

3. korak: napišite pravila pravila kao koda

Pravila pravila trebaju biti eksplicitna, testirana i čitljiva timovima za sigurnost i platformu.

Primjer pravila u pseudokodu:

deny if data_class == "credentials"
  razlog "vjerodajnice_se_ne_smije_slati_modelu"
dopustiti samo ako data_class u ["regulirano", "customer_pii"]
  i profile.zdr_eligible == true
  i profile.zdr_contract_required_satisfied == true
  razlog_na_neuspjehu "model_profil_nije_zdr_prihvatljiv"
odbij ako je residency_required == "eu"
  a "eu" nije u profilu.processing_residency
  razlog "region_processing_not_supported"
deny if data_class u ["confidential", "customer_pii", "regulated"]i request.raw_prompt_logging == istina
  razlog "raw_prompt_logging_not_allowed"
deny if request.features.search_grounding == true
  i politika.requires_zdr == istina
  i profile.feature_storage.search_grounding_days > 0
  razlog "uzemljenje_zahtijeva_zadržani_sadržaj"
odbij ako fallback_profile.retention_level < primarni_profil.retention_level
  razlog "fallback_weakens_retention_policy"

Ova pravila trebala bi se pokrenuti prije odabira pružatelja i ponovno prije rezervnog načina. Zamjensko usmjeravanje čest je izvor slučajnog odstupanja pravila: primarna ruta može biti usklađena, dok je zamjenska ruta samo dostupna.

Korak 4: tretirajte alate i značajke kao sposobnosti koje mijenjaju zadržavanje

Nemojte modelirati zadržavanje samo kao svojstvo osnovnog modela. Značajke često mijenjaju ponašanje u pohrani, zapisivanju ili pregledu.

Dajte svakoj značajki vlastite oznake pravila:

• Uzemljenje pretraživanja: može pohranjivati upite, dohvaćeni kontekst i generirani izlaz ovisno o uvjetima pružatelja usluga.
• Karte ili uzemljenje lokacije: mogu uvesti zapisnike specifične za lokaciju ili pravila zadržavanja.
• Prijenos datoteke: može pohranjivati datoteke odvojeno od upita i odgovora.
• Izvršenje koda: može stvoriti privremene datoteke, zapisnike izvršenja ili artefakte sandboxa.
• Skupni poslovi: mogu imati drugačije ponašanje zadržavanja, čekanja i pohrane rezultata od sinkronih API poziva.
• Pohranjeni razgovori: namjerno zadržavaju sadržaj i nikada ne bi trebali biti skriveni iza općenite opcije chata.
• Nadzorne ploče za evaluaciju ili pregled: mogu stvoriti tijekove rada za ljudski pregled ili dugotrajnije skupove podataka.

Preporuka: uključite značajke koje mijenjaju zadržavanje na razini stanara i rute. Ako razvojni programer omogući grounding_search=true, pristupnik bi trebao ponovno procijeniti zahtjev prema pravilima pohrane značajki prije nego što ga pošalje uzvodno.

Korak 5: sačuvajte analitiku bez pohranjivanja neobrađenih upita

Usmjeravanje s obzirom na zadržavanje ne bi trebalo zaslijepiti tim platforme. Možete zadržati korisnu analizu upotrebe umjetne inteligencije dok minimalizirate pohranu sadržaja.

Sigurna zadana telemetrijska polja:

• ID stanara i ID projekta
• raspršeni ili interni API ključ ID
• ID profila modela i ID pružatelja usluge
• vremenska oznaka zahtjeva i regija
• ulazni, izlazni, predmemorirani i rezonantni token se broje kada su dostupni
• kašnjenje, statusni kod, broj ponovnih pokušaja i rezervna odluka
• procijenjeni i utvrđeni trošak
• oznaka klasifikacije podataka
• verzija pravila i razlog odluke o politici
• tražene oznake značajki i dopuštene oznake značajki

Izbjegavajte pohranjivanje neobrađenih upita i rezultata modela prema zadanim postavkama za povjerljivi promet. Ako otklanjanje pogrešaka zahtijeva sadržaj, upotrijebite kontrolirani tijek rada:

• odobrenje kupca ili stanara
• uzak vremenski okvir
• ograničenje uzorkovanja
• propusnica za uređivanje
• odvojena kontrola pristupa
• kratki rok trajanja
• revizijski zapis tko ga je omogućio i zašto

Ovo je kompromis. Blokiranje neobrađenih hitnih zapisa otežava otklanjanje pogrešaka, podršku, pregled kvalitete i istragu zlouporabe. Ali pohranjivanje svega prema zadanim postavkama stvara veću površinu privatnosti, kršenja i usklađenosti.

Korak 6: vratite opravdane razloge odbijanja

Generički 403 zabranjeno frustrira programere i potiče zaobilazna rješenja. Vrati stabilan strojno čitljiv razlog i čovjeku čitljivo objašnjenje.

Primjer odgovora:

{
  "greška": {
    "tip": "pravilo_odbijeno",
    "kod": "uzemljenje_zahtijeva_30_dnevno_skladištenje",
    "message": "Uzemljenje pretraživanja nije dopušteno za radna opterećenja označena kao requires_zdr jer ova značajka pružatelja usluge pohranjuje prompt, kontekst i izlazni sadržaj.",
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "dopuštene_radnje": [
      "onemogući_uzemljenje_pretrage",
      "odaberite_profil:zdr_plain_chat",
      "zahtjev_iznimka"
    ]
  }
}

Korisni kodovi odbijanja uključuju:

• 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

Korak 7: dodajte tijek rada iznimke, a ne skriveno zaobilaženje

Neke su iznimke legitimne: odgovor na incident, uklanjanje pogrešaka koje je odobrio korisnik, testiranje migracije ili privremeno ograničenje pružatelja usluga. Gateway bi trebao podržavati iznimke bez njihovog pretvaranja u trajnu politiku sjene.

Svaka iznimka treba uključivati:

• identitet odobravatelja
• tražiteljski tim ili stanar
• ulaznica ili veza za pregled rizika
• poslovno opravdanje
• dopušteni profili i značajke modela
• pokrivene klase podataka
• datum isteka
• dodatni zahtjevi za bilježenje

Preporuka: napravite iznimke uže od uobičajenih pravila. Izbjegavajte globalne prekidače kao što je disable_retention_policy=true. Dajte prednost nadjačavanjima s opsegom kao što je "dopusti bilježenje upita za otklanjanje pogrešaka za stanara A, krajnju točku B, tijekom 24 sata, uz redigiranje i sigurnosno odobrenje."

Operativni kontrolni popis

• Stvorite matricu mogućnosti pružatelja s verzijama.
• Odredite vlasnika za uvjete pružatelja usluga, preduvjete ugovora i preglede zadržavanja.
• Zahtijevajte od aplikacija da deklariraju klasu podataka, zahtjev prebivališta i tražene značajke.
• Zadani povjerljivi i regulirani promet bez neobrađenog brzog bilježenja.
• Predstavljaju alate, uzemljenje, prijenos datoteka, skupne i pohranjene razgovore kao zasebne oznake mogućnosti.
• Pokrenite provjere pravila prije primarnog usmjeravanja i prije rezervnog usmjeravanja.
• Verzija pravila dnevnika, profil modela, klasa podataka, oznake značajki i razlog odbijanja.
• Držite analitičke metapodatke odvojene od brzog i izlaznog sadržaja.
• Predstavnik testa dopušta i odbija slučajeve u CI-ju.
• Pregledajte promjene pravila kad god pružatelj promijeni uvjete, regije, krajnje točke ili značajke.

Kompromisi koje treba učiniti eksplicitnim

Strogo usmjeravanje smanjuje izbor. ZDR i ograničenja prebivališta mogu spriječiti korištenje najnovijeg modela, najjeftinije rute ili značajkama bogate krajnje točke.

Regionalno usmjeravanje može povećati kašnjenje ili troškove. Najbliža usklađena regija možda ne podržava željeni način obrade ili može zahtijevati drugačiji put pružatelja usluga.

Vrata značajki iznenađuju programere. Programer može misliti da samo omogućuje pretraživanje, ali sigurnost vidi novo ponašanje zadržavanja. Dokumentacija i poruke odbijanja smanjuju trvenje.

Brzo minimiziranje komplicira otklanjanje pogrešaka. Timovi trebaju redigirane uzorke, prozore za otklanjanje pogrešaka odobrene od strane stanara i jake metapodatke za istraživanje problema bez pohranjivanja svega.

Matrix zahtijeva održavanje. Promjena uvjeta pružatelja usluga. Lansiranje novih modela. Regije se šire. Značajke prelaze iz beta u produkciju. Ustajala matrica gora je od nepostojanja matrice jer stvara lažno samopouzdanje.

Što je preporuka, a što predviđanje?

Preporuke: nametnite zadržavanje na pristupniku, klasificirajte zahtjeve prije usmjeravanja, izgradite matricu mogućnosti pružatelja usluga, blokirajte značajke koje mijenjaju zadržavanje po pravilu, izbjegavajte neobrađeno brzo bilježenje prema zadanim postavkama i verziju svake odluke o pravilu.

Predviđanje: Timovi za platformu umjetne inteligencije sve će više tretirati privatnost kao dio odabira modela. Umjesto pitanja "koji bismo model trebali koristiti?" aplikacije će tražiti profil modela koji zadovoljava ograničenja mogućnosti, cijene, latencije, prebivališta i zadržavanja.

Predviđanje: značajke privatnosti specifične za pružatelja usluga nastavit će se razlikovati. Pristupnici koji normaliziraju samo formate zahtjeva i odgovora neće biti dovoljni; produkcijski će timovi također trebati normalizaciju pravila.

Zaključak koji se može poduzeti

Usmjeravanje s obzirom na zadržavanje podataka nije zasebna nadzorna ploča usklađenosti. Pripada putu zahtjeva.

Počnite s tri isporučena rezultata: taksonomijom osjetljivosti zahtjeva, matricom mogućnosti pružatelja s verzijama i malim skupom pravila pravila kao koda za ZDR, prebivalište, neobrađeno bilježenje, rezervne značajke i značajke promjene zadržavanja. Zatim neka pristupnik vrati jasne razloge odbijanja i sačuva analitiku bez pohranjivanja sirovog sadržaja prema zadanim postavkama.

Taj dizajn centralizira odluke koje bi inače bile raspršene po opcijama SDK-a, varijablama okruženja, konzolama pružatelja usluga i konvencijama specifičnim za tim. Timovima za sigurnost i platformu također daje praktičan revizijski trag: koji je zahtjev dopušten, koja je verzija pravila primijenjena, koji je profil modela odabran i zašto.

Povezano čitanje

• siguran upit bilježenje i analiza korištenja na razini pristupnika
• izgradnja matrice mogućnosti pružatelja tijekom migracije API-ja kompatibilnog s OpenAI-om
• alati upravljačkog agenta s opsegom, odobrenjima i tragovima revizije