لا تكلف الوكيل قبل ضبط صلاحياته

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

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

ما الذي تغيّر مع الوكلاء؟

تُقدَّم الإصدارات الحديثة من النماذج الوكيلة على أنها موجَّهة أكثر إلى تنفيذ العمل. فإعلان Anthropic عن Claude Sonnet 5، مثلًا، يصف نموذجًا مصمَّمًا لوضع الخطط واستخدام أدوات مثل المتصفحات والطرفيات. وأهمية ذلك أن سير العمل لم يعد يقتصر على إنتاج نص ينسخه إنسان.

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

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

وهذه المقالة تصحّح ترتيب السؤالين. عامل الوكلاء كما تعامل الموظفين المبتدئين الذين لهم مستويات صلاحية. ولا تعاملهم كأنهم برمجيات سحرية يُفتح لها الوصول بلا حد.

حدد السلطة قبل المهمة

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

ابدأ بخمسة مدخلات. أولًا، سمِّ سير العمل تسمية ضيقة. فعبارة «عمليات المبيعات» أوسع من اللازم، أما «تجهيز ملاحظات تجديد الحساب من حقول CRM المعتمدة» فصالحة للاستخدام. ثانيًا، سمِّ المالك البشري. يستطيع الوكيل أن ينفّذ العمل، لكن التبعات يتحملها شخص.

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

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

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

مصفوفة الموافقة

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

المستوى الأول: قراءة فقط

يستطيع الوكيل أن يفحص المدخلات المعتمدة ويعيد ملخصات، أو مقارنات، أو مستخلصات، أو تحليلًا. ولا يستطيع أن يغيّر أي شيء.

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

المستوى الثاني: صياغة فقط

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

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

المستوى الثالث: توصية

يستطيع الوكيل أن يحلل الخيارات ويقترح قرارًا. ويبقى القرار للإنسان.

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

المستوى الرابع: إجراء يمكن التراجع عنه

يستطيع الوكيل أن ينفّذ إجراءات منخفضة المخاطر، تُسجَّل ويسهل التراجع عنها.

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

المستوى الخامس: موافقة مطلوبة

يجب أن يتوقف الوكيل قبل أي إجراء لا يمكن التراجع عنه أو عالي المخاطر. هذا هو الخط الذي يحمي الشركة.

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

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

شغِّل سير العمل

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

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

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

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

أين يفشل الوكلاء؟

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

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

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

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

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

أمر ضبط الصلاحيات

استخدم هذا الأمر قبل أن يبدأ الوكيل عملًا يستخدم فيه الأدوات. املأ الحقول بنفسك. لا تطلب من النموذج أن يخترع سلطته. (الأمر التالي مكتوب بالإنجليزية. انسخه كما هو واملأ الحقول.)

You are acting as a workflow agent under explicit permission limits.

Business context:
Workflow name:
Human owner:
Business objective:

Allowed inputs:
Approved documents, records, pages, repositories, datasets, or tools:
Inputs that are not allowed:

Data restrictions:
Use only the minimum data required for the task.
Do not request or use confidential, regulated, credential, payment, legal, medical, or unnecessary personal data unless the human owner confirms approved access.
If required information is missing, ask for the minimum safe input.

Permission levels by system:
System 1:
Permission level: read-only, draft-only, recommend, execute reversible actions, or request approval for irreversible actions
System 2:
Permission level:
System 3:
Permission level:

Approval triggers:
Stop and request human approval before any action that sends, publishes, deletes, overwrites, purchases, changes billing, changes permissions, modifies customer records, commits code, deploys, submits a form, or creates an external obligation.

Task:

Required output:
1. Planned steps before action.
2. Work performed within the permission limits.
3. Drafts or recommendations produced.
4. Items that require human approval.
5. Assumptions, uncertainties, and missing information.
6. Action log showing inputs used and changes made.

Quality rule:
If the task requires authority beyond the listed permission levels, stop. Do not improvise around the limit.

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

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

اعتراض السرعة

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

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

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

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

ما العمل الآن؟

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

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