ماذا يحدث إذا وقع خطأ؟

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

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

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

فقد أُدرج السعر في:

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

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

هل تُعدّ المشكلة محلولة بالكامل إذا أُعيدت الملفات القديمة؟

ماذا لو زحفت محركات البحث إلى السعر الخاطئ؟

أو قرأه نظام ذكاء اصطناعي؟

أو التقط العميل صورة للشاشة؟

أو تكوّنت توقعات في لقاء المبيعات بناءً على هذا السعر؟

هل سيقتصر التراجع عن المعلومة الخاطئة المنشورة في ست لغات على الجانب التقني، أم سيُقدَّم تفسير للناس أيضًا؟

والسؤال الأهم: لماذا اجتاز هذا الخطأ بوابات النشر؟

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

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

ماذا يحدث إذا وقع خطأ؟

إدراج احتمال الخطأ في التصميم

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

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

الخطأ ليس هو الضرر

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

لذلك يجب الفصل بين مفهومين:

الخطأ

هو انحراف النظام عن المعلومة أو القرار أو العملية أو النتيجة المتوقعة.

الضرر

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

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

ليس الإخفاق على صورة واحدة

عبارة «فشلت العملية» واسعة جدًا. فقد يخفق سلوك الوكيل بأشكال مختلفة.

عملية صحيحة بمعلومة خاطئة

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

عملية خاطئة بمعلومة صحيحة

يملك الوكيل البيانات الصحيحة، لكنه يغيّر الملف الخطأ، أو يراسل الشخص الخطأ، أو يستخدم الحساب الخطأ.

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

الفعل سليم تقنيًا، لكن الوكيل غير مخوّل بتنفيذه.

تنفيذ جزئي

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

تنفيذ مزدوج

يظن النظام أن العملية فشلت بسبب انتهاء مهلة الانتظار، فيعيد المحاولة. فيُحصَّل المبلغ من المستخدم مرتين أو تُرسَل الرسالة نفسها مرتين.

إخفاق صامت

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

إخفاق متأخر

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

إخفاق متسلسل

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

إخفاق على المستوى الإنساني

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

النجاح التقني لا يعني النجاح الفعلي

قد تنتج العملية إحدى النتائج التقنية التالية:

• HTTP 200
• نجحت عملية البناء
• رُفع الملف
• قُبل استدعاء API
• استلم خادم البريد الرسالة
• عالج مزوّد الدفع الطلب
• قَبِل IndexNow الإشعار

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

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

ادّعاء النجاح يحتاج إلى تدقيق أيضًا

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

قد يقول النظام: «اكتمل النشر». لكن ما اكتمل هو نقل الملفات فقط، ولم تُفحص بعد النسخة الحية التي تُقدَّم عبر HTTPS.

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

وقد يقول النموذج: «المستخدم راضٍ». وربما لم يفعل المستخدم سوى أنه لم يرد.

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

ما الذي ثبت؟ ما الذي لم يثبت بعد؟ أي نتيجة ليست سوى خطوة وسيطة؟ ما الغموض الذي لا يزال قائمًا؟

الوكيل الموثوق يصرّح بحدود نجاحه بوضوح.

أوقف أولًا، ثم اشرح

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

وإذا كانت نسخة برمجية تُفسد البيانات، فيجب توجيه حركة الاستخدام إلى نسخة آمنة.

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

التوقف الآمن

حين يكتشف الوكيل مشكلة، يجب ألا يترك النظام في حالة عشوائية.

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

الحالة الآمنة لوكيل بريد إلكتروني قد تعني:

إيقاف إرسال الرسائل الجديدة مع حفظ الرسائل الواردة دون فقدانها.

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

العودة إلى آخر نسخة تم التحقق منها، أو تعطيل الوظيفة المتأثرة وحدها مؤقتًا.

ولوكيل مشتريات:

عدم إجراء دفعات جديدة مع الاحتفاظ بسلال الشراء المفتوحة والمسودات.

ولنظام أفاتار:

إيقاف توليد المحتوى الجديد ونشره دون حذف سجلات الأدلة.

ولبوابة عملاء:

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

