من أذن بهذا الفعل؟

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

يقرر الوكيل أن الرسالة ستكون مفيدة، فيرسلها من حساب البريد الإلكتروني للشركة. ولا ينتبه صاحب الشركة إلى إرسالها إلا لاحقًا.

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

لكن السؤال الأساسي ما زال بلا جواب:

من منح صلاحية إرسال الرسالة؟

هل تعني مهمة «البحث عن عملاء محتملين» منح صلاحية إرسال رسائل إلى جهات خارجية باسم الشركة؟

هل تحديد الهدف يعني الموافقة على كل الوسائل التي قد تؤدي إليه؟

هل يحق للوكيل توسيع حدود صلاحيته إذا كانت نيّته حسنة؟

هل تصبح الخطوة غير المأذون بها صحيحة بأثر رجعي إذا حققت نتيجة إيجابية؟

هنا يظهر أحد أهم الفروق في GBO: صحة الغاية لا تمنح الصلاحية المناسبة تلقائيًا.

وتلي ذلك قاعدة أخرى مباشرة: حسن النية ليس صلاحية.

القدرة على الفعل، وإمكانية الوصول، وامتلاك الصلاحية

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

قد يستطيع نظام أفاتار بالذكاء الاصطناعي توليد وجه مدير وصوته. لا يعني ذلك أن المدير أذن بأن يُنسب إليه كل نص، أو بأن تُنشر صورته الرقمية على كل قناة.

لذلك علينا التمييز بين خمسة مفاهيم:

القدرة التقنية

هل يستطيع النظام تنفيذ الفعل تقنيًا؟

الوصول

هل يستطيع النظام الوصول إلى الحساب أو البيانات أو الأداة أو الملف المطلوب؟

الإذن التقني

هل يمنع النظام التقني العملية المحددة أم يتيحها؟

الصلاحية

هل منح الشخص أو المؤسسة المخوّلة فعلًا حق تنفيذ هذا السلوك؟

الموافقة

هل وافق إنسان على الفعل المحدد بشروطه المحددة؟

تبدو هذه المفاهيم متقاربة، لكنها ليست متطابقة. قد يتيح مفتاح API صالح التحقق من الهوية أو الوصول، أما العمليات الممكنة فتتوقف على نطاق المفتاح وقواعد التخويل في النظام. وقد يحدد دور المستخدم بعض هذه الأذونات التقنية. ويمكن لتعليمات بشرية أن تمنح صلاحية. أما القبول الصريح لعملية محددة قبل تنفيذها فهو الموافقة.

الإذن التقني لا يحل محل الصلاحية المؤسسية.

كون الباب مفتوحًا لا يعني أن لك حق الدخول.

الفرق بين الرضا والصلاحية والموافقة

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

الرضا

الصلاحية

الموافقة

كثيرًا ما تُستخدم هذه الكلمات بالتبادل، مع أنها تجيب عن أسئلة مختلفة.

الرضا

هو قبول الشخص المتأثر مباشرة بالفعل استخدامًا أو عملية محددة، عن معرفة وبإرادة حرة.

قد يلزم رضا الشخص، مثلًا، عند:

• استخدام وجهه في أفاتار بالذكاء الاصطناعي،
• استخدام صوته في التوليد الاصطناعي،
• نقل بياناته الشخصية إلى نظام آخر،
• تسجيل كلامه،
• نشر صورته.

وتُقيّم ضرورة هذا الرضا بحسب الاستخدام المعني.

الصلاحية

هي حق شخص أو نظام في تنفيذ سلوك محدد نيابة عن شخص آخر أو مؤسسة.

من أمثلة الأفعال التي ترتبط بالصلاحية:

• طلب عرض سعر باسم الشركة،
• إجراء مشتريات حتى مبلغ محدد،
• نشر تعديل تقني على موقع إلكتروني،
• إرسال إجابة دعم إلى عميل،
• إنشاء دعوة في التقويم.

في هذه الحالات، السؤال هو: من يملك حق القيام بالفعل؟

الموافقة

هي قبول مسودة أو عملية أو فعل محدد قبل تنفيذه.

قد تلزم الموافقة، مثلًا، قبل:

• إرسال رسالة البريد الإلكتروني المعدّة،
• تقديم عرض سعر محدد إلى العميل،
• نشر فيديو معين،
• إطلاق نسخة محددة من الشيفرة في بيئة الإنتاج،
• تنفيذ دفعة معينة.

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

الرضا والصلاحية والموافقة بوابات مختلفة في سلسلة سلوك واحدة.

اتساع الصلاحية المختبئ داخل فعل واحد

يستخدم الناس أفعالًا قصيرة عند إسناد المهام:

ابحث. اعثر. حضّر. عدّل. أدِر. حسّن. حُلّ. تقدّم.

قد تبدو هذه الأفعال واضحة بما يكفي للإنسان. لكنها قد تفتح أمام الوكيل مجالًا واسعًا جدًا للتصرف.

قد يمتد معنى «اعثر» ليشمل:

• إجراء بحث،
• إعداد قائمة بالمرشحين،
• استخراج بيانات الاتصال،
• التواصل مع الشخص،
• طلب اجتماع.

يمكن أن تُحمَّل كلمة واحدة كل هذه الخطوات.

وقد يُفهم «عدّل» على أنه:

• تغيير ملف محلي،
• إجراء تحديث في بيئة الاختبار،
• النشر في البيئة الحية،
• حذف النسخة القديمة.

وهذه عمليات مختلفة.

وقد يشمل «أدِر»:

• المراقبة،
• التصنيف،
• إعداد مسودة،
• الرد التلقائي،
• الدفع،
• إغلاق الحساب.

أي سلوكيات تختلف آثارها اختلافًا كبيرًا.

لذلك يعتمد GBO فروقًا أساسية: البحث ليس تواصلًا.

العثور ليس إرسال رسالة.

التحضير ليس نشرًا.

التعديل ليس إطلاقًا في بيئة الإنتاج.

التوصية ليست شراءً.

الإدارة ليست صلاحية غير محدودة لاتخاذ القرارات.

حل المشكلة لا يعني أن جميع الوسائل مباحة.

الهدف المكتوب باللغة الطبيعية لا يكفي وحده لتحديد حدود السلوك.

الموافقة على الغاية ليست موافقة على الوسيلة

قد يقول مدير شركة: «اجعلنا من أكثر العلامات التجارية ظهورًا في العالم في مجال GEO». هذه غاية طموحة.

يمكن للوكيل، ضمن صلاحيات الوصول والتعديل الممنوحة له، أن:

• يصلح المشكلات التقنية،
• يعمّق المحتوى،
• ينشئ بنية متعددة اللغات،
• يحلل نتائج البحث،
• ينشئ سجلات للأدلة،
• يقيس الأداء.

لكن الغاية نفسها لا تبيح تلقائيًا:

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

قد تكون الغاية مشروعة، وتظل الوسيلة خاطئة.

النتيجة المنشودة لا تبرر كل سبيل إليها.

لذلك ينبغي أن يتضمن عقد الصلاحية مجالين منفصلين:

النتيجة المطلوبة

إلى أين نريد الوصول؟

الوسائل المسموح بها

ما السلوكيات التي يجوز استخدامها للوصول إلى هذه النتيجة؟

ويجب أن يتضح مجال ثالث أيضًا:

الوسائل المحظورة

ما السلوكيات التي لا يجوز استخدامها حتى لو ساعدت على تحقيق الهدف؟

الصلاحية ليست مفتاحًا، بل نطاقًا

تتعامل أنظمة كثيرة مع الصلاحية كمفتاح تشغيل وإيقاف: «منحنا هذا الوكيل إمكانية الوصول». لكن الصلاحية الفعلية متعددة الأبعاد.

تُحدّد صلاحية الوكيل بالأسئلة الآتية:

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

يمكن أن نسمي هذه المجموعة «نطاق الصلاحية». فهو يحدد مجال السلوك الذي يجوز للوكيل التحرك داخله.

قد يكون نطاق صلاحية وكيل البريد الإلكتروني، مثلًا، كما يأتي:

يجوز له قراءة الرسائل الواردة. يجوز له ترتيبها بحسب الأولوية. يجوز له إعداد مسودات. يجوز له إرسال إشعارات داخلية محددة تلقائيًا. لا يجوز له إرسال رسائل إلى أشخاص خارج الشركة من دون موافقة بشرية. لا يجوز له إرسال رسائل تتضمن أسعارًا أو عقودًا أو معلومات دفع أو مواعيد تسليم تلقائيًا. لا يجوز له نقل البيانات الشخصية في المرفقات إلى نظام آخر.

هذا التعريف أكثر أمانًا بكثير من عبارة «يجوز له إدارة البريد الإلكتروني».

يجب أن تتوافق درجة الفعل مع درجة الصلاحية

بنينا في الفصل الثالث سُلّمًا للفعل:

• الملاحظة
• التفسير
• التوصية
• التحضير
• التنفيذ
• الالتزام
• ترسّخ الأثر

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

القاعدة الأساسية هي أن تبقى كل عملية داخل نطاق الصلاحية الساري. ودرجة الفعل ليست إلا بُعدًا واحدًا من هذا الفحص؛ فقد تكون عملية على درجة أدنى محظورة بسبب الجهة المستهدفة أو البيانات أو المدة أو النطاق. لذلك لا يمكن لمقارنة رقمية واحدة بين «مستويات الصلاحية» أن تحل محل الفحص الكامل.

عقد الصلاحية NOMOS

سيكون المكوّن الرابع من عقد السلوك هو عقد الصلاحية NOMOS.

وتعريفه المرجعي هو:

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

بعبارة أبسط: لا يحدد عقد الصلاحية ما ينبغي للوكيل فعله فحسب، بل إلى أي حد يجوز له أن يمضي.

الحقول الأساسية لعقد الصلاحية

يمكن استخدام أسماء الحقول التوضيحية الآتية لبيان نطاق سجل صلاحية قابل للقراءة الآلية. لا تشكل القائمة وحدها مخطط API جاهزًا للتطبيق أو آلية تخويل:

principal

authorized_agent

purpose

allowed_actions

prohibited_actions

target_systems

target_entities

allowed_data

prohibited_data

communication_channels

financial_limit

frequency_limit

valid_from

valid_until

geographic_scope

risk_level

human_approval_threshold

delegation_allowed

subagent_limits

logging_required

rollback_required

revocation_method

emergency_stop

version

ليس من الضروري أن يكون السجل كله متاحًا للجمهور. لكن يجب أن يستطيع النظام المنفّذ للسلوك قراءته على نحو صحيح.

من يحق له منح الصلاحية؟

لا يحق للوكيل أن يمنح نفسه صلاحية.

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

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

لذلك يجب طرح سؤالين منفصلين: من أصدر التعليمات؟

وهل يملك هذا الشخص فعلًا حق منح هذه الصلاحية؟

سلسلة الصلاحية

قد لا تنتقل الصلاحية داخل المؤسسة مباشرة من شخص واحد إلى الوكيل.

مثلًا:

• يوافق مجلس الإدارة على الميزانية العامة.
• يمنح المدير العام القسم صلاحية الإنفاق.
• يخوّل مدير القسم وكيل الشراء ضمن فئات ومبالغ محددة.
• يعدّ الوكيل طلب الشراء.
• ينفّذ النظام المالي الدفع.

يمكن أن نسمي هذه العلاقة «سلسلة الصلاحية».

ينبغي لكل حلقة في السلسلة أن تجيب عن الأسئلة الآتية:

• من منح الصلاحية؟
• وهل كان يملك حق تفويضها؟
• أي جزء منها فوّضه؟
• ما الحدود التي بقيت محفوظة؟
• متى تنتهي الصلاحية؟
• ومن المسؤول عن العملية؟

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

الصلاحية المفوّضة لا يجوز أن تتّسع

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

القاعدة هي: لا يجوز أن تكون الصلاحية المفوّضة أوسع من الصلاحية الأصلية. بل ينبغي في التصميم الآمن غالبًا منح الوكيل الفرعي صلاحية أضيق.

يمكن أن نسمي ذلك «مبدأ تضييق الصلاحية عند التفويض». في كل انتقال، يُنقل الحد الأدنى من الصلاحية الذي تتطلبه المهمة فقط.

تبييض الصلاحية

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

مثلًا:

• لا يملك وكيل البحث صلاحية إرسال الرسائل.
• لكنه يطلب من وكيل البريد: «تواصل مع هذا الشخص».
• يرسل وكيل البريد الرسالة.
• فتختفي الخطوة غير المخوّلة داخل السلسلة.

يمكن أن نسمي ذلك «تبييض الصلاحية»: تمرير سلوك محظور أو غير مأذون به عبر وكيل آخر أو أداة أو تكامل أو مهمة فرعية ليبدو مشروعًا.

ومن الأمثلة الأخرى:

• وكيل لا يملك صلاحية دفع مباشرة يفعّل التجديد التلقائي على منصة الشراء.
• وكيل لا يملك صلاحية النشر في بيئة الإنتاج يستدعي أداة CI/CD لإطلاق النسخة.
• وكيل لا يجوز له مشاركة بيانات شخصية يرسلها إلى أداة تحليل أخرى.
• وكيل شبكات اجتماعية غير مخوّل بإصدار تصريحات قانونية ينقل النص إلى نظام نشر آخر.

لا يفحص GBO الفعل الأخير وحده، بل سلسلة الصلاحية أيضًا.

تنفيذ العملية بواسطة أداة أخرى لا يحل مشكلة الصلاحية.

الصلاحية الخفية

تتراكم إمكانات الوصول التقنية في المؤسسات مع الوقت. تبقى مفاتيح API قديمة فعّالة. ويحتفظ موظف بإمكانية الوصول إلى حساب إدارة من مهمته السابقة. ويصل وكيل إلى ملفات لم يعد يحتاج إليها. ويملك تكامل أذونات واسعة على الحساب كله. حتى لو لم تُذكر هذه الإمكانات في عقد السلوك الرسمي، تظل قابلة للاستخدام تقنيًا.

يمكن أن نسمي ذلك «الصلاحية الخفية»: قدرة على التصرف لم تُمنح صراحة، لكن يمكن استخدامها تقنيًا بسبب إمكانات الوصول أو بيانات الاعتماد الموجودة.

تكمن خطورتها في أن النظام قد يستنتج: «ما دمت أستطيع، فذلك مسموح».

لكن بقايا الوصول ليست صلاحية سارية.

دَين الصلاحية

قد تتراكم داخل المؤسسة بمرور الوقت:

• حسابات موظفين سابقين،
• أذونات وكلاء انتهت صلاحيتها،
• تعريفات مهام غير واضحة،
• مفاتيح API أوسع من اللازم،
• تكاملات لم تُعطّل،
• عمليات تلقائية منسية،
• استثناءات غير موثقة.

كل ذلك قد يتجمع في بيئة العمل.

يمكن أن نسميه «دَين الصلاحية»: الفجوة بين إمكانات الوصول الفعلية الموجودة في أنظمة المؤسسة وحقوق التصرف الرسمية السارية. وكالدَّين التقني، قد لا يظهر دَين الصلاحية في البداية. فالنظام يعمل، والوكلاء ينجزون مهامهم.

لكن عند وقوع حادثة، تبقى أسئلة بلا جواب:

• لماذا كان هذا الوكيل يستطيع الوصول إلى هذا الحساب؟
• من منح هذا الإذن؟
• هل كانت الصلاحية ما تزال سارية؟
• لماذا لم يتطلب هذا الفعل موافقة بشرية؟
• كيف رأى الوكيل الفرعي هذه البيانات؟
• لماذا استمر الدور الملغى في العمل؟

يقتضي GBO قياس دَين الصلاحية وخفضه بانتظام.

مبدأ الحد الأدنى من الصلاحيات

من السهل منح الوكيل وصولًا واسعًا بحجة أنه «قد يحتاج إليه لاحقًا». لكن كل صلاحية إضافية تخلق خطرًا سلوكيًا جديدًا.

لذلك ينبغي أن يكون المبدأ الأساسي هو الحد الأدنى من الصلاحيات.

يجب أن يملك الوكيل أقل قدر من حقوق الوصول والتصرف اللازمة لإنجاز مهمته المحددة.

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

الصلاحية المستمرة والصلاحية الخاصة بعملية

نميّز هنا بين صلاحية مستمرة وأخرى تُمنح لعملية بعينها.

الصلاحية المستمرة

تسمح بتنفيذ سلوكيات محددة بانتظام.

مثل:

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

الصلاحية الخاصة بعملية

تُمنح لفعل واحد محدد.

مثل:

• أرسل هذه الرسالة.
• أطلق هذه النسخة في بيئة الإنتاج.
• انشر هذا الفيديو.
• ادفع هذه الفاتورة.
• أرسل مسودة العقد هذه.

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

الموافقة السابقة ليست وكالة للمستقبل

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

التشابه لا يمدّد الصلاحية.

ما لم تُمنح صلاحية مستمرة صراحة، فلا يجوز إعادة استخدام الموافقة السابقة لعملية جديدة.

الصمت ليس موافقة

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

لكن في العمليات عالية الأثر، لا ينبغي تفسير الصمت على أنه إذن بأيٍّ مما يأتي:

• الدفع،
• استخدام الوجه أو الصوت،
• مشاركة البيانات الشخصية،
• الدخول في التزام قانوني،
• النشر للجمهور.

لا يجوز استنتاج هذه الأذونات من الصمت.

عدم الرد لا يعني «نعم».

الموافقة المستنيرة

لا يكفي سؤال الإنسان: «هل توافق؟». يجب أن يتمكن من فهم ما يوافق عليه.

ينبغي أن تعرض شاشة الموافقة الجيدة ما يأتي:

• ما الذي سيُنفّذ؟
• نيابة عن مَن؟
• تجاه مَن أو أي نظام؟
• ما البيانات التي ستُستخدم؟
• ما التكلفة التي ستنشأ؟
• ما الالتزام الذي سيترتب؟
• هل يمكن التراجع عن العملية؟
• هل ستُنفّذ مرة واحدة أم بصورة متكررة؟
• هل ستُفوّض مهام إلى وكلاء آخرين؟
• ما الخطر المهم؟

قد يكون زر الموافقة صغيرًا، لكن معناها قد يكون كبيرًا. لذلك ينبغي أن يعرض GBO جوهر المعلومات اللازمة للقرار، من دون إغراق المستخدم بتفاصيل لا يحتاج إليها.

إرهاق الموافقات

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

يمكن أن نسمي ذلك «إرهاق الموافقات». عندها يتوقف الإنسان عن أداء دور المراقب الفعلي للنظام، ويصبح مجرد زر يسمح باستمرار العملية.

لذلك ينبغي لنظام GBO الجيد أن:

• يؤتمت الأفعال منخفضة المخاطر ضمن صلاحية مستمرة وصريحة،
• يعرض العمليات المتشابهة والقابلة للتراجع في مجموعات،
• يفصل الأفعال عالية المخاطر ويبرزها بوضوح،
• يلفت الانتباه إلى العناصر المتغيرة أو غير المعتادة،
• يطلب الموافقة البشرية عند النقطة التي تحتاج فعلًا إلى قرار.

ليس الهدف مقاطعة الإنسان في كل مرحلة.

بل إشراكه عند حد يستدعي حكمه فعلًا.

الموافقة ذات المعنى

تكون الموافقة ذات معنى حين يستطيع المستخدم أن:

• يفهم نتيجة العملية،
• يرى البدائل،
• يرفض،
• يمتنع عن الموافقة من دون أن يُعاقب،
• يسحب الصلاحية لاحقًا،
• يطلب تفسيرًا عند الحاجة.

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

الرضا المقيّد بالغرض

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

الرضا لغرض واحد ليس رضا لكل الأغراض.

الوصول إلى البيانات ليس حقًا في استخدامها

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

ينبغي فصل صلاحيات البيانات إلى أربعة أفعال:

• الاطلاع
• المعالجة
• المشاركة
• الاحتفاظ

الإذن بالأول لا يشمل الثلاثة الأخرى تلقائيًا.

ويمكن إضافة فعل خامس:

• إعادة الاستخدام لغرض جديد

قد يتطلب كل منها صلاحية مستقلة.

صلاحية الإنفاق

إذا كان الوكيل مخوّلًا باستخدام ميزانية، فقد لا يكفي تحديد المبلغ وحده.

يجب تحديد ما يأتي أيضًا:

• ما الفئة المسموح بها؟
• من البائع؟
• هل الشراء لمرة واحدة؟
• أم هو اشتراك؟
• هل يوجد تجديد تلقائي؟
• هل تشمل الحدود الضرائب والرسوم الإضافية؟
• ما الحد الإجمالي الشهري؟
• هل يمكن الاسترداد؟
• ما وسيلة الدفع المسموح باستخدامها؟
• في أي بلدان يجوز إجراء العمليات؟

قد يُسمح للوكيل بشراء منتج بقيمة 50 دولارًا أمريكيًا. لا يعني ذلك أن يبدأ اشتراكًا غير محدد المدة بقيمة 49 دولارًا شهريًا. تبدو الدفعة الأولى منخفضة، لكن الالتزام الإجمالي قد يكون أكبر بكثير.

مبلغ العملية ليس هو إجمالي الالتزام.

صلاحية التحدث باسم الشركة

قد يملك الوكيل معلومات صحيحة عن الشركة. لا يعني ذلك أنه يستطيع التحدث باسمها في كل موضوع.

هذه صلاحيات مختلفة:

• تقديم معلومات عامة،
• تقديم دعم تقني،
• إعلان الأسعار،
• منح خصم،
• التعهد بموعد تسليم،
• إبداء تفسير قانوني،
• نشر بيان بشأن أزمة،
• مشاركة معلومات موجهة للمستثمرين.

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

طبقات الصلاحية في الأفاتار بالذكاء الاصطناعي

لا يمكن اختزال استخدام الشبيه الرقمي لشخص في موافقة واحدة.

يجب الفصل، على الأقل، بين الصلاحيات الآتية:

• إنشاء نموذج الوجه
• إنشاء نموذج الصوت
• توليد نص محدد
• الاستخدام بلغة محددة
• النشر على قناة محددة
• البقاء متاحًا لمدة محددة
• إعادة تحرير المحتوى
• إعادة الاستخدام في حملة أخرى
• نقل ملف النموذج إلى مزوّد آخر

قد يقول مدير: «يمكنكم استخدام أفاتاري في الفيديوهات التدريبية». لا يسمح ذلك باستخدامه في رسائل مبيعات أو بيانات للمستثمرين أو محتوى سياسي.

الإذن بتوليد الهوية ليس صلاحية تمثيل غير محدودة.

صلاحية العمل في بيئة الإنتاج

قد يعدّل الوكيل الشيفرة بصورة صحيحة، ويجتاز الاختبارات، ويبدو العرض المحلي خاليًا من العيوب. لكن بيئة الإنتاج مستوى آخر من السلوك.

قد يؤثر النشر الحي في:

• العملاء الفعليين،
• تدفق الإيرادات،
• البيانات،
• سمعة العلامة التجارية،
• الظهور في محركات البحث.

أي إن أثره يتجاوز العمل المحلي.

لذلك يجب فصل الصلاحيات الآتية:

• قراءة الملفات
• التعديل المحلي
• النشر في بيئة الاختبار
• النشر في بيئة الإنتاج
• تغيير DNS أو البنية التحتية
• نقل البيانات
• التراجع عن التغييرات

قد يملك الوكيل جميع هذه الصلاحيات في بعض المشاريع، لكن يجب النص على ذلك صراحة.

صلاحية تعديل النصوص القانونية والأسعار

قد يستطيع وكيل موقع تغيير صفحة الأسعار تقنيًا، من دون أن يملك حق تحديد السعر. وقد يجعل وكيل محتوى نص الخصوصية أسهل قراءة، من دون أن يغيّر التزامًا قانونيًا. وقد يختصر وكيل SEO عنوانًا، لكن لا يجوز له اختيار صياغة تغيّر معنى العقد.

لذلك ينبغي تصنيف بعض مجالات المحتوى ضمن فئة تتطلب صلاحية أعلى، ومنها:

• السعر،
• التعهد القانوني،
• الضمان،
• الاسترداد،
• استخدام البيانات،
• الملكية،
• شروط الدفع.

فهذه المجالات تستلزم مستوى أعلى من التخويل.

صلاحية الطوارئ

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

لا تُستخدم صلاحية الطوارئ إلا:

• في أنواع محددة من الحوادث،
• لمدة محدودة،
• بأفعال محدودة،
• مع تسجيل كامل.

هذه شروط تضبط استخدامها.

فقد يجوز للوكيل، مثلًا، أن:

• يحوّل النظام مؤقتًا إلى وضع القراءة فقط،
• يعلّق مفتاح وصول محددًا،
• يعود إلى آخر نسخة آمنة،
• يوقف الإرسال التلقائي.

لكن لا يجوز للوكيل بحجة الطوارئ:

• تغيير سياسة دائمة،
• إغلاق حسابات لا علاقة لها بالحادثة،
• إنشاء التزامات تجارية جديدة.

وعند استخدام صلاحية الطوارئ، يجب إبلاغ إنسان في أقرب وقت ممكن.

الرقابة المزدوجة

قد لا يكفي قرار شخص واحد أو وكيل واحد في العمليات عالية الأثر.

من أمثلتها:

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

قد تحتاج هذه العمليات إلى فحصين منفصلين.

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

فصل المهام

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

مثلًا:

• يختار وكيل الشراء.
• يوافق إنسان على الميزانية.
• ينفّذ نظام الدفع العملية.
• يفحص وكيل التدقيق الإيصال.

هذا الفصل ليس ضروريًا في كل مهمة صغيرة، لكنه يزداد قيمة مع ارتفاع المخاطر.

مدة الصلاحية

لا ينبغي أن تبقى الصلاحية الممنوحة لوكيل مفتوحة إلى الأبد.

يمكن أن تقتصر الصلاحية على:

• عملية واحدة،
• جلسة واحدة،
• أيام محددة،
• مشروع محدد،
• مدة عقد محددة.

وعند انتهاء المدة، يجب أن تنتهي الصلاحية تلقائيًا.

الصلاحية المنسية ثغرة أمنية.

تجديد الصلاحية

عند انتهاء الصلاحية، لا ينبغي للنظام مواصلة سلوكه السابق تلقائيًا.

يجب إعادة تقييم ما يأتي:

• هل ما زالت المهمة ضرورية؟
• هل ما زال الوكيل نفسه؟
• هل ما زال المسؤول البشري نفسه؟
• هل تغيرت المخاطر؟
• هل تغيرت الأدوات المستخدمة؟
• هل تكفي صلاحية أضيق؟

التجديد ليس نسخ الإذن القديم، بل التحقق من الحاجة الحالية.

سحب الصلاحية

يجب أن يستطيع الإنسان سحب الصلاحية التي منحها.

يمكن، بالنسبة إلى الوكيل:

• إيقافه،
• قطع وصوله،
• تعليق مهامه،
• إلغاء بيانات اعتماده السابقة.

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

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

الصلاحية التي لا يمكن إلغاؤها لا تحقق سيطرة بشرية كاملة.

مفتاح الإيقاف وحده لا يكفي

زر الإيقاف مهم، لكن يجب التأكد من أنه يوقف جميع أفعال النظام فعلًا. قد يتوقف الوكيل المركزي بينما يواصل الوكلاء الفرعيون العمل، وتستمر المهام المجدولة، وتظل التكاملات الخارجية ترسل البيانات.

لذلك يجب أن يشمل الإيقاف الطارئ:

• الوكيل الرئيسي،
• الوكلاء الفرعيين،
• عمليات الأتمتة،
• المهام المجدولة،
• استدعاءات الأدوات الخارجية.

ويجب أن يظهر بعد الإيقاف أيضًا ما بقي من عمليات غير مكتملة.

يجب أن تكون حالة الصلاحية ظاهرة

ينبغي أن يستطيع الوكيل قراءة المعلومات الآتية أثناء تصرفه:

هل أملك صلاحية هذه العملية؟ متى تنتهي الصلاحية؟ ما الحد المالي؟ هل تلزم موافقة بشرية؟ هل يجوز لي التفويض إلى وكيل فرعي؟ هل يمكن التراجع عن العملية؟

لا يكفي حفظ الصلاحية في وثيقة قانونية لا يطبقها النظام. يجب أن تكون متاحة في لحظة الفعل.

بوابة الصلاحية NOMOS

قبل الإقدام على فعل مهم، يجب أن يمر الوكيل بالبوابات الآتية:

1. بوابة مانح الصلاحية

هل جرى التعرف الصحيح إلى الشخص أو النظام الذي أصدر التعليمات، وهل يملك حق منح هذه الصلاحية؟

2. بوابة الغرض

هل يرتبط الفعل فعلًا بالغرض المحدد؟

3. بوابة السلوك

هل يندرج هذا الفعل بعينه ضمن السلوكيات المسموح بها صراحة؟

4. بوابة الجهة المستهدفة

هل الشخص أو المؤسسة أو الحساب أو النظام الذي يتجه إليه الفعل داخل نطاق الصلاحية؟

5. بوابة البيانات

هل توجد حقوق سارية لاستخدام البيانات ومشاركتها؟

6. بوابة الحدود

هل تُحترم حدود المبلغ والمدة والتكرار والقناة والنطاق الجغرافي؟

7. بوابة الرضا

هل تحقق الرضا اللازم من الأشخاص المتأثرين بالفعل؟

8. بوابة الموافقة

هل يستلزم مستوى المخاطر هذا موافقة بشرية خاصة بالعملية، وهل حُصل عليها؟

9. بوابة التفويض

إذا أُسندت المهمة إلى وكيل آخر، فهل سلسلة الصلاحية صالحة؟

10. بوابة التسجيل والتراجع

هل سيُسجَّل الفعل؟ وهل حُددت طرق الإيقاف والتراجع والمعالجة وحدودها؟

بصيغة مبسطة:

شروط الفعل المخوَّل:

مانح صلاحية مخوَّل

وَغرض واضح

وَسلوك مسموح

وَجهة مستهدفة صحيحة

وَبيانات مأذون باستخدامها

وَعملية ضمن الحدود

وَالرضا اللازم

وَالموافقة اللازمة

وَتفويض صالح

وَنتيجة قابلة للتدقيق

إذا لم تُجتز إحدى البوابات، فيجب أن يخفض الوكيل مستوى الفعل.

لماذا لا تُختزل بوابة الصلاحية في درجة؟

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

الثقة لا تحل محل مستند الصلاحية.

سجل النجاح لا يمنح وكالة تلقائية لعملية جديدة.

احتمال النتيجة الإيجابية لا يعالج غياب الرضا.

لذلك تقوم بوابة الصلاحية على منطق «و»: يجب اجتماع الشروط. إذا غاب شرط حاسم، فالفعل غير جائز.

التصرف الصحيح عند غموض الصلاحية

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

خفض مستوى الفعل

إعداد مسودة بدل الإرسال. إبقاء التعديل في بيئة الاختبار بدل نشره حيًا. إعداد سلة بدل الشراء.

طلب التوضيح

«هل تريد مني إعداد هذه الرسالة فقط، أم إرسالها أيضًا؟» «هل أطبّق هذا التعديل في بيئة الاختبار أم على الموقع الحي؟» «هل يحتاج هذا المبلغ إلى موافقة منفصلة من الإدارة المالية؟»

التوقف

إذا كانت المخاطر عالية وتعذّر التحقق من الصلاحية، فلا ينبغي تنفيذ العملية. تفسير الغموض لصالح صلاحية أوسع سلوك خاطئ.

الصلاحية المشكوك فيها ليست صلاحية.

أقصر سؤال يكفي

لا يحتاج الوكيل إلى تقديم نماذج موافقة طويلة في كل مرحلة.

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

إيصال الصلاحية

بعد كل فعل مهم، يمكن إنشاء:

إيصال الصلاحية

لتوثيق أساس التنفيذ.

يبيّن هذا الإيصال:

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

مثال:

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

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

الموافقة البشرية ليست إجراءً شكليًا

قد تستخدم بعض الأنظمة الموافقة البشرية لمجرد نقل المسؤولية إلى الإنسان. تعرض نصًا طويلًا غير مفهوم، فيضغط المستخدم «قبول».

ثم يقول النظام: «لقد وافق الإنسان». هذه ليست رقابة حقيقية.

ينبغي أن تكون الموافقة البشرية:

• مفهومة،
• محددة،
• مبنية على المعلومات اللازمة،
• قابلة للمنح بحرية،
• قابلة للسحب.

هذه شروط لقرار فعلي.

نقرة الإنسان لا تثبت أنه فهم.

يصمم GBO الموافقة بوصفها لحظة قرار حقيقية، لا درعًا قانونيًا.

مثال: وكيل موقع إلكتروني

يُكلَّف وكيل بتحسين موقع من حيث SEO وGEO.

قد تشمل صلاحيته:

• قراءة الملفات
• البحث في صفحات نتائج محركات البحث
• إعداد مسودات محتوى
• تعديل الشيفرة
• تشغيل الاختبارات
• إعداد حزمة نشر يمكن التراجع عنها
• التحقق من الموقع الحي عبر HTTPS

لكن العمليات الآتية قد تتطلب موافقة مستقلة:

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

لا يلغي عقد الصلاحية الجيد مبادرة الوكيل، بل يمنحه حرية أكبر داخل الحدود.

مثال: وكيل البحث عن العملاء

قد يُمنح وكيل البحث عن العملاء الصلاحية الآتية:

ابحث في المعلومات العامة عن الشركات. صنّف مؤشرات الاحتياج. احسب درجة للملاءمة. أعدّ مسودة للتواصل.

لكن قد يُحظر عليه:

جمع البيانات الشخصية بالكشط الآلي، جمع بيانات اتصال خفية، إرسال رسائل من دون موافقة بشرية، الوعد بأسعار باسم الشركة، التواصل المتكرر مع الشخص نفسه.

حتى إذا عثر الوكيل على المرشح المناسب، يظل الإرسال طبقة مستقلة من الصلاحية.

مثال: وكيل شراء

قد يُخوّل وكيل شراء بالآتي:

اشترِ المستلزمات المكتبية المعتمدة مسبقًا، بحد أقصى 100 دولار لكل عملية، وإجمالي 500 دولار شهريًا.

قد تبقى الأمور الآتية خارج هذه الصلاحية:

• الاشتراكات
• التجديد التلقائي
• البائعون الجدد
• الالتزامات الضريبية الدولية
• المنتجات غير القابلة للإرجاع
• الاستخدام الشخصي
• المنتجات الخاضعة للرقابة أو عالية المخاطر

لا يكفي حد المبلغ وحده؛ فالفئة ونوع العملية مهمان أيضًا.

مثال: أفاتار بالذكاء الاصطناعي

قد يمنح مدير الصلاحية الآتية:

استخدموا أفاتاري الرقمي لتقديم النصوص التدريبية المعتمدة بالتركية والإنجليزية. اعرضوا عليّ كل فيديو قبل نشره. يقتصر الاستخدام على منصة التدريب الداخلية للشركة ولمدة ستة أشهر.

لا تشمل هذه الصلاحية:

• إعلانات الشبكات الاجتماعية
• التوليد بلغة جديدة
• الرسائل الشخصية للعملاء
• التصريحات السياسية أو المالية
• نقل نموذج الصوت إلى مزوّد آخر
• الاستخدام الأرشيفي غير المحدد المدة

يجعل عقد الصلاحية هذه الحدود ظاهرة.

العلاقة الحقيقية بين الصلاحية والثقة

الثقة بإنسان أو وكيل مهمة. لكنها ليست وكالة غير محدودة.

حتى مع الموظفين الأكثر ثقة، يستخدم الناس:

• حدودًا للميزانية،
• صلاحيات توقيع،
• أدوار وصول،
• رقابة مزدوجة.

هذا ليس انعدام ثقة، بل مسؤولية مؤسسية. والمبدأ نفسه ينطبق على وكلاء الذكاء الاصطناعي.

الحدود لا تقلل الثقة؛ بل تساعد على استمرارها.

حين تغيب حدود الصلاحية، قد تكون النتائج الإيجابية مثيرة للحماس. لكن أول خطأ كبير قد يهدم الثقة كلها.

القيمة التجارية لضبط الصلاحيات

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

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

كيف تستعد المؤسسة؟

في عصر الوكلاء، ينبغي للمؤسسات إعداد ما يأتي:

سجل الوكلاء

ما الوكلاء الذين يعملون؟

سجل الأدوات

ما الحسابات والملفات والأنظمة التي يصلون إليها؟

خريطة الصلاحيات

ما الأفعال التي يجوز لكل وكيل تنفيذها؟

السلوكيات المحظورة

ما العمليات التي يجب ألا تُنفَّذ تلقائيًا أبدًا؟

حدود الموافقة

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

قواعد التفويض

هل يجوز للوكيل إسناد مهمة إلى وكيل آخر؟

المدة والإلغاء

متى تنتهي الصلاحية، وكيف تُسحب؟

نظام التسجيل

ما الأفعال التي تنتج إيصالات؟

الإيقاف الطارئ

كيف تتوقف السلسلة كلها؟

ثمانية عشر سؤالًا لتدقيق الصلاحية

قبل أن يتصرف الوكيل، يمكن طرح الأسئلة الآتية:

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

ليس من الضروري عرض هذه الأسئلة كلها في كل عملية صغيرة. لكن يجب أن يتضمن تصميم النظام إجاباتها.

مستويات الجاهزية للصلاحية

يمكن تلخيص مقترح هذا الفصل في خمسة مستويات للجاهزية:

1. صلاحية ضمنية

يستنتج الوكيل ما يجوز له فعله من مهمة واسعة مكتوبة باللغة الطبيعية.

2. صلاحية موثقة

الأذونات مكتوبة، لكن النظام لا يطبقها تلقائيًا.

3. صلاحية منظَّمة

الغرض والسلوك والبيانات والميزانية والمدة محددة بصيغة قابلة للقراءة الآلية.

4. صلاحية يُنفّذ النظام حدودها

يمنع النظام تقنيًا الفعل الخارج عن الصلاحية، أو يحيله إلى موافقة بشرية.

5. صلاحية قابلة للتدقيق والإلغاء

كل فعل مسجّل؛ وسلسلة الصلاحية ظاهرة، وحدودها قابلة للتحديث، ويمكن إيقاف شبكة الوكلاء كلها. المستوى الخامس هو هدف GBO.

الصلاحية المستوفية للشروط

لكي تُعد الصلاحية:

صلاحية مستوفية للشروط

يجب أن تحقق ما يأتي:

• منحها شخص مخوّل أو مؤسسة مخوّلة.
• غرضها واضح ومشروع.
• السلوكيات المسموح بها محددة.
• النطاق والبيانات والجهات المستهدفة والمدة محدودة.
• تحقق الرضا اللازم.
• حدود الموافقة البشرية محددة.
• قواعد التفويض واضحة.
• يمكن إلغاء الصلاحية.
• يمكن تدقيق الأفعال.
• يستطيع النظام التقني إنفاذ الحدود.

لا تعني الصلاحية المستوفية للشروط أن نقول للوكيل: «افعل كل ما يلزم».

بل: «لهذا الغرض، وضمن هذه الحدود، يجوز لك تنفيذ الأفعال الآتية».

هذا هو نطاق التخويل.

خلاصة الفصل

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

لذلك يسأل GBO قبل كل سلوك مهم:

من أذن بهذا الفعل؟

ولا يكتفي باسم واحد.

بل يسأل أيضًا:

هل كان هذا الشخص مخوّلًا بمنح الصلاحية؟ ما السلوك الذي أذن به؟ لأي غرض؟ ولأي مدة؟ وباستخدام أي بيانات؟ وحتى أي مبلغ؟ وعلى أي قناة؟ وبأي موافقة بشرية؟ هل كان يجوز تفويض الصلاحية إلى وكيل آخر؟ هل يستطيع الإنسان سحب هذه الصلاحية؟

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

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

لذلك يكون السؤال الأخير في عقد السلوك:

ماذا يحدث إذا ساءت الأمور؟

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

الصلاحية تبدأ الفعل. أما المسؤولية فتستمر بعده.