سياسات أمن المعلومات الحكومية في اليمن وحوكمة الذكاء الاصطناعي: من القرار 59/2020 إلى مخاطر النماذج

الوثيقة الأساسية

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

تغطي الوثيقة أمن المعلومات في الجهات الحكومية.

ولا ينبغي إعادة توصيفها بأنها AI Security Framework.

لكنها توفر قاعدة مفيدة يمكن البناء عليها عند تشغيل أنظمة AI داخل البيئة الحكومية.

لماذا تبقى السياسات ذات صلة؟

الذكاء الاصطناعي لا يلغي أساسيات أمن المعلومات.

النظام ما يزال يعتمد على:

هوية.

أجهزة.

شبكات.

خوادم.

قواعد بيانات.

صلاحيات.

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

وسجلات.

أي ضعف في هذه الطبقات ينتقل إلى AI.

الفرق بين Information Security وAI Security

أمن المعلومات يركز على حماية:

السرية.

السلامة.

والتوافر.

AI Security يحتاج إلى هذه المبادئ، لكنه يضيف أسئلة أخرى.

هل يمكن خداع النموذج؟

هل يمكن تسميم المعرفة؟

هل يستطيع المستخدم جعل Agent ينفذ أمرًا غير مسموح؟

هل يتغير السلوك بعد تحديث النموذج؟

هل يكشف النظام محتوى من سياق مستخدم آخر؟

إدارة الهوية

كل خدمة AI يجب أن تستخدم هوية محددة.

لا يجب أن يعمل Model Service بحساب Administrator لمجرد سهولة التطوير.

المبدأ الصحيح هو Least Privilege.

كل خدمة تحصل فقط على الصلاحيات التي تحتاجها.

الحسابات الخدمية

Service Accounts تمثل خطرًا إذا أصبحت مشتركة بين عدة تطبيقات.

يجب أن يكون لكل مكون Credential يمكن تتبعه وإلغاؤه وتدويره.

إذا تم اختراق أحد المكونات، لا ينبغي أن يمتد الوصول تلقائيًا إلى بقية البيئة.

مفاتيح API

مفاتيح النماذج الخارجية أصبحت Secrets مهمة.

يجب ألا توجد داخل:

الكود.

Repositories العامة.

Scripts مشتركة.

أو ملفات المستخدم.

يجب إدارتها داخل Secrets Management مناسب.

Prompt Injection

النموذج اللغوي قد يفسر النص كتعليمات.

هذا يخلق نوعًا جديدًا من الهجوم.

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

وقد تحتوي وثيقة خارجية على تعليمات خبيثة.

لا يوجد Prompt مثالي يمنع هذا الخطر.

الحماية تحتاج إلى Architecture وPermissions وValidation.

Indirect Prompt Injection

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

هذا مهم خصوصًا في RAG أو Agents.

المحتوى الخارجي يجب ألا يحصل على سلطة مساوية لـSystem Instructions.

RAG Security

قاعدة المعرفة قد تصبح جزءًا من سطح الهجوم.

يجب ضبط:

من يضيف الوثائق؟

من يعدلها؟

من يراها؟

هل يستطيع مستخدم استرجاع مستند ليس من صلاحياته؟

كيف تزال الوثيقة القديمة؟

تسميم مصادر المعرفة

إذا أُدخلت وثيقة مضللة أو خبيثة إلى Knowledge Base، قد تصبح الإجابات خاطئة بصورة ممنهجة.

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

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

النظام قد يسرب البيانات عبر:

Prompt.

Output.

Logs.

RAG.

Context.

أو Vendor API.

يجب رسم كل مسار للبيانات.

Logs

السجلات ضرورية للأمن والتحقيق.

لكن تسجيل كل Prompt وResponse إلى الأبد قد يخلق مستودعًا ضخمًا من البيانات الحساسة.

يجب تحديد ما يحتاج إلى التسجيل ومدة الاحتفاظ ومن يستطيع الوصول.

أثر التدقيق

Audit Trail للأنظمة المؤثرة يجب أن يربط:

المستخدم.

الوقت.

النظام.

الإصدار.

البيانات.

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

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

هذه المعلومات تساعد على التحقيق بعد الحادث.

Model Risk

قد يكون النظام آمنًا من الاختراق لكنه غير موثوق من ناحية الأداء.

Model Risk تشمل:

سوء الملاءمة للغرض.

انخفاض الأداء.

الانحياز.

تغير البيانات.

واستخدام النموذج خارج نطاقه.

