GDPR: جریمه‌های سنگین ناشی از نشت PII در عامل‌های هوش مصنوعی

اگر امروز یک پروژه .NET را با تکیه بر SessionStore، یک JsonSerializer و مقدار زیادی خوش‌بینی مدیریت می‌کنید، احتمالاً با بمب ساعتی امنیتی رو‌به‌رو هستید؛ چرا که هر مورد نشت داده‌های حساس (PII) در سال ۲۰۲۵ به‌طور متوسط ۴.۸۸ میلیون دلار برای شرکت‌ها هزینه داشته است. با وجود این ریسک‌های بالا، اکثر پروژه‌های عامل‌محور (Agentic) در .NET هنوز فاقد یک خط لوله (Pipeline) ابتدایی برای پاک‌سازی داده‌ها هستند. برای حل این بحران، یک چارچوب معماری جدید برای عامل‌های .NET معرفی شده است که یک لایه امنیتی اجباری را معرفی می‌کند؛ لایه‌ای که پاک‌سازی را نه به عنوان یک ابزار نمایش (Presentation)، بلکه به عنوان یک دغدغه داده‌ای (Data Concern) در نظر می‌گیرد. این معماری مجموعه‌ای از پیاده‌سازی‌هایی را تکمیل می‌کند که در بخش‌های قبلی به تعویق افتاده بود: پاک‌سازی پیش از ذخیره‌سازی، حسابرسی ضد-دست‌کاری، مالکیت در سطح هر فضای کاری (Per-workspace) و مدل تهدید ابزارهایی که قابلیت نوشتن (Write) دارند.

بسیاری از توسعه‌دهندگان به اشتباه پاک‌سازی داده‌ها را در سطح رابط کاربری (UI) انجام می‌دهند که طبق گزارش‌ها منجر به نرخ شکست ۷۰ درصدی در حذف بصری داده‌ها (Visual-blackout redaction) می‌شود. تا زمانی که یک توکن، کلید API یا رشته اتصال (Connection String) به پایگاه‌داده برسد، نشت داده عملاً رخ داده است و این امر منجر به نیاز به مهاجرت‌های دیتابیسی، چرخش کلیدها (Key Rotations) و گفتگوهای دشوار درباره اعلان نشت داده می‌شود. طبق راهنمای فنی منتشر شده در ۷ اکتبر ۲۰۲۶، تنها لحظهٔ امن برای رهگیری داده‌های حساس، مرحله‌ای از خط لوله است که بلافاصله پیش از عملیات INSERT در پایگاه‌داده قرار دارد.

تصور کنید عامل هوش مصنوعی شما مانند کارمندی است که به یک فایلینگ کابینت دسترسی دارد؛ اگر این کارمند رمز عبور مشتری را روی یک یادداشت چسبان بنویسد و در کابینت بگذارد، شکست امنیتی دائمی شده است. لایهٔ امنیتی در اینجا مانند یک افسر امنیت عمل می‌کند که یادداشت را پیش از آنکه به کشو برسد، پاک می‌کند. در این مدل، هر نوبت گفتگو یک شیء ConversationTurn تولید می‌کند که باید پیش از ذخیره‌سازی از یک خط لوله پاک‌سازی (RedactionPipeline) عبور کند.

خط لوله پاک‌سازی سه‌لایه

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

