Datu saglabāšanu apzinošs AI API maršrutēšana: ieviešiet ZDR, dzīvesvietas un reģistrēšanas politikas vārtejā

Drošības komandām ne tikai jāzina, kurš modelis ir lētākais, ātrākais vai jaudīgākais. Viņiem ir jāzina, vai konkrētu pieprasījumu likumīgi un funkcionāli var nosūtīt konkrētam pakalpojumu sniedzējam, galapunktam, reģionam, līdzeklim un reģistrēšanas režīmam.

Tas ir grūtāk, nekā izklausās. Modelis var būt pieņemams parastai iekšējai tērzēšanai, bet ne klienta PII. Pakalpojumu sniedzējs var piedāvāt nulles datu saglabāšanu vienam API ceļam, savukārt meklēšanas iezemējuma funkcija saglabā uzvednes un izvades uz noteiktu laiku. Reģions var atbalstīt krātuves rezidenci, bet ne gaidīto apstrādes režīmu. Izstrādātājiem piederošie žurnāli var būt konfigurējami, savukārt pakalpojumu sniedzēja ļaunprātīgas izmantošanas uzraudzības žurnālos tiek ievērota cita politika.

Praktiskā atbilde ir pārcelt lēmumus par saglabāšanu no atsevišķām lietojumprogrammām uz AI API vārteju. Vārtejai ir jāklasificē pieprasījums, jānovērtē tas, izmantojot pakalpojumu sniedzēja iespēju matricu, jābloķē nesaderīgi līdzekļi, jānovirza tikai uz apstiprinātiem modeļu profiliem un jāreģistrē politikas lēmums, pēc noklusējuma nesaglabājot neapstrādātas uzvednes.

Lasītāja problēma: pakalpojumu sniedzēja konfidencialitātes noteikumi nav izpildlaika vadīklas

Lielākā daļa komandu sāk ar izklājlapu vai drošības pārbaudi, kurā norādīts, kuri AI nodrošinātāji ir apstiprināti. Tas ir noderīgi, taču ar to nepietiek ražošanas maršrutēšanai.

Lietojumprogrammas veic izpildlaika izvēles:

• Kuram modeļa ID ir jāapstrādā šis pieprasījums?
• Vai pieprasījumā ir jāizmanto meklēšanas pamatojums, failu augšupielāde, koda izpilde, pakešu apstrāde, tūlītēja kešatmiņa vai saglabātas sarunas?
• Kuram reģionam vai galapunktam ir jāapstrādā pieprasījums?
• Vai sistēma var reģistrēt atkļūdošanas neapstrādāto uzvedni?
• Vai rezerves maršrutēšana var nosūtīt to pašu pieprasījumu citam pakalpojumu sniedzējam?

Katra no šīm izvēlēm var mainīt saglabāšanas profilu. Pieprasījums, kas bija saderīgs vienkāršajā tērzēšanas režīmā, var kļūt neatbilstošs, kad izstrādātājs ieslēdz zemējumu vai pastāvīgu sarunu glabāšanu. Atkāpšanās noteikums, kas izstrādāts uzticamībai, var nejauši novirzīt regulētos datus uz pakalpojumu sniedzēja ceļu, kas nav apstiprināts nulles datu saglabāšanai, datu atrašanās vietai vai ļaunprātīgas izmantošanas uzraudzības vadīklām.

Ieteikums: uztveriet saglabāšanas darbību kā pirmās klases maršrutēšanas ierobežojumu, nevis kā dokumentāciju, kas pievienota pakalpojumu sniedzēja kontam.

Fakti, kas jākodē pirms politikas izstrādes

Precīzi noteikumi atšķiras atkarībā no pakalpojumu sniedzēja, produkta, līguma, reģiona, galapunkta un līdzekļa. Nepaļaujieties uz atmiņu vai vienreizēju pārskatu. Izveidojiet avotam piederošu matricu un atjauniniet to, kad mainās noteikumi.

Vairāki pašreizējie publisko pakalpojumu sniedzēju dokumenti parāda, kāpēc tas ir nepieciešams:

