وكلاء الذكاء الاصطناعي داخل نظام ERP: ما الذي يمكن تفويضه بأمان في 2026 وما لا يجوز

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

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

قبل عامين كان معنى «الذكاء الاصطناعي داخل نظام ERP» نافذة محادثة تجيب عن أسئلتك حول بياناتك. في 2026 تغيّر العرض: تبيع شركات البرمجيات اليوم وكلاء (agents)، أي ذكاءً اصطناعيًا لا يكتفي بالكلام، بل يبحث عن المعلومة ويتخذ القرار وينفّذ إجراءات فعلية داخل أنظمتك. يستطيع أن يُنشئ أمر شراء، أو يرسل تذكيرًا بالدفع، أو يغيّر سعرًا.

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

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

هذه هي الحلقة الأولى من سلسلة من ثلاث حلقات عن الذكاء الاصطناعي في العمليات. تشرح الحلقة الثانية كيف يربط MCP الذكاء الاصطناعي ببيانات الأعمال بأمان: MCP explained. وتتناول الحلقة الثالثة الموافقات وسجلات التدقيق وتصميم الإشراف البشري: AI guardrails.

من المساعد إلى الوكيل: ما الذي تغيّر فعلًا

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

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

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

وتعكس التوقعات المبكرة ذلك. ففي يونيو 2025 توقعت شركة Gartner أن يُلغى أكثر من 40% من مشاريع الذكاء الاصطناعي الوكيلي بحلول نهاية 2027، بسبب ارتفاع التكاليف وغموض القيمة التجارية وضعف ضوابط المخاطر (بيان Gartner الصحفي). ويحذّر البيان نفسه مما يسمى «agent washing»، أي إعادة تغليف روبوتات المحادثة والأتمتة المعتادة وتسميتها وكلاء. وقدّرت Gartner أن نحو 130 مزوّدًا فقط من بين آلاف المزوّدين الذين يدّعون امتلاك قدرات وكيلية هم أصحاب قدرات حقيقية.

سُلّم المخاطر: أربعة مستويات لإجراءات الوكيل

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

المستوى	ماذا يفعل الوكيل	مثال في نظام ERP	موضعه المناسب في 2026
1. الإجابة	يقرأ البيانات ويشرح ويلخّص	«أي أصناف SKU ستنفد خلال 10 أيام؟»	آمن للتشغيل بحرية، بصلاحية قراءة فقط
2. المسودة	يعدّ مستندًا يراجعه إنسان	مسودة أمر شراء، وصف منتج، بريد تذكير	آمن إذا لم يُرسل شيء أو يُسجَّل قبل موافقة شخص
3. إجراء قابل للتراجع	يغيّر بيانات يمكن التراجع عنها بسلاسة	وضع وسوم على الطلبات، حجز مخزون، إعادة جدولة مهمة	مسموح في حالات ضيقة ومختبَرة جيدًا، مع سجل وإمكانية تراجع
4. أموال أو لا رجعة فيه	يدفع، يسترد، يحذف، يرسل إلى جهات خارجية	الدفع لمورّد، استرداد مبلغ، حذف سجلات	يقرر إنسان في كل مرة، في الوقت الحالي

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

ويتحول السُّلّم إلى قاعدة توجيه حين تطرح ثلاثة أسئلة بالترتيب، فأول إجابة تنطبق تحدد وجهة المهمة.

خمس حالات استخدام قوية للبداية في شركة نامية

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

1. أسئلة المخزون والطلبات

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

2. مسودات أوامر الشراء

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

3. مطابقة الفاتورة مع أمر الشراء

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

4. متابعة المستحقات المتأخرة

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

5. نصوص المنتجات والترجمات

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

ما لا ينبغي أتمتته بعد

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

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

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

جودة البيانات والصلاحيات أولًا

موثوقية الوكيل بقدر موثوقية البيانات التي يقرؤها والصلاحيات التي يحملها. وإصلاح الأمرين أسهل قبل تشغيله.

بيانات نظيفة

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

• أرقام المخزون تطابق ما على الرف، ضمن هامش تسامح قِسته فعلًا.
• لكل منتج رمز SKU واحد ومورّد وتكلفة ومدة توريد.
• العملاء والموردون المكررون جرى دمجهم.
• وحدات القياس متسقة (فلا يكون الصندوق أحيانًا وحدة وأحيانًا اثنتي عشرة).

صلاحيات ضيقة

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

تتعمق الحلقة الثالثة من هذه السلسلة في الموافقات وسجلات التدقيق. أما الآن فاحفظ القاعدة: ما لا يحق للشخص فعله، لا يحق لوكيله فعله.

كيف تحكم على ادعاءات المورّد حول «وكيل الذكاء الاصطناعي»

في زمن agent washing لا يثبت العرض التوضيحي المبهر إلا القليل. اطرح هذه الأسئلة وانتظر إجابات محددة لا شرائح عرض.

1. الصلاحيات. هل أستطيع تقييد الوكيل بحسب الدور والوحدة والإجراء؟ وهل هو للقراءة فقط افتراضيًا؟
2. سجل التدقيق. هل يُسجَّل كل إجراء: من طلبه، وماذا رأى الوكيل، وماذا فعل، ومتى؟ وهل يمكن تصدير السجل؟
3. قابلية التفسير. هل أستطيع، لأي إجراء، أن أرى المنطق والبيانات التي استند إليها بلغة بسيطة؟
4. التراجع. أي الإجراءات يمكن عكسها، وكيف؟ وماذا عن التي لا يمكن عكسها؟
5. خطوات الموافقة. هل أستطيع اشتراط موافقة بشرية على إجراءات أو مبالغ محددة، وهل يفرض النظام ذلك بنفسه لا مجرد تعليمة في الموجّه (prompt)؟
6. التعامل مع البيانات. إلى أين تذهب بياناتي؟ وهل تُستخدم لتدريب النماذج؟ وهل يمكن تشغيل النموذج حيث أختار؟
7. ضبط التكلفة. هل أرى الاستخدام لكل مستخدم وأضع حدودًا، حتى لا يرفع وكيل عالق في حلقة متكررة الفاتورة؟
8. السلوك عند الفشل. ماذا يفعل حين لا يكون متأكدًا: يتوقف ويسأل أم يخمّن؟

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

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

خطة تجريبية مدتها 30-60-90 يومًا

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

الأيام 1 إلى 30: للقراءة فقط

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

الأيام 31 إلى 60: مسودات بموافقة

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

الأيام 61 إلى 90: إجراء واحد قابل للتراجع

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

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

• الساعات الموفَّرة أسبوعيًا، مقيسة لا مقدَّرة.
• نسبة قبول المسودات وأهم أسباب الرفض.
• الأخطاء التي وصلت إلى عميل أو مورّد (الهدف صفر).
• تكلفة استخدام الذكاء الاصطناعي مقارنة بالوقت الموفَّر.

إلى أين يتجه الأمر

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

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

أبرز الخلاصات

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

Anichur Rahaman مهندس برمجيات معماري ومؤسس StoreConsole، يصمّم أنظمة التجارة وERP للشركات النامية، ويهتم خصوصًا بالبنية القائمة على الأحداث وسلامة البيانات وتشغيل الأنظمة على خوادم الشركة نفسها.