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

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

طبق گزارش‌های منتشر شده، بسیاری از شرکت‌ها از هوش مصنوعی زاینده (Generative AI) — شبیه به دستیاری که میلیاردها صفحه را خوانده و حالا می‌تواند هر کاری را شبیه‌سازی کند — برای مدیریت امور داخلی استفاده می‌کنند. اما مشکل اینجاست که آن‌ها از همان قوانین سخت‌گیرانه‌ای استفاده می‌کنند که برای داده‌های مشتریان تعریف شده است؛ در حالی که داده‌های کارکنان در دنیای عامل‌ها (Agents) مسیرهای نشت متفاوتی دارند.

در ۱۸ آوریل ۲۰۲۶، شرکت متا (Meta) افشا کرد که در Rahmen «ابتکار قابلیت مدل» (Model Capability Initiative یا MCI)، نرم‌افزارهای نظارت بر ضربات کیبورد و صفحه نمایش را روی لپ‌تاپ‌های کارکنان آمریکایی نصب کرده است. هدف از این اقدام، ساخت عامل‌هایی (Agents) بود که قادر به انجام کارهای اداری (White-collar tasks) باشند. این حرکت نشان‌دهنده یک روند رو به رشد است که در آن داده‌های رفتاری کارکنان، بدون داشتن حفاظ‌های امنیتی که معمولاً برای داده‌های مشتریان به کار می‌رود، به پنجره‌های متنی مدل‌های هوش مصنوعی جریان می‌یابند.

این ابزار، که در یک یادداشت داخلی برای کارکنان «آزمایشگاه‌های ابرهوش متا» (Meta Superintelligence Labs) توصیف شده بود، تمام حرکات موس، کلیک‌ها، ضربات روی کیبورد و عکس‌های صفحه نمایش (Screenshots) را برای آموزش مدل‌هایی که متا برای «استفاده خودکار از کامپیوتر» می‌سازد، ضبط می‌کرد. اگرچه هدف اعلام شده، بهبود مدل بود و در آن یادداشت ادعا شد که این داده‌ها برای ارزیابی عملکرد کارکنان استفاده نخواهند شد، اما این حادثه یک شکست سیستمیک عمیق‌تر را آشکار کرد: حاکمیت داده‌ها به جای یک «سیاست داده رسمی» (Formal Data Policy)، تنها توسط یک «یادداشت برنامه» (Program Memo) مدیریت می‌شد.

اکثر سازمان‌ها سال‌هاست که کنترل‌های مربوط به شناسنامه‌ای شخصی (PII) مشتریان را بهینه کرده‌اند. این سیستم‌ها از جریان‌های رضایت (Consent flows)، رویه‌های اطلاع‌رسانی در صورت نقض داده‌ها و گزارش‌های دسترسی (Access logs) متصل به کاربران خاص استفاده می‌کنند، زیرا سازمان هر دو طرف تراکنش را در اختیار دارد. اما داده‌های کارکنان که توسط عامل‌های هوش مصنوعی پردازش می‌شوند، چنین مرزهایی ندارند. این موضوع یک نقطه کور خطرناک ایجاد می‌کند؛ جایی که داده‌های عملیاتی داخلی با سخت‌گیری کمتری نسبت به داده‌های خارجی مشتریان مدیریت می‌شوند، علیرغم اینکه رکوردهای مربوطه حساسیت بسیار بالایی دارند.

مکانیسم‌های نشت در پنجره متنی

این افشای اطلاعات به دلیل سه دلیل ساختاری در نحوه عملکرد هوش مصنوعی عامل‌محور (Agentic AI) رخ می‌دهد:

• بازیابی بیش‌ازحد در پنجره متنی (Context Window Over-Retrieval): عامل‌ها معمولاً داده‌های بیشتری را نسبت به آنچه یک تسک خاص نیاز دارد، بازیابی می‌کنند. یک پرسش ساده درباره «مانده مرخصی»، می‌تواند رکوردی شامل آدرس منزل، مخاطبان اضطراری و سوابق مرخصی پزشکی را وارد حافظه فعال مدل کند. مدل تمام این اطلاعات را پردازش می‌کند و این انتقال داده پس از وقوع، غیرقابل بازگشت است. هیچ ورودی در گزارش‌ها (Log) نمی‌تواند این افشا را خنثی کند.
• انتشار در لایه‌های پایین‌دستی (Downstream Propagation): در معماری‌های چند-عاملی، یک عامل سازمان‌دهنده (Orchestrator) اغلب هنگام تفویض اختیار به عامل‌های کارگر (Worker Agents)، بستری از اطلاعات گسترده‌تر از آنچه برای آن زیر-تسک لازم است، ارسال می‌کند. این عامل‌های کارگر، داده‌های حساس کارکنان را بدون اینکه بدانند چه چیزی را پردازش می‌کنند و بدون مکانیزم‌هایی برای اطمینان از اینکه فقط فیلدهای مرتبط به هر گام می‌رسند، پردازش می‌کنند.
• ترانزیت توسط شخص ثالث (Third-Party Transit): کارکنان در مقیاس وسیع از دستیارهای تامین‌کننده‌ای مانند Claude Desktop، GitHub Copilot و Cursor برای انجام وظایف داخلی استفاده می‌کنند. هنگام مسیریابی پرسش‌ها از طریق پروتکل زمینه مدل (Model Context Protocol یا MCP)، داده‌های سیستم‌های متصل — شامل دایرکتوری‌ها، ویکی‌ها و پورتال‌های داخلی — به خارج از کنترل مستقیم سازمان منتقل می‌شوند.

بر اساس گزارش ۲۰۲۵ شرکت Cyberhaven در زمینه پذیرش و ریسک AI، ۳۴.۸٪ از تمام داده‌های شرکتی که کارکنان وارد ابزارهای هوش مصنوعی می‌کنند «حساس» هستند. این عدد در مقایسه با ۱۰.۷٪ در دو سال پیش، جهشی خیره‌کننده است و رکوردهای کارکنان بخش قابل توجهی از این نشت‌ها را تشکیل می‌دهند.

شکست ساختاری در مدیریت دسترسی

مشکل اصلی یک شکاف معماری است. یک عامل معمولاً دارای اعتبارنامه‌های حساب خدماتی (Service Account Credentials) است که اجازه دسترسی به یک ذخیره داده گسترده را می‌دهد، اما هیچ سیاست مجزایی مشخص نمی‌کند که کدام «زیرمجموعه» از آن داده‌ها می‌تواند برای یک جریان کاری خاص وارد پنجره متنی مدل شود.

این الگو شبیه به اتفاقی است که در مه ۲۰۲۵ برای شرکت Serviceaide (تامین‌کننده نرم‌افزارهای مدیریت IT و جریان کاری مبتنی بر AI) رخ داد. در آن مورد، یک پایگاه داده Elasticsearch به طور تصادفی به صورت عمومی در دسترس قرار گرفت و اطلاعات ۴۸۳ هزار بیمار از Catholic Health افشا شد. اگرچه آن مورد یک نشت پایگاه داده بود و نه نشت پنجره متنی، اما ریشه هر دو یکی است: جمع‌آوری رکوردهای حسامی که هرگز با عملکرد واقعی عامل محدود نشده بودند (Scoping)، که از نظر ساختاری با نحوه مدیریت PII کارکنان در امروز یکسان است.

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

• عامل‌های مالی: یک عامل تطبیق حسابات که به API منابع انسانی دسترسی دارد، می‌تواند به فیلدهای حقوقی دست یابد که هرگز قرار نبود آن‌ها را پردازش کند.
• عامل‌های بهره‌وری: عاملی که ایمیل‌ها را خلاصه می‌کند، ممکن است ارزیابی‌های عملکرد، اطلاعیه‌های اخراج و درخواست‌های تسهیل شرایط کاری (Accommodation requests) را از رشته‌های ایمیلی مجاور جذب کند.
• عامل‌های کدنویسی: عاملی که در حال رفع باگ در یک ماژول پرداخت است، ممکن است با شماره‌های تامین اجتماعی (SSN) که در داده‌های تست جاسازی شده‌اند، مواجه شود.

در هیچ‌یک از این موارد، عامل اعلام نمی‌کند که چه چیزی را جمع‌آوری کرده است یا چرا این کار را انجام داده است.

برخورد با چارچوب‌های قانونی

هوش مصنوعی عامل‌محور اکنون با سه چارچوب قانونی بزرگ در تضاد است و محاسبات مربوط به نحوه برخورد با داده‌های کارکنان را تغییر می‌دهد:

