في المدينة الذكية الخليجية، من يملك قرار إيقاف الوكيل؟

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

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

الإيقاف ليس زرّاً واحداً

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

تظهر أهمية هذا التفريق مع طموح الحكومات الخليجية إلى خدمات رقمية مترابطة. ويشير المقال إلى استراتيجية أبوظبي الرقمية الحكومية للفترة 2025 إلى 2027، وإلى إعلان في 6 يوليو 2026 عن إتاحة Microsoft 365 Copilot لما مجموعه 35 ألف موظف حكومي. لكنه يوضح بجلاء أن إتاحة أداة لإنتاجية الموظفين لا تثبت تشغيل سيناريو ذاتي لإدارة صيانة المياه. بين الطموح والتشغيل الفعلي، توجد عقود وصلاحيات وسجلات وأنظمة مستقلة لا تُدار جميعها من شاشة واحدة.

اختبر الاستدعاء قبل الخدمة الحية

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

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

السجل المستقل أهم من تطمين الوكيل

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

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