باحثون: لا يمكن تحصين نماذج اللغة ضد الاختراق نهائيًا

ما وجده الباحثون: تعليمات بلا هوية

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

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

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

لماذا لا يعرف النموذج من يخاطبه؟

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

لا يوجد في هذا التصميم فاصل صلب يقول للنموذج: هذا الجزء أمرٌ يُطاع، وهذا الجزء مجرد بيانات تُقرأ. الفصل بينهما ناتج عن التدريب والإقناع، لا عن حاجز هندسي.

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

لماذا يهمّك

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

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

والنتيجة أن ضمانات مثل "النموذج لا يفعل هذا أبدًا" و"لن يفصح عن هذه البيانات" تصبح احتمالات، لا وعودًا.

الوكيل الذي يقرأ بريدك هو نقطة الضعف الجديدة

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

• البريد والمستندات: نص مدسوس داخل ملف قد يُقرأ كتعليمات لا كمحتوى.
• الاسترجاع من قواعد المعرفة: أنظمة التوليد المعزّز بالاسترجاع تجلب نصوصًا من مصادر لا تسيطر عليها بالكامل.
• الصلاحيات: كل صلاحية تمنحها للوكيل تصبح صلاحية متاحة لمن ينجح في التلاعب به.

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

لماذا يقول الباحثون إن الإصلاح قد لا يأتي أبدًا

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

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

ولذلك يفترض أن يتحوّل السؤال من "هل النموذج آمن؟" إلى "ماذا يحدث حين يُخترق، ومن يوقف الضرر؟".

ما لم يذكره الخبر

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

كما لا تحدد النماذج التي جُرِّبت، ولا نسبة نجاح الهجوم، ولا إن كانت الشركات المعنية أصدرت تحديثات بعد إبلاغها. كل ذلك لم يُؤكَّد.

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

الدفاع بالطبقات: أفضل الموجود، وليس حلًا نهائيًا

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

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

الإشراف البشري هنا ليس ترفًا تنظيميًا، بل آخر خط دفاع عملي أمام ثغرة لا تُغلق.

بالنسبة للمنطقة العربية

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

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

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

ما يمكن فعله اليوم بشكل عملي:

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

الخلاصة

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

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