مجموعة بوسطن الاستشارية (BCG) تؤكد أن الاستراتيجية أهم من الأدوات — الجزء الثاني: من تبني الوكلاء إلى حوكمة الأدوات وبيئات التشغيل

تناول الجزء الأول منشورين لشركة BCG معاً — وهما الذكاء الاصطناعي في العمل استطلاع عام 2026 (يونيو) و دليل القيادة الوكيلة: استراتيجية التوسع لرؤساء التكنولوجيا ورؤساء المعلومات (أوائل يوليو 2026؛ بقلم الممارسين مارك أبراهام ونيفين عوض) — وربطت نتائج مختارة من الاستطلاع والقيادة بضوابط بوابة الذكاء الاصطناعي الموثقة. يتناول هذا الجزء نتائج الوكلاء في كلا الوثيقتين — إحصائيات الاستطلاع حول التبني مقابل الحوكمة، وملاحظات الممارسين في الدليل حول ما يتغير عندما يقوم الوكلاء بالتنفيذ بدلاً من مجرد تقديم التوصيات — ويواصل اتباع نفس النمط المعتمد في كل قسم، مستكملاً ما بدأه الجزء الأول: بناء الوكلاء على أساس متين، وفحص تنفيذهم القابل للمراقبة ونتائجهم المقاسة، والتوسع مع زيادة الثقة. تشير تقارير BCG إلى أن الوكلاء ينتشرون بسرعة بينما تتخلف الحوكمة: يقول حوالي 30% من المشاركين إن مؤسساتهم دمجت وكلاء الذكاء الاصطناعي في سير العمل، ويتوقع حوالي 61% أن يقوم الوكلاء بنصف مهام وظائفهم في غضون ثلاث سنوات، ومع ذلك يقول حوالي نصف المشاركين إن شركاتهم تفتقر إلى حوكمة واضحة للفرق التي تضم بشراً وذكاءً اصطناعياً. يطبق هذا الجزء نفس المنهج التحريري على نتائج الوكلاء هذه، متسائلاً كيف يمكن للوصول الموجه إلى الأدوات (بوابة MCP) وبيئة التشغيل المُدارة (Agent Harness) معالجة جزء من الفجوة في نموذج التشغيل. وكما في الجزء الأول، تمت إعادة صياغة أرقام BCG مع الاستشهاد بالمصادر الأساسية، وتم الاستشهاد بالقدرات ضمنياً في وثائق TrueFoundry.

1. ملخص: النمط، ومكانة نتائج الوكلاء

وضع الجزء الأول المنهجية: تحدد BCG فجوة؛ ويرتبط ضابط موثق بجزء تقني منها؛ بينما تظل قرارات التشغيل بيد المؤسسة. كانت نتائجها تتعلق بحركة مرور النماذج وتتوافق مع بوابة الذكاء الاصطناعي (AI Gateway). تختلف نتائج الوكلاء لدى BCG في طبيعتها. الوكيل ليس مجرد استدعاء لنموذج واحد؛ بل هو حلقة تخطط، وتستدعي الأدوات، وتراقب النتائج، وتقرر ما إذا كانت ستستمر — وتصل استدعاءات الأدوات هذه إلى أنظمة حقيقية وتتطلب بيانات اعتماد حقيقية. لذا، فإن حوكمة الوكيل تعني حوكمة أمرين لا تغطيهما بوابة الذكاء الاصطناعي وحدها بشكل كامل: الأدوات التي يستدعيها الوكيل، وبيئة التشغيل التي تدير هذه الحلقة.

ولهذا السبب يقدم هذا الجزء قدرتين إضافيتين بدلاً من إعادة استخدام الأولى. تعمل بوابة MCP على حوكمة الوصول إلى الأدوات — أي حركة مرور بروتوكول سياق النموذج (Model Context Protocol) بين الوكلاء والأنظمة التي يعملون عليها. أما Agent Harness فهي بيئة التشغيل التي تدير حلقة الوكيل مع حوكمة مدمجة. تتناول الأقسام أدناه هذه القدرات بالتتابع: العجز، وحوكمة الأدوات، وبيئة التشغيل، ثم إعادة تصميم سير العمل والنشر.

2. النتيجة: الوكلاء ينتشرون أسرع من حوكمتهم

