در دنیای قراردادهای سازمانی، تامین‌کنندگان AI اغلب وعده می‌دهند که داده‌های مشتری در محیط ایزوله (Tenant) باقی می‌ماند و تنها به‌روزرسانی‌های مدل که با استفاده از Differential Privacy (حریم خصوصی تفاضلی) محافظت شده‌اند، به اشتراک گذاشته می‌شوند. در این قراردادها، تضمین حریم خصوصی معمولاً با یک عدد ساده به عنوان «بودجه حریم خصوصی» (Privacy Budget) در قالب پارامترهای epsilon و delta بیان می‌شود. اما مشکل اینجاست که یک عدد به تنهایی ثابت نمی‌کند که مدل واقعاً با آن سطح از حریم خصوصی آموزش دیده است.
شکاف بین ادعاهای قراردادی و واقعیت فنی
هدف حریم خصوصی پیش از شروع آموزش تعیین می‌شود، اما میزان «از دست دادن حریم خصوصی» (Privacy Loss) به عوامل متعددی بستگی دارد: تعداد دورهای آموزش (Rounds)، روش نمونه‌برداری از شرکت‌کنندگان، پارامترهای Clipping و مقدار نویز اضافه شده. اگر این موارد به هم مرتبط نباشند، یک تامین‌کننده می‌تواند عددی را در قرارداد ذکر کند که هیچ ارتباطی به فرآیند واقعی آموزش مدل منتشر شده ندارد.
نقاط ضعف کلیدی در پیاده‌سازی‌های فعلی
- ناپایداری در سطح Tenant: مقدار epsilon 3.0 به تنهایی مشخص نمی‌کند که واحد مورد حفاظت یک رکورد است، یک کاربر یا کل یک Tenant. در سیستم‌های سازمانی، تفاوت بین حریم خصوصی در سطح رکورد و سطح Tenant بسیار حیاتی است.
- ضعف در مدیریت دسترسی (Cohort Selection): استفاده از Secure Aggregation مانع از خواندن مستقیم به‌روزرسانی‌ها توسط سرویس تجمیع می‌شود، اما تضمینی برای امنیت گروه شرکت‌کنندگان (Cohort) نمی‌دهد. اگر هماهنگ‌کننده (Coordinator) مخرب باشد، می‌تواند با حملات Sybil، حریم خصوصی شرکت‌کنندگان را به خطر بیندازد.
- تأثیر ماندگار داده‌ها: حذف داده‌ها یا لاگ‌ها، تأثیر به‌روزرسانی‌های قبلی را از مدل حذف نمی‌کند. اینجاست که مفهوم Federated Unlearning اهمیت می‌یابد؛ زیرا حذف ساده داده‌ها پاسخ کاملی به درخواست‌های قانونی حذف اطلاعات نیست.
راهکار: درخواست «سند انتشار حریم خصوصی» (Privacy Release Record)
برای اطمینان از صحت ادعاهای تامین‌کننده، مدیران امنیت و CISOها نباید تنها به اعداد قراردادی اکتفا کنند. آن‌ها باید درخواست سندی کنند که لینک مستقیمی بین «عدد بودجه» و «اجرای واقعی مدل» (Run) برقرار کند. در یک سیستم با سطح اطمینان بالا، این سند باید توسط یک Privacy Accountant (حسابدار حریم خصوصی) در مسیر انتشار مدل تولید شود، نه اینکه پس از درخواست مشتری به صورت دستی آماده گردد.
نتیجه‌گیری: بودجه حریم خصوصی نباید صرفاً یک مقدار قابل مذاکره در قرارداد باشد، بلکه باید یک Runtime Invariant باشد که شواهد فنی قابل استناد از خود به جای بگذارد.
