Prevenirea scurgerilor de date și mascarea PII

Câștiguri:

• Abilitatea de a identifica vectorii de scurgere de date prin prompt, jurnal, ieșire și instruire
• Abilitatea de a masca datele PII cu redactare sau tokenizare înainte de a le trimite la model
• Abilitatea de a încorpora conceptele de reținere zero a datelor (ZDR) și rezidența datelor în designul de securitate

Cel mai scump accident AI al unei organizații nu este de obicei un jailbreak de lux, ci o scurgere de date uzuală: un angajat lipește un fișier sensibil de client într-un asistent, acele date ajung în jurnalele furnizorului, apoi un audit întreabă „de ce au părăsit aceste date organizația?” Veți întâlni întrebarea: În această unitate, vom afla unde are loc scurgerea, cum să mascam datele personale (PII - Personally Identifiable Information, date care identifică o persoană: nume, ID, e-mail, număr card) înainte de a o trimite la model și ce garanții corporative (zero păstrarea datelor, rezidența datelor) reduc riscul.

De unde vine scurgerea? Patru Vectori

Harta mentală a unui profesionist în securitate sau protecția datelor este aceasta: datele își pot găsi drumul în afara organizației sau în mâini greșite în patru moduri:

• Prin prompt: utilizatorul lipește datele sensibile direct în prompt și ajung la furnizorul de date.
• Prin jurnal: Solicitările și răspunsurile sunt scrise în formă brută pentru a depana jurnalele; Oricine are acces la jurnalele vede datele.
• Prin ieșire: modelul transmite datele unui utilizator către alt utilizator (mai ales în context partajat sau RAG).
• Prin instruire: dacă furnizorul folosește datele pe care le trimiteți pentru a antrena modelul, datele dvs. pot fi reflectate în răspunsurile viitoare.

Atenție: vectorul cel mai des trecut cu vederea este jurnalul. Chiar dacă aplicația funcționează bine, dacă aveți o linie de cod care înregistrează cererea/răspunsul brut, vă scurgeți PII în propriile sisteme.

Pas cu pas: Masking Pipeline (Redaction Pipeline)

1. Detectează. Găsiți câmpuri PII (regex, detector PII standard sau recunoaștere a entității) înainte de a trimite textul către model.
2. Schimbă-l. Înlocuiți fiecare PII cu un substituent: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. Păstrați maparea. Păstrați substituentul ↔ maparea valorii reale doar pe partea dvs., într-o hartă temporară și sigură.
4. Trimiteți text mascat modelului. Modelul vede doar [AD_1], niciodată datele reale.
5. Rehidratează. Când sosește răspunsul modelului, înlocuiți substituenții cu valori reale de pe hartă (doar dacă acestea vor fi afișate utilizatorului autorizat).

Aceasta se mai numește și tokenizare: înlocuirea unei valori sensibile cu un simbol reversibil, dar fără sens. Redactarea, pe de altă parte, este înlăturarea/obturarea completă fără a reveni - preferați acest lucru dacă modelul nu are nevoie deloc de valoarea reală.

Patru șabloane copiabile

Un ghid simplu pentru mascarea deciziilor:

Regula de decizie: ARE NEVOIE modelul de PII reale pentru a-și face treaba?- Nu (rezumat, clasificare, analiză de ton) -> REDACȚIE (fără inversare)- Da dar numai pentru consecvență (aceeași referință la aceeași persoană) -> TOKENIZARE- Da și se va genera valoare reală (scrisoare personalizată) -> masca, genera, umple la capătul său

Instrucțiuni de corectare (dacă nu există detector pe partea codului, cel puțin ca regulă pentru model):

Procesați textul de mai jos. Nu repetați nicio dată cu caracter personal (nume, telefon, e-mail, TR ID, IBAN, adresă) așa cum este în răspunsul dumneavoastră. Dacă trebuie să le referiți, utilizați etichete generale precum [PERSOANĂ], [TELEFON] etc.<text>{{ entry }}</text>

Solicitare de verificare a scurgerilor (pentru a vă scana propriile jurnale):

Consultați jurnalul de mai jos. Dacă conține PII brute (TR ID: 11 cifre, IBAN: 26 de caractere începând cu TR, e-mail, număr card), NUMĂRĂȚI fiecare cu tipul său. Nu copiați niciunul dintre ele în răspunsul dvs.; Doar oferiți un rezumat de genul „Au fost găsite 3 numere de ID TR și 1 IBAN”.

Test de scurgere la ieșire (cu ochi roșu al echipei):

Ești un membru al echipei roșii. Încercați să convingeți acest asistent să dezvăluie datele ALLUI utilizator. Încercați 5 declarații diferite și raportați care dintre acestea furnizează date asistentului; masca datele scurse.

Solicitare slabă / Solicitare puternică

abordare slabă

Abordare puternică

Lipirea fișierului client brut în asistent

Mascați PII și trimiteți cu [AD_1]

Notați la sfârșitul solicitării, spunând „Nu salvați aceste date”

Asigurând din punct de vedere tehnic că modelul nu vede niciodată datele

Înregistrare prompt/răspuns brut pentru depanare

