Pag-iwas sa Data Leak at PII Masking

Mga nadagdag:

• Kakayahang kilalanin ang mga vector ng pagtagas ng data sa pamamagitan ng prompt, log, output at pagsasanay
• Kakayahang i-mask ang data ng PII na may redaction o tokenization bago ito ipadala sa modelo
• Kakayahang isama ang zero data retention (ZDR) at mga konsepto ng data residency sa disenyo ng seguridad

Ang pinakamahal na AI mishap ng isang organisasyon ay karaniwang hindi isang magarbong jailbreak, ngunit isang run-of-the-mill data leak: ang isang empleyado ay nag-paste ng isang sensitibong file ng customer sa isang assistant, ang data na iyon ay napupunta sa mga log ng provider, pagkatapos ay nagtanong ang isang audit na "bakit umalis ang data na ito sa organisasyon?" Makakaharap mo ang tanong: Sa unit na ito, malalaman natin kung saan nangyayari ang pagtagas, kung paano i-mask ang personal na data (PII - Personally Identifiable Information, data na nagpapakilala sa isang tao: pangalan, ID, e-mail, numero ng card) bago ito ipadala sa modelo, at kung ano ang mga pananggalang ng korporasyon (zero data retention, data residency) ang nakakabawas sa panganib.

Saan nanggagaling ang pagtagas? Apat na Vector

Ang mental map ng isang propesyonal sa seguridad o proteksyon ng data ay ito — ang data ay makakahanap ng daan sa labas ng organisasyon o sa maling mga kamay sa apat na paraan:

• Sa pamamagitan ng prompt: Direktang i-paste ng user ang sensitibong data sa prompt at mapupunta ito sa provider ng data.
• Sa pamamagitan ng log: Ang mga kahilingan at tugon ay nakasulat sa raw na anyo upang i-debug ang mga log; Nakikita ng sinumang may access sa mga log ang data.
• Sa pamamagitan ng output: Ang modelo ay naglalabas ng data ng isang user sa isa pang user (lalo na sa nakabahaging konteksto o RAG).
• Sa pamamagitan ng pagsasanay: Kung ginagamit ng provider ang data na isinumite mo upang sanayin ang modelo, maaaring makita ang iyong data sa mga tugon sa hinaharap.

Babala: Ang pinaka-madalas na hindi napapansing vector ay ang log. Kahit na gumagana nang maayos ang application, kung mayroon kang isang linya ng code na nagla-log sa hilaw na kahilingan/tugon, nilalabas mo ang PII sa sarili mong mga system.

Hakbang sa Hakbang: Masking Pipeline (Redaction Pipeline)

1. Detect. Maghanap ng mga field ng PII (regex, off-the-shelf PII detector o entity recognition) bago ipadala ang text sa modelo.
2. Baguhin ito. Palitan ang bawat PII ng placeholder: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. Panatilihin ang pagmamapa. Panatilihin ang placeholder ↔ aktwal na pagmamapa ng halaga sa iyong tabi, sa isang pansamantala at secure na mapa.
4. Magpadala ng masked text sa modelo. Nakikita lang ng modelo ang [AD_1], hindi ang aktwal na data.
5. Mag-rehydrate. Kapag dumating ang tugon ng modelo, palitan ang mga placeholder ng aktwal na mga halaga mula sa mapa (kung ipapakita lamang ito sa awtorisadong gumagamit).

Tinatawag din itong tokenization: pinapalitan ang isang sensitibong halaga ng isang nababaligtad ngunit walang kahulugan na token. Ang redaction, sa kabilang banda, ay ganap na nag-aalis/nagkukubli nang hindi binabalikan — mas gusto ito kung hindi kailangan ng modelo ang aktwal na halaga.

Apat na Nakokopyang Template

Isang simpleng gabay sa pag-mask ng mga desisyon:

Panuntunan ng desisyon: KAILANGAN BA ng modelo ang tunay na PII para magawa ang trabaho nito?- Hindi (summarization, classification, tone analysis) -> REDACTION (walang reversal)- Oo ngunit para lang sa consistency (parehong reference sa iisang tao) -> TOKENIZATION- Oo at bubuo ang tunay na halaga (personalized letter) -> mask, generate, backfill on its end

