حریم خصوصی قابل بازتولید: چرا تیمهای ML به پیشتنظیم نیاز دارند، نه فقط اسناد
مسئول حفاظت از داده طرح익명화 را تأیید کرده است. چهار مورد را پوشش میدهد: نامها، ایمیلها، شماره تلفنها و تاریخهای تولد. روش Replace است. طرح چهار صفحه است و در ویکی انطباق زندگی میکند.
دوازده دانشمند داده آن را در جلسه راهاندازی خواندند. هر کدام ابزار را به تنهایی تنظیم کردند. برخی شناسههای ملی اضافه کردند. برخی آدرسهای IP اضافه کردند. برخی به Redact تغییر دادند. سه ماه بعد، مجموعهها سازگار نیستند.
CNIL در سال ۲۰۲۴ چند شرکت هوش مصنوعی را بررسی کرد. موضوع: استفاده نادرست از جزئیات شخصی در مجموعههای مدل. آنها فقط نپرسیدند آیا익명화 اتفاق افتاده. پرسیدند چقدر به طور منسجم اعمال شده است.
اسناد لازم هستند. اما کافی نیستند. راهحل پیشتنظیم است.
چرا مجموعههای مدل ML پیکربندی خاص خود را نیاز دارند
ساخت مجموعههای مدل نیازهای منحصربهفردی دارد.익명화 سند عمومی آنها را به اشتراک نمیگذارد.
Replace، نه Redact. مدلهایی که روی متنی آموزش دیدهاند که نامها [REDACTED] میشوند این توکن را به عنوان نشانگر جایگاه نام یاد میگیرند. این به مدل آسیب میزند. Replace «John Smith» را با «David Chen» عوض میکند. مدل الگوهای نام واقعی را میبیند. توکن ماسک نمیبیند.
فرآیند یکسان برای همه رکوردها. مجموعهای که ۷۰٪ از نامها جایگزین شدهاند و ۳۰٪ [REDACTED] هستند سیگنال مختلط ارسال میکند. هر رکورد باید از همان مراحل عبور کند.
همان فهرست موجودیت. اگر مجموعه حاوی جزئیات بهداشتی باشد، حذف نامها اما باقی گذاشتن تاریخهای تولد در برخی رکوردها شکاف ایجاد میکند. همه دوازده دانشمند داده باید همان انواع را حذف کنند.
بدون حذف بیش از حد. برداشتن تاریخهایی که مهر زمانی هستند — نه تاریخهای تولد — کیفیت مجموعه را بدون هیچ دستاورد انطباقی کاهش میدهد. پیشتنظیم تأییدشده دقیقاً میگوید کدام موارد را حذف کنید.
خروجی قابل تکرار. اگر یک مجموعه باید دوباره اجرا شود — مثلاً پس از یافتن یک نوع موجودیت از دست رفته — پیشتنظیم هر بار همان نتیجه را میدهد. پیکربندیهای موقت این کار را نمیکنند.
مشکل دوازده دانشمند داده
یک تیم ML در شرکت فینتک اروپا از مجموعههایی از لاگهای مشتری استفاده میکند. مسئول حفاظت از داده هدف را تأیید کرده — تشخیص تقلب — با یک قانون: همه نامهای مشتری، ایمیلها، شماره تلفنها و شناسههای پرداخت قبل از شروع کار مدل باید جایگزین شوند.
بدون پیشتنظیم:
- نفر ۱ نامها، ایمیلها و شماره تلفنها را حذف میکند — اما شناسههای پرداخت را از دست میدهد
- نفر ۲ شناسههای پرداخت را قرار میدهد اما از Redact به جای Replace استفاده میکند
- نفر ۳ سند طرح را دقیقاً دنبال میکند
- نفرات ۴ تا ۱۲ متفاوتند
مجموعه ادغامشده تا حدی ناسازگار و تا حدی بیش از حد پردازششده است. مسئول حفاظت از داده نمیتواند آن را تأیید کند.
با پیشتنظیم تأییدشده توسط مسئول حفاظت از داده:
- مسئول حفاظت از داده «ML Dev — Fraud Detection» را با انواع موجودیت دقیق و روش Replace میسازد
- پیشتنظیم با یک قانون به همه دوازده نفر میرسد: از این برای همه کارهای مجموعه استفاده کنید
- هیچکس نمیتواند پیشتنظیم را بدون تأیید مسئول حفاظت از داده تغییر دهد
هر نفر حالا همان خروجی را تولید میکند. مجموعه ادغامشده منسجم است. حسابرسی سالانه هوش مصنوعی با صفر یافته قبول میشود. سال قبل سه یافته از کار مجموعه ناسازگار داشت.
GDPR و قانون هوش مصنوعی اتحادیه اروپا
بهروزرسانیشده برای ۲۰۲۶
قانون هوش مصنوعی اتحادیه اروپا در اوت ۲۰۲۴ به طور کامل اجرایی شد. قوانینی برای سیستمهای هوش مصنوعی که از جزئیات شخصی برای کار مدل استفاده میکنند اضافه میکند. سیستمهای هوش مصنوعی پرخطر باید مجموعههای خود، از جمله اینکه چه익명화 اعمال شده است، مستند کنند.
ماده ۵(۱)(b) GDPR — قانون محدودیت هدف — استفاده از جزئیات شخصی بدون مبنای قانونی روشن را ممنوع میکند. موارد CNIL در سال ۲۰۲۴ روی این شکاف تمرکز کرد: جزئیاتی که برای یک سرویس جمعآوری شده بودند و برای کار مدل بدون مبنا یا익명화 معتبر استفاده میشدند.
پیشتنظیمها به رضایت هر دو مجموعه قانون کمک میکنند:
- نام و پیکربندی پیشتنظیم: روش مستند
- لاگهای پردازش: اثبات اعمال روش
- تأیید مسئول حفاظت از داده: تأیید ثبتشده روی پیکربندی
این مسیر حسابرسی را که هر دو قانون الزامی میکنند ایجاد میکند. برای تعهدات ماده ۱۰ به طور مفصل، به راهنمای دادههای آموزشی قانون هوش مصنوعی اتحادیه اروپا مراجعه کنید.
پیکربندی پیشتنظیم برای مجموعههای مدل NLP
انواعی که باید در بیشتر مجموعههای مدل NLP قرار داشته باشند:
- PERSON — با نامهای مشابه جایگزین کنید
- EMAIL_ADDRESS — با آدرسهای مصنوعی جایگزین کنید
- PHONE_NUMBER — با شمارههای مصنوعی جایگزین کنید
- CREDIT_CARD / IBAN — جایگزین یا ویرایش کنید
- LOCATION — اگر مکان مهم است با مکانهای مشابه جایگزین کنید؛ اگر نیست ویرایش کنید
- DATE_OF_BIRTH — ویرایش کنید؛ اغلب به گروهبندی سنی نیاز است
انواعی که اغلب حذف میشوند:
- تاریخهای عمومی — مهرهای زمانی به مدلهای زمانی کمک میکنند
- نامهای سازمان — به مدلهای موجودیت نامگذاریشده کمک میکنند
- URLها — به مدلهای لینک و مرجع کمک میکنند
سرپرست ML و مسئول حفاظت از داده این قوانین را در پیشتنظیم تأییدشده تنظیم میکنند. اعضای تیم آن را اعمال میکنند. آنها انتخابهای پیکربندی نمیکنند.
پیشتنظیمها به عنوان حافظه نهادی
قبل از پیشتنظیم. پیکربندی موجودیت صحیح در ذهن سه دانشمند داده بود. آنها از بررسی انطباق عبور کرده بودند. دو نفر در فصل سوم رفتند. دانش با آنها رفت.
بعد از پیشتنظیم. پیکربندی در «ML Dev — Customer Records v2.1» زندگی میکند. لاگ نسخه نشان میدهد چه زمانی ساخته شده، چه کسی آن را تأیید کرده و چه چیزی از v2.0 تغییر کرده. اعضای جدید تیم پیشتنظیم را استفاده میکنند و همه دانش ساختهشده در آن را میگیرند.
نسخه ۲.۱ شناسایی IBAN را پس از یافتن آن در یک بررسی اضافه کرد. نسخه ۲.۰ در فوریه ۲۰۲۵ تأیید شد. لاگ کامل است.
برای نحوه کار لاگهای پردازش و جریانهای بررسی مسئول حفاظت از داده، به راهنمای익명화 دادههای آموزشی ML سازگار با GDPR مراجعه کنید.
پیشتنظیمها در مقابل الگوی CNIL
موارد هوش مصنوعی CNIL در سال ۲۰۲۴ یک الگوی روشن تعیین کردند. آنها نه فقط از آنچه حذف شده، بلکه از نحوه حاکمیت آن میپرسند. یک پیشتنظیم مشترک با یک رکورد تأیید مسئول حفاظت از داده و لاگهای پردازش مستقیماً به این پاسخ میدهد.
یک پیکربندی موقت این کار را نمیکند. همان شکاف در سایر موارد DPA اتحادیه اروپا که از منطق CNIL پیروی میکنند وجود دارد. برای اطلاعات بیشتر در مورد رویکرد هوش مصنوعی CNIL، به راهنمای انطباق هوش مصنوعی GDPR فرانسه مراجعه کنید.
نتیجهگیری
اسناد به اعضای تیم میگویند چه کاری انجام دهند. پیشتنظیمها آن را هر بار به همان شکل انجام دادن را آسان — و قابل اجرا — میکنند.
برای مجموعههای مدل ML، سازگاری هم یک نیاز قانونی و هم یک نیاز فنی است. پیشتنظیم هر دو را به طور همزمان برآورده میکند.
DPAهایی که به رویههای هوش مصنوعی نگاه میکنند خواهان شواهد익명화 یکنواخت هستند. یک پیشتنظیم که به همان شکل در سراسر تمام کار مجموعه اعمال میشود واضحترین مدرکی است که میتوانید بدهید.