بيانات تدريب ML متوافقة مع GDPR: إخفاء هوية 10,000...

بيانات تدريب ML متوافقة مع GDPR: إخفاء هوية 10,000 سجل دون كتابة كود

كل فريق علم بيانات يعمل على بيانات خاضعة لـ GDPR قد كتب نسخة من هذا السكربت:

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

هذا ليس توافقًا مع GDPR. إنه استبدال عنوان البريد الإلكتروني. لا تزال مجموعة البيانات تحتوي على أسماء وأرقام هواتف ومعرفات سجلات طبية وعشرات الفئات الأخرى من PII التي ستسبب فشل التوافق.

الفجوة بين "لقد أخفيت هوية البريد الإلكتروني" و"هذه مجموعة البيانات متوافقة مع GDPR لتدريب ML" كبيرة وعواقبها جسيمة وغالبًا ما يتم التقليل من شأنها.

لماذا يحد GDPR من استخدام بيانات تدريب ML

تنص مبدأ تحديد الغرض في GDPR (المادة 5(1)(ب)) على أنه يمكن جمع البيانات الشخصية لأغراض محددة وصريحة ومشروعة ولا يجوز معالجتها بشكل يتعارض مع تلك الأغراض.

لم يتم جمع بيانات العملاء التي تم جمعها لتلبية الطلب لغرض تدريب نموذج التوصية. لم يتم جمع بيانات السجلات الصحية التي تم جمعها للعلاج لغرض تدريب نموذج توقع إعادة القبول. لم يتم جمع بيانات استجابة الاستطلاع التي تم جمعها لتعليقات المنتج لغرض تدريب نموذج تحليل المشاعر.

يتطلب استخدام هذه البيانات لتدريب ML إما:

1. موافقة صريحة من كل موضوع بيانات لغرض تدريب ML (معقدة من الناحية التشغيلية، وغالبًا ما تكون مستحيلة بأثر رجعي)
2. تقييم المصلحة المشروعة يظهر أن الغرض من التدريب متوافق مع الجمع الأصلي (غير مؤكد قانونيًا، يعتمد على DPA)
3. إخفاء الهوية — إزالة أو استبدال PII بحيث لم تعد البيانات بيانات شخصية بموجب GDPR

الإخفاء المناسب هو الطريق الأقل مقاومة وأكبر يقين قانوني. التحدي هو القيام بذلك بشكل صحيح ومتسق.

المشكلة مع سكربتات الإخفاء غير الرسمية

تقوم فرق علم البيانات بكتابة سكربتات بايثون لمرة واحدة لكل مجموعة بيانات جديدة مما يخلق مشاكل متراكمة:

تغطية غير كاملة: سكربت مكتوب للتعامل مع مخطط مجموعة بيانات واحدة يفوت PII في الأعمدة التي تمت إضافتها منذ آخر تحديث للمخطط. حقل الملاحظات السريرية الذي تمت إضافته قبل 6 أشهر: ليس في نمط regex. حقل اسم العميل الأوسط: regex يتعامل فقط مع أنماط FIRST_NAME و LAST_NAME.

عدم الاتساق عبر مجموعات البيانات: تم إخفاء هوية مجموعة البيانات A باستخدام script_v1.py. تم إخفاء هوية مجموعة البيانات B باستخدام script_v3.py. تم إخفاء هوية مجموعة البيانات C بواسطة عضو فريق مختلف لم يكن يعرف عن script_v3.py. تحتوي مجموعة بيانات التدريب المدمجة على ثلاث منهجيات إخفاء هوية مختلفة. لا يمكن لموظف حماية البيانات (DPO) التصديق عليها.

عدم وجود سجل تدقيق: تم تشغيل السكربت. ماذا غير؟ أي الكيانات تم العثور عليها؟ في أي صفوف؟ بدون معالجة البيانات الوصفية، فإن الوثائق المتعلقة بالتوافق مستحيلة. عندما يسأل مدقق DPA "كيف تعرف أن مجموعة بيانات التدريب هذه مخفية الهوية؟"، فإن "قمنا بتشغيل سكربت بايثون" ليست إجابة مرضية.

