الأمن السيبراني وحوكمة الذكاء الاصطناعي في سوريا: من حماية البنية إلى أمن النماذج

استراتيجية الأمن السيبراني ليست إطار AI Security

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

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

هذه عناصر مهمة جدًا لـAI، لكنها لا تجيب وحدها عن أسئلة مثل Model Drift أو Prompt Injection أو Hallucination أو تسميم البيانات.

طبقة الأمن التقليدي

قبل مناقشة أمن النموذج، يجب حماية البيئة التي يعمل داخلها.

الحسابات الإدارية.

الأسرار.

مفاتيح API.

الشبكات.

Endpoints.

التخزين.

CI/CD.

النسخ الاحتياطية.

والسجلات.

كلها أهداف مباشرة.

نموذج آمن نظريًا يعمل على بنية مخترقة لا ينتج نظامًا آمنًا.

توسيع Threat Model

AI يغير حدود التهديد.

المستخدم لم يعد يرسل فقط قيمًا إلى نموذج برمجي تقليدي؛ قد يرسل لغة طبيعية قادرة على تغيير سلوك النظام.

وعندما يستطيع النموذج استخدام أدوات أو استدعاء قواعد بيانات أو إرسال رسائل أو تنفيذ Workflows، قد تتحول استجابة لغوية خاطئة إلى فعل حقيقي.

لذلك يجب أن يغطي Threat Model:

النموذج.

السياق.

الأدوات.

البيانات.

الهوية.

والمورد.

Prompt Injection

في الأنظمة المعتمدة على LLM، قد تحتوي وثيقة أو صفحة أو رسالة يجري تحليلها على تعليمات خبيثة تحاول التأثير في النموذج.

المشكلة أخطر عندما يكون النموذج متصلًا بأدوات.

الحماية لا تعتمد على Prompt سري أو عبارة تمنع التجاوز.

تحتاج إلى فصل الصلاحيات، Allow-list للأدوات، Validation للمدخلات والمخرجات، وعدم منح النموذج صلاحيات أكبر من المهمة.

Indirect Prompt Injection

الهجوم قد لا يأتي من المستخدم مباشرة.

قد توجد التعليمات الخبيثة داخل مستند أو موقع أو بريد يقوم النظام بقراءته.

هذه الحالة تجعل البيانات نفسها قناة محتملة للهجوم.

لذلك يجب الفصل قدر الإمكان بين التعليمات الموثوقة والمحتوى الذي تتم معالجته.

تسريب البيانات

قد يحدث التسريب عندما يرسل الموظف بيانات حساسة إلى خدمة خارجية، أو عندما يعرض النظام سياق مستخدم لمستخدم آخر، أو عندما تظهر معلومات في Logs.

لذلك يجب أن تغطي سياسات حماية البيانات قنوات AI وليس البريد والملفات فقط.

RAG ليس حلًا سحريًا

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

يجب حماية:

المستودع.

صلاحيات الاسترجاع.

Embeddings.

Metadata.

والوثائق التي تدخل إلى الفهرس.

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

تسميم البيانات

Data Poisoning لا يقتصر على Training Dataset.

يمكن أن يحدث أيضًا في Knowledge Base أو البيانات التي يستند إليها النظام في القرار.

لذلك يجب حماية عملية إدخال البيانات ومراجعة المصدر والتغييرات.

سلامة البيانات

Confidentiality ليست الهدف الوحيد.

إذا استطاع طرف تعديل سجل أو Dataset يستخدمها AI، فقد يغير النتيجة دون سرقة أي معلومة.

Integrity تصبح جزءًا من AI Assurance.

مخاطر المورد

عند استخدام نموذج خارجي، تتغير أجزاء من النظام دون سيطرة المؤسسة.

قد يحدث تحديث للنموذج أو شروط الخدمة أو مناطق المعالجة أو الخصائص الأمنية.

لهذا يجب أن تتضمن إدارة الموردين:

الإخطار بالتغييرات المهمة.

