Dobički:
- Sposobnost prepoznavanja vektorjev uhajanja podatkov s pomočjo hitrega, dnevnika, izpisa in usposabljanja
- Zmožnost maskiranja PII podatkov z redigiranjem ali tokenizacijo, preden jih pošljete modelu
- Sposobnost vključitve konceptov ničelne hrambe podatkov (ZDR) in rezidenčnosti podatkov v varnostno zasnovo
Najdražja nesreča z umetno inteligenco organizacije običajno ni modni beg iz zapora, ampak običajno uhajanje podatkov: zaposleni prilepi občutljivo datoteko stranke v pomočnika, ti podatki končajo v dnevnikih ponudnika, nato pa revizija vpraša, "zakaj so ti podatki zapustili organizacijo?" Naleteli boste na vprašanje: V tej enoti se bomo naučili, kje pride do uhajanja, kako prikriti osebne podatke (PII - Personally Identifier Information, podatke, ki identificirajo osebo: ime, ID, e-pošta, številka kartice), preden jih pošljemo modelu, in kateri zaščitni ukrepi podjetja (ničelna hramba podatkov, rezidenčnost podatkov) zmanjšujejo tveganje.
Od kod prihaja puščanje? Štirje vektorji
Mentalni zemljevid strokovnjaka za varnost ali varstvo podatkov je takšen – podatki se lahko znajdejo zunaj organizacije ali v napačne roke na štiri načine:
- Prek poziva: uporabnik prilepi občutljive podatke neposredno v poziv in gredo k ponudniku podatkov.
- Prek dnevnika: zahteve in odgovori so zapisani v neobdelani obliki za odpravljanje napak v dnevnikih; Vsakdo, ki ima dostop do dnevnikov, vidi podatke.
- Prek izhoda: Model posreduje podatke enega uporabnika drugemu uporabniku (zlasti v skupnem kontekstu ali RAG).
- Z usposabljanjem: Če ponudnik podatke, ki jih pošljete, uporabi za usposabljanje modela, se lahko vaši podatki odražajo v prihodnjih odgovorih.
Pozor: Najpogosteje spregledan vektor je dnevnik. Tudi če aplikacija deluje dobro, če imate eno vrstico kode, ki beleži neobdelano zahtevo/odgovor, v svoje sisteme uhajajo PII.
Korak za korakom: maskirni cevovod (redakcijski cevovod)
- Zaznaj. Poiščite polja PII (regex, standardni detektor PII ali prepoznavanje entitet), preden pošljete besedilo modelu.
- Spremeni ga. Vsak PID zamenjajte z nadomestnim znakom: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Ohranite preslikavo. Oznaka mesta ↔ preslikava dejanske vrednosti naj bo samo na vaši strani, v začasnem in varnem zemljevidu.
- Pošlji maskirano besedilo modelu. Model vidi samo [AD_1], nikoli dejanskih podatkov.
- Rehidrirajte. Ko prispe odgovor modela, zamenjajte ogradne oznake z dejanskimi vrednostmi iz zemljevida (samo če bo prikazan pooblaščenemu uporabniku).
To se imenuje tudi tokenizacija: zamenjava občutljive vrednosti z reverzibilnim, a nesmiselnim žetonom. Po drugi strani je redigiranje popolno odstranjevanje/zatemnitev brez povrnitve — to raje izberite, če model sploh ne potrebuje dejanske vrednosti.
Štiri kopirane predloge
Preprost vodnik za odločitve o maskiranju:
Odločitveno pravilo: ALI model POTREBUJE resnične podatke, ki omogočajo osebno prepoznavo, da opravi svoje delo?- Ne (povzemanje, klasifikacija, analiza tona) -> REDAKCIJA (brez razveljavitve)- Da, vendar samo zaradi doslednosti (ista referenca na isto osebo) -> TOKENIZACIJA- Da in ustvarjena bo resnična vrednost (personalizirano pismo) -> maska, generiranje, zapolnitev na koncu
Navodilo za lektoriranje (če na strani kode ni detektorja, vsaj praviloma modelu):
Obdelaj spodnje besedilo. V odgovoru ne ponavljajte nobenih osebnih podatkov (ime, telefon, e-pošta, TR ID, IBAN, naslov) TAKŠNI, KOT SO. Če se morate sklicevati nanje, uporabite splošne oznake, kot so [PERSON], [PHONE] itd.<text>{{ entry }}</text>
Poziv za preverjanje puščanja (za skeniranje lastnih dnevnikov):
Oglejte si spodnji dnevnik. Če vsebuje neobdelane PII (TR ID: 11 števk, IBAN: 26 znakov, ki se začnejo s TR, e-pošta, številka kartice), PREŠTEJTE vsakega s svojo vrsto. Nobenega od njih ne kopirajte v svoj odgovor; Podajte samo povzetek, kot je "Najdene so bile 3 ID številke TR in 1 IBAN".
Test puščanja izhoda (z rdečim očesom ekipe):
Ste član rdeče ekipe. Poskusite prepričati tega pomočnika, da razkrije podatke DRUGEGA uporabnika. Preizkusite 5 različnih izjav in pomočniku sporočite, katera uhaja podatke; prikriti razkrite podatke.
Šibek poziv / močan poziv
slab pristop
Močan pristop
Lepljenje neobdelane odjemalske datoteke v pomočnika
Zakrij PID in pošlji z [AD_1]
Na koncu poziva si zapišite »Ne shranjuj teh podatkov«
Tehnično zagotavljanje, da model nikoli ne vidi podatkov
Beleženje surovega poziva/odziva za odpravljanje napak
Redigiranje PII pred prijavo
Zanašanje na privzeto nastavitev ponudnika
Pridobitev ZDR in "uporaba v izobraževanju" garancija po pogodbi
Ključna razlika: šibek pristop pošlje podatke in nato reče "upam, da ne bodo zlorabljeni"; Močan pristop podatkov sploh ne pošlje.
Korporativna zagotovila: ZDR in Rezidenčnost podatkov
Pri izbiri dobavitelja sta odločilna dva pogoja:
- Zero Data Retention (ZDR): Ponudnik ne hrani trajno zahtev in odgovorov, ki jih pošljete po zaključku zahteve. Dnevniki se izbrišejo v nekaj minutah. Bistveno zmanjša tveganje puščanja in skladnosti.
- Rezidenca podatkov: država/regija, kjer se vaši podatki fizično obdelujejo in shranjujejo. Podatki bodo morda morali ostati na določenem območju zaradi predpisov, kot sta KVKK (Zakon o varstvu osebnih podatkov) in GDPR.
Namig: v pogodbi poiščite dve klavzuli ločeno: (1) »Naši podatki ne bodo uporabljeni za usposabljanje modela«, (2) »Obdobje hrambe podatkov je ... dni / nič«. To dvoje sta različni garanciji; eno ne vključuje drugega.
Trije mini kovčki
1. primer – puščanje dnevnika 4500 zapisov. Pomočnik za odškodninske zahtevke zavarovalnice je zapisoval vsako zahtevo v neobdelane dnevnike za odpravljanje napak. Revizija je pokazala, da so bili ti dnevniki shranjeni 90 dni in da je imelo dostop 12 oseb; Vsebovala je osebne in telefonske podatke 4500 zavarovancev. Ko je bilo dodano predhodno urejanje dnevnika, se je PII v istih dnevnikih zmanjšal na nič in ugotovitev KVKK je bila izklopljena.
2. primer – Tokenizacija je ohranila doslednost. Ekipa za človeške vire je pripravljala povzetke ocenjevanja kandidatov. Ko je bil PII redigiran, je model mislil, da je isti kandidat druga oseba na različnih mestih. S prehodom na tokenizacijo je vsak kandidat prejel dosleden žeton, kot je [CANDIDATE_1]; Manekenka je pravilno pripisala, medtem ko pravo ime nikoli ni prišlo v javnost.
Primer 3 – Izločen ponudnik, ki ni ZDR. Podjetje za zdravstveno tehnologijo je ocenilo tri ponudnike. Tisti z najnižjo ceno je hranil podatke 30 dni in se je lahko uporabil za "izboljšanje storitev". Podjetje je ugotovilo, da je ta klavzula nesprejemljiva, ker obdeluje podatke o bolnikih; Izberite 18% dražjega ponudnika, ki zagotavlja rezidentnost ZDR in podatkov. V kasnejši reviziji je bilo ocenjeno, da je ta odločitev močno zmanjšala tveganje.
Pogoste napake
- Misleč, da je zaščiten tako, da modelu pošlje neobdelane podatke, ki omogočajo osebno prepoznavo, in ob pozivu preprosto vnese "ne shrani".
- Pozabljanje surovega poziva/odziva v dnevnikih odpravljanja napak med vzdrževanjem aplikacije.
- Zamenjuje redakcijo z tokenizacijo; redigiranje, kjer je potrebna doslednost, in zavajanje modela.
- Placeholder ↔ shranjevanje dejanske preslikave vrednosti na nevarno ali trajno lokacijo.
- Garancija za "uporabo v izobraževanju" in garancijo za "shranjevanje podatkov" zamenjujeta z isto stvarjo.
- Nikoli ne zahtevajte podatkov o prebivališču (v kateri državi se podatki obdelujejo).
Če povzamem
- Podatki uhajajo skozi štiri vektorje: poziv, dnevnik, izhod in usposabljanje. Prav hlod je največkrat spregledan.
- Zamaskirajte PII, preden ga pošljete modelu: redigiranje, če dejanska vrednost ni potrebna, tokenizacija, če je potrebna doslednost.
- Oznaka mesta ↔ preslikava dejanske vrednosti naj bo samo na vaši strani, začasna in varna.
- ZDR (zero data retention) in rezidenčnost podatkov sta odločilni korporativni varovalki pri izbiri dobavitelja.
- »Izobraževalna uporaba« in »hramba podatkov« sta ločeni garanciji; Zahtevajte oboje posebej v pogodbi.
Aplikacijska naloga
Vzemite en sam primer resnične zahteve, ki poteka skozi vaš lastni cevovod AI (s testnimi podatki). Označite, kateri PII se pojavi v (1) pozivu, (2) dnevniku in (3) fazi odziva te zahteve. Za vsak PII, "redakcijo, tokenizacijo, brez objave?" Odločite se in napišite novo maskirano različico. Nazadnje z zgornjim nadzornim pozivom preverite, ali vaši dnevniki vsebujejo PII.
kontrolni seznam
- [ ] V svojem sistemu sem preslikal štiri vektorje puščanja (poziv, dnevnik, izhod, usposabljanje).
- [ ] Zamaskiram (redigiram/žetoniziram) PII, preden ga pošljem modelu.
- [ ] Dnevniki ne vsebujejo PII; Pred prijavo je lektoriranje.
- [ ] Preslikava ograd je shranjena začasno in varno.
- [ ] Od ponudnika sem pogodbeno prejel ZDR in garancijo »neuporabe v izobraževanju«.
- [ ] Preveril sem svojo zahtevo glede stalnega prebivališča (KVKK/GDPR).