• OpenAI: API datu atrašanās vieta ir dokumentēta kā projektā konfigurēta, un reģionālajiem pieprasījumiem ir nepieciešami reģionam specifiski domēna prefiksi. OpenAI arī atšķir krātuves atbalstu no apstrādes atbalsta pēc reģiona un atzīmē papildu prasības reģioniem ārpus ASV. OpenAI norāda, ka API datu atrašanās vietai ārpus ASV ir nepieciešams apstiprinājums ļaunprātīgas izmantošanas uzraudzības vadīklām un modificēts saglabāšanas grozījums.
• Antropisks: antropiski dokumentē nulles datu saglabāšanu ar API saistītiem komerciālas lietošanas gadījumiem, vienlaikus ņemot vērā, ka dažiem saistītiem produktiem vai atbilstības plūsmām ir atsevišķi saglabāšanas modeļi, tostarp ilgāka saglabāšana darbību plūsmai un attālās sesijas atšifrējumi.
• Google Gemini: Gemini API termini atšķir neapmaksātus un maksas pakalpojumus. Neapmaksātiem pakalpojumiem Google var izmantot iesniegto saturu un ģenerētās atbildes, lai uzlabotu produktus; maksas pakalpojumiem Google saka, ka uzvednes un atbildes netiek izmantotas produktu uzlabošanai. Gemini Developer API ZDR dokumentācijā teikts, ka maksas pakalpojuma ļaunprātīgas izmantošanas uzraudzības žurnālos parasti tiek saglabātas uzvednes un atbildes ierobežotu laika periodu, savukārt apstiprinātie ZDR projekti pirms reģistrēšanas notīra lietotāja saturu un identificējamus metadatus.
• Funkcijai specifiska krātuve: Gemini dokumentācijā teikts, ka Grounding with Google Search un Grounding with Google Maps glabā uzvednes, kontekstuālo informāciju un ģenerēto izvadi 30 dienas, taču šo krātuvi nevar atspējot, kad šīs funkcijas tiek izmantotas.
• Izstrādātājiem piederošie žurnāli: Gemini API reģistrēšanas dokumentācijā teikts, ka izstrādātājiem piederošos API žurnālus pēc noklusējuma var saglabāt līdz 55 dienām projektiem, kuros iespējoti norēķini, un izstrādātāji var izvēlēties īsākus periodus, piemēram, 7, 14 vai 28 dienas.
• Riska pārvaldība: NIST ģeneratīvais AI profils iesaka pārraudzīt mākslīgā intelekta radītā satura konfidencialitātes riskus un ģeneratīvās AI politikas saistīt ar esošajiem datiem, programmatūru, juridiskiem, atbilstības un riska pārvaldības procesiem.

Šie ir fakti, kas pirms izlaišanas jāpārbauda saskaņā ar pašreizējo piegādātāja dokumentāciju. Arhitektūras stunda ir stabila: saglabāšana nav viena nodrošinātāja līmeņa Būla vērtība.

Arhitektūra: vārtejas politikas dzinējs pieprasījuma ceļā

Saglabāšanas vārtejai ir pieci galvenie komponenti:

1. Pieprasīt jutīguma klasifikatoru: pirms maršrutēšanas atzīmē darba slodzi.
2. Pakalpojumu sniedzēja iespēju matrica: apraksta nodrošinātāju, modeli, galapunktu, reģionu, saglabāšanu, reģistrēšanu un funkciju darbību.
3. Politikas kā koda noteikumi: pārveidojiet drošības prasības izpildlaika atļaujas, noraidīšanas vai pārskatīšanas lēmumos.
4. Funkciju vārtu slānis: bloķē saglabāšanu mainošas funkcijas, ja vien tas nav skaidri atļauts.
5. Audita un analīzes slānis: reģistrē noderīgus metadatus, pēc noklusējuma nesaglabājot neapstrādātas uzvednes.

Vārtejai nav jāsaprot visas juridiskās nianses. Tai ir jāīsteno lēmumi, ko apstiprinājušas jūsu juridiskās, drošības, atbilstības un platformas komandas.

1. darbība. Pirms modeļa atlasīšanas klasificējiet pieprasījuma jutīgumu

Sāciet ar nelielu klasifikācijas taksonomiju. Tam jābūt pietiekami vienkāršam, lai izstrādātāji to varētu izmantot, bet pietiekami izteiksmīgam, lai virzītu politiku.

Jūtības iezīmju piemēri:

• publisks: publiska dokumentācija, mārketinga kopija, publiska vietnes saturs.
• iekšējais: nepubliska uzņēmuma informācija ar zemu jutīgumu.
• konfidenciāli: stratēģija, līgumi, klientu konteksts, nepublicēta produkta informācija.
• customer_pii: vārdi, e-pasta adreses, adreses, konta identifikatori, atbalsta atšifrējumi.
• regulēti: veselības aprūpes, finanšu, juridiskie, izglītības vai ar jurisdikciju saistīti aizsargāti dati.
• avota_kods: patentēts kods, konfigurācijas, arhitektūras faili.
• akreditācijas dati: noslēpumi, pilnvaras, paroles, privātās atslēgas. Lielākajā daļā sistēmu tas ir jābloķē, nevis jāmaršrutē.

Klasifikācija var būt no vairākiem avotiem:

