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

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

ماذا نسمح لوكيل البرمجة أن يفعل أولاً؟

ابدؤوا بالمساهمة، لا بالسلطة.

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

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

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

ما التغييرات التي يمكن أتمتتها أكثر لاحقاً؟

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

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

يوصي إطار NIST للتطوير الآمن للبرمجيات SSDF الإصدار 1.1، المنشور في فبراير 2022، بدمج ممارسات الأمن عبر دورة حياة تطوير البرمجيات. كما أضاف NIST SP 800-218A، الذي صدر نهائياً في يوليو 2024، ممارسات مرتبطة بتطوير الذكاء الاصطناعي التوليدي والنماذج الأساسية ثنائية الاستخدام. هذه الوثائق ليست تعليمات خاصة بوكلاء البرمجة، لكن منهج دورة الحياة فيها يوفر أساساً مفيداً للتطوير بمساعدة الوكلاء.

لماذا لا تكفي الاختبارات وحدها؟

نجاح الاختبارات ضروري، لكنه لا يثبت أن التغيير آمن.

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

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

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

يجب أن يشرح طلب الدمج ماذا تغير ولماذا، وما الاختبارات التي شُغلت، وما النقاط غير المؤكدة. عبارة «نجحت جميع الاختبارات» تظل اقتراحاً، لا ضماناً.

كيف تضيف الفرق السعودية الحوكمة المحلية؟

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

تنشر الهيئة الوطنية للأمن السيبراني ضوابط الأمن السيبراني لجهات القطاع الخاص من غير ذوات البنى التحتية الحساسة (NCNICC–1:2025). أما المتطلبات الدقيقة التي تنطبق على كل منشأة فتعتمد على قطاعها وأنظمتها ووضعها التنظيمي، ولذلك ينبغي ربط صلاحيات الوكيل بالضوابط والسياسات الداخلية التي تنطبق فعلاً.

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

هذه إرشادات تقنية وليست استشارة قانونية أو تنظيمية.

كيف يبدو سير دمج آمن؟

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

يمكن أن يكون المسار المنضبط كالتالي:

  1. يحصل الوكيل فقط على المستودع وسياق المهمة اللازمين.
  2. يعمل في فرع معزول ولا يستطيع الوصول إلى أسرار الإنتاج.
  3. يغير كود لوحة العمليات ويضيف الاختبارات.
  4. يشغل CI الاختبارات المعتادة والتحقق من التنسيق والاعتماديات والفحوص الأمنية.
  5. تتحقق قاعدة آلية من عدم تغيير ملفات المدفوعات أو المصادقة أو ترحيلات قواعد البيانات.
  6. يفتح الوكيل طلب دمج يشرح التغيير والاختبارات التي شغلها.
  7. يراجع مطور السلوك والفرق في الكود.
  8. تطبق سياسة الدمج العادية.
  9. يستمر النشر عبر خط الإنتاج الحالي، مع توفر المراقبة والتراجع.

الآن غيّروا المهمة إلى: «عدّل قواعد صلاحيات استرداد الأموال». يجب أن يتشدد المسار تلقائياً: مالك للمجال، واختبارات أقوى، وربما موافقة شخصين، وتحقق في بيئة تجريبية قبل الإنتاج.

الوكيل قد يكون نفسه. الذي يتغير هو الضبط لأن مخاطر الأعمال تغيرت.

ماذا نقيس قبل زيادة استقلالية الوكيل؟

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

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

قائمة مختصرة قبل التشغيل

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

وكلاء البرمجة لا يستبدلون ممارسات التسليم الآمن؛ بل يجعلون هذه الممارسات أكثر أهمية.

أسئلة شائعة

هل يمكن أن نسمح للوكيل بالدمج التلقائي؟

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

هل نعطي الوكيل أسرار الإنتاج لكي يشخص المشاكل أسرع؟

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

هل يجعل الفحص الأمني الكود المولد آمناً؟

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

كيف يمكن لمسار نيكست المساعدة؟

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

ناقشوا سير عمل البرمجيات أو الذكاء الاصطناعي مع مسار نيكست.

المصادر

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