۱. HIPAA و انطباق بهداشتی
در سازمان‌های بهداشتی، انتخاب‌های مربوط به مزایای بهداشتی، مستندات FMLA و رکوردهای تسهیل شرایط کاری، جزو «اطلاعات حفاظت‌شده بهداشتی» (PHI) هستند. استاندارد شناسایی کاربر منحصربه‌فرد در HIPAA (بند 45 CFR § 164.312(a)(2)(i)) ایجاب می‌کند که دسترسی به PHI برای هر فرد قابل ردیابی باشد. وقتی چندین عامل از یک حساب خدماتی مشترک استفاده می‌کنند، ردپای حسابرسی (Audit Trail) نابود می‌شود. در اینجا هیچ زنجیره توثیقی (Chain of Custody) وجود ندارد و تنها یک گزارش اعتبارنامه باقی می‌ماند که نمی‌تواند این الزام قانونی را برآورده کند.

۲. GDPR و اصل کمینه‌سازی داده‌ها
ماده ۵(۱)(ج) قانون GDPR اروپا ایجاب می‌کند که داده‌های شخصی «کافی، مرتبط و محدود به آنچه برای هدف پردازش ضروری است» باشند. ماهیت «بازیابی گسترده برای پاسخ کوتاه» در پنجره‌های متنی، مستقیماً با این استاندارد در تضاد است، به‌ویژه زمانی که داده‌های کارکنان اتحادیه اروپا در محدوده باشند. علاوه بر این، در ۱۹ مارس ۲۰۲۶، هیئت حفاظت از داده‌های اروپا (EDPB) یک اقدام اجرایی هاهنگ در ۲۵ سازمان حفاظت از داده اروپا آغاز کرد که دقیقاً تعهدات شفافیت در پردازش‌های خودکار را هدف قرار داده بود؛ تعهداتی که به سیستم‌های هوش مصنوعی عامل‌محور نیز تعمیم می‌یابد.

۳. CCPA و تصمیم‌گیری خودکار
از ۱ ژانویه ۲۰۲۶، قوانین «تکنولوژی تصمیم‌گیری خودکار» (ADMT) در کالیفرنیا الزام می‌کند زمانی که سیستم‌های خودکار تصمیمات consequential (سرنوشت‌ساز) درباره افراد می‌گیرند، افشای معنا‌داری صورت گیرد. این قانون شامل کارکنان نیز می‌شود. عامل‌های AI که برای جریان‌های کاری HR (مانند زمان‌بندی، تحلیل عملکرد یا تخصیص وظایف) استفاده می‌شوند، ممکن است تعهدات ADMT را فعال کنند که اکثر تیم‌های حقوقی هنوز آن‌ها را در برابر استقرار‌های فعلی خود ارزیابی نکرده‌اند.

بازتعریف سیاست‌های PII

سازمان‌ها باید بین «سیاست دسترسی به داده» (Data Access Policy) و «سیاست PII عامل» (Agent PII Policy) تفاوت قائل شوند. سیاست دسترسی تعیین می‌کند که کدام اعتبارنامه‌ها می‌توانند به کدام سیستم‌ها دسترسی داشته باشند. اما سیاست PII عامل متفاوت است: این سیاست کنترل می‌کند که چه داده‌ای می‌تواند وارد پنجره متنی مدل شود، فارغ از اینکه اعتبارنامه‌های حساب خدماتی قادر به بازیابی چه اطلاعاتی هستند.

حاکمیت موثر نیاز به «رهگیری پیش از اجرا» (Pre-execution Interception) دارد، نه «تشخیص پس از پردازش» (Post-processing Detection). ابزارهای امنیتی سازمانی به طور سنتی پیرامون تشخیص ساخته شده‌اند: ثبت اتفاقات و هشدار در صورت تخلف. برای عامل‌های AI، این روش از نظر ساختاری ناکافی است. زمانی که PII وارد یک پنجره متنی شد و روی تکمیل مدل (Model Completion) اثر گذاشت، نشت رخ داده است. سیاست‌ها باید در لایه بازیابی (Retrieval Layer) عمل کنند و فیلدهای غیرمرتبط را از پاسخ‌های فراخوان ابزار (Tool call responses) پیش از رسیدن به مدل حذف کنند.

