هل يستطيع نموذج التواصل في موقعك خداع وكيل الذكاء الاصطناعي؟

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

بحسب تقرير نشره موقع Forkast.news، كُشف عن سلسلة ثغرات باسم SalesBleed في Salesforce Agentforce. الفكرة التي يلفت إليها التقرير ليست مرتبطة باسم منصة واحدة فقط، بل بنمط معماري يتكرر في شركات كثيرة: نموذج ويب عام، وسجلات داخل نظام إدارة علاقات العملاء (CRM)، ووكيل ذكاء اصطناعي (AI Agent) يقرأ السجلات ويتصرف بناءً عليها. في هذه الحالة قد يكفي سجل ملوث قادم من نموذج عام لدفع الوكيل إلى تصرف غير آمن، دون أن يضغط موظف على رابط أو يفتح ملفًا.

نموذج الويب لم يعد مجرد صندوق رسائل

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

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

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

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

لا تعامل بيانات الجمهور كأنها أوامر داخلية

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

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

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

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

التصميم الآمن يبدأ من الفصل بين نوعين من النصوص:

• تعليمات النظام التي تضعها الشركة.
• بيانات العميل التي قد تكون مفيدة أو مضللة.

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

افصل الاستقبال عن التنفيذ

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

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

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

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

أمثلة على إجراءات تحتاج اعتمادًا بشريًا:

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

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

امنح الوكيل أقل صلاحية ممكنة

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

التصميم الصحيح يسأل سؤالًا آخر: “ما أقل صلاحية يحتاجها الوكيل كي يؤدي مهمة محددة؟”

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

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

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

قاعدة “أقل صلاحية” ليست تعقيدًا إداريًا. هي صمام أمان. عندما يحدث خطأ أو محاولة تلاعب، يكون الضرر محدودًا.

سجّل كل خطوة واختبر الهجمات قبل الإطلاق

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

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

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

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

أهم الخلاصات:

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

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