ماذا سيحدث حين يتوقف الوكيل؟

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

اختيار الجانب الآمن عند الإخفاق

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

مثلًا:

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

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

السرعة تحت الغموض ليست موثوقية.

ما معنى التراجع؟

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

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

التراجع التقني

هل يمكن استعادة حالة النظام السابقة؟

التراجع عن العملية

هل يمكن إلغاء الطلب أو الدفعة أو الحجز أو العقد أو النشر؟

التراجع على المستوى الإنساني

هل يمكن بالفعل معالجة الأثر في الخصوصية أو الثقة أو السمعة أو الفرصة أو الحقوق؟

غالبًا ما يكون المستوى الثالث هو الأصعب.

وهم التراجع الكامل

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

فقد تكون النسخة الاحتياطية:

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

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

يسأل GBO: أي جزء من الأثر الذي وقع تعكسه عملية التراجع حقًا؟

درجات تعذّر التراجع

يمكن استخدام الدرجات التوضيحية التالية لفحص صعوبة التراجع. ولا تُسنَد الدرجة تلقائيًا من اسم العملية؛ بل تُفحص حركة البيانات الفعلية والنسخ والآثار الخارجية.

1. قابل للتراجع بالكامل

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

2. سهل التراجع

تغيير صغير في النظام نُشر، لكنه لم يُحدث أثرًا خارجيًا.

3. قابل للتراجع جزئيًا

حجز أو طلب أو منشور مجدول يتاح إلغاؤه؛ لكن الإلغاء قد يترك خسارة في الوقت أو المال.

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

5. يصعب جبر ضرره

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

6. لا يمكن التراجع عنه

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

كلما ارتقى الفعل في هذه الدرجات، ازدادت الحاجة إلى:

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

وتشتد هذه المتطلبات كلما صعب التراجع.

كلما زاد تعذّر التراجع، وجب أن تزيد المسؤولية، لا الاستقلالية.

نقطة التراجع

في بعض العمليات، يظل التراجع سهلًا حتى لحظة معينة.

يمكن أن نسمّي هذه اللحظة نقطة التراجع.

في البريد الإلكتروني:

قبل الإرسال.

وفي الشراء:

قبل الموافقة على الدفع.

وفي نشر نسخة برمجية:

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

وفي منشور على وسائل التواصل:

قبل إتاحته للجمهور.

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

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

مهلة التراجع

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

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

نقاط التحقق

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

يمكن أن نسمّيها نقاط تحقق.

في مشروع ويب، قد تشمل نقطة التحقق:

• تثبيتًا للتغييرات commit تم التحقق من نطاقه،
• وسم إصدار،
• بيان ملفات النشر،
• نسخة احتياطية،
• سجلًا لقيمة التجزئة.

يمكن لهذه السجلات أن تثبّت حالة يُرجع إليها.

وفي معالجة البيانات، يمكن حفظ:

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

فتُوثَّق بذلك الحالة الوسيطة.

وفي محادثة الوكيل، يمكن تسجيل:

• المرشحين الذين جرى تقييمهم،
• الافتراضات التي استُخدمت،
• الصلاحية السارية.

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

حماية الصفحة الرئيسية

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

يمكن للنظام اتباع الخطوات التالية:

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

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

المهمة الضيقة يجب أن تنتج نطاق تأثير ضيقًا.

نطاق التأثير

من أول الأسئلة عند وقوع خطأ: إلى أي مدى امتد الأثر؟

يمكن أن نسمّي هذا نطاق التأثير.

قد يمسّ الخطأ:

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

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

مثلًا:

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

يمكن أن نسمّي ذلك تضييق نطاق التأثير. وهو يتناول السؤال نفسه الذي يطرحه مفهوم blast radius في أدبيات الأمن: إذا وقع خلل، فإلى أي مدى قد يمتد الضرر؟

النشر التدريجي

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

يتيح ذلك الفحص المبكر لأربعة مجالات:

• الأداء،
• الأخطاء،
• سلوك المستخدم،
• الأمن.

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

أمان إعادة المحاولة

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

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

يجب أن يعرف الوكيل الفرق بين «لم يصل رد» و«لم تحدث العملية».

