GenAI
وكلاء الذكاء الاصطناعي داخل أنظمتك: ما الذي يجوز للوكيل أن يفعله وحده، وما الذي يجب أن يوافق عليه شخص، وكيف تبدأ دون أن تفقد السيطرة
وكيل الذكاء الاصطناعي نموذج لغوي يستطيع استدعاء دوال في أنظمتك، مثل الاستعلام عن دفعة أو إصدار استرداد مالي. وتصنّف هذه المقالة تلك الدوال بحسب من يقرر، الوكيل أم الشخص، وتبيّن كيف تبدأ بسير عمل واحد ضيق.
بقلم amBrainقراءة 10 دقائق
في هذا المقال
وكيل الذكاء الاصطناعي نموذج لغوي يستطيع أن يطلب من برمجياتك تشغيل دوال، أي إجراءات مثل الاستعلام عن دفعة، أو تحديث تذكرة، أو إصدار استرداد مالي. والنموذج لا يفعل سوى تقديم الطلب. أما أنظمتك فتقرر هل تنفّذه، وهنا تحتفظ بالسيطرة. ابدأ بمهمة واحدة ضيقة، يقرأ فيها الوكيل البيانات ويُعدّ المسودات وحده. ويوافق شخص محدد بالاسم على كل ما ينقل أموالًا، أو يغيّر سجل عميل، أو يخرج من الشركة.
الجواب المختصر: صنّف كل دالة يمكن أن يستدعيها الوكيل في ثلاث مجموعات. فالوكيل يقرأ البيانات ويكتب المسودات وحده. ويوافق شخص على الاستردادات المالية والمدفوعات وتغييرات سجلات العملاء والرسائل الموجّهة إلى العملاء قبل حدوثها. أما البيانات المصرفية والحدود وصلاحيات الوصول فتبقى بعيدة عن متناوله. ابدأ بسير عمل واحد، وامنح الوكيل حسابًا خاصًا به بأضيق الصلاحيات، وسجّل كل استدعاء، وقارن نتائجه بعمل فريقك اليوم.
ما وكيل الذكاء الاصطناعي، بكلمات بسيطة؟
النموذج اللغوي، وهو نوع الذكاء الاصطناعي الذي يقف وراء ChatGPT، ينتج نصًا. أما الوكيل فهو نموذج لغوي موصول بدوال في أنظمتك، فيمكن أن يكون ناتجه إجراءً لا إجابة فقط.
تقول وثائق Anthropic الخاصة بنماذج Claude: «استخدام الأدوات (ويُسمّى أيضًا استدعاء الدوال) يتيح لـ Claude استدعاء دوال تحددها أنت أو توفّرها Anthropic». أما في الدوال التي تحددها أنت، فإن النموذج «يعيد استدعاءً منظمًا يشغّله تطبيقك». فهو يكتب الطلب، وبرمجياتك تشغّله أو ترفضه. وقد جرى الاطلاع على جميع المصادر في هذه المقالة في 2 نوفمبر 2026.
يكرر الوكيل ذلك في حلقة. فهو يستدعي دالة، ويقرأ النتيجة، ويختار الخطوة التالية حتى تكتمل المهمة. ويصف منشور صدر عام 2024 على المدونة الهندسية لـ Anthropic الوكلاءَ بأنهم «عادةً مجرد نماذج LLM تستخدم الأدوات بناءً على التغذية الراجعة من البيئة، في حلقة». وLLM اختصار لعبارة large language model، أي النموذج اللغوي الكبير، والأدوات هي الدوال التي يستطيع استدعاءها.
لذا لا يستطيع الوكيل أن يفعل إلا ما تسمح به دواله. فقائمة الدوال هي وصفه الوظيفي، وهي أول وثيقة ينبغي أن تطلبها.
لماذا يهم أن يقرأ الوكيل البيانات أو يغيّرها؟
لأن القراءة لا تغيّر شيئًا. فإذا جلب الوكيل آخر خمس دفعات لعميل وأخطأ في إحداها، فالنتيجة مسودة خاطئة يستطيع شخص أن يكتشفها.
أما الكتابة فتغيّر شيئًا خارج النموذج: يُدفع مبلغ مسترد، أو تصل رسالة بريد إلى عميل. وبعض هذه التغييرات لا يمكن التراجع عنه.
يقترح دليل OpenAI لبناء الوكلاء تصنيف كل دالة على أنها منخفضة المخاطر أو متوسطتها أو عاليتها، «بناءً على عوامل مثل الوصول للقراءة فقط مقابل الوصول للكتابة، وإمكانية التراجع، وصلاحيات الحساب المطلوبة، والأثر المالي». ولا تبقى القراءة منخفضة المخاطر إلا ما دام الوكيل لا يستطيع إرسال ما قرأه إلى أي مكان. ويبيّن القسم الخاص بحقن الموجّهات، وهو حيلة تزرع تعليمات في بريد إلكتروني أو مستند، السبب في ذلك.
ما الإجراءات التي يستطيع الوكيل اتخاذها وحده، وما التي تحتاج إلى شخص؟
صنّف كل دالة في إحدى ثلاث مجموعات:
- الوكيل وحده: قراءة البيانات، والبحث في المستندات، ووضع الوسوم، وكتابة مسودات تبقى داخل أنظمتك إلى أن يستخدمها أحد
- الوكيل يقترح، وشخص يوافق: كل ما ينقل أموالًا، أو يغيّر سجل عميل أو وضعه، أو يرسل رسالة إلى خارج الشركة
- أبدًا: تغيير صلاحيات الوصول أو الحدود أو البيانات المصرفية، والقرارات التي تتوقع جهتك التنظيمية أن يتخذها شخص محدد بالاسم
أربعة أسئلة تحدد المجموعة لمعظم الدوال:
- هل يمكن التراجع عن الإجراء، ومن يستطيع ذلك؟
- هل ينقل أموالًا أو يغيّر ما يدين به العميل؟
- هل سيرى النتيجةَ عميلٌ أو شريك أو جهة تنظيمية؟
- هل ينص قانون، أو شرط في الترخيص، أو سياستك أنت، على أن شخصًا يجب أن يتخذ القرار؟
ويقدّم دليل OpenAI النصيحة نفسها للمجموعة الوسطى: «الإجراءات الحساسة، أو التي لا رجعة فيها، أو التي تنطوي على مخاطر عالية، ينبغي أن تستدعي إشرافًا بشريًا إلى أن تزداد الثقة في موثوقية الوكيل». ومن أمثلته «إلغاء طلبات المستخدمين، أو الموافقة على استردادات مالية كبيرة، أو إجراء مدفوعات».
تضم قائمة OWASP Top 10 for LLM Applications 2025، وهي قائمة بالمخاطر ينشرها مشروع OWASP الأمني، بندًا بعنوان الصلاحيات المفرطة (excessive agency). ويتناول هذا البند الضرر الذي يمكن أن يُحدثه وكيل لديه دوال أو صلاحيات أو حرية تفوق ما تحتاجه مهمته. ومن الضوابط التي يذكرها أن «يُشترط أن يوافق إنسان على الإجراءات عالية الأثر قبل اتخاذها».
كيف يبدو ذلك في الدعم وتسجيل العملاء الجدد والمدفوعات والتقارير؟
في كل مجال، يقرأ الوكيل ويكتب المسودات، ويحتفظ شخص بالقرارات. أما قائمتك أنت فتتوقف على أنظمتك وعلى ما تتوقعه جهتك التنظيمية.
- الدعم: يضع الوكيل الوسوم على التذاكر ويصوغ الردود. ويوافق شخص على كل رد في البداية، أما الاستردادات المالية والإعفاءات من الرسوم فتحتاج دائمًا إلى موافقة. ولا يغيّر الوكيل أبدًا البريد الإلكتروني للعميل أو رقم هاتفه، لأن من يتحكم بهما يستطيع إعادة تعيين بيانات دخول العميل
- تسجيل العملاء الجدد: يفحص الوكيل المستندات بحثًا عن الحقول الناقصة ويلخّصها للمحلل. وأي تغيير في تصنيف المخاطر ينتظر الموافقة، ويبقى قبول العميل في يد شخص
- المدفوعات: يطابق الوكيل بنود كشف الحساب المصرفي مع الفواتير ويشير إلى الفجوات. وتحرير دفعة محتجزة ينتظر الموافقة، أما البيانات المصرفية للمستفيد فليس للوكيل أن يغيّرها أبدًا
- التقارير: يصوغ الوكيل مسودة التقرير الشهري مع مصدر كل رقم. ويوافق شخص على كل ما يُرسل إلى عميل أو إلى مجلس الإدارة أو إلى جهة تنظيمية
أين ينبغي أن توضع خطوة الموافقة؟
ضع الموافقة في البرنامج الذي يشغّل الدالة، لا في الموجّه وحده، والموجّه هو مجموعة التعليمات التي يتلقاها النموذج. فالنموذج قد يتجاهل سطرًا في موجّهه، أو يُقنَع بالتخلي عنه. أما دالة الاسترداد التي لا تعمل دون نقرة من الموافِق فلا يمكن إقناعها بالتخلي عن أي شيء.
وتتفق إرشادات OWASP مع ذلك: «طبّق التفويض في الأنظمة اللاحقة بدلًا من الاعتماد على LLM ليقرر ما إذا كان الإجراء مسموحًا به أم لا».
شاشة الموافقة المفيدة تعرض على الموافِق ما يلي:
- الإجراء، والسجل الذي يغيّره، والمبلغ
- السجل قبل التغيير وبعده
- الأدلة التي استند إليها الوكيل، مثل التذكرة أو بند كشف الحساب
- سبب إلزامي في كل مرة يرفض فيها الموافِق
إذا كانت كل الاقتراحات تُقبل في غضون ثوانٍ، فهذا يعني أن الناس توقفوا عن التحقق. ولهذا اسم في EU AI Act: انحياز الأتمتة (automation bias). وتقول مادته الخاصة بالإشراف البشري إن الأشخاص الذين يشرفون على نظام عالي المخاطر يجب أن يظلوا قادرين على إدراك «النزعة المحتملة إلى الاعتماد التلقائي أو المفرط على المخرجات». أعِد التحقق من عيّنة من الإجراءات الموافَق عليها كل أسبوع.
ما الصلاحيات التي ينبغي أن يملكها حساب الوكيل؟
ينبغي أن يسمح حساب الوكيل بالدوال الموجودة في قائمته ولا شيء غيرها. وامنح كل وكيل حسابًا خاصًا به في كل نظام يتعامل معه، ولا تمنحه أبدًا حساب مسؤول نظام أو بيانات دخول موظف. واضبط هذه الصلاحيات في النظام نفسه، حيث لا يستطيع النموذج تغييرها. وتبقى كلمات المرور والمفاتيح في برمجياتك، بعيدًا عن نظر النموذج.
ومثال OWASP وكيل يوصي بالمنتجات و«قد لا يحتاج إلا إلى صلاحية قراءة لجدول “products”». وتحذّر OWASP أيضًا من الدوال المفتوحة، مثل تشغيل أي أمر على خادم، وتفضّل دوال ضيقة تؤدي كل واحدة منها شيئًا واحدًا.
حين يعمل الوكيل لصالح موظف واحد، ينبغي أن يتصرف، بتعبير OWASP، «في سياق ذلك المستخدم بعينه، وبالحد الأدنى من الصلاحيات اللازمة». وعندئذ لا يستطيع أن يرى أو يفعل أكثر مما يستطيعه ذلك الشخص.
ما حقن الموجّهات، ولماذا تزداد أهميته مع الوكلاء؟
حقن الموجّهات يعني زرع تعليمات في نص يقرؤه الوكيل، مثل بريد إلكتروني أو تذكرة أو مستند مرفوع. وقد يتبعها النموذج كأنها صادرة منك. ويمكن إخفاء هذه التعليمات عن القارئ البشري، ومع الوكيل قد تتحول إلى إجراءات. وتضع OWASP حقن الموجّهات في المرتبة الأولى في قائمتها لعام 2025، وتقول إنه «ليس واضحًا ما إذا كانت هناك أساليب مضمونة تمامًا للوقاية من حقن الموجّهات».
يصف بند OWASP الخاص بالصلاحيات المفرطة مساعدًا يقرأ صندوق بريد ليلخّص الرسائل الواردة. والإضافة التي يستخدمها تستطيع أيضًا إرسال الرسائل. فتخدعه رسالة مصمَّمة بعناية فيبحث في صندوق الوارد عن معلومات حساسة ويعيد توجيهها إلى المهاجم.
وتبدأ حلول OWASP بدالة لا تستطيع إلا قراءة البريد، وبصلاحية قراءة فقط لصندوق البريد. ويجب أيضًا على شخص أن «يراجع يدويًا كل رسالة صاغتها إضافة LLM ويضغط “إرسال” عليها». وبما أنه لا يمكن استبعاد حقن الموجّهات، فخطّط لوكيل جرى خداعه، وأبقِ الضرر الذي يمكن أن يُحدثه صغيرًا.
ماذا نسجّل، وكيف نتراجع عن خطأ؟
سجّل كل استدعاء لدالة. ويُظهر كل قيد الوكيلَ، والدالة ومدخلاتها، والنتيجة، والنص الذي أدى إلى الاستدعاء، وإصدار النموذج والموجّه، ومن وافق على الاستدعاء ومتى. وينبغي أن يستطيع شخص من خارج فريق البناء قراءة السجل ومعرفة ما حدث لعميل بعينه.
تشير OWASP إلى أن التسجيل وحدود المعدل لن تمنع الصلاحيات المفرطة، «لكنها قد تحدّ من مستوى الضرر الناتج». وحدّ المعدل يضع سقفًا لعدد الإجراءات من نوع واحد التي يستطيع الوكيل اتخاذها في مدة معينة، فتتوقف سلسلة الإجراءات الخاطئة مبكرًا.
قبل الإطلاق، اكتب كيف يُلغى أثر كل دالة تغيّر البيانات، ومن يتولى ذلك. وفضّل الدوال التي تُنشئ شيئًا معلّقًا، مثل استرداد مالي ينتظر في طابور. فالبند المعلّق يمكن حذفه، أما الدفعة المرسلة فيصعب استرجاعها. واحتفظ بمفتاح يوقف دوال الوكيل فورًا، دون إصدار جديد للبرنامج، واختبره قبل التشغيل الفعلي.
هل ينص القانون على أن شخصًا يجب أن يوافق؟
في الاتحاد الأوروبي، يضع AI Act قواعد للإشراف البشري على أنظمة الذكاء الاصطناعي التي يصنّفها عالية المخاطر. وترد هذه القواعد في المادة 14، ويُدرج الملحق III الاستخدامات عالية المخاطر. وتشمل القائمة تقييم الجدارة الائتمانية للأفراد أو تحديد درجتهم الائتمانية، مع استثناء الأنظمة التي تكشف الاحتيال المالي. وتشمل أيضًا تقييم المخاطر والتسعير للأفراد في التأمين على الحياة والتأمين الصحي. ويذكر مكتب الخدمة الخاص بـ AI Act (AI Act Service Desk) لدى المفوضية الأوروبية تاريخ 2 ديسمبر 2027 موعدًا لسريان قواعد الأنظمة عالية المخاطر الواردة في الملحق III. ويعكس هذا التاريخ تعديلات أدخلتها حزمة Digital Omnibus on AI. وقد تتغير مثل هذه التواريخ، لذا تحقّق من الجدول الزمني الحالي قبل أن تبني خططك عليه.
تقول المادة 14 إن تدابير الإشراف «يجب أن تتناسب مع المخاطر ومستوى الاستقلالية وسياق الاستخدام» الخاصة بالنظام. ويجب أن يكون الأشخاص الذين يشرفون عليه قادرين «على أن يقرروا، في أي حالة بعينها، عدم استخدام نظام الذكاء الاصطناعي عالي المخاطر، أو تجاهل مخرجاته أو تجاوزها أو عكسها بأي طريقة أخرى». ويجب أيضًا أن يتمكنوا من إيقافه عبر «زر “إيقاف” أو إجراء مماثل».
لا تنطبق هذه القواعد إلا على الأنظمة عالية المخاطر التي يُدرجها القانون، وكثير من الوكلاء في الدعم والعمليات لن يكونوا من بينها. ومع ذلك تظل الضوابط نفسها منطقية لهؤلاء الوكلاء. أما هل يخضع نظامك لهذه القواعد فمسألة يحسمها محاموك. وهذه المقالة ليست استشارة قانونية، ولا تتناول إلا قواعد الاتحاد الأوروبي.
كيف نبدأ دون أن نفقد السيطرة؟
ابدأ بأن تسأل هل تحتاج المهمة إلى وكيل أصلًا. يوصي المنشور الهندسي لـ Anthropic بـ«إيجاد أبسط حل ممكن، وعدم زيادة التعقيد إلا عند الحاجة»، ويضيف: «وقد يعني هذا عدم بناء أنظمة وكلاء على الإطلاق». ففي كثير من المهام، يكفي طلب واحد إلى النموذج أو تسلسل ثابت من الخطوات. كما أن التسلسل الثابت يتصرف على نحو يسهل التنبؤ به أكثر من وكيل يختار خطواته بنفسه.
اختر سير عمل واحدًا فيه حالات كثيرة كل أسبوع، وقواعد واضحة، وأخطاء يسهل إصلاحها بتكلفة قليلة، مثل فرز تذاكر الدعم وصياغة الردود. ثم تقدّم على مراحل:
- قِس سير العمل كما يجري اليوم: الوقت لكل حالة، ونسبة الحالات التي يُعاد العمل عليها، والأعمال المتراكمة كل أسبوع
- شغّل الوكيل في وضع الظل على حالات حقيقية. فهو يقترح، ويعمل الموظفون كما كانوا من قبل، وتقارن بين الاثنين
- انتقل إلى وضع الموافقة، حيث يوافق شخص على كل إجراء، وسجّل كم مرة يعدّل الموافقون أو يرفضون
- لا تدع الوكيل يتصرف وحده إلا في أنواع الإجراءات الأقل حاجةً إلى التصحيح، وواصل التحقق من عيّنة كل أسبوع
اتفق مسبقًا على الأرقام التي تنقل الوكيل إلى المرحلة التالية، وعلى من يتخذ القرار. ويُختتم دليل OpenAI بعبارة: «ابدأ صغيرًا، وتحقّق مع مستخدمين حقيقيين، ووسّع القدرات بمرور الوقت». ويوصي منشور Anthropic بـ«اختبار مكثّف في بيئات معزولة»، أي نسخة من أنظمتك لا تكلّف فيها الأخطاء شيئًا.
ما الذي نتحقق منه قبل تشغيل الوكيل فعليًا؟
- كل دالة تنتمي إلى إحدى المجموعات الثلاث، ولها مسؤول محدد بالاسم من جهتك
- جرّب أحدهم إجراءً محظورًا بحساب الوكيل في كل نظام، ورأى أنه فشل
- مرّت عبر الوكيل تذاكر ومستندات تحمل تعليمات مزروعة، ولم يحدث شيء خارج ما تسمح به المجموعات
- يُظهر السجل، لأي عميل، ما فعله الوكيل ومن وافق عليه
- لا يدخل إصدار جديد من النموذج الخدمة إلا بعد إعادة تشغيل الاختبارات نفسها
من يملك الكود والموجّهات والسجلات؟
ينبغي أن تملكها شركتك، وأن ينص العقد على ذلك. فالكود ليس إلا جزءًا من الوكيل. أما الموجّهات وقائمة الدوال وقواعد الموافقة وحالات الاختبار فهي التي تحدد سلوكه. فاذكرها كلها بوصفها مخرجات تسليم، تُحفظ على وسائط تخزين تتحكم بها شركتك.
تحتوي السجلات على بيانات العملاء، لذا تحتاج إلى قواعد الوصول نفسها ومدة الاحتفاظ نفسها اللتين تخضع لهما السجلات التي تصفها. وإن كان النموذج يعمل لدى مزوّد خارجي، فاسأل هل يخزّن ذلك المزوّد ما يرسله إليه الوكيل، ولأي مدة.
ماذا نسأل شركة تعرض أن تبنيه؟
- هل نستطيع أن نرى كل دالة سيستدعيها الوكيل، مع المجموعة التي تنتمي إليها كل واحدة؟
- أين تُفرض الموافقات: في أنظمتنا، أم في الكود الذي تكتبونه، أم في الموجّه فقط؟
- أي حساب يستخدمه الوكيل في كل نظام، وكيف اختبرتم أنه لا يستطيع فعل أكثر من ذلك؟
- كيف تختبرون حقن الموجّهات، وماذا يحدث حين ينجح أحد الاختبارات؟
- هل يستطيع فريق الامتثال لدينا قراءة السجل دون مساعدتكم؟
- كيف يُتراجَع عن كل إجراء، وبأي سرعة نستطيع إيقاف الوكيل؟
- ماذا نملك في النهاية: الكود، والموجّهات، وتعريفات الدوال، وحالات الاختبار، والسجلات؟
أين موقع amBrain من ذلك؟
تستخدم amBrain الوكلاء في منتجها الخاص. ويقول سطرها عن هذا المنتج: «منتجنا الخاص، shyash.ai، يعمل بوكلاء ذكاء اصطناعي يبحثون ويكتبون ويتحققون ويقيسون انطلاقًا من ذاكرة مشتركة واحدة لوقائع الشركة. ويوافق شخص على كل ما يصدر».
المشروع الوحيد المنفَّذ لعميل باستخدام النماذج اللغوية الذي تصفه amBrain علنًا هو التالي: «أوصلنا تكاملًا مع LLM إلى الإنتاج داخل محيط FinTech لدى أحد العملاء: استخراج إشعارات غير مهيكلة من الوسطاء ومنصات التداول وتطبيعها — إجراءات الشركات، وتغييرات الأدوات المالية والهامش — إلى سجلات مهيكلة يستهلكها نظام التداول».
هذه المقالة ليست دراسة حالة، ولا تصف أي عمل لعميل غير ما ورد في السطر أعلاه. وذلك السطر لا يقول شيئًا عن الوكلاء أو الموافقات، ولا تقول المقالة إن amBrain تبني أنظمة وكلاء للعملاء. والأمثلة المأخوذة من الدعم وتسجيل العملاء الجدد والمدفوعات والتقارير عامة، وليست مأخوذة من عمل amBrain.
الشركات والمنظمات المذكورة هنا مقتبسة من صفحاتها المنشورة. ولا تدّعي المقالة أي علاقة بين amBrain وأي منها، ولا تذكر أسعارًا أو جداول زمنية لـ amBrain.
تبني amBrain البرمجيات منذ عام 2019. وتعمل بثلاث صيغ: تسليم كامل، أو فريق مخصّص، أو مهندسون مدمجون في فريقك. أما في الملكية فسطرها هو: «يحتفظ العميل بالملكية الكاملة للمنتج وللكود، باستثناء مكوّناتنا القابلة لإعادة الاستخدام». والأسئلة أعلاه تنطبق على أي شركة تفكر فيها.
المواضيع
- وكلاء الذكاء الاصطناعي
- الموافقة البشرية
- حقن الموجّهات
- الامتثال