تصور کنید تمام تلاش‌های امنیتی شما برای محافظت از حریم خصوصی کاربران، تنها با یک تغییر در ارائه‌دهنده مدل هوش مصنوعی به کلی از بین برود. اگر فکر می‌کنید فیلترهای حذف اطلاعات حساس یک استاندارد جهانی هستند، احتمالاً در حال حاضر در حال نشت داده‌های حساس سازمان خود هستید. ریسک ذاتی در تغییر ارائه‌دهنده AI دقیقاً در همین فرض نهفته است: این تصور غلط که مدیریت اطلاعات شناسایی شخصی (PII) یک ویژگی همگانی و یکسان در همه پلتفرم‌هاست.
بسیاری از توسعه‌دهندگان به اشتباه، فیلترینگ ایمنی را با مدیریت اطلاعات شناسایی شخصی (PII) — که مثل یک سانسورچی دقیق است و هر نام یا شماره تلفنی را پیش از رسیدن به مدل می‌پوشاند — یکی می‌دانند. در حالی که APIهای استنتاج استاندارد به‌طور پیش‌فرض محتوای توهین‌آمیز، محتوای جنسی، خشونت یا خودزنی را مسدود می‌کنند، اما معمولاً نسبت به شماره‌های ملی یا ایمیل‌ها بی‌تفاوت‌اند. این فیلترهای پیش‌فرض، متن را در دسته‌های آسیب‌زا طبقه‌بندی کرده و سطح شدت را برمی‌گردانند یا درخواست را مسدود می‌کنند، اما هیچ حرفی درباره PII مشتری ندارند. طبق گزارش‌های فنی، حذف واقعی PII معمولاً یک لایه اختیاری (Opt-in) است که بین درخواست و مدل قرار می‌گیرد و خارج از فراخوانی استنتاج تنظیم می‌شود؛ بنابراین گردش کاری که از نظر «فیلترینگ محتوا» تأیید شده، ممکن است هیچ حفاظتی در برابر نشت داده‌های شخصی نداشته باشد. این چالش‌ها در حوزه‌های حساس‌تر مانند خدمات مالی دوچندان می‌شود، جایی که استفاده از مدل‌های زبانی برای طبقه‌بندی سیاست‌های نظارتی به ابزاری حیاتی برای مدیریت محتوا تبدیل شده است.
همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های حفاظتی هرگز جایگزین معماری امن نمی‌شوند. در این مورد نیز، حفاظ‌ها (Guardrails) — شبیه به نرده‌های ایمنی در لبه یک پل که مانع سقوط می‌شوند — مانند Amazon Bedrock Guardrails و فیلترهای مشابه در سطح پلتفرم، متعلق به خود پلتفرم هستند، نه مدل. به همین دلیل، لحظه‌ای که از یک پلتفرم به پلتفرم دیگر مهاجرت می‌کنید، تمام وضعیت امنیتی شما تغییر می‌کند. در حالی که تغییر مدل در داخل یک پلتفرم واحد، فیلتر را حفظ می‌کند، اما تغییر پلتفرم باعث می‌شود این لایه حفاظتی به‌طور کامل از دست برود.
به نقل از یک راهنمای فنی منتشر شده در ۱۳ اوت ۲۰۲۶، طراحی ساختاری این فیلترها سه نقطه شکست بحرانی ایجاد می‌کند:
شکاف حذف داده‌ها
- تشخیص احتمالی: تشخیص PII به شدت به متن اطراف وابسته است. مستندات صراحتاً توصیه می‌کنند که متن‌های محیطی بیشتری ارائه شود، زیرا یک رشته ساده از اعداد مبهم است. تغییر ارائه‌دهنده اغلب منجر به تغییر در نرخ بازیابی (Recall) می‌شود؛ این یعنی تغییر در ریسک باقی‌مانده است، نه یک تنظیم ساده در پیکربندی.
- شکست جهت‌دار: جهت جریان داده اهمیت دارد. اگر ارائه‌دهنده قبلی هر دو مسیر ورودی و خروجی را از طریق
inputActionوoutputActionماسک می‌کرد، اما ارائه‌دهنده جدید فقط ورودی‌ها را می‌پوشاند، داده‌های حساس PII که از حافظه مدل بازیابی شده‌اند، مستقیماً به رابط کاربری (UI)، لاگ‌ها و خط لوله‌های تحلیل داده شما نشت می‌کنند. - ابهام در رویدادها: در سامانه‌هایی مثل Amazon Bedrock، یک درخواست «مسدود شده» به جای خطای مدل، یک پیام تنظیم‌شده برمی‌گرداند. اگر معیارهای سنجش شما تعداد «رد درخواست توسط مدل» را از طریق تطبیق متن پاسخ می‌شمارند، یک تغییر در سیاست‌های پلتفرم می‌تواند به‌طور خاموش ترافیک را بین دو دسته‌ای جابجا کند که شما فکر می‌کردید در حال اندازه‌گیری آن‌ها هستید.
- انواع عملیات: رفتار حذف بسته به نوع عملیات متفاوت است. در حالت
ANONYMIZE(گمنام‌سازی)، بخش‌های شناسایی شده با انواع موجودیت در براکت جایگزین می‌شوند، مانند {NAME} یا {EMAIL}. اما در حالتBLOCK(مسدودسازی)، کل درخواست یا پاسخ رد می‌شود.
تله‌ی لاگ‌ها
بر اساس مستندات، دو استثنای خطرناک وجود دارد که در آن ارائه‌دهندگان با وجود ماسک کردن، مقادیر اصلی را نگه می‌دارند. نخست، لاگ‌های فراخوانی مدل (مانند ارسالی به CloudWatch یا S3) اغلب حاوی درخواست‌های اصلی و دست‌نخورده هستند. ماسک کردن، ورودی مدل را می‌پوشاند، نه سوابق پلتفرم را. هر کسی که دسترسی خواندن به آن گروه لاگ‌ها داشته باشد، به پرامپت خام دسترسی دارد.
دوم، خروجی‌های ردیابی (Trace) در پاسخ‌های API اغلب مقدار اصلی PII را در فیلد 'match' قرار می‌دهند. این طراحی به برنامه‌ها اجازه می‌دهد تا بر اساس تشخیص داده‌ها واکنش نشان دهند، اما به این معناست که هر شیء پاسخی که در لاگ‌های داخلی شما سریال‌سازی (Serialize) شود، دقیقاً حاوی همان داده‌هایی است که قصد حذفشان را داشتید.
عدم تطابق طبقه‌بندی‌ها
لیست موجودیت‌های حساس در هر پلتفرم بر اساس حوزه‌های قضایی و استانداردهای خاص همان شرکت متفاوت است. برای مثال، Amazon Bedrock تفاوت دقیقی بین شماره‌های تأمین اجتماعی آمریکا (US_SOCIAL_SECURITY_NUMBER)، بریتانیا (UK_NATIONAL_INSURANCE_NUMBER) و کانادا (CA_SOCIAL_INSURANCE_NUMBER) قائل می‌شود و آن‌ها را به عنوان انواع مجزا ردیابی می‌کند. همچنین انواع کلی مانند NAME، ADDRESS، AGE، USERNAME و PASSWORD و همچنین انواع IT شامل IP_ADDRESS، MAC_ADDRESS و کلیدهای دسترسی ابری را ردیابی می‌کند.
اما ارائه‌دهنده دیگر ممکن است این‌ها را در یک گروه قرار دهد یا کلاً حذف کند. این تفاوت‌ها باعث می‌شود ارزیابی اثرات حفاظت از داده‌ها (DPIA) و واژگان سوابق پردازش شما با قابلیت‌های ارائه‌دهنده جدید هم‌خوانی نداشته باشد. نگاشت بین واژگان شما و لیست موجودیت‌های هر پلتفرم، سندی است که شما موظف به تهیه آن هستید؛ لحظه مهاجرت، بهترین زمان برای نوشتن این سند است تا شناسایی کنید کدام دسته‌ها را اکنون باید خودتان مدیریت کنید.
در حالی که عبارت‌های منظم (Regex) سفارشی می‌توانند شناسه‌های ساختاریافته مانند شماره‌های رزرو یا شماره حساب را پوشش دهند، اما توانایی تشخیص نام‌ها را ندارند. علاوه بر این، برخی پلتفرم‌ها محدودیت‌های خاصی دارند؛ برای مثال، Bedrock اشاره می‌کند که فیلتر Regex آن از lookaround پشتیبانی نمی‌کند.
این وضعیت نشان می‌دهد که حذف داده در سمت ارائه‌دهنده، در مقیاس بزرگ یک نقطه ضعف و مسئولیت (Liability) است. هر مهاجرت، بازنویسی کامل فیلترها با طبقه‌بندی و استثناهای جدید را می‌طلبد، بدون اینکه راهی برای تست یکسان دو سیستم وجود داشته باشد. درس کلی این است که ویژگی حذف داده در سمت ارائه‌دهنده، ورودی مدل را محافظت می‌کند، اما قابلیت‌های مشاهده‌پذیری (Observability) خود پلتفرم معمولاً خارج از این مرز حفاظتی قرار دارند.
برای توسعه‌دهنده، این بدان معناست که تنها راه حفظ یک مرز امنیتی ثابت، انتقال کنترل به سمت کاربر (Client-side) است. این تغییر رویکرد با گذار کلی در طراحی APIهای هوش مصنوعی از اجرای دستور به مدیریت خط لوله هم‌سو است تا کنترل بیشتری بر جریان داده‌ها حاصل شود. یک خط لوله حذف داده که در مالکیت کاربر باشد، روی هر ارائه‌دهنده‌ای به‌طور یکسان اجرا می‌شود، امکان تست واحد (Unit-testing) در برابر مجموعه‌داده‌های ثابت را فراهم می‌کند و تضمین می‌کند که PII خام هرگز در وهله اول به لاگ‌ها یا مدل‌های ارائه‌دهنده نرسد. تست این روش ساده است: تأیید اینکه حذف داده‌ها پیش از چاپ هر چیزی در مسیر خطا (Failure path) اتفاق می‌افتد، اکثر نشت‌ها را شناسایی می‌کند. مهاجرت یک خط لوله حذف داده که در مقابل فراخوانی API قرار دارد، اجرای فنی را پوشش می‌دهد، در حالی که شرایط نگهداری داده‌ها (Retention terms)، ریسک‌های باقی‌مانده را مدیریت می‌کند.
گام بعدی شما
- کنترل حذف داده‌ها را از سمت پلتفرم به سمت کاربر (Client-side) منتقل کنید تا امنیت شما مستقل از ارائه‌دهنده مدل باشد.
- یک خط لوله (Pipeline) حذف داده اختصاصی بسازید که بتوان آن را با مجموعه‌داده‌های ثابت تست واحد (Unit-test) کرد.
- بررسی کنید که آیا لاگ‌های زیرساختی شما (مانند S3 یا CloudWatch) حاوی داده‌های خام هستند یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو