ماسک‌گذاری اطلاعات حساس در صندوق پیام مشترک هوش مصنوعی

ماسک‌گذاری خودکار داده‌ها با فیلتر کردن اطلاعات هویتی و مالی پیش از ذخیره‌سازی یا ارسال به مدل‌های زبانی، مانع از افشای ناخواسته داده‌های کاربران در محیط‌های اشتراکی پشتیبانی می‌شود. این فرایند با جایگزینی مقادیر حساسی مثل شماره کارت، کد ملی یا شماره تماس با برچسب‌های خنثی، ریسک دسترسی افراد غیرمجاز یا ثبت اطلاعات محرمانه در لاگ‌های خارجی را به حداقل می‌رساند. انتخاب رویکرد مناسب به موازنه میان سرعت پاسخ‌دهی، پیچیدگی استقرار فنی و میزان درک مدل از متن پیام بستگی دارد.

حساسیت داده‌ها در تعامل هم‌زمان انسان و هوش مصنوعی

وقتی یک مشتری در دایرکت اینستاگرام یا ویجت چت وب‌سایت پیامی ارسال می‌کند، متن پیام مستقیماً وارد چرخه‌ای می‌شود که چندین بازیگر دارد: مدل هوش مصنوعی پردازش‌کننده، پایگاه داده ذخیره‌ساز پیام‌ها، و کارشناسان پشتیبانی انسانی که در اینباکس مشترک مشغول بررسی گفتگوها هستند. اطلاعات مبادله‌شده معمولاً شامل دو دسته داده است:

۱. داده‌های ساختاریافته: الگوهای عددی ثابت دارند؛ مانند شماره کارت بانکی (۱۶ رقم)، کد ملی (۱۰ رقم) و شماره تلفن همراه (۱۱ رقم با پیش‌شماره‌های مشخص). شناسایی این داده‌ها از نظر الگوریتمی سرراست است، اما نادیده گرفتن ارقام فارسی یا وجود خط تیره و فاصله میان اعداد می‌تواند الگوریتم‌ها را با خطا مواجه کند.

۲. داده‌های نیمه‌ساختاریافته و وابسته به متن: مواردی نظیر نام مشتری، نام شهر، آدرس پستی، جزئیات بیماری (در سناریوی کلینیک‌ها) یا نام کاربری. این اطلاعات قالب ثابتی ندارند و جداسازی آن‌ها از متن پیام نیازمند درک نحو زبان فارسی است.

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

معماری سه گزینه اصلی ماسک‌گذاری داده‌ها

برای ایمن‌سازی پیام‌ها پیش از ورود به مدل هوش مصنوعی و صندوق پیام، سه رویکرد اصلی در لایه میانی (Middleware) وجود دارد که هرکدام محل قرارگیری متفاوتی در معماری نرم‌افزار دارند:

۱. قوانین مبتنی بر عبارات باقاعده (Regex Engine)

ساده‌ترین و سبک‌ترین روش، اجرای مجموعه‌ای از الگوهای منظم در لایه دریافت پیام است. این اسکریپت پیش از ثبت داده در دیتابیس یا ارسال متن به مدل، توالی‌های عددی خاص را بررسی می‌کند. برای مثال، تابعی بر پایه الگوریتم Luhn می‌تواند بررسی کند که آیا یک عدد ۱۶ رقمی ورودی، شماره کارت معتبر بانکی است یا صرفاً یک کد رهگیری پستی، و سپس آن را با متنی مانند [MASKED_CARD] جایگزین سازد.

۲. مدل‌های بومی تشخیص موجودیت نام‌دار (Local NER Models)

در این رویکرد، پیام ابتدا از یک مدل کوچک پردازش زبان طبیعی عبور داده می‌شود که برای زبان فارسی بازتنظیم شده است. این مدل‌ها به جای اتکا به قالب کاراکترها، نقش گرامری و جایگاه واژه در جمله را تحلیل می‌کنند تا اسامی اشخاص، آدرس‌ها و اصطلاحات خاص را حتی در صورت وجود غلط‌های املایی یا محاوره‌نویسی استخراج و ماسک‌گذاری کنند.

