اگر صورت‌حساب یک پروژهٔ هوش مصنوعی را باز کنید، چیزی که کمتر از تصور هزینه دارد خودِ مدل است. پول کجا می‌رود؟ به همان لایهٔ نامرئی میان مدل و دنیای واقعی سازمان: اتصال به سامانهٔ حساب‌داری، به انبار، به پروندهٔ مشتری، به فایل‌های پراکنده روی شبکهٔ داخلی. این چسبِ سفارشی، بخش گران و شکنندهٔ هر پروژه است.

پروتکل زمینهٔ مدل (MCP) که پایان ۲۰۲۴ به‌صورت باز منتشر شد و در طول ۲۰۲۵ عرضه‌کنندگان بزرگ مدل یکی پس از دیگری آن را پذیرفتند، همین لایه را هدف گرفته است. ایده در یک جمله: به‌جای واسطی اختصاصی برای هر جفتِ «مدل و ابزار»، ابزارها یک بار خود را در قالبی استاندارد معرفی کنند و هر مدلی بتواند آن‌ها را بخواند.

چه چیزی با اتصال استاندارد عوض می‌شود

• کد چسبی کمتر: هر ابزار یک بار در قالب استاندارد آماده می‌شود، نه یک بار برای هر مدل و هر پروژه.
• بازاستفاده به‌جای بازنویسی: اتصالی که برای دستیار پشتیبانی ساخته‌اید، برای دستیار فروش هم کار می‌کند.
• قفل‌شدگی کمتر به فروشنده: با واسط استاندارد، تعویض مدل یک تصمیم فنی کوچک است، نه بازنویسی پروژه.

چرا این نقطه، نقطهٔ درد سازمان‌های ایرانی است

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

ارزش کجا آزاد می‌شود

کاهش هزینهٔ اتصال فقط صرفه‌جویی نیست؛ اقتصاد آزمودن را عوض می‌کند. وقتی راه‌اندازی یک نمونهٔ اولیه چند روز طول بکشد و نه چند ماه، می‌توانید ده فرضیه را بیازمایید و آن‌هایی که جواب نمی‌دهند را ارزان کنار بگذارید. سازمان‌هایی که در هوش مصنوعی جلو می‌افتند لزوماً مدل بهتری ندارند؛ سریع‌تر یاد می‌گیرند. اما یک هشدار لازم است: استاندارد، مسئلهٔ اتصال را حل می‌کند، نه مسئلهٔ کیفیت داده و نه مسئلهٔ فرآیند. اگر دادهٔ انبار آشفته باشد، دسترسی استانداردِ مدل به آشفتگی فقط آن را سریع‌تر منتشر می‌کند.

یک تصویر عملی

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

نقشهٔ ۹۰ روزهٔ شروع

• روز ۱ تا ۳۰: فهرست کنید کدام سامانه‌ها بیشترین درخواست اتصال را دارند و نگه‌داری کدام واسط سفارشی بیشترین وقت تیم فنی را می‌گیرد.
• روز ۳۰ تا ۶۰: یکی از پرتقاضاترین منابع داده را در قالب استاندارد، با دسترسی فقط‌خواندنی و محدود، در اختیار یک نمونهٔ اولیه بگذارید.
• روز ۶۰ تا ۹۰: زمان راه‌اندازی و شمار خطاها را با نسخهٔ قبلی مقایسه کنید؛ اگر بهبود دیدید منبع دوم را اضافه و قاعدهٔ دسترسی را مکتوب کنید.

خطاهای پرتکرار

• باز کردن دسترسی کامل و نوشتنی به سامانه‌های حیاتی در روز اول؛ شروع درست، دسترسی فقط‌خواندنی و محدود به دامنهٔ کار است.
• پنداشتن استاندارد اتصال به‌عنوان پاسخ مسئلهٔ داده؛ استاندارد لوله‌کشی است و کیفیت آب را تضمین نمی‌کند.
• بی‌توجهی به ثبت رخداد؛ اگر ندانید مدل چه خواند و چه کرد، نه عیب‌یابی ممکن است و نه پاسخ‌گویی.
• ساختن ده اتصال پیش از اثبات ارزش نخستین مورد استفاده.

