الحواجز الواقية، محرك السياسات، وسير عمل الموافقة البشرية

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

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

هذا هو السؤال الذي يجب على كل شركة الإجابة عليه قبل منح الوكيل إمكانية الوصول إلى أنظمة الإنتاج: كيف نمنع الوكيل من القيام بإجراءات خاطئة قبل حدوث الضرر؟ قابلية المراقبة (Observability)، التي تمت مناقشتها في المقال السابق، يمكنها فقط رؤية وشرح ما حدث بعد وقوعه. لمنع حدوث ذلك مسبقًا، نحتاج إلى ثلاثة مكونات تعمل معًا: الحواجز الواقية (Guardrails)، ومحرك السياسات (Policy Engine)، وسير عمل الموافقة البشرية (Human Approval Workflow).

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

لهذا السبب، يجب تثبيت الحواجز الواقية في بيئة العمل العاملة (Runtime) في المؤسسات العاملة بالوكلاء، بالقرب من عملية اتخاذ القرار والإجراء، وليس فقط كتابتها في وثائق السياسات أو مطالبات النظام (System Prompts).

الحواجز الواقية ليست مجرد فلتر للمخرجات

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

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

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

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

رابعًا، تنفيذ الإجراء (Action Execution). هذه هي النقطة الأكثر أهمية. يجب أن تتحقق الحواجز الواقية مما إذا كان الإجراء الذي سيغير حالة العمل مسموحًا به بالفعل. إنشاء مورد جديد، ترحيل قيد محاسبي، تغيير حد ائتماني، تحرير حظر دفع، أو إغلاق حادثة كمكتملة - كل هذه الأمور تحتاج إلى تحكم. هنا تحتاج الشركة إلى التمييز بوضوح بين القراءة (Read)، والتوصية (Recommend)، والمسودة (Draft)، والتنفيذ (Execute). تبدو العديد من حالات الاستخدام آمنة حتى يتم منح الوكيل صلاحية التنفيذ دون تحكم كافٍ في وقت التشغيل.

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

الحواجز الواقية يجب أن تعمل في وقت التشغيل (Runtime)

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

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

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

محرك السياسات: مكان اتخاذ قرارات الإذن بشكل متسق

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

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

بالنسبة للمؤسسات، يحتاج قرار السياسة عادةً إلى النظر في مجموعة من العوامل. أولاً، الدور والسلطة المفوضة (Role and Delegated Authority). الوكيل يتصرف نيابة عن من؟ هل هو بناءً على تعليمات المستخدم، أو سير عمل رسمي، أو حدث نظام؟ هل صلاحيته لا تزال سارية؟ ثانيًا، السياق التجاري (Business Context). ما هو الكائن الذي يتم التعامل معه؟ مورد، فاتورة، طلب، تذكرة، عقد، أو بيانات موظف؟ المجالات المختلفة قد يكون لها قواعد مختلفة. ثالثًا، قيمة المعاملة أو الأهمية النسبية (Transaction Value or Materiality). العديد من الإجراءات آمنة عند القيم المنخفضة، ولكنها ليست كذلك عند القيم المرتفعة. قد يُسمح بتنفيذ رصيد حسن نية صغير تلقائيًا، ولكن يجب أن يخضع المبلغ المسترد الكبير لإشراف المشرف. قد تتم معالجة طلب الشراء القياسي تلقائيًا حتى حد معين، ولكن يجب أن تتوقف المشتريات الاستراتيجية للموافقة. رابعًا، مستوى المخاطرة (Risk Level). بعض الإجراءات قابلة للعكس، والبعض الآخر غير قابل للعكس. بعضها له تأثير محلي، والبعض الآخر عبر الأنظمة. يجب أن يفهم محرك السياسات هذا الفرق. خامسًا، المتطلبات التنظيمية أو متطلبات الرقابة (Regulatory or Control Requirement). في مجالات معينة، القواعد ليست مجرد تفضيلات داخلية، بل هي التزامات امتثال - مثل الفصل بين المهام، أو الحد الأدنى من الأدلة، أو الالتزام بالمراجعة البشرية.

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

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

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

أحد أهم المبادئ: يجب أن يترك كل قرار سياسة أثرًا يمكن تدقيقه. يجب أن تكون الشركة قادرة على شرح السياسة التي تم تقييمها، ومدخلات السياق المستخدمة، وما إذا كانت النتيجة هي السماح (Allow)، أو الرفض (Deny)، أو رفع المستوى (Escalate)، أو طلب الموافقة (Require Approval)، ومتى تم اتخاذ القرار. هذا مهم ليس فقط للتدقيق الرسمي، ولكن أيضًا للعمليات اليومية. عندما يسأل المستخدم لماذا رفض الوكيل إجراءً معينًا، لا ينبغي للفريق الإجابة، "لأن النظام قال لا." يجب أن يكونوا قادرين على إظهار المنطق والسياق.

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

