ડેટા લીક નિવારણ અને PII માસ્કીંગ

નફો:

• પ્રોમ્પ્ટ, લોગ, આઉટપુટ અને તાલીમ દ્વારા ડેટા લીક વેક્ટર્સને ઓળખવાની ક્ષમતા
• PII ડેટાને મોડલ પર મોકલતા પહેલા તેને રીડેક્શન અથવા ટોકનાઇઝેશન સાથે માસ્ક કરવાની ક્ષમતા
• સુરક્ષા ડિઝાઇનમાં શૂન્ય ડેટા રીટેન્શન (ZDR) અને ડેટા રેસીડેન્સી ખ્યાલો સામેલ કરવાની ક્ષમતા

સંસ્થાની સૌથી મોંઘી AI દુર્ઘટના સામાન્ય રીતે ફેન્સી જેલબ્રેક નથી, પરંતુ રન-ઓફ-ધ-મિલ ડેટા લીક છે: એક કર્મચારી એક સંવેદનશીલ ગ્રાહક ફાઇલને સહાયકમાં પેસ્ટ કરે છે, તે ડેટા પ્રદાતાના લોગમાં સમાપ્ત થાય છે, પછી ઓડિટ પૂછે છે કે "આ ડેટા શા માટે સંસ્થા છોડી ગયો?" તમને પ્રશ્નનો સામનો કરવો પડશે: આ એકમમાં, અમે શીખીશું કે લીક ક્યાં થાય છે, વ્યક્તિગત ડેટાને કેવી રીતે માસ્ક કરવો (PII - વ્યક્તિગત રીતે ઓળખી શકાય તેવી માહિતી, ડેટા કે જે વ્યક્તિને ઓળખે છે: નામ, ID, ઈ-મેલ, કાર્ડ નંબર) તેને મોડેલ પર મોકલતા પહેલા, અને કયા કોર્પોરેટ સલામતી (શૂન્ય ડેટા રીટેન્શન, ડેટા રેસીડેન્સી) જોખમ ઘટાડે છે.

લીક ક્યાંથી આવે છે? ચાર વેક્ટર

સિક્યોરિટી અથવા ડેટા પ્રોટેક્શન પ્રોફેશનલનો માનસિક નકશો આ છે — ડેટા ચાર રીતે સંસ્થાની બહાર અથવા ખોટા હાથમાં તેનો રસ્તો શોધી શકે છે:

• પ્રોમ્પ્ટ દ્વારા: વપરાશકર્તા સીધા જ પ્રોમ્પ્ટમાં સંવેદનશીલ ડેટા પેસ્ટ કરે છે અને તે ડેટા પ્રદાતા પાસે જાય છે.
• લોગ દ્વારા: લોગ ડીબગ કરવા માટે વિનંતીઓ અને પ્રતિસાદો કાચા સ્વરૂપમાં લખવામાં આવે છે; લોગની ઍક્સેસ ધરાવતી કોઈપણ વ્યક્તિ ડેટા જુએ છે.
• આઉટપુટ દ્વારા: મોડલ એક વપરાશકર્તાનો ડેટા બીજા વપરાશકર્તાને લીક કરે છે (ખાસ કરીને વહેંચાયેલ સંદર્ભ અથવા આરએજીમાં).
• તાલીમ દ્વારા: જો પ્રદાતા મોડેલને તાલીમ આપવા માટે તમે સબમિટ કરેલા ડેટાનો ઉપયોગ કરે છે, તો તમારો ડેટા ભવિષ્યના પ્રતિસાદોમાં પ્રતિબિંબિત થઈ શકે છે.

સાવધાન: સૌથી વધુ વારંવાર અવગણવામાં આવતું વેક્ટર લોગ છે. જો એપ્લીકેશન બરાબર કામ કરે તો પણ, જો તમારી પાસે કોડની એક લાઇન હોય જે કાચી વિનંતી/પ્રતિસાદને લૉગ કરે છે, તો તમે તમારી પોતાની સિસ્ટમમાં PII લીક કરી રહ્યાં છો.

સ્ટેપ બાય સ્ટેપ: માસ્કિંગ પાઇપલાઇન (રિડેક્શન પાઇપલાઇન)

1. શોધો. મોડેલ પર ટેક્સ્ટ મોકલતા પહેલા PII ફીલ્ડ્સ (રેજેક્સ, ઑફ-ધ-શેલ્ફ PII ડિટેક્ટર અથવા એન્ટિટી ઓળખ) શોધો.
2. તેને બદલો. દરેક PII ને પ્લેસહોલ્ડર સાથે બદલો: Ahmet Yılmaz → [AD_1], 12345678901 → [TCID_1].
3. મેપિંગ રાખો. પ્લેસહોલ્ડર રાખો ↔ વાસ્તવિક મૂલ્ય મેપિંગ ફક્ત તમારી બાજુ પર, અસ્થાયી અને સુરક્ષિત નકશામાં.
4. મોડેલ પર માસ્ક કરેલ ટેક્સ્ટ મોકલો. મોડેલ માત્ર [AD_1] જુએ છે, વાસ્તવિક ડેટા ક્યારેય નહીં.
5. રીહાઇડ્રેટ. જ્યારે મોડેલ પ્રતિસાદ આવે, ત્યારે પ્લેસહોલ્ડર્સને નકશામાંથી વાસ્તવિક મૂલ્યો સાથે બદલો (ફક્ત જો તે અધિકૃત વપરાશકર્તાને પ્રદર્શિત કરવામાં આવશે).

આને ટોકનાઇઝેશન પણ કહેવામાં આવે છે: ઉલટાવી શકાય તેવા પરંતુ અર્થહીન ટોકન સાથે સંવેદનશીલ મૂલ્યને બદલવું. બીજી બાજુ રીડેક્શન, પાછું ફેરવ્યા વિના સંપૂર્ણપણે દૂર/અસ્પષ્ટ કરી રહ્યું છે — જો મોડેલને વાસ્તવિક મૂલ્યની બિલકુલ જરૂર ન હોય તો આને પસંદ કરો.

ચાર નકલ કરી શકાય તેવા નમૂનાઓ

માસ્કિંગ નિર્ણયો માટે એક સરળ માર્ગદર્શિકા:

નિર્ણય નિયમ: શું મોડલને તેનું કામ કરવા માટે વાસ્તવિક PIIની જરૂર છે?- ના (સારાંશ, વર્ગીકરણ, સ્વર વિશ્લેષણ) -> રીડૅક્શન (કોઈ રિવર્સલ નહીં)- હા પરંતુ માત્ર સુસંગતતા માટે (સમાન વ્યક્તિ માટે સમાન સંદર્ભ) -> ટોકનાઇઝેશન- હા અને વાસ્તવિક મૂલ્ય જનરેટ કરવામાં આવશે (વ્યક્તિગત અક્ષર) -> તેના પાછળના ભાગ પર, માસ્ક કરો.

પ્રૂફરીડિંગ સૂચના (જો કોડ બાજુ પર કોઈ ડિટેક્ટર ન હોય તો, ઓછામાં ઓછા મોડેલના નિયમ તરીકે):

નીચેના ટેક્સ્ટ પર પ્રક્રિયા કરો. કોઈપણ વ્યક્તિગત ડેટા (નામ, ટેલિફોન, ઈ-મેલ, TR ID, IBAN, સરનામું) તમારા પ્રતિભાવમાં હોય તેમ પુનરાવર્તન કરશો નહીં. જો તમારે તેનો સંદર્ભ લેવાની જરૂર હોય, તો [વ્યક્તિ], [PHONE], વગેરે જેવા સામાન્ય ટૅગ્સનો ઉપયોગ કરો.<text>{{ પ્રવેશ }}</text>

લીક ચેક પ્રોમ્પ્ટ (તમારા પોતાના લોગને સ્કેન કરવા માટે):

નીચેનો લોગ તપાસો. જો તેમાં કાચો PII (TR ID: 11 અંક, IBAN: TR, ઈ-મેલ, કાર્ડ નંબરથી શરૂ થતા 26 અક્ષરો) હોય, તો દરેકને તેના પ્રકાર સાથે COUNT. તમારા જવાબમાં તેમાંથી કોઈપણની નકલ કરશો નહીં; ફક્ત "3 TR ID નંબર અને 1 IBAN મળ્યા" જેવો સારાંશ આપો.

આઉટપુટ લીક ટેસ્ટ (લાલ ટીમ આંખ સાથે):

તમે લાલ ટીમના સભ્ય છો. આ સહાયકને અન્ય વપરાશકર્તાનો ડેટા જાહેર કરવા માટે સમજાવવાનો પ્રયાસ કરો. 5 અલગ-અલગ નિવેદનો અજમાવી જુઓ અને જાણ કરો કે આસિસ્ટન્ટને કઈ ડેટા લીક કરે છે; લીક થયેલ ડેટાને માસ્ક કરો.

નબળા પ્રોમ્પ્ટ / મજબૂત પ્રોમ્પ્ટ

નબળી અભિગમ

મજબૂત અભિગમ

આસિસ્ટન્ટમાં કાચી ક્લાયન્ટ ફાઇલ પેસ્ટ કરી રહ્યાં છીએ

PII માસ્ક કરો અને [AD_1] સાથે મોકલો

પ્રોમ્પ્ટના અંતે "આ ડેટા સાચવશો નહીં" એમ કહીને એક નોંધ બનાવો

તકનીકી રીતે ખાતરી કરવી કે મોડેલ ક્યારેય ડેટા જુએ નહીં

ડીબગ માટે કાચો પ્રોમ્પ્ટ/પ્રતિસાદ લોગ કરી રહ્યું છે

લોગીંગ કરતા પહેલા PII ને સુધારવું

પ્રદાતાની ડિફૉલ્ટ સેટિંગ પર આધાર રાખવો

કરાર દ્વારા ZDR અને "શિક્ષણમાં ઉપયોગ" વોરંટી મેળવવી

મુખ્ય તફાવત: નબળો અભિગમ ડેટા મોકલે છે અને પછી કહે છે "આશા છે કે તેનો દુરુપયોગ થશે નહીં"; મજબૂત અભિગમ ડેટા બિલકુલ મોકલતો નથી.

કોર્પોરેટ એશ્યોરન્સ: ZDR અને ડેટા રેસીડેન્સી

સપ્લાયરની પસંદગીમાં બે શરતો નિર્ણાયક છે:

• ઝીરો ડેટા રીટેન્શન (ZDR): પ્રદાતા વિનંતી પૂર્ણ થયા પછી તમે મોકલો છો તે વિનંતીઓ અને પ્રતિસાદો કાયમ માટે જાળવી રાખતા નથી. લોગ મિનિટોમાં કાઢી નાખવામાં આવે છે. નોંધપાત્ર રીતે લિક અને પાલનના જોખમને ઘટાડે છે.
• ડેટા રેસીડેન્સી: દેશ/પ્રદેશ જ્યાં તમારા ડેટાની ભૌતિક રીતે પ્રક્રિયા અને સંગ્રહ કરવામાં આવે છે. KVKK (પર્સનલ ડેટા પ્રોટેક્શન લૉ) અને GDPR જેવા નિયમો માટે ડેટાને ચોક્કસ ભૂગોળમાં રહેવાની જરૂર પડી શકે છે.

ટીપ: કરારમાં અલગથી બે કલમો જુઓ: (1) "અમારા ડેટાનો ઉપયોગ મોડેલને તાલીમ આપવા માટે કરવામાં આવશે નહીં", (2) "ડેટા જાળવી રાખવાનો સમયગાળો ... દિવસ/શૂન્ય" છે. આ બે અલગ અલગ ગેરંટી છે; એકમાં બીજાનો સમાવેશ થતો નથી.

ત્રણ મિની કેસ

કેસ 1 - 4,500 રેકોર્ડ્સનો લોગ લીક. વીમા કંપનીના દાવા સહાયક દરેક વિનંતીને ડીબગીંગ માટે કાચા લોગમાં લખતા હતા. એક ઓડિટમાં જાણવા મળ્યું કે આ લોગ 90 દિવસ માટે સંગ્રહિત કરવામાં આવ્યા હતા અને 12 લોકો પાસે પ્રવેશ હતો; તેમાં 4,500 પોલિસીધારકોની આઈડી અને ટેલિફોન માહિતી હતી. પ્રી-લોગ રીડેક્શન ઉમેર્યા પછી, સમાન લોગમાં PII ઘટીને શૂન્ય થઈ ગયું અને KVKK શોધ બંધ થઈ ગઈ.

કેસ 2 - ટોકનાઇઝેશન સુસંગતતા જાળવી રાખે છે. માનવ સંસાધન ટીમ ઉમેદવાર મૂલ્યાંકન સારાંશનું નિર્માણ કરી રહી હતી. જ્યારે PII નું સંશોધન કરવામાં આવ્યું હતું, ત્યારે મોડેલને લાગ્યું કે એક જ ઉમેદવાર અલગ-અલગ જગ્યાએ અલગ વ્યક્તિ છે. ટોકનાઇઝેશન પર સ્વિચ કરીને, દરેક ઉમેદવારને સતત ટોકન પ્રાપ્ત થયું જેમ કે [CANDIDATE_1]; મોડેલે યોગ્ય એટ્રિબ્યુશન કર્યું છે, જ્યારે વાસ્તવિક નામ ક્યારેય બહાર આવ્યું નથી.

કેસ 3 — બિન-ZDR પ્રદાતા દૂર કરવામાં આવ્યા. આરોગ્ય તકનીકી પેઢીએ ત્રણ પ્રદાતાઓનું મૂલ્યાંકન કર્યું. સૌથી ઓછી કિંમત ધરાવતો એક 30 દિવસ માટે ડેટા રાખે છે અને તેનો ઉપયોગ "સેવા સુધારણા" માટે થઈ શકે છે. કંપનીને આ કલમ અસ્વીકાર્ય લાગી કારણ કે તે દર્દીના ડેટા પર પ્રક્રિયા કરે છે; ZDR અને ડેટા રેસીડેન્સીની બાંયધરી આપતા 18% વધુ ખર્ચાળ પ્રદાતા પસંદ કરો. ત્યારપછીના ઓડિટમાં, આ નિર્ણયથી જોખમમાં ઘણો ઘટાડો થયો હોવાનું માનવામાં આવતું હતું.