سه اقدام برای همین فصل

• پرهزینه‌ترین یکپارچه‌سازی جاری را از نظر ساعت نگه‌داری شناسایی کنید.
• یک منبع داده را در قالب استاندارد و با دسترسی محدود در دسترس بگذارید.
• اثر را با زمان راه‌اندازی نمونهٔ اولیهٔ بعدی بسنجید.

پرسش‌های پرتکرار

• برای شروع چه چیزی لازم است؟
  یک سامانهٔ داخلی با داده‌ای که همین حالا دارید و یک مورد استفادهٔ مشخص. این یک پروژهٔ زیرساختی چندماهه نیست.
• سامانه‌های ما قدیمی‌اند و واسط برنامه‌نویسی مدرن ندارند؛ باز هم ممکن است؟
  بله، اما به یک لایهٔ میانی نیاز دارید. نکته اینجاست که آن لایه را یک بار می‌نویسید و کاربردهای بعدی از آن استفاده می‌کنند.
• خطر امنیتی چیست؟
  مهم‌ترین خطر، دسترسی بیش از نیاز است. اصل کار: کمترین سطح دسترسی، ثبت کامل رخدادها و تأیید انسانی برای هر عملیات نوشتنی.

جمع‌بندی

در پروژه‌های هوش مصنوعی، گلوگاه سال‌ها هوشمندی مدل نبود؛ لوله‌کشی بود. استاندارد شدن این لوله‌کشی به‌خودی‌خود ارزشی نمی‌سازد، اما هزینهٔ آزمودن را چنان پایین می‌آورد که یادگیری سازمان از پروژه‌های سنگین سالانه به تکرارهای کوچک ماهانه منتقل می‌شود. برای شرکتی با منابع فنی محدود، همین تفاوت مسیر را عوض می‌کند.

واژه‌نامه

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

اقدام این هفته

این هفته، یک جلسهٔ ۹۰ دقیقه‌ای با تیم فنی خود برگزار کنید و فهرستی از تمام اتصال‌های سفارشی فعلی میان سیستم‌ها و ابزارهای داخلی تهیه کنید. برای هر اتصال، سه ستون ثبت کنید: «سیستم مبدأ»، «سیستم مقصد» و «هزینهٔ نگه‌داری ماهانه به ساعت انسانی». سپس دو اتصالی را که بیشترین زمان نگه‌داری را می‌گیرند مشخص کنید و برای یکی از آن‌ها، یک نمونهٔ اولیهٔ فقط‌خواندنی با استاندارد MCP طراحی کنید. هدف این هفته فقط مستندسازی و انتخاب یک کاندیداست؛ نه پیاده‌سازی کامل. اگر در پایان هفته بتوانید یک اسلاید یک‌صفحه‌ای از نقشهٔ اتصال‌های فعلی و یک نامزد مشخص برای استانداردسازی داشته باشید، قدم اول را درست برداشته‌اید.

منابع

• مستندات رسمی پروتکل زمینهٔ مدل (MCP) — راهنمای معماری و شروع سریع برای توسعه‌دهندگان: modelcontextprotocol.io
• «معرفی MCP به زبان ساده» — مقالهٔ تحلیلی در وبلاگ راکت دربارهٔ کاربردهای عملی MCP در سازمان‌ها: blog.roocket.ir/ai/introduction-to-model-context-protocol
• «الگوهای یکپارچه‌سازی سامانه‌های سازمانی با استانداردهای باز» — درس‌آموخته‌هایی از تجربهٔ شرکت‌های ایرانی در یکپارچه‌سازی: virgool.io/@enterprise-integration/standard-open-integration-patterns
• «قفل‌شدگی فنی و راه‌های خروج از آن» — گزارش پژوهشی مرکز نوآوری دانشگاه شریف دربارهٔ هزینه‌های پنهان اتصال‌های اختصاصی: techpark.sharif.ir/research/vendor-lock-in-report
• «معماری داده برای هوش مصنوعی» — راهنمای عملی از دیجیاتو دربارهٔ آماده‌سازی داده پیش از اتصال مدل به سامانه‌ها: digiato.com/article/2025/01/data-architecture-for-ai