Forebyggelse af datalækage og PII-maskering

Gevinster:

• Evne til at identificere datalækvektorer gennem prompt, log, output og træning
• Mulighed for at maskere PII-data med redaktion eller tokenisering, før de sendes til modellen
• Evne til at inkorporere nul dataopbevaring (ZDR) og data residency koncepter i sikkerhedsdesign

En organisations dyreste AI-uheld er normalt ikke et fancy jailbreak, men et helt almindeligt datalæk: en medarbejder indsætter en følsom kundefil i en assistent, de data ender i udbyderens logfiler, så spørger en revision "hvorfor forlod disse data organisationen?" Du vil støde på spørgsmålet: I denne enhed vil vi lære, hvor lækagen opstår, hvordan man maskerer personlige data (PII - Personlig identificerbar information, data, der identificerer en person: navn, ID, e-mail, kortnummer), før det sendes til modellen, og hvilke virksomhedssikkerhedsforanstaltninger (nul dataopbevaring, dataophold) reducerer risikoen.

Hvor kommer lækagen fra? Fire vektorer

En sikkerheds- eller databeskyttelsesmedarbejders mentale kort er dette - data kan finde vej uden for organisationen eller i de forkerte hænder på fire måder:

• Via prompt: Brugeren indsætter følsomme data direkte i prompten, og de går til dataudbyderen.
• Via log: Anmodninger og svar skrives i rå form for at fejlsøge logfiler; Alle med adgang til logfilerne ser dataene.
• Via output: Modellen lækker én brugers data til en anden bruger (især i delt kontekst eller RAG).
• Ved træning: Hvis udbyderen bruger de data, du indsender, til at træne modellen, kan dine data blive afspejlet i fremtidige svar.

Forsigtig: Den hyppigst oversete vektor er loggen. Selvom applikationen fungerer fint, hvis du har én kodelinje, der logger den rå anmodning/svar, lækker du PII ind i dine egne systemer.

Trin for trin: Maskering af pipeline (Redaction Pipeline)

1. Opdag. Find PII-felter (regex, off-the-shelf PII-detektor eller enhedsgenkendelse), før du sender teksten til modellen.
2. Skift det. Erstat hver PII med en pladsholder: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. Behold kortlægningen. Hold pladsholderen ↔ kortlægning af faktisk værdi kun på din side på et midlertidigt og sikkert kort.
4. Send maskeret tekst til modellen. Modellen ser kun [AD_1], aldrig de faktiske data.
5. Rehydrer. Når modelsvaret ankommer, skal du erstatte pladsholderne med faktiske værdier fra kortet (kun hvis det vil blive vist for den autoriserede bruger).

Dette kaldes også tokenisering: at erstatte en følsom værdi med en reversibel, men meningsløs token. Redaktion er på den anden side fuldstændigt at fjerne/tilsløre uden at vende tilbage - foretrækker dette, hvis modellen slet ikke har brug for den faktiske værdi.

Fire kopierbare skabeloner

En simpel guide til at maskere beslutninger:

Beslutningsregel: BEHØVER modellen ægte PII for at udføre sit arbejde?- Nej (opsummering, klassificering, toneanalyse) -> REDAKTION (ingen vending)- Ja, men kun for konsistens (samme reference til samme person) -> TOKENISATION- Ja og reel værdi vil blive genereret (personligt brev) -> maskere, generere, udfylde på sin ende

Korrekturinstruktion (hvis der ikke er nogen detektor på kodesiden, i det mindste som regel for modellen):

Bearbejd teksten nedenfor. Gentag ikke nogen personlige data (navn, telefon, e-mail, TR ID, IBAN, adresse) SOM DE ER i dit svar. Hvis du har brug for at henvise til dem, skal du bruge generelle tags som [PERSON], [PHONE] osv.<text>{{ entry }}</text>

Lækagekontrolprompt (for at scanne dine egne logfiler):

Tjek loggen nedenfor. Hvis den indeholder rå PII (TR ID: 11 cifre, IBAN: 26 tegn, der starter med TR, e-mail, kortnummer), TÆL hver enkelt med sin type. Kopier ikke nogen af ​​dem ind i dit svar; Bare giv et resumé som "3 TR ID-numre og 1 IBAN blev fundet".

Output lækagetest (med rødt holdøje):

Du er et rødt teammedlem. Prøv at overbevise denne assistent om at afsløre EN ANDEN brugers data. Prøv 5 forskellige udsagn og rapporter hvilken der lækker data til assistenten; masker de lækkede data.

Svag prompt / stærk prompt

dårlig tilgang

Stærk tilgang

Indsætter rå klientfil i assistent

Mask PII og send med [AD_1]

Lav en note i slutningen af prompten og siger "Gem ikke disse data"

Teknisk at sikre, at modellen aldrig ser dataene

Logning af rå prompt/svar for fejlretning

