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