۳. پراکسی‌های اختصاصی پیشگیری از نشت داده (DLP Proxies)

پراکسی‌های امنیتی مانند نرم‌افزارهای مدیریت حریم خصوصی متن‌باز (نظیر Presidio)، سرورهای واسطی هستند که میان نرم‌افزار کسب‌وکار و ارائه‌دهنده سرویس هوش مصنوعی قرار می‌گیرند. این ابزارها ترکیبی از قوانین Regex، مدل‌های سبک یادگیری ماشین و تحلیل سیاستی را اعمال می‌کنند و وظیفه دارند متن را قبل از ارسال به API بیرونی تصفیه کرده و در صورت لزوم، در مسیر بازگشت پاسخ، داده‌های مورد نیاز را بازنشانی کنند.

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

مقایسه تحلیلی گزینه‌های ماسک‌گذاری

انتخاب هریک از این روش‌ها نیازمند بررسی موازنه میان کارایی و پیچیدگی پیاده‌سازی است:

معیار ارزیابی	عبارات باقاعده (Regex)	مدل‌های محلی پردازش زبان (NER)	پراکسی‌های واسط (DLP Engine)
پیچیدگی پیاده‌سازی	بسیار کم؛ قابل نگارش در چند خط کد	بالا؛ نیازمند آماده‌سازی داده و نگهداری مدل	متوسط رو به بالا؛ نیازمند مدیریت زیرساخت سرور جداگانه
تأخیر در پردازش (Latency)	کمتر از چند میلی‌ثانیه	بین ۵۰ تا ۳۰۰ میلی‌ثانیه به ازای هر پیام	بین ۱۰۰ تا ۵۰۰ میلی‌ثانیه بر حسب پیچیدگی فیلترها
هزینه زیرساخت سخت‌افزاری	ناچیز (روی سرور فعلی برنامه اجرا می‌شود)	نیازمند منابع حافظه (RAM) یا پردازنده گرافیکی (GPU)	نیازمند سرور مجزا برای مدیریت لایه پراکسی
خطای مثبت کاذب (Over-masking)	متوسط (ممکن است کد سفارش را به جای کارت بشناسد)	کم در تشخیص بافت، اما وابسته به کیفیت داده آموزش	کم تا متوسط، به دلیل امکان استفاده از چند لایه اعتبارسنجی
پوشش متن و زبان فارسی	ضعیف در درک آدرس و اسامی؛ عالی در اعداد	بسیار خوب در صورت آموزش روی داده‌های فارسی	وابسته به پشتیبانی اجزای داخلی از زبان فارسی

چالش بازگشت‌پذیری و حفظ درک معنایی ایجنت

یکی از مهم‌ترین تصمیم‌های فنی این است که آیا ماسک‌گذاری باید قطعی (Redaction) باشد یا موقت (Tokenization/Pseudonymization):

• حذف قطعی با کاراکترهای عمومی: اگر پیام ورودی مشتری به صورت سلام، هزینه را به ۶۰۳۷۹۹۱۱... زدم و آدرسم میدان ونک پلاک ۱۰ است دریافت شود، تبدیل آن به سلام، هزینه را به *** زدم و آدرسم *** است اگرچه حریم خصوصی را حفظ می‌کند، اما زمینه معنایی را از ایجنت می‌گیرد. مدل ممکن است متوجه نشود که بخش دوم، آدرس فیزیکی برای ارسال کالا است.
• توکن‌سازی با برچسب‌های معنایی: روش بهینه این است که داده‌ها با توکن‌های تایپ‌شده جایگزین شوند: سلام، هزینه را به [CARD_NUMBER_1] زدم و آدرسم [STREET_ADDRESS_1] است. در این حالت، ایجنت هوش مصنوعی متوجه ساختار جمله و خواسته‌ی مشتری می‌شود و پاسخی منطقی تولید می‌کند (برای مثال: «رسید شما دریافت شد، مرسوله به نشانی ثبت‌شده ارسال خواهد شد»).

