پردازش اسناد حساس با مدلهای محلی، بدون رفتن داده به ابر
خلاصهٔ کاملتر
شروع مقاله با یه یادآوری سادهست: هر روز تیمها قرارداد، پروندهٔ منابع انسانی، فرم پزشکی و صورت مالی رو به ابزارهایی میفرستن که روی سرور راه دور پردازش میشن. برای خیلی از کاربردها اشکالی نداره، ولی وقتی سند دادهٔ شخصی یا اعتبارنامه یا دادهٔ مشمول HIPAA و GDPR داره، معادله عوض میشه. نویسنده چهار ریسک رو نام میبره: نگهداری ورودیها توسط ارائهدهنده، بزرگتر شدن سطح نشت، مسئولیت مقرراتی، و مهمتر از همه اشتراکگذاری تصادفی وقتی کاربر کل سند رو داخل یه چت میچسبونه.
قدم اول به گفتهٔ مقاله اینه که بدونی دنبال چی میگردی. دادهٔ شخصی رو سه دسته میکنه: شناسههای مستقیم مثل نام کامل، شمارهٔ ملی، تاریخ تولد، ایمیل و شمارهٔ حساب؛ شناسههای غیرمستقیم مثل IP، شناسهٔ دستگاه و دادهٔ مکانی که در ترکیب با بقیه هویت میسازن؛ و دستهٔ سومی که معمولاً تو بحث انطباق فراموش میشه، یعنی کلیدهای API، رمزهای جاسازیشده و رشتههای اتصال پایگاه داده.
برای انتخاب مدل محلی، سه معیار مطرح میشه. اول اندازهٔ پنجرهٔ متن، چون یه قرارداد بیستصفحهای تو پنجرهٔ ۴ هزار توکنی جا نمیشه؛ مدلهایی مثل Llama 3.1 و Mistral و Phi-3 پنجرههای بلندتری دارن. دوم پیروی از دستورالعمل، چون استخراج دادهٔ شخصی به رعایت دقیق یه اسکیمای مشخص وابستهست و نسخههای Instruct بهتر جواب میدن. سوم توازن سرعت و دقت: برای اسکن بلادرنگ، مدل ۸ تا ۱۳ میلیاردی روی یه GPU متعارف نقطهٔ تعادله و برای پردازش دستهای، مدل بزرگتر ارزش هزینهٔ محاسباتی رو داره. LM Studio برای توسعه و ارزیابی سریع پیشنهاد میشه و Ollama برای محیطهای سروری و بدون رابط گرافیکی.
خود خط لوله پنج مرحله داره. پیشپردازش برای بیرون کشیدن متن از PDF و DOCX و تصویر — با OCR وقتی سند اسکنشدهست — و حفظ فرادادههای ساختاری، چون دونستن اینکه یه مقدار زیر فیلد «تاریخ تولد» بوده یا «تاریخ قرارداد»، طبقهبندی بعدی رو دقیقتر میکنه. بعد تکهکردن سند به قطعات ۲ تا ۴ هزار توکنی با ۲۰۰ تا ۳۰۰ توکن همپوشانی، تا دادهٔ شخصیای که روی مرز دو قطعه افتاده از دست نره. بعد استخراج با مدل محلی و خروجی JSON با نوع، مقدار و آفست کاراکتر.
مرحلهٔ چهارم همون چیزیه که نویسنده بیشترین تأکید رو روش داره: اعتبارسنجی قاعدهمحور. مدلهای زبانی گاهی توهم میزنن یا الگوهای ساختاریافته رو رد میکنن، برای همین باید یه لایهٔ regex برای الگوهای پرقطعیت — شمارهٔ تأمین اجتماعی، ایمیل، کارت بانکی با اعتبارسنجی Luhn — رویش سوار بشه و نتیجهٔ دو روش با هم ادغام و یکتا بشه. مرحلهٔ آخر پوشاندنه، با سه گزینهٔ جایگزینی با برچسب نوع، ناممستعارسازی سازگار برای حفظ ساختار سند، و حذف کامل. برای اعتبارنامهها تأکید میکنه جایگزینی باید کامل باشه، چون یه کلید نیمهپوشانده هنوز یه کلیده.
نویسنده تشخیص اعتبارنامه رو یه مسئلهٔ جدا و جدی میدونه: مهندسها کلید API رو تو Confluence میچسبونن و تیم منابع انسانی فایل پیکربندی با رمز پایگاه داده ایمیل میکنه. پیشنهادش استفاده از ابزارهای آماده مثل detect-secrets و trufflehog بهجای ساخت کتابخانهٔ الگو از صفره. واکنش درست موقع پیدا شدن کلید هم اینه: رویداد رو با فراداده لاگ کن ولی هرگز خود مقدار کلید رو ننویس، مالک سند و تیم امنیت رو خبر کن، سند رو قرنطینه کن و پردازش خودکار رو متوقف کن — و کلید رو صرفنظر از اینکه نشتی رخ داده یا نه، بچرخون.
در بخش انطباق، مقاله یادآوری میکنه GDPR پردازش دادهٔ شخصی با هوش مصنوعی رو ممنوع نکرده؛ مبنای قانونی، کمینهسازی داده و تدابیر فنی میخواد، و پردازش محلی همون تدابیر فنی رو بهتر از مسیر ابری تأمین میکنه. HIPAA هم استاندارد Safe Harbor با ۱۸ شناسه داره که چالش اصلیش نرخ پوششه، نه پیدا کردن. SOC 2 هم فناوری خاصی رو الزام نمیکنه و دنبال جریان دادهٔ مستند، کنترل دسترسی و لاگ حسابرسیه.
نویسنده آخرش پنج اشتباه رایج رو میشمره: تکیه به مدل زبانی بهتنهایی؛ نادیده گرفتن فراداده که اغلب از خود متن سند دادهٔ شخصی بیشتری داره؛ فرض برگشتناپذیر بودن پوشاندن بدون راستیآزمایی؛ حذف کامل بازبینی انسانی؛ و بستن خط لوله به یه مدل خاص، در حالی که مدلهای باز سریع عوض میشن و مدل باید قابلتعویض بمونه.
نکات کلیدی:
- اجرای محلی مدل با LM Studio یا Ollama بیشتر ریسک خروج دادهٔ حساس رو حذف میکنه
- تشخیص باید هیبریدی باشه: مدل زبانی برای متن آزاد، regex و NER برای الگوهای ساختاریافته
- همپوشانی بین قطعهها جلوی از دست رفتن دادهٔ شخصی روی مرز قطعهها رو میگیره
- کلیدها و رمزهای داخل سند یه مسئلهٔ جداست؛ ابزار آماده بهتر از الگوی دستساز جواب میده
- فرادادههای PDF و DOCX اغلب نام و اطلاعات نویسنده رو لو میدن
- انطباق نتیجهٔ خط لولهست: کنترل دسترسی، لاگ، مستندسازی جریان داده و بازبینی انسانی