• Lietojumprogrammas nodrošināta galvene, piemēram, X-Data-Class: customer_pii.
• Īrnieka politika, saskaņā ar kuru visa regulētā klienta datplūsma tiek uzskatīta par regulētu, ja vien tā nav pazemināta saskaņā ar apstiprinātu noteikumu.
• Galapunkta politika, kurā atbalsta biļešu kopsavilkuma noklusējuma vērtība ir customer_pii.
• Viegla satura skenēšana, lai atrastu akreditācijas datus, acīmredzamus PII vai politikas pārkāpumus.

Ieteikums: nav pilnībā atkarīgi no automātiskās noteikšanas. Pieprasīt, lai lietojumprogrammas deklarētu paredzēto datu klasi, pēc tam izmantojiet skenēšanu, lai konstatētu acīmredzamas neatbilstības vai piespiestu noteikt drošāku klasi.

2. darbība: izveidojiet nodrošinātāja iespēju matricu

Iespēju matrica ir patiesības avots, ko maršrutētājs novērtē. Tai ir jāveido, jāpārskata un jāpārbauda tā versija tāpat kā ražošanas konfigurācija.

Lauku piemēri:

{
  "profile_id": "provider_x.chat.eu.zdr",
  "provider": "provider_x",
  "modelis": "modelis-liels",
  "api_family": "chat_completions",
  "galapunkts": "https://eu.example-provider.com/v1",
  "reģions": "eu",
  "processing_residency": ["eu"],
  "storage_residency": ["eu"],
  "zdr_eligible": patiess,
  "zdr_contract_required": patiess,
  "training_use": "not_used_for_training_on_paid_api",
  "abuse_monitoring": "approved_modified_retention_required",
  "developer_log_retention_days": 0,
  "raw_prompt_logging_allowed": nepatiess,
  "supported_features": {
    "plain_chat": taisnība,
    "straumēšana": taisnība,
    "tool_calls": taisnība,
    "search_grounding": nepatiess,
    "maps_grounding": nepatiess,
    "file_upload": nepatiess,
    "partija": nepatiess,
    "stored_conversations": nepatiess
  },
  "last_reviewed": "2026-08-01",
  "source_refs": ["security-review-123", "vendor-doc-version-abc"]
}

Izmantojiet modeļu profilus, nevis neapstrādātus modeļu ID. Profils apvieno modeli, nodrošinātāju, galapunktu, reģionu, funkciju kopu un saglabāšanas pozu. Izstrādātāji pieprasa model_profile: compliant_summarisation, nevis tikai modelis: ātrākais-lielākais modelis.

Ieteikums: matricā iekļaujiet līguma priekšnoteikumus. Maršruts nav ZDR apstiprināts tikai tāpēc, ka pārdevējs kaut kur piedāvā ZDR. Tas tiek apstiprināts tikai tad, ja jūsu konts, projekts, reģions un galapunkts atbilst nepieciešamajiem nosacījumiem.

3. darbība: rakstiet politikas kā koda noteikumus

Politikas noteikumiem ir jābūt skaidriem, pārbaudāmiem un lasāmiem drošības un platformas komandām.

Noteikumu piemēri pseidokodā:

noliegt, ja data_class == "akreditācijas dati"
  iemesls "credentials_must_not_be_sent_to_model"
atļaut tikai tad, ja datu_klase ["regulated", "customer_pii"]
  un profile.zdr_eligible == true
  un profile.zdr_contract_required_satisfied == patiess
  cēlonis_neveiksmei "model_profile_not_zdr_eligible"
noliegt, ja rezidence_required == "eu"
  un "eu" nav profilā.processing_residency
  iemesls "region_processing_not_supported"
noliegt, ja datu_klase ["confidential", "customer_pii", "regulated"]un request.raw_prompt_logging == true
  iemesls "raw_prompt_logging_not_allowed"
noliegt, ja request.features.search_grounding == true
  un politika.requires_zdr == true
  un profile.feature_storage.search_grounding_days > 0
  iemesls "iezemējuma_nepieciešams_saglabāts_saturs"
noliegt, ja fallback_profile.retention_level 

{
  "kļūda": {
    "type": "policy_denied",
    "kods": "grounding_requires_30_day_storage",
    "message": "Meklēšanas zemējums nav atļauts darba slodzēm, kas atzīmētas ar prasību_zdr, jo šī nodrošinātāja funkcija saglabā uzvednes, konteksta un izvades saturu."
    "request_id": "req_123",
    "policy_version": "retention-policy-2026-08-01",
    "allowed_actions": [
      "disable_search_grounding",
      "choose_profile:zdr_plain_chat",
      "pieprasījums_izņēmums"
    ]
  }
}