Forebygging av datalekkasje og PII-maskering

Gevinster:

• Evne til å identifisere datalekkasjevektorer gjennom spørsmål, logg, utdata og opplæring
• Evne til å maskere PII-data med redaksjon eller tokenisering før de sendes til modellen
• Evne til å inkorporere null dataoppbevaring (ZDR) og dataoppholdskonsepter i sikkerhetsdesign

En organisasjons dyreste AI-ulykke er vanligvis ikke et fancy jailbreak, men en løpende datalekkasje: en ansatt limer inn en sensitiv kundefil i en assistent, disse dataene havner i leverandørens logger, så spør en revisjon "hvorfor forlot disse dataene organisasjonen?" Du vil støte på spørsmålet: I denne enheten vil vi lære hvor lekkasjen oppstår, hvordan du maskerer personopplysninger (PII - Personlig identifiserbar informasjon, data som identifiserer en person: navn, ID, e-post, kortnummer) før du sender det til modellen, og hvilke bedriftssikkerhetsforanstaltninger (null dataoppbevaring, dataopphold) reduserer risikoen.

Hvor kommer lekkasjen fra? Fire vektorer

En sikkerhets- eller databeskyttelseseksperts mentale kart er dette - data kan finne veien utenfor organisasjonen eller i feil hender på fire måter:

• Via ledetekst: Brukeren limer inn sensitive data direkte i ledeteksten, og den går til dataleverandøren.
• Via logg: Forespørsler og svar skrives i rå form for å feilsøke logger; Alle med tilgang til loggene ser dataene.
• Via utgang: Modellen lekker én brukers data til en annen bruker (spesielt i delt kontekst eller RAG).
• Ved opplæring: Hvis leverandøren bruker dataene du sender til å trene modellen, kan dataene dine gjenspeiles i fremtidige svar.

Forsiktig: Den hyppigst oversett vektoren er loggen. Selv om applikasjonen fungerer bra, hvis du har én kodelinje som logger råforespørselen/svaret, lekker du PII inn i dine egne systemer.

Trinn for trinn: Maskeringsrørledning (redaksjonsrørledning)

1. Oppdag. Finn PII-felt (regex, hyllevare PII-detektor eller enhetsgjenkjenning) før du sender teksten til modellen.
2. Endre det. Erstatt hver PII med en plassholder: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. Behold kartleggingen. Hold plassholderen ↔ kartleggingen av faktisk verdi bare på din side, i et midlertidig og sikkert kart.
4. Send maskert tekst til modellen. Modellen ser bare [AD_1], aldri de faktiske dataene.
5. Rehydrerer. Når modellsvaret kommer, bytt ut plassholderne med faktiske verdier fra kartet (bare hvis det vil bli vist til den autoriserte brukeren).

Dette kalles også tokenisering: å erstatte en sensitiv verdi med en reversibel, men meningsløs token. Redaksjon, på den annen side, er fullstendig fjerning/tilsløring uten å gå tilbake - foretrekk dette hvis modellen ikke trenger den faktiske verdien i det hele tatt.

Fire kopierbare maler

En enkel veiledning for å maskere beslutninger:

Beslutningsregel: TRENGER modellen ekte PII for å gjøre jobben sin?- Nei (oppsummering, klassifisering, toneanalyse) -> REDAKSJON (ingen reversering)- Ja, men bare for konsistens (samme referanse til samme person) -> TOKENISERING- Ja og reell verdi vil bli generert (personliggjort brev) -> maskere, generere, fylle ut på slutten.

Korrekturinstruksjon (hvis det ikke er noen detektor på kodesiden, i det minste som regel for modellen):

Behandle teksten nedenfor. Ikke gjenta noen personlige data (navn, telefon, e-post, TR ID, IBAN, adresse) SOM ER i svaret ditt. Hvis du trenger å referere til dem, bruk generelle tagger som [PERSON], [PHONE], osv.<text>{{ oppføring }}</text>

Lekkasjekontrollspørsmål (for å skanne dine egne logger):

Sjekk ut loggen nedenfor. Hvis den inneholder rå PII (TR ID: 11 sifre, IBAN: 26 tegn som begynner med TR, e-post, kortnummer), TELLE hver enkelt med sin type. Ikke kopier noen av dem inn i svaret ditt; Bare gi et sammendrag som "3 TR ID-numre og 1 IBAN ble funnet".

Utgangslekkasjetest (med rødt lagøye):

Du er et rødt teammedlem. Prøv å overbevise denne assistenten om å avsløre EN ANNEN brukers data. Prøv 5 forskjellige utsagn og rapporter hvilken som lekker data til assistenten; maskere de lekkede dataene.

Svak forespørsel / sterk forespørsel

dårlig tilnærming

Sterk tilnærming

Limer inn rå klientfil i assistent

Mask PII og send med [AD_1]

Noter på slutten av forespørselen og sier "Ikke lagre disse dataene"

Teknisk å sikre at modellen aldri ser dataene

