وزارة التنمية الرقمية الروسية والاتحاد الأوروبي وNIST يضعون قواعد جديدة لأمن AI وتنظيمه

نشرت Security Vision تحليلاً موسعاً حول الكيفية التي يتشكل بها بسرعة حول AI نظام جديد من القواعد والمعايير والممارسات الوقائية. وما يتقدم إلى الواجهة ليس القوانين فقط، بل أيضاً قضايا عملية جداً: تسرّب البيانات، وprompt injection، وسرقة النماذج، والتحكم في الأنظمة القائمة على الوكلاء.

كيف يُنظَّم AI

في روسيا، ما يزال المرسوم رقم 490 الصادر في 10 أكتوبر 2019 والاستراتيجية المحدَّثة لتطوير AI حتى عام 2030 هما نقطة المرجع الأساسية. ثم ظهر النظام التجريبي في موسكو، ومشروع مفهوم تنظيم AI حتى عام 2030 من وزارة التنمية الرقمية و“AI Alliance”، إضافة إلى مدونة الأخلاقيات الخاصة بالبنك المركزي للسوق المالية. والاتجاه العام واضح: تشجيع تبني AI، لكن مع المطالبة في الوقت نفسه بالشفافية، وحماية البيانات، وإدارة المخاطر، والإشراف البشري.

أما خارج روسيا، فيزداد الإطار صرامة. ففي الاتحاد الأوروبي دخل EU AI Act حيز التنفيذ بالفعل، مع تقسيم الأنظمة إلى مستويات مخاطر غير مقبولة وعالية وعادية: من الحظر المباشر للتصنيف الاجتماعي وبعض الممارسات البيومترية إلى logs إلزامية، وإشراف بشري، ومتطلبات للأمن السيبراني. وفي عام 2025، أطلقت الولايات المتحدة AI Action Plan مع تركيز على تسريع الابتكار، والبنية التحتية، وsecure by design. كما تعزّز الصين وسم المحتوى المرتبط بـ AI، واعتمدت كوريا الجنوبية وكازاخستان قوانينهما الخاصة، فيما تبني الأمم المتحدة واليونسكو وBRICS منصة دولية لقواعد مشتركة.

المعايير والضبط

بالتوازي مع القوانين، تنمو بسرعة طبقة من المعايير وframeworks. ففي ISO وIEC توجد بالفعل وثائق تتناول المصطلحات، وإدارة المخاطر، ودورة حياة AI، وتقييم المتانة، وأمن البيانات. وفي روسيا تقابلها معايير GOST جديدة، بينما يطوّر NIST في الولايات المتحدة AI Risk Management Framework، الذي أصبح واحداً من أبرز الأطر العملية للشركات. ومنطقه بسيط: لا تناقش AI في فراغ، بل ادمج المخاطر في الإدارة المعتادة للمنتج، والأمن، والتطوير.

• Govern — تعيين المسؤولين والسياسات والعمليات الخاصة بمخاطر AI
• Map — فهم السياق، وحالات الاستخدام، والضرر المحتمل
• Measure — التحقق من موثوقية تدابير الحماية وصحتها وفعاليتها
• Manage — ترتيب المخاطر حسب الأولوية، وتقليل الضرر، وتوثيق القرارات

كما تتشكل طبقة مستقلة من frameworks المتخصصة: إذ يقوم MITRE ATLAS بفهرسة تكتيكات الهجوم على AI، ويجمع OWASP المخاطر الحرجة الخاصة بـ LLM والأنظمة القائمة على الوكلاء، ويطوّر Google إطار SAIF، فيما ينشر كبار المورّدين frameworks الخاصة بهم في مجالَي safety وpreparedness.

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

أين يتعرّض AI للهجوم

لدى AI سطح هجوم خاص به. فالنماذج اللغوية الكبيرة لا تميّز جيداً بين البيانات والتعليمات، ولذلك يمكن لنص خبيث على صفحة ويب، أو في رسالة بريد إلكتروني، أو داخل مستند أن يتحول إلى أمر لوكيل. ومن هنا تنمو هجمات prompt injection المباشرة وغير المباشرة، وjailbreak، وextraction، وdata poisoning. وإذا كان النظام متصلاً بالبريد الإلكتروني، أو CRM، أو مخزن ملفات، أو خدمات خارجية، فإن كلفة الخطأ ترتفع بسرعة: فقد لا يكتفي المهاجم بالحصول على إجابة غريبة، بل قد يصل إلى بيانات الشركة أو يجبر الوكيل على تنفيذ إجراء غير مرغوب فيه.

والمنطقة الثانية الكبرى للمخاطر هي البيانات نفسها. فالشركات تواجه بشكل متزايد ظاهرة Shadow AI، أي حين يرفع الموظفون مستندات داخلية إلى chatbots عامة من دون تنسيق أو موافقة. وقد أوردت IBM تقديراً يفيد بأن 13% من الشركات التي شملها الاستطلاع أبلغت بالفعل عن تسريبات عبر AI. وإذا أضفت إلى ذلك سرقة مفاتيح API لأغراض LLM jacking، وإمكانية نسخ النماذج عبر distillation، ومشكلة الهلوسات على البيانات الاصطناعية، يصبح واضحاً لماذا لم تعد grounding وzero data retention وMLSecOps وDLP مجرد خيارات.

وثمة اتجاه آخر يتمثل في أن المهاجمين أنفسهم يستخدمون أدوات قائمة على الوكلاء لأتمتة الاختراق وخفض عتبة الدخول إلى الجريمة السيبرانية.

ماذا يعني ذلك

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