انحراف النموذج: أنماط regex التي عملت على بيانات 2023 لا تكتشف تنسيقات المعرف الجديدة التي تم تقديمها في بيانات 2024 (تنسيق SSN الجديد، أنماط نطاق البريد الإلكتروني المختلفة، تنسيقات أرقام الهواتف المتطورة). لا تقوم السكربتات بتحديث نفسها.

نهج معالجة الدفعات

تحتاج فريق علم البيانات في شركة AI للرعاية الصحية إلى إخفاء هوية 8,000 سجل مريض قبل أن يتمكن فريقهم الأمريكي من الوصول إليها من مكتبهم في الاتحاد الأوروبي (تنطبق قيود نقل البيانات عبر الحدود في Schrems II).

النهج التقليدي: يكتب مهندس البيانات سكربت إخفاء هوية بايثون مخصص. الوقت: 2-3 أيام من التطوير، 1-2 يوم من الاختبار والمراجعة مع DPO، يوم واحد من التكرار. المجموع: 4-6 أيام. ينزلق الجدول الزمني لمشروع ML.

نهج معالجة الدفعات:

1. تصدير 8,000 سجل كملف CSV (تنسيق علم البيانات القياسي)
2. تحميل إلى معالجة الدفعات
3. تكوين أنواع الكيانات: PERSON، EMAIL_ADDRESS، PHONE_NUMBER، US_SSN، MEDICAL_RECORD، DATE_OF_BIRTH، LOCATION
4. اختيار الطريقة: استبدال (استبدال البيانات الواقعية المزيفة للحفاظ على هيكل مجموعة البيانات لتدريب ML)
5. المعالجة: 45 دقيقة لـ 8,000 سجل
6. تنزيل CSV المخفي الهوية
7. يراجع DPO بيانات المعالجة الوصفية (الكيانات التي تم العثور عليها لكل سجل، طرق التطبيق): ساعتان
8. يوافق DPO، ويستمر مشاركة البيانات

إجمالي الوقت: 45 دقيقة معالجة + ساعتان مراجعة DPO مقابل 4-6 أيام هندسة. يبقى الجدول الزمني لمشروع ML على المسار الصحيح.

الاستبدال مقابل الإخفاء للبيانات التدريبية ML

تعتبر طريقة الإخفاء مهمة لفائدة ML:

الإخفاء (استبدال بشريط أسود / عنصر نائب): يستبدل PII بـ [REDACTED] أو رمز مشابه. تحتوي مجموعة البيانات الناتجة على رموز عنصر نائب متسقة حيث كانت PII. بالنسبة لنماذج NLP المدربة لاكتشاف PII، فإن هذا ينشئ مجموعة بيانات موسومة. بالنسبة للنماذج المدربة على المهام اللاحقة (المشاعر، التصنيف، التوصية)، فإن رمز [REDACTED] يعطل نمذجة اللغة الطبيعية - يتعلم النموذج أن [REDACTED] هو رمز خاص بدلاً من التعلم من توزيع الأسماء والقيم الحقيقية.

الاستبدال (استبدال اصطناعي واقعي): يستبدل "جون سميث" بـ "ديفيد تشين" (اسم واقعي ولكنه مختلف). يصبح البريد الإلكتروني "jsmith@company.com" هو "dchen@synthetic.com". تحافظ مجموعة البيانات الناتجة على توزيعات اللغة الطبيعية - بنية الجملة، وضع الكيانات، أنماط التواجد المشترك - التي تعتبر مهمة لتدريب نموذج NLP.

بالنسبة لبيانات تدريب ML تحديدًا، فإن الاستبدال هو الطريقة المناسبة. لا يتعلم النموذج التنبؤ بالقيم المزيفة المحددة (إنها استبدالات عشوائية)، ولكنه يتعلم من الأنماط الهيكلية والسياقية لكيفية ظهور الأسماء والبريد الإلكتروني والكيانات الأخرى في النص.