• لایه اول: ردیاب‌های Regex. این ردیاب‌ها اسرار ساختاریافته را با تأخیر صفر و نرخ منفی کاذب (False-negative) صفر شناسایی می‌کنند. اهداف آن‌ها شامل رشته‌های اتصال (Server=.*;Password=)، الگوهای JWT، پیشوندهای کلید AWS (AKIA[0-9A-Z]{16}) و توکن‌های شخصی GitHub (ghp_[A-Za-z0-9]{36}) است.
• لایه دوم: ردیاب‌های آنتروپی شانون. این لایه کلیدهای API که ظاهر تصادفی دارند و فاقد پیشوند شناخته‌شده هستند را شکار می‌کند. هر توکن متوالی که بیش از ۴.۵ بیت بر کاراکتر آنتروپی داشته باشد و طول آن بیش از ۲۰ کاراکتر باشد (و URL یا GUID نباشد)، علامت‌گذاری می‌شود.
• لایه سوم: مدل‌های زمینه‌ای. ابزارهایی مانند Microsoft Presidio — که می‌تواند به صورت یک REST sidecar یا Python SDK مستقر شود — متن‌های بدون ساختار مثل نام، آدرس، شماره‌های ملی، IBAN و شماره پاسپورت را شناسایی می‌کنند. Presidio به عنوان یک sidecar نگه داشته می‌شود زیرا تأخیر آن برای مسیرهای ذخیره‌سازی غیرهمزمان (Async) قابل قبول است، اما برای استریم‌های بلادرنگ (Real-time) مناسب نیست. برای ساختارهای گفتگوی چند-نوبتی، استفاده از Azure Conversation PII API (نسخه پیش‌نمایش ۱۵ نوامبر ۲۰۲۶، مدل پیش‌نمایش ۱۵ آپریل ۲۰۲۶) برای کسانی که در اکوسیستم Azure هستند توصیه شده است.

مکانیزم‌های پاک‌سازی و خزانه

وقتی خط لوله یک بخش حساس را شناسایی می‌کند، متن خام را با یک توکن بازگشت‌پذیر مانند [REDACTED:Category:Guid] جایگزین می‌کند. مقدار اصلی در یک خزانه مقادیر ماسک‌شده (MaskedValueVault) مجزا و رمزنگاری‌شده ذخیره می‌شود که توسط امنیت سطح ردیف (RLS) محافظت می‌شود.

• آستانه اطمینان: اگر اطمینان یک ردیاب زیر ۸۰٪ (۰.۸۰) باشد، مورد به صف بررسی انسانی (IFlaggedItemQueue) ارسال می‌شود. برای مثال، یک ردیاب آنتروپی با اطمینان پایه ۰.۶۵ به‌طور خودکار یک ورودی در صف بررسی ایجاد می‌کند.
• گردش کار بررسی: اپراتورها از طریق یک نقطه انتهایی مدیریتی (/admin/flagged) موارد را تأیید یا رد می‌کنند. موارد تأیید شده در خزانه به عنوان Verified علامت‌گذاری می‌شوند. موارد رد شده در خزانه از حالت ماسک خارج شده و توکن اصلی از طریق متد RestoreTokenAsync در ذخیره نشست بازیابی می‌شود و سپس ورودی خزانه حذف می‌گردد.
• انطباق با GDPR: طبق ماده ۴(۵) GDPR، مستعارسازی (Pseudonymization) — مانند جایگزینی «علی محمدی» با «PERSON_001» — داده‌ها را از دایره شمول GDPR خارج نمی‌کند، زیرا فرد همچنان از طریق خزانه قابل شناسایی است. توسعه‌دهندگان باید کل بافت (Context) نوبت گفتگو را به عنوان واحد ارزیابی در نظر بگیرند، زیرا ترکیب عناوین شغلی نادر با شهرهای کوچک و تاریخ‌های رویدادها می‌تواند کاربران را حتی بدون داشتن نام، شناسایی کند.

تست واحد خط لوله

تست این سیستم نیازمند ورودی‌های مبتنی بر ویژگی (Property-based) است، نه رشته‌های ساده و خوش‌بینانه. یک مجموعه تست جامع باید شامل موارد زیر باشد:

• اعتبارسنجی الگو: تأیید اینکه رشته‌ای مانند Server=myserver;Password=hunter2; به‌درستی در دسته ConnectionString قرار می‌گیرد و رمز عبور خام هرگز به متن نهایی نمی‌رسد.
• تشخیص اسرار: اطمینان از اینکه کلیدهای AWS (مثلاً AKIAIOSFODNN7EXAMPLE) و توکن‌های Bearer JWT به‌درستی ماسک شده و در خزانه ذخیره می‌شوند.
• تست اطمینان: تأیید اینکه توکن‌های شناسایی شده توسط ردیاب‌های آنتروپی (مثلاً xK9mP2qRvL8nW3yT6jA1cB5eH0uM4sZ7) در صورتی که اطمینان آن‌ها زیر آستانه ۰.۸۰ باشد، به‌درستی به صف بررسی هدایت می‌شوند.

