لماذا لا يحمي الأمن السيبراني التقليدي أنظمة الذكاء الاصطناعي

تحمي كل شركة ثانية نشرت وكيل ذكاء اصطناعي أو نموذجًا لغويًا لديها هذا النموذج بالطريقة نفسها التي تحمي بها أي خدمة مصغّرة عادية: جدار ناري، وماسح للتبعيات، وسياسة صلاحيات. يبدو هذا معقولًا، لكنه في الواقع أشبه بتركيب باب معدني لمنزل تنقصه جدار كامل. وقد صاغ بوريس ماكاكوف، مهندس علم البيانات (Data Science) في Cloud.ru، في تحليله المنشور على Habr المشكلة التي يفضّل القطاع حتى الآن تجاهلها: DevSecOps التقليدي وأمن الذكاء الاصطناعي مساران مختلفان، ولا يغني أحدهما عن الآخر.

جوهر التباين بسيط، وهو في الوقت نفسه جوهري. فقد تشكّل DevSecOps على مدى عقود حول نموذج تهديدات واضح: هناك محيط، وتبعيات، وبنية تحتية، وصلاحيات وصول. إذا حميت كل طبقة من هذه الطبقات صار النظام آمنًا. أما نماذج الذكاء الاصطناعي فتُهاجَم بطريقة مختلفة تمامًا. فحقن الأوامر (prompt injection) يتيح للمهاجم الاستيلاء على التحكم في سلوك النموذج عبر نص مصمَّم خصيصًا. وتسميم بيانات التدريب يشوّه منطق اتخاذ القرار نفسه قبل وقت طويل من وصول النموذج إلى بيئة الإنتاج. أما التلاعب بالسياق فيدفع وكيل الذكاء الاصطناعي إلى تنفيذ إجراءات لم يتوقعها مطوّروه. ولا يمس أي من هذه الهجمات البنية التحتية بالمعنى التقليدي؛ فهي تضرب ما يجعل الذكاء الاصطناعي ذكاءً اصطناعيًا: البيانات، وقدرة النموذج على تفسيرها.

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

والخبر الجيد أن القطاع لا يقف مكتوف اليدين. فخلال العام والنصف الأخيرين ظهرت عدة وثائق مرجعية جادة تتيح بناء منظومة حماية عملية. فقد أصدرت OWASP قائمتي Top 10 منفصلتين للثغرات: إحداهما لتطبيقات LLM والأخرى للأنظمة الوكيلية (agentic). وقدمت Google إطار SAIF (Secure AI Framework) مع خريطة مخاطر تساعد الشركات على تقييم التهديدات بصورة منهجية. ووسّعت MITRE قاعدتها الشهيرة ATT&CK لتصبح مشروع ATLAS، الذي يفهرس تقنيات الهجوم الخاصة بأنظمة تعلّم الآلة. وتغطي كل أداة من هذه الأدوات مجالًا محددًا: فـOWASP تقدّم قائمة مراجعة بالثغرات المحددة، وSAIF منهجية لتقييم المخاطر، وATLAS لغة لوصف الهجمات وبناء نماذج التهديد.

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

والخلاصة العملية للشركات هي أن أمن الذكاء الاصطناعي ينبغي التعامل معه بوصفه مسارًا مستقلًا يُضاف فوق DevSecOps القائم، لا أن يُدمج فيه. وهذا يعني كفاءات منفصلة داخل الفريق، ومجموعة أدوات اختبار منفصلة، تشمل الاختبار الهجومي للنماذج (red teaming) والفحص ضد prompt injection وتدقيق بيانات التدريب، إضافة إلى نموذج تهديدات منفصل يراعي خصوصية تعلّم الآلة. وتوفّر أطر OWASP وSAIF وATLAS قاعدة كافية، بحيث لا حاجة إلى البدء من الصفر.

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