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

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

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

لا يُكتب الأمر الجيد مرة واحدة. التصميم الاحترافي للأوامر يعني اختبار النموذج على حالات متنوعة، ورصد الردود غير المتوقعة، وتعديل الأمر بناءً على ما يكشفه الاختبار. شركة Anthropic تصف هذا بـ"الهندسة التكرارية للأوامر" — حيث يُعامَل الأمر كقاعدة كود حية تحتاج إلى إصدارات ومراجعات.

أي مخرج من نظام ذكاء اصطناعي يمكن تقييمه على ثلاثة مستويات متمايزة:

• الدقة الواقعية: هل المعلومات الواردة صحيحة وقابلة للتحقق؟ هل يمكن تتبع مصادرها؟
• الملاءمة للسياق: هل الإجابة مناسبة لحالة الاستخدام المحددة؟ هل تتناسب مع مستوى المستخدم وحاجته؟
• الاتساق الداخلي: هل تتناقض أجزاء من المخرج مع بعضها؟ هل المنطق سليم؟

عند بناء أي نظام ذكاء اصطناعي يُنتج مخرجات، من الضروري تصميم "إطار التقييم" (Evaluation Framework) مسبقاً — قبل البدء في الاستخدام الفعلي. هذا الإطار يتضمن:

• مجموعة اختبار (Test Set) تمثّل الحالات المتوقعة والحالات الاستثنائية
• معايير تقييم موضوعية مكتوبة مسبقاً لكل نوع من المخرجات
• عملية تحقق بشري لفئات المخرجات عالية المخاطر
• آلية لرصد الانجراف في الأداء عبر الزمن (Performance Drift)

لا يمكن الاعتماد حصراً على التقييم الآلي (مثل مقاييس BLEU وROUGE في ترجمة النصوص) لأن هذه المقاييس تقيس التشابه النصي لا الجودة الحقيقية. كذلك لا يمكن الاعتماد حصراً على التقييم البشري لأنه مُكلف وغير قابل للتوسع. الممارسة الأفضل هي مزج الاثنين: استخدام التقييم الآلي كفلتر أولي، والتقييم البشري للحالات الحدية والمخرجات عالية الأثر.

التصميم الناضج لأنظمة الذكاء الاصطناعي يُحدد بوضوح ثلاثة أنماط من العلاقة بين الإنسان والآلة:

• الإنسان في الحلقة (Human-in-the-loop): الإنسان يراجع ويُوافق على كل قرار قبل تنفيذه. مثالي للقرارات عالية الأثر.
• الإنسان فوق الحلقة (Human-on-the-loop): النظام يعمل تلقائياً لكن يُنبّه الإنسان للحالات الاستثنائية. مناسب للعمليات المتكررة والمنخفضة المخاطر.
• الإنسان خارج الحلقة (Human-out-of-the-loop): النظام يعمل باستقلالية كاملة. يستلزم ثقة عالية جداً وبيانات اختبار واسعة — ونادراً ما يكون مناسباً.

في تصميم سير العمل، أهم ما يجب تحديده هو "نقاط الانتقال" — أي اللحظات التي يجب فيها نقل القرار من النظام الآلي إلى الإنسان. هذه النقاط تشمل:

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

الخطأ الأكثر شيوعاً في تصميم سير العمل هو "فجوة المسؤولية" — حين لا يعرف أحد بالضبط من المسؤول حين يقع خطأ. قضية Tay كانت نموذجاً على ذلك: لم يكن واضحاً من المسؤول عن مراقبة محتوى الروبوت في الوقت الفعلي. كل نظام يجب أن يكون له "خريطة تدفق مسؤولية" واضحة تُجيب: من يراقب؟ من يتدخل؟ من يُوقف النظام إذا لزم الأمر؟

الاختبار الأحمر (Red-Teaming) في سياق الذكاء الاصطناعي هو عملية منهجية يحاول فيها فريق مخصص إيجاد طرق لجعل النظام يتصرف بطرق ضارة أو غير مقصودة. على عكس اختبار الأداء العادي، الاختبار الأحمر يفترض عقلية "الخصم" — محاولة كسر النظام لا التحقق من عمله الطبيعي.

