IBM Bob ذاتي الاستضافة: لماذا تريد المؤسسات وكيل البرمجة داخل شبكتها؟

في الأول من أكتوبر 2026 أعلنت IBM خيار نشر ذاتي الاستضافة لمنصة Bob، وهي منصتها للتطوير الوكيلي. العنوان يبدو تقنياً محضاً، لكنه يلمس سؤالاً تواجهه مؤسسات كثيرة: كيف تستفيد من وكلاء البرمجة دون أن يغادر كودك المصدري حدود شبكتك؟ في هذا المقال نعرض ما أُعلن فعلاً، ونشرح لماذا تهمّ «السيادة» في أدوات الذكاء الاصطناعي، وما الأسئلة التي ينبغي طرحها قبل اعتماد حل كهذا.

ما الذي أعلنته IBM؟

بحسب بيانات الشركة وما نقلته تقارير صحفية متخصصة، يتيح الخيار الجديد تشغيل Bob في بيئات محلية (on-premises) وسحابات خاصة وسحابات سيادية وبيئات معزولة تماماً عن الإنترنت (air-gapped). الفكرة أن تحتفظ المؤسسة بالتحكم في إقامة البيانات وسياسات الأمان والحوكمة داخل بنيتها القائمة.

أبرز ما ورد:

• المنصة موجهة للمؤسسات التي تمنعها قواعد الأمان أو الامتثال من استخدام منصات ذكاء اصطناعي عامة.
• يمكن تشغيل نماذج مدعومة داخل البيئة المحلية، بما فيها المعزولة، باستخدام نماذج مرخّصة لدى المؤسسة.
• تتوفر أيضاً إعدادات هجينة تتصل بخدمات نماذج خارجية عند الحاجة.
• بحسب تقرير صحفي، تعمل النسخة المستضافة ذاتياً داخل مستوى تحكم خاص بالمؤسسة، فلا حاجة إلى نسخ المستودعات أو دفعها إلى بيئات سحابية خارجية.

وقال نيل سندرسان، المدير العام للذكاء الاصطناعي والأتمتة في IBM، إن مستقبل الذكاء الاصطناعي المؤسسي سيعتمد على الأمان والحوكمة والسيادة.

ما الذي لم يُعلن؟

لم نجد في المصادر التي راجعناها تفاصيل عن التسعير ولا موعد التوفر العام ولا قائمة النماذج المدعومة. وقد لاحظ بعض المحللين الماليين أن استمرار الأثر الإيجابي على سهم الشركة يتوقف على تفاصيل لم تكشفها بعد. لذلك فهذا إعلان اتجاه أكثر منه منتجاً جاهزاً للمقارنة.

لماذا تحتاج المؤسسات إلى استضافة ذاتية؟

وكيل البرمجة ليس مجرد أداة إكمال نص؛ هو يقرأ المستودع ويشغّل أوامر ويعدّل الملفات. وهذا يعني أن كل ما يراه الوكيل قد يمرّ عبر خوادم المزوّد. بالنسبة لشركة تعمل في البنوك أو الاتصالات أو الدفاع، هذا غير مقبول غالباً لأسباب نظامية.

ثلاثة قيود تدفع نحو النشر المحلي

1. إقامة البيانات: بعض الأنظمة تشترط بقاء بيانات معيّنة داخل حدود بلد أو منشأة.
2. حماية الملكية الفكرية: الكود المصدري أصل تجاري لا يريد أصحابه أن يخرج من شبكتهم.
3. التدقيق: المؤسسات المنظَّمة تحتاج سجلات كاملة بما فعله الوكيل وأين، وهذا أسهل حين تكون البنية تحت سيطرتها.

السيادة في الذكاء الاصطناعي لا تعني رفض الوكلاء، بل أن تقرر أنت أين يعمل الوكيل وماذا يرى.

مقارنة بين نمط السحابة العامة والنشر الذاتي

الجانب	خدمة سحابية عامة	نشر ذاتي الاستضافة
مكان الكود	يمر عبر خوادم المزوّد	يبقى داخل شبكتك
سهولة البدء	عالية	تحتاج بنية وفريق تشغيل
التحديثات	تلقائية	تديرها أنت
الامتثال	يعتمد على المزوّد	تحت سيطرتك
التكلفة	اشتراك	بنية تحتية إضافية وصيانة

لا يوجد خيار أفضل بإطلاق؛ الأمر يعتمد على حساسية بياناتك وقدرة فريقك على التشغيل.

أسئلة تطرحها قبل الاعتماد

على مستوى النماذج

هل تملك المؤسسة تراخيص نماذج قادرة على العمل محلياً؟ جودة الوكيل تتأثر بالنموذج، وتشغيل نموذج كبير داخل بيئة معزولة يتطلب عتاداً مناسباً. وقد ناقشنا اقتصاديات العتاد في مقالنا عن رقائق الاستدلال المخصّصة.

