Andmete säilitamise teadlik AI API marsruutimine: jõustage lüüsis ZDR-i, elukoha- ja logimispoliitikad
Praktiline lüüsiarhitektuur AI API liikluse suunamiseks andmete säilitamise reeglite järgi: klassifitseerige päringu tundlikkus, kaardi pakkuja säilitamiskäitumine, blokeerige ühildumatud funktsioonid, säilitage turvaline analüüs ja auditeerige iga otsust.
Turvameeskonnad ei pea ainult teadma, milline mudel on odavaim, kiireim või kõige võimekam. Nad peavad teadma, kas konkreetse päringu saab seaduslikult ja operatiivselt saata konkreetsele pakkujale, lõpp-punktile, piirkonnale, funktsioonile ja logimisrežiimile.
See on raskem, kui see kõlab. Mudel võib olla vastuvõetav tavalise sisevestluse jaoks, kuid mitte kliendi isikuandmete jaoks. Pakkuja võib pakkuda ühe API tee jaoks nullandmete säilitamist, samal ajal kui otsingu-maandusfunktsioon salvestab viipasid ja väljundeid kindla perioodi jooksul. Piirkond võib toetada salvestusresidentsust, kuid mitte eeldatud töötlemisrežiimi. Arendajale kuuluvad logid võivad olla konfigureeritavad, samas kui pakkuja väärkasutuse jälgimise logid järgivad teistsugust reeglit.
Praktiline vastus on teisaldada säilitamisotsused üksikutest rakendustest välja AI API lüüsi. Lüüs peaks päringu klassifitseerima, hindama seda teenusepakkuja võimete maatriksi alusel, blokeerima ühildumatud funktsioonid, suunama ainult heakskiidetud mudeliprofiilidele ja salvestama poliitikaotsuse ilma vaikimisi töötlemata viipasid salvestamata.
Lugeja probleem: pakkuja privaatsustingimused ei ole käitusaja juhtelemendid
Enamik meeskondi alustab arvutustabeli või turvaülevaatega, mis ütleb, millised tehisintellekti pakkujad on heaks kiidetud. See on kasulik, kuid sellest ei piisa tootmise marsruutimiseks.
Rakendused teevad käitusaja valikuid:
- Millise mudeli ID peaks seda taotlust käsitlema?
- Kas taotlus peaks kasutama otsingu maandust, faili üleslaadimist, koodi täitmist, paketttöötlust, viipade vahemällu salvestamist või salvestatud vestlusi?
- Milline piirkond või lõpp-punkt peaks taotlust töötlema?
- Kas süsteem saab logida silumise töötlemata viipa?
- Kas varumarsruutimine võib saata sama päringu teisele pakkujale?
Iga neist valikutest saab muuta säilitamisprofiili. Tavalises vestlusrežiimis ühilduv taotlus võib muutuda nõuetele mittevastavaks, kui arendaja lülitab sisse maanduse või püsiva vestluste salvestusruumi. Usaldusväärsuse tagamiseks loodud varureegel võib kogemata suunata reguleeritud andmed teenusepakkuja teele, mis ei ole heaks kiidetud andmete nullsäilitamise, andmete elukoha või väärkasutuse jälgimise jaoks.
Soovitus: käsitlege säilitamiskäitumist esmaklassilise marsruutimispiiranguna, mitte teenusepakkuja kontole lisatud dokumentatsioonina.
Faktid, mida enne poliitika kujundamist kodeerida
Täpsed tingimused sõltuvad pakkujast, tootest, lepingust, piirkonnast, lõpp-punktist ja funktsioonist. Ärge lootke mälule ega ühekordsele ülevaatele. Looge allikale kuuluv maatriks ja värskendage seda tingimuste muutumisel.
Mitmed kehtivad avaliku teenusepakkuja dokumendid näitavad, miks see vajalik on:
- OpenAI: API andmete elukoht on dokumenteeritud projekti konfiguratsiooniga, piirkondlikud päringud nõuavad piirkonnapõhiseid domeeni eesliiteid. OpenAI eristab ka salvestustoetust töötlemise toest piirkondade kaupa ja märgib täiendavaid nõudeid USA-välistele piirkondadele. OpenAI väidab, et väljaspool USA-d asuva API andmete elukohaks on vaja väärkasutuse jälgimise juhtelementide heakskiitu ja muudetud säilitamise muudatust.
- Antroopiline: antroopsed dokumendid ei säilita API-ga seotud ärilise kasutuse juhtude puhul andmeid, märkides samas, et mõnel seotud tootel või vastavuse voogudel on eraldi säilitusmudelid, sealhulgas tegevuste voo ja kaugseansi transkriptsioonide pikem säilitamine.
- Google Gemini: Gemini API terminid eristavad tasuta ja tasulisi teenuseid. Tasuta teenuste puhul võib Google toodete täiustamiseks kasutada esitatud sisu ja loodud vastuseid; Google ütleb, et tasuliste teenuste puhul ei kasutata viipasid ja vastuseid toodete täiustamiseks. Gemini Developer API ZDR-dokumentatsioon ütleb, et tasuliste teenuste kuritarvitamise jälgimise logid säilitavad tavaliselt viipasid ja vastuseid piiratud aja jooksul, samas kui heakskiidetud ZDR-i projektid puhastavad kasutaja sisu ja tuvastatavad metaandmed enne logimist.
- Funktsioonispetsiifiline salvestusruum: Gemini dokumentatsioonis öeldakse, et Google'i otsinguga maandus ja Google Mapsiga maandus salvestavad viipasid, kontekstipõhist teavet ja loodud väljundit 30 päevaks, ilma et seda salvestusruumi saaks nende funktsioonide kasutamisel keelata.
- Arendaja omanduses olevad logid: Gemini API logidokumentatsioon ütleb, et arendaja omanduses olevaid API logisid saab arveldustoega projektide puhul vaikimisi säilitada kuni 55 päeva ja arendajad saavad valida lühemad aknad, näiteks 7, 14 või 28 päeva.
- Riskijuhtimine: NISTi generatiivne tehisintellekti profiil soovitab jälgida tehisintellekti loodud sisu privaatsusriskide suhtes ja ühendada generatiivsed AI eeskirjad olemasolevate andmete, tarkvara, juriidiliste, vastavus- ja riskijuhtimisprotsessidega.
Need on faktid, mida tuleb enne levitamist kontrollida müüja kehtivate dokumentidega. Arhitektuuritund on stabiilne: säilitamine ei ole üks pakkuja taseme Boole'i väärtus.
Arhitektuur: lüüsi poliitikamootor päringu teel
Säilitustundlikul lüüsil on viis põhikomponenti:
- Taotle tundlikkuse klassifikaatorit: märgistab töökoormuse enne marsruutimist.
- Pakkuja võimaluste maatriks: kirjeldab pakkujat, mudelit, lõpp-punkti, piirkonda, säilitamist, logimist ja funktsioonide käitumist.
- Poliitika koodina reeglid: teisendage turbenõuded käitusaja lubamise, keelamise või ülevaatamise otsusteks.
- Funktsioonivärava kiht: blokeerib säilitamist muutvad funktsioonid, kui see pole selgesõnaliselt lubatud.
- Auditi- ja analüüsikiht: salvestab kasulikud metaandmed ilma vaikimisi töötlemata viipasid salvestamata.
Lüüs ei pea mõistma kõiki juriidilisi nüansse. See peab jõustama otsused, mille teie õigus-, turva-, vastavus- ja platvormimeeskonnad on heaks kiitnud.
1. samm: klassifitseerige päringu tundlikkus enne mudeli valimist
Alustage väikese klassifikatsiooni taksonoomiaga. See peaks olema piisavalt lihtne, et arendajad saaksid seda kasutada, kuid piisavalt väljendusrikas, et poliitikat juhtida.
Tundlikkuse siltide näidised:
avalik: avalik dokumentatsioon, turunduskoopia, avalik veebisaidi sisu.sisemine: madala tundlikkusega mitteavalik ettevõtteteave.konfidentsiaalne: strateegia, lepingud, kliendi kontekst, avaldamata toote üksikasjad.customer_pii: nimed, e-posti aadressid, konto identifikaatorid, toe ärakirjad.reguleeritud: tervishoiu-, finants-, õigus-, haridus- või jurisdiktsioonipõhised kaitstud andmed.lähtekood: varaline kood, konfiguratsiooni-, arhitektuurifailid.mandaadid: saladused, märgid, paroolid, privaatvõtmed. Enamikus süsteemides tuleks see blokeerida, mitte suunata.
Klassifikatsioon võib pärineda mitmest allikast:
- Rakendusega varustatud päis, nt
X-Data-Class: customer_pii. - Üürniku eeskirjad, mille kohaselt kogu reguleeritud kliendi liiklust käsitletakse reguleerituna, välja arvatud juhul, kui heakskiidetud reegel muudab madalamaks.
- Lõpp-punkti eeskirjad, kus tugi-pileti kokkuvõtte vaikeväärtus on
customer_pii. - Kerge sisu kontrollimine mandaatide, ilmsete isikuandmete või eeskirjade rikkumiste tuvastamiseks.
Soovitus: ärge sõltuge täielikult automaatsest tuvastamisest. Nõua, et rakendused deklareeriksid kavandatud andmeklassi, seejärel kasutage skannimist ilmsete mittevastavuste tuvastamiseks või turvalisema klassi sundimiseks.
2. samm: looge pakkuja võimete maatriks
Võimemaatriks on tõe allikas, mida ruuter hindab. Seda tuleks versioonida, üle vaadata ja testida sarnaselt tootmiskonfiguratsiooniga.
Näidisväljad:
Kasutage mudeliprofiile, mitte töötlemata mudeli ID-sid. Profiil ühendab mudeli, pakkuja, lõpp-punkti, piirkonna, funktsioonide komplekti ja hoidmisasendi. Arendajad nõuavad model_profile: compliant_summarisation, mitte ainult mudel: kiireim-suurem-mudel.
Soovitus: lisage maatriksisse lepingulised eeltingimused. Marsruut ei ole ZDR-i poolt heaks kiidetud ainult seetõttu, et müüja pakub kuskil ZDR-i. See kiidetakse heaks ainult siis, kui teie konto, projekt, piirkond ja lõpp-punkt vastavad nõutavatele tingimustele.
3. samm: kirjutage reeglid koodina
Eeskirjareeglid peaksid olema selgesõnalised, testitavad ning turva- ja platvormimeeskondadele loetavad.
Näidisreeglid pseudokoodis:
deny if data_class == "mandaadid"
põhjus "mandaadid_ei_mudelile_saadetud"
luba ainult siis, kui andmeklass ["regulated", "customer_pii"]
ja profile.zdr_eligible == tõene
ja profile.zdr_contract_required_satisfied == tõsi
ebaõnnestumise põhjus "model_profile_not_zdr_eligible"
keelata, kui resident_required == "eu"
ja "eu" ei ole profiilis.töötluse_residentsus
põhjus "region_processing_not_supported"
deny if data_class in ["confidential", "customer_pii", "regulated"]ja request.raw_prompt_logging == tõene
põhjus "raw_prompt_logging_not_allowed"
deny if request.features.search_grounding == true
ja poliitika.requires_zdr == true
ja profile.feature_storage.search_grounding_days > 0
põhjus "maandus_nõuab_säilitatud_sisu"
deny if fallback_profile.retention_level Need reeglid peaksid kehtima enne teenusepakkuja valimist ja uuesti enne varuvariandi. Varumarsruut on tavaline poliitika juhusliku kõrvalekalde allikas: esmane marsruut võib olla nõuetele vastav, samas kui varumarsruut on lihtsalt saadaval.
4. samm: käsitlege tööriistu ja funktsioone kui säilitamist muutvaid võimalusi
Ärge modelleerige säilitamist ainult põhimudeli omadusena. Funktsioonid muudavad sageli salvestamise, logimise või ülevaatamise käitumist.
Andke igale funktsioonile oma eeskirjade lipud:
- Otsingu maandus: võib sõltuvalt teenusepakkuja tingimustest salvestada viipasid, otsitud konteksti ja loodud väljundit.
- Kaardid või asukoha maandus: võib lisada asukohapõhiseid logisid või säilitamise reegleid.
- Failide üleslaadimine: võib faile salvestada viipadest ja vastustest eraldi.
- Koodi täitmine: võib luua ajutisi faile, täitmisloge või liivakasti artefakte.
- Pakitööd: võib sünkroonsetest API-kõnedest erineda säilitus-, järjekordade- ja tulemuste salvestamise käitumisega.
- Salvestatud vestlused: sisu säilitatakse tahtlikult ja neid ei tohiks kunagi peita üldise vestlusvaliku taha.
- Hindamise või ülevaatamise juhtpaneelid: võivad luua inimeste poolt ülevaatavaid töövooge või pikema elueaga andmekogumeid.
Soovitus: lubage säilitamist muutvad funktsioonid rentniku ja marsruudi tasemel. Kui arendaja lubab grounding_search=true, peaks lüüs päringu enne ülesvoolu saatmist funktsioonide salvestusreeglite suhtes uuesti hindama.
5. samm: säilitage analüütika ilma töötlemata viipade salvestamiseta
Säilitamist arvestav marsruutimine ei tohiks platvormi meeskonda pimestada. Saate säilitada kasuliku AI kasutusanalüüsi, minimeerides samal ajal sisu salvestusruumi.
Ohutud vaiketelemeetriaväljad:
- üürniku ID ja projekti ID
- räsitud või sisemise API võtme ID
- mudeli profiili ID ja pakkuja ID
- taotlege ajatemplit ja piirkonda
- sisend-, väljund-, vahemällu salvestatud ja arutlusmärk loeb, kui see on saadaval
- latentsusaeg, olekukood, korduskatsete arv ja varuotsus
- hinnanguline ja arveldatud kulu
- andmete klassifikatsiooni silt
- poliitika versioon ja poliitikaotsuse põhjus
- funktsioonide lipud on taotletud ja funktsioonide lipud lubatud
Vältige vaikimisi töötlemata viipade ja mudeliväljundite salvestamist konfidentsiaalse liikluse jaoks. Kui silumine nõuab sisu, kasutage kontrollitud töövoogu:
- kliendi või rentniku kinnitus
- kitsas ajaaken
- proovivõtmise limiit
- redigeerimisluba
- eraldi juurdepääsu kontroll
- lühike aegumine
- kontrolli logi selle kohta, kes selle lubas ja miks
See on kompromiss. Toores viipade logide blokeerimine muudab silumise, toe, kvaliteediülevaatuse ja väärkasutuse uurimise raskemaks. Kuid kõige vaikimisi salvestamine loob suurema privaatsus-, rikkumis- ja vastavuspinna.
6. toiming: esitage keeldumise põhjused, mida saab esitada
Üldine 403 keelatud valmistab arendajatele meelehärmi ja julgustab lahendusi. Tagasta stabiilne masinloetav põhjus ja inimloetav selgitus.
Vastuse näide:
Kasulikud keeldumiskoodid on järgmised:
model_profile_not_zdr_eligibleregion_processing_not_supportedsalvestusruumi_residentsust_ei_toetaraw_prompt_logging_not_allowedfeature_requires_content_storagefallback_weakens_retention_policycontract_prerequisite_missingmandaadid_tuvastatud
7. samm: lisage erandi töövoog, mitte peidetud möödaviigu
Mõned erandid on õigustatud: intsidentidele reageerimine, kliendi poolt heaks kiidetud silumine, migratsioonitestimine või teenusepakkuja ajutine piirang. Lüüs peaks toetama erandeid, muutmata neid püsivaks varipoliitikaks.
Iga erand peaks sisaldama järgmist:
- kinnitaja identiteet
- taotlev meeskond või üürnik
- pileti või riskiülevaatuse link
- äri põhjendus
- lubatud mudeliprofiilid ja funktsioonid
- kaetud andmeklassid
- aegumiskuupäev
- täiendavad logimisnõuded
Soovitus: tehke erandid tavaeeskirjadest kitsamad. Vältige globaalseid lüliteid, nagu disable_retention_policy=true. Eelistage ulatusega alistamisi, näiteks „luba silumisviiba logimine rentnikule A lõpp-punktile B 24 tunni jooksul koos redigeerimise ja turvalisuse kinnitusega”.
Käitamise kontroll-loend
- Looge versiooniga teenusepakkuja võimaluste maatriks.
- Määrake pakkuja tingimuste, lepingu eeltingimuste ja säilitamise ülevaatuste jaoks omanik.
- Nõua, et rakendused deklareeriksid andmeklassi, elukohanõude ja soovitud funktsioonid.
- Vaikimisi konfidentsiaalne ja reguleeritud liiklus ilma töötlemata viipade logimiseta.
- Esitage tööriistad, maandus, failide üleslaadimine, pakkimine ja salvestatud vestlused eraldi funktsioonilippudena.
- Käitage eeskirjade kontrollimine enne esmast marsruutimist ja enne varumarsruutimist.
- Logipoliitika versioon, mudeli profiil, andmeklass, funktsioonide lipud ja keelamise põhjus.
- Hoidke analüüsi metaandmed viipade ja väljundi sisust eraldi.
- Testi esindaja lubab ja keelab juhtumeid CI-s.
- Vaadake eeskirjade muutus üle alati, kui pakkuja muudab tingimusi, piirkondi, lõpp-punkte või funktsioone.
Selgesõnaliseks muutmise kompromissid
Range marsruutimine vähendab valikut. ZDR-i ja elukohapiirangud võivad takistada uusima mudeli, odavaima marsruudi või funktsioonirikka lõpp-punkti kasutamist.
Piirkondlik marsruutimine võib suurendada latentsust või kulusid. Lähim ühilduv piirkond ei pruugi soovitud töötlemisrežiimi toetada või võib vajada teist teenusepakkuja teed.
Funktsiooniväravad üllatavad arendajaid. Arendaja võib arvata, et nad lubavad ainult otsingut, kuid turvalisus näeb uut säilitamiskäitumist. Dokumenteerimine ja keeldumise teated vähendavad hõõrdumist.
Kiire minimeerimine raskendab silumist. Meeskonnad vajavad redigeeritud näidiseid, rentnike heakskiidetud silumisaknaid ja tugevaid metaandmeid, et uurida probleeme ilma kõike salvestamata.
Maatriks vajab hooldust. Pakkuja tingimused muutuvad. Uute mudelite käivitamine. Piirkonnad laienevad. Funktsioonid liiguvad beetaversioonist tootmisse. Vananenud maatriks on hullem kui maatriksi puudumine, sest see loob vale kindlustunde.
Mis on soovitus ja mis on ennustus?
Soovitused: jõustage lüüsis säilitamine, klassifitseerige päringud enne marsruutimist, looge pakkuja võimete maatriks, blokeerige säilitamist muutvad funktsioonid poliitika alusel, vältige vaikimisi töötlemata viipade logimist ja muutke iga poliitikaotsus versiooniks.
Prognoos: tehisintellekti platvormi meeskonnad käsitlevad privaatsust üha enam mudelivaliku osana. Selle asemel, et küsida "millist mudelit peaksime kasutama?" rakendused küsivad mudeliprofiili, mis vastab võimekuse, kulu, latentsusaja, elukoha ja säilituspiirangutele.
Prognoos: teenusepakkujapõhised privaatsusfunktsioonid erinevad jätkuvalt. Lüüsidest, mis normaliseerivad ainult päringu ja vastuse vorminguid, ei piisa; tootmismeeskonnad vajavad samuti poliitika normaliseerimist.
Tehtitav järeldus
Andmete säilitamist arvestav marsruutimine ei ole eraldiseisev vastavuse juhtpaneel. See kuulub päringu teele.
Alustage kolme väljundiga: päringu tundlikkuse taksonoomia, versiooniga teenusepakkuja võimete maatriks ja väike komplekt poliitika kui koodi reegleid ZDR-i, elukoha, töötlemata logimise, varu- ja säilitamist muutvate funktsioonide jaoks. Seejärel muutke lüüsil selged keeldumise põhjused ja säilitage analüütika ilma vaikimisi töötlemata sisu salvestamata.
See kujundus koondab otsused, mis muidu oleksid hajutatud SDK valikute, keskkonnamuutujate, pakkujakonsoolide ja meeskonnapõhiste tavade vahel. Samuti annab see turva- ja platvormimeeskondadele praktilise kontrolljälje: milline taotlus oli lubatud, millist poliitika versiooni rakendati, milline mudeliprofiil valiti ja miks.