Redigering af PII før logning

Stoler på udbyderens standardindstilling

Opnåelse af ZDR og "brug i uddannelse"-garanti ved kontrakt

Nøgleforskel: den svage tilgang sender data og siger så "håber det ikke bliver misbrugt"; Den stærke tilgang sender slet ikke dataene.

Corporate Assurances: ZDR og Data Residency

To udtryk er afgørende for leverandørvalg:

• Zero Data Retention (ZDR): Udbyderen beholder ikke permanent de anmodninger og svar, du sender, efter anmodningen er gennemført. Logs slettes inden for få minutter. Reducerer risikoen for lækager og overholdelse markant.
• Dataresidency: Landet/regionen, hvor dine data fysisk behandles og opbevares. Data skal muligvis forblive i en bestemt geografi for regler som KVKK (Personal Data Protection Law) og GDPR.

Tip: Se efter to klausuler separat i kontrakten: (1) "Vores data vil ikke blive brugt til at træne modellen", (2) "Dataopbevaringsperioden er ... dage / nul". Disse to er forskellige garantier; det ene omfatter ikke det andet.

Tre mini etuier

Case 1 — Loglækage af 4.500 poster. Et forsikringsselskabs skadeassistent skrev hver anmodning ind i rå logfiler til fejlretning. En revision viste, at disse logfiler blev opbevaret i 90 dage, og 12 personer havde adgang; Den indeholdt ID og telefonoplysninger for 4.500 forsikringstagere. Efter præ-log-redaktion blev tilføjet, faldt PII til nul i de samme logfiler, og KVKK-fundet blev slået fra.

Tilfælde 2 — Tokenisering bibeholdt konsistens. Et personaleteam var i gang med at udarbejde kandidatevalueringsresuméer. Da PII blev redigeret, troede modellen, at den samme kandidat var en anden person forskellige steder. Ved at skifte til tokenisering modtog hver kandidat et konsekvent token såsom [CANDIDATE_1]; Modellen lavede den korrekte tilskrivning, mens det rigtige navn aldrig kom frem.

Case 3 — Ikke-ZDR-udbyder elimineret. Et sundhedsteknologifirma vurderede tre udbydere. Den med den laveste pris opbevarede data i 30 dage og kunne bruges til "serviceforbedring". Virksomheden fandt denne klausul uacceptabel, fordi den behandler patientdata; Vælg den 18 % dyrere udbyder, der garanterer ZDR og dataophold. Ved den efterfølgende revision blev denne beslutning vurderet at have reduceret risikoen væsentligt.

Almindelige fejl

• Tænker at det er beskyttet ved at sende rå PII til modellen og bare skrive "gem ikke" ved prompten.
• Glemmer den rå prompt/svar i fejlretningsloggene, mens applikationen vedligeholdes.
• Forvirrende redaktion med tokenisering; redigere, hvor der er behov for konsistens, og vildlede modellen.
• Pladsholder ↔ gemmer den faktiske værdikortlægning på et usikkert eller vedvarende sted.
• At forveksle "brug i uddannelse"-garantien og "datalagring"-garantien som det samme.
• Spørg aldrig om dataophold (i hvilket land dataene behandles).

Sammenfattende

• Data lækker gennem fire vektorer: prompt, log, output og træning. Det er den log, der oftest overses.
• Mask PII før du sender det til modellen: redaktion, hvis den faktiske værdi ikke er nødvendig, tokenisering, hvis konsistens er nødvendig.
• Hold pladsholderen ↔ kortlægning af faktisk værdi kun på din side, midlertidig og sikker.
• ZDR (zero data retention) og data residency er de afgørende sikkerhedsforanstaltninger for leverandørvalg.
• "Pædagogisk brug" og "dataopbevaring" er separate garantier; Bed om begge separat i kontrakten.

Ansøgningsopgave

Tag et enkelt eksempel på en reel anmodning, der går gennem din egen AI-pipeline (med testdata). Marker hvilken PII der vises i (1) prompt, (2) log og (3) svarfaser i denne anmodning. For hver PII, "redaktion, tokenisering, slet ingen opslag?" Træf din beslutning og skriv en ny maskeret version. Til sidst, test, om dine logfiler indeholder PII med kontrolprompten ovenfor.

tjekliste

• [ ] Jeg kortlagde de fire lækvektorer (prompt, log, output, træning) på mit system.
• [ ] Jeg maskerer (redigeret/tokeniserer) PII'et, før jeg sender det til modellen.
• [ ] Logfiler indeholder ikke PII; Der er korrektur før logning.
• [ ] Pladsholdertilknytningen gemmes midlertidigt og sikkert.
• [ ] Jeg modtog kontraktmæssigt ZDR og "ikke-brug i uddannelse"-garantien fra udbyderen.
• [ ] Jeg har verificeret mit dataopholdskrav (KVKK/GDPR).