Lifecycle stage — Build
أصعب عقبة بين نموذج أولي للذكاء الاصطناعي يعمل وآلة حرجة للسلامة مُنشَرة هي حالة السلامة — الحجة المنظمة المدعومة بالأدلة على أن النظام آمن بشكل مقبول. يكسر تعلم الآلة (ML) الافتراضات التي بُنيت عليها عمليات السلامة الوظيفية التقليدية: لا توجد مواصفة سطراً بسطر لتتبعها، والسلوك إحصائي، ولن تقبل جهات الإخطار نموذجاً غير موثق في مركبة أو نظام طيران أو خط صناعي. هندسة حالة السلامة وأدلة التصديق هي القدرة على إنتاج هذه الحجة وهذا المسار من الأدلة — تحليل المخاطر والأخطار، وتقييم المخاطر، وتحليل ASIL/DAL/SIL، وبناء حالة الضمان، وتتبع التحقق والتصديق — مُعيَّنةً على المعيار الذي يحكم مجالك. هذا هو الخط الأحد بين متخصص Physical AI ومستشار ذكاء اصطناعي عام، وهو العائق الأول في كل قطاع حرج للسلامة. لأكون صريحاً بشأن الحدود: جهة الإخطار هي التي تُحدد تصنيف السلامة الفعلي وتُصادق على النظام. أنا أُهندس حالة السلامة والأدلة التي تُقيِّمها — ولا أُصدر شهادات التصديق.
يكسر ML نهج V&V التقليدي. تفترض معايير السلامة الوظيفية وجود مواصفة يمكن تتبعها اختباراً بعد اختبار؛ أما النماذج المُتعلَّمة فلا تمتلك ذلك. يجب إعادة بناء حجة الضمان للسلوك الإحصائي، ومعظم الفرق لا تمتلك المنهجية اللازمة لذلك.
ترفض جهات الإخطار نماذج ML غير الموثقة. النموذج الذي يؤدي أداءً جيداً في التحقق لكنه يصل بدون تحليل مخاطر وتحليل للمتطلبات ومسار أدلة قابل للتتبع لن يجتاز تقييم المطابقة — الأداء ضروري لكنه بعيد كل البعد عن الكفاية.
يجب هندسة الأدلة من البداية لا تجميعها في النهاية. إضافة حالة السلامة بأثر رجعي على نظام لم يُبنَ لإنتاج أدلة هو أغلى طريقة لاكتشاف ما اشترطه المعيار.
مُعيَّن على المعيار الذي يحكم مجالك — ISO 26262 (السيارات)، وDO-178C/EASA (الفضاء والطيران)، وIEC 61508 (الصناعة)، وISO 13482 (روبوتات الخدمة) — ومحدد لوظيفة نظام واضحة.
تنفيذ HARA (أو ما يعادلها في المجال): تحديد الأخطار، وتقييم التعرض/قابلية التحكم/الخطورة، واستنتاج أسئلة تصنيف المخاطر التي ستطرحها جهة الإخطار — دون استباق التصنيف الذي تحدده.
تحليل أهداف السلامة إلى متطلبات سلامة وظيفية وتقنية مُوزَّعة عبر البنية المعمارية، بما في ذلك عنصر ML وآليات السلامة والمراقبة والبدائل الاحتياطية.
بناء حجة الضمان المنظمة (مثل GSN) التي تربط الادعاءات بالأدلة، مما يجعل المنطق الأمني صريحاً وقابلاً للمراجعة بدلاً من أن يكون ضمنياً ومُسلَّماً به.
تعريف وتجميع أدلة التحقق والتصديق ومصفوفة التتبع من المتطلب إلى الاختبار، حتى يكون الملف التقني مكتملاً وجاهزاً للتدقيق.
شركات OEM للسيارات وموردو Tier-1 (ISO 26262)، ومقاولو الطيران والفضاء والدفاع الرئيسيون (DO-178C/EASA)، ومتكاملو الصناعة والروبوتات (IEC 61508، وISO 10218/13482)، ومشغلو الطاقة الذين ينشرون ML في وظائف يُعدّ فيها حادث السلامة حدثاً تنظيمياً وقانونياً — لا بلاغ خطأ برمجي. للفرق التي لديها نموذج يعمل وتحتاج الآن إلى إثبات أنه آمن.
لا. جهة الإخطار أو المُقيِّم المعتمد هو من يُحدد تصنيف السلامة ويُصادق على النظام. أنا أُهندس حالة السلامة ومسار الأدلة الذي يُقيِّمونه — تحليل الأخطار، وتحليل المتطلبات، وحالة الضمان، وتتبع V&V. الادعاء بخلاف ذلك سيكون غير أمين، وستكتشفه جهة الإخطار.
المعيار الذي يحكم مجالك — ISO 26262 للسيارات، وDO-178C/EASA للطيران والفضاء، وIEC 61508 للسلامة الوظيفية الصناعية، وISO 10218/13482 للروبوتات. الخطوة الأولى من العمل تُحدد المعيار المنطبق وحدود النظام.
يتعلق الامتثال لـ EU AI Act بالتزامات الحوكمة والتوثيق التي يفرضها التشريع. أما التصديق على السلامة الوظيفية فهو نظام منفصل وأقدم وأعمق يتعلق بالسلامة المادية للآلة. يحتاج نظام الذكاء الاصطناعي الحرج للسلامة عادةً إلى كليهما؛ هذه الخدمة تغطي الجانب المتعلق بالسلامة الوظيفية.
استكشف خدمات أخرى تُكمّل هذا العرض
٣٠ دقيقة. أشخّص وضعك وأخبرك بصراحة ما إذا كانت هذه الخدمة مناسبة — وإن لم تكن، فأيها مناسب.