ناشناس‌سازی داده‌های آموزشی ML مطابق 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 شکست می‌خورد.

شکاف بین «ایمیل‌ها را ناشناس کردم» و «این مجموعه داده با GDPR مطابقت دارد» بزرگ است. تیم‌ها همیشه آن را دست کم می‌گیرند.

چرا GDPR استفاده آموزش ML را محدود می‌کند

ماده ۵(۱)(ب) GDPR قانون کلیدی است. اصل محدودیت هدف نام دارد. سوابق شخصی فقط برای هدفی که برای آن جمع‌آوری شده‌اند قابل استفاده‌اند.

سفارشات مشتریان برای پردازش سفارش جمع‌آوری شده‌اند. نه برای آموزش مدل توصیه. سوابق سلامتی برای درمان جمع‌آوری شده‌اند. نه برای آموزش مدل پیش‌بینی بستری مجدد. پاسخ‌های نظرسنجی برای بازخورد محصول جمع‌آوری شده‌اند. نه برای آموزش طبقه‌بند احساسات.

برای استفاده از آن سوابق در آموزش ML، یک تیم به یکی از سه چیز نیاز دارد:

1. رضایت صریح هر فرد برای هدف ML — دشوار برای دریافت، اغلب به صورت گذشته‌نگر غیرممکن
2. ارزیابی منافع مشروع که نشان دهد استفاده ML سازگار است — از نظر حقوقی نامشخص، وابسته به DPA
3. ناشناس‌سازی — جایگزینی یا حذف جزئیات شخصی تا مجموعه داده دیگر تحت GDPR شخصی نباشد

ناشناس‌سازی صحیح بیشترین اطمینان قانونی را می‌دهد. چالش این است که هر بار آن را درست انجام دهیم.

مشکل اسکریپت‌های یک‌بار مصرف

تیم‌هایی که برای هر مجموعه داده اسکریپت پایتون جدید می‌نویسند، مشکلات مرکب ایجاد می‌کنند.

پوشش ناقص. اسکریپتی که برای یک طرح ساخته شده، فیلدهای جدید را نادیده می‌گیرد. ستون یادداشت‌های بالینی اضافه شده شش ماه پیش؟ در regex نیست. فیلد نام میانی؟ اسکریپت فقط الگوهای نام و نام خانوادگی را مدیریت می‌کند.

بدون ثبات. مجموعه داده A با script_v1 پردازش شد. مجموعه داده B از script_v3 استفاده کرد. مجموعه داده C توسط عضو تیم دیگری پردازش شد. مجموعه آموزشی ادغام‌شده سه روش مختلف دارد. یک DPO نمی‌تواند آن را تأیید کند.

بدون رد حسابرسی. اسکریپت اجرا شد. چه چیزی تغییر داد؟ کدام موجودیت‌ها پیدا شدند؟ بدون سوابق پردازش، انطباق غیرممکن است. وقتی حسابرس DPA می‌پرسد «چطور می‌دانید این مجموعه آموزشی تمیز است؟»، پاسخ «اسکریپت پایتون اجرا کردیم» کافی نیست.

انحراف مدل. الگوهای regex که در ۲۰۲۳ کار می‌کردند، فرمت‌های شناسه جدید ۲۰۲۴ را از دست می‌دهند. اسکریپت‌ها خودشان به‌روزرسانی نمی‌شوند.

پیاده‌سازی پردازش دسته‌ای

یک تیم هوش مصنوعی بهداشتی نیاز دارد ۸٬۰۰۰ پرونده بیمار را ناشناس کند. تیم آمریکایی نیاز به دسترسی از دفتر اروپایی دارد. Schrems II اعمال می‌شود — سوابق با منشأ اروپایی بدون تضمین‌های مناسب به زیرساخت آمریکایی نمی‌توانند بروند.

مسیر سنتی: یک مهندس داده اسکریپت سفارشی می‌نویسد. دو تا سه روز توسعه. یک تا دو روز بررسی DPO. یک روز تکرار. مجموع: چهار تا شش روز. پروژه ML به تأخیر می‌افتد.

مسیر پردازش دسته‌ای:

1. ۸٬۰۰۰ رکورد را به عنوان CSV صادر کنید
2. برای پردازش دسته‌ای آپلود کنید
3. نوع موجودیت‌ها را تنظیم کنید: PERSON، EMAIL_ADDRESS، PHONE_NUMBER، US_SSN، MEDICAL_RECORD، DATE_OF_BIRTH، LOCATION
4. روش را انتخاب کنید: Replace (مقادیر مصنوعی واقعی را جایگزین می‌کند تا ساختار حفظ شود)
5. پردازش: ۴۵ دقیقه برای ۸٬۰۰۰ رکورد
6. CSV تمیز را دانلود کنید
7. DPO متادیتای پردازش را بررسی می‌کند: ۲ ساعت
8. DPO تأیید می‌کند. انتقال انجام می‌شود.

