یک کارمند صبح دوشنبه ساعت ۹ از تیم مالی جدا می‌شود، اما سیستم همگام‌سازی تنها شبانه ساعت ۲ اجرا می‌گردد. برای هفده ساعت کامل، آن فرد همچنان قادر است اسناد حساس مالی را از نمایه بازیابی (RAG) استخراج کند و هیچ مکانیزمی در سیستم از این ناهنجاری آگاه نمی‌شود. این سناریو را از تیم Truto اقتباس کرده‌ام، اما هر تیمی که با آن گفتگو کرده‌ام، вариانت‌های مشابهی از همین چالش را شناسایی می‌کند.

مشکل ساعت‌دار و کابوس مرور امنیتی

نسخه‌ای که در مرور‌های امنیتی طرح می‌شود، از منظر فنی متفاوت اما از منظر خطر یکسان است: پایлот بازیابی کار می‌کند، دمو موفقیت‌آمیز است، حامیان اجرایی راضی‌اند، و ناگهان کسی می‌پرسد: «چگونه تضمین می‌کنید این سیستم هرگز خلاصه بازبینی حقوق CEO را برای یک کارآموزی که به‌صورت بی‌گناهانه درباره باندهای حقوقی پرسیده، تولید نخواهد کرد؟»

اکثر تیم‌ها پاسخی قانع‌کننده ندارند. تنها ابزار در اختیارشان، یک فیلتر متادیتا ساده روی نتایج بازیابی است.

چرا پاسخ باید ساختاری باشد، نه فیلتری

مجوزها (Permissions) فیلتری نیستند که پس از تجمیع بافت (Context Assembly) روی خروجی اعمال شوند. آن‌ها خاصیتی بنیادین از نحوه تجمیع بافت برای یک هویت خاص هستند. دلیلش ساده است: تجمیع، لحظه آخر است که «امتناع از شامل کردن» یک سند، هنوز به معنی «مدل هرگز آن را ندیده است» می‌باشد. هرچه در بالادست (Upstream) باشد ذخیره‌سازی است، و هرچه در پایین‌دست (Downstream) باشد استنتاج (Inference). تجمیع، جایی است که هویت یا حضور دارد یا ندارد.

من شرکت Modus را در این حوزه می‌سازم، بنابراین این استدلال را با آگاهی از پیشینه‌ی فنی آن ارزیابی کنید. در محصول ما به این مرحله «تولید بافت» (Context Composition) می‌گوییم؛ در این نوشتار از مصطلح «تجمیع بافت» استفاده می‌کنم. این مکانیزم است که تعیین می‌کند کدام قطعات از دانش سازمانی، برای کدام شخص، در کدام لحظه، و برای کدام پرسش به مدل زبان بزرگ (LLM) تحویل داده می‌شوند.

اعلام شده، همان «ارسال شده» (Shipped) نیست

دلیل اینکه این بحث در سپتامبر، نه ژوئن، جدی شده است این است که فروشندگان پلتفرم بزرگ از نظر معماری به توافق رسیده‌اند، اما نرم‌افزاری که اکثر شرکت‌ها در محیط تولید (Production) اجرا می‌کنند، هنوز به آن سطح نرسیده است.

AWS Context: نقشه راه صریح، اما در دسترس نیست

AWS در ژوئن، در قمته نیویورک، AWS Context را اعلام کرد. نکته کلیدی تصمیم طراحی زیرین آن است: گراف دانش (Knowledge Graph) توسط همان مجوزهای Data Lake از طریق Glue Data Catalog، SageMaker Unified Studio و Lake Formation حکومتشده می‌شود و هویت مجدداً در لحظه پرس‌وجو بررسی می‌گردد. خط‌مشی‌های سطح ستون، ردیف و سلول (Column/Row/Cell-level policies) چیزی هستند که مجوزهای شیء S3 به تنهایی نمی‌توانند تأمین کنند.

اما دقت در زمان فعل (Tense) حیاتی است: «طراحی شده تا مجوزهای IAM و Lake Formation را ارث ببرد». این زبان نقشه‌ راه (Roadmap language) است. نزدیک به سه ماه پس از اعلام، AWS Context همچنان با برچسب Coming Soon فهرست شده، بدون تاریخ GA، بدون لیست منطقه‌ای و بدون قیمت‌گذاری. Amazon Bedrock Managed Knowledge Base در همان روز GA شد، که بیشتر دلیل خلط این دو در ذهن بازار است.

