قادة الفكر
مستخدمك التالي للبرمجيات هو وكيل ذكاء اصطناعي. فهل بنيتك جاهزة؟
أضف Unite.AI إلى مصادرك المفضلة على Google
تخيّل وكيلاً للذكاء الاصطناعي يتولى معالجة نزاع حول فاتورة أحد العملاء. يقرأ الشكوى، ويتحقق من سجل الحساب، ويقرر أن من المناسب إصدار رصيد دائن. كل ذلك في غضون ثوانٍ.
هذا مثير للإعجاب. والآن اطلب منه أن يصدر الرصيد الدائن فعلياً.
اتفاقية العميل موجودة في نظام آخر. وقواعد الموافقة مدفونة في شيفرة التطبيق. أما أداة الفوترة، فتتطلب من شخص أن ينقر على عدة شاشات.
يدرك الوكيل ما ينبغي فعله، لكن البنية لا تتيح له إتمام المهمة.
هذه هي المشكلة التي أتوقع أن تواجهها مزيد من المؤسسات مع انتقال الذكاء الاصطناعي الوكيلي إلى مرحلة الإنتاج. لكن الغريب أن العائق أمام إتمام المهمة لا علاقة تُذكر له بذكاء الوكيل.
أمضينا سنوات في تحديث برمجيات المؤسسات لتناسب الأشخاص الذين يستخدمونها. والآن علينا تحديثها لتناسب الوكلاء الذين سيتولون تشغيلها على نحو متزايد.
لم تكن واجهة المستخدم المنتج بأكمله قط
فكّر في طريقة عمل برمجيات المؤسسات اليوم. يفتح الأشخاص التطبيقات، ويتنقلون بين لوحات المعلومات، ويتخذون القرارات، وينقلون العمل من نظام إلى آخر. وواجهة المستخدم هي وسيلتهم للتفاعل مع الأعمال.
ليس من الضروري أن يحتاج الوكيل إلى تلك الشاشات. إذ يمكنه استرجاع المعلومات وبدء الإجراءات عبر واجهات برمجة التطبيقات (APIs)، وخوادم بروتوكول سياق النموذج (MCP)، وغيرها من الواجهات البرمجية. وهذا جزء من التحول نحو البنية عديمة الواجهة.
لكن انعدام الواجهة لا يعني اختفاء التطبيق. فما زالت بياناته وقواعد الأعمال والأذونات ومتطلبات الامتثال مهمة، بل أرى أنها أصبحت أهم.
على مدى سنوات، بنت شركات البرمجيات مزايا تنافسية على أساس واجهات المستخدم المصقولة، وعادات المستخدمين، وتكلفة إعادة تدريب الموظفين. وتضعف هذه المزايا عندما تنجز الوكلاء مزيداً من العمل من دون فتح واجهة التطبيق. وتزداد قيمة ما يقوم عليه النظام: بيانات موثوقة، ومنطق أعمال مُتحقَّق من صحته، وحوكمة تشغيلية، ومعاملات قابلة للتدقيق.
ولهذا التحول أثر تجاري أيضاً: فقد يتعرض ما يصل إلى 234 مليار دولار من الإنفاق على تطبيقات المؤسسات لاضطراب بفعل الذكاء الاصطناعي الوكيلي بحلول عام 2030. وهذا إنفاق معرّض للاضطراب، لا إنفاق مؤكد الزوال. ومع تولي الوكلاء أعمالاً كان ينفذها الأشخاص عبر لوحات المعلومات، قد تحل نماذج التسعير القائمة على الاستخدام أو الإجراء أو النتائج، على نحو متزايد، محل التسعير لكل مقعد.
يمثل ذلك تحدياً لنموذج الأعمال لدى شركات البرمجيات، وتحدياً معمارياً للمؤسسات التي تعتمد على تطبيقاتها.
حدّثنا المكوّنات، لا سير العمل
تعمل معظم المؤسسات على التحديث منذ سنوات. فهناك فريق يحدّث التطبيقات القديمة، وآخر يدمج البيانات المتفرقة على منصة حديثة، وثالث يبني عمليات التكامل أو يكتفي بتجديد واجهة المستخدم.
قد ينجح كل مشروع بمفرده. لكن المشكلة تبدأ عندما يحتاج وكيل إلى تنفيذ سير عمل يشملها جميعاً.
يمكنك تزويد وكيل بمعلومات دقيقة عن العميل، لكن ماذا يحدث بعد ذلك إذا كان التطبيق المسؤول عن التصرف بناءً عليها يُبقي قواعد أساسية مدفونة في شيفرة قديمة؟ أو يمكنك إتاحة واجهة برمجة تطبيقات واضحة، بينما تظل البيانات التي تستند إليها غير متسقة. يستطيع الوكيل اتخاذ إجراء، لكن هل يمكنك الوثوق بقراره؟
في الحالتين، حدّثنا أجزاءً من التقنية من دون تحديث العمل نفسه.
لا يكترث الذكاء الاصطناعي الوكيلي بنجاح مشروع تحديث بعينه. ما يهمه هو أن يعمل سير العمل بأكمله.
إليك كيف يبدو ذلك عملياً. احتاج أحد العملاء إلى تسريع إعداد عروض الأسعار لإصلاحات المحركات المعقدة، إذ تحدد العقود القطع التي يمكن إصلاحها أو استبدالها أو تجديدها. وكان إعداد كل عرض سعر يستغرق أياماً، وأحياناً أسابيع، من البحث اليدوي في العقود وأدلة الصيانة. وكان العميل قد حدّث منصة البيانات لديه بالفعل، لكن إعداد عروض الأسعار لم يتسارع، لأن عنق الزجاجة لم يكن البيانات قط، بل البحث. أعدنا بناء سير العمل هذا بالاستناد إلى مجموعة من وكلاء البحث، وخفّضنا وقت البحث بنسبة 80%، فبدأ إعداد عروض الأسعار يسير بوتيرة مختلفة تماماً.
لهذا السبب، لا يمكن التخطيط لتحديث التطبيقات وتحديث البيانات باعتبارهما مساري عمل مستقلين. يجب أن تدعم البنية تحقيق نتيجة الأعمال كاملة.
واجهة برمجة التطبيقات لا تجعل النظام جاهزاً للوكلاء
قد يظن المرء أن الحل بسيط: إتاحة نقاط النهاية، وربط الوكيل، وانتهى الأمر.
ليت الأمر بهذه السهولة.
استرجاع المعلومات شيء، وإصدار رصيد دائن أو تحديث سجل مالي أو طلب قطعة بديلة شيء آخر تماماً. هنا نتحدث عن التنفيذ، لا عن الوصول فحسب.
هنا أستخدم مصطلح سطح التحكم بالوكلاء: واجهة محددة النطاق وخاضعة للحوكمة، تقرأ الوكلاء من خلالها أنظمة السجلات وتكتب إليها.
يمكن لواجهات برمجة التطبيقات وخوادم MCP إتاحة الأدوات والبيانات للوكلاء. لكن MCP لا يفرض تلقائيًا قواعد عملك ولا يحدد من يحق له اتخاذ إجراء. فلا بد من تضمين هذه الضوابط في الأنظمة وسير العمل الأساسية.
هل يستطيع الوكيل استرجاع بيانات موثوقة ومعتمدة؟ وهل قواعد العمل واضحة ويُطبَّقها الجميع باستمرار؟ وهل يمكنه التوصية بإجراء، على ألا ينفذ إلا الإجراءات التي يُصرَّح له بتنفيذها؟ وإذا حدث خطأ، فهل يمكننا تتبع الإجراء ومعالجة الاستثناء، والتراجع عنه متى أمكن؟
هذه ليست مشكلات يمكن لنموذج أفضل أن يحلها بمفرده. إنها أسئلة تتعلق بسير العمل، وتصميم التطبيقات، وبنية البيانات، والتكامل، والحوكمة. ويجب الإجابة عنها جميعًا معًا.
ابدأ بالعمل، لا بالتقنية
فمن أين ينبغي أن تبدأ؟
لن أبدأ بجعل كل تطبيق بلا واجهة أو بإتاحة كل واجهة برمجة تطبيقات متوفرة. بل سأبدأ بسير عمل واحد ذي أهمية للأعمال.
تتبّع سير العمل من بدايته إلى نهايته. ما الأنظمة التي تحفظ السجلات؟ وأين يوجد منطق الأعمال؟ وما البيانات التي يمكن للوكيل الوثوق بها؟ وأي القرارات تتطلب موافقة بشرية؟ وماذا يحدث إذا تعطل أحد الأنظمة في منتصف العملية؟ وكيف تُحافَظ على الحوكمة؟
ستكتشف مواطن الخلل المهمة. وهذا هو مسار تحديث الأنظمة لديك: قائمة أعمال منسّقة تشمل التطبيقات والبيانات والتكاملات والضوابط، وتستند إلى نتيجة عملية للأعمال بدلًا من مشروعات تقنية متفرقة.
وقِس التقدم وفقًا لذلك. لا بعدد واجهات برمجة التطبيقات التي أتحتها أو بحجم البيانات التي نقلتها، بل بمدى موثوقية إتمام سير العمل، وكيفية معالجة الاستثناءات، وما إذا كانت نتائج الأعمال تتحسن.
ليس الهدف تحقيق الاستقلالية في كل شيء، بل تنفيذ المهام على نحو موثوق وجدير بالثقة، مع الاستعانة بالحكم البشري حيث يلزم.
التحول الحقيقي يتجاوز مفهوم الأنظمة بلا واجهة
ما يثير حماسي ليس التخلص من لوحات المعلومات، بل ما سيحدث حين لا يعود الناس مضطرين إلى نقل العمل يدويًا بين الأنظمة المنفصلة لإنجاز المهام.
لكننا لن نصل إلى ذلك بإضافة وكيل إلى بنية لم تُصمَّم له أصلًا.
لن يتحدد شكل الجيل المقبل من برمجيات المؤسسات بما تتيح للناس الاطلاع عليه فحسب، بل بما تتيح للوكلاء تنفيذه على نحو موثوق ومسؤول.