دفاع در برابر تزریق پرامپت

این سیستم علاوه بر PII، با تهدید بحرانی تزریق پرامپت غیرمستقیم مقابله می‌کند که در طبقه‌بندی OWASP به عنوان LLM01:2025 شناخته می‌شود. این راهنما به EchoLeak (CVE-2025-32711) اشاره می‌کند که نشان داد مهاجمان چگونه می‌توانند بدون نیاز به اعتبارنامه، بدافزار یا تعامل کاربر، از Microsoft 365 Copilot سوءاستفاده کنند. به همین ترتیب، سرور رسمی Git MCP شرکت Anthropic با سه CVE تزریق قابل بهره‌برداری عرضه شده بود.

برای جلوگیری از این اتفاق، معماری مذکور یک ردپای حسابرسی ضد-دست‌کاری (Tamper-evident audit trail) را پیاده می‌کند. استاندارد ATR-2026-00550 (منتشر شده در ۲۸ مه ۲۰۲۶، شدت: بحرانی) یک ردپای تزریق استاندارد را به صورت «یک بخش بازیابی (RETRIEVER) غیرقابل اعتماد و به‌دنبال آن یک بخش ابزار (TOOL) دارای امتیاز» تعریف می‌کند. هر فراخوانی ابزار باید یک رویداد ساختاریافته شامل موارد زیر تولید کند:

• شناسه‌ها: WorkspaceId و AgentSessionId.
• جزئیات ابزار: ToolName و ToolInputHash (از هش به جای ورودی خام استفاده می‌شود تا از ذخیره شدن Payload جلوگیری شود).
• بافت: SourceSpan (که نشان می‌دهد آیا ورودی از یک منبع غیرقابل اعتماد بوده است یا خیر) و PrivilegeLevel (سطوح Read، Write یا Admin).
• نتیجه: OutcomeStatus و OutcomeHash.

این رویدادها در ذخیره‌سازهای append-only (فقط-افزودنی) ذخیره می‌شوند. در PostgreSQL این کار با یک جدول insert-only و تریگری که مانع UPDATE/DELETE می‌شود و یک شغل شبانه برای تأیید زنجیره هش (Hash-chain) انجام می‌گیرد. در Azure، از یک immutable blob container با سیاست‌های زمانی استفاده می‌شود. بدون بازپخش قطعی (Deterministic replay)، حوادث از طریق حافظه بازسازی می‌شوند؛ اما با این سیستم، بازسازی از طریق پرس‌وجو (Query) امکان‌پذیر است.

برای اقدامات نوشتن (Write) با امتیاز بالا، چارچوب رویکرد «دفاع در عمق» را پیشنهاد می‌کند. از آنجایی که هر کنترل منتشر شده به‌تنهایی دور زده شده است، سیستم به ۵ تا ۷ لایه مستقل نیاز دارد: حصار محتوای غیرقابل اعتماد، پرامپت‌های سلسله‌مراتب دستورات، فیلترهای خروجی، تأیید انسانی (Human-in-the-loop)، لیست سفید در سطح ابزار، هشدار حسابرسی و یک مدارشکن (Kill-switch) برای توقف سریع.

چندمستاجری و نگهداری داده‌ها

جداسازی داده‌ها از طریق امنیت سطح ردیف (RLS) در پایگاه‌داده مدیریت می‌شود. هر پرس‌وجو علیه AgentSessions ،ConversationTurns و MaskedValueVault باید شامل یک شرط workspace_id باشد. این کار از تکرار باگ‌های احراز هویت کوکی نشست — که در یک مورد واقعی منجر به نشتی شناسایی نشده به مدت ۸ ماه شد — جلوگیری می‌کند تا یک مستاجر نتواند داده‌های مستاجر دیگر را بخواند.

