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

اگر امروز عامل‌های هوش مصنوعی خود را به پایگاه‌داده یا ایمیل‌های مشتریان متصل کرده‌اید، احتمالاً در هر ثانیه در حال نشت داده‌های حساس به سرورهای شرکت‌های ثالث هستید. این اتفاق زمانی رخ می‌دهد که عامل‌ها برای خواندن یک ایمیل یا پرس‌وجو از یک پایگاه‌داده، اطلاعات را به APIهای خارجی ارسال می‌کنند. این تنش بین کاربردی بودن و امنیت، در ۲۹ سپتامبر ۲۰۲۶ در یک راهنمای فنی منتشر شده در وب‌سایت dev.to برجسته شد. این گزارش یک آسیب‌پذیری حیاتی در نحوه مدیریت خروجی ابزارها توسط عامل‌ها شناسایی کرده است؛ جایی که داده‌های حساسی مثل شماره تلفن و شناسه‌های ملی بدون بازبینی انسانی، به‌طور خودکار و مستقیم وارد پرامپت‌ها می‌شوند.

این ریسک امنیتی زمانی بحرانی می‌شود که عامل‌ها از چت‌بات‌های ساده به سیستم‌های «همیشه فعال» (Always-on) تبدیل شوند که به‌طور خودکار لاگ‌ها و تیکت‌ها را پردازش می‌کنند. این موضوع در واقع تکمله‌ای بر چالش‌های دسترسی‌های گسترده API در عامل‌هاست که می‌تواند حفره‌های امنیتی جبران‌ناپذیری ایجاد کند. همان‌طور که در تحلیل قبلی ما درباره‌ی پروفایل‌های استنتاج (Inference Profiles) و تمرکز بر کاهش توکن‌های ورودی اشاره کردیم، صنعت اکنون با بحرانی موازی روبروست: هزینه قانونی و امنیتی توکن‌هایی که حاوی اطلاعات شناسایی شخصی (PII) هستند. برای مثال در ویتنام، اجرای فرمان Decree 13/2023/NĐ-CP و قانون حفاظت از داده‌های شخصی (که از ۱ ژانویه ۲۰۲۶ اجرایی شده است)، انتقال کنترل‌نشده داده‌ها به خارج از مرزها را به یک مسئولیت قانونی ملموس و جدی تبدیل کرده است.

معماری لایه حذف داده

برای حل این مشکل، سیستمی پیشنهاد شده که یک لایه حذف (Redaction Layer) بین منبع داده و API مدل زبانی بزرگ (LLM) قرار می‌دهد. این لایه شبیه به یک فیلتر هوشمند است که کلمات ممنوعه را پیش از رسیدن به مقصد سانسور می‌کند. برخلاف روش‌های ساده که داده را با برچسب‌های کلی مثل [REDACTED] می‌پوشانند — که باعث می‌شود مدل زبانی زمینه (Context) لازم برای پاسخ‌دهی را از دست بدهد — این سیستم از یک فرآیند توکن‌سازی بازگشت‌پذیر استفاده می‌کند:

• تشخیص: سیستم از کتابخانه متن‌باز Microsoft Presidio برای شناسایی اطلاعات شناسایی شخصی (PII) استفاده می‌کند.
• شناسگرهای سفارشی: از آنجایی که مدل‌های پیش‌فرض اغلب داده‌های منطقه‌ای را نادیده می‌گیرند، نویسنده الگوهای Regex سفارشی برای شناسه‌های ملی ویتنام (CCCD) و شماره تلفن‌ها اضافه کرده است.
• گاوصندوق (Vault): یک حافظه محلی و نشست‌محور (Session-based)، نقشه‌ی تبدیل مقدار واقعی (مثلاً "۰۹۱۲۳۴۵۶۷۸") به یک توکن پایدار و منحصربه‌فرد (مثلاً "") را ذخیره می‌کند.

پیاده‌سازی و جریان داده

بر اساس مستندات این راهنما، جریان داده به‌صورت سخت‌گیرانه مدیریت می‌شود: داده‌ها پیش از ارسال به مدل حذف می‌شوند و پاسخ مدل پیش از رسیدن به کاربر نهایی یا یک ابزار، از طریق گاوصندوق «بازسازی» (Restore) می‌شود. این ساختار تضمین می‌کند که مدل زبانی نوع داده‌ای که با آن سروکار دارد را می‌فهمد، اما هرگز مقدار واقعی و حساس آن را نمی‌بیند.

