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