محرمانگی داده در پروژه هوش مصنوعی
بحث محرمانگی در پروژههای هوش مصنوعی معمولاً روی یک سؤال متوقف میشود: داده به سرویس بیرونی میرود یا نه؟ سؤال مهمی است و تنها سؤال نیست. داده از چند نقطه دیگر هم بیرون میرود که هیچکدام در قرارداد سرویس نوشته نشدهاند.
اول: نقشه جریان داده را بکشید
پیش از هر تصمیم فنی، روی کاغذ بیاورید که یک پرسش کاربر از کجا شروع میشود و به کجاها میرسد. در یک سامانه معمولی، این ایستگاهها وجود دارند:
مرورگر کاربر. سرور برنامه شما. لاگ سرور. سرویس تبدیل متن به بردار. پایگاه داده برداری. مدل زبانی. لاگ مدل. سامانه پایش و خطایاب. و پشتیبانگیریها.
هر ایستگاه، یک نقطه بالقوه نشت است. بیشتر تیمها فقط دربارهٔ یکی از اینها فکر میکنند.
نقاطی که معمولاً فراموش میشوند
لاگها. پرکاربردترین نشتی. اگر برای عیبیابی، متن پرسش و پاسخ را لاگ کنید، داده حساس در فایل لاگ مینشیند — جایی که معمولاً دسترسیاش بازتر از پایگاه داده است و مدت نگهداریاش هم مشخص نیست.
سرویس خطایاب. ابزارهای رصد خطا، محتوای درخواست را همراه خطا میفرستند. اگر سرویسشان بیرونی باشد، داده شما بدون اینکه کسی تصمیم گرفته باشد بیرون رفته.
سرویس تبدیل متن به بردار. تیمها روی مدل زبانی حساساند و این را نادیده میگیرند، در حالی که کل متن اسناد از این سرویس عبور میکند — نه فقط پرسشها. اگر مدل زبانی داخلی است ولی بردارسازی بیرونی، محرمانگی را حل نکردهاید.
تاریخچه گفتوگو. برای تجربه کاربری ذخیره میشود و کسی برایش سیاست حذف تعریف نکرده.
پشتیبانها. اگر داده حساس در پایگاه داده است، در پشتیبان هم هست — با همان عمر و اغلب با کنترل دسترسی کمتر.
دو چیزی که با هم اشتباه میشوند
پردازش یعنی داده برای تولید پاسخ استفاده شود و بعد دور ریخته شود. نگهداری و آموزش یعنی داده ذخیره شود و برای بهبود مدل به کار رود.
اینکه سرویسی داده را پردازش میکند، به این معنا نیست که نگهش میدارد؛ و برعکس. در ارزیابی هر سرویسی، این دو را جدا بپرسید — پاسخهایشان معمولاً متفاوت است و بند مربوط به آموزش، همان چیزی است که بیشتر سازمانها با آن مشکل دارند.
کاهش داده، مؤثرترین کنترل
سادهترین راه محافظت از داده، نفرستادنش است.
پاکسازی پیش از ارسال. اگر کاربرد شما به شماره ملی و شماره تماس نیاز ندارد، پیش از پردازش حذفشان کنید. برای متن فارسی، الگوهای شماره ملی، شبا، کد اقتصادی و شماره موبایل قابل تشخیص و جایگزینیاند.
جایگزینی برگشتپذیر. نامها با برچسب جایگزین شوند و پس از دریافت پاسخ دوباره سر جایشان بنشینند. مدل کار خودش را میکند بیآنکه نام واقعی را دیده باشد.
فرستادن قطعه بهجای سند. در RAG فقط بخش مرتبط سند همراه پرسش میرود، نه کل سند. این خودش یک کنترل محرمانگی است، نه فقط یک بهینهسازی.
سطح دسترسی باید در بازیابی باشد
این نکته فنی، مهمترین بند این مقاله است.
اگر سامانه ابتدا از همه اسناد بازیابی کند و بعد پاسخ را بر اساس دسترسی کاربر فیلتر کند، اطلاعات از منبع خارج شده و راههای نشتش قابل پیشبینی نیست — کافی است کاربر جور دیگری بپرسد.
راه درست این است که جستجو از ابتدا فقط در اسنادی انجام شود که این کاربر حق دیدنشان را دارد. این تصمیم معماری است و افزودنش بعداً یعنی بازنویسی لایه بازیابی. در دستیار دانش داخلی بازترش کردهایم.
بندهایی که در قرارداد باید باشند
اگر از سرویس بیرونی استفاده میکنید:
داده برای آموزش مدل استفاده میشود یا نه؟
چه مدت نگه داشته میشود و کجا؟
آیا امکان قرارداد بدون نگهداری وجود دارد؟
و کدام کارکنان ارائهدهنده به داده دسترسی دارند؟
و برای پیمانکار پروژه:
مالکیت داده و مدلهای تولیدشده با شماست؟
در پایان همکاری، چه چیزی و در چه بازهای حذف میشود؟
داده در محیط توسعه و تست از کجا میآید؟ استفاده از کپی داده واقعی در محیط تست، یکی از رایجترین راههای نشت است و کمترین توجه را میگیرد.
اگر پاسخ «هیچ دادهای نباید بیرون برود» است
آنوقت مسیر شما استقرار داخلی است — با این قید که همه اجزا باید داخلی باشند، نه فقط مدل زبانی. بردارسازی، پایگاه داده برداری، لاگ و پایش هم جزو زنجیرهاند.
این تصمیم باید پیش از شروع پیادهسازی گرفته شود. عوضکردنش در میانه راه، بازنویسی است نه تنظیم — و بدتر از آن، تا آن لحظه دادهای که نباید بیرون میرفت، رفته است.
یک تمرین ساده پیش از شروع
فهرست ایستگاههای ابتدای این مقاله را بردارید و برای پروژه خودتان پر کنید: در هر ایستگاه چه دادهای مینشیند، چقدر میماند، و چه کسی میتواند ببیندش.
اگر برای هر ردیف جواب روشنی ندارید، آن ردیف همان جایی است که ریسک شماست — نه جایی که بیشترین وقت را صرفش کردهاید.