كيف يُعالَج النجاح الجزئي؟

إذا نُشرت خمس لغات من أصل ست، فلا ينبغي أن يقول النظام: «اكتمل النشر».

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

يجب أن يبيّن تقرير النجاح الجزئي:

• الجزء المكتمل،
• الجزء غير المكتمل،
• الخطر القائم،
• حالة الإتاحة،
• الخطوة التالية المطلوبة،
• ما إذا كانت هناك حاجة إلى قرار بشري.

عرض النجاح الجزئي على أنه نجاح كامل يدفع الأنظمة اللاحقة إلى سلوك خاطئ.

الإخفاق الصامت

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

يجب ألا يكون إعلان النظام المنفّذ عن نجاحه هو الدليل الوحيد.

مثلًا:

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

التحقق المستقل

ينفّذ الوكيل فعلًا، وتتحقق طريقة أخرى من النتيجة.

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

إعلان نجاح غير صحيح

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

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

ما الحادثة؟

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

لكن ينبغي التعامل مع الحالة بوصفها حادثة إذا أثّرت في:

• البيانات،
• الهوية،
• المال،
• التواصل الخارجي،
• النظام الحي،
• التزام قانوني،
• حق إنساني.

فالأثر في هذه المجالات يستدعي التعامل معه كحادثة.

ويمكن تعريف النوع التالي من الحوادث:

حادثة في سلوك الوكيل

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

شدة الحادثة

الحوادث ليست متساوية. يمكن وضع تصنيف عملي لها.

منخفضة

خطأ صغير ومحلي وسهل التصحيح.

متوسطة

أثر محدود في المستخدم أو العملية، يستلزم تدخلًا بشريًا.

عالية

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

حرجة

تسريب واسع للبيانات، أو خسارة مالية كبيرة، أو ضرر قانوني أو جسدي لا يمكن التراجع عنه، أو إساءة استخدام الهوية، أو خروج سلوك الوكيل عن السيطرة.

كلما ارتفعت الشدة:

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

الدقائق الأولى للحادثة

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

1. اكتشف

ما الذي حدث فعلًا؟

2. أوقف

اقطع الفعل الجاري.

3. احتوِ

أي حساب أو مستخدم أو ملف أو نظام تأثر؟

امنع الانتشار.

4. احفظ الأدلة

لا تحذف السجلات أو النسخ أو الرسائل أو سجلات الصلاحية.

5. عُد إلى حالة آمنة

استخدم آخر نسخة متحقّق منها أو نمط تشغيل آمنًا.

6. أبلغ المسؤول البشري

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

حفظ الأدلة

عند وقوع الخطأ، يجب على النظام:

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

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

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

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

سجل الحادثة

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

incident_id

detected_at

detected_by

affected_systems

affected_people

agent_identity

authorization_version

action_receipts

initial_signal

actual_behavior

expected_behavior

impact

containment

rollback

notifications

recourse

compensation

root_cause

contract_change

closed_at

ليس ضروريًا أن تكون التفاصيل كلها علنية. لكن يجب أن يبقى أثر كافٍ للتدقيق الداخلي في الحادثة.

التصحيح وجبر الضرر ليسا شيئًا واحدًا

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

لذلك توجد مهمتان منفصلتان:

التصحيح

تحويل الحالة الخاطئة في النظام إلى حالة صحيحة.

جبر الضرر

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

إجراء جابر للضرر

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

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

الاعتذار وحده لا يجبر الضرر

قد يقول نظام أو مؤسسة: «نأسف للمشكلة التي حدثت». هذا مهم.

لكن جبر الضرر فعليًا يحتاج أيضًا إلى إجابات عن الأسئلة التالية:

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

الاعتذار لا يحل محل المسؤولية.

حق الاعتراض

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

ينبغي أن يستطيع نظام الاعتراض الفعّال:

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

قابلية الاعتراض

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

قد يقول التفسير: «رفضناك لهذا السبب».

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

سلوك قابل للاعتراض

يجب أن يكون السلوك قابلًا للاعتراض أيضًا. فالخطأ المفسَّر يظل خطأً، ويجب أن يتمكن الإنسان من التدخل في القرار.

