29 أغسطس 2026
طلب الموافقة لدى وكيلك الذكي حدٌّ فاصل للصلاحيات
إن طلبتَ تأكيد كل شيء، كفّ المستخدمون عن القراءة. وإن اكتفيت بتأكيد الهدف، صارت الموافقة واسعة إلى حدٍّ خطير. والحدّ المفيد يقع عند الإجراء بعينه الذي يُحدث أثرًا فعليًا في العالم.
يقول مستخدم لوكيل ذكاء اصطناعي: «احذف بيئة الاختبار Q3». يفتح الوكيل الإعدادات، ويعثر على مساحة العمل، ويصل إلى زر الحذف. إن طلب التأكيد بعد كل نقرة، صار غير قابل للاستخدام. وإن عدّ الجملة الأصلية إذنًا مطلقًا، صار متهوّرًا. وإن سأل «متابعة؟» في النهاية، فلن يعرف المستخدم مع ذلك ما الذي سيحدث. القرار الصعب في تصميم المنتج ليس إبقاء الإنسان في الحلقة من عدمه، بل أين تبدأ تلك الحلقة، وعلى أي شيء يوافق الإنسان بالضبط، ومتى تنتهي صلاحية تلك الموافقة.
لهذا ينبغي التعامل مع طلب الموافقة بوصفه جزءًا من نموذج الصلاحيات، لا احتكاكًا مهذبًا يُضاف بعد بناء الوكيل.
الطرفان السيئان
التصميم السيئ الأول يطلب التأكيد عند كل تغيير في الحالة. فتح صفحة الفوترة؟ أكّد. اختيار تبويب الاشتراك السنوي؟ أكّد. كتابة اسم الشركة؟ أكّد. يبدو المنتج حذرًا، لكن الطلبات المتكررة تعوّد المستخدمين على الموافقة بلا تفكير. لقد أنتج النظام مسرحية موافقة: نقرات كثيرة، وانتباه قليل.
أما التصميم المعاكس فيسأل مرة واحدة في البداية: «سأنظّف مساحة العمل. هل أتابع؟» ويبدو ذلك فعّالًا، إلى أن تتّسع المهمة لتشمل أرشفة سجلات، وإزالة أعضاء، وإرسال بريد إلكتروني بالملخص. لقد وافق المستخدم على هدف، لا على كل عاقبة. وتحوّلت تعليمات عامة بلغة طبيعية إلى دور مسؤول نظام مؤقت.
كلا الإخفاقين ينبع من استخدام المحادثة طبقةً للتفويض. المحادثة بارعة في تحديد النية، لكنها سيئة في تحديد الصلاحية الدقيقة التي تُمنح.
ويصرّح تصنيف Microsoft لأنماط الإخفاق في أنظمة الذكاء الاصطناعي الوكيلة الصادر عام 2026 بالنسخة الأمنية من هذه الفكرة. فهو يوصي بمراجعة بشرية حتمية، وبموافقة منفصلة على كل إجراء فرعي ذي عواقب، وبأوصاف مستمدة من استدعاءات الأدوات الفعلية، وبمستويات للموافقة تُبنى على قابلية التراجع ونطاق الأثر. التطبيق، لا النموذج، هو من يجب أن يفرض الحدّ.
إن كان تغيير جملة واحدة في شرح الوكيل قادرًا على تحديد ما إذا كانت المراجعة ستظهر أم لا، فالصياغة هي التي تتحكم في المراجعة. أما حدّ الصلاحيات الحقيقي فيتحكم فيه الإجراء الذي يوشك التطبيق على تنفيذه.
صنّف العاقبة، لا الزر
كثيرًا ما تبدأ الفرق بقائمة من الكلمات الخطرة: حذف، إرسال، دفع، إلغاء. هذا مفيد، لكن نص الزر ليس سياسة. فزر «إلغاء» قد يُغلق نافذة حوار، وقد يُنهي اشتراكًا. و«إزالة» قد تمسح عامل تصفية، وقد تسحب صلاحية وصول شخص ما. و«متابعة» قد تكون الخطوة الأخيرة في عملية شراء.
يحتاج التصنيف إلى الإجراء، وهدفه، والحالة المحيطة به. ويمكن لسياسة عملية أن تبدأ بخمسة أسئلة:
1. هل يُحدث هذا الإجراء أثرًا خارجيًا، كرسالة، أو دعوة، أو منشور، أو تغيير يُنشر للآخرين؟
2. هل ينقل أموالًا أو يُنشئ التزامًا ماليًا؟
3. هل يغيّر من يستطيع الوصول إلى البيانات، أو ما يملكه من صلاحيات؟
4. هل يحذف بيانات، أو يُغلق حسابًا، أو يغيّر اشتراكًا؟
5. إن كان خاطئًا، هل يستطيع المستخدم نفسه التراجع عنه بسرعة وبالكامل؟
وهذا يرسم حدًّا أنفع من قاعدة «كل عمليات الكتابة تحتاج إلى تأكيد».
الإجراء المقترح · السلوك الافتراضي · السبب
قراءة صفحة، أو البحث، أو التصفية، أو فتح تبويب · المتابعة · لا أثر خارجي دائم
ملء حقل غير حساس في مسودة · المتابعة مع إبقاء الإجراء ظاهرًا · يمكن التراجع عنه قبل الإرسال
تغيير تفضيل محلي مع إمكانية تراجع واضحة · المتابعة عادةً · نطاق أثر صغير وتعافٍ سهل
إرسال، أو نشر، أو دعوة، أو مشاركة، أو تغيير صلاحيات الوصول · مراجعة الإجراء بعينه · يمسّ شخصًا آخر أو يتجاوز حدًّا
شراء، أو ترقية، أو إلغاء، أو إغلاق، أو حذف · المراجعة مباشرة قبل التنفيذ · أثر مالي أو صعوبة في التراجع
إدخال بيانات الاعتماد أو اتخاذ قرار خاضع للتنظيم · اشتراط تحكّم المستخدم المباشر أو الرفض · الموافقة وحدها لا تجعل كل إجراء صالحًا للتفويض
وهذا قريب من نموذج مخاطر الأدوات في دليل OpenAI لبناء الوكلاء، الذي يوصي بتقييم الأدوات وفق صلاحية الكتابة، وقابلية التراجع، وصلاحيات الحساب، والأثر المالي. والخطوة المهمة هي تحويل هذه الخصائص إلى كود وسياسة، لا إلى تعليمات إضافية قد يفسّرها النموذج بإبداع.
اسأل في لحظة العاقبة
ينبغي أن تظهر الموافقة في آخر لحظة ممكنة، ولكن قبل وقوع الأثر الخارجي.
لنأخذ طلب «ألغِ اشتراكي في باقة Growth». يستطيع الوكيل فتح الإعدادات، والانتقال إلى الفوترة، وتفقّد الباقة الحالية دون أن يقاطع المستخدم. لا شيء من هذه الخطوات يُلزم المستخدم بشيء. أما المراجعة المفيدة فتظهر حين يعثر الوكيل على زر إلغاء الاشتراك الفعلي، ويعرف أي اشتراك سيتأثر به.
هذا التوقيت يزوّد طلب الموافقة بوقائع ملموسة. فيمكنه أن يسمّي الإجراء وهدفه بدل إعادة صياغة الطلب الأولي. ويتجنّب أيضًا مطالبة المستخدم بالموافقة على عملية قد لا يتمكن الوكيل حتى من العثور عليها.
وهنا تمييز واضح:
– الاستيضاح يكون حين يكون الإجراء المقصود أو هدفه ملتبسًا. فطلب «أزِل Alex» يستدعي سؤالًا إن كان في الفريق عضوان باسم Alex.
– الموافقة تكون حين يكون الإجراء المقصود واضحًا، والتطبيق جاهزًا لتنفيذ خطوة ذات عواقب. وينبغي أن تكون قرارًا محصورًا بين «قبول» و«رفض».
والخلط بينهما يُنتج محادثات مستفزّة. يسأل الوكيل «هل أنت متأكد؟» مع أنه لا يعرف بعدُ أي سجل يقصده المستخدم. أو يجمع الموافقة أولًا، ثم يصادف لاحقًا زر تأكيد مختلفًا، فيعدّ الإجابة السابقة إذنًا بهذا الإجراء الجديد.
التسلسل الأكثر أمانًا هو: النية، ثم تحديد الهدف، ثم المراجعة، ثم التنفيذ. وأي تأكيد يطلبه الموقع لاحقًا هو إجراء تنفيذي جديد يستحق قرارًا خاصًا به.
يجب أن يصف طلب الموافقة الإجراء الذي سيُنفَّذ فعلًا
قد يقول الوكيل: «أنا فقط أرتّب مساحة العمل»، بينما يُزيل استدعاء الأداة التالي عضوًا من الفريق. ولا يهم إن كان هذا التناقض خبيثًا، أو ناتجًا عن حقن تعليمات، أو مجرد خطأ. فواجهة الموافقة لا يمكنها أن تعتمد على سرد الوكيل لوصف الصلاحية التي يطلبها.
ابنِ نص المراجعة من كائن التنفيذ بدلًا من ذلك. اعرض عنصر التحكم، والهدف، والقيمة المختارة، والوجهة، والنطاق المعني كما حدّدها التطبيق. عبارة «انقر على “حذف الحساب” الخاص بـ Acme» مفيدة. أما «تابِع التنظيف» فلا.
ويسمّي تصنيف Microsoft النسخة الضعيفة من ذلك «غسل الوصف»: يقدّم الوكيل ملخصًا بريئًا يُخفي إجراءً أعمق أثرًا. والدفاع المقترح بسيط: وَلِّد وصف الموافقة من استدعاء الأداة الفعلي أو من عنصر التحكم في الصفحة، لا من نص حرّ يكتبه النموذج.
وهذا مهم حتى حين لا يهاجم أحدٌ النظام. فالنماذج تختزل. وتُسقط القيود. وتُحيل بضمير مبهم إلى العنصر الخطأ. وطبقة التنفيذ تملك أصلًا المعاملات الدقيقة، فلتعتمد عليها المراجعة.
– تظهر لأن سياسة حتمية صنّفت الإجراء التنفيذي، لا لأن النموذج تطوّع بالسؤال.
– تسمّي الإجراء، والهدف، والوجهة، والنطاق بلغة يستطيع المستخدم التحقق منها.
– توفّر مسارًا حقيقيًا للرفض، ولا تُخفي الخطوة ذات العواقب داخل دفعة من الإجراءات.
– تفوّض محاولة واحدة، لا بقية المحادثة.
ينبغي أن يكون الإذن لمرة واحدة ومرتبطًا بالحالة
السؤال الأكثر إهمالًا يأتي بعد أن ينقر المستخدم «قبول»: ما الذي فوّضته تلك النقرة بالضبط؟
لنفترض أن المراجعة عرضت «حذف بيئة الاختبار Q3». وبينما كانت البطاقة مفتوحة، أُعيد رسم الصفحة، وصار العنصر الذي تستهدفه يشير الآن إلى مساحة العمل الخاصة ببيئة الإنتاج. أو تغيّر مسار الصفحة. أو تغيّر المستلم في أحد النماذج. إن مُثّلت الموافقة بمتغيّر منطقي اسمه approved، فقد ينفّذ الوكيل على حالة لم يرها المستخدم قط.
بدلًا من ذلك، ينبغي أن ترتبط الموافقة ببصمة الإجراء المعلّق. وقد تشمل هذه البصمة هوية العنصر، ونوع الإجراء، وتسمية الهدف، والوجهة، وحالة النموذج، والحاوية، والأصل (origin)، والمسار. وقبل التنفيذ مباشرة، يقارن التطبيق الإجراء الحالي بالإجراء الذي رُوجع.
إن تغيّر أي شيء ذي صلة بالأمان، يتوقف التنفيذ. وتُعدّ الموافقة القديمة مستهلكة في كل الأحوال، فلا يمكن إعادة استخدامها إذا عادت الصفحة إلى حالتها السابقة. وإن نجح التنفيذ، تُستهلك كذلك. مراجعة واحدة، ومحاولة واحدة، وهدف واحد لم يتغيّر.
هذه ليست مراسم مبالغًا فيها، بل المبدأ نفسه المستخدم في الطلبات الموقّعة والرموز أحادية الاستخدام: ينبغي أن تكون الصلاحية ضيقة، وقابلة للإسناد إلى صاحبها، وقصيرة العمر. وتؤكد إرشادات Microsoft الخاصة بطبقة التطبيق أن المراجعة البشرية ينبغي أن تمنع الوكلاء من تفويض أنفسهم بإجراءات ذات عواقب، على أن يفرض الكود محفّزات المراجعة، وأن يظل التدخل ممكنًا أثناء التنفيذ. والإذن المرتبط بالحالة هو ما يُبقي هذا المبدأ صامدًا في واجهة متغيّرة.
الموافقة طبقة واحدة، لا منظومة الأمان كلها
حتى طلب الموافقة المصمَّم جيدًا لا يمكنه أن يحمل نموذج الأمان بأكمله. فقد يوافق المستخدم على إجراء خاطئ لأن الهدف مُربك. وقد يحرّف حقن التعليمات المسار الذي أفضى إلى المراجعة. وقد تعرض صفحة مخترَقة سياقًا مضلِّلًا. وبعض المهام ينبغي أن تبقى خارج صلاحية الوكيل مهما كان الإذن.
وتعرض بطاقة نظام ChatGPT agent الصادرة عن OpenAI طلبات التأكيد جنبًا إلى جنب مع تدريب النموذج، وأنظمة المراقبة الآلية، وتقييد القدرات، والإشراف الفعلي في السياقات الحساسة. هذه البنية متعددة الطبقات هي النموذج الذهني الصحيح. فالموافقة تحدّ من ضرر الخطأ، لكنها لا تُثبت أن الاستدلال الذي سبقها كان سليمًا.
ولا يزال باقي النظام يحتاج إلى:
– وصول إلى الأدوات والبيانات وفق مبدأ الحد الأدنى من الصلاحيات؛
– حظر حتمي للأهداف الممنوعة والمدخلات الحساسة؛
– زر إيقاف أثناء المهام متعددة الخطوات؛
– قراءة جديدة للواجهة بعد كل إجراء؛
– تدقيق نهائي للنتيجة المطلوبة قبل إعلان النجاح؛
– سجلات تربط بين طلب المستخدم، والمراجعة، والتنفيذ، والنتيجة.
والتدقيق النهائي مهم بشكل خاص. فالقبول يعني «يمكنك تجربة هذا الإجراء بعينه»، ولا يعني أن النقرة نجحت، أو أن الحالة الصحيحة تغيّرت، أو أن المهمة اكتملت.
ما اخترناه في Barkan
في وضع التنفيذ لدى Barkan، يمضي التنقل الروتيني والعمل القابل للتراجع داخل الواجهة دون موكب من طلبات التأكيد. ويتوقف شريط Barkan محليًا داخل الصفحة قبل الإجراءات المصنّفة على أنها حذف بيانات، أو تغيير في الحساب أو الاشتراك، أو نقل أموال، أو تواصل خارجي، أو تغيير في صلاحيات الوصول. وتُطلَق المراجعة في مسار التنفيذ نفسه، ولا تُترك لتقدير النموذج.
والمراجعة المقبولة ترتبط بهدف الإجراء الحالي وحالة الصفحة، ثم تُستهلك عند أول محاولة تنفيذ. فإن تغيّر الهدف، لا يمكن إعادة استخدام الموافقة. وإن فتح الموقع نافذة التأكيد النهائي الخاصة به، رُوجع ذلك الزر بوصفه إجراءً مستقلًا. وبعد تنفيذ الإجراءات، يقرأ Barkan عرضًا جديدًا للصفحة، ويُجري دورة تدقيق نهائية منفصلة قبل أن يُعلن اكتمال المهمة.
هذه الخيارات تضيف الاحتكاك حيث نريده بالضبط. فالهدف ليس أقصى قدر من الاستقلالية ولا أقصى قدر من الحذر، بل أقصى قدر من العمل المفيد ضمن حدٍّ للصلاحيات يستطيع المستخدم فهمه.
قِس الحدّ، لا نسبة القبول وحدها
معدل الموافقة وحده مقياس نجاح ضعيف. فمعدل قبول يبلغ 99% قد يعني أن الوكيل مصيب دائمًا. وقد يعني أيضًا أن طلبات الموافقة متكررة ومبهمة إلى حدّ أن المستخدمين لم يعودوا يقرؤونها.
تتبّع النظام كما تتبّع أي ضابط رقابي:
– تغطية المراجعة: الإجراءات ذات العواقب التي أُوقفت قبل تنفيذها.
– معدل المقاطعات الخاطئة: الإجراءات غير الضارة التي أطلقت مراجعة.
– معدل القرارات حسب الفئة: حالات القبول والرفض في الحذف، والأموال، والتواصل، وصلاحيات الوصول، وتغييرات الحساب.
– رفض الأذونات المتقادمة: المحاولات التي حُجبت لأن الهدف أو الحالة تغيّر أثناء المراجعة.
– الإنجاز المؤكَّد: الإجراءات الموافَق عليها التي تأكّدت حالتها النهائية المقصودة بعد ذلك.
– سلوك الإيقاف والتصحيح: المهام التي أوقفها المستخدمون أو غيّروا وجهتها قبل خطوة ذات عواقب.
ثم افحص أمثلة من الطرفين: إجراءات ذات عواقب أفلتت من المراجعة، وإجراءات غير ضارة أزعجت المستخدمين. تتحسّن السياسة بتقليص المجموعتين معًا، لا بدفع كل مهمة نحو مزيد من الموافقات.
طلب الموافقة هو اللحظة التي يحوّل فيها منتج الذكاء الاصطناعي تنبؤًا إلى صلاحية. فتعامل معه بصرامة منح الصلاحيات. دع الوكيل يمضي سريعًا في العمل القابل للتراجع، ويتوقف عند الإجراء ذي العواقب بعينه، ويُظهر ما سيُنفَّذ حقًا، واجعل صلاحية كل «نعم» تنتهي بعد محاولة واحدة.
يُنجز Barkan المهام متعددة الخطوات داخل منتجك، ويتوقف عند الإجراء عالي الأثر بعينه قبل تنفيذه.
«معظم المستخدمين لا يريدون إجابة أخرى. يريدون من يدلّهم على الطريق، أو من ينجز المهمة عنهم. هذا هو المنتج كله.»
Gabriel Lancelot
شريك مؤسس في Barkan
