الأمن السيبراني والمرونة التشغيلية لأنظمة الذكاء الاصطناعي في اليمن

لماذا تحتاج AI إلى قراءة سيبرانية مختلفة؟

الذكاء الاصطناعي لا يلغي الأمن السيبراني التقليدي.

لكنه يضيف فوقه طبقة من المخاطر لا تظهر بالضرورة في تطبيق تقليدي.

نظام AI قد يكون محدثًا وخاليًا من ثغرات الويب المعروفة، ومع ذلك يفشل بسبب Prompt Injection أو Model Drift أو تسريب بيانات عبر السياق أو اعتماد غير مضبوط على مزود خارجي.

لذلك يجب التعامل مع AI Security باعتباره امتدادًا للأمن السيبراني وليس اسمًا بديلًا له.

الأساس اليمني القائم

السياسات العامة لأمن المعلومات في الجهات الحكومية الصادرة بقرار مجلس الوزراء رقم 59 لسنة 2020 تمثل المرجع الرسمي الأوضح المتحقق لدينا.

هذه السياسات لا تنظم AI بصورة متخصصة.

لكنها توفر نقطة بداية تتعلق بأمن المعلومات والحماية المؤسسية.

المسار الصحيح هو Mapping الضوابط القائمة على مكونات نظام AI ثم تحديد ما لا تغطيه.

🔴 مشروع قانون مكافحة جرائم تقنية المعلومات ليس قانونًا نهائيًا متحققًا

في أبريل 2026 أعلنت وزارة العدل وحقوق الإنسان اختتام اجتماعات اللجنة المشتركة لمراجعة مشروع قانون مكافحة جرائم تقنية المعلومات، ودعت اللجنة إلى سرعة إصدار المشروع بعد استيعاب الملاحظات.

هذه الصياغة تعني أن الوثيقة كانت لا تزال مشروع قانون في تلك المرحلة.

لذلك لا يجوز وصفها هنا بأنها قانون نافذ نهائي.

ولا ينبغي بناء Claims تنظيمية عليها كما لو أن جميع أحكامها أصبحت ملزمة.

الفرق بين الجريمة السيبرانية ومخاطر AI

الجريمة السيبرانية تتضمن أفعالًا مثل الاختراق والاحتيال والاعتداء على الأنظمة أو البيانات.

أما AI Risk فأوسع.

قد ينتج الضرر دون جريمة أصلًا.

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

قد تكون بياناته ضعيفة.

قد يعطي توصية خاطئة.

قد يعتمد الموظف عليه بصورة زائدة.

وقد يتغير المورد دون أن تلاحظ المؤسسة.

لذلك Cybercrime Regulation لا يساوي AI Governance.

الذكاء الاصطناعي كأداة للهجوم

يمكن استخدام GenAI لتوسيع قدرات المهاجم.

مثل:

صياغة رسائل تصيد أكثر إقناعًا.

توليد محتوى احتيالي.

تسريع البحث عن المعلومات.

أتمتة بعض مراحل الهندسة الاجتماعية.

أو إنتاج محتوى مزيف.

هذا لا يعني أن AI يجعل كل الهجمات جديدة.

لكنه يخفض تكلفة تنفيذ بعضها ويزيد سرعتها.

الذكاء الاصطناعي كأداة دفاع

يمكن كذلك استخدام AI في:

تحليل Logs.

ترتيب Alerts.

كشف أنماط.

تلخيص Incident Data.

مساعدة المحللين في البحث.

لكن أداة الدفاع نفسها تحتاج Governance.

إذا أعطيت نموذجًا وصولًا واسعًا إلى Security Logs فقد يحصل على بيانات شديدة الحساسية.

Prompt Injection

الأنظمة اللغوية تتعامل مع النص بطريقة تختلف عن التطبيقات التقليدية.

قد يحاول المهاجم إدخال تعليمات تغير سلوك النظام.

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

مستند.

موقع.

Email.

قاعدة معرفة.

لهذا لا يكفي Filter بسيط.

Tool Use

عندما يستطيع النموذج تنفيذ أدوات، يرتفع أثر Prompt Injection.

إذا كان Agent قادرًا على:

إرسال بريد.

تعديل سجل.

استدعاء API.

إنشاء مستخدم.

أو تشغيل Script.

فإن الخطأ لم يعد مجرد نص سيئ.

قد يصبح Action.

Least Privilege

AI Agent يجب ألا يحصل على صلاحيات واسعة لأنه "ذكي".

بل العكس.

كلما زادت قدرته على التصرف، زادت الحاجة إلى تقييد الصلاحيات.

الأداة يجب أن تصل فقط إلى ما تحتاجه لتنفيذ المهمة المحددة.

Human-in-the-Loop

الإجراء الحساس يمكن أن يحتاج إلى موافقة بشرية قبل التنفيذ.

المثال:

النظام يقترح حظر حساب.

لكن الموظف يراجع Evidence قبل تنفيذ الحظر.

هذا يفصل بين قدرة AI على التحليل وبين سلطة القرار.

RAG Poisoning

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

إدخال وثيقة مزيفة أو قديمة أو خبيثة قد يؤثر في إجابات النظام.

لذلك يجب التحكم في:

مصدر الوثائق.

الاعتماد.

التحديث.

والحذف.

Data Exfiltration

قد يحدث التسريب من خلال Prompt أو Response أو Logs أو Tool Call.

يجب أن تشمل مراقبة Data Loss Prevention قنوات AI.

الاعتماد على أن المستخدم "لن يكتب معلومات حساسة" ليس ضابطًا كافيًا.