تحمل بيانات الوكلاء لدى BCG فرصاً وتحذيرات في آن واحد: يقول حوالي 30% من المشاركين إن مؤسساتهم دمجت وكلاء الذكاء الاصطناعي في سير العمل — ارتفاعاً من 13% في العام السابق — ويعتقد حوالي 61% أن الوكلاء يمكنهم أداء نصف مسؤوليات وظائفهم على الأقل في غضون ثلاث سنوات (bcg.com/press/3june2026). وبجانب ذلك تأتي قراءة الحوكمة: يقول حوالي نصف المشاركين إن شركاتهم تفتقر إلى حوكمة واضحة لإدارة الفرق التي تضم بشراً وذكاءً اصطناعياً، وتشير الأغلبية إلى فهم محدود لماهية الوكلاء.

إن سباق التبني الذي يسبق الحوكمة يعد أكثر خطورة بالنسبة للوكلاء مقارنة بالدردشة، لأن الوكيل يقوم بالتنفيذ، ويربط الإجراءات عبر الأدوات، وغالباً ما يحمل بيانات اعتماد للقيام بذلك. لذا، فإن وجود عدد غير خاضع للحوكمة من الوكلاء يمثل مخاطرة قائمة — وكلاء غير مسجلين، وبيانات اعتماد مضمنة، ووصول غير خاضع للتدقيق إلى الأدوات. ويشير الدليل، الذي نُشر بعد شهر من وجهة نظر معاكسة، إلى نفس النمط: حوالي 5% من الشركات تعتمد نهج "الوكيل أولاً"، بينما تقل نسبة التبني لدى معظم الشركات الأخرى عن 30%، ويُعزى هذا الاختلاف إلى القيادة وانضباط التغيير وليس إلى اختيار النموذج (الدليل). كما يوضح الدليل سبب أهمية فجوة الحوكمة للوكلاء أكثر من الدردشة: فالوكلاء ينفذون بدلاً من تقديم التوصيات، لذا فإن تكلفة المدخلات الخاطئة تتحول من شريحة عرض مضللة إلى إجراء خاطئ — ومثال الممارسين هو تعريف معيب لـ "العميل المنقطع" يؤدي إلى إفساد حملة تسويقية. الفجوة التي تقيسها BCG من القوى العاملة هي نفس الفجوة التي يراها فريق البنية التحتية من الأعلى، والقسمان التاليان يربطانها بسطحي تحكم تقنيين موثقين يمكنهما معالجة جزء منها: الوصول إلى الأدوات عبر MCP، ثم بيئة تشغيل وكيل خاضعة للحوكمة.

3. حوكمة ما يستدعيه الوكلاء ← بوابة MCP

يتمثل النصف الأول من حوكمة الوكلاء في الأدوات. يصل العديد من الوكلاء إلى الأنظمة الخارجية من خلال الأدوات، وبشكل متزايد عبر بروتوكول سياق النموذج (Model Context Protocol)؛ وأينما حدث ذلك، يطرح كل فريق أمني السؤال نفسه: باستخدام بيانات اعتماد من؟ وتحت أي تفويض؟ ومع أي سجل تدقيق؟ يتماشى هذا مع بوابة MCP. وفقاً لوثائق TrueFoundry، تقع مصادقة أدوات الوكيل في بوابة MCP بدلاً من الوكيل نفسه: حيث يستدعي الوكلاء الأدوات بالاسم، وتتولى البوابة حقن بيانات الاعتماد، وتحديث الرموز المميزة، والتفويض لكل مستخدم (docs/agent-platform/agent-harness/overview). تضيف واجهة المنتج عناصر التحكم التي تجعل هذا الأمر بمستوى مؤسسي: توجيه استدعاءات أدوات MCP عبر خوادم مسجلة، وتطبيق OAuth2، والتحكم في الوصول المستند إلى الأدوار (RBAC)، والسياسات المستندة إلى البيانات الوصفية على استدعاءات الأدوات التي تتم عبر البوابة، بالإضافة إلى تتبع تلك الاستدعاءات ونسبها لأغراض المراجعة الأمنية والامتثال (خوادم MCP في وثائق Agent Harness).

