MLCommons تصدر دليلًا: مخاطر الذكاء الاصطناعي في الأعمال يمكن قياسها وتقديرها بالمال

نشرت MLCommons في 8 أكتوبر 2026 دليلًا موجهًا لأصحاب الأعمال حول تقييم مخاطر الذكاء الاصطناعي وإدارتها في التطبيقات التجارية. ويعد العنوان الفرعي بـ«تكلفة يمكن قياسها وتقديرها بالمال والتحكم بها». الإعلان قصير: يصف المشكلة والفكرة الأساسية، لكنه لا يكشف المنهجية ولا العتبات ولا الأمثلة. لذلك يتناول هذا المقال الفكرة نفسها والسياق الذي تروّج فيه MLCommons لها، دون اختلاق أي تفاصيل عن الدليل.

التعارض الذي تصفه MLCommons

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

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

لماذا MLCommons تحديدًا

يُعرف الاتحاد قبل كل شيء بمعيار MLPerf الذي تقيس به الصناعة سرعة التدريب والاستدلال على المسرّعات. وفي عام 2024 أطلقت المنظمة AILuminate، وهي مجموعة اختبارات أمان لنماذج المحادثة. وفيما يلي معلمات AILuminate v1.0 بحسب بيانات MLCommons وقت الإطلاق. ويُفضَّل مطابقة القيم الحالية مع الوثائق المحدّثة.

• التغطية: 12 فئة من المخاطر، بينها الجرائم العنيفة والمخاطر على الأطفال وإيذاء النفس.
• البيانات: عشرات الآلاف من المطالبات (prompts)، بعضها مفتوح للتجريب وبعضها مغلق للتقييم الرسمي.
• المقياس: خمسة مستويات تقييم، من «Poor» إلى «Excellent».
• المبدأ: بروتوكول موحد لنماذج مختلفة لتكون النتائج قابلة للمقارنة.
• الموقع: منظمة مستقلة بمشاركة الصناعة والأوساط الأكاديمية، وليست مورّدًا يقيّم منتجه بنفسه.

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

ما الذي لا يتضمنه الإعلان

لا يتضمن النص منهجية لتحويل درجات الأمان إلى مبالغ مالية، ولا أمثلة من قطاعات بعينها، ولا بيانات عن علاقة الدليل بإطار NIST AI RMF أو معيار ISO/IEC 42001 أو قانون الذكاء الاصطناعي الأوروبي (AI Act). هذه هي الأسئلة الرئيسية التي ينبغي طرحها على الوثيقة الكاملة. فتقدير احتمال الضرر وحجمه يتوقف على السيناريو: روبوت دعم العملاء ووكيل يملك صلاحية الوصول إلى المدفوعات ومساعد للمحامين لكل منها ملف مخاطر مختلف. ولن يحل معيار عام للأمان محل الاختبارات على بياناتك الخاصة وفي سيناريوهات الهجوم الخاصة بك.

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

حتى دون النص الكامل، يمكن تطبيق المنطق نفسه. والخطوات كالتالي:

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

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