Dobici:
- Sposobnost identifikacije vektora curenja podataka kroz prompt, log, izlaz i obuku
- Sposobnost maskiranja PII podataka redigovanjem ili tokenizacijom prije slanja u model
- Sposobnost inkorporiranja koncepta nulte retenzije podataka (ZDR) i rezidencije podataka u sigurnosni dizajn
Najskuplja greška AI organizacije obično nije fensi bijeg iz zatvora, već propušteno curenje podataka: zaposlenik zalijepi osjetljivu datoteku korisnika u pomoćnika, ti podaci završe u evidenciji provajdera, a zatim revizija pita "zašto su ovi podaci napustili organizaciju?" Naići ćete na pitanje: U ovoj jedinici naučit ćemo gdje dolazi do curenja, kako maskirati lične podatke (PII - Personal Identifiable Information, podaci koji identifikuju osobu: ime, ID, e-mail, broj kartice) prije nego što ih pošaljemo modelu i koje korporativne mjere zaštite (nulto zadržavanje podataka, rezidentnost podataka) smanjuju rizik.
Odakle dolazi curenje? Četiri vektora
Mentalna mapa stručnjaka za sigurnost ili zaštitu podataka je ova — podaci mogu pronaći put izvan organizacije ili u pogrešne ruke na četiri načina:
- Preko prompt-a: Korisnik zalijepi osjetljive podatke direktno u prompt i oni idu do dobavljača podataka.
- Putem dnevnika: Zahtjevi i odgovori se pišu u sirovom obliku za otklanjanje grešaka u evidenciji; Svako ko ima pristup evidenciji vidi podatke.
- Preko izlaza: Model propušta podatke jednog korisnika drugom korisniku (posebno u zajedničkom kontekstu ili RAG-u).
- Obukom: Ako dobavljač koristi podatke koje dostavite za obuku modela, vaši podaci se mogu odraziti u budućim odgovorima.
Oprez: Vektor koji se najčešće zanemaruje je dnevnik. Čak i ako aplikacija radi dobro, ako imate jednu liniju koda koja bilježi neobrađeni zahtjev/odgovor, propuštate PII u vlastite sisteme.
Korak po korak: Maskiranje cjevovoda (Redaction Pipeline)
- Detect. Pronađite PII polja (regex, gotovi PII detektor ili prepoznavanje entiteta) prije slanja teksta u model.
- Promijeni ga. Zamijenite svaki PII sa čuvarom mjesta: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
- Zadrži mapu. Čuvajte mjesto ↔ mapiranje stvarne vrijednosti samo na svojoj strani, u privremenoj i sigurnoj mapi.
- Pošaljite maskirani tekst modelu. Model vidi samo [AD_1], nikada stvarne podatke.
- Rehidrirajte. Kada stigne odgovor modela, zamijenite rezervirane mjesta stvarnim vrijednostima sa karte (samo ako će biti prikazana ovlaštenom korisniku).
Ovo se također naziva tokenizacija: zamjena osjetljive vrijednosti reverzibilnim, ali besmislenim tokenom. Redakcija, s druge strane, je potpuno uklanjanje/zamračenje bez vraćanja - preferirajte ovo ako model uopće ne treba stvarnu vrijednost.
Četiri predloška koji se mogu kopirati
Jednostavan vodič za maskiranje odluka:
Pravilo odluke: DA LI modelu TREBA pravi PII da bi obavio svoj posao?- Ne (sažimanje, klasifikacija, analiza tona) -> REDAKCIJA (bez preokreta)- Da, ali samo zbog konzistentnosti (ista referenca na istu osobu) -> TOKENIZACIJA- Da i stvarna vrijednost će se generirati (personalizirano pismo) -> maskirati, generirati, popuniti na kraju
Uputstvo za lekturu (ako na strani koda nema detektora, barem po pravilu modela):
Obradite tekst ispod. Nemojte ponavljati nikakve lične podatke (ime, telefon, e-mail, TR ID, IBAN, adresa) KAKVI JESU u svom odgovoru. Ako ih trebate referencirati, koristite općenite oznake kao što su [PERSON], [PHONE], itd.<text>{{ entry }}</text>
Prompt za provjeru curenja (za skeniranje vlastitih dnevnika):
Pogledajte zapisnik ispod. Ako sadrži neobrađeni PII (TR ID: 11 cifara, IBAN: 26 znakova koji počinju sa TR, e-mail, broj kartice), BROJITE svaki sa svojim tipom. Ne kopirajte nijednu od njih u svoj odgovor; Samo dajte sažetak poput "3 TR ID broja i 1 IBAN su pronađeni".
Test izlaznog curenja (sa crvenim timskim okom):
Vi ste član crvenog tima. Pokušajte uvjeriti ovog asistenta da otkrije podatke DRUGOG korisnika. Isprobajte 5 različitih izjava i prijavite pomoćniku koja od njih propušta podatke; maskirati procurele podatke.
Slaba prompt / jaka prompt
loš pristup
Snažan pristup
Lijepljenje neobrađenog klijentskog fajla u pomoćnika
Maskirajte PII i pošaljite s [AD_1]
Napravite bilješku na kraju upita i kažete "Nemojte pohranjivati ove podatke"
Tehnički osiguravajući da model nikada ne vidi podatke
Zapisivanje sirovog upita/odgovora za otklanjanje grešaka
Redakcija PII prije evidentiranja
Oslanjajući se na zadanu postavku provajdera
Dobijanje ZDR i garancije za "upotrebu u obrazovanju" po ugovoru
Ključna razlika: slab pristup šalje podatke, a zatim kaže "nadam se da neće biti zloupotrijebljen"; Snažan pristup uopće ne šalje podatke.
Korporativne garancije: ZDR i Rezidentnost podataka
Dva pojma su odlučujuća u izboru dobavljača:
- Zero Data Retention (ZDR): Provajder ne zadržava trajno zahtjeve i odgovore koje pošaljete nakon što je zahtjev završen. Dnevnici se brišu u roku od nekoliko minuta. Značajno smanjuje rizik od curenja i usklađenosti.
- Rezidencija podataka: Zemlja/regija u kojoj se vaši podaci fizički obrađuju i pohranjuju. Podaci će možda morati da ostanu u određenoj geografiji za propise kao što su KVKK (Zakon o zaštiti ličnih podataka) i GDPR.
Savjet: Potražite dvije klauzule odvojeno u ugovoru: (1) "Naši podaci se neće koristiti za obuku modela", (2) "Period zadržavanja podataka je ... dana / nula". To su dvije različite garancije; jedno ne uključuje drugo.
Tri mini futrole
Slučaj 1 — Curenje dnevnika od 4.500 zapisa. Pomoćnik osiguravajućeg društva za potraživanja upisivao je svaki zahtjev u neobrađene dnevnike radi otklanjanja grešaka. Revizijom je utvrđeno da su ovi dnevnici pohranjeni 90 dana i da je 12 ljudi imalo pristup; Sadržao je identifikaciju i telefonske podatke 4.500 osiguranika. Nakon dodavanja redakcije prije evidencije, PII se smanjio na nulu u istim evidencijama i KVKK nalaz je isključen.
Slučaj 2 — Tokenizacija je zadržala konzistentnost. Tim ljudskih resursa izrađivao je sažetke evaluacije kandidata. Kada je PII redigovan, model je mislio da je isti kandidat druga osoba na različitim mjestima. Prelaskom na tokenizaciju, svaki kandidat je dobio dosljedan token kao što je [CANDIDATE_1]; Model je napravio ispravnu atribuciju, dok pravo ime nikada nije objavljeno.
Slučaj 3 — Ne-ZDR provajder eliminisan. Firma za zdravstvenu tehnologiju procijenila je tri pružaoca usluga. Onaj s najnižom cijenom čuva podatke 30 dana i može se koristiti za „poboljšanje usluge“. Kompanija je ovu klauzulu smatrala neprihvatljivom jer obrađuje podatke o pacijentima; Odaberite 18% skupljeg provajdera koji garantuje ZDR i rezidentnost podataka. U naknadnoj reviziji, ova odluka je u velikoj mjeri umanjila rizik.
Uobičajene greške
- Misleći da je zaštićen slanjem neobrađene PII modelu i samo kucanjem "ne sačuvaj" na upit.
- Zaboravljanje sirovog upita/odgovora u evidenciji otklanjanja grešaka uz održavanje aplikacije.
- Brkanje redakcije sa tokenizacijom; redigovanje tamo gde je potrebna doslednost i dovođenje modela u zabludu.
- Čuvar mjesta ↔ pohranjivanje stvarnog mapiranja vrijednosti na nesigurnoj ili trajnoj lokaciji.
- Pogrešiti garanciju "upotrebe u obrazovanju" i garanciju "skladištenja podataka" kao istu stvar.
- Nikada ne pitajte za podatke o prebivalištu (u kojoj zemlji se podaci obrađuju).
Ukratko
- Podaci cure kroz četiri vektora: prompt, dnevnik, izlaz i obuka. To je dnevnik koji se najčešće zanemaruje.
- Maskirajte PII prije slanja u model: redigovanje ako stvarna vrijednost nije potrebna, tokenizacija ako je potrebna konzistentnost.
- Čuvajte mjesto ↔ mapiranje stvarne vrijednosti samo na vašoj strani, privremeno i sigurno.
- ZDR (nulto zadržavanje podataka) i rezidentnost podataka su odlučujuće korporativne garancije izbora dobavljača.
- "Obrazovna upotreba" i "zadržavanje podataka" su odvojene garancije; Zatražite oba odvojeno u ugovoru.
Zadatak aplikacije
Uzmite jedan primjer stvarnog zahtjeva koji prolazi kroz vaš vlastiti AI cjevovod (sa testnim podacima). Označite koji se PII pojavljuje u (1) promptu, (2) dnevniku i (3) fazama odgovora ovog zahtjeva. Za svaki PII, „redakcija, tokenizacija, bez objavljivanja?“ Donesite odluku i napišite novu maskiranu verziju. Na kraju, provjerite da li vaši zapisnici sadrže PII pomoću kontrolnog prompta iznad.
kontrolna lista
- [ ] Mapirao sam četiri vektora curenja (prompt, dnevnik, izlaz, obuka) na svom sistemu.
- [ ] Ja maskiram (redigiram/tokeniziram) PII prije nego što ga pošaljem modelu.
- [ ] Dnevnici ne sadrže PII; Postoji lektoriranje prije evidentiranja.
- [ ] Mapiranje čuvara mjesta je privremeno i sigurno pohranjeno.
- [ ] Ugovorno sam primio ZDR i garanciju za "neupotrebu u obrazovanju" od dobavljača.
- [ ] Potvrdio sam svoj zahtjev za prebivalište (KVKK/GDPR).