حاکمیت همچنین نیازمند اجرای محدوده (Scope Enforcement) در سطح عامل است، نه در سطح اعتبارنامه. مجوزهای حساب خدماتی، پیکربندی زیرساختی هستند؛ اما سیاست PII عامل، لایه مجزایی است که به ازای هر جریان کاری مشخص می‌کند کدام انواع داده در متن مجاز هستند. به عنوان مثال، یک عامل مالی نباید آدرس منزل کارکنان را پردازش کند، حتی اگر حساب خدماتی آن از نظر فنی توانایی بازیابی آن‌ها را داشته باشد. این‌ها تصمیمات سیاستی هستند که سیستم‌های استاندارد RBAC (کنترل دسترسی مبتنی بر نقش) نمی‌توانند اعمال کنند، زیرا RBAC برای کاربران انسانی طراحی شده بود، نه برای ساخت پنجره‌های متنی. این چالش‌های حاکمیتی نشان می‌دهد که چرا تکیه صرف بر نظارت انسانی دیگر پاسخگو نیست و حتی غول‌هایی چون آمازون نیز به دلیل شکست‌های سیستمیک در مدل‌های قدیمی نظارت، در حال تغییر استراتژی‌های ایمنی خود هستند.

پیاده‌سازی با Waxell

شرکت Waxell سعی دارد این شکاف را با ابزار Waxell Observe پر کند. این ابزار عامل‌های هوش مصنوعی را در لایه جذب متن (Context Ingestion Layer) تنها با دو خط کد و بدون نیاز به بازسازی (Rebuild) تجهیز می‌کند. این ابزار داده‌ها را در بیش از ۲۰۰ کتابخانه و چارچوب پشتیبانی شده — از جمله LangChain، CrewAI، AutoGen، OpenAI و Anthropic — رهگیری می‌کند. این سیستم قوانین شناسایی و سانسور (Redaction) را از ۵۰ دسته‌بندی سیاستی شامل PII، حریم خصوصی، انطباق و هویت اعمال می‌کند. این فرآیند، زنجیره توثیق مورد نیاز برای اصل پاسخگویی در GDPR (ماده ۵(۲)) و الزامات حسابرسی دسترسی HIPAA را ایجاد می‌کند.

برای دستیارهای تامین‌کننده و ابزارهای متصل به MCP، ابزار Waxell MCP Gateway در لایه ترانزیت عمل می‌کند تا موارد زیر را تضمین کند:

• سانسور در لحظه (In-flight Redaction): داده‌های PII پیش از رسیدن به مدل دستیار شناسایی و حذف می‌شوند، فارغ از اینکه کدام عامل درخواست را ارسال کرده است.
• مسدودسازی اسرار (Secret Blocking): کلیدهای API، توکن‌ها و اعتبارنامه‌های جاسازی شده به طور کامل مسدود شده و هرگز از گیت‌وی خارج نمی‌شوند.
• انگشت‌نگاری ابزار (Tool Fingerprinting): این قابلیت تضمین می‌کند که تنها اتصالات تأیید شده توسط سازمان، همان‌هایی باشند که دستیار در واقعیت از آن‌ها استفاده می‌کند.

برای جریان‌های کاری با ریسک بالا — مانند HR بهداشتی، سیستم‌های جبران خدمات مالی یا پرونده‌های رگولاتوری که پردازش اشتباه در آن‌ها غیرقابل بازگشت است — Waxell Runtime اجرای سیاست‌ها را پیش از هر گام عملیاتی (Pre-execution) فراهم می‌کند. از طریق گیت‌های سیاستی (Policy Gates)، محدودیت‌های بودجه و نقاط بازرسی جریان کاری بادوام (Durable Workflow Checkpoints)، حاکمیت داده بخشی جدایی‌ناپذیر از محیط اجرا می‌شود.

این معماری ترکیبی، یک لایه اجرای حریم خصوصیِ محدود-محدوده و قابل حسابرسی ایجاد می‌کند که بین مجوزهای حساب خدماتی و زمینه مدل عمل می‌کند. این کار باعث تولید آثارستندهای انطباقی (Compliance Artifacts) می‌شود که حسابرسی‌های GDPR، تحقیقات OCR در HIPAA و اجرای قوانین CCPA به آن‌ها نیاز خواهند داشت.

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

سوالات متداول

