التبني المسؤول للذكاء الاصطناعي يبدأ من تصميم سير عمل المطورين

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

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

الاستخدام غير المعتمد إشارة إلى خلل في سير العمل

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

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

تحويل السياسة إلى واجهة هندسية

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

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

ضع الضوابط حيث يحدث العمل

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

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

المساءلة والتدريب والقياس

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

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

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

القراءة التحريرية من certi.news

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

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