كيف ينبغي أن يسير الاعتراض؟

مسار الاعتراض الفعّال يجب أن يكون:

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

إذا وُجد زر اعتراض بينما تُرفض جميع الطلبات تلقائيًا، فلا يوجد حق اعتراض حقيقي. المراجعة البشرية يجب ألا تكون مجرد تكرار لقرار الآلة.

من يحق له الاعتراض؟

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

حق السحب

يمكن للشخص سحب رضاه أو الصلاحية التي منحها سابقًا.

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

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

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

طريق إلى مسؤول بشري

عند حدوث مشكلة، ينبغي ألا يكتفي النظام باستمارة آلية. يجب وجود مسؤول بشري فعلي في الحوادث التي تتجاوز درجة محددة من الشدة.

يجب أن يعرف المستخدم:

بمن أتواصل؟ متى أتلقى ردًا؟ هل ستتوقف العملية خلال الانتظار؟ ما السجلات التي يجب تقديمها؟

لا يضع GBO الإنسان خارج النظام. بل يجعل دوره أشد وضوحًا وقت التعافي.

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

قد تتعدد الأطراف في سلسلة الفعل:

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

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

مثلًا:

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

يمكن توزيع المسؤولية، لكن لا يجوز أن تضيع.

«فعلها الذكاء الاصطناعي» ليس تفسيرًا كافيًا

لا تستطيع المؤسسة تبرير فعل خاطئ بقولها: «هذا ما فعله الذكاء الاصطناعي».

هذه العبارة لا تجيب عن الأسئلة التالية:

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

يجب ألا يكون الذكاء الاصطناعي ستارًا يخفي المسؤولية.

السبب الجذري

قد يختلف السبب الظاهر للحادثة عن سببها الفعلي. نُشر سعر خاطئ.

السبب الظاهر:

استخدم الوكيل الرقم على نحو خاطئ.

لكن الأسباب الجذرية قد تشمل:

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

لا يمكن اختزال تحليل السبب الجذري في سؤال: «لماذا فكّر النموذج بطريقة خاطئة؟». يجب فحص النظام بأكمله.

لماذا، خمس مرات؟

يمكن تكرار سؤال «لماذا؟» لتفكيك المشكلة. السلسلة التالية تفسير محتمل وليست إثباتًا للسبب الجذري. يجب اختبار كل رابط بالسجلات، والبحث عن أسباب أخرى أيضًا.

لماذا نُشر سعر خاطئ؟ لأن الوكيل خلط بين خدمتين.

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

لماذا لم تكن واضحة؟ لعدم وجود كتالوج مرجعي موحّد.

لماذا لم يوجد كتالوج؟ لأن الأسعار كانت محفوظة في النصوص المرئية وحدها.

لماذا لم تكتشف بوابة النشر ذلك؟ لأن الاختبار تحقّق من الصيغة لا من العلاقة التجارية.

لا تحمّل هذه السلسلة الوكيل وحده الخطأ، بل تُظهر فجوة في تصميم النظام.

أصلح العقد، لا الشخص وحده

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

يجب أن يغيّر التحسين الدائم واحدًا على الأقل مما يلي:

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

المراجعة الجيدة للحادثة لا تبحث عن مذنب، بل عن الفجوة في العقد التي سمحت بالسلوك الخاطئ.

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

الفرق بين التعلّم والعقاب

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

ينبغي أن تنشئ المؤسسة الموثوقة الثقافة التالية:

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

هذه ليست ثقافة انعدام مسؤولية، بل ثقافة تعلّم حقيقي.

واقعة كادت تقع

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

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

دَين التعافي

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

وبمرور الوقت، تتراكم:

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

ويزداد العبء مع هذا التراكم.

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

إذا زادت قدرة الفعل ولم تزد معها قدرة التعافي، فالنظام لا يزداد قوة، بل هشاشة.

دَين جبر الضرر

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

يمكن أن نسمّي هذا التراكم دَين جبر الضرر. وهو يتحول بمرور الوقت إلى فقدان للثقة.

قد تقول المؤسسة: «صُححت المشكلة».

