الخلاصة

  • أُعلن في 27 سبتمبر عن النسخة الأولى من مسودة Andreas Ehstand بشأن أفعال الرقابة البشرية على الأنظمة المؤتمتة والوكلاء. وهي مقترح فردي لا يحظى بتبنّي IETF، ولا يفرض بروتوكولًا أو شكلًا لسجل التدقيق أو طريقة قياس.
  • تفرّق المسودة بين عرض الشيء على المشرف، وفحص خاصية محددة فيه، واختيار مسار للتصرف، والإذن بفعل معين استنادًا إلى صلاحية موجودة مسبقًا. الإذن نوع من القرار، وليس دليلًا على صحة النتيجة.
  • خانة «تمت الموافقة» من دون بيان إضافي تثبت تسجيل تفاعل فحسب. وإثبات الفحص والإذن معًا يحتاج إلى دليل يبيّن كل فعل على حدة.

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

تتناول مسودة draft-ehstand-oversight-acts-00 هذه الفجوة في المفردات. أصدر IETF إعلان إتاحتها في 27 سبتمبر، وتصنفها صفحتها في Datatracker مسودة فردية نشطة، مع تنبيه صريح إلى أنها غير معتمدة من IETF وليست ذات وضع رسمي في مسار المعايير. وتقول المسودة إنها تعرّف مصطلحات فقط؛ فلا تحدد بروتوكولًا أو بنية بيانات أو إجراءً أو وسيلة للقياس. لذلك لا يصح تقديمها بوصفها قاعدة إلزامية بدأت تُطبق.

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

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

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

السؤال الحاكم إذن ليس مجرد وجود إنسان في المسار. ما النسخة التي رآها؟ ما الخاصية التي فحصها؟ أي قرار اتخذ؟ ومن أين جاءت سلطة الإذن بالفعل؟ هذه قراءة تحريرية يقدمها Daniel Kade لمقترح فردي، وليست حكمًا من IETF على أي خدمة قائمة. وينسجم الحذر مع تمييز Heng Lu بين المشاركة الشكلية والتفويض الحقيقي، لكنه لا يحل محل الدليل الخاص بكل واقعة.

المصادر