زمان کل: ۴۵ دقیقه به علاوه ۲ ساعت بررسی DPO. به جای چهار تا شش روز.

برای آموزش اقدامات EU AI Act، راهنمای آموزش EU AI Act را ببینید.

Replace در مقابل Redact برای استفاده ML

روش ناشناس‌سازی برای کیفیت مدل اهمیت دارد.

Redact PII را با توکنی مانند [REDACTED] جایگزین می‌کند. این برای مدل‌های تشخیص PII کار می‌کند. برای سایر وظایف — احساسات، طبقه‌بندی، توصیه — ضرر می‌زند.

Replace «John Smith» را با «David Chen» جایگزین می‌کند. «jsmith@company.com» را با «dchen@synthetic.com» جایگزین می‌کند. ساختار سالم می‌ماند. مدل از زمینه واقعی یاد می‌گیرد.

برای مجموعه‌های آموزشی ML، Replace انتخاب درست است. مدل مقادیر جعلی را یاد نمی‌گیرد. الگوهای اطراف آنها را یاد می‌گیرد. این چیزی است که اهمیت دارد.

Schrems II و انتقال‌های فرامرزی

حکم Schrems II (CJEU، ۲۰۲۰) سپر حریم خصوصی EU-US را باطل کرد. سوابق با منشأ اروپایی نمی‌توانند بدون تضمین‌های انتقال مناسب به زیرساخت ML آمریکایی بروند.

سه تضمین اصلی عبارتند از:

• بندهای قراردادی استاندارد با ارزیابی تأثیر انتقال
• قوانین شرکتی الزام‌آور برای انتقال‌های درون گروه شرکتی
• معافیت برای سوابق ناشناس — فایل‌های ناشناس‌سازی‌شده دیگر تحت GDPR شخصی نیستند و از قوانین انتقال معاف هستند

برای تیم‌هایی که از زیرساخت آمریکایی با مجموعه‌های با منشأ اروپایی استفاده می‌کنند، ناشناس‌سازی صحیح مشکل Schrems II را حذف می‌کند. مجموعه داده تمیز شخصی نیست. می‌تواند آزادانه جابجا شود.

آنچه به DPO می‌دهید

هنگام ارسال مجموعه آموزشی تمیز برای تأیید DPO، این پنج مورد را وارد کنید:

1. توضیح منبع. مجموعه داده اصلی چه بود؟ هدف جمع‌آوری چه بود؟ چه دسته‌های شخصی داشت؟
2. پیکربندی ناشناس‌سازی. کدام نوع موجودیت‌ها تشخیص داده و جایگزین شدند؟ چه روشی اعمال شد؟
3. متادیتای پردازش. تعداد موجودیت‌ها در هر رکورد، امتیازات اطمینان، کل رکوردهای پردازش‌شده.
4. ارزیابی ریسک باقی‌مانده. چه احتمالی وجود دارد که هر فردی دوباره شناسایی شود؟
5. استفاده مورد نظر. چه مدلی آموزش خواهد دید؟ هدف آموزش چیست؟

پردازش دسته‌ای موارد ۲ و ۳ را به صورت خودکار ارائه می‌دهد. موارد ۱، ۴، و ۵ از دانشمند داده می‌آیند.

آنچه به دست می‌آورید

مجموعه‌های ML مطابق GDPR بدون اسکریپت‌های سفارشی، بدون تأخیرهای چند روزه، و بدون از دست دادن کیفیت مدل قابل دستیابی هستند.

روش Replace خصوصیات زبان طبیعی مهم برای آموزش NLP را حفظ می‌کند. جزئیات شخصی که ریسک GDPR ایجاد می‌کنند را حذف می‌کند.

۴۵ دقیقه پردازش دسته‌ای تفاوت بین بررسی انطباق تأخیرافتاده و تأیید ساده DPO است.

منابع

• مواد GDPR ۵، ۹، ۸۹: محدودیت هدف، دسته‌های ویژه سوابق، و تضمین‌های تحقیقاتی
• CJEU: Schrems II — انتقال از EU به آمریکا
• هیئت حفاظت از داده‌های اروپایی: دستورالعمل‌های ML و GDPR