يعالج هذا ما يجعل الوكلاء غير الخاضعين للحوكمة خطيرين: فالمصادقة المركزية التي تديرها البوابة تقلل من الحاجة إلى تضمين بيانات الاعتماد في تعريفات الوكيل، مما يجعل بيانات الاعتماد أسهل في التدوير، وتحديد النطاق، والإبطال، حيث يتم الاحتفاظ بها مركزياً بدلاً من لصقها في ملفات التكوين. يمكن للهوية المركزية، والتفويض، والتحكم في الوصول المستند إلى الأدوار (RBAC) لكل أداة، وقيود الأدوات أن تساعد في تقليل مخاطر "النائب المرتبك" (confused-deputy) والصلاحيات المفرطة. ولأن استدعاءات الأدوات التي تتم عبر البوابة يتم تتبعها ونسبها، فإن السؤال الضمني لشركة BCG — أي وكيل فعل ماذا، وبأي نظام، ومع أي بيانات — أصبح له إجابة بالنسبة لحركة المرور التي تمر عبر البوابة. تعمل بوابة MCP على توسيع نطاق حواجز الحماية من الجزء الأول لتشمل استدعاءات الأدوات: وهو نفس مبدأ "الحوكمة عند البوابة"، المطبق على الإجراءات التي يتخذها الوكيل بدلاً من النص الذي يولده. كما أنها تمثل الشكل الملموس لعقيدة البيانات الخاصة بدليل التشغيل. عندما ينصح الممارسون ببناء وكلاء يعتمدون على نواة موثوقة من البيانات وتوسيع النطاق مع زيادة الثقة، فإن السجل يعد آلية واحدة للتحكم في الوصول حول تلك النواة الموثوقة: فهو يقيد الخوادم والأدوات المعتمدة التي قد يستخدمها الوكيل، ضمن نطاق RBAC والتفويض لكل مستخدم، ويعد توسيع هذا النطاق تغييراً متعمداً وقابلاً للتدقيق في السجل. ومع ذلك، لا يزال يتعين على المؤسسة تحديد جودة البيانات الأساسية ومصدرها وصحتها الدلالية.

4. حوكمة كيفية تشغيل الوكلاء ← نظام Agent Harness

يتمثل النصف الثاني من حوكمة الوكلاء في وقت التشغيل (Runtime) — أي الحلقة نفسها وعناصر التحكم الخاصة بها. يتماشى هذا مع نظام Agent Harness، الذي تصفه TrueFoundry بأنه نظام إدارة مبني على بوابة الذكاء الاصطناعي (AI Gateway) وبوابة MCP: حيث تختار نموذجاً، وتصل خوادم MCP، وتضيف المهارات، وتكتب التعليمات، بينما تتولى المنصة إدارة التنسيق، ودورة حياة بيئة الاختبار (sandbox)، وتنفيذ الأدوات، والموافقات، والحوكمة، وقابلية المراقبة (docs/agent-platform/agent-harness/overview). خاصية الحوكمة المحددة له هي: عدم لصق أي مفاتيح واجهة برمجة تطبيقات أو بيانات اعتماد في تعريفات الوكيل؛ حيث تتم الإشارة إلى النماذج وخوادم MCP والمهارات بالاسم من خلال مستوى تحكم مركزي، مع وجود بيانات اعتماد النموذج في بوابة الذكاء الاصطناعي، ومصادقة الأدوات في بوابة MCP، والمهارات في سجل مهارات (Skills Registry) مُدار بإصدارات وخاضع لـ RBAC.

يعالج هذا النظام جزءاً تقنياً واحداً من عجز الحوكمة الذي أشارت إليه BCG. فوفقاً لوثائقه، فإنه يشغل حلقة تنسيق — التخطيط، والتنفيذ، والمراقبة، والاستمرار أو التوقف — مع توجيه الأدوات وتنفيذها، وعناصر التحكم في الذاكرة والسياق للمهام طويلة الأمد، والحدود الأمنية بما في ذلك بيئة الاختبار والأذونات، وبوابات الموافقة البشرية التي توقف استدعاءات الأدوات الحساسة وتتطلب موافقة صريحة قبل تنفيذها (docs/agent-platform/agent-harness/overview). ولأن النظام يعمل في نفس مستوى البوابة الخاص بحركة مرور النموذج وMCP، فإن الحوكمة وقابلية المراقبة تظلان في نظام واحد بدلاً من ثلاثة. والنتيجة هي جزء تقني واحد من "حوكمة فرق البشر والذكاء الاصطناعي"، يتم التعبير عنه كبيئة تشغيل: وكلاء يعملون بهويات خاضعة للحوكمة، ويعتمدون على نماذج وأدوات معتمدة، ويوقفون استدعاءات الأدوات الحساسة أو التدميرية للحصول على الموافقة. وهو أيضاً المكان الذي تصبح فيه الانضباطات المرحلية لدليل التشغيل عملية: ابدأ بالبناء مقابل النواة الموثوقة، ثم استخدم سجلات التشغيل والتقييمات ونتائج الأعمال لتقرر متى توسع نطاق وصول الوكيل إلى البيانات أو صلاحياته.