• اختبار الأداء (Benchmark Testing): قياس دقة النموذج على مجموعات بيانات قياسية. ضروري لكن غير كافٍ.
• اختبار التحيز (Bias Testing): فحص مخرجات النموذج عبر فئات سكانية مختلفة للكشف عن التفاوتات.
• اختبار الأمان (Safety Testing): محاولة توليد محتوى ضار عبر أساليب متنوعة من الاستفزاز.
• اختبار الحدود (Edge Case Testing): اختبار النموذج على مدخلات نادرة أو غير اعتيادية قد لا يكون تدرّب عليها.
• اختبار الاستمرارية (Adversarial Testing): اختبار متقدم يحاكي هجمات موجّهة من مستخدمين ضارين.

ليس كل مشروع يملك ميزانية 50 خبيراً كما فعلت OpenAI. لكن كل مشروع يمكنه تطبيق الحد الأدنى من الاختبار الأحمر:

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

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

الإطلاق الكامل لأي نظام ذكاء اصطناعي دفعة واحدة إلى جميع المستخدمين هو خطر يمكن تجنّبه. الممارسة الأفضل هي "الإطلاق التدريجي" (Staged Rollout):

• إطلاق لنسبة صغيرة من المستخدمين (1-5%) ومراقبة المخرجات
• تحليل أي انحرافات في أداء الفئات الفرعية قبل التوسع
• توسيع النطاق تدريجياً مع تحديث المراقبة في كل مرحلة
• الاحتفاظ بقدرة التراجع الفوري (Rollback) في أي وقت

نظام Epic كان دقيقاً وقت تدريبه — لكن البيانات الحقيقية تتغير بمرور الوقت، والأنماط السلوكية للمستخدمين تتطور، والسياق الاجتماعي يتبدل. "انجراف الأداء" (Model Drift) يعني أن نموذجاً كان دقيقاً يصبح أقل دقة تدريجياً دون أن يُعلن عن نفسه. المراقبة المستمرة للأداء عبر شرائح مستخدمين مختلفة — وليس فقط المتوسط العام — هي ما يكشف هذا الانجراف قبل أن يتحول إلى أذى.

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

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

خطأ شائع هو الاعتقاد بأن نظاماً عادلاً يجب أن يُعطي نفس المخرج لجميع المستخدمين. العدالة في الذكاء الاصطناعي تعني أن النظام يُؤدي بجودة متكافئة لجميع الفئات، لا أنه يُنتج نتائج متطابقة. نموذج تشخيص طبي يُشخّص بدقة 95% للرجال و70% للنساء ليس عادلاً — حتى لو كانت دقته الإجمالية 90%.

لا يمكن إضافة العدالة في نهاية المشروع كطبقة من الإصلاحات — يجب بناؤها منذ البداية:

• تحديد الفئات السكانية المتأثرة قبل اختيار مؤشرات النجاح
• تدقيق التوزيع الديموغرافي لبيانات التدريب
• تضمين أصوات المجتمعات المتأثرة في مرحلة التصميم والتقييم
• تحديد حد أدنى للأداء على كل فئة — لا فقط متوسط الأداء الكلي

الأنظمة الناجحة تقنياً قد تخفق بشرياً إذا أُهملت مرحلة ما بعد النشر. دورة الحياة الكاملة لا تنتهي عند الإطلاق — بل تستمر طوال عمر النظام:

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

المسؤولية المستمرة لا تعني فقط مراقبة الأداء — بل تعني أيضاً التواصل الصريح مع المتأثرين. الأسر في Allegheny لم تكن تعلم أن نظام ذكاء اصطناعي يُؤثر في قرارات تخص أطفالها. الشفافية هنا ليست ترفاً أخلاقياً — بل هي شرط أساسي للمساءلة الديمقراطية.

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