Logger rå melding/svar for feilsøking

Redigerer PII før logging

Stoler på leverandørens standardinnstilling

Anskaffelse av ZDR og "bruk i utdanning"-garanti etter kontrakt

Hovedforskjell: den svake tilnærmingen sender data og sier så "håper den ikke blir misbrukt"; Den sterke tilnærmingen sender ikke dataene i det hele tatt.

Corporate Assurances: ZDR og Data Residency

To begreper er avgjørende for leverandørvalg:

• Zero Data Retention (ZDR): Leverandøren beholder ikke forespørslene og svarene du sender permanent etter at forespørselen er fullført. Logger slettes i løpet av minutter. Reduserer risikoen for lekkasjer og overholdelse betydelig.
• Dataopphold: Landet/regionen der dataene dine fysisk behandles og lagres. Data må kanskje forbli i en bestemt geografi for forskrifter som KVKK (Personal Data Protection Law) og GDPR.

Tips: Se etter to klausuler separat i kontrakten: (1) "Våre data vil ikke bli brukt til å trene modellen", (2) "Dataoppbevaringsperioden er ... dager / null". Disse to er forskjellige garantier; det ene inkluderer ikke det andre.

Tre minivesker

Sak 1 — Logglekkasje av 4500 poster. Et forsikringsselskaps skadeassistent skrev hver forespørsel inn i rålogger for feilsøking. En revisjon fant at disse loggene ble lagret i 90 dager og 12 personer hadde tilgang; Den inneholdt ID og telefoninformasjon til 4500 forsikringstakere. Etter at pre-log-redaksjon ble lagt til, sank PII til null i de samme loggene og KVKK-funnet ble slått av.

Tilfelle 2 – Tokenisering opprettholdt konsistens. Et personalteam laget sammendrag av kandidatevalueringer. Da PII ble redigert, trodde modellen at den samme kandidaten var en annen person på forskjellige steder. Ved å bytte til tokenisering mottok hver kandidat et konsistent token som [CANDIDATE_1]; Modellen gjorde den riktige attribusjonen, mens det virkelige navnet aldri kom ut.

Tilfelle 3 – Ikke-ZDR-leverandør eliminert. Et helseteknologifirma evaluerte tre leverandører. Den med lavest pris beholdt data i 30 dager og kan brukes til "forbedring av tjenesten." Selskapet fant denne klausulen uakseptabel fordi den behandler pasientdata; Velg den 18 % dyrere leverandøren som garanterer ZDR og dataopphold. I den påfølgende revisjonen ble denne beslutningen vurdert å ha redusert risikoen betydelig.

Vanlige feil

• Tenker at den er beskyttet ved å sende rå PII til modellen og bare skrive "ikke lagre" ved ledeteksten.
• Glemte den rå ledeteksten/svaret i feilsøkingsloggene mens du vedlikeholder applikasjonen.
• Forvirrende redaksjon med tokenisering; redigere der konsistens er nødvendig og villedende modellen.
• Plassholder ↔ lagrer den faktiske verdikartleggingen på et usikkert eller vedvarende sted.
• Å ta feil av "bruk i utdanning"-garantien og "datalagring"-garantien som det samme.
• Spør aldri om dataopphold (i hvilket land dataene behandles).

Oppsummert

• Data lekker gjennom fire vektorer: ledetekst, logg, utdata og opplæring. Det er stokken som oftest blir oversett.
• Mask PII før du sender den til modellen: redaksjon hvis den faktiske verdien ikke er nødvendig, tokenisering hvis konsistens er nødvendig.
• Hold plassholderen ↔ kartleggingen av faktisk verdi bare på din side, midlertidig og trygg.
• ZDR (zero data retention) og data residency er de avgjørende sikkerhetstiltakene for leverandørvalg.
• "Utdanningsbruk" og "dataoppbevaring" er separate garantier; Be om begge separat i kontrakten.

Søknadsoppgave

Ta et enkelt eksempel på en reell forespørsel som går gjennom din egen AI-pipeline (med testdata). Merk hvilken PII som vises i (1) ledeteksten, (2) loggen og (3) svarfasene for denne forespørselen. For hver PII, "redaksjon, tokenisering, ingen innlegg i det hele tatt?" Ta avgjørelsen din og skriv en ny maskert versjon. Til slutt, test om loggene dine inneholder PII med kontrollprompten ovenfor.

sjekkliste

• [ ] Jeg kartla de fire lekkasjevektorene (spørsmål, logg, utgang, trening) på systemet mitt.
• [ ] Jeg maskerer (redigert/tokeniserer) PII før jeg sender den til modellen.
• [ ] Logger inneholder ikke PII; Det er korrekturlesing før logging.
• [ ] Plassholdertilordningen lagres midlertidig og sikkert.
• [ ] Jeg mottok kontraktsmessig ZDR og "ikke-bruk i utdanning"-garantien fra leverandøren.
• [ ] Jeg har bekreftet mitt krav om bosted (KVKK/GDPR).