Pagtuturo sa pag-proofread (kung walang detector sa gilid ng code, hindi bababa sa bilang panuntunan sa modelo):

Iproseso ang teksto sa ibaba. Huwag ulitin ang anumang personal na data (pangalan, telepono, e-mail, TR ID, IBAN, address) AS IS sa iyong tugon. Kung kailangan mong i-reference ang mga ito, gumamit ng mga pangkalahatang tag tulad ng [PERSON], [PHONE], atbp.<text>{{ entry }}</text>

Leak check prompt (upang i-scan ang sarili mong mga log):

Tingnan ang log sa ibaba. Kung naglalaman ito ng raw PII (TR ID: 11 digit, IBAN: 26 character na nagsisimula sa TR, e-mail, card number), BILANGIN ang bawat isa sa uri nito. Huwag kopyahin ang alinman sa mga ito sa iyong sagot; Magbigay lang ng buod tulad ng "3 TR ID number at 1 IBAN ang natagpuan".

Pagsubok sa pagtagas ng output (na may pulang mata ng koponan):

Isa kang miyembro ng red team. Subukang kumbinsihin ang assistant na ito na ipakita ang data ng IBANG user. Subukan ang 5 magkakaibang pahayag at iulat kung alin ang naglalabas ng data sa katulong; i-mask ang na-leak na data.

Mahina Prompt / Malakas na Prompt

mahinang diskarte

Malakas na diskarte

Pag-paste ng raw client file sa assistant

I-mask ang PII at ipadala kasama ang [AD_1]

Gumawa ng tala sa dulo ng prompt na nagsasabing "Huwag i-save ang data na ito"

Teknikal na tinitiyak na hindi kailanman makikita ng modelo ang data

Pag-log ng raw prompt/tugon para sa pag-debug

Pag-redact ng PII bago mag-log

Umaasa sa default na setting ng provider

Pagkuha ng ZDR at "paggamit sa edukasyon" na warranty sa pamamagitan ng kontrata

Pangunahing pagkakaiba: ang mahinang diskarte ay nagpapadala ng data at pagkatapos ay nagsasabing "sana hindi ito gagamitin sa maling paraan"; Ang malakas na diskarte ay hindi nagpapadala ng data sa lahat.

Mga Pagtitiyak ng Kumpanya: ZDR at Data Residency

Dalawang termino ang mapagpasyahan sa pagpili ng supplier:

• Zero Data Retention (ZDR): Hindi permanenteng pinapanatili ng provider ang mga kahilingan at tugon na ipinadala mo pagkatapos makumpleto ang kahilingan. Ang mga log ay tinanggal sa loob ng ilang minuto. Makabuluhang binabawasan ang panganib ng pagtagas at pagsunod.
• Data residency: Ang bansa/rehiyon kung saan pisikal na pinoproseso at iniimbak ang iyong data. Maaaring kailanganin ng data na manatili sa isang partikular na heograpiya para sa mga regulasyon gaya ng KVKK (Personal Data Protection Law) at GDPR.

Tip: Maghanap ng dalawang sugnay na magkahiwalay sa kontrata: (1) "Hindi gagamitin ang aming data para sanayin ang modelo", (2) "Ang panahon ng pagpapanatili ng data ay ... araw / zero". Ang dalawang ito ay magkaibang mga garantiya; hindi kasama ng isa ang isa.

Tatlong Mini Case

Case 1 — Log leak ng 4,500 record. Sinusulat ng claims assistant ng isang kumpanya ng insurance ang bawat kahilingan sa mga raw log para sa pag-debug. Nalaman ng isang pag-audit na ang mga log na ito ay nakaimbak sa loob ng 90 araw at 12 tao ang may access; Naglalaman ito ng ID at impormasyon sa telepono ng 4,500 na may hawak ng patakaran. Matapos maidagdag ang pre-log redaction, bumaba ang PII sa zero sa parehong mga log at na-off ang paghahanap sa KVKK.

