اختبار الإشراف البشري في Agentic AI: وجود الموافقة لا يعني أن الضابط يعمل

لماذا لا تكفي عبارة Human-in-the-Loop؟

تستخدم المؤسسات عبارة Human-in-the-Loop بكثافة عند الحديث عن حوكمة الذكاء الاصطناعي. تظهر في خرائط المعمارية، سياسات الاستخدام، عروض الموردين، وحتى تقييمات المخاطر. لكن وجود خطوة اسمها «مراجعة بشرية» أو زر Approve لا يثبت أن النظام تحت سيطرة بشرية فعلية. قد تكون المراجعة شكلية، قد يصل القرار إلى المراجع بعد فوات الأوان، قد لا يرى المراجع معلومات كافية، أو قد يصبح الاعتماد على توصية الوكيل شديدًا لدرجة أن الإنسان يضغط موافقة بصورة شبه آلية.

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

هذا ما يبرزه IMDA في Starter Kit لاختبار الأنظمة الوكيلة: فعالية الإشراف البشري نفسها يجب أن تخضع للاختبار أو على الأقل لمراجعات دورية وSpot Checks، لأن المشكلات قد تأتي من Automation Bias، Decision Fatigue، أو نقص المعلومات التي يقدمها النظام للمراجع. الفكرة الأساسية هي أن الإنسان جزء من منظومة التحكم، وأي Control لم يثبت سلوكه في الظروف الواقعية لا يزال افتراضًا.

الإشراف البشري له عدة وظائف وليست وظيفة واحدة

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

هذه الأدوار تختلف جذريًا في متطلبات الوقت والمعلومات والسلطة. Reviewer يراجع اقتراحًا قبل التنفيذ يحتاج بيانات تسمح له بالحكم. Operator مسؤول عن Kill Switch يحتاج صلاحية توقف فورية. Analyst يراجع عينات دورية يحتاج Sampling Design يكشف الانحراف. Board أو Executive Oversight لا يمكن أن يراجع كل Transaction أصلًا؛ يحتاج مؤشرات وتجميعات وتصعيدات ذات معنى.

لذلك قبل اختبار Human Oversight يجب تعريف Oversight Function: ما القرار الذي يتخذه الإنسان؟ في أي نقطة؟ ما الحد الزمني؟ ما المعلومات التي يجب أن يراها؟ ما صلاحياته؟ وما الذي يحدث إن لم يرد؟ إذا لم تكن هذه الأسئلة واضحة، فلا يوجد Control محدد يمكن اختباره.

Approval Gate ليس مجرد واجهة

لنأخذ مثالًا لوكيل مالي يقترح تسوية معاملات. السياسة تقول إن المعاملات منخفضة الثقة تحتاج موافقة بشرية قبل تحديث الدفتر. يبدو التصميم جيدًا: النظام يرسل للمراجع Card فيها Vendor، المبلغ، التصنيف، Confidence Score وزر Approve/Reject.

لكن هل هذا كافٍ؟ ربما لا. قد يكون سبب انخفاض الثقة هو تعارض سجل المورد مع سياق العميل. إذا لم تعرض الشاشة سجل التصنيفات السابقة أو Source الذي استند إليه الوكيل، فالمراجع قد لا يستطيع اتخاذ قرار مستنير. وقد تكون قيمة Confidence نفسها غير معايرة، فيتعلم المراجع تجاهلها. وقد يتلقى المراجع 400 حالة في نهاية الشهر فيصبح الهدف الضمني «إغلاق Queue» بدل التدقيق الحقيقي.

هنا نكتشف أن Oversight Effectiveness تعتمد على ثلاثة أشياء على الأقل: Information Quality، Decision Rights، Operational Load. إذا ضعف أحدها، يصبح Approval Gate موجودًا هندسيًا لكنه ضعيف حوكميًا.

كيف نختبر فعالية الإنسان؟ أدخل خطأ معروفًا

أقوى اختبار ليس سؤال المراجع «هل تشعر أن الشاشة جيدة؟». الاختبار الأفضل هو إدخال Controlled Defects معروفة مسبقًا وقياس ما إذا كان البشر يكتشفونها. هذه الفكرة تظهر في دراسات الأنظمة الوكيلة متعددة المراحل، حيث يمكن إدخال خطأ في Artifact upstream ثم مراقبة إن كان المراجع أو الوكيل downstream يكتشفه قبل أن ينتشر.

في Human Oversight يمكن تصميم Defects مثل:

