مهارات وظائف AI تغيّرت: التشغيل والحوكمة يتقدمان على العروض التجريبية

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

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

ما الذي تغيّر في الطلب؟

اتسع طلب مهارات AI داخل وظائف تقنية متعددة، لا في المسميات المتخصصة وحدها. فقد ارتفعت حصة إعلانات الوظائف التقنية الأميركية التي تذكر مهارة AI واحدة على الأقل من 15% في يناير 2024 إلى 73% في مايو 2026؛ كما زادت إعلانات المسميات التي تتضمن AI بنسبة 173% بين الربع الأول من 2025 والربع الأول من 2026، وفق تغطية CIO Dive لبيانات Dice.

وفي بيانات يوليو، بلغت حصة الإعلانات الأميركية التي تتطلب مهارات AI نحو 79%. ويضع تقرير وظائف Dice لشهر أغسطس 2026 مهارات Agentic AI وAI Agents وResponsible AI والبنية التحتية والتكامل المؤسسي وقواعد البيانات المتجهية وقابلية المراقبة والمعمارية السحابية وPrompt Engineering ضمن المهارات التي تجاوز نموها السنوي 200%. حللت Dice أكثر من سبعة ملايين إعلان تقني أميركي، اعتمادًا على بيانات سُحبت في 4 أغسطس 2026.

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

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

الحزمة الأولى: بناء وكيل ينفذ مهمة كاملة

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

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

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

الحزمة الثانية: التشغيل والتكامل

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

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

هذه الحزمة تتيح لمهندسي البرمجيات والبيانات وDevOps إضافة AI إلى خبرة قائمة. وفي ملف التوظيف، يقدّم وصف مثل «نشرت خدمة وكيلة بصلاحيات محدودة وآلية استعادة» معلومة قابلة للفحص، بخلاف أوصاف عامة مثل «خبير في أدوات AI».

الحزمة الثالثة: المراقبة والموثوقية

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

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

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

الحزمة الرابعة: الحوكمة والاستخدام المسؤول

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

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

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

مشروع واحد يبرهن على الحزم الأربع

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

1. حدد مهمة ضيقة ومدخلاتها ونتيجتها ونقطة تدخل الإنسان.
2. ابنِ وكيلًا يستدعي أداة واحدة على الأقل، مع اختبارات للحالات الطبيعية والفاشلة.
3. انشره كخدمة صغيرة، وأضف الصلاحيات وإعادة المحاولة وإجراء الإيقاف.
4. سجّل المسارات والتكلفة والأخطاء، وأنشئ مجموعة تقييم قابلة للتكرار.
5. أضف سجل مخاطر وضوابط وصول وتوثيقًا للقيود والقرارات.

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