خطة خروج.

إدارة للحوادث.

وفهمًا لسلسلة الموردين.

Model Risk

قد يفشل النموذج دون وجود مهاجم.

يمكن أن ينخفض الأداء مع تغير البيانات.

قد يظهر سلوك غير متوقع في فئة محددة.

وقد يقدم إجابة واثقة خاطئة.

هذا هو سبب عدم كفاية Cybersecurity وحدها.

Model Risk Management تتعامل مع صلاحية النموذج وأدائه وحدوده وليس فقط مع اختراقه.

AI Assurance

ضمان AI يمكن أن يكون طبقة عملية بين التطوير والإنتاج.

الفكرة ليست ضمان الكمال.

الفكرة أن المؤسسة تستطيع تقديم Evidence على أن النظام اختبر ضمن سياقه، وأن حدوده معروفة، وأن هناك ضوابط ومراقبة وخطة عند الفشل.

TEVV

الاختبار والتقييم والتحقق والتثبت يجب أن يسبق الإنتاج ويستمر بعده.

يجب تصميم حالات اختبار من:

العمل الحقيقي.

الحالات الحدية.

سيناريوهات إساءة الاستخدام.

ومحاولات تجاوز الضوابط.

في GenAI يمكن قياس Groundedness والامتناع عند عدم المعرفة والتسريب ومقاومة الهجمات.

Red Teaming

Red Teaming للذكاء الاصطناعي يختلف عن اختبار اختراق تطبيق ويب فقط.

الفريق يحاول جعل النظام:

يكشف معلومات.

يتجاوز التعليمات.

يستخدم أدوات بصورة خاطئة.

يتعامل مع محتوى خبيث.

أو ينتج مخرجات خطرة.

لكن Red Team ليس بديلًا عن الاختبارات المنهجية.

هو طبقة إضافية لاكتشاف ما لم تتوقعه حالات الاختبار المعتادة.

الهوية والصلاحيات

يجب ألا يرث AI كل صلاحيات المستخدم أو الحساب الإداري.

كل Service تحتاج إلى هوية وصلاحيات محددة.

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

Least Privilege مهم جدًا عندما يستطيع AI تنفيذ Actions.

Agentic AI

الخطر يرتفع عندما ينتقل النظام من إعطاء نص إلى تنفيذ فعل.

Agent قد:

يرسل رسالة.

يغير سجلًا.

ينشئ طلبًا.

يستدعي API.

أو يبدأ Workflow.

كلما ارتفعت قدرة النظام على الفعل، يجب رفع مستوى الموافقة والقيود والمراقبة.

Human Approval

بعض Actions يجب أن تحتاج موافقة بشرية قبل التنفيذ.

وليس بعده.

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

Logging

سجل التدقيق يجب أن يسمح بفهم ما حدث دون أن يتحول هو نفسه إلى مستودع للبيانات الحساسة.

بحسب حالة الاستخدام قد نحتاج إلى:

هوية المستخدم.

إصدار النموذج.

الأدوات المستدعاة.

مصادر RAG.

نتيجة Policy Checks.

القرار النهائي.

والتصعيد البشري.

الاحتفاظ الكامل بكل Prompt بصورة دائمة ليس دائمًا الخيار الصحيح.

Incident Response

حادث AI قد لا يبدو كحادث سيبراني تقليدي.

قد يكون:

تسريب بيانات.

مخرجات ضارة واسعة النطاق.

قرارًا خاطئًا.

تغيرًا مفاجئًا في النموذج.

أو اكتشاف استخدام غير مصرح به لخدمة خارجية.

لذلك يجب توسيع تصنيف الحوادث وخطط الاستجابة لتشمل AI-specific incidents.

تصنيف الحوادث

ليست كل مشكلة AI حادثًا أمنيًا.

قد يكون الخلل بسبب:

بيانات.

نموذج.

مورد.

عملية.

أو هجوم.

لكن هذه المجالات قد تتداخل.