الأسرار والمفاتيح

Model APIs تحتاج Credentials.

يجب أن تخزن داخل Secrets Management.

لا داخل Source Code.

ولا داخل ملفات Scripts مشتركة.

ولا داخل Prompt.

مفتاح مسرب قد يؤدي إلى استخدام غير مصرح أو تكلفة مالية أو وصول إلى بيانات.

Model Supply Chain

النظام قد يعتمد على Model لا تملكه المؤسسة.

ثم على Cloud Provider.

ثم على مكتبات.

ثم على Vector Database.

هذه Supply Chain.

المؤسسة تحتاج إلى معرفة المكونات الحرجة بدل التركيز فقط على Vendor المباشر.

مخاطر التحديث

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

قد تتغير:

الدقة.

طريقة الرفض.

السلوك.

الدعم اللغوي.

أو Safety Filters.

لذلك بعض التغييرات تحتاج إلى Re-test.

المرونة في بيئة اتصال غير مستقرة

في البيئات التي قد يتأثر فيها الاتصال الخارجي، يصبح الاعتماد الكامل على Model API خارجي مخاطرة تشغيلية.

السؤال ليس فقط:

هل النموذج جيد؟

بل:

ماذا يحدث عندما لا نستطيع الوصول إليه؟

الخدمة الحرجة تحتاج إلى جواب واضح.

Degraded Mode

قد لا تحتاج الخدمة إلى التوقف بالكامل.

يمكن أن تتحول إلى وضع أقل قدرة.

مثلاً:

إيقاف AI Recommendation.

مع استمرار Workflow اليدوي.

أو استخدام Search عادي بدل Assistant.

هذا يقلل أثر الانقطاع.

Local Fallback

بعض الحالات قد تبرر وجود مكون محلي أو Cached Capability.

لكن Local لا يعني تلقائيًا أفضل.

النموذج المحلي يحتاج:

تحديث.

حماية.

Compute.

Monitoring.

Skills.

ويجب تقييم الكلفة مقابل الحاجة.

Business Continuity

إذا أصبح AI جزءًا من عملية حرجة، يجب أن يدخل في BCP.

يجب تحديد:

RTO.

RPO عند وجود بيانات.

المورد البديل.

آلية العودة للعمل اليدوي.

ومن يقرر تعطيل النظام.

Single Point of Failure

قد يكون Model Provider نقطة فشل واحدة.

وقد يكون اتصال الإنترنت نقطة فشل.

وقد يكون Identity Provider.

وقد تكون Vector Database.

Architecture Review يجب أن تبحث عن الاعتماد المشترك.

Incident Response

AI Incident يمكن أن يكون:

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

استخدام غير مصرح.

Prompt Injection ناجح.

مخرجات خطرة.

Model Update غير متوقع.

أو Agent Action خاطئ.

كل نوع يحتاج إلى سيناريو استجابة.

الاحتواء

الإجراءات الممكنة تشمل:

تعطيل Key.

إيقاف Integration.

حظر Model Endpoint.

إيقاف Agent Tool.

إزالة Knowledge Source.

العودة إلى Manual Mode.

يجب أن تكون الإجراءات معروفة قبل الحادث.

الأدلة الرقمية

عند التحقيق نحتاج إلى Logs.

لكن يجب تصميم Logging بصورة متوازنة.

السجل يجب أن يساعد التحقيق دون أن يخزن تلقائيًا كل معلومة حساسة.

يمكن تسجيل Metadata بدلاً من المحتوى الكامل في بعض الحالات.

Forensics

في AI Forensics قد نحتاج إلى معرفة:

Model Version.

Prompt Template.

Tools.

Retrieved Documents.

Policy Decisions.

User Identity.

Timestamp.

هذه العناصر تساعد على إعادة بناء ما حدث.

AI Red Teaming

الاستخدامات الأعلى أثرًا تستحق اختبارات خصومية.

الفريق يحاول كسر الحدود قبل المهاجم.

لكن Red Teaming ليس اختبارًا لمرة واحدة.

كل تغيير كبير قد يعيد فتح سيناريوهات جديدة.

TEVV

TEVV يساعد على تقييم النظام خارج زاوية الأمن وحدها.

هل يعمل كما صمم؟

هل يلبي الغرض؟

هل يستمر الأداء؟

هل يفشل بصورة مقبولة؟

لا يجب تقديم TEVV كمتطلب قانوني يمني حالي.

إنه ممارسة حوكمة تقنية.

Cybersecurity Governance

الهدف ليس إنشاء فريق AI Security منفصلًا عن الأمن السيبراني.

الأكثر عقلانية هو إدخال AI إلى:

Risk Register.

Architecture Review.

Vendor Review.

Incident Response.

BCP.

Security Testing.

بهذا تصبح الحوكمة متكاملة.

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

مشروع قانون مكافحة جرائم تقنية المعلومات الذي كان قيد المراجعة في أبريل 2026 لا يجب عرضه كتشريع نهائي.

والسياسات العامة لأمن المعلومات لا يجب عرضها كـAI Security Framework.

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

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

ارسم Architecture.

حدد Assets.

اعرف كل Vendor.

اربط AI بـIAM.

قيد Tools.

اختبر Injection.

ضع Fallback.

أدخل AI في Incident Response.

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

الخلاصة

الأمن السيبراني هو نقطة البداية لأمن AI في اليمن، وليس نقطة النهاية.

قرار 59/2020 يوفر قاعدة رسمية يمكن البناء عليها.

لكن النماذج والـAgents وRAG وموردي AI يضيفون مخاطر جديدة.

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