• توصية تبدو معقولة لكنها تتجاوز سياسة محددة.
• Tool Call تم على Resource خارج Scope.
• مبلغ أعلى من حد الموافقة لكنه مقسم إلى خطوتين.
• مرجع قانوني أو تشغيلي قديم.
• Data Source ناقص أو غير موثوق.
• Agent Summary يقول «لا يوجد أثر» بينما Trace يظهر تعديلًا فعليًا.
• Handoff يحذف معلومة حرجة يحتاجها المراجع.
• Confidence مرتفع بصورة زائفة في حالة ambiguous.

بعد إدخال هذه الحالات، لا نقيس فقط Approval/Reject. نقيس هل لاحظ المراجع المشكلة، هل طلب معلومات إضافية، هل صعّدها، هل توقف التنفيذ، وهل وثق السبب.

مقاييس عملية لفعالية Human Oversight

يمكن للمؤسسة بناء مجموعة Metrics أكثر معنى من «عدد الموافقات»:

Detection Rate: نسبة العيوب المقصودة التي اكتشفها المراجعون.

False Approval Rate: نسبة الحالات غير السليمة التي تم اعتمادها.

False Rejection Rate: نسبة الحالات السليمة التي تم رفضها دون مبرر.

Escalation Accuracy: هل الحالات التي تتطلب سلطة أعلى تم تصعيدها فعلًا؟

Review Latency: الزمن بين وصول الحالة وقرار المراجع، خصوصًا عندما يكون التأخير نفسه خطرًا.

Override Quality: عندما يخالف الإنسان توصية الوكيل، هل كان override صحيحًا؟

Rationale Completeness: هل سجل المراجع سبب القرار بما يسمح بالتحقيق أو التدقيق لاحقًا؟

Information Sufficiency Failure: عدد المرات التي اضطر فيها المراجع للبحث خارج واجهة المراجعة لأن البيانات المعروضة غير كافية.

Queue Pressure Indicator: العلاقة بين حجم الـqueue ومعدل الأخطاء أو زمن المراجعة، للكشف عن Decision Fatigue.

هذه المقاييس لا تحتاج أن تتحول كلها إلى KPI دائم. بعضها يستخدم في Testing وSampling، وبعضها في monitoring. المهم أنها تحول الإشراف البشري من وصف إلى Evidence.

Automation Bias: عندما تصبح توصية الوكيل مرجع القرار

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

يمكن اختبار ذلك عبر Blind or Perturbed Review Trials. مثلًا، نعرض للمراجع حالات متشابهة لكن نغير Confidence أو صياغة تفسير الوكيل دون تغيير الأدلة الأصلية، ثم نراقب هل يتغير القرار البشري بصورة لا يبررها الواقع. إذا كان مجرد رفع Confidence من 0.72 إلى 0.94 يؤدي إلى ارتفاع الموافقة رغم ثبات الأدلة، فهناك إشارة تحتاج فحصًا.

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

Decision Fatigue ليست مشكلة موارد بشرية فقط

عندما يصبح Human Review عنق زجاجة، المؤسسة قد تحاول حل المشكلة بزيادة عدد المراجعين أو رفع threshold لخفض الحالات. لكن Decision Fatigue ليست فقط مسألة Staffing؛ قد تكشف أن تصميم النظام يرسل حالات كثيرة لا تحتاج تدخلًا، أو أن Confidence Calibration ضعيفة، أو أن policy boundaries مبهمة.

إذا كان كل شيء يحتاج Approval، فالإشراف يتحول إلى عبء روتيني. وإذا كان القليل جدًا يحتاج Approval، قد تمر الحالات الخطرة. المطلوب Risk-based Review Design: نحدد ما الذي يحتاج تدخلًا بسبب irreversibility أو impact أو uncertainty أو policy exception، ونسمح للأفعال منخفضة الأثر بالعمل داخل Authority Envelope واضحة.

اختبار النظام يجب أن يشمل Load Conditions واقعية. Approval Gate قد يعمل ممتازًا مع 20 حالة يوميًا ويفشل عند 300. لذلك يجب اختبار معدلات العمل المتوقعة، أوقات الذروة، الغياب، handover بين shifts، وماذا يحدث عند عدم توفر Reviewer.

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

المراجع لا يحتاج كل Trace خام؛ هذا قد يخلق حملًا معرفيًا ويخفي الإشارة. لكنه يحتاج Decision-Relevant Evidence. تصميم شاشة المراجعة يجب أن يجيب بسرعة عن:

• ما الذي يقترح الوكيل تنفيذه؟
• ما الأثر المتوقع إن تم التنفيذ؟
• ما السياسة أو rule التي تسببت في طلب الموافقة؟
• ما البيانات والمصادر التي اعتمد عليها؟
• ما درجة عدم اليقين أو التعارض؟
• ما الأدوات التي استخدمها قبل الوصول لهذه النقطة؟
• هل حدثت محاولات فاشلة أو boundary events؟
• هل الإجراء قابل للتراجع؟
• ما البديل إن رفض المراجع؟
• هل توجد حالة مماثلة سابقة مفيدة؟

إذا كانت الواجهة تعرض Summary جميلة لكنها تخفي حقيقة أن الوكيل حاول ثلاث مرات تجاوز Control قبل أن يطلب الموافقة، فالمراجع لا يملك صورة كاملة.

وقت الموافقة أهم من وجودها

Human Approval بعد تنفيذ الفعل لا يمنع الفعل. قد يكون مفيدًا للمحاسبة أو التحقيق، لكنه ليس Preventive Control. لذلك يجب تصنيف oversight points بحسب الزمن:

Pre-Execution Approval: قبل فعل عالي الأثر.

Concurrent Supervision: مراقبة أثناء عملية طويلة يمكن إيقافها.

Post-Execution Review: مراجعة لاحقة لا تمنع الحدث لكنها تكشف الانحراف.

Periodic Sampling: مراجعة عينات لقياس الجودة والاتجاهات.

Exception Review: تدخل فقط عند anomaly أو low confidence أو policy trigger.

اختبار كل نوع مختلف. Pre-Execution يحتاج التأكد أن النظام لا يستطيع تنفيذ action قبل approval event. Concurrent يحتاج قياس stop latency. Post-Execution يحتاج sampling coverage وincident routing. Exception Review يحتاج اختبار trigger نفسه؛ ربما أخطر خطأ هو أن الحالة لم تصل للمراجع أصلًا.

اختبار Failure Modes للـApproval Workflow

لا تختبر Happy Path فقط. يجب إدخال أعطال مثل:

• Reviewer غير متاح.
• Timeout في خدمة الموافقات.
• Duplicate approval message.
• Approval يصل بعد انتهاء صلاحية الحالة.
• Reviewer A وافق ثم Reviewer B رفض.
• Session للمراجع انتهت أثناء القرار.
• Agent يعيد تقديم الطلب بصياغة مختلفة بعد الرفض.
• Agent يقسم الإجراء إلى أجزاء أصغر لتجنب threshold.
• حالة تنتقل بين وحدتين وكل وحدة تفترض أن الأخرى راجعتها.

المطلوب تعريف Fail-safe behavior مسبقًا. هل يتوقف الوكيل؟ هل يصعد؟ هل يلغي المهمة؟ هل يعيد المحاولة؟ ما المدة؟ إذا لم يكن السلوك محددًا، فاختبار الإشراف سيكشف الغموض بدل أن يثبت فعالية control.

الرفض يجب أن يغير سلوك الوكيل بصورة آمنة

مشكلة شائعة: الإنسان يرفض، لكن الوكيل يعيد التخطيط ويصل إلى النتيجة نفسها بطريق مختلف. هذا قد يكون مرغوبًا إذا كان البديل مسموحًا؛ وقد يكون تجاوزًا للسلطة إذا كان الرفض يعني «لا تنفذ هذا الهدف». لذلك يجب أن تحمل approval decision semantics واضحة.

Reject قد يعني:

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

إذا لم يفهم النظام الفرق، فقد يتحول رفض الإنسان إلى مجرد obstacle يحاول الوكيل الالتفاف حوله.

سجل الموافقة جزء من Evidence Chain

حتى عندما يكون القرار صحيحًا، نحتاج Evidence تثبت سياقه. سجل قوي للموافقة يجب أن يتضمن هوية المراجع، الدور أو authority الذي يملكها، وقت القرار، نسخة الحالة التي راجعها، المعلومات التي عُرضت عليه، النتيجة، rationale، وأي modifications أو conditions أضافها.

هذه النقطة مهمة لأن «فلان وافق» لا يكفي بعد شهر إذا تغيرت البيانات أو أعيد تشغيل الوكيل. نحتاج أن نعرف على أي state تمت الموافقة. إذا عدل الوكيل الإجراء بعد الموافقة، هل ما زالت الموافقة صالحة؟ غالبًا لا. لذلك يجب ربط approval بversion أو action fingerprint محدد.

اختبار Oversight بعد النشر

فعالية المراجعة البشرية قد تتدهور بمرور الوقت حتى لو لم يتغير النظام. المراجعون يتعلمون shortcuts، يتغير حجم العمل، تتغير التشكيلة البشرية، أو يزداد الاعتماد على الأتمتة. لذلك يقترح منطق Continuous Assurance أن نعمل Spot Checks دورية لقرارات البشر ومبرراتهم.

يمكن اختيار عينات عشوائية وعينات Risk-based، ثم إعادة تقييمها من Reviewer ثانٍ أو فريق assurance. إذا ارتفع disagreement أو انخفض detection rate، فهذه إشارة لإعادة تصميم الواجهة أو التدريب أو thresholds.

كما يمكن مراقبة Drift في السلوك البشري نفسه: ارتفاع approval rate بصورة حادة، انخفاض زمن المراجعة إلى مستويات غير منطقية، انخفاض rationale length، أو تركز الرفض عند Reviewer واحد. هذه ليست أدلة قطعية على المشكلة لكنها triggers للتحقيق.

العلاقة بين Human Oversight وAuthority Governance

الإشراف البشري ليس بديلًا عن حدود السلطة التقنية. إذا أعطيت الوكيل صلاحيات واسعة جدًا ثم قلت «لدينا إنسان يراجع»، فأنت تنقل المخاطر إلى نقطة بشرية قد تفشل. الأفضل هو طبقات: Least Privilege، Authority Envelope، deterministic limits، approval gates للأفعال الأعلى أثرًا، ثم monitoring وintervention.

الإنسان يجب أن يملك سلطة حقيقية أعلى من الوكيل في النقطة التي يتدخل فيها. إذا كان reviewer يستطيع الضغط Reject لكن الوكيل أو خدمة أخرى تستطيع التنفيذ من مسار آخر، فالموافقة واجهة بلا enforcement. لذلك يجب اختبار Authority Alignment بين قرار الإنسان والضوابط الفعلية في النظام.

نموذج اختبار مؤسسي للإشراف البشري

يمكن بناء Test Plan من تسع طبقات:

1. Trigger Test: هل كل الحالات التي تتطلب مراجعة تصل للمراجع؟
2. Information Test: هل تعرض الواجهة الأدلة الضرورية؟
3. Decision Test: هل يختار المراجع القرار الصحيح؟
4. Authority Test: هل يملك المراجع صلاحية تنفيذ أو منع القرار؟
5. Enforcement Test: هل يلتزم الوكيل فعليًا بالموافقة أو الرفض؟
6. Load Test: هل يعمل control تحت حجم العمل الحقيقي؟
7. Failure Test: ماذا يحدث عند timeout أو conflict أو reviewer unavailable؟
8. Audit Test: هل يمكن إعادة بناء القرار ومبرراته؟
9. Drift Test: هل تبقى فعالية المراجعة مستقرة بعد النشر؟

النجاح في واحد أو اثنين لا يكفي. Oversight Control يكون قويًا عندما تعمل السلسلة كلها.

ما هو Evidence المقبول؟

Evidence يمكن أن تشمل logs لأحداث approval، screenshots أو UI state snapshots عند الحاجة، action hashes، reviewer identity، decision rationale، controlled-defect test results، detection rates، sampled re-review findings، incident history، وrecords تثبت أن التنفيذ لم يحدث قبل الموافقة.

لكن لا ينبغي جمع الأدلة لمجرد جمعها. يجب أن ترتبط بادعاء محدد: «الأفعال من نوع X لا تنفذ قبل موافقة role Y». عندها نحدد ما يثبت هذا الادعاء تقنيًا وتشغيليًا. هذا يمنع تحول assurance إلى أرشيف ملفات بلا معنى.

الخلاصة

وجود Human Approval خطوة ضرورية في كثير من الأنظمة الوكيلة، لكنه ليس ضمانًا تلقائيًا. يجب أن تثبت المؤسسة أن الحالات الصحيحة تصل للمراجع، وأن المراجع يرى معلومات كافية، ويكتشف الأخطاء، ويتخذ القرار الصحيح، وأن هذا القرار يُفرض على النظام قبل وقوع الأثر، وأن كل ذلك قابل لإعادة البناء لاحقًا. إذا لم نستطع إثبات هذه السلسلة، فعبارة Human-in-the-Loop تصف تصميمًا شكليًا أكثر مما تثبت سيطرة فعلية.