لذلك يجب ألا يعتمد التحقيق على فريق الأمن وحده.

Kill Switch

النظام عالي الأثر يحتاج إلى طريقة واضحة لتقليل الضرر.

قد يكون ذلك بإيقاف النموذج.

تعطيل أداة معينة.

الرجوع إلى Workflow يدوي.

تغيير النظام إلى وضع Read-only.

أو تعطيل Integration.

إذا لم تعرف المؤسسة كيف توقف النظام بأمان، فهي لم تكمل تصميم المرونة التشغيلية.

المرونة التشغيلية

الأمن لا يعني منع كل حادث.

يعني أيضًا قدرة المؤسسة على الاستمرار.

إذا توقف Model API الخارجي، ماذا يحدث؟

إذا تغير المورد؟

إذا تعطلت الهوية؟

إذا فقدت قاعدة RAG؟

يجب أن توجد سيناريوهات Fallback مناسبة لأهمية الخدمة.

الأطراف الثالثة وسلسلة التوريد

سلسلة AI قد تشمل:

Model Provider.

Cloud Provider.

Vector Database.

Plugins.

مكتبات مفتوحة المصدر.

وأدوات مراقبة.

تقييم المورد الرئيسي وحده لا يكشف الاعتماد الحقيقي.

يجب بناء Dependency Inventory يوضح المكونات الحرجة ونقاط الفشل والتعاقد من الباطن.

تحديث النموذج

النموذج الخارجي قد يتغير دون أن يتغير اسم المنتج.

هذا قد يغير:

الدقة.

السلوك.

رفض الطلبات.

أو طريقة التعامل مع المحتوى.

لذلك يجب تحديد أنواع التغيير التي تحتاج إلى Re-test أو Re-approval.

الأمن حسب مستوى الأثر

ليس كل AI بحاجة إلى الضوابط نفسها.

مساعد يراجع نصًا عامًا لا يساوي نظامًا يصل إلى بيانات شخصية أو يؤثر في خدمة حكومية.

النموذج القائم على المخاطر يسمح بتركيز الاختبارات والمراجعة الأمنية والاعتماد على الأنظمة التي يمكن أن تسبب أكبر ضرر.

العلاقة مع الاستراتيجية السورية

يمكن استخدام الاستراتيجية الوطنية للأمن السيبراني كطبقة أساس:

الحوكمة.

إدارة التهديدات.

القدرات.

البنية.

والحماية متعددة الطبقات.

لكن ضوابط AI-specific يجب إضافتها صراحة.

هذا يحافظ على دقة العلاقة:

نحن لا ننسب إلى الاستراتيجية متطلبات AI لم يتم التحقق من وجودها فيها، وفي الوقت نفسه لا نبني برنامج AI Security منفصلًا عن المنظومة السيبرانية الوطنية والمؤسسية.

ما الذي لا ينبغي استنتاجه؟

لا ينبغي وصف الاستراتيجية الوطنية للأمن السيبراني بأنها AI Security Framework.

ولا ينبغي الادعاء بأن سوريا فرضت TEVV أو Red Teaming أو Model Risk Framework محددًا دون مصدر رسمي.

هذه ممارسات نستخدمها تحليليًا لتحسين الحوكمة، لا متطلبات وطنية مثبتة حاليًا.

ماذا تفعل المؤسسة الآن؟

ابدأ من النظام الفعلي.

ارسم Architecture.

حدد Data Flows.

اعرف الموردين.

طبق Least Privilege.

اختبر Prompt Injection والتسرب.

أدخل AI في Incident Response.

ضع Fallback.

وأعد الاختبار عند التغيير.

هذه الخطوات لا تحتاج إلى انتظار إطار AI وطني متخصص.

الخلاصة

أمن AI ليس تخصصًا منفصلًا عن الأمن السيبراني، لكنه ليس مجرد اسم جديد له أيضًا.

البيئة السورية تملك أساسًا وطنيًا سيبرانيًا يمكن البناء عليه.

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

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