I-redact ang PII bago ang LLM call

Ilagay ang pagtukoy at pag-anonymize ng personal na datos sa application bago buuin ang prompt o ipadala ang request sa LLM. Suriin ang aktuwal na text na ipapasa, magpasya kung aling detalye ang kailangan sa gawain, at ang nalinis na bersyon lamang ang ibigay sa model. Kailangan pa ring sukatin ang mga PII na hindi nahuhuli ng detector: hindi maaalis ng redaction ang bahaging hindi nito natukoy.

Inirerekomenda ng gabay ng Microsoft sa seguridad ng LLM ang pag-sanitize ng data, pag-redact ng PII sa logs, paglilimita ng access at pagsubaybay sa input at output. Para sa isang application, kailangang tingnan ang buong daluyan: maaaring mapunta ang orihinal na detalye sa request log, nakuhang dokumento, error message o datos na ilalaan sa training kahit nalinis ang nakikitang mensahe ng user.

Iharang ang PII bago buuin ang prompt

Maaaring sundan ang daluyang analyzer → policy decision → anonymizer → LLM → output check. Tinutukoy ng analyzer ang uri at eksaktong puwesto ng mga posibleng PII sa text. Isama sa pagsusuri ang mensahe ng user at ang anumang sipi mula sa retrieval o tool na idaragdag sa prompt; maaaring magdala ng personal na detalye ang bawat bahagi ng konteksto.

Sa policy decision, itanong kung kailangan ng model ang mismong halaga, ang uri lamang ng impormasyon, o wala sa dalawa. Kung buod ng reklamo ang hinihingi, maaaring panatilihin ang problema habang inaalis ang pangalan at contact details. Kung may field na inaasahang sensitibo ngunit hindi malinaw ang pagkakatukoy, maaaring pigilan ang request o idaan sa awtorisadong pagsusuri ayon sa panganib ng gawain.

Pagkatapos lamang ng desisyong iyon ilapat ang anonymizer at buuin ang prompt mula sa nalinis na kopya. Panatilihing magkahiwalay ang orihinal na input at ang kopyang para sa model upang hindi aksidenteng magamit ng prompt builder ang maling bersyon. Suriin din ang sagot bago ito ipakita o itala: maaaring ulitin ng LLM ang detalyeng nakalusot sa input o nasa ibang bahagi ng konteksto.

Piliin ang operator ayon sa impormasyong kailangang matira

Ang dokumentasyon ng Presidio Anonymizer ay naglalarawan ng replace, redact, mask, hash at encrypt para sa mga bahaging natukoy na bilang PII. Iba-iba ang impormasyong naiiwan at ang posibilidad na maibalik ang halaga, kaya dapat nakabatay sa gawain ang pagpili ng operator.

Redact: alisin nang buo ang natukoy na halaga sa kopyang ipapadala. Angkop ito kapag hindi kailangan ng model ang halaga o ang uri nito. Hindi nito binubura ang orihinal na nasa ibang imbakan.
Replace: palitan ang halaga ng label gaya ng [PERSON] o [EMAIL]. Nananatili ang konteksto ng pangungusap nang hindi ibinibigay ang mismong detalye. Kung kailangang pag-ibahin ang dalawang tao sa iisang request, gumamit ng magkaibang pansamantalang label at itago ang mapping sa labas ng prompt.
Mask: takpan ang mga character habang may iniiwang bahagi kung kailangan talaga iyon sa gawain. Isaalang-alang na ang natitirang mga digit, kapag isinama sa ibang impormasyon, ay maaari pa ring makatulong sa pagkilala ng tao.
Hash: gawing token ang halaga para sa paghahambing. Hindi ito paraan para maibalik nang direkta ang orihinal na text, ngunit maaaring hulaan ang isang madaling tantiyahing input; huwag ipalagay na sapat na ang hash para maitago ang bawat uri ng identifier.
Encrypt: gawing ciphertext ang halaga kung may awtorisadong hakbang na kailangang magbalik nito sa orihinal. Reversible ito gamit ang tamang susi, kaya kailangang hiwalay ang pamamahala sa susi at sa data.