Schrems II وتدفقات البيانات عبر الحدود

ألغت قرار Schrems II (CJEU، 2020) درع الخصوصية بين الاتحاد الأوروبي والولايات المتحدة، مما خلق عدم اليقين بشأن نقل البيانات من خوادم الاتحاد الأوروبي إلى الولايات المتحدة. التأثير العملي على علم البيانات: لا يمكن إرسال بيانات التدريب ذات الأصل الأوروبي إلى بنية ML المستندة إلى الولايات المتحدة (AWS US-East، GCP US-Central) بدون تدابير حماية نقل كافية.

تشمل تدابير الحماية الكافية:

• بنود تعاقدية قياسية (SCCs) مع تقييم تأثير النقل
• قواعد الشركات الملزمة (BCRs) للنقل داخل المجموعة
• استثناء للبيانات المخفية الهوية: البيانات المخفية الهوية بشكل صحيح ليست بيانات شخصية بموجب GDPR ولا تخضع لقيود النقل

بالنسبة للفرق التي تستخدم بنية ML المستندة إلى الولايات المتحدة مع بيانات ذات أصل أوروبي، فإن الإخفاء المناسب يلغي تمامًا مشكلة Schrems II. لم تعد مجموعة البيانات المخفية الهوية بيانات شخصية - يمكن نقلها وتخزينها ومعالجتها على أي بنية تحتية دون متطلبات آلية النقل.

الوثائق لموافقة DPO

عند تقديم بيانات التدريب المخفية الهوية إلى DPO للموافقة، قدم:

1. وصف بيانات المصدر: ما كانت مجموعة البيانات الأصلية، ما كان غرض جمعها، ما الفئات من البيانات الشخصية التي احتوتها؟

2. تكوين الإخفاء: ما أنواع الكيانات التي تم اكتشافها واستبدالها؟ ما الطريقة التي تم تطبيقها؟

3. بيانات المعالجة الوصفية: عدد الكيانات التي تم اكتشافها لكل سجل، درجات الثقة في الاكتشاف، إجمالي السجلات المعالجة

4. تقييم المخاطر المتبقية: ما احتمال أن يتم إعادة تحديد هوية أي فرد من مجموعة البيانات المخفية الهوية؟ بالنسبة للإخفاء بطريقة الاستبدال مع تطبيق 285+ نوع من الكيانات على نص منظم، فإن هذه الاحتمالية منخفضة جدًا لمعظم مجموعات بيانات التدريب.

5. الاستخدام المقصود: ما نموذج ML الذي سيتم تدريبه؟ ما هو غرض التدريب؟

توفر بيانات المعالجة الوصفية من معالجة الدفعات النقاط 2-3 تلقائيًا. تتطلب النقاط 1 و 4 و 5 مدخلات عالم البيانات.

الخاتمة

يمكن تحقيق بيانات تدريب ML المتوافقة مع GDPR دون سكربتات غير رسمية، ودون تأخيرات هندسية لعدة أيام، ودون التضحية بفائدة مجموعة البيانات لتدريب النموذج. تحافظ طريقة الإخفاء بالاستبدال على خصائص اللغة الطبيعية التي تجعل البيانات مفيدة لتدريب نموذج NLP بينما تزيل الخصائص الشخصية التي تخلق مسؤولية GDPR.

45 دقيقة من معالجة الدفعات هي الفرق بين مراجعة توافق تؤخر الجدول الزمني وموافقة DPO مباشرة.

المصادر:

• المواد 5 و 9 و 89 من GDPR: تحديد الغرض، بيانات الفئات الخاصة، واحتياطات البحث
• CJEU: Schrems II - نقل البيانات من الاتحاد الأوروبي إلى الولايات المتحدة
• مجلس حماية البيانات الأوروبي: إرشادات حول ML و GDPR