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

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

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

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

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

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

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

هذا هو التحول المطلوب: تعامل مع الوكلاء كموظفين مبتدئين لهم مستويات صلاحية، لا كبرمجيات سحرية بقدرة وصول مفتوحة.

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

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

ابدأ بخمسة مدخلات. أولا، سم سير العمل بدقة. عبارة مثل «عمليات المبيعات» واسعة جدا. أما «تجهيز ملاحظات تجديد الحساب من حقول 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.

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

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

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

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

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

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

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

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

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

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