موافقة بشرية قبل أن ينفّذ المساعد إجراء حسّاسا

ما معنى الموافقة البشرية قبل التنفيذ؟

«الإنسان في الحلقة» (Human-in-the-Loop) نمط رقابي يشترط مشاركة شخص في القرار قبل أن ينفّذه نظام الذكاء الاصطناعي. في المساعدين، الذين يستدعون أدوات تقرأ أنظمة حقيقية وتعدّلها، يأخذ غالبا شكل بوابة موافقة: يقترح المساعد إجراء محددا، فيتوقف التنفيذ، ويوافق شخص عليه أو يعدّله أو يرفضه.

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

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

لماذا يحتاج المساعدون إلى بوابات موافقة؟

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

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

والتنظيم يسير في الاتجاه نفسه. تشترط المادة 14 من قانون الذكاء الاصطناعي الأوروبي أن تُصمَّم أنظمة الذكاء الاصطناعي عالية المخاطر بحيث يستطيع أشخاص طبيعيون الإشراف عليها فعليا، بما في ذلك تجاوز مخرجاتها أو عكسها، وإيقافها لتتوقف في حالة آمنة. ليس كل مساعد أعمال عالي المخاطر وفق القانون، لكن بوابات الموافقة هي الشكل العملي لهذه الرقابة في المساعدين الذين يستخدمون الأدوات.

أنماط الموافقة: never وpolicy وalways

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

• يمكن أن تطابق القواعد مفتاح أداة أو نمطا مثل gmail.*، أو مستوى خطورة، أو مساعدا بعينه، أو حقولا في مدخلات الأداة مثل عنوان المستلم.
• حين تتعارض قاعدتان بالأولوية نفسها يجب أن تفوز الأشد: الرفض يتقدم على طلب الموافقة، وطلب الموافقة يتقدم على السماح.
• يجب أن يستطيع المساعد الواحد تشديد أداة (طلب الموافقة حيث تسمح السياسة) دون أن يستطيع تخفيفها أبدا.

مستويات الخطورة: read وwrite وdestructive وexternal_send

أنماط الموافقة تجيب عن سؤال «هل نسأل أم لا»، ومستويات الخطورة تشرح السبب. وسم كل أداة بأحد أربعة مستويات يتيح للسياسة أن تقول مرة واحدة «كل ما يخرج من المؤسسة يحتاج موافقة» بدلا من سرد الأدوات واحدة واحدة.

كيف توقف الموافقةُ تشغيلَ المساعد؟

في أطر المساعدين القائمة على الرسوم البيانية يكون الإيقاف مقاطعة (interrupt). الدالة interrupt() في LangGraph تعلّق الرسم البياني داخل العقدة، وتحفظ حالته عبر أداة الحفظ (checkpointer)، وتعيد حمولة إلى الجهة المستدعية، ثم ينتظر الرسم البياني حتى يُستأنف بأمر Command يحمل إجابة الإنسان، فتصبح هذه الإجابة القيمة التي تعيدها interrupt(). وتنبّه الوثائق إلى أن العقدة تبدأ من أولها عند الاستئناف، فيُعاد تنفيذ أي كود يسبق المقاطعة.

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

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

ماذا يجب أن يرى المعتمِد؟

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

• ملخص من سطر واحد مبني من الأداة ومدخلاتها، مثل «Send mail from Gmail (gmail.send) to finance@… about “Invoice 1042”».
• مفتاح الأداة ومستوى خطورتها.
• معاينة للبيانات التي ستُرسل بالضبط، مع حجب الأسرار مثل رموز الوصول وكلمات المرور ومفاتيح API واختصار النصوص الطويلة جدا.
• وقت انتهاء الصلاحية.
• الإجراءات: الموافقة، أو الرفض مع ملاحظة يراها النموذج، أو الموافقة مع بيانات مصححة يُعاد التحقق منها قبل التنفيذ.

المهل الزمنية: ماذا يحدث إذا لم يرد أحد؟

كل موافقة تحتاج مهلة، وانتهاء المهلة يجب أن يعني الرفض. الطلب الذي لم يُجب عنه يجب أن ينتهي بـ«لم يُنفَّذ»، لا بـ«نُفِّذ افتراضيا». في Botify تنتهي صلاحية الموافقات بعد 24 ساعة ما لم تحدد قاعدة في السياسة مدة أخرى، وتعلّم عملية خلفية الطلبات المتأخرة بأنها منتهية وتستأنف كل تشغيل متوقف، فينتهي بإجابة صادقة مفادها أن الإجراء لم يُعتمد في الوقت المحدد بدلا من البقاء معلّقا إلى الأبد.

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

سجلات التدقيق وإرهاق الموافقات

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

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