وقد يقول المتأثر: «لكن لم يشرح لي أحد ما الذي حدث لي». يفرّق GBO بين الإغلاق التقني والإغلاق من منظور الإنسان.

عقد التعافي وجبر الضرر NOMOS

المكوّن الخامس والأخير المقترح لعقد السلوك هو عقد التعافي وجبر الضرر NOMOS.

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

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

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

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

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

action_type

failure_modes

detection_signals

safe_state

automatic_stop_conditions

containment_scope

checkpoint

rollback_method

rollback_window

irreversible_point

human_owner

notification_rules

affected_party_contact

appeal_channel

compensation_policy

evidence_retention

root_cause_review

contract_update

recovery_test_date

version

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

بوابة التعافي NOMOS

قبل بدء الفعل، يجب أن يفحص الوكيل مسار الإخفاق كما يفحص مسار النجاح.

1. بوابة الاكتشاف

كيف سيُعرف أن الفعل سار على نحو خاطئ؟

2. بوابة الإيقاف

كيف ستُوقَف العملية الجارية؟

3. بوابة الاحتواء

كيف سيُضيَّق نطاق التأثير؟

4. بوابة نقطة التحقق

هل توجد حالة متحقّق منها يمكن العودة إليها؟

5. بوابة التراجع

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

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

من يتحمل مسؤولية الحادثة من الأشخاص أو المؤسسات؟

7. بوابة الإبلاغ

من سيُبلَّغ، ومتى، وبأي معلومات؟

8. بوابة الاعتراض

كيف يستطيع المتأثر الاعتراض على القرار أو الفعل؟

9. بوابة جبر الضرر

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

10. بوابة التعلّم

أي عقد أو نظام سيتغير حتى لا يتكرر الخطأ نفسه؟

وبصورة مبسطة:

شروط التعافي المسؤول:

الاكتشاف

والإيقاف

والاحتواء

والعودة الآمنة

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

والإبلاغ

والاعتراض

وجبر الضرر

وتصحيح العقد

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

لماذا يجب أن تعمل بوابة التعافي قبل الفعل؟

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

لذلك يجب السؤال قبل الفعل عالي المخاطر: ماذا سيحدث إذا أخطأنا؟

إذا غابت الإجابة، وجب خفض مستوى الفعل.

الموافقة البشرية في الأفعال التي لا رجعة فيها

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

يجب أن يرى الإنسان:

• النتيجة،
• والخطر،
• والبديل،
• وحدود جبر الضرر.

يجب أن تكون هذه العناصر واضحة له قبل اتخاذ القرار.

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

مدة انتظار للأفعال عالية التأثير

قد تكون مهلة قصيرة مفيدة في بعض العمليات عالية التأثير:

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

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

مثال من نشر المواقع

يُعدّ الوكيل صفحة خدمة جديدة بست لغات.

يتضمن التصميم الجيد للتعافي:

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

إذا وُجدت مشكلة:

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

هذه ليست جودة تقنية فحسب، بل مسؤولية GBO بعد الفعل.

مثال من البريد الإلكتروني

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

قد يتضمن التعافي الصحيح:

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

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

مثال من الشراء

يشتري الوكيل المنتج الخطأ.

يشمل التعافي الأسئلة التالية:

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

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

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

يُنشر أفاتار مدير بنص لم يوافق عليه.

في هذه الحادثة، يجب:

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

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

مثال من التوظيف

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

قد يتطلب التعافي الصحيح:

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

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

مثال من شبكة وكلاء

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

بل يجب أيضًا:

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

اختبار التعافي

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

كم دقيقة تستغرق العودة إلى النسخة القديمة؟

هل البيانات المستعادة متسقة؟

هل توقف مفتاح API الملغى عن العمل فعلًا؟

هل يصل مسار الاعتراض إلى إنسان حقيقي؟

لذلك يجب أن تتدرب المؤسسات على التعافي على فترات محددة.

تمرين التعافي

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

أمثلة على التمارين

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

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

مستويات الاستعداد للتعافي

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

1. ردّ فعل

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

2. موثّق

توجد خطة للتراجع، لكنها لا تُختبر بانتظام.

