بناء، شراء، شراكة، أو استعارة: استراتيجية توريد وكلاء الذكاء الاصطناعي

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

هل يجب على فريقك بناء كل شيء من الصفر؟ أم مجرد شراء حلول جاهزة من البائعين؟ أم ربما العمل مع شريك خارجي؟ أم مجرد استعارة مكونات مفتوحة المصدر للتحرك بسرعة؟

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

لماذا هذا القرار معقد للغاية

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

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

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

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

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

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

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

متى يصبح البناء هو الخيار الصحيح

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

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

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

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

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

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

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

متى يكون الشراء أكثر منطقية

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

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

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

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

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

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

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

متى تصبح الشراكة أو الاستعارة خياراً صحياً

بين البناء والشراء، هناك نهجان غالباً ما يكونان الأكثر واقعية للشركات الكبيرة: الشراكة والاستعارة. كلاهما مفيد، لكن لأغراض مختلفة.

يناسب نهج الشراكة عندما تعرف الشركة مجموعة القيمة التي تريد ملاحقتها، لكنها لا تمتلك بعد نمط تنفيذ ناضج، أو ليست مستعدة بعد لتشغيل خدمة وكيلية بنفسها في المرحلة المبكرة. يمكن للشريك أن يلعب عدة أدوار: المساعدة في بناء مخطط والهندسة المرجعية، وتطوير الوكيل الأول مع الفريق الداخلي، وتشغيل خدمة مُدارة لمجال معين، أو تسريع التصنيع من خلال مسرعات وقدرات التسليم.

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

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

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

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

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

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

واقع هجين: إدارة مزيج من مصادر الوكلاء

من الناحية العملية، ستنتهي الشركات الكبيرة بالتأكيد بسلسلة توريد هجينة من الوكلاء. بعض الوكلاء مبنيون داخلياً، والبعض الآخر مشترى من SaaS، والبعض مطور مع شركاء، والبعض مستعار للتجارب أو لمكونات معينة. هذه ليست مشكلة. الخطير هو أن ينمو هذا المزيج بدون بنية تحتية وحوكمة مشتركة.

لإدارة هذا النموذج الهجين، تحتاج الشركة إلى عدة أشياء. أولاً، سجل الوكلاء (agent registry)، وهو كتالوج يشرح ماهية الوكلاء الموجودين، ومن هو المالك التجاري والتقني، ومصدرهم، وما هي البيانات والأدوات التي يستخدمونها، ومستوى المخاطر، وحالة دورة الحياة. بدون سجل، لا توجد طريقة صحية لإدارة محفظة الوكلاء.

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

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

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

طريقة تفكير أكثر صحة: التوريد حسب الطبقة

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

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

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