كيف نتحكم في الوكلاء داخل المؤسسة؟ من الهوية والصلاحيات إلى بوابة الإيقاف

المشكلة ليست في ذكاء الوكيل، بل في مساحة حركته

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

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

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

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

أربعة أضلاع تحدد كل وكيل: الهوية والنطاق والأدوات والبيانات

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

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

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

الصلاحيات تُمنح على مستوى الأداة، لا على مستوى المحادثة

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

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

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

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

سجل يُعيد بناء القرار، لا مجرد سجل محادثة

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

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

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

الكمون

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

دورة حياة الوكيل: تسجيل، تجربة، ترقية، ثم إيقاف

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

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

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

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

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

حدود التحكم: أين يتوقف الضبط ويبدأ التصميم

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

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

المقارنة العملية تفيد عند توزيع المهام لا عند المقارنة بين تقنية وإنسان:

أما في اختيار الأدوات، فالمفيد أن تكون الصلاحيات والسجل جزءاً من المنصة لا إضافات تُبنى لاحقاً. هذا هو المنطق الذي تُبنى عليه منصة مثل Pilardin: مساحة عمل واحدة تجمع المحادثة مع المستندات (RAG) وربط الأنظمة الحية ووحدات Matrix المتخصصة، بحيث يمكن تحديد ما يقرأه الوكيل وما يكتبه وما يُسجَّل. يمكن البدء بحساب تجريبي عبر /signup ثم مراجعة الوحدات المتخصصة عبر /matrix، مع إبقاء قرار الصلاحيات بيد فريقكم لا بيد المورّد.

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

FAQ

من يملك الوكيل داخل المؤسسة: تقنية المعلومات أم الإدارة التشغيلية؟

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

هل يكفي سجل المحادثات للتدقيق على قرارات الوكيل؟

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

كيف نتحكم في وكيل يتصل بأنظمة قديمة لا تدعم صلاحيات دقيقة؟

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

ما أول ثلاث خطوات نبدأ بها هذا الأسبوع دون مشروع كبير؟

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

هل يمكن التحكم في الوكلاء مع الاحتفاظ بالبيانات داخل المؤسسة؟

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