برای رعایت ماده ۵(۱)(e) GDPR، سیستم از یک شغل پاک‌سازی نگهداری (RetentionPruningJob) استفاده می‌کند که شبانه اجرا می‌شود. این کار از مشکلاتی مانند آنچه در حسابرسی Nakama دیده شد (که رونوشت‌ها برای همیشه باقی مانده بودند) جلوگیری می‌کند. این شغل سطوح انقضای متفاوتی را اعمال می‌کند:

• بدون PII: ۹۰ روز
• فقط ایمیل (غیر متصل به حساب): ۳۰ روز
• تیکت‌های پشتیبانی: ۳۶۵ روز یا ۹۰ روز پس از حل تیکت
• داده‌های سلامت/مالی: طبق استانداردهای HIPAA / PCI-DSS

سوابق پیش از حذف نهایی، وارد یک قرنطینه حذف نرم (Soft-delete) ۳۰ روزه می‌شوند. یک پرچم «نگهداری» (Hold flag) روی رکورد می‌تواند حذف نهایی را برای مقاصد قانونی متوقف کند بدون اینکه نیازی به تغییر در منطق پاک‌سازی باشد.

تحلیل معماری

این رویکرد، بحث ایمنی هوش مصنوعی را از «مهندسی پرامپت» به «مهندسی سیستم‌ها» منتقل می‌کند. لایه امنیتی به عنوان یک دغدغه عرضی (Cross-cutting concern) عمل می‌کند: متن ورودی $
ightarrow$ خط لوله پاک‌سازی $
ightarrow$ ذخیره نشست (ماسک‌شده) + خزانه (خام، رمزنگاری‌شده در حالت استراحت، تحت RLS) $
ightarrow$ اجرای عامل $
ightarrow$ فراخوانی ابزارها و تولید رویدادهای حسابرسی (فقط-افزودنی) $
ightarrow$ متن خروجی $
ightarrow$ عبور مجدد از خط لوله پاک‌سازی $
ightarrow$ پاسخ نهایی.

برای اکوسیستم .NET، این یعنی لایه امنیتی باید به عنوان یک مؤلفه مستقل و قابل تست در نظر گرفته شود. هزینه‌های بالای عدم انطباق — مانند جریمه ۵.۱ میلیون دلاری یک شرکت Ed-Tech در سال ۲۰۲۵ و جریمه یک بانک لهستانی برای جمع‌آوری بیش از حد داده‌ها — این سربار معماری را به یک بیمه‌نامه ضروری تبدیل می‌کند.

اگر قصد دارید این سیستم را از ابتدا بسازید، سه بهبود توصیه می‌شود:

1. شناسه‌های Strongly-Typed: به جای رشته (string)، از یک نوع داده‌ای WorkspaceId استفاده کنید تا نشت‌های بین-مستاجری در سطح کامپایلر شناسایی شوند.
2. هشدار زودهنگام ردپای داده: پرچم SourceSpan.IsTrusted را از اولین ادغام ابزار فعال کنید تا نیازی به بازسازی رویدادهای تاریخی نباشد.
3. تست مستقل: یک محیط تست اختصاصی (Test Harness) برای خط لوله پاک‌سازی با ورودی‌های مبتنی بر ویژگی بسازید. هزینه متوسط ۴.۸۸ میلیون دلاری هر نشت داده، سرمایه‌گذاری روی این محیط تست را ضروری می‌کند.

توسعه‌دهندگان باید اکنون منطق ذخیره‌سازی نشست‌های فعلی خود را ارزیابی کنند تا ببینند آیا PII به‌صورت متن ساده ذخیره می‌شود یا خیر. کفِ انطباق (Compliance floor) برای سیستم‌های عامل‌محور اکنون مشابه هر پردازشگر داده‌های شخصی دیگر است. ابتدا لایه امنیتی را بسازید.