الهوية والتحكم في الوصول لوكلاء الذكاء الاصطناعي

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

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

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

بالنسبة للمؤسسات، هذه ليست تفاصيل صغيرة. بدون نموذج هوية ووصول صريح، ستنهار قابلية التدقيق والمساءلة والتحكم في وقت التشغيل (runtime governance) تمامًا عندما يبدأ الوكيل في تقديم قيمة حقيقية.

الوكيل ليس سكريبتًا مجهولاً

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

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

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

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

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

الصلاحيات لا تكفي إذا كانت قائمة على الأدوار الثابتة

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

لا ينبغي تحديد صلاحيات الوكيل فقط من خلال دوره، ولكن أيضًا من خلال السياق: من هو المستخدم الذي يمثله، وما هي المهمة التي يتم تنفيذها، وما هي البيانات التي يتم الوصول إليها، وحساسية المعلومات، والمخاطر الناتجة عن الإجراء الذي سيتم تنفيذه. يُعرف هذا النهج باسم التفويض المراعي للسياق (context-aware authorization).

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

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

في كل هذه الأمثلة، الأدوار الثابتة غير كافية. المطلوب هو تفويض يأخذ في الاعتبار سياق وقت التشغيل.

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

لماذا هذا مهم؟ لأن الوكيل الذي لديه صلاحيات كثيرة جدًا هو أحد أكثر المخاطر واقعية في المؤسسات. الإغراء كبير: لنجاح النموذج الأولي بسرعة، غالبًا ما تمنح الفرق وصولاً واسعًا للوكيل. على المدى القصير، هذا يسرع العرض التجريبي. على المدى الطويل، هذا يخلق وكلاء ذوي صلاحيات مفرطة (over-permissioned agents) يصعب تدقيقهم ويشكلون خطرًا عند التوسع. المبدأ الأكثر صحة يظل كما هو في أمن البشر والتطبيقات: أقل صلاحية (least privilege). الفرق هو أنه في الذكاء الاصطناعي الوكيل، يجب تطبيق مبدأ أقل صلاحية بشكل أكثر ديناميكية لأن الوكيل يعمل عبر سياقات مختلفة.

السلطة المفوضة: باسم من يتصرف الوكيل؟

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

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

يجب التمييز بين مصادر التفويض الثلاثة هذه في النظام. إذا لم يتم ذلك، سيفقد مسار التدقيق (audit trail) سياقًا مهمًا جدًا.

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

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

أنماط التنفيذ للمؤسسات

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

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

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

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

رابعًا، استخدم الوصول في الوقت المناسب (just-in-time) والوصول المحدد النطاق (scoped access) عندما يكون ذلك ممكنًا. للإجراءات الأكثر حساسية، يجب ألا يكون الوصول نشطًا بشكل دائم. من الأكثر أمانًا أن يحصل الوكيل على وصول مؤقت، فقط لمهمة معينة، ثم ينتهي هذا الوصول بعد اكتمال المهمة. يساعد هذا النهج في تقليل نصف قطر الانفجار (blast radius) في حالة حدوث خطأ في التكوين أو إساءة استخدام.

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

كيف تعمل هذه الأنماط في الممارسة العملية

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

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

في عمليات العملاء، يكون لوكيل الخدمة هويته الخاصة ويعمل في سياق عميل تم التحقق منه. يُسمح له بقراءة تاريخ التذاكر والاستحقاقات. يُسمح له بتنفيذ ائتمان حسن النية الصغير إذا تم استيفاء السياسة. بالنسبة للعملاء المهمين (VIP)، أو الحالات المتكررة، أو القيم فوق الحد، يقدم الوكيل توصية فقط وينتظر المشرف.

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

متى لا يكون هذا النمط مناسبًا بعد

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

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

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

أسئلة للعودة بها إلى المنزل

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

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