معظم الوكلاء المؤسسية تبدو جيدة عندما يكون الطلب واضحًا، والبيانات مكتملة، والمسار معروفًا مسبقًا. لكن المؤسسة لا تمنح الثقة على أساس المسار الطبيعي وحده. الثقة تُبنى عندما يواجه الوكيل حالةً ملتبسة، أو تعارضًا في الصلاحيات، أو نقصًا في البيانات، أو تعطلًا في نظام تابع، ثم يبقى تصرفه مفهومًا وقابلًا للسيطرة.
لهذا فإن السؤال العملي قبل التوسع ليس: هل ينجح الوكيل عندما تسير الأمور كما ينبغي؟ بل: ماذا يحدث عندما لا تسير كما ينبغي، ومن يملك القرار عندها؟
هذا ليس مجرد رأي تشغيلي. فإطار NIST AI RMF 1.0 يطلب مراقبة ما بعد النشر مع آليات لالتقاط الملاحظات والاستئناف والتجاوز والاستجابة للحوادث والتعافي وإدارة التغيير. وفي Generative AI Profile الصادر عن NIST في يوليو 2024، تظهر أربع أولويات واضحة للذكاء التوليدي: الحوكمة، واختبار ما قبل النشر، وإفصاح الحوادث، وتتبّع المصدر. كما يوصي الدليل نفسه بتحديد بدائل fallback، وتسجيل الحوادث وتحليلها، وتوثيق حالات تجاوز البشر أو الأنظمة الأخرى لقرارات النظام. المعنى التشغيلي هنا واضح: المؤسسة لا تحتاج وكيلًا ينجح فقط؛ بل تحتاج نظامًا يعرف متى يتوقف، ومتى يصعّد، وكيف يترك أثرًا يمكن مراجعته.
الاستثناء ليس هامشًا في تشغيل الوكيل؛ بل هو المكان الذي تُختبر فيه الثقة فعلًا.
ما المقصود بالاستثناء داخل المؤسسة؟
الاستثناء ليس خطأً تقنيًا فقط. في الواقع، كثير من الاستثناءات المؤسسية ليست أعطالًا برمجية أصلًا. قد يكون الاستثناء طلبًا صحيحًا لغويًا لكنه غير واضح تشغيليًا. وقد يكون تنفيذًا ممكنًا تقنيًا لكنه غير مسموح بحسب الدور أو السياسة أو جهة الاعتماد.
عمليًا، تظهر الاستثناءات المؤسسية غالبًا في خمس حالات:
- غموض القرار: الطلب يحتمل أكثر من تفسير واحد، أو يحتاج إلى حكم بشري لا إلى قاعدة آلية.
- تعارض السياسات: مسار العمل صحيح من ناحية السرعة، لكنه يصطدم بموافقة مطلوبة أو قيد امتثال أو فصل صلاحيات.
- نقص الحالة التشغيلية: الوكيل لا يملك البيانات الكاملة عن الحالة الحالية للطلب أو الملف أو المستخدم.
- فشل نظام تابع: النظام الذي يعتمد عليه التنفيذ غير متاح، أو أعاد نتيجة متناقضة، أو تأخر بما يكفي لتغيير القرار.
- خروج عن النطاق: المستخدم يطلب من الوكيل فعلًا يتجاوز ما صُمِّم له أو ما مُنح له من صلاحيات.
حين تُعامل هذه الحالات على أنها تفاصيل لاحقة، يبدأ التعثر. وحين تُصمم مسبقًا بوصفها جزءًا من التشغيل، يصبح الوكيل أكثر قابليةً للثقة حتى قبل أن يصبح أكثر ذكاءً.
ما الذي تخطئ فيه الفرق عادةً؟
الخطأ الأول هو اعتبار الاستثناءات حالات نادرة. هذا صحيح في العروض المحدودة، لكنه يضعف بسرعة في البيئات الحية. فكلما ارتبط الوكيل بأنظمة أكثر، وصلاحيات أكثر، ومسارات اعتماد أكثر، زادت احتمالات الوقوع في حالات غير مكتملة أو متعارضة.
الخطأ الثاني هو الخلط بين وجود إنسان في الحلقة ووضوح ملكية التصعيد. ليس المطلوب أن يوافق الإنسان على كل خطوة. المطلوب أن يكون معروفًا مسبقًا أي نوع من الاستثناءات يذهب إلى من: هل هي حالة يملكها مدير العملية؟ أم مسؤول الامتثال؟ أم فريق الدعم؟ أم مالك النظام المصدر؟ غياب هذه الملكية يحول الوكيل من أداة تسريع إلى مولّد غموض.
الخطأ الثالث هو الاكتفاء بسجل تقني بدل أثر تشغيلي قابل للمراجعة. التسجيل المفيد ليس مجرد وقت الطلب والاستجابة. ما تحتاجه المؤسسة هو معرفة: ما القرار الذي كان الوكيل على وشك اتخاذه؟ ما القاعدة أو الإشارة التي أوقفته؟ من الذي تجاوز القرار أو اعتمده؟ وما الذي تغير بعد ذلك؟ هنا تحديدًا تصبح سجلات الحوادث والتجاوزات جزءًا من الحوكمة، لا من المراقبة الفنية فقط.
إطار عملي لتصميم الاستثناءات قبل التوسع
1) صنّف الاستثناءات قبل الإطلاق
قبل الحديث عن الدقة أو سرعة الإنجاز، صنّف أنواع الاستثناءات المتوقعة في كل حالة استخدام. لا يكفي وصفها بأنها "حالات طرفية". المطلوب قائمة صريحة: غموض، نقص بيانات، تعارض صلاحيات، تعارض سياسات، فشل تكامل، أو خروج عن النطاق. هذا التصنيف يحدد من البداية أين يسمح للوكيل بالتصرف، وأين يجب أن يتوقف.
2) اربط كل فئة بمالك قرار واضح
كل استثناء يحتاج مالكًا معروفًا لا صندوقًا عامًا. إذا كان الاستثناء متعلقًا بسياسة سفر أو إجازات أو تعويضات، فمالك القرار ليس بالضرورة الفريق التقني. وإذا كان متعلقًا بفصل صلاحيات أو حد إنفاق أو وصول إلى بيانات حساسة، فلابد أن يكون مسار التصعيد متصلًا بصاحب الصلاحية الفعلية. الاستثناء بلا مالك يعني تأخيرًا صامتًا أو قرارًا غير محسوب.
3) صمّم "توقفًا آمنًا" لا انهيارًا كاملًا
أفضل الوكلاء ليسوا الذين يستمرون دائمًا، بل الذين يعرفون متى يتوقفون بطريقة مفيدة. التوقف الآمن قد يعني تحويل الحالة إلى إنسان مع ملخص واضح، أو طلب معلومة ناقصة بدل التخمين، أو تعليق التنفيذ مع حفظ السياق، أو الرجوع إلى مسار أبسط غير ذاتي التنفيذ. توصية NIST بشأن fallbacks مهمة هنا: البديل ليس فشلًا؛ بل جزء من التصميم المسؤول.
4) اجعل التجاوزات مصدر تعلم لا مجرد إذن استثنائي
عندما يتجاوز إنسان قرار الوكيل، لا ينبغي أن يضيع ذلك في البريد أو الدردشة. فـ NIST يوصي بتوثيق حالات تجاوز البشر أو الأنظمة الأخرى لقرارات النظام ومراجعتها. عمليًا، هذا يعني أن كل override مهم يجب أن يتحول إلى إشارة تعلم: هل كانت قاعدة التصعيد خاطئة؟ هل كانت السياسة غير ممثلة؟ هل كانت البيانات ناقصة؟ أم أن المسألة بطبيعتها تحتاج حكمًا بشريًا دائمًا؟
5) راقب الحوادث بوصفها مادة تشغيلية
إفصاح الحوادث وتسجيلها لا يهمان فقط في الحوادث الكبرى. حتى الحوادث الصغيرة المتكررة قد تكشف أن الوكيل ينجح شكليًا لكنه يستهلك وقتًا مؤسسيًا في الخلفية. إذا كان الفريق يعالج كل يوم حالات إعادة توجيه أو تصحيح يدوي أو اعتماد لاحق، فالمشكلة ليست في الاستخدام فحسب، بل في نموذج التشغيل نفسه.
لماذا يهم هذا الآن؟
كلما انتقلت المؤسسات من الاستخدام المعرفي إلى التنفيذ الفعلي، تغير نوع المخاطر. الإجابة الخاطئة قد تُصحَّح لاحقًا. أما الإجراء الخاطئ فقد يخلق أثرًا ماليًا أو تشغيليًا أو امتثاليًا يحتاج إلى معالجة أوسع. لهذا تصبح قضايا مثل الاستئناف، والتجاوز، والتعافي، وإدارة التغيير عناصر تشغيلية أساسية، لا تحسينات لاحقة.
والأهم أن البيئة العربية المؤسسية تضيف طبقة أخرى من الحساسية: تعدد المصطلحات، واختلاف صيغ السياسات، وتفاوت مسارات الاعتماد بين الجهات، كلها تجعل الاستثناءات أكثر أهمية من مجرد جودة اللغة. الوكيل قد يفهم العربية جيدًا، لكنه يظل غير جاهز إذا لم يفهم متى يجب أن يتوقف أو إلى من يصعّد.
الحدود التي يجب الاعتراف بها
ليس الهدف من هذا الطرح إبطاء كل مشروع. الإفراط في التصعيد قد يقتل القيمة مثلما يقتلها التسيّب. كما أن بعض الحالات لا تحتاج وكيلًا أصلًا؛ بل تحتاج أتمتة واضحة أو مساعدًا معرفيًا دون صلاحية تنفيذ. لذلك فتصميم الاستثناءات الجيد لا يعني تعميم الحذر، بل توزيع الثقة بحسب نوع القرار وأثره وقابليته للتراجع.
كذلك، لا يمكن حل كل استثناء بالنموذج نفسه. بعض الاستثناءات سببه سياسة غامضة، وبعضها سببه تكامل ضعيف، وبعضها سببه غياب مالك قرار. تحميل النموذج مسؤولية كل التعثر خطأ إداري قبل أن يكون خطأً تقنيًا.
أسئلة سريعة قبل توسيع أي وكيل
- ما أنواع الاستثناءات الأكثر احتمالًا في هذه الحالة تحديدًا؟
- ما الحالات التي يجب أن تتوقف تلقائيًا بدل أن تُنفَّذ؟
- من يملك كل نوع من أنواع التصعيد؟ وهل هذه الملكية معروفة خارج الفريق التقني؟
- هل يمكن مراجعة التجاوزات البشرية لاحقًا واستخلاص نمط واضح منها؟
- ما البديل الآمن إذا تعطل النظام التابع أو تعارضت الإشارات؟
خطوة أولى عملية
اختر حالة استخدام واحدة فقط، ثم ابنِ سجل استثناءات من صفحة واحدة قبل أي توسع. يجب أن يتضمن هذا السجل: أنواع الاستثناءات المتوقعة، مالك كل نوع، شرط التوقف، مسار التصعيد، وما الذي يجب تسجيله عند كل حالة. إذا لم تستطع المؤسسة كتابة هذه الصفحة بوضوح، فهي على الأرجح لم تصل بعد إلى مستوى يسمح بتوسيع الوكيل بأمان.
الخلاصة
المؤسسات لا تحتاج إلى وكيل مبهر في أفضل الظروف، بل إلى وكيل منضبط في الظروف غير المثالية. المسار الطبيعي يثبت أن الفكرة تعمل. أما الاستثناء فيثبت أن التشغيل يمكن الوثوق به. وبين الاثنين يتحدد ما إذا كان الوكيل سيبقى تجربةً جيدة، أم يصبح جزءًا مسؤولًا من العمل اليومي.