Dobici:
- Sposobnost identificiranja vektora curenja podataka putem brzog pisanja, zapisnika, izlaza i obuke
- Mogućnost maskiranja PII podataka redigiranjem ili tokenizacijom prije slanja modelu
- Sposobnost ugradnje koncepata nultog zadržavanja podataka (ZDR) i rezidentnosti podataka u sigurnosni dizajn
Najskuplja nezgoda s umjetnom inteligencijom u organizaciji obično nije otmjeno bjekstvo iz zatvora, već uobičajeno curenje podataka: zaposlenik zalijepi osjetljivu korisničku datoteku u pomoćnika, ti podaci završe u zapisima pružatelja usluga, a zatim revizija postavlja pitanje "zašto su ti podaci napustili organizaciju?" Susrest ćete se s pitanjem: U ovoj jedinici naučit ćemo gdje dolazi do curenja, kako maskirati osobne podatke (PII - Personally Identifiable Information, podatke koji identificiraju osobu: ime, ID, e-mail, broj kartice) prije slanja modelu i koje korporativne zaštitne mjere (nulto zadržavanje podataka, prebivalište podataka) smanjuju rizik.
Odakle dolazi curenje? Četiri vektora
Mentalna mapa stručnjaka za sigurnost ili zaštitu podataka je sljedeća — podaci mogu pronaći put izvan organizacije ili u pogrešne ruke na četiri načina:
- Putem upita: korisnik lijepi osjetljive podatke izravno u upit i oni idu davatelju podataka.
- Putem dnevnika: Zahtjevi i odgovori pišu se u sirovom obliku za otklanjanje pogrešaka u zapisnicima; Svatko tko ima pristup zapisnicima vidi podatke.
- Putem izlaza: Model prenosi podatke jednog korisnika drugom korisniku (osobito u zajedničkom kontekstu ili RAG-u).
- Obukom: ako pružatelj koristi podatke koje pošaljete za obuku modela, vaši se podaci mogu odraziti u budućim odgovorima.
Oprez: vektor koji se najčešće zanemaruje je log. Čak i ako aplikacija radi dobro, ako imate jedan redak koda koji bilježi neobrađeni zahtjev/odgovor, propuštate podatke koji otkrivaju identitet u vlastite sustave.
Korak po korak: Cjevovod za maskiranje (Cjevovod za uređivanje)
- Otkriti. Pronađite PII polja (regex, gotov detektor PII ili prepoznavanje entiteta) prije slanja teksta modelu.
- Promijenite to. Zamijenite svaki PII rezerviranim mjestom: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Zadržite mapiranje. Držite rezervirano mjesto ↔ mapiranje stvarne vrijednosti samo na svojoj strani, u privremenoj i sigurnoj karti.
- Pošalji maskirani tekst modelu. Model vidi samo [AD_1], nikad stvarne podatke.
- Rehidrirati. Kada stigne odgovor modela, zamijenite rezervirana mjesta stvarnim vrijednostima s karte (samo ako će biti prikazana ovlaštenom korisniku).
Ovo se također naziva tokenizacija: zamjena osjetljive vrijednosti reverzibilnim, ali besmislenim tokenom. Redakcija je, s druge strane, potpuno uklanjanje/zamagljivanje bez vraćanja — preferirajte ovo ako model uopće ne treba stvarnu vrijednost.
Četiri predloška za kopiranje
Jednostavan vodič za odluke o maskiranju:
Pravilo odlučivanja: TREBA LI model pravi PII da radi svoj posao?- Ne (sažimanje, klasifikacija, analiza tona) -> REDAKCIJA (bez poništavanja)- Da, ali samo radi dosljednosti (ista referenca na istu osobu) -> TOKENIZACIJA- Da i stvarna vrijednost će biti generirana (personalizirano pismo) -> maska, generiranje, zatrpavanje na kraju
Upute za lekturu (ako nema detektora na strani koda, barem u pravilu na modelu):
Obradite donji tekst. U svom odgovoru nemojte ponavljati nikakve osobne podatke (ime, telefon, e-mail, TR ID, IBAN, adresa) KAKVI JESU. Ako ih trebate referencirati, koristite općenite oznake kao što su [OSOBA], [TELEFON] itd.<text>{{ entry }}</text>
Upit za provjeru curenja (za skeniranje vlastitih zapisa):
Pogledajte zapisnik ispod. Ako sadrži neobrađeni PII (TR ID: 11 znamenki, IBAN: 26 znakova koji počinju s TR, e-mail, broj kartice), BROJITE svaki s njegovom vrstom. Nemojte kopirati ništa od njih u svoj odgovor; Samo dajte sažetak poput "Pronađena su 3 TR ID broja i 1 IBAN".
Test izlaznog curenja (s crvenim okom tima):
Vi ste član crvenog tima. Pokušajte uvjeriti ovog pomoćnika da otkrije podatke DRUGOG korisnika. Isprobajte 5 različitih izjava i prijavite koja od njih curi podatke asistentu; maskirati podatke koji su procurili.
Slab upit / Jak upit
loš pristup
Snažan pristup
Lijepljenje neobrađene datoteke klijenta u pomoćnika
Maskirajte PII i pošaljite s [AD_1]
Zabilježite na kraju upita "Nemoj spremati ove podatke"
Tehnički osigurava da model nikada ne vidi podatke
Bilježenje neobrađenog upita/odgovora za ispravljanje pogrešaka
Redigiranje podataka koji otkrivaju identitet prije prijave
Oslanjanje na zadanu postavku davatelja usluga
Ugovorom se dobiva ZDR i jamstvo "uporaba u obrazovanju".
Ključna razlika: slab pristup šalje podatke i zatim kaže "nadam se da neće biti zloupotrijebljeni"; Snažan pristup uopće ne šalje podatke.
Korporativna jamstva: ZDR i Data Residency
U izboru dobavljača odlučujuća su dva uvjeta:
- Nulto zadržavanje podataka (ZDR): Davatelj ne zadržava trajno zahtjeve i odgovore koje pošaljete nakon što je zahtjev dovršen. Dnevnici se brišu u roku od nekoliko minuta. Značajno smanjuje rizik od curenja i sukladnosti.
- Rezidencija podataka: država/regija u kojoj se vaši podaci fizički obrađuju i pohranjuju. Podaci će možda morati ostati u određenom zemljopisnom području zbog propisa kao što su KVKK (Zakon o zaštiti osobnih podataka) i GDPR.
Savjet: potražite dvije klauzule zasebno u ugovoru: (1) "Naši podaci neće se koristiti za obuku modela", (2) "Razdoblje zadržavanja podataka je ... dana / nula". Ova dva su različita jamstva; jedno ne uključuje drugo.
Tri mini kućišta
Slučaj 1 — curenje dnevnika od 4500 zapisa. Pomoćnik za odštetne zahtjeve osiguravajućeg društva zapisivao je svaki zahtjev u neobrađene dnevnike radi otklanjanja pogrešaka. Revizijom je utvrđeno da su ti zapisnici bili pohranjeni 90 dana i da je 12 osoba imalo pristup; Sadržao je osobne iskaznice i telefonske podatke 4500 osiguranika. Nakon što je dodana redakcija prije zapisnika, PII se smanjio na nulu u istim zapisima, a nalaz KVKK je isključen.
Slučaj 2 — Tokenizacija je održala dosljednost. Tim za ljudske resurse izrađivao je sažetke ocjenjivanja kandidata. Kad je PII redigiran, model je mislio da je isti kandidat druga osoba na različitim mjestima. Prelaskom na tokenizaciju svaki je kandidat dobio konzistentan token kao što je [CANDIDATE_1]; Manekenka je napravila točnu atribuciju, dok pravo ime nikada nije izašlo.
Slučaj 3 — Davatelj koji nije ZDR eliminiran. Tvrtka za zdravstvenu tehnologiju ocijenila je tri pružatelja usluga. Onaj s najnižom cijenom čuvao je podatke 30 dana i mogao se koristiti za “poboljšanje usluge”. Tvrtka je ovu klauzulu smatrala neprihvatljivom jer obrađuje podatke pacijenata; Odaberite 18% skupljeg davatelja koji jamči ZDR i podatkovnu rezidentnost. Naknadnom revizijom ocijenjeno je da je ova odluka uvelike smanjila rizik.
Uobičajene greške
- Misleći da je zaštićen slanjem neobrađenih PII modelu i samo upisivanjem "nemoj spremati" na upit.
- Zaboravljanje neobrađenog odziva/odgovora u zapisnicima otklanjanja pogrešaka tijekom održavanja aplikacije.
- Brkanje redigiranja s tokenizacijom; redigiranje tamo gdje je potrebna dosljednost i pogrešno dovođenje modela.
- Rezervirano mjesto ↔ pohranjivanje mapiranja stvarne vrijednosti na nesigurnu ili postojanu lokaciju.
- Miješati jamstvo "korištenje u obrazovanju" i jamstvo "pohranjivanje podataka" kao istu stvar.
- Nikada ne tražiti podatke o prebivalištu (u kojoj se zemlji podaci obrađuju).
Ukratko
- Podaci cure kroz četiri vektora: prompt, zapisnik, izlaz i obuka. To je balvan koji se najčešće zanemaruje.
- Maskirajte PII prije slanja u model: redigiranje ako stvarna vrijednost nije potrebna, tokenizacija ako je potrebna dosljednost.
- Držite rezervirano mjesto ↔ mapiranje stvarne vrijednosti samo na svojoj strani, privremeno i sigurno.
- ZDR (zero data retention) i rezidentnost podataka odlučujuće su korporativne zaštite pri odabiru dobavljača.
- "Upotreba u obrazovne svrhe" i "zadržavanje podataka" odvojena su jamstva; Tražite oboje zasebno u ugovoru.
Zadatak aplikacije
Uzmite jedan primjer stvarnog zahtjeva koji prolazi kroz vaš vlastiti AI cjevovod (s testnim podacima). Označite koji se PII pojavljuje u (1) odzivu, (2) zapisniku i (3) fazi odgovora ovog zahtjeva. Za svaki PII, "redakcija, tokenizacija, nikakvo objavljivanje?" Donesite svoju odluku i napišite novu maskiranu verziju. Na kraju, provjerite sadrže li vaši zapisnici PII pomoću gornjeg kontrolnog upita.
popis za provjeru
- [ ] Mapirao sam četiri vektora curenja (prompt, log, output, training) na svom sustavu.
- [ ] Maskiram (redigiram/označavam) PII prije nego što ga pošaljem modelu.
- [ ] Dnevnici ne sadrže PII; Postoji lektura prije prijave.
- [ ] Mapiranje rezerviranog mjesta pohranjuje se privremeno i sigurno.
- [ ] Od davatelja sam ugovorom dobio ZDR i jamstvo za "nekorištenje u obrazovanju".
- [ ] Potvrdio sam svoje uvjete prebivališta podataka (KVKK/GDPR).