المراقبة (Observability) للأنظمة العاملة بالوكلاء (Agentic Systems)

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

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

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

لماذا تعتبر المراقبة للأنظمة العاملة بالوكلاء أكثر صعوبة بكثير

الصعوبة الرئيسية في مراقبة الأنظمة العاملة بالوكلاء ليست لأن التكنولوجيا أحدث، بل لأن الكائن الذي تتم مراقبته أكثر تعقيداً. في التطبيقات العادية، يكون مسار التنفيذ واضحاً نسبياً. يصل الطلب، تقوم الخدمة بمعالجته، تُقرأ قاعدة البيانات، ويخرج الرد. إذا كانت هناك مشكلة، يمكن للفريق تتبع السجلات (Logs) والمقاييس (Metrics) والتتبعات (Traces) للعثور على الاختناق أو الخطأ. في الأنظمة العاملة بالوكلاء، يمكن أن يكون المسار أكثر تداخلاً بكثير: يأتي المحفز (Trigger) من مستخدم، أو حدث، أو سير عمل (Workflow)؛ يقوم المنسق (Orchestrator) بتقسيم المهمة؛ يجلب الوكيل السياق من RAG أو الذاكرة؛ ينتج النموذج (Model) الاستدلال أو الخطة؛ يتم استدعاء الأدوات واحدة تلو الأخرى؛ يقوم محرك السياسات (Policy Engine) بتقييم الإجراءات؛ قد يُطلب من الإنسان الموافقة؛ ثم ينفذ الوكيل الإجراء أو يرفع الأمر لمستوى أعلى.

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

الطبيعة الاحتمالية للأنظمة العاملة بالوكلاء تغير طريقة مراقبتنا. حتى عندما تبدو التعليمات (Prompt) والأدوات والبيانات متطابقة، يمكن أن تختلف المخرجات قليلاً. هذا يعني أن المؤسسات لا يمكنها الاعتماد فقط على المراقبة القائمة على رموز الأخطاء. إنها بحاجة لمراقبة أنماط السلوك. على سبيل المثال، في عمليات خدمة العملاء: قد لا يفشل وكيل استرداد الأموال (Refund Agent) تقنياً أبداً، لكنه في الأسبوع الماضي بدأ في تصعيد الحالات التي كان يمكن حلها تلقائياً بشكل متكرر أكثر. من الناحية التحتية، كل شيء أخضر. من الناحية التشغيلية، هناك انحراف سلوكي (Behavioral Drift) يقلل الإنتاجية. مثال آخر في المشتريات: قد يظل وكيل "من الطلب إلى أمر الشراء" (Intake-to-PO) ناجحاً في إنشاء الطلبات، لكنه بدأ في اختيار مسار موافقة أكثر تحفظاً بسبب تغيير في سياسة الاسترجاع (Retrieval Policy). لا يوجد حادث تقني، لكن زمن الدورة (Cycle Time) يزداد سوءاً.

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

ما يجب تسجيله: من التعليمات (Prompt) إلى النتيجة (Outcome)

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

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

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

ثالثاً، السياق المسترجع (Retrieved Context). إذا كان الوكيل يستخدم RAG، أو قاعدة المعرفة الرسومية (Knowledge Graph)، أو الذاكرة، يجب أن يظهر السجل أي المستندات أو أجزاء السياق تم جلبها، ومن أي مصدر، وما هو إصدارها أو طابعها الزمني، وما إذا كان الوصول قد اجتاز فحص الصلاحيات. بدون هذا، من الصعب شرح لماذا اتخذ الوكيل قراراً معيناً.

رابعاً، استجابة النموذج (Model Response) وأثر الاستدلال (Reasoning Artifact). لا تحتاج المؤسسات دائماً إلى تخزين سلسلة الأفكار الخام (Chain-of-Thought) بالكامل. لكنها تحتاج إلى تخزين ما يكفي من الأثر للتدقيق وتصحيح الأخطاء، مثل ملخص خطة العمل، أو تصنيف النية (Intent Classification)، أو إشارة الثقة (Confidence Signal) إن وجدت، أو مخرجات القرار المنظمة المستخدمة للخطوة التالية. المبدأ: احتفظ بما يكفي للمساءلة، لكن لا تجعل السجلات مكاناً لتسرب البيانات الحساسة أو الملكية الفكرية للنموذج.

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