سير عمل الموافقة البشرية: دخول الإنسان في النقطة المناسبة

في المؤسسة العاملة بالوكلاء، لا يعني مفهوم "الإنسان في الحلقة" (Human-in-the-loop) أن الإنسان يجب أن يفحص كل شيء. هذا سيدمر فوائد الذكاء الاصطناعي العاملي. المطلوب هو سير عمل موافقة بشرية انتقائي وقائم على المخاطر.

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

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

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

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

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

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

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

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

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

بالنسبة لإجراءات معينة، لا يتوقف التحكم عند الموافقة. تحتاج الشركة أيضًا إلى التفكير في ما يحدث إذا تبين أن إجراء الوكيل خاطئ. هناك ثلاثة أنماط شائعة. أولاً، التراجع (Rollback). إذا كان النظام يدعم الإلغاء المباشر، فهذا مثالي - إلغاء تذكرة تم إنشاؤها بشكل خاطئ، أو استعادة تكوين غير إنتاجي، أو إلغاء حالة معينة قبل متابعة العملية. ثانيًا، الإجراء التعويضي (Compensation Action). إذا كان لا يمكن عكس الإجراء مباشرة، يحتاج النظام إلى إجراء تعويضي - إذا أرسل الوكيل إشعارًا خاطئًا لمورد، فيجب متابعة تصحيحية؛ إذا قام الوكيل بتوجيه حالة عميل بشكل خاطئ، فيجب إعادة التعيين والتواصل مرة أخرى؛ إذا قام الوكيل بتشغيل خطوة عملية خاطئة، فيجب إجراء تحييد. ثالثًا، مسار المعالجة اليدوي (Manual Remediation Path). للحالات الأكثر تعقيدًا، تحتاج الشركة إلى مسار معالجة يدوي واضح: من يتولى المسؤولية، وكيف يتم تسجيل الحادث، وكيف يتم إعادة دمج الدروس المستفادة في السياسات أو الحواجز الواقية.

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

مصفوفة الاستقلالية: طريقة عملية لتحديد حدود إجراءات الوكيل

الطريقة الأكثر عملية لاختتام هذه المناقشة هي استخدام مصفوفة الاستقلالية (Autonomy Matrix). ليس من الضروري أن تكون جميع حالات الاستخدام في نفس المستوى.

على مستوى المساعدة (Assist)، يساعد الوكيل فقط في البحث عن السياق أو التلخيص أو تقديم الرؤى. مناسب للمجالات الغامضة، أو البيانات غير المستقرة، أو العمليات التي لا تزال تعتمد بشكل كبير على الحكم البشري.

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

على مستوى التنفيذ مع الموافقة (Execute-with-Approval)، يمكن للوكيل إعداد وتنفيذ الإجراءات بعد الموافقة البشرية. مناسب للإجراءات عالية القيمة، أو سير العمل الخاضع للتنظيم، أو المجالات التي تحتاج إلى دليل على التحكم الرسمي.

على مستوى التنفيذ مع المراقبة (Execute-with-Monitoring)، ينفذ الوكيل تلقائيًا ضمن حدود سياسة واضحة، ثم تتم مراقبته من خلال قابلية المراقبة وأخذ العينات. مناسب للكميات الكبيرة، والمخاطر المنخفضة إلى المتوسطة، والإجراءات القابلة للعكس، والمجالات ذات السياسات الناضجة بما فيه الكفاية.

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

الآثار العملية

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

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

أسئلة تأملية لرؤساء أقسام تكنولوجيا المعلومات (CIO)، والعمليات (COO)، والموارد البشرية (CHRO)، وقادة التحول: إذا قام وكيل واحد في شركتك غدًا باتخاذ إجراء خاطئ له تأثير حقيقي على عميل أو موظف أو معاملة، هل يمكنك أن تشرح بسرعة أي حاجز واقٍ كان يجب أن يمنعه، وأي سياسة سمحت به، ومن كان يجب أن يوافق عليه، وكيف سيعمل النظام على استعادة الوضع؟ إذا كانت الإجابة غير واضحة بعد، فإن التركيز التالي ليس إضافة المزيد من الوكلاء، بل تعزيز الحوكمة الرقابية والحوكمة في وقت التشغيل أولاً.