5. الإشراف على موجة الوكلاء ← قابلية المراقبة والموافقات في نظام Harness

يطرح الوكلاء سؤال الإشراف من الجزء الأول على مستوى أعلى — فتوجيه وكيل أصعب من توجيه استدعاء واحد — وإجابة النظام هي التتبع لكل خطوة بالإضافة إلى بوابات الموافقة. وفقاً لما كتبته TrueFoundry، يجب أن تكون قابلية المراقبة عبر حركة مرور النموذج والأداة والوكيل في لوحة واحدة — سجلات شاملة لكل عملية تشغيل، مع التكلفة والرموز المميزة وزمن الاستجابة لكل خطوة (blog/agent-harness-managed-ai-agents). هذا التتبع لكل خطوة هو ما يمنح المشرف سجلاً واضحاً لما فعله الوكيل، والأداة التي استدعاها، وتكلفة كل خطوة — وهي نسخة على مستوى الوكيل من الرؤية التي تتطلبها نتائج الثورة الإدارية لشركة BCG، والتطبيق العملي لنصيحة دليل التشغيل بمراقبة أداء الوكلاء واستخلاص النتائج قبل توسيع صلاحياتهم: تجعل سجلات التشغيل مسار التنفيذ القابل للمراقبة واضحاً — الأدوات المستدعاة، والإجراءات المختارة، والمخرجات الوسيطة الصريحة، والموافقات، والتكاليف — على الرغم من أنها لا تكشف عن التفكير الداخلي الخاص بالنموذج.

تُمثل بوابة الموافقة النصف الآخر من المعادلة: حيث تتوقف استدعاءات الأدوات الحساسة أو ذات التأثير العالي مؤقتاً بانتظار تفويض بشري صريح، وهو ما يعني إشرافاً موجهاً بدقة وليس مراقبة مستمرة. يمكن لبوابات الموافقة وضوابط الوصول عبر بروتوكول MCP تقليل نطاق التأثير للإجراءات الحساسة المكونة، لكنها لا تلغي مخاطر الحوكمة ونموذج التشغيل الأوسع التي تُظهر بيانات مجموعة بوسطن الاستشارية (BCG) أن معظم المؤسسات لم تعالجها بعد.

6. "إعادة تصميم سير العمل من البداية إلى النهاية" ← بيئة التشغيل ونشرها

تتطلب إعادة تصميم سير العمل من البداية إلى النهاية بيئة تنفيذ يمكن من خلالها بناء سير عمل الوكلاء ومراقبته وإدارته؛ وتُعد "Agent Harness" إحدى بيئات التشغيل المُدارة التي تحقق ذلك. فهي ترث سياسات الوصول إلى النماذج، والميزانيات، وحدود المعدلات، وضوابط الحماية من بوابة الذكاء الاصطناعي (AI Gateway)، بينما تساعد ضوابط تنفيذ وقت التشغيل وبوابات الموافقة في إدارة السلوك المكون (وثائق Harness؛ حول تقييد الحلقات بشكل عام، انظر منشورنا حول هندسة الحلقات) — وهي نفس آليات الميزانية والسياسات من الجزء الأول، ولكنها مخصصة لحلقة الوكيل، ولهذا السبب تم بناء بيئة التشغيل (Harness) على بوابة الذكاء الاصطناعي بدلاً من أن تكون منفصلة عنها.