3. قابل للتراجع تقنيًا

توجد نسخ احتياطية وإدارة إصدارات ونظام للتراجع.

4. جاهزية جبر الضرر الإنساني ومعالجة آثار العمليات

تكون مسارات الإبلاغ والاعتراض وجبر الضرر محددة أيضًا.

5. تعافٍ جاهز للوكلاء

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

عشرون سؤالًا لتدقيق التعافي

يمكن طرح الأسئلة التالية قبل أن يتصرف الوكيل أو أثناء تدقيق النظام:

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

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

التعافي المستوفي للشروط

للحكم على التعافي متطلبات محددة.

التعافي المستوفي للشروط

لا يستحق التعافي هذا الوصف إلا باجتماع الشروط التالية:

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

استعادة الملف القديم وحدها ليست تعافيًا مستوفيًا للشروط.

لا تُخفِ الإخفاق

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

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

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

يجب أن تتناسب لغة وصف الخطأ مع أثره الفعلي.

الشفافية لا تعني نشر كل شيء

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

التوازن الصحيح هو قدر كافٍ من الوضوح بشأن:

• ما حدث،
• والفترة المتأثرة،
• والبيانات أو العملية المتأثرة،
• وما اتُّخذ من إجراءات،
• وحقوق الشخص.

يحتاج المتأثر إلى معلومات كافية عن هذه الجوانب.

قيمة الإخفاق في GBO

ليست الحادثة مجرد قيد سلبي في السجل. إذا دُرست جيدًا، كشفت ما ينقص عقد النظام.

السعر الخاطئ:

قد يكشف فجوة في عقد القدرة والنطاق التجاري.

والرسالة غير المخوّلة:

قد تكشف فجوة في الصلاحية وحدود مستوى الفعل.

واختيار الشركة الخطأ:

قد يكشف فجوة في عقد الهوية أو الملاءمة.

والنشر الذي لا يمكن التراجع عنه:

قد يكشف فجوة في عقد التعافي. ليس الخطأ عدو النظام؛ عدوه هو الخطأ الذي يُخفى ولا يُتعلّم منه.

العقود الخمسة تعمل معًا

بنينا في الجزء الثاني خمسة عقود أساسية.

1. عقد الهوية

من أنت؟

2. عقد القدرة

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

3. عقد الملاءمة

في أي ظروف ينبغي اختيارك؟

4. عقد الصلاحية

أي فعل يجوز لك تنفيذه، وإلى أي حد؟

5. عقد التعافي وجبر الضرر

ماذا يحدث إذا وقع خطأ؟

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

النموذج الأساسي لعقد السلوك

بصورة مبسطة:

الشروط الأساسية لسلوك الوكيل الصحيح:

هوية صحيحة

و قدرة حقيقية

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

و صلاحية سارية

و تعافٍ مسؤول

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

لماذا يظل الإنسان في المركز؟

لأن الضرر لا يقع في حالة النظام وحدها.

بل يمسّ لدى الناس:

• المال،
• والوقت،
• والسمعة،
• والخصوصية،
• والفرص،
• والهوية،
• والثقة.

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

العبارة الصحيحة حين يقع خطأ

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

هذه العبارة أجدى بكثير من «حدث خطأ»، لأنها تُظهر المشكلة والسلوك والمسؤولية معًا.

حكم الفصل

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

النظام القوي:

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

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

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

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

في نهاية الجزء الثاني، أصبح لدينا كامل البنية الأساسية لعقد السلوك:

بلا هوية، لا يوجد طرف صحيح للتعامل معه. وبلا قدرة، لا يوجد وعد حقيقي. وبلا ملاءمة، لا يوجد اختيار صحيح. وبلا صلاحية، لا يوجد فعل مشروع. وبلا تعافٍ، لا توجد ثقة مستدامة.

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

وسيكون سؤالنا الأول:

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

فالجاهزية لا تعني نشر واجهة API أو وضع عبارة «AI-ready» على الموقع فحسب.

المؤسسة الجاهزة للوكلاء تكون قد:

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

بهذه الشروط تتحدد جاهزيتها.

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