لو كتب الذكاء الاصطناعي كود مشروعك، فمن يملكه ومن يتحمل مسؤوليته؟

ملكية ومسؤولية

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

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

سؤال واحد في الظاهر، ثلاثة في الحقيقة

عبارة «من كتب الكود؟» تخفي ثلاثة أسئلة مستقلة، لكلٍّ منها إجابة مختلفة وجهة مختلفة تحسمها. الخلط بينها هو مصدر أغلب سوء الفهم هنا.

ماذا تقول الأدوات نفسها؟

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

الشروط الخاصة بمنتج GitHub Copilot تنص على أن GitHub لا تملك الاقتراحات، وأن المستخدم يحتفظ بملكية كوده. ثم تضيف ما هو أهم: يحتفظ المستخدم كذلك بالمسؤولية الكاملة عن هذا الكود، بما في ذلك الاقتراحات التي يُدرجها فيه، وقرار استخدام أي اقتراح يعود إليه وحده. وتوصي الشروط بوضع سياسات تمنع استخدام اقتراح بطريقة قد تنتهك حقوق الآخرين، ومنها تفعيل خصائص التصفية المتاحة داخل الأداة.[1]

هذه شروط أداة واحدة بعينها، وهي تتغيّر مع الوقت وتختلف من مزوّد لآخر. فاطلب اسم الأداة المستخدمة فعليًا وخطّة الاشتراك، ثم اقرأ شروطها بتاريخها. لا تكتفِ بانطباع عام عن «الأدوات».

أن تملك شيئًا لا يعني أنه محمي

هنا تقع المفاجأة عادةً. العقد ينقل الملكية إليك، لكنه لا يمنح الكود حمايةً لا يمنحها القانون أصلًا.

أصدر مكتب حقوق النشر الأمريكي في ٢٩ يناير ٢٠٢٥ الجزء الثاني من تقريره عن الذكاء الاصطناعي وحقوق النشر، وخصّصه لقابلية المخرجات المولَّدة للحماية.[2] خلاصته أن التأليف البشري شرط أساسي، وأن المواد المولَّدة بالكامل لا تتمتع بالحماية، بينما تظل المساهمات البشرية داخل العمل قابلة للحماية وتُقيَّم حالة بحالة. ورأى المكتب أن كتابة الأوامر النصية وحدها، مهما بلغت من التفصيل، لا تكفي لإنشاء عمل محمي.[3]

وليست المسألة أمريكية الطابع. أعلنت الهيئة السعودية للملكية الفكرية في أغسطس ٢٠٢٥ إطلاق «دليل المبادئ التوجيهية للمصنفات المولدة عبر الذكاء الاصطناعي في مجال حقوق المؤلف».[4] وأصدرت المنظمة العالمية للملكية الفكرية دليلًا متاحًا بالعربية يضع قائمة مرجعية لمخاطر الملكية الفكرية والضمانات الممكنة عند تبنّي هذه الأدوات.[5] التنظيم قادم في المنطقة إذن، والتفاصيل هي ما يختلف.

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

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

أين ينتهي ضمان الأداة بالضبط

المخاوف لا تقف عند الحماية. هناك احتمال آخر: أن يشبه الاقتراح كودًا مملوكًا لطرف آخر. لهذا توفّر الأدوات مرشّحات لكشف التطابق مع الكود العام، وتشترط برامج التعويض عن مطالبات حقوق النشر أن تكون وسائل التخفيف المطلوبة مفعّلة أثناء التوليد.[1]

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

الخبر الجيد أن التحقق سهل. سؤالان بإجابة نعم أو لا: هل المرشّح مفعّل؟ وهل يمر المستودع على فحص تراخيص آلي؟

الكود الذي يعمل ليس بالضرورة كودًا آمنًا

هذه أهم نقطة عملية في الملف، لأنها الوحيدة التي تظهر آثارها على عملائك مباشرة.

في تقرير أجرته شركة Veracode عام ٢٠٢٥ على أكثر من مئة نموذج لغوي عبر أربع لغات برمجة، أدخل الكود المُولَّد ثغرات من قائمة OWASP العشر في نحو ٤٥٪ من الحالات المختبَرة، وكانت Java الأعلى في نسبة الإخفاق.[6] وفي تحديث لاحق، ظل معدل النجاح الأمني قرابة ٥٥٪ بينما تجاوزت دقة الصياغة البرمجية ٩٥٪. النماذج تحسّنت في إنتاج كود يعمل، ولم تتحسّن بالقدر نفسه في إنتاج كود آمن.[7]

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

وهناك بُعد سلوكي أخطر من الأرقام. في دراسة محكّمة نُشرت في مؤتمر ACM CCS عام ٢٠٢٣، كتب المشاركون الذين أُتيح لهم مساعد ذكاء اصطناعي كودًا أقل أمانًا بفارق ذي دلالة إحصائية، وكانوا في الوقت نفسه أكثر ميلًا للاعتقاد بأن كودهم آمن.[8] استخدمت الدراسة نموذجًا من عام ٢٠٢٢، فلا تصلح مقياسًا لقدرات نماذج اليوم. لكن ما ترصده ليس قدرة النموذج. إنه ثقة الإنسان في مخرجاته، وهو أثر سلوكي لا تقيسه معايير أداء النماذج.

ولا يقتصر التفاوت بين الإحساس والقياس على الأمن. في تجربة عشوائية مُحكَمة أجرتها منظمة METR غير الربحية عام ٢٠٢٥ على ستة عشر مطورًا خبيرًا أنجزوا ٢٤٦ مهمة حقيقية في مستودعات يعرفونها جيدًا، استغرقت المهام وقتًا أطول بنسبة ١٩٪ حين سُمح باستخدام الأدوات. وقد توقّع المطورون قبل التجربة تسريعًا بنحو ٢٤٪، وظلوا بعدها يعتقدون أنها سرّعتهم بنحو ٢٠٪.[9]

والأمانة تقتضي ذكر ما تلا ذلك. نشرت METR في فبراير ٢٠٢٦ تحديثًا رجّحت فيه أن المطورين أصبحوا أسرع فعلًا مع أدوات اليوم، لكنها أوضحت أن بيانات تجربتها الجديدة تأثرت بانحياز في اختيار المشاركين يجعل تقدير حجم التسريع غير موثوق.[10] الخلاصة المتماسكة من التجربتين معًا بسيطة: تقدير الفريق لسرعته ليس دليلًا عليها. وهذا ينطبق على وعود التسريع كما ينطبق على تطمينات الجودة.

إذن، من المبرمج؟

من يقرّر، لا من يكتب.

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

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

ثمانية أسئلة قبل التوقيع

لا تسأل «هل تستخدمون الذكاء الاصطناعي؟». السؤال بهذه الصيغة يدعو إلى إجابة تطمينية بلا معنى. اسأل عن الضوابط، وانتبه لنوع الإجابة بقدر انتباهك لمضمونها.

هذه كلها مما يُكتب في وثيقة المتطلبات وفي العقد قبل البدء، لا مما يُناقش عند التسليم.

ما الذي يُكتب في العقد؟

ستة بنود تغطي أغلب ما سبق. ليست معقدة، لكن غيابها مكلف.

الصياغة تصنع الفارق

وهل يُفترض أن ينخفض السعر؟

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

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

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

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

قائمة تحقق قبل الاستلام

البند الأول هو الذي يُنسى أكثر من غيره، وهو أصعبها استدراكًا بعد انتهاء العلاقة مع المورّد.

أسئلة متكررة