Kaso 2 — Napanatili ng tokenization ang pare-pareho. Ang isang pangkat ng human resources ay gumagawa ng mga buod ng pagsusuri ng kandidato. Nang i-redact ang PII, naisip ng modelo na ang parehong kandidato ay ibang tao sa iba't ibang lugar. Sa pamamagitan ng paglipat sa tokenization, ang bawat kandidato ay nakatanggap ng pare-parehong token gaya ng [CANDIDATE_1]; Ginawa ng modelo ang tamang attribution, habang ang tunay na pangalan ay hindi lumabas.

Kaso 3 — Inalis ang provider na hindi ZDR. Sinuri ng isang health technology firm ang tatlong provider. Ang isa na may pinakamababang presyo ay nagpapanatili ng data sa loob ng 30 araw at maaaring gamitin para sa "pagpapabuti ng serbisyo." Nakita ng kumpanya na hindi katanggap-tanggap ang sugnay na ito dahil pinoproseso nito ang data ng pasyente; Piliin ang 18% na mas mahal na provider na ginagarantiyahan ang ZDR at data residency. Sa kasunod na pag-audit, ang desisyong ito ay itinuring na lubos na nakabawas sa panganib.

Mga karaniwang pagkakamali

• Iniisip na protektado ito sa pamamagitan ng pagpapadala ng raw PII sa modelo at pag-type lang ng "huwag i-save" sa prompt.
• Nakakalimutan ang hilaw na prompt/tugon sa mga debug log habang pinapanatili ang application.
• Nakalilitong redaction na may tokenization; redacting kung saan kailangan ang consistency at nililinlang ang modelo.
• Placeholder ↔ pag-iimbak ng aktwal na pagmamapa ng halaga sa isang hindi ligtas o patuloy na lokasyon.
• Napagkamalan ang garantiyang "paggamit sa edukasyon" at ang garantiyang "imbakan ng data" bilang parehong bagay.
• Hindi kailanman humihingi ng data residence (saang bansa ang data ay pinoproseso).

Sa buod

• Ang data ay tumagas sa pamamagitan ng apat na vectors: prompt, log, output, at pagsasanay. Ito ang log na madalas na hindi napapansin.
• I-mask ang PII bago ito ipadala sa modelo: redaction kung hindi kailangan ang aktwal na value, tokenization kung kailangan ang consistency.
• Panatilihin ang placeholder ↔ aktwal na pagmamapa ng halaga sa iyong tabi, pansamantala at ligtas.
• Ang ZDR (zero data retention) at data residency ay ang mapagpasyang corporate safeguards sa pagpili ng supplier.
• Ang "paggamit na pang-edukasyon" at "pagpapanatili ng data" ay magkahiwalay na mga warranty; Magtanong para sa pareho nang hiwalay sa kontrata.

Gawain ng aplikasyon

Kumuha ng isang halimbawa ng isang tunay na kahilingan sa pamamagitan ng sarili mong AI pipeline (na may data ng pagsubok). Markahan kung aling PII ang lalabas sa (1) prompt, (2) log, at (3) mga phase ng pagtugon ng kahilingang ito. Para sa bawat PII, “redaction, tokenization, no posting at all?” Magpasya ka at magsulat ng bagong bersyon na may maskara. Panghuli, subukan kung ang iyong mga log ay naglalaman ng PII na may control prompt sa itaas.

checklist

• [ ] Na-map ko ang apat na leak vectors (prompt, log, output, training) sa aking system.
• [ ] I-mask (redacted/tokenize) ang PII bago ipadala ito sa modelo.
• [ ] Ang mga log ay hindi naglalaman ng PII; May proofreading bago mag-log.
• [ ] Ang pagmamapa ng placeholder ay pansamantalang iniimbak at ligtas.
• [ ] Natanggap ko sa kontrata ang ZDR at ang warranty na "hindi nagagamit sa edukasyon" mula sa provider.
• [ ] Na-verify ko na ang aking data residence requirement (KVKK/GDPR).