چرا حاکمیت PII کارکنان در عامل‌های AI سخت‌تر از PII مشتریان است؟
حاکمیت PII مشتریان دارای مرزهای تعریف شده است: جریان‌های رضایت، ذخیره‌سازهای داده ساختاریافته و برنامه‌های رگوله‌شده با مرزهای شفاف. داده‌های کارکنان در سیستم‌های عامل‌محور این مرزها را ندارند. عامل‌های داخلی به طور هم‌زمان دایرکتوری‌های HR، مجموعه‌های بهره‌وری، کدهای منبع و پایگاه‌های داده عملیاتی را در بر می‌گیرند؛ در حالی که هیچ‌کدام از این‌ها با این فرض طراحی نشده بودند که یک AI بخواهد پنجره‌های متنی را از محتویات آن‌ها بسازد. PII کارکنان از مسیرهایی وارد زمینه‌های مدل می‌شوند که هیچ سیاست داده‌ای در حال حاضر به طور خاص به آن‌ها نمی‌پردازد.

آیا GDPR روی PII کارکنان پردازش شده توسط عامل‌های AI اعمال می‌شود؟
بله. تعهد کمینه‌سازی داده (ماده ۵(۱)(ج)) و اصل پاسخگویی (ماده ۵(۲)) در GDPR بر هرگونه پردازش داده‌های شخصی افراد اتحادیه اروپا، از جمله کارکنان، اعمال می‌شود. عامل‌های AI که رکوردهای کارکنان را بازیابی می‌کنند باید پردازش را به آنچه برای هدف ذکر شده ضروری است محدود کنند و باید بتوانند انطباق خود را اثبات کنند. اقدام اجرایی هماهنگ EDPB در مارس ۲۰۲۶، که ۲۵ سازمان حفاظت از داده اروپا را در بر می‌گرفت، به طور خاص تعهدات شفافیت در پردازش خودکار را بررسی کرد که سیستم‌های AI عامل‌محور را نیز شامل می‌شود.

استاندارد شناسایی کاربر منحصربه‌فرد HIPAA چگونه روی عامل‌های AI اعمال می‌شود؟
بند 45 CFR § 164.312(a)(2)(i) ایجاب می‌کند که دسترسی به PHI الکترونیکی از طریق شناسه‌های منحصربه‌فرد تخصیص یابد تا کاربران واقعی قابل شناسایی و ردیابی باشند. وقتی چندین عامل AI تحت یک حساب خدماتی مشترک عمل می‌کنند، دسترسی به PHI را نمی‌توان به یک عامل مسئول خاص یا انسانی که تسک را مجاز کرده است، ردیابی کرد. این موضوع مستقیماً با الزامات حسابرسی دسترسی HIPAA در تضاد است. هر عاملی که به سیستم‌های حاوی PHI دسترسی دارد، نیاز به هویت مجزای خود در ردپای حسابرسی دارد.

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

سریع‌ترین مسیر برای حاکمیت PII کارکنان در یک سیستم عامل موجود چیست؟
بدون بازسازی معماری زیربنایی، سریع‌ترین مداخله، تجهیز در سطح SDK در لایه جذب متن است. Waxell Observe با ۲ خط کد مقداردهی اولیه می‌شود، نیاز به بازسازی ندارد و می‌تواند روی یک عامل موجود بدون تغییر در منطق زیربنایی اعمال شود. برای دستیاران تامین‌کننده متصل به MCP، مسیریابی از طریق یک گیت‌وی تحت نظارت که سانسور PII را در حین ترانزیت اعمال می‌کند، پوشش امنیتی را بدون تغییر در پیکربندی دستیار فراهم می‌کند.

آیا سازمان‌ها باید داده‌های کارکنان را از تمام زمینه‌های عامل‌ها مسدود کنند؟
ممنوعیت کامل برای جریان‌های کاری که به اطلاعات خاص کارکنان وابسته هستند، غیرعملی است. استاندارد عملیاتی، کمینه‌سازی داده با توجیه صریح است: هر فیلدی که در زمینه یک عامل ظاهر می‌شود باید دلیل مستندی برای حضورش نسبت به آن تسک داشته باشد و فیلدهای بدون توجیه باید حذف شوند. این همان استاندارد ماده ۵(۱)(ج) GDPR است که بر مکانیسم‌های ساخت پنجره متنی اعمال شده است و اجرای آن نیازمند ابزارهایی است که در لایه بازیابی عمل کنند، نه در لایه ثبت گزارشات (Logging).

گام بعدی شما

• تفکیک دسترسی‌های حساب خدماتی (Service Account) از سیاست‌های ورود داده به پنجره متنی مدل.
• بررسی جریان‌های کاری عامل‌های HR و مالی برای شناسایی فیلدهای غیرضروری که در Prompt ارسال می‌شوند.
• تست ابزارهای لایه گیت‌وی برای متوقف کردن نشت کلیدهای API در اتصالات MCP.

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