تغییر Mistral بدون مهاجرت خودکار؛ مدیران باید واکنش نشان دهند

Mistral اعلام کرده هنگام جایگزینی کانکتورهای Google Drive و SharePoint با نسخه‌های مبتنی بر MCP، هیچ مهاجرت خودکاری انجام نخواهد داد. بنابراین پیش از آنکه کاربران حساب Google یا Microsoft خود را دوباره متصل کنند، مدیران سازمانی باید جایگزین‌های مبتنی بر MCP را نصب و پیکربندی کنند. این جابجایی شیوهٔ دسترسی Vibe Work به اسناد شرکت را تغییر می‌دهد و هنوز جزئیات معماری بازیابی و محل پردازش اسناد توسط Mistral به‌طور شفاف اعلام نشده است.

مقایسهٔ مدل فعلی با مدل مبتنی بر MCP

در معماری کنونی، مدیر مشخص می‌کند کدام پوشه‌های Google Drive یا سایت‌های SharePoint قابل جستجو باشند؛ سپس Mistral آن فایل‌ها را نمایه‌سازی و نمایهٔ نهایی را در مراکز دادهٔ اروپایی ذخیره می‌کند. پس از آماده‌شدن نمایه، کاربران حساب‌های شخصی‌شان را وصل می‌کنند و هنگام جستجو در Vibe Work، کانکتور با بررسی مجوزهای منتقل‌شده از منبع تنها فایل‌هایی را بازمی‌گرداند که برای آن کاربر مجاز است. این فرآیند جستجوی سریع از روی یک ایندکس پیش‌ساخته را ممکن می‌سازد؛ زمان ساخت نمایه بسته به حجم داده از چند دقیقه تا چند ساعت متغیر است اما قبل از شروع جستجوها تکمیل می‌شود.

MCP چیست و چرا تغییر اهمیت دارد

MCP را می‌توان به‌عنوان لایه‌ای پروتکلی تعریف کرد که شیوهٔ فراخوانی ابزارها و بازیابی داده‌ها از سرویس‌های خارجی را استاندارد می‌کند. این لایه نحوهٔ اتصال محصولات هوش مصنوعی به APIهای خارجی را بازتعریف می‌کند. Mistral در ژوئن Google Drive و SharePoint را به فهرستی که بیش از 60 یکپارچگی دارد اضافه کرد؛ با این حال توضیح نداد این کانکتورها کجا و چگونه اسناد را بازیابی می‌کنند و چه کسی سرورهای MCP را اداره خواهد کرد.

الگوهای رایج بازیابی

  • تماس زنده با API منبع: هر درخواست جستجو مستقیماً از مبدا پرس‌وجو می‌شود و داده‌ها هنگام نیاز خوانده می‌شوند.
  • ایندکس سروری مدیریت‌شده: یک سرور خارجی نمایهٔ جستجو را نگهداری می‌کند و پاسخ‌ها را از روی آن می‌دهد.
  • مدل ترکیبی: استفاده از کش محلی یا سرور و فراخوانی‌های آنی برای بهینه‌سازی تأخیر و هزینه.

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

ابهام در قواعد دسترسی و نگهداری داده

Mistral اعلام کرده سرورهای ثالث را برای کانکتورها اجرا نمی‌کند؛ بنابراین نمی‌تواند رفتار این سرورها نسبت به داده‌های مشتری یا سیاست‌های کش و نگهداری را تضمین کند. اطلاعیهٔ مهاجرت روشن نکرده آیا سرورهای MCP فایل‌ها را مستقیماً از Google و Microsoft می‌خوانند یا ابتدا کش می‌کنند و آیا نگهداری موقت محتوا خواهند داشت. این ابهامات باعث تردید در مورد محل باقی‌ماندن نمایه‌های قبلی و تغییرات احتمالی در عملکرد و کیفیت نتایج جستجو می‌شود.

مسئلهٔ مجوزها

کانکتور فعلی Google Drive بر قواعد اشتراک‌گذاری متصل به هر فایل تکیه دارد؛ شامل دسترسی گروهی و دامنه‌ای. SharePoint از گروه‌های Microsoft Entra ID استفاده می‌کند و گاهی گروه‌های داخلی قدیمی SharePoint را به‌درستی بازتولید نمی‌کند. هنوز مشخص نیست جایگزین‌های مبتنی بر MCP همین قواعد را رعایت خواهند کرد یا نه. اگرچه OAuth می‌تواند دسترسی سرور را به سطح کاربر محدود کند، خودِ پروتکل برای پیاده‌سازی تمام مدل‌های پیچیدهٔ مجوز سازمانی طراحی نشده است؛ لایهٔ بازیابی کانکتور باید فیلترینگ مجوزها را اعمال کند تا کاربران تنها به نتایجی دسترسی یابند که پیش‌تر برایشان قابل مشاهده بود.

صفحهٔ نمایش داشبورد مدیریت کانکتورها

اقدامات فوری برای مدیران — چک‌لیست

  • نصب و پیکربندی: جایگزین‌های مبتنی بر MCP را پیش از اجازهٔ اتصال مجدد کاربران نصب کنید؛ مهاجرت خودکار انجام نخواهد شد.
  • بررسی اسکوپ‌ها: اسکوپ‌های OAuth را بازبینی و دسترسی‌ها را به حداقل مورد نیاز محدود کنید.
  • شفاف‌سازی سیاست کش: از اپراتور MCP دربارهٔ محل نگهداری ایندکس، دورهٔ کش و نگهداری موقت محتوا پرس‌وجو کنید.
  • آزمون تطابق نتایج: چند جستجوی نمونه اجرا و نتایج را با نمایهٔ قبلی مقایسه کنید تا تغییر در کیفیت یا دسترسی را شناسایی کنید.
  • الگوی حذف داده: جدول زمانی و مکانیزم حذف ایندکس پس از غیرفعالسازی کانکتور را از اپراتور بخواهید.
  • نظارت و لاگ‌گذاری: گزارش‌ها و لاگ‌ها را فعال کنید و خروجی سرورها را برای نشانه‌های حمله یا تزریق پرامپت بررسی کنید.
  • گسترش بررسی‌ها: بررسی‌های امنیتی را به سایر سیستم‌هایی که از همین کانکتورها استفاده می‌کنند (مثلاً Vibe Code و گردش کارها) تعمیم دهید.

حاکمیت و ریسک‌های عملیاتی

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

پیشنهاد نهایی و گام‌های بعدی

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

برای مطالعهٔ بیشتر دربارهٔ مفاهیم دخیل می‌توانید صفحهٔ Mistral AI و مرجع OAuth را بررسی کنید یا گزارش‌های مرتبط در TechCrunch را دنبال نمایید.