يجعل النشر هذا الحل قابلاً للاستخدام من قبل المؤسسات الخاضعة للتنظيم في عينة BCG المكونة من 14 سوقاً: حيث تعمل المنصة كبرمجيات كخدمة (SaaS)، أو مستضافة ذاتياً، أو داخل مقر العمل، مع بنية ذات مستوى مقسم يعمل فيها مستوى الحوسبة — بما في ذلك البوابة — داخل حساب السحابة الخاص بالعميل، بحيث لا تضطر المطالبات، والمخرجات، والبيانات إلى مغادرته (blog/field-notes-ai-cost-gateway-not-a-switch). بالنسبة لبنك أو مستشفى، يُعد سؤال "أين يتم تشغيل هذا؟" سؤالاً استراتيجياً بحد ذاته، وتسمح مرونة النشر ببقاء التخصيص، وضوابط الحماية، وحوكمة MCP في مستوى البوابة بينما تعمل بيئة التشغيل (Harness) في نفس البيئة التي يتحكم فيها العميل — بما في ذلك أحمال العمل التي لا يمكنها استخدام برمجيات SaaS متعددة المستأجرين — وهي مرونة في النشر يمكن أن تجعل تشغيل الوكلاء الخاضع للحوكمة أمراً ممكناً لأحمال العمل الحساسة من حيث السيادة أو الخاضعة للتنظيم. يضيف دليل العمل (Playbook) مُسرعاً لإعادة التصميم وحدوده: حيث يضغط الوكلاء أبطأ مدخلات — وهي دورة جمع وتنظيف البيانات التي تستغرق ثمانية أسابيع — لتصبح حوالي أسبوع واحد في حساب الممارسين، بينما تظل طبقة الذكاء — وفقاً لتعريف أبراهام، أي ربط سياق الأعمال الفعلي للشركة ببياناتها ليفهم الوكلاء محركات العمل — عملاً بشرياً، وهو الجزء الأكثر استخفافاً به في نشر الوكلاء حسب قولهم. يوضح عوض توجه القادة في الاقتباس المباشر الوحيد في هذا المنشور من دليل العمل: "إنهم يسألون، 'كيف نعمل بشكل مختلف؟'" — وليس كيف ننشر الوكلاء (دليل العمل). الوكلاء يسرعون عملية إعادة التصميم؛ لكنهم لا يضعونها.

7. تقسيم العمل، بوضوح

سيكون من غير الدقيق بحق BCG وTrueFoundry الادعاء بأن المنصة تسد فجوة القيمة بمفردها؛ فقد حددت TrueFoundry الحدود في كتاباتها: هذه العناصر الأساسية هي ما يجعل نموذج التشغيل ممكناً — لكنها ليست نموذج التشغيل بحد ذاتها؛ فالمنصة تمنحك أدوات التحكم والبيانات، ولا يزال يتعين على الفريق الكفء تحديد العتبات والعمل بناءً على التنبيهات (blog/field-notes-ai-cost-gateway-not-a-switch). هذا هو نفس التقسيم الذي يشير إليه تباين BCG بين الاستراتيجية والأدوات (+25 نقطة للوضوح الاستراتيجي مقابل +5 للوصول إلى الأدوات، في مقارنة الاستطلاع) — ويذكره دليل العمل بأرقامه الخاصة: النجاح في تنفيذ الوكلاء يعتمد بنسبة 70% على الأفراد وإدارة التغيير، حيث قامت المؤسسات الأكثر تقدماً بتدريب أكثر من نصف قوتها العاملة. الاستراتيجية هي التي تضع العتبات، وتقرر ما يجب قياسه، وتختار ما يجب إيقافه، وتحدد العمل عالي القيمة الذي يجب أن يملأ الساعات التي يوفرها الذكاء الاصطناعي. القدرات الأربع التي حددتها هذه السلسلة — بوابة الذكاء الاصطناعي، وضوابط الحماية، وبوابة MCP، وبيئة تشغيل الوكلاء (Agent Harness) — يمكن أن تجعل السياسات التقنية المختارة قابلة للتنفيذ وتنتج القياسات التي تساعد المؤسسات على مراجعتها. لا تفرض BCG هذه البنية؛ فهذا التخطيط هو تفسير TrueFoundry لطريقة واحدة لتفعيل جزء من الاستجابة.

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

8. التخطيط الكامل، في عرض واحد

عند النظر إليها مجتمعة، تتماشى النتائج التي توصلت إليها BCG مع أربع قدرات عبر طبقات البوابة وبيئة التشغيل، وكل منها مستند إلى وثائق: تخصيص التكلفة والمراقبة (بوابة الذكاء الاصطناعي)، وضوابط الحماية والسياسة كإعدادات، وحوكمة الأدوات (بوابة MCP)، وبيئة التشغيل المُدارة (Agent Harness) — مع بوابات الموافقة، والتتبع، والنشر كبرمجيات كخدمة أو مستضافة ذاتياً أو داخل مقر العمل. لم يتغير النمط أبداً: نتيجة من BCG في جانب، وقدرة موثقة في الجانب الآخر، وقرارات تشغيلية تظل بيد المؤسسة طوال الوقت.

‍

‍