در سناریویی فرضی، فرض کنید در یک فروشگاه آنلاین، مشتری پیام ارسال می‌کند که واریز را انجام داده و شماره پیگیری می‌دهد. اگر لایه ماسک‌گذاری شماره تراکنش معتبر را به دلیل اشتباه الگوریتمی فیلتر کند، ایجنت متوجه وجود کد پیگیری در متن نخواهد شد و مرتباً از مشتری درخواست ارسال مجدد کد می‌کند؛ خطایی که مستقیماً باعث توقف روند پاسخ‌گویی خودکار می‌شود.

چه زمانی این راهکار مناسب نیست و چه مشکلاتی را حل نمی‌کند؟

ماسک‌گذاری خودکار داده‌ها راه‌حلی برای تمام سناریوهای پشتیبانی نیست و پیاده‌سازی شتاب‌زده آن ممکن است چالش‌های تازه‌ای ایجاد کند:

• درخواست‌های پشتیبانی نیازمند داده دقیق: در فرآیندهای مالی یا احراز هویت که اپراتور یا ایجنت حتماً باید صحت کدملی یا ارقام تراکنش را در سیستم حسابداری استعلام کند، ماسک‌گذاری کامل پیام مانع از انجام کار می‌شود. در چنین شرایطی، به‌جای متن باز دایرکت یا چت، باید فرآیند احراز به درگاه‌های امن وب منتقل شود.
• مکالمات صوتی یا تصاویر فیش‌های واریزی: ابزارهای ماسک‌گذاری متنی هیچ کمکی به فایل‌های تصویری ارسالی در پیام‌رسان‌ها (نظیر اسکرین‌شات رسید همراه با شماره کارت) نمی‌کنند. محافظت از این تصاویر نیازمند خط لوله مجزای بینایی ماشین (OCR Redaction) است که بار پردازشی و هزینه بسیار بالاتری دارد.
• جبران ضعف کنترل دسترسی داخلی: ماسک‌گذاری جایگزین تفکیک سطح دسترسی پرسنل نیست. اگر کارشناس صندوق پیام به کل پایگاه داده دسترسی مستقیم داشته باشد، ماسک کردن متن در رابط کاربری لایه چت کارکرد حفاظتی واقعی نخواهد داشت.

چارچوب تصمیم‌گیری گام‌به‌گام برای کسب‌وکارها

برای انتخاب روش مناسب، می‌توانید این سه مرحله اجرایی را مبنا قرار دهید:

۱. بررسی داده‌های ردوبدل‌شده: نوع متداول داده‌هایی که مشتریان شما ارسال می‌کنند چیست؟ اگر مکالمات شما صرفاً شامل شماره سفارش و شماره موبایل است، استفاده از مدل‌های سنگین پردازش زبان توجیه فنی و اقتصادی ندارد. یک موتور اعتبارسنجی Regex با تبدیل اعداد فارسی به انگلیسی نیاز شما را با کمترین تأخیر برطرف می‌کند. ۲. بررسی حجم مکالمات و منابع سرور: اگر روزانه هزاران پیام در کانال‌های مختلف مانند بله، تلگرام و وب‌سایت دریافت می‌کنید، استفاده از مدل‌های محلی پردازش زبان بدون تجهیزات سخت‌افزاری اختصاصی باعث کندی شدید در ارسال پیام‌ها به صندوق خواهد شد. در حجم بالا، تفکیک پردازش‌ها با کمک صف‌های پیام (Message Queue) ضرورت پیدا می‌کند. ۳. تنظیم سطح دسترسی در تحویل به انسان: اطمینان حاصل کنید که در صورت فعال بودن سناریوی ارجاع گفتگو به اپراتور انسانی، داده‌های محرمانه فقط برای افراد دارای مجوز بازگشایی شوند و لاگ عملیات بازبینی داده ثبت گردد.

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

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

رایگان امتحان کنید