على مستوى الأمان

هل يُعزل الوكيل أثناء التنفيذ؟ النشر المحلي يحمي البيانات من الخروج، لكنه لا يعالج وحده خطر أن يتجاوز الوكيل صلاحياته داخل الشبكة. لذلك يبقى العزل وتقييد الأوامر ضرورياً، كما شرحنا في مقال عزل وكلاء الذكاء الاصطناعي.

على مستوى التشغيل

من سيدير التحديثات والمراقبة؟ البيئة المعزولة تعني أن التحديثات تُنقل يدوياً أحياناً، ما قد يؤخر الوصول إلى تحسينات الأمان.

ما الذي يعنيه هذا للسوق؟

يشير الإعلان إلى أن سوق أدوات البرمجة الوكيلية يتفرع. فهناك أدوات مفتوحة تستضيف أي وكيل للأفراد والفرق الصغيرة، وهناك منصات مؤسسية تبيع الحوكمة والتحكم. والمؤسسات الكبرى التي كانت تنتظر قبل تبنّي الوكلاء بسبب قيود الامتثال قد تجد في هذا النمط مدخلاً. أما الفرق الصغيرة فالأرجح أن تبقى على الخدمات السحابية لبساطتها.

نصائح عملية لمن يقيّم الحل

• ابدأ بمشروع تجريبي غير حرج قبل التعميم.
• اطلب من المزوّد توثيقاً واضحاً لمسار البيانات وما يُسجَّل.
• قدّر التكلفة الكلية، شاملةً العتاد وفريق التشغيل، لا سعر الترخيص وحده.
• اختبر الوكيل على مهام حقيقية من مستودعاتك قبل الحكم على جودته.
• حدّد من يملك قرار تحديث النماذج داخل البيئة، وكيف تُختبر النماذج الجديدة قبل اعتمادها.

كيف تبني خطة تبنٍّ واقعية؟

الانتقال من تجربة إلى اعتماد مؤسسي يحتاج مراحل واضحة، وإلا تحوّل المشروع إلى بنية مكلفة لا يستخدمها أحد. هذا تصور عام نقترحه نحن، وليس خطة من IBM.

المرحلة الأولى: تحديد النطاق

اختر فريقاً واحداً ومستودعات محدودة ذات حساسية متوسطة. الهدف في هذه المرحلة هو فهم سلوك الوكيل في بيئتك، لا إثبات العائد المالي. وثّق المهام التي نجح فيها الوكيل والمهام التي أخفق فيها، فهذه البيانات ستكون أساس أي قرار توسّع.

المرحلة الثانية: ضبط الصلاحيات والسجلات

قبل أن يصل الوكيل إلى مستودعات أوسع، حدّد ما يُسمح له بتنفيذه وما يحتاج موافقة بشرية. ثم تأكد أن السجلات تُحفظ في مكان تملكه، وأن فريق الأمان يستطيع مراجعتها دورياً. الوكيل الذي لا تعرف ما فعله لا يمكن الوثوق به مهما كانت البنية محلية.

المرحلة الثالثة: قياس الأثر

قس مؤشرات بسيطة: زمن إنجاز المهام المتكررة، ومعدل رفض مراجعي الكود لما يولّده الوكيل، وعدد الحوادث الأمنية. إن لم تتحسن هذه المؤشرات فلا مبرر للتوسّع مهما بدا الحل جذاباً من حيث السيادة.

أسئلة شائعة

هل النشر الذاتي يعني أن الكود لا يغادر الشبكة أبداً؟

وفق وصف IBM يمكن ذلك في الإعدادات المحلية والمعزولة، لكن الإعدادات الهجينة قد تتصل بخدمات نماذج خارجية. راجع إعدادك لتعرف ما الذي يخرج فعلاً.

هل الخيار متاح لكل العملاء الآن؟

لم تتضح تفاصيل التوفر والتسعير في المصادر التي اطّلعنا عليها، فتواصل مع IBM للتأكد.

هل يناسب الفرق الصغيرة؟

غالباً لا؛ النشر الذاتي يضيف عبء تشغيل لا تحتاجه معظم الفرق الصغيرة.

الخلاصة

إعلان IBM يؤكد أن سؤال «أين يعمل الوكيل؟» صار قراراً معمارياً بقدر سؤال «أي وكيل؟». الحل المحلي يمنحك التحكم، لكنه يطلب منك الاستثمار في البنية والتشغيل والعزل. وبما أن التسعير والتوفر والنماذج المدعومة لم تُكشف بعد، فالأولى أن تتعامل مع الخبر كإشارة اتجاه، وتبني تقييمك على تجربة فعلية في بيئتك.