الوكلاء الخارقون لا تنقصهم القدرة، تنقصهم بوابة السياسات

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

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

متى يتوقف الوكيل عن كونه أداة إنتاجية

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

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

تشبيه بسيط

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

الغريب أننا نتخلى عن هذا المنطق بالضبط عندما يكون "الموظف" وكيلًا برمجيًا، ثم نتفاجأ عندما تتعثر التجربة.

ما الذي يجب أن يثبته الوكيل

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

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

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

من واقع التسليم

أشارك اليوم منصة وكلاء ذكاء اصطناعي سيادية تعمل on-premises لخدمات الجمهور في الإمارات، بمواءمة NESA، إلى جانب منصة للوكلاء المؤسسيين الداخليين بالعربية أولًا.

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

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

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

عن أرقام مثل "خفض الإشراف بنسبة خمسين بالمئة"

هذا النوع من الأرقام يظهر كثيرًا في العروض التقديمية، وأنا لا أوقّع عليه.

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

قبل وجود قياس كامل للدورة، الرقم تقدير وليس عائدًا. والفرق بين الاثنين هو الفرق بين قرار استثماري ووعد.

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

الترتيب الصحيح للعمل

أولًا: لوحة تفويض المهام

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

ثانيًا: سجل التنفيذ وبوابة السياسات

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

ثالثًا: توسيع القدرات

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

تحفظان لا بد من ذكرهما

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

الثاني: هذه ليست دعوة للانتظار. الجهات التي تنتظر نضوج المنظومة قبل البدء تخسر التعلم المؤسسي، وهو الأصل الحقيقي في هذه المرحلة. ابدأ بمهمة واحدة ذات أثر محدود وحدود واضحة، وابنِ عليها.

الخلاصة

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

ما أول مهمة تثقون بتفويضها بالكامل لوكيل داخل مؤسستكم، ولماذا هي تحديدًا؟