در عامل‌هایی که از فراخوانی تابع (Tool Calling) استفاده می‌کنند، نقطه نشت داده به‌ندرت ورودی کاربر است، بلکه معمولاً خروجی ابزار (Tool Output) است. این آسیب‌پذیری در کنار ضعف عامل‌ها در برابر تزریق پرامپت که توسط OmniTool Hub افشا شد، لزوم ایجاد لایه‌های حفاظتی سخت‌گیرانه را دوچندان می‌کند. راهکار پیشنهادی، استفاده از یک تابع پوشاننده (Wrapper) است؛ به گونه‌ای که هر آرگومانی که به یک ابزار پاس داده می‌شود ابتدا بازسازی شود و هر خروجی که از ابزار بازگردانده می‌شود، پیش از ارسال به مدل، حذف (Redact) گردد.

چالش‌های عملیاتی و بهینه‌سازی

پیاده‌سازی این لایه چندین چالش عملی را آشکار می‌کند. مدل‌های استاندارد NER مانند en_core_web_lg در شناسایی نام‌های خاص (مثلاً نام‌های ویتنامی) دچار مشکل می‌شوند. برای رفع این نقص، نیاز است لیست‌های نام خانوادگی رایج و الگوهای Regex برای خوشه‌های کلمات با حروف بزرگ به سیستم اضافه شود.

مشکل «مثبت کاذب» (False Positives) نیز یک مانع جدی است. برای مثال، یک کد سفارش ۱۲ رقمی که با عدد ۰ شروع می‌شود، ممکن است به‌اشتباه به عنوان شناسه ملی شناسایی شود. نویسنده توصیه می‌کند امتیاز پایه (Base Score) را به ۰.۴ کاهش دهید تا تنها تطابق‌هایی که زمینه محیطی قوی دارند (مثلاً وجود کلمه "CCCD" در کنار عدد) باعث فعال شدن حذف داده شوند.

همچنین برای جلوگیری از توهم (Hallucination) — یعنی زمانی که مدل با اطمینان چیزی را می‌گوید که وجود ندارد یا توکن‌ها را تغییر می‌دهد — یک دستورالعمل خاص در پرامپت سیستمی الزامی است: «توکن‌های با فرمت را دقیقاً همان‌طور که هستند نگه دارید؛ آن‌ها را تغییر ندهید».

عملکرد و تست

از نظر فنی، اگرچه مقداردهی اولیه AnalyzerEngine چند ثانیه زمان می‌برد، اما تحلیل واقعی چند کیلوبایت متن تنها چند میلی‌ثانیه طول می‌کشد. این میزان تأخیر در مقایسه با زمان پاسخ‌دهی کلی APIهای مدل‌های زبانی، کاملاً ناچیز و قابل چشم‌پوشی است.

برای تضمین اینکه سیستم در طول به‌روزرسانی‌ها دچار شکست نشود، نویسنده پیشنهاد می‌کند از یک فایل PII Fixture در خط لوله CI/CD استفاده شود. این رویکرد در راستای جلوگیری از ورود کدهای معیوب هوش مصنوعی به محیط تولید است تا پایداری سیستم در محیط‌های عملیاتی تضمین گردد. این کار به توسعه‌دهندگان اجازه می‌دهد تست‌های خودکاری را اجرا کنند که تأیید می‌کند هیچ مقدار واقعی از PII در خروجی‌های حذف‌شده باقی نمانده است.

این تغییر در زیرساخت، گفتگو را از «امید به اینکه ارائه‌دهنده داده‌های ما را لاگ نکند» به یک «تضمین فنی حریم خصوصی» تغییر می‌دهد. با تبدیل حذف داده‌ها به یک مسئله مرزی (Boundary Problem) به‌جای یک مسئله پرامپت‌نویسی، توسعه‌دهندگان می‌توانند عامل‌ها را در محیط‌های با نظارت شدید قانونی استقرار دهند بدون اینکه ریسک جریمه‌های سنگین را بپذیرند.

گام بعدی شما

• کد خود را برای عبارت‌های chat.completions یا messages.create جست‌وجو (Grep) کنید تا دقیقاً بفهمید چه داده‌هایی در حال حاضر به پرامپت‌های شما جریان می‌یابند.
• کتابخانه Microsoft Presidio را برای شناسایی اولیه داده‌های حساس در محیط محلی تست کنید.
• یک لایه Wrapper ساده برای خروجی ابزارهای (Tools) خود طراحی کنید تا داده‌های حساس پیش از ارسال به مدل توکن‌سازی شوند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.