سادساً، قرار السياسة (Policy Decision)، والموافقة البشرية (Human Approval)، والإجراء النهائي (Final Action). إذا كان هناك محرك سياسات، أو سير عمل موافقة، أو حواجز حماية (Guardrails)، يجب أن يدخل كل شيء في السجل: أي سياسة تم تقييمها، وما هي نتيجتها (سماح، منع، تصعيد، أو طلب موافقة)، ومن هو المعتمد البشري، وما هو القرار النهائي، وما هو الإجراء النهائي الذي تم تنفيذه بالفعل. بدون هذه الطبقة، تمتلك المؤسسة فقط سجلات تقنية، وليس سجلات حوكمة.

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

كلما زادت شمولية السجلات، زاد خطر كشف البيانات. هذه مقايضة يجب إدارتها بانضباط. غالباً ما تتعامل الأنظمة العاملة بالوكلاء مع بيانات العملاء، ومعلومات الرواتب، وتفاصيل الموردين، والعقود، والبيانات المالية، أو سجلات الحوادث الداخلية. لهذا السبب، يجب تصميم التسجيل وفقاً لمبدأ تنقيح (Redaction) البيانات الحساسة التي لا تحتاج للتخزين الخام، وترميز (Tokenization) أو إخفاء (Masking) معرفات معينة، وتخزين آمن مع ضوابط وصول صارمة، وسياسة احتفاظ واضحة، وفصل المهام (Segregation of Duties) بحيث لا يمكن لكل من يدير المراقبة رؤية المحتوى الحساس. مثال في عمليات الموارد البشرية: يمكن للسجل أن يذكر أن الوكيل جلب سياسة الإجازات وحالة التوظيف، لكن ليس كل التفاصيل الشخصية يجب أن تُخزن بشكل خام في لوحة بيانات عامة. مثال في خدمة العملاء: قد يلزم حفظ النص للتدقيق المحدود، لكن يجب إخفاء المعلومات الشخصية (PII) للاستخدام التشغيلي اليومي. المبدأ الهام: يجب أن تزداد قابلية التدقيق دون توسيع نطاق الضرر المحتمل للبيانات.

مقاييس وقت التشغيل (Runtime Metrics): ليست تقنية فقط، بل أيضاً الجودة والأعمال

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

المجموعة الأولى هي المقاييس التقنية للحفاظ على صحة وقت التشغيل. تظل المقاييس التقنية مهمة لأن الأنظمة العاملة بالوكلاء تعتمد على النماذج وواجهات API والاسترجاع وتكامل الأدوات، وكلها يمكن أن تفشل. بعض المقاييس الأساسية التي يجب مراقبتها: زمن الاستجابة لكل خطوة ومن البداية إلى النهاية، وتكلفة الرموز (Token) أو الحوسبة لكل معاملة، ومعدل خطأ الأداة، ومعدل إعادة المحاولة، ومعدل انتهاء المهلة، واستخدام البديل (Fallback)، وتوزيع أنماط الفشل، وتوفر المكونات الهامة مثل بوابة النموذج (Model Gateway)، ومخزن المتجهات (Vector Store)، ومحرك السياسات، أو سجل الأدوات. مثال في عمليات تقنية المعلومات: إذا زاد زمن استجابة وكيل فرز الحوادث (Incident Triage)، فقد يتأثر اتفاق مستوى الخدمة (SLA) لمعالجة الحوادث. مثال في عمليات العملاء: إذا ارتفع معدل إعادة المحاولة لواجهة CRM API، فقد يبدأ الوكيل في الفشل في تجميع سياق العميل بشكل صحيح. تساعد المقاييس التقنية فريق المنصة في الحفاظ على الاستقرار، لكنها ليست كافية لتقييم ما إذا كان الوكيل لا يزال جديراً بالثقة.

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

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

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

المراقبة والتنبيهات (Monitoring and Alerting): اكتشاف الانحراف (Drift) قبل أن يصبح حادثاً

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

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

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

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

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

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

مفاضلات التنفيذ: لا تقم ببناء "وحش مراقبة"

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

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

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

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

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