البنتاغون يفرض 3 عمليات تحقق على كل مقطع برمجي تنتجه الذكاء الاصطناعي

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

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

تسري هذه القاعدة على مؤسسات الوزارة وبرامج المشتريات التي تتضمن برمجيات. لكن النهج نفسه مفيد لأي شركة تسمح بالفعل للوكلاء بالعمل داخل مستودعاتها: سرعة توليد الشفرة لا تعد دليلا على أن التغيير آمن.

ما الذي يجب إثباته تحديدا

تلخص التعليمة العمل مع الذكاء الاصطناعي في ثلاثة متطلبات عملية.

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

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

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

كيف يبدو ذلك في تصحيح اعتيادي

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

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

تطرح GitLab منصتها الخاصة وسيلة لتطبيق هذه المتطلبات: سجلات التدقيق، والفروع المحمية، وقواعد الموافقة، وفحص التبعيات، وبوابة مستضافة ذاتيا للوصول إلى النماذج. وهذا مثال مفيد، لكن المصدر يظل مادة تجارية. تصف التعليمة المتطلبات ولا تلزم باستخدام GitLab؛ ويمكن تطبيق المبادئ نفسها في GitHub أو Azure DevOps أو نظام داخلي.

ما الذي ينبغي تغييره في عملية التطوير

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

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

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