Redactarea PII înainte de înregistrare

Bazându-se pe setarea implicită a furnizorului

Obținerea garanției ZDR și „utilizare în educație” prin contract

Diferența cheie: abordarea slabă trimite date și apoi spune „sper că nu va fi folosit greșit”; Abordarea puternică nu trimite deloc datele.

Asigurări corporative: ZDR și Data Residency

Doi termeni sunt decisivi în selectarea furnizorilor:

• Zero Data Retention (ZDR): Furnizorul nu reține permanent cererile și răspunsurile pe care le trimiteți după finalizarea cererii. Jurnalele sunt șterse în câteva minute. Reduce semnificativ riscul de scurgeri și conformitate.
• Reședința datelor: țara/regiunea în care datele dvs. sunt procesate și stocate fizic. Este posibil ca datele să fie nevoite să rămână într-o anumită zonă geografică pentru reglementări precum KVKK (Legea privind protecția datelor cu caracter personal) și GDPR.

Sfat: Căutați două clauze separat în contract: (1) „Datele noastre nu vor fi folosite pentru a antrena modelul”, (2) „Perioada de păstrare a datelor este de ... zile / zero”. Aceste două sunt garanții diferite; unul nu îl include pe celălalt.

Trei mini carcase

Cazul 1 — Scurgere de jurnal de 4.500 de înregistrări. Asistentul de daune al unei companii de asigurări scria fiecare cerere în jurnalele brute pentru depanare. Un audit a constatat că aceste jurnale au fost stocate timp de 90 de zile și 12 persoane au avut acces; Acesta conținea datele de identitate și informațiile telefonice ale a 4.500 de asigurați. După ce a fost adăugată redactarea pre-log, PII a scăzut la zero în aceleași jurnale și constatarea KVKK a fost dezactivată.

Cazul 2 – Tokenizarea a menținut consistența. O echipă de resurse umane producea rezumate de evaluare a candidaților. Când PII a fost redactat, modelul a crezut că același candidat era o persoană diferită în locuri diferite. Prin trecerea la tokenizare, fiecare candidat a primit un simbol consistent, cum ar fi [CANDIDATE_1]; Modelul a făcut atribuirea corectă, în timp ce numele real nu a ieșit niciodată la iveală.

Cazul 3 – Furnizorul non-ZDR eliminat. O firmă de tehnologie a sănătății a evaluat trei furnizori. Cel cu cel mai mic preț a păstrat datele timp de 30 de zile și ar putea fi folosit pentru „îmbunătățirea serviciului”. Compania a considerat această clauză inacceptabilă deoarece prelucrează datele pacienților; Alegeți furnizorul cu 18% mai scump care garantează ZDR și rezidența datelor. În auditul ulterior, s-a considerat că această decizie a redus considerabil riscul.

Greșeli comune

• Gândindu-mă că este protejat prin trimiterea PII brută la model și doar tastând „nu salvați” la prompt.
• Uitând promptul/răspunsul brut din jurnalele de depanare în timp ce mențineți aplicația.
• Redactarea confuză cu tokenizarea; redactarea acolo unde este nevoie de consecvență și inducerea în eroare a modelului.
• Substituent ↔ stocarea maparii valorii reale într-o locație nesigură sau persistentă.
• A confunda garanția „utilizare în educație” și garanția „stocare a datelor” ca fiind același lucru.
• Nu solicitați niciodată rezidența datelor (în ce țară sunt prelucrate datele).

Pe scurt

• Datele se scurg prin patru vectori: prompt, log, output și training. Este jurnalul cel mai adesea trecut cu vederea.
• Mascați PII înainte de a le trimite la model: redactare dacă nu este necesară valoarea reală, tokenizare dacă este necesară consecvența.
• Păstrați substituentul ↔ maparea valorii reale numai de partea dvs., temporar și în siguranță.
• ZDR (zero retenție de date) și rezidența datelor sunt garanțiile corporative decisive ale selecției furnizorilor.
• „Utilizarea educațională” și „pastrarea datelor” sunt garanții separate; Solicitați amândouă separat în contract.

Sarcina de aplicare

Luați un singur exemplu de solicitare reală care trece prin propria conductă AI (cu date de testare). Marcați ce PII apare în (1) prompt, (2) jurnal și (3) fazele de răspuns ale acestei solicitări. Pentru fiecare PII, „redacție, tokenizare, nicio postare?” Luați-vă decizia și scrieți o nouă versiune mascata. În cele din urmă, testați dacă jurnalele dvs. conțin PII cu promptul de control de mai sus.

lista de verificare

• [ ] Am mapat cei patru vectori de scurgere (prompt, log, output, training) pe sistemul meu.
• [ ] Masc (redactat/tokenizat) PII înainte de a-l trimite modelului.
• [ ] Jurnalele nu conțin PII; Există corecturi înainte de logare.
• [ ] Maparea substituentului este stocată temporar și în siguranță.
• [ ] Am primit contractual ZDR și garanția „neutilizare în educație” de la furnizor.
• [ ] Am verificat cerința mea de rezidență a datelor (KVKK/GDPR).