لذلك لا يجب اختزال AI Risk في Cybersecurity.

Hallucination

GenAI قد ينتج معلومات غير صحيحة دون وجود هجوم.

في الأنظمة الحكومية قد يتحول الخطأ إلى معلومة رسمية إذا لم توجد مراجعة.

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

AI Assurance

يمكن بناء بوابة AI Assurance قبل Production.

تسأل:

هل النظام اختبر؟

هل هناك Threat Model؟

هل البيانات معروفة؟

هل الحدود موثقة؟

هل المورد مقيم؟

هل الإشراف واضح؟

هل توجد خطة للحوادث؟

TEVV

Testing, Evaluation, Verification and Validation يضيف طبقة أعمق من اختبار البرمجيات العادي.

لا نختبر فقط هل النظام يعمل.

بل هل يعمل بصورة مناسبة للغرض وفي الظروف الواقعية.

هذا ليس متطلبًا يمنيًا مثبتًا في قرار 59/2020.

هو ممارسة إضافية مناسبة لـAI.

Red Teaming

الأنظمة الأعلى أثرًا تستفيد من اختبارات خصومية.

يحاول الفريق:

تجاوز السياسات.

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

خداع النموذج.

إساءة استخدام Tools.

أو الوصول إلى معلومات محظورة.

لكن Red Teaming لا يستبدل Secure Development أو الاختبارات العادية.

Agents

عندما يستطيع AI تنفيذ فعل، يرتفع الخطر.

قد يرسل Email.

يعدل سجلًا.

ينفذ API Call.

أو يصدر Workflow.

كل Action حساس يجب أن يملك حدودًا واضحة.

Human Approval

يمكن السماح للنظام باقتراح الإجراء.

لكن التنفيذ قد يحتاج موافقة بشرية.

خصوصًا عندما يؤثر في بيانات أو حقوق أو أموال أو خدمة مهمة.

الموردون

Model Provider يصبح جزءًا من الأمن.

يجب معرفة:

كيف يحمي البيانات؟

ما شروط الاحتفاظ؟

كيف يبلغ عن الحوادث؟

هل توجد Subprocessors؟

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

سلسلة التوريد

قد يعتمد التطبيق على:

Cloud.

Model API.

Open-source libraries.

Vector Database.

Plugins.

Monitoring.

يجب معرفة نقاط الاعتماد الحرجة.

Incident Response

سياسات أمن المعلومات تتضمن منطق التعامل مع الحوادث.

AI يحتاج توسيع سيناريوهات الحوادث.

مثل:

Prompt Injection ناجح.

تسريب Context.

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

تحديث Model تسبب بسلوك خطر.

أو Agent نفذ Action خاطئًا.

الاحتواء

الاستجابة تحتاج أدوات فنية.

يمكن أن تشمل:

تعطيل Model API.

سحب Key.

إيقاف Tool.

حظر Data Source.

العودة إلى Workflow يدوي.

أو عزل الخدمة.

يجب اختبار إجراءات الاحتواء قبل الحاجة إليها.

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

بيئة الاتصالات والبنية الرقمية تجعل Resilience مهمة بصورة خاصة.

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

قد يحتاج النظام إلى Cached Data أو Local Fallback أو Manual Process.

Business Continuity

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

لا ينبغي أن يصبح مزود نموذج واحد Single Point of Failure دون أن تعرف الإدارة ذلك.

إدارة التغيير

كل تغيير مهم قد يحتاج مراجعة جديدة.

Model Version.

Prompt.

RAG Source.

Tool.

Vendor.

Dataset.

أو Permission.

الاعتماد السابق لا يجب أن يغطي تغييرًا جذريًا تلقائيًا.

العلاقة مع قرار 59/2020

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

لكن ضوابط AI-specific يجب إضافتها فوقها.

المسار الصحيح هو Mapping بين Controls الحالية والمخاطر الجديدة.

وليس إعادة تسمية السياسات الحالية على أنها AI Security Regulation.

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

لا ينبغي الادعاء أن قرار 59/2020 ينظم Prompt Injection أو Model Risk أو TEVV إلا إذا ورد ذلك فعليًا في النص.

هذه مفاهيم نضيفها تحليليًا كي تصبح الحوكمة مناسبة للأنظمة الحديثة.

ماذا تفعل الجهة الحكومية الآن؟

ابدأ من السياسات الموجودة.

اربط أنظمة AI بها.

ثم حدد الفجوات.

أضف AI Threat Modeling.

Vendor Review.

Model Testing.

Human Oversight.

Incident Scenarios.