Sa hash operator na inilalarawan sa dokumentasyon, random ang salt bilang default. Kung kailangang makakuha ng parehong hash ang parehong halaga sa magkakaibang record o tawag, magbigay ng pare-parehong salt. Itago lamang ito kung kailangan ang gayong pagtutugma, sa protektadong imbakan ng secrets na may mahigpit na access; huwag ilagay ang salt sa prompt, output o log.

May kapalit ang pagpiling panatilihing pare-pareho ang token: mas madali nang pagdugtungin ang mga record na may parehong halaga. Sa encryption naman, nakasalalay ang posibilidad ng pagbabalik sa susi; kung ang application mismo ang kailangang magbalik ng pangalan sa sagot para sa awtorisadong user, gawin iyon pagkatapos ng model call at sa ilalim ng access control. Sa dalawang kaso, hindi dapat ipadala sa LLM ang salt, susi o mapping.

Subukan ang mga anyong nakikita sa Filipino input

Gumawa ng test set na may markadong uri, simula at dulo ng bawat PII span. Ang mga sumusunod ay mga halimbawang ginawa para sa test, at dapat matukoy ang nakasaad na bahagi bago maging prompt ang text:

“Pakisagot si Maria Santos tungkol sa reklamo.” — pangalan: Maria Santos.
“Tawagan sa 0917-000-0000 kapag handa na.” — numero ng telepono: 0917-000-0000.
“Ipadala ang sagot sa [email protected].” — email: [email protected].
“Hanapin ang customer ID na PH-CUST-0042.” — lokal na identifier: PH-CUST-0042.

Palawakin ang set sa mga baryasyon ng teleponong may +63, may espasyo o dagdag na bantas, at sa email na nakasingit sa gitna ng pangungusap. Subukan ding palitan ang “customer” ng “kliyente” o “account” sa paligid ng identifier. Ang PH-CUST-0042 ay halimbawang code lamang: para sa totoong application, ibatay ang recognizer sa sariling format ng mga identifier nito at sa mga salitang karaniwang kasama ng mga iyon.

Malinaw sa FAQ ng Presidio na walang garantiya ang awtomatikong pagtukoy sa lahat ng sensitibong impormasyon; maaari ring iangkop ang mga recognizer sa partikular na entity, datos at wika. Sukatin ang false-negative rate bilang bilang ng aktuwal na PII span na hindi natukoy na hinati sa lahat ng aktuwal na PII span sa test set. Tingnan din kung tama ang buong saklaw ng bawat natukoy na bahagi: maaaring matakpan ang unang bahagi ng numero ngunit maiwang lantad ang natitirang digit.

Itala rin ang mga false positive, o tekstong natakpan kahit hindi ito PII, upang makita kung nasisira ang gamit ng prompt. Ulitin ang pagsusukat kapag nagbago ang format ng input, recognizer o detection threshold. Mas kapaki-pakinabang ang magkahiwalay na resulta para sa pangalan, telepono, email at sariling identifier kaysa sa iisang kabuuang bilang na maaaring magtago ng mahinang pagkilala sa isang uri.

Isama ang log, training data at sagot sa daluyan

Kung naitala na ang raw request bago tumakbo ang analyzer, naroon pa rin ang PII kahit nalinis ang ipinadala sa LLM. Ilagay ang redaction bago ang request logging, at suriin din ang mga error message at debugging trace na maaaring kumopya ng input. Limitahan ang access sa orihinal na data kung kailangan itong panatilihin para sa isang awtorisadong proseso.

Gamitin ang parehong pagtukoy at patakaran bago kumopya ng text sa training o evaluation dataset. Sa output check, hanapin ang mga identifier na maaaring naulit mula sa input o konteksto at pigilan o linisin ang sagot ayon sa policy. Ang mahalagang sukatan ng pipeline ay ang aktuwal na naaalis at nalalampasang PII sa bawat rutang dadaanan ng data, kasama ang mga rutang hindi nakikita sa prompt.

Basahin din: