المؤسسة الجاهزة للوكلاء

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

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

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

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

فالاستعداد للوكلاء لا يعني مجرد:

• الوصول إلى نموذج،
• أو إضافة نافذة محادثة إلى الموقع،
• أو ربط حساب بريد إلكتروني،
• أو تقديم بضعة مفاتيح API،
• أو كتابة «AI-first».

بل يعني أن ترتب المؤسسة حقائقها وصلاحياتها وحدودها وطريقة تصرفها بعد الخطأ، بحيث تستطيع الآلات الاستفادة منها بأمان.

لذلك، فإن أول سؤال في الجزء الثالث هو:

كيف تصبح المؤسسة جاهزة للوكلاء؟

ماذا يعني الاستعداد للوكلاء؟

المؤسسة الجاهزة للوكلاء ليست مجرد مؤسسة تستطيع أنظمة الذكاء الاصطناعي العثور على معلومات عنها.

المؤسسة الجاهزة للوكلاء:

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

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

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

نشر واجهة API لا يكفي

غالبًا ما يتصرف الوكلاء عبر الأدوات: ينشئون مواعيد في التقويم، ويرسلون البريد، ويعدّلون الملفات، ويقدّمون طلبات شراء، وينشئون سجلات للعملاء.

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

لكن لا يجوز له تحويل الخصم الخاص الذي منحه مدير المبيعات إلى قاعدة عامة.

تجيب واجهة API عن سؤال: «كيف تُنفَّذ هذه العملية تقنيًا؟»

أما GBO فيطرح أسئلة أخرى أيضًا:

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

لذلك يقوم أساس المؤسسة الجاهزة للوكلاء على عقد السلوك، لا على الاتصال التقني.

على المؤسسة أن تعرف حقائقها

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

على المؤسسة أن تنظر أولًا إلى داخلها.

تحتاج الأسئلة التالية إلى إجابات واضحة:

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

إذا غابت الإجابات، فلن يؤدي ربط الوكيل إلى تسريع عمل المؤسسة، بل إلى أتمتة الغموض القائم.

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

الركائز الست للمؤسسة الجاهزة للوكلاء

أتناول في هذا الكتاب الاستعداد المؤسسي من خلال ست ركائز:

1. ركيزة الحقائق

2. ركيزة الهوية

3. ركيزة القدرة والملاءمة

4. ركيزة الصلاحية

5. ركيزة الفعل والدليل

6. ركيزة التعافي

قد تظل بعض العمليات المحدودة ممكنة مع غياب إحدى الركائز. لكن لا يجوز افتراض موثوقية الأفعال التي تتأثر بهذا النقص.

1. ركيزة الحقائق

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

تجيب ركيزة الحقائق عن الأسئلة التالية:

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

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

ماذا يعني وجود مصدر واحد معتمد للحقيقة؟

لا يعني «المصدر الواحد المعتمد» وضع المعلومات كلها في ملف واحد. المهم هو معرفة المصدر الأساسي المخوّل لكل نوع من المعلومات.

قد يكون هذا المصدر مثلًا:

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

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

المصدر الواحد المعتمد ليس ملفًا واحدًا، بل مرجعًا واحدًا مخوّلًا لكل حقيقة.

كل معلومة تحتاج إلى مسؤول

قد تكون المعلومة موجودة في النظام، من دون أن يُعرف من يتولى تحديثها. من يغيّر السعر؟

ومن يعتمد نطاق الخدمة؟

ومن يحدّث مواعيد العمل؟

ومن يسحب صلاحيات الوكلاء؟

ومن يقرر تقديم الخدمة في بلد معين من عدمه؟

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

يتولى المسؤول عن المعلومة ما يلي:

• التحقق من صحتها.
• الموافقة على تعديلها.
• تحديد الفترة التي تظل فيها المعلومة معبّرة عن الواقع.
• حل التناقضات.
• إلغاء السجل السابق.

وعند الشك، يجب أن يعرف الوكيل الشخص أو الجهة التي يرجع إليها.

التاريخ الذي تسري فيه الحقائق

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

لذلك ينبغي أن تتضمن سجلات الحقائق:

• تاريخ الإنشاء
• تاريخ آخر تحقق
• بداية السريان
• نهاية السريان
• الإصدار
• المسؤول
• الحالة

ومن أمثلة الحالة:

• مسودة
• بانتظار الموافقة
• نشط
• محدود
• منتهي الصلاحية
• ملغى
• مؤرشف

لا يجوز للوكيل أن يعدّ السجل محدثًا لمجرد أنه موجود.

الوجود لا يعني الصلاحية.

2. ركيزة الهوية

تربط ركيزة الهوية المؤسسة بأفرادها وعلاماتها ووكلائها وقنواتها الرسمية.

قد تختلف العناصر التالية في المؤسسة بعضها عن بعض:

• اسم العلامة
• الاسم القانوني
• اسم النطاق
• الحسابات الاجتماعية
• عناوين البريد الرسمية
• الممثلون المخوّلون
• هويات الوكلاء
• أسماء المنتجات

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

تتضمن ركيزة الهوية، في الحد الأدنى:

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

سجل حصر الوكلاء

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

لكن قد تبقى أسئلة بلا إجابة على مستوى المؤسسة:

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

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

agent_id

public_name

technical_identity

operator

human_owner

purpose

connected_systems

accessible_data

allowed_actions

prohibited_actions

approval_thresholds

subagents

valid_from

valid_until

shutdown_method

last_reviewed

status

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

الوكلاء خارج الإطار الرسمي

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

يمكن أن نسمي ذلك تشغيل الوكلاء خارج الإطار الرسمي. هؤلاء الوكلاء ليسوا دائمًا نتاج سوء نية؛ فكثيرًا ما يريد الموظف إنجاز العمل بسرعة أكبر.

لكن المؤسسة لا تعرف:

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

غالبًا لا يكفي حظر هؤلاء الوكلاء وحده. على المؤسسة أن تفهم حاجة الناس إلى هذه الأدوات، وأن توفر لهم مسارات رسمية آمنة.

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

كيف يعرّف الوكيل بنفسه؟

عندما يتواصل الوكيل مع الناس، ينبغي ألا يخفي هويته تمامًا. وليس عليه أن يبدأ كل جملة بعبارة «أنا ذكاء اصطناعي».

لكن يجب أن يستطيع المستخدم فهم الآتي:

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

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

3. ركيزة القدرة والملاءمة

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

ينبغي شرح ما يلي لكل خدمة:

• النتيجة الفعلية
• المدخلات
• النطاق
• الاستثناءات
• السعر أو طريقة التسعير
• الطاقة المتاحة
• العميل المناسب
• الحالات غير المناسبة
• الدليل
• التصرف عند الإخفاق

لا بد من بيان هذه الجوانب كلها.

ويمكن تنظيمها في سجل القدرة والملاءمة.

اسم الخدمة وحده لا يكفي

قد يكون «أتمتة الذكاء الاصطناعي» اسم خدمة.

لكن الوكيل لا يعرف بذلك إجابات الأسئلة التالية:

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

المؤسسة الجاهزة للوكلاء تحول اسم الخدمة إلى عقد سلوك.

السجل المرجعي للخدمة

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

service_id

service_name

provider_identity

outcome

target_users

supported_use_cases

unsupported_use_cases

required_inputs

deliverables

scope_included

scope_excluded

pricing_model

starting_price

third_party_costs

supported_languages

supported_regions

capacity_status

estimated_start

evidence

quality_criteria

human_approval

failure_behavior

version

validity

هذا السجل ليس للآلات وحدها. تستخدم فرق المبيعات والموقع والعروض والعقود والعمليات المصدر نفسه. وبهذا تستند الواجهات المختلفة للمؤسسة إلى الحقائق التجارية ذاتها.

تحديد العميل غير المناسب بوضوح

ينبغي أن يوضح السجل أيضًا لمن لا تصلح الخدمة.

ومن الأمثلة:

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

هذه الاستثناءات ليست مواقف أخلاقية فحسب، بل حدود للاختيار تقلل احتمال أن يبدأ الوكيل التعامل مع عميل غير مناسب.

حالة الطاقة المتاحة

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

لذلك قد يلزم سجل منفصل:

service_id

availability_status

accepting_new_work

earliest_start

capacity_band

last_updated

expires_at

لا يجوز للوكيل تقديم وعد ملزم بناءً على سجل قديم للطاقة المتاحة.

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

4. ركيزة الصلاحية

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

تتكون ركيزة الصلاحية من:

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

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

قد تقول مؤسسة: «يستطيع وكيل المبيعات الوصول إلى عمليات المبيعات». هذا نطاق واسع جدًا.

فقد تشمل عمليات المبيعات:

• البحث عن العملاء المحتملين.
• إعداد قائمة مختصرة.
• صياغة مسودة الرسالة الأولى.
• إرسال رسالة.
• ترتيب لقاء.
• توضيح السعر.
• منح خصم.
• إرسال عرض.
• قبول عقد.

ليست هذه صلاحية واحدة. ينبغي فصل الصلاحيات بحسب نوع السلوك.

مصفوفة الصلاحيات

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

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

نقاط الإحالة إلى الإنسان

ينبغي تحديد المواضع التي يتدخل فيها الإنسان في كل عملية.

يمكن أن نسمي كل موضع منها نقطة الإحالة إلى الإنسان.

ومن الأمثلة:

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

لا ينبغي ترك نقطة الإحالة إلى الإنسان مبهمة بعبارة مثل «اسأل إن وُجد خطر». يجب تحديدها بأكبر قدر ممكن من الوضوح.

ما الذي تتضمنه الموافقة البشرية؟

عندما يطلب الوكيل الموافقة، لا يكفي أن يقول: «هل أتابع؟»

بل ينبغي أن يوضح:

• ماذا سيفعل؟
• وباسم من؟
• وما الهدف الذي يتجه إليه الفعل؟
• وبأي بيانات؟
• وبأي تكلفة؟
• وبأي التزام؟
• وهل يمكن التراجع عنه؟
• وما الذي لا يزال غير مؤكد؟

بهذا يستطيع الإنسان أن يتخذ قرارًا حقيقيًا.

مدد الصلاحية

لا ينبغي ترك صلاحيات الوكلاء مفتوحة المدة ومن دون مراجعة.

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

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

وعند انقضاء المدة، يجب إعادة تقييم الصلاحية.

5. ركيزة الفعل والدليل

حين ينفذ الوكيل فعلًا، ينبغي ألا يكتفي بإنتاج النتيجة، بل يسجل ما فعله، ولماذا، وبأي صلاحية.

تتضمن هذه الركيزة العناصر الأساسية التالية:

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

كتالوج الأفعال

على المؤسسة أن تحدد بوضوح الأفعال التي يمكن أن ينفذها الوكلاء.

على سبيل المثال:

• البحث عن عميل محتمل.
• إعداد مسودة بريد.
• إرسال رسالة.
• إعداد مقترح موعد.
• إرسال دعوة عبر التقويم.
• تقييم ملاءمة الخدمة.
• عرض معلومات السعر.
• إعداد مسودة عرض.
• تحديث محتوى الموقع.
• النشر على الموقع الفعلي.
• إرسال إشعار إلى محرك البحث.
• قياس الأداء.
• إعداد تقرير.

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

• المدخلات المطلوبة
• مستوى الصلاحية
• الموافقة البشرية
• مستوى المخاطر
• الناتج المتوقع
• دليل النجاح
• طريقة التراجع

متى يُعد الفعل مكتملًا؟

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

قد تتضمن شروط اكتمال نشر موقع ما يلي:

• نُقلت الملفات.
• تطابقت قيم التجزئة على الخادم البعيد.
• محتوى HTML على الموقع الفعلي صحيح.
• اجتازت روابط العنوان الأساسي (canonical) وروابط اللغات التحقق.
• تأكدت صحة العرض على الهاتف والحاسوب.
• لا توجد أخطاء حرجة.
• تتوافر حزمة للتراجع.

قد تحدد هذه الشروط معًا اكتمال النشر.

أما مشاركة مسودة عرض غير ملزم فقد تتطلب:

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

هذه شروط محتملة للاكتمال. وينبغي أن يشمل شرط الاكتمال نتيجة الفعل في الواقع، لا ما نفذه الوكيل تقنيًا فحسب.

إيصال الفعل

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

action_id

action_type

requested_by

performed_by

target

purpose

authorization

inputs_used

data_shared

started_at

completed_at

technical_result

real_world_verification

human_approval

rollback_status

open_uncertainties

يمكن تقديم الإيصال للمستخدم بصيغة مبسطة، وللمدقق بصيغة أكثر تفصيلًا.

مراتب الأدلة

ليست الأدلة التي تسند ادعاءات النجاح متساوية القوة.

لنأخذ نشر موقع مثالًا:

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

هذه الملاحظات التسع لا تثبت الشيء نفسه، ولا يلزم أن تحدث دائمًا بهذا الترتيب. على الوكيل أن يبين بوضوح مستوى الدليل الذي وصل إليه.

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

يجب أن تحافظ لغة عرض الأدلة على هذه الفروق.

مبدأ التحقق المستقل

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

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

للتحقق المستقل تكلفة، لكنه يقلل الإخفاقات التي تمر دون أن تُلاحظ.

6. ركيزة التعافي

لا تخطط المؤسسة الجاهزة للوكلاء للسلوك الناجح وحده.

بل تحسم مسبقًا ما يلي في حال وقوع خطأ:

• من يوقف العملية.
• وأي الأنظمة تُغلَق.
• وما آخر حالة آمنة.
• وأي البيانات تُحفَظ.
• ومن يُبلَّغ.
• وكيف يُستقبَل الاعتراض.
• وكيف يُجبَر الضرر.

تُحسم هذه المسائل قبل وقوع الحادثة.

تشمل ركيزة التعافي:

• تصنيف الحادثة
• الحالة الآمنة
• الإيقاف الطارئ
• نقاط التحقق
• النسخ الاحتياطي والتراجع التقني
• سجل الحادثة
• المسؤول البشري
• الإبلاغ
• الاعتراض
• جبر الضرر
• السبب الجذري
• تحديث العقد

إيقاف الوكيل يختلف عن إيقاف النظام

يمكن إيقاف الوكيل المركزي.

ومع ذلك قد يستمر عمل:

• الوكلاء الفرعيين.
• والمهام المجدولة.
• وطوابير البريد.
• والأتمتة الخارجية.
• والاشتراكات.
• وعمليات الملفات.

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

إسكات الوكيل لا يعني إيقاف الأفعال التي أطلقها.

آخر حالة آمنة

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

سجل عقود السلوك

ينبغي إدارة العقود الخمسة التي بنيناها من الفصل الرابع إلى الثامن معًا داخل المؤسسة.

يمكن أن نسمي هذا التنظيم سجل عقود السلوك.

يجمع السجل ما يلي:

• عقد الهوية
• عقد القدرة
• عقد الملاءمة
• عقد الصلاحية
• عقد التعافي وجبر الضرر

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

عقد السلوك ليس ثابتًا

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

مع كل تغيير، يجب أن نعرف:

• من أجراه؟
• ولماذا؟
• وأي السجلات تأثرت؟
• وأي الاختبارات شُغّلت؟
• وأي إصدار أصبح نشطًا؟
• وكيف أُرشف الإصدار السابق؟

يجب أن تتوافر هذه الإجابات لكل تغيير.

ينبغي أن يتطابق العقد مع السلوك الفعلي

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

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

لهذا يجب المقارنة بين مستويين:

الصلاحية المعلنة

ما تنص عليه السياسة.

الصلاحية المتاحة للتنفيذ

ما يسمح به النظام التقني فعلًا.

يمكن أن نسمي الفارق فجوة إنفاذ الصلاحية. في المؤسسة الجاهزة للوكلاء، تضيق هذه الفجوة قدر الإمكان.

إنفاذ القاعدة تقنيًا

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

على سبيل المثال:

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

التعليمات مهمة، لكن الضبط التقني أكثر أمانًا في الحالات عالية المخاطر.

قول الوكيل «ينبغي ألا أفعل» لا يوفر مستوى الأمان نفسه الذي يوفره قول النظام «لا تستطيع».

ينبغي إدارة الأفعال لا أسماء الأدوات

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

النهج الأرسخ هو أن تسأل:

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

قد تتغير الأداة، ويبقى المبدأ الذي يحكم السلوك.

تصميم العمل بين الإنسان والوكيل

لا تقسم المؤسسة الجاهزة للوكلاء العمل ببساطة إلى «عمل بشري» و«عمل للذكاء الاصطناعي». بل توزع المهام داخل العملية بحسب نوع السلوك.

على سبيل المثال:

مجالات يبرع فيها الوكيل

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

مجالات يبقى فيها الإنسان محور القرار

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

هذا التقسيم ليس قطعيًا، لكنه مفيد في تصميم العمل.

دور الإنسان ليس الموافقة فقط

من الخطأ اختزال الإنسان في زر «نعم».

فالإنسان يحدد:

• لماذا اختير هذا الهدف.
• ومن سيتأثر به.
• وأي مفاضلة يمكن قبولها.
• وما الذي تريد المؤسسة أن تمثله.
• وأي خطر يمكن تحمله.

ولا ينبغي أن ينشئ الوكيل هذا السياق كله من تلقاء نفسه.

ودور الوكيل ليس السرعة فقط

لا يقتصر ما يقدمه الوكيل للمؤسسة على تسريع العمليات.

عند استخدامه على نحو صحيح، يمكن أن يحقق:

• الاتساق.
• قابلية التتبع.
• التدقيق المستمر.
• اتساق الحقائق بين اللغات.
• جودة قابلة للتكرار.
• اكتشاف الأخطاء مبكرًا.

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

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

بيانات جاهزة للوكلاء

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

ينبغي أن تكون البيانات الجاهزة للوكلاء:

• صحيحة.
• محدثة.
• محددة المصدر.
• مصنفة.
• خاضعة لضوابط الوصول.
• مقيدة بالغرض.
• قابلة للحذف عند الحاجة.
• قابلة لتسجيل استخدامها.

لا بد من مراعاة هذه المتطلبات جميعًا.

فئات البيانات

يمكن للمؤسسة وسم البيانات بالفئات التالية. وهي ليست فئات متنافية، ولا تحل محل التصنيفات القانونية؛ فقد تنتمي البيانات نفسها إلى أكثر من فئة.

• عامة
• داخلية
• سرية
• شخصية
• حساسة
• مقيدة قانونيًا
• محظورة على الوكلاء

لا ينبغي أن يملك الوكيل الصلاحية نفسها تجاه كل فئات البيانات.

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

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

البيانات الأكثر لا تعني دائمًا سلوكًا أفضل؛ فقد توسع أيضًا نطاق الضرر المحتمل.

منشأ البيانات

على الوكيل أن يعرف من أين جاءت المعلومات التي يستخدمها.

• إدخال بشري
• سجل الشركة المرجعي
• مصدر خارجي
• استنتاج النموذج
• محادثة سابقة
• تقدير
• قياس

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

سياسة التعامل مع عدم اليقين

تحدد المؤسسة الجاهزة للوكلاء كيف يتصرف النظام عند نقص المعلومات.

هل على الوكيل أن:

• يخمّن؟
• أم يسأل؟
• أم يعدّ مسودة؟
• أم يطلب موافقة بشرية؟
• أم يوقف المهمة؟

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

ميزانية عدم اليقين

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

يمكن أن نسمي ذلك ميزانية عدم اليقين.

على سبيل المثال:

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

يجب أن يعرف الوكيل أي أوجه عدم اليقين يمكن قبولها.

إدارة التغيير

عندما تتغير الحقائق التي يعتمد عليها الوكلاء، يجب تحديث النظام.

إذا تغير سعر، ينبغي مراجعة العناصر التالية معًا:

• صفحة الموقع
• كتالوج الخدمات
• الأسئلة الشائعة
• البيانات المنظمة Schema
• نموذج العرض
• معلومات وكيل المبيعات

يجب النظر إلى هذه المواضع مجتمعة.

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

تغيير صغير وأثر كبير في السلوك

قد يتغير اسم خدمة، فيبدو الأمر تعديلًا تحريريًا بسيطًا.

لكنه قد يؤثر في:

• المطابقة التي يجريها الوكيل.
• نية البحث.
• كتالوج الأسعار.
• الروابط الداخلية.
• مجموعة القياس.
• توقعات المستخدم.

لذلك لا تقيّم المؤسسة الجاهزة للوكلاء التغيير على مستوى الملفات وحده، بل على مستوى نتائجه السلوكية.

إدارة الإصدارات

ينبغي أن يكون لكل سجل مهم للهوية والقدرة والملاءمة والصلاحية إصدار محدد. وفق أي إصدار نفذ الوكيل الفعل؟

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

لا يمكن إثبات الجاهزية من دون قياس

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

من السيناريوهات التوضيحية:

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

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

الاختبارات السلبية

ينبغي أن تختبر المؤسسة الجاهزة للوكلاء أسئلة مثل:

ماذا يحدث إذا ترك المستخدم نطاق المهمة غامضًا؟

وأي سجل يختار الوكيل إذا كان السعر القديم أكثر بروزًا؟

وماذا لو أصدر موظف غير مخوّل أمرًا بالدفع؟

أو طلب وكيل فرعي وصولًا أوسع؟

أو انتهت صلاحية سجل الرضا؟

أو تشابه اسما خدمتين؟

أو قدم مصدر خارجي معلومات تناقض المصدر المرجعي؟

أو تعطّل مسار التراجع؟

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

دَين الاستعداد للوكلاء

قد تبدأ المؤسسة استخدام الوكلاء بسرعة.

لكن قد تكون:

• سجلات الهوية مبعثرة،
• والقدرات غامضة،
• والصلاحيات واسعة،
• وسجلات العمليات ناقصة،
• ومسارات التراجع غير مختبرة.

تتقدم التقنية وتتأخر الحوكمة.

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

علامات دَين الاستعداد للوكلاء

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

إضافة مزيد من الوكلاء إلى مؤسسة غير جاهزة

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

المزيد من الوكلاء ليس علاجًا لغياب الحوكمة.

أحيانًا تكون الخطوة الأصح تبسيط منظومة السلوك الحالية، لا إضافة وكيل آخر.

العبرة بتماسك السلوك لا بعدد الوكلاء

قد تكون مؤسسة صغيرة تستخدم عشرة وكلاء أكثر استعدادًا من مؤسسة كبيرة تستخدم مئة.

فالمهم:

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

المستويات الخمسة للمؤسسة الجاهزة للوكلاء

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

المستوى 1 — متصلة

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

المستوى 2 — محددة

أدوار الوكلاء والخدمات ومسارات العمل الأساسية موثقة. الهويات والمهام أوضح.

المستوى 3 — محكومة بعقود

تتوافر عقود محددة الإصدارات للهوية والقدرة والملاءمة والصلاحية والتعافي.

المستوى 4 — الضوابط مطبَّقة

تفرض الأنظمة التقنية حدود الصلاحية. وتعمل عتبات الموافقة البشرية وضوابط البيانات وإيصالات الأفعال فعليًا.

المستوى 5 — قابلة للتدقيق والتعلم

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

أوهام الاستعداد للوكلاء

«موقعنا ممتاز، إذن نحن جاهزون».

قد يحسّن الموقع الجيد تمثيل الهوية والقدرات، لكنه لا ينشئ وحده نظام الصلاحيات والأفعال والتعافي.

«كل معلوماتنا على السحابة».

إمكانية الوصول إلى المعلومة لا تعني أنها صحيحة أو محدثة أو معتمدة.

«النموذج قوي جدًا».

قوة النموذج لا تعالج نقص العقود المؤسسية.

«الإنسان يراقب بالفعل».

ماذا يراقب، ومتى، وبأي معلومات؟

إن بقي ذلك غامضًا، فقد تكون الموافقة مجرد إجراء شكلي.

«سنغلقه إذا أخطأ».

كيف؟

وهل سيتوقف الوكلاء الفرعيون والمهام المجدولة والأنظمة الخارجية أيضًا؟

«الوكيل لا يقدم سوى توصيات».

قد تتحول التوصية في سير عمل آلي إلى مدخل للاختيار أو التنفيذ.

واجهة عملاء جاهزة للوكلاء

يمكن أن تكون الواجهة التي تقدمها المؤسسة لعملائها الخارجيين جاهزة للوكلاء أيضًا.

ينبغي أن يستطيع العميل أو وكيله الوصول بثقة إلى المعلومات التالية:

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

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

الاستعداد للوكلاء ليس تلاعبًا

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

الاستعداد للوكلاء يعني:

• إيضاح الحقائق.
• وإظهار الحدود.
• وتسهيل الاختيار المناسب.
• وتصعيب الاختيار الخاطئ.

ذلك هو المقصود بالاستعداد.

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

مثال مؤسسي: من التشتت إلى الاستعداد للوكلاء

لنتصور شركة خدمات رقمية افتراضية. يوضح الانتقال التالي مثالًا للتطبيق، وليس نتيجة مقاسة لدى عميل.

وضعها الأولي:

• أكثر من 40 خدمة.
• عدة لغات.
• صيغ مختلفة للتسعير.
• صفحات قديمة وأخرى جديدة.
• عدة وكلاء.
• أتمتة للبريد والموقع والشبكات الاجتماعية والبحث عن العملاء.
• سجلات صلاحيات متفرقة.

إذا اكتفت الشركة بإضافة وكيل جديد، ازداد الخطر.

يمكن إجراء التحول بالترتيب التالي:

1. حصر الخدمات

تُحصر الخدمات والأسعار والنطاقات الفعلية.

2. السجل المرجعي

يُنشأ سجل رئيسي معتمد لكل خدمة يحدد نطاقها وطريقة تسعيرها.

3. الاتساق متعدد اللغات

تُكتب كل لغة بأسلوب طبيعي، وتحمل الحقائق نفسها.

4. فصل أدوار الوكلاء

تُفصل أدوار وكلاء الموقع والبريد والشبكات الاجتماعية وSEO/GEO واكتشاف العملاء.

5. حدود الصلاحية

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

6. بوابات الجودة

تُنشأ اختبارات البناء والدلالة والمتصفح الحقيقي وقيم التجزئة للموقع الفعلي والأداء.

7. سجل القياس

يُسجل التغيير الذي نُشر وتاريخ نشره، وما سيجري قياسه.

8. الاستقرار

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

مسار عملي للأيام التسعين الأولى

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

الأيام 1–30 — اجمع الحقائق ونظمها

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

الأيام 31–60 — اضبط السلوك بالعقود

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

الأيام 61–90 — اختبر وافرض الحدود

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

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

عقد المؤسسة الجاهزة للوكلاء NOMOS

المخرج المركزي لهذا الفصل هو عقد المؤسسة الجاهزة للوكلاء NOMOS.

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

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

بعبارة أبسط: لا يكتفي هذا العقد بفتح أبواب المؤسسة للوكلاء، بل يجعلها تعرف أي باب يُفتح، ومتى، وبأي صلاحية.

بوابة المؤسسة الجاهزة للوكلاء

قبل أن تسمح المؤسسة للوكلاء بأفعال ذات أثر كبير، ينبغي أن تجتاز البوابات التالية:

1. بوابة الحقائق

هل المعلومات المرجعية والمسؤولون عنها وإصداراتها معروفة؟

2. بوابة الهوية

هل رُبطت العلامة والكيان القانوني وهويات البشر والوكلاء ربطًا صحيحًا؟

3. بوابة القدرة

هل الخدمات الفعلية والمدخلات والنطاق والأدلة واضحة؟

4. بوابة الملاءمة

هل حُدد الطرف المناسب والظروف التي تجعل الاختيار ملائمًا؟

5. بوابة الصلاحية

هل حُددت حدود سلوك البشر والوكلاء بصورة قابلة للإنفاذ؟

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

أي بيانات يجوز للوكيل استخدامها، ولأي غرض؟

7. بوابة الفعل

هل مسارات العمليات وشروط الاكتمال والإيصالات محددة؟

8. بوابة التحقق

هل يُفحَص الوكيل بصورة مستقلة عن ادعائه النجاح؟

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

هل تعمل آليات الإيقاف والتراجع والاعتراض وجبر الضرر؟

10. بوابة المسؤولية البشرية

هل لكل فعل حرج مسؤول بشري حقيقي؟

توضح الصيغة المفاهيمية التالية ضرورة النظر إلى هذه الشروط معًا؛ وليست حسابًا عدديًا للسلامة:

المؤسسة الجاهزة للوكلاء =

حقائق مرجعية

و هوية صحيحة

وقدرة واضحة

و ملاءمة متحقق منها

وصلاحية تُفرَض حدودها

وبيانات محدودة

وفعل مسجل

و تحقق مستقل

و تعافٍ خضع للاختبار

و مسؤولية بشرية

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

فيمكن، مثلًا، قصر العمل على:

• البحث فقط.
• التوصية فقط.
• المسودة فقط.
• بيئة الاختبار.
• التنفيذ بموافقة بشرية.

هذه حدود ممكنة لطريقة العمل.

الاستعداد للوكلاء مستوى صلاحية، لا درجة تقييم

قد تقول مؤسسة إنها جاهزة بنسبة 80%.

لكن إن كانت نسبة 20% الناقصة تخص مجالات حرجة، مثل:

• صلاحية الدفع،
• والرضا بمعالجة البيانات البيومترية،
• واستعادة البيانات،
• والهوية القانونية،

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

لا تولّد الدرجة الإجمالية حقًا في الفعل ما لم تُجتَز البوابة الحرجة.

متى تستطيع المؤسسة منح الوكيل استقلالًا أكبر؟

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

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

كلما ترسخت هذه الشروط، قلّت الحاجة إلى موافقة الإنسان على كل خطوة صغيرة.

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

القيمة التجارية للمؤسسة الجاهزة للوكلاء

لا يقتصر هذا التحول على السلامة.

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

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

الاستعداد للوكلاء ليس تأهبًا لتقنية المستقبل فحسب، بل تقليلًا للتشتت المؤسسي القائم اليوم.

المؤسسة غير الجاهزة للبشر ليست جاهزة للوكلاء

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

الوضوح للآلة لا يحل محل الوضوح للإنسان، بل يتطلبه.

خمسة وعشرون سؤال تدقيق للمؤسسة الجاهزة للوكلاء

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

إذا لم تتمكن المؤسسة من الإجابة عن معظم هذه الأسئلة، فدَين الاستعداد للوكلاء لديها مرتفع.

حكم هذا الفصل

الاستعداد للوكلاء ليس ربط نظام ذكاء اصطناعي بالشركة.

إنه يعني:

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

إذا منحت المؤسسة وكلاء أقوياء صلاحيات واسعة من دون هذا العمل، فقد تسرّع الفوضى القائمة.

من دون تنظيم مؤسسي صحيح، قد يستطيع الوكيل:

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

قوة الوكيل وحدها ليست نضجًا.

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

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

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

لكن مهما أحسنت المؤسسة الاستعداد، يبقى السؤال التالي مفتوحًا:

كيف نقيس ما إذا كان هذا النظام يتصرف فعلًا على النحو الصحيح؟

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

كيف نقيس الفعل المستوفي للشروط؟

لأن السلوك الجيد:

• ليس مجرد فعل،
• ولا مجرد نجاح،
• ولا مجرد رضا المستخدم.

السلوك الجيد يجمع الاختيار الصحيح في الظروف الصحيحة، والصلاحية السارية، والدليل الكافي، والتنفيذ الآمن، والتعافي المسؤول.

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