یک سیستم پشتیبانی مبتنی بر هوش مصنوعی که تصور می‌شد در مرحله خروجی مدل ایمن‌سازی شده است، از طریق «درِ جانبی» که سوابق CRM را به پرامپت (prompt) تزریق می‌کند، در حال نشت داده‌های مشتری بود. تحلیل پس از حادثه (post-mortem) سازنده نشان می‌دهد که محافظت از تنها متنی که مدل تولید می‌کند کافی نیست؛ درخواست ورودی، داده‌های بازیابی شده از ابزارهای داخلی و خروجی نهایی همگی به حفاظ‌های مستقل نیاز دارند، در غیر این صورت یک کسب‌وکار ممکن است نام‌ها، ایمیل‌ها و شناسه‌ها را بدون اینکه هرگز شاهد نقض خروجی مدل باشد، فاش کند.

چرا این سه مرز اهمیت دارند

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

  • ورودی (Ingress) – پرس‌وجوی خام که مشتری تایپ می‌کند.
  • مسیر بازگشتی (Return path) – اطلاعاتی که عامل از سیستم‌های پایین‌دستی مانند CRM استخراج می‌کند.
  • خروجی (Emission) – متنی که مدل به کاربر بازمی‌گرداند.

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

از نسخه نمایشی تا تولید: درس‌های سخت‌به‌دست‌آمده

انتقال یک نمونه اولیه به یک مرکز کمک‌رسانی زنده، شکست‌های ملموسی را آشکار کرد که یک رویکرد ساده‌ی «پوشاندن (redact) و سپس ارسال» آن‌ها را نادیده گرفته بود.

  • به جای پوشاندن، توکن‌سازی کنید (Tokenize instead of redact) – حذف یک نام یا ایمیل قبل از رسیدن به مدل، مانع از بازسازی پاسخ صحیح توسط سیستم می‌شود. مقدار اصلی را در یک مخزن امن ذخیره کنید، آن را در پرامپت با یک UUID تصادفی جایگزین کنید و پس از اتمام کار مدل، UUID را به مقدار اصلی برگردانید. این کار داده‌های خام را از بافت (context) مدل دور نگه می‌دارد و در عین حال عملکرد سیستم را حفظ می‌کند.

  • شناسه‌ها را با چک‌سام (checksum) اعتبارسنجی کنید – یک عبارت منظم (regular expression) رشته‌ای را که شبیه شماره حساب است شناسایی می‌کند؛ اما یک چک‌سام تأیید می‌کند که آیا آن یک شناسه واقعی است یا خیر. یک فیلتر چک‌سام از عامل جلوگیری می‌کند تا اعداد دلخواه را به عنوان داده‌های حساس در نظر بگیرد، که این امر باعث کاهش موارد مثبت کاذب می‌شود که در غیر این صورت منجر به پوشاندن‌های غیرضروری می‌شد.

  • بازه های هم‌پوشان را ادغام کنید (Merge overlapping spans) – سوابق مشتریان اغلب شامل نامی است که پس از آن یک آدرس ایمیل قرار دارد که کاراکترهای مشترکی دارند (مثلاً “John Doe john.doe@example.com”). توکن‌سازیِ تنها نام باعث می‌شود قطعه‌ای از ایمیل به صورت متن آشکار باقی بماند که ممکن است در خروجی منتشر شود. کل ناحیه هم‌پوشان را به عنوان یک توکن واحد در نظر بگیرید.

  • مرز درست را آزمایش کنید – آزمایشی که تنها با بررسی لایه خروجی (emission) با موفقیت انجام می‌شود، حس امنیت کاذبی ایجاد می‌کند. آزمایشی که شکست می‌خورد و نشت در مسیر بازگشتی را شناسایی می‌کند، باعث اصلاح خطا می‌شود. مجموعه‌ آزمون‌هایی طراحی کنید که صراحتاً هر یک از سه مرز را اعتبارسنجی کنند.

  • واقعیت پایه (ground truth) را پیگیری کنید – وقتی یک انسان پیش‌نویس تولید شده توسط هوش مصنوعی را قبل از ارسال ویرایش می‌کند، مدل قبلاً پاسخی نادرست تولید کرده است. مقایسه پیش‌نویس هوش مصنوعی با پیام نهایی تأیید شده توسط انسان، شکاف‌های اطمینان را آشکار کرده و از یادگیری سیستم برای تکرار اشتباهات جلوگیری می‌کند.

مخاطرات برای کسب‌وکارها

عوامل هوش مصنوعیِ خدمات مشتری در نقطه تلاقی تعاملات عمومی و ذخیره‌سازهای داده‌های داخلی قرار دارند.

استدلال مخالف: چرا برخی هنوز پوشاندن (redaction) را ترجیح می‌دهند

نتیجه‌گیری

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