مایکروسافت: تحویل واقعی در ۱۶ ژوئن

روز قبل از اعلام AWS، API Work IQ مایکروسافت به صورت عمومی در دسترس (GA) قرار گرفت. این API در بافت کاربر واردشده (Signed-in User) اجرا می‌شود، مجوزهای Microsoft 365 را محترم می‌شمارد، از طریق اعتبارهای Copilot قابل صورتحساب است و یک مدیر می‌تواند همین امروز آن را فعال کند. دو اعلامیه با یک روز اختلاف، یک موقعیت معماری، اما فقط یکی قابل استقرار در تولید (Production) است.

Databricks: رویکرد از سمت Runtime

Databricks با گسترش Unity Catalog به عامل‌های هوشمند (Agents) به همان نقطه رسیده است. با این حال، شرکای اکوسیستم توجه کرده‌اند که حفاظت به Databricks Runtime لنگر انداخته شده، نه به خود داده‌ها. در نتیجه، وقتی یک ابزار BI یا سرور MCP مستقیماً به همان منبع داده می‌رسد، کنترل از بین می‌رود.

مقایسه معماری تجمیع بافت در AWS، مایکروسافت و Databricks

تیم‌ها منتظر نماندند: ریسک نمایه تخت (Flat Index)

تیم‌های مهندسی برای هیچ‌کدام از این قابلیت‌های بومی صبر نکردند. آن‌ها نسخه «نمایه تخت» (Flat-index version) را ارسال کردند در حالی که نسخه هویت‌آگاه (Identity-aware) تنها روی اسلایدهای معماری باقی مانده بود. نتیجه؟ یک بافت تجمیع شده که در لحظه کوئری، هویت پرسش‌کننده را نمی‌شناسد و مجوزها را به عنوان یک پیش‌فیلتر یا پس‌فیلتر ناکارآمد تلاش می‌کند جبران کند.

چالش بین‌سیستمی: دریاچه (Lake) کسب‌وکار نیست

Lake Formation مجوزهای ریزگرد (Fine-grained) را درون دریاچه‌ای که حکومتشده می‌کند به خوبی اعمال می‌کند. اما این مجوزها به قوانین اشتراک‌گذاری در Salesforce، Slack، Google Drive یا Confluence تبدیل نمی‌شوند. AWS در راهنمای اوتگوست خود مرزها را مستند کرده: عامل (Agent) به عنوان یک ارکسترتر (Orchestrator) عمل می‌کند، نه گیت‌کیپر (Gatekeeper). توکن به محدوده کاربر واقعی برای Salesforce تحویل داده می‌شود تا Salesforce قوانین اشتراک‌گذاری خودش را اعمال کند. خدمات پایین‌دست (Downstream services) مجوزدهی را اجرا می‌کنند.

این انتخاب معقولی برای معماری مرجعی است، اما پیاده‌سازی آن در مقیاس سازمانی، لایه تجمیع بافتی را می‌طلبد که بتواند هویت را در سراسر سیستم‌های ناهمگن تدوین (Federate) کند، بدون اینکه داده‌ها را کپی یا центраلیزه نماید.

آینده: تجمیع بافت به عنوان لایه کنترل هویت

جهت واحد است: کنترل دسترسی باید از لایه ذخیره‌سازی جدا شده و در لایه تجمیع بافت متمرکز شود. هرکدام از پلتفرم‌ها (AWS، Microsoft، Databricks) قوی‌ترین کنترل را در اکوسیستم خود دارند. مقیاس واقعی چالش زمانی است که یک عامل نیاز به بافتی دارد که همزمان چندین از این سیستم‌ها را بکشد — و این دقیقاً وظیفه لایه تجمیع است، نه لایه ذخیره‌سازی و نه لایه مدل.

سازمانی که امروزه همچنان بر روی فیلترهای متاداتا تکیه دارد، در واقع روی بوم زمان (Time-of-check to Time-of-use gap) قمار می‌کند. راهکار فیلتره، راهکار موقت است؛ معماری تجمیع بافت هویت‌آگاه، راهکار دائمی است.