સામાન્ય ભૂલો

• એવું વિચારીને કે તે મોડેલને કાચો PII મોકલીને અને પ્રોમ્પ્ટ પર ફક્ત "સેવ કરશો નહીં" લખીને સુરક્ષિત છે.
• એપ્લિકેશનને જાળવી રાખતી વખતે ડીબગ લોગમાં કાચો પ્રોમ્પ્ટ/પ્રતિસાદ ભૂલી જવું.
• ટોકનાઇઝેશન સાથે ગૂંચવણભર્યું સુધારણા; જ્યાં સુસંગતતાની જરૂર હોય ત્યાં સુધારવું અને મોડેલને ગેરમાર્ગે દોરવું.
• પ્લેસહોલ્ડર ↔ અસુરક્ષિત અથવા સતત સ્થાન પર વાસ્તવિક મૂલ્ય મેપિંગને સંગ્રહિત કરવું.
• "શિક્ષણમાં ઉપયોગ" ગેરંટી અને "ડેટા સ્ટોરેજ" ગેરંટી સમાન વસ્તુ તરીકે ભૂલ કરવી.
• ક્યારેય ડેટા રેસિડેન્સ માટે પૂછશો નહીં (જે દેશમાં ડેટા પર પ્રક્રિયા કરવામાં આવે છે).

સારાંશમાં

• ચાર વેક્ટર દ્વારા ડેટા લીક થાય છે: પ્રોમ્પ્ટ, લોગ, આઉટપુટ અને તાલીમ. તે લોગ છે જે મોટેભાગે અવગણવામાં આવે છે.
• મોડેલ પર મોકલતા પહેલા PII માસ્ક કરો: જો વાસ્તવિક મૂલ્યની જરૂર ન હોય તો સુધારણા, જો સુસંગતતાની જરૂર હોય તો ટોકનાઇઝેશન.
• પ્લેસહોલ્ડર રાખો ↔ વાસ્તવિક મૂલ્ય મેપિંગ ફક્ત તમારી બાજુ પર, અસ્થાયી અને સલામત.
• ZDR (શૂન્ય ડેટા રીટેન્શન) અને ડેટા રેસીડેન્સી એ સપ્લાયરની પસંદગીના નિર્ણાયક કોર્પોરેટ સલામતી છે.
• "શૈક્ષણિક ઉપયોગ" અને "ડેટા રીટેન્શન" અલગ વોરંટી છે; કરારમાં બંને માટે અલગથી પૂછો.

એપ્લિકેશન કાર્ય

તમારી પોતાની AI પાઇપલાઇન (પરીક્ષણ ડેટા સાથે)માંથી પસાર થતી વાસ્તવિક વિનંતીનું એક ઉદાહરણ લો. (1) પ્રોમ્પ્ટ, (2) લોગ અને (3) આ વિનંતીના પ્રતિભાવ તબક્કામાં કયો PII દેખાય છે તે ચિહ્નિત કરો. દરેક PII માટે, "રિડેક્શન, ટોકનાઇઝેશન, બિલકુલ પોસ્ટિંગ નથી?" તમારો નિર્ણય લો અને નવું માસ્ક કરેલ સંસ્કરણ લખો. છેલ્લે, ઉપરના કંટ્રોલ પ્રોમ્પ્ટ સાથે તમારા લૉગમાં PII છે કે કેમ તે તપાસો.

ચેકલિસ્ટ

• [ ] મેં મારી સિસ્ટમ પર ચાર લીક વેક્ટર (પ્રોમ્પ્ટ, લોગ, આઉટપુટ, તાલીમ) ને મેપ કર્યા છે.
• [ ] હું PIIને મોડલ પર મોકલતા પહેલા તેને માસ્ક (રીડેક્ટ/ટોકનાઇઝ) કરું છું.
• [ ] લોગમાં PII નથી; લોગીંગ કરતા પહેલા પ્રૂફરીડિંગ છે.
• પ્લેસહોલ્ડર મેપિંગ અસ્થાયી રૂપે અને સુરક્ષિત રીતે સંગ્રહિત થાય છે.
• [ ] મને પ્રદાતા પાસેથી ZDR અને "શિક્ષણમાં બિન-ઉપયોગ" વોરંટી કરારપૂર્વક પ્રાપ્ત થઈ છે.
• [ ] મેં મારી ડેટા રેસિડેન્સ જરૂરિયાત (KVKK/GDPR) ચકાસેલ છે.