GDPR-ին համապատասխան ML ուսուցման տվյալների անանունացում

Մեկ սկրիպտը բավարար չէ

Տվյալների գիտության յուրաքանչյուր թիմ գրել է մոտավորապես այսպիսի բան.

import re
def anonymize_email(text):
    return re.sub(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', '[EMAIL]', text)

Սա փոխարինում է էլ. հասցեները: Այն արդյունավետ է միայն դրա համար: Տվյալների հավաքածուն դեռ պահում է անուններ, հեռախոսահամարներ և բժշկական ID-ներ: Այն կձախողվի GDPR-ի աուդիտի ժամանակ:

"Ես անանունացրել եմ էլ. հասցեները" և "այս տվյալների հավաքածուն GDPR-ին համապատասխան է" արտահայտությունների միջև եղած բացը մեծ է: Թիմերը թերագնահատում են այն ամեն անգամ:

Ինչու GDPR-ը սահմանափակում է ML ուսուցման օգտագործումը

GDPR-ի 5(1)(բ) հոդվածը հիմնական կանոնն է: Այն կոչվում է նպատակի սահմանափակման սկզբունք: Անձնական գրառումները կարող են օգտագործվել միայն այն նպատակի համար, որի համար դրանք հավաքվել են:

Հաճախորդի պատվերները հավաքվել են պատվերի կատարման համար: Ոչ թե խորհուրդ տվող մոդելի ուսուցման համար: Բժշկական գրառումները հավաքվել են բուժման համար: Ոչ թե վերաընդունման մոդելի ուսուցման համար: Հարցման պատասխանները հավաքվել են արտադրանքի հետ կապված կարծիքի համար: Ոչ թե տրամադրությունների դասակարգչի ուսուցման համար:

Այդ գրառումները ML ուսուցման համար օգտագործելու համար թիմը կարիք ունի երեք բանից մեկին.

1. Յուրաքանչյուր անձի բացահայտ համաձայնությունը ML-ի նպատակի համար — դժվար է ստանալ, հաճախ հետ հայացքով անհնար
2. Օրինական շահերի գնահատումը, որը ցույց է տալիս, որ ML-ի օգտագործումը համատեղելի է — իրավական առումով անորոշ, կախված DPA-ից
3. Անանունացումը — անձնական մանրամասների փոխարինումը կամ հեռացումը, որպեսզի տվյալների հավաքածուն GDPR-ի ներքո այլևս անձնական չլինի

Պատշաճ անանունացումն ապահովում է ամենամեծ իրավական որոշակիությունը: Մարտահրավերն այն ճիշտ կատարելն է ամեն անգամ:

Մեկ անգամյա սկրիպտների հետ կապված խնդիրը

Այն թիմերը, որոնք յուրաքանչյուր տվյալների հավաքածուի համար նոր Python սկրիպտ են գրում, ստեղծում են բազմաշերտ խնդիրներ:

Թերի ծածկույթ: Մեկ սխեմայի համար կառուցված սկրիպտը բաց է թողնում նոր դաշտեր: Վեց ամիս առաջ ավելացված կլինիկական նշումների սյունակ? Regex-ում չկա: Միջին անվան դաշտ? Սկրիպտը կառավարում է միայն անվան և ազգանվան ձևաչափերը:

Անհամապատասխանություն: A տվյալների հավաքածուն մշակվել է script_v1-ով: B տվյալների հավաքածուն օգտագործել է script_v3: C տվյալների հավաքածուն մշակվել է այլ թիմի անդամի կողմից: Միաձուլված ուսուցման հավաքածուն ունի կիրառված երեք տարբեր մեթոդ: DPO-ն չի կարող հաստատել այն:

Աուդիտի հետք չկա: Սկրիպտն աշխատեց: Ի՞նչ փոխեց այն: Ո՞ր կազմակերպությունները հայտնաբերվեցին: Առանց մշակման գրառումների՝ համապատասխանությունն անհնար է: Երբ DPA-ի աուդիտորն հարցնում է. «Ինչպե՞ս գիտեք, որ այս ուսուցման հավաքածուն մաքուր է», «Մենք Python սկրիպտ ենք գործարկել» պատասխանը բավարար չէ:

Մոդելի շեղում: 2023 թ.-ին աշխատող regex ձևաչափերը բաց են թողնում 2024 թ.-ի նոր ID ձևաչափերը: Սկրիպտները ինքնաթարմացում չեն անում:

Խմբաքանակի մշակման ուղղորդում

Առողջապահության AI թիմը կարիք ունի 8,000 հիվանդի գրառումներ անանունացնել: ԱՄՆ-ի թիմը կարիք ունի EU գրասենյակից մուտք: Schrems II-ն կիրառվում է — EU-ծագման գրառումները չեն կարող գնալ ԱՄՆ ենթակառուցվածք՝ առանց պատշաճ երաշխիքների:

Ավանդական ուղի: Տվյալների ինժեները գրում է հատուկ սկրիպտ: Երկուսից երեք օր մշակման: Մեկից երկու օր DPO-ի ստուգման: Կատարելագործման մեկ օր: Ընդհանուր՝ չորսից վեց օր: ML նախագիծը հետ է ընկնում:

Խմբաքանակի մշակման ուղի.

1. Արտահանել 8,000 գրառումները CSV-ով
2. Բեռնել խմբաքանակի մշակման մեջ
3. Սահմանել կազմակերպությունների տեսակները. PERSON, EMAIL_ADDRESS, PHONE_NUMBER, US_SSN, MEDICAL_RECORD, DATE_OF_BIRTH, LOCATION
4. Ընտրել մեթոդ. Replace (փոխարինում է ռեալիստական սինթետիկ արժեքներ՝ կառուցվածքը պահպանելու համար)
5. Մշակել. 45 րոպե 8,000 գրառումների համար
6. Ներբեռնել մաքուր CSV-ը
7. DPO-ն ստուգում է մշակման մետատվյալները — գրառման կողմից հայտնաբերված կազմակերպություններ, կիրառված մեթոդներ. 2 ժամ
8. DPO-ն հաստատում է: Փոխանցումն իրականացվում է:

Ուղղակի ժամանակ. 45 րոպե, ավելի DPO-ի ստուգման 2 ժամ: Փոխանակ չորսից վեց օրի:

Те же шаги, կատարման EU AI Act ուսուցման ուղեցույցում նկարագրված են, թե ինչպես 10-րդ հոդվածի պարտավորությունները կատարվում են:

Replace ընդդեմ Redact-ի ML-ի կիրառման համար

Անանունացման մեթոդը կարևոր է մոդելի որակի համար:

Redact փոխարինում է PII-ն [REDACTED] նշանի պես թոքենով: Սա աշխատում է PII-ի հայտնաբերման մոդելների համար: Այլ առաջադրանքների համար — բովանդակություն, դասակարգում, առաջարկ — այն վնաս է հասցնում: Մոդելը սովորում է, որ [REDACTED]-ն հատուկ թոքեն է: Այն չի կարող սովորել անուններից և արժեքների բնական բաշխումից:

Replace փոխարինում է «John Smith»-ը «David Chen»-ով: Փոխարինում է «jsmith@company.com»-ը «dchen@synthetic.com»-ով: Կառուցվածքն անփոփոխ է մնում: Կազմակերպության տեղադրումը, համատեղ հանդիպման ձևաչափերը, նախադասությունների հոսքը — ամեն ինչ պահպանված է: Մոդելն ուսուցում է ռեալիստական համատեքստից:

ML ուսուցման հավաքածուների համար Replace-ը ճիշտ ընտրությունն է: Մոդելը չի սովորում կեղծ արժեքները: Այն սովորում է նրանց շուրջ ձևաչափերը: Դա կարևոր է:

Schrems II-ը և սահմանամերձ փոխանցումները

Schrems II-ի վճիռը (CJEU, 2020) անվավեր է ճանաչել EU-ԱՄՆ Privacy Shield-ը: EU-ծագման գրառումները չեն կարող գնալ ԱՄՆ ML ենթակառուցվածք — AWS US-East, GCP US-Central — առանց պատշաճ փոխանցման երաշխիքների:

Երեք հիմնական երաշխիքներն են.

• Ստանդարտ պայմանագրային կետեր՝ փոխանցման ազդեցության գնահատմամբ
• Կոռպորատիվ պարտադիր կանոններ ընկերությունների խմբի ներսում փոխանցումների համար
• Անանունացված գրառումների ազատ կիրառում — պատշաճ անանունացված ֆայլերն այլևս GDPR-ի ներքո անձնական չեն և ազատ են փոխանցման կանոններից

ԱՄՆ ենթակառուցվածք կիրառող թիմերի համար EU-ծագման հավաքածուների հետ՝ պատշաճ անանունացումը վերացնում է Schrems II-ի խնդիրը: Մաքուր տվյալների հավաքածուն անձնական չէ: Այն կարող է ազատ շարժվել:

Սա խմբաքանակի անանունացման ամենաուժեղ գործնական օգուտներից մեկն է: Այն ոչ միայն բավարարում է GDPR-ը: Այն ամբողջությամբ վերացնում է սահմանամերձ շփոթությունը:

Փոխանցման սահմանափակումների մասին ավելի մանրամասն կարդացեք GDPR-ի նպատակի սահմանափակման ուղեցույցում:

Ի՞նչ տալ DPO-ին

Մաքուր ուսուցման հավաքածուն DPO-ի հաստատման համար ներկայացնելիս ներառեք հետևյալ հինգ կետերը.

1. Աղբյուրի նկարագրություն: Ի՞նչ էր սկզբնական տվյալների հավաքածուն: Ի՞նչ էր հավաքագրման նպատակը: Ի՞նչ անձնական կատեգորիաներ էր այն պարունակում:
2. Անանունացման կոնֆիգուրացիա: Ի՞նչ կազմակերպությունների տեսակներ հայտնաբերվեցին և փոխարինվեցին: Ի՞նչ մեթոդ կիրառվեց:
3. Մշակման մետատվյալներ: Կազմակերպությունների հաշվարկ գրառման կողմից, վստահության գնահատականներ, ընդհանուր մշակված գրառումներ:
4. Մնացորդային ռիսկի գնահատում: Ո՞րն է հնարավորությունը, որ որևէ անձ կարող է վերաճանաչվել: Replace-մեթոդի անանունացման համար 285+ կազմակերպությունների տեսակներով կառուցվածքային տեքստի վրա՝ այս հավանականությունը շատ ցածր է:
5. Նախատեսված կիրառում: Ի՞նչ մոդել կուսուցանվի: Ի՞նչ է ուսուցման նպատակը:

Խմբաքանակի մշակումն ապահովում է 2-րդ և 3-րդ կետերն ավտոմատ կերպով: 1-ին, 4-րդ և 5-րդ կետերը գալիս են տվյալների գիտնականից:

Те же шаги, կատարման anonym.legal-ի խմբաքանակի API-ում կարելի է տեսնել, թե ինչպես է մշակման մետատվյալները վերադարձվում յուրաքանչյուր առաջադրանքի հետ:

Ի՞նչ եք ձեռք բերում

GDPR-ին համապատասխան ML հավաքածուները հնարավոր են առանց հատուկ սկրիպտների, բազմօրյա ուշացումների, և մոդելի որակի կորստի:

Replace-ի մեթոդը պահպանում է NLP ուսուցման համար կարևոր բնական լեզվի հատկությունները: Այն հեռացնում է GDPR-ի ռիսկ ստեղծող անձնական մանրամասները:

Խմբաքանակի մշակման 45 րոպեն տարբերությունն է հետաձգված համապատասխանության ստուգման ու ուղղակի DPO-ի հաստատման միջև:

Աղբյուրներ

• GDPR 5-րդ, 9-րդ, 89-րդ հոդվածներ. Նպատակի սահմանափակում, հատուկ կատեգորիայի գրառումներ, և հետազոտական երաշխիքներ
• CJEU: Schrems II — EU-ից ԱՄՆ փոխանցում
• Եվրոպական Տվյալների Պաշտպանության Խորհուրդ. ML-ի և GDPR-ի ուղեցույցներ