الأمن السيبراني وحوكمة أنظمة الذكاء الاصطناعي في لبنان: من استراتيجية 2019 إلى الأطر والسياسات الناشئة في 2026

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

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

هي تضيف طبقة جديدة فوقها.

النظام ما يزال يعتمد على شبكات، وهويات، وواجهات، وحسابات خدمة، وقواعد بيانات، وسحابة، وموردين.

لكن AI يضيف أيضًا مكونات جديدة مثل:

النموذج.

بيانات التدريب أو الاسترجاع.

Prompt.

Vector Stores.

Model APIs.

وسلاسل اعتماد جديدة على مزودي النماذج.

لهذا فإن أمن AI يجب أن يندمج داخل برنامج الأمن السيبراني، لا أن يعيش كمسار منفصل بالكامل.

الأساس الوطني: استراتيجية الأمن السيبراني 2019

لبنان لديه استراتيجية وطنية للأمن السيبراني منشورة رسميًا من رئاسة مجلس الوزراء منذ 2019.

هذه الاستراتيجية تمثل أساسًا وطنيًا للأمن السيبراني.

لكن يجب الحفاظ على الفرق الوظيفي:

هي استراتيجية للأمن السيبراني وليست AI Security Framework مستقلًا.

قيمتها بالنسبة إلى AI تأتي من كون أنظمة AI جزءًا من البيئة الرقمية التي يجب أن تخضع للحوكمة الأمنية والاستجابة للحوادث والمرونة وإدارة المخاطر.

المشهد تغير منذ 2019

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

المؤسسة لم تعد تحمي فقط خادمًا وتطبيقًا وقاعدة بيانات.

قد تحتاج أيضًا إلى حماية:

بيانات الاسترجاع.

أوامر النظام.

واجهات النماذج.

سجلات المحادثات.

مفاتيح API.

نماذج داخلية.

ومكونات طرف ثالث.

هذا يفسر لماذا تظهر في 2026 أدوات تنظيمية وسيبرانية جديدة داخل خارطة MITAI.

🔴 مشروع قانون الأمن السيبراني

خارطة MITAI الرسمية تصنف Cybersecurity Law على أنه:

Drafted for Submission

أي أنه مشروع معد للتقديم.

لا يمثل حتى تاريخ التحقق قانونًا نافذًا.

لذلك يجب ألا تُنسب إليه التزامات قانونية نهائية.

تعرض خارطة MITAI المشروع باعتباره أداة تهدف إلى تعزيز الحوكمة الوطنية للأمن السيبراني والإبلاغ عن الحوادث.

هذه إشارة تنظيمية مهمة، لكنها ليست بديلًا عن النص القانوني النهائي عند صدوره.

🔴 إطار الجاهزية السيبرانية

Cyber Readiness Framework مصنف رسميًا:

Currently Under Consultation

أي أنه قيد الاستشارة وغير نهائي.

خارطة MITAI تربطه ببناء Baseline لتحسين الوضع السيبراني.

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

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

🔴 الإطار الوطني للذكاء الاصطناعي

National AI Framework أيضًا:

Currently Under Consultation

وتعرضه MITAI كإرشاد للتبني الآمن والقابل للمساءلة للذكاء الاصطناعي.

هذه الوثيقة مهمة بصورة مباشرة لـAI Governance.

لكن وضعها الحالي يعني أن تفاصيلها قابلة للتعديل.

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

🔴 إرشادات الخصوصية والأمن

Privacy & Security Guidelines موجودة أيضًا تحت الاستشارة.

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

هذا يجعلها ذات صلة مباشرة بالخدمات التي تستخدم AI.

لكنها:

ليست نهائية.

ولا تحل محل قانون 81/2018.

ولا تمثل Regulation نافذًا حتى الآن.

يجب التعامل معها كإشارة إلى اتجاه تنظيمي قيد التطوير.

لماذا حالة الوثيقة جزء من الأمن؟

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

يمكن أن ينتج عنه قرار أمني أو تعاقدي أو قانوني خاطئ.

المؤسسة قد تبني Control أو عقدًا أو تقييم امتثال على متطلب لم يصبح نافذًا أصلًا.

لذلك فإن Regulatory Status نفسه يجب أن يكون جزءًا من Governance Metadata.

سطح الهجوم في AI

سطح هجوم AI أوسع من التطبيق التقليدي.

يمكن مهاجمة:

الهوية.

الواجهة.

النموذج.

البيانات.

الـPrompt.

الـPlugins.

RAG Sources.

المورد الخارجي.

وآلية المراقبة نفسها.

لهذا يجب رسم Architecture كاملة قبل تقييم الأمن.

Prompt Injection

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

Prompt Injection لا يشبه SQL Injection تمامًا.

المشكلة أن النموذج نفسه مصمم لتفسير اللغة.

لذلك لا يمكن حل الخطر فقط بفلتر كلمات بسيط.

يجب استخدام طبقات دفاع متعددة.

Indirect Prompt Injection

الخطر لا يأتي فقط من المستخدم.

قد يقرأ النظام:

صفحة ويب.

وثيقة.

بريدًا.

ملفًا.

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

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

لذلك يجب اعتبار مصادر الاسترجاع جزءًا من سطح الهجوم.

RAG Security

أنظمة Retrieval-Augmented Generation تعتمد على مصادر خارجية أو داخلية.

يجب ضبط:

من يستطيع إضافة الوثائق؟

من يستطيع تعديلها؟

ما تاريخ المصدر؟

هل المصدر موثوق؟

هل البيانات حساسة؟

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

RAG غير محكوم يمكن أن يتحول إلى قناة لإدخال بيانات أو تعليمات غير موثوقة.

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

Data Poisoning يعني التأثير في البيانات المستخدمة لتدريب النظام أو تغذيته.

قد يكون التلاعب متعمدًا أو نتيجة ضعف في جودة البيانات.

في الحالتين، النتيجة واحدة:

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

لهذا يجب حماية Data Pipeline مثلما نحمي Application Pipeline.

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

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

Integrity مهمة بنفس القدر.

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

يجب مراقبة:

المصدر.

التغييرات.

التوقيعات أو hashes عند الحاجة.

والصلاحيات.

سرقة النماذج

النموذج نفسه قد يكون أصلًا مهمًا.

في النماذج الداخلية قد توجد مخاطر تتعلق بسرقة:

Weights.

Prompts.

Fine-tuning Data.

Configuration.

أو منطق الملكية الفكرية.

الحماية يجب أن تختلف حسب قيمة النموذج وطريقة تشغيله.

تسرب البيانات عبر المخرجات

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

قد يحدث ذلك بسبب:

صلاحيات سيئة.

RAG غير مفصول.

Context مشترك.

Training leakage.

أو Prompt Injection.

لذلك يجب اختبار Data Leakage بصورة مقصودة.

التحكم في الوصول

القاعدة الأساسية هي Least Privilege.

لا يحتاج كل نموذج إلى الوصول لكل البيانات.

ويجب أن نفصل بين:

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

هوية التطبيق.

هوية النموذج أو الخدمة.

وصلاحية مصدر البيانات.

هذا يمنع انتقال صلاحية المستخدم تلقائيًا إلى كل مكونات النظام.

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

Service Accounts غالبًا تحصل على صلاحيات واسعة لأنها تعمل في الخلفية.

هذه ممارسة خطرة.

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

الحساب المشترك يجعل التحقيق أصعب.

إدارة الأسرار

API Keys ومفاتيح النماذج يجب ألا توضع في:

الكود.

المستندات.

Repositories العامة.

أو Prompt.

يجب استخدام Secrets Management مناسب.

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

سجلات AI

Logs ضرورية للتحقيق.

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

قد تحتوي:

Prompts.

Responses.

Identifiers.

System Instructions.

أو Metadata.

لذلك يجب تحديد ما نسجل، ولأي مدة، ومن يستطيع الوصول.

أثر التدقيق

Audit Trail يجب أن يسمح بربط:

المستخدم.

الطلب.

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

البيانات.

الأدوات التي استدعاها.

النتيجة.

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

هذا مهم عندما يكون النظام قادرًا على تنفيذ Actions وليس فقط إنتاج نص.

Agentic AI

الأنظمة الوكيلية Agentic AI ترفع مستوى الخطر.

النظام قد:

يرسل رسالة.

يعدل سجلًا.

يستدعي API.

ينفذ خطوة.

أو يبدأ Workflow.

كل صلاحية تنفيذ يجب أن تخضع لحدود وموافقات مناسبة.

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

Human-in-the-Loop

الموافقة البشرية مفيدة في العمليات الحساسة.

لكنها يجب أن تكون في النقطة الصحيحة.

إذا وافق الإنسان بعد تنفيذ الفعل، فلا قيمة حقيقية للموافقة.

يجب تحديد Actions التي تحتاج Pre-Approval قبل التنفيذ.

Model Supply Chain

النموذج الخارجي جزء من سلسلة التوريد.

يجب معرفة:

المزود.

الإصدار.

طريقة التحديث.

مكان المعالجة.

المعالجات الفرعية.

سياسة الاحتفاظ.

وسجل الحوادث.

لا يكفي تقييم واجهة المنتج فقط.

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

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

هذا قد يغير:

السلوك.

الدقة.

الرفض.

الأمان.

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

لذلك يجب مراقبة Model Changes عندما يكون النظام مهمًا.

الاعتماد على المورد

إذا كانت خدمة حرجة تعتمد على Model API واحد، فهذا Concentration Risk.

يجب التفكير في:

Fallback.

Provider Exit.

Model Portability.

أو مسار يدوي.

المرونة جزء من الأمن.

السحابة

MITAI تضع Cloud ضمن البنية الرقمية الوطنية.

Cloud Security وAI Security مترابطان.

كثير من AI workloads تعمل أصلًا فوق بيئات سحابية.

لذلك يجب مراجعة:

IAM.

Network Segmentation.

Encryption.

Logging.

Data Residency.

Backups.

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

نقل البيانات عبر الحدود

AI APIs قد تؤدي إلى معالجة خارج لبنان.

المؤسسة يجب أن تعرف:

ما البيانات التي تخرج؟

إلى أين؟

لماذا؟

من يعالجها؟

هل تُحتفظ بها؟

وهل تستخدم في تدريب أو تحسين الخدمة؟

هذا موضوع Privacy وSecurity معًا.

الاستجابة للحوادث

حادث AI قد يكون مختلفًا عن Malware تقليدي.

قد يكون:

تسريبًا داخل Response.

Prompt Injection ناجحًا.

تغييرًا في Model Behavior.

تلاعبًا في RAG.

إجراء Agent غير مصرح.

أو انحرافًا أدى إلى نتائج خاطئة واسعة.

خطة Incident Response يجب أن تعرف هذه السيناريوهات.

تصنيف حادث AI

ليس كل خطأ Incident أمني.

قد يكون Model Risk أو Data Quality أو Operational Failure.

لكن بعض الحالات تتداخل.

مثال:

نتائج خاطئة بسبب Dataset تم التلاعب بها.

هنا المشكلة Data + Security + Model Risk.

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

الاحتواء

عند وقوع حادث يجب أن تكون هناك آليات لعزل النظام.

قد تشمل:

تعطيل Tool.

حظر مصدر RAG.

سحب Credential.

العودة إلى نموذج سابق.

تحويل العملية إلى Manual.

أو إيقاف الخدمة.

Containment يجب أن يكون قابلًا للتنفيذ بسرعة.

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

الأمن لا ينتهي عند منع الهجوم.

المؤسسة يجب أن تستمر.

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

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

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

إذا فقدت قاعدة الاسترجاع؟

المرونة تتطلب سيناريوهات وتمارين.

الاختبار الأمني

اختبار AI يحتاج أكثر من Vulnerability Scan.

يمكن أن يشمل:

Adversarial Prompts.

Privilege Escalation attempts.

RAG poisoning tests.

Data leakage tests.

Tool abuse.

Model extraction attempts.

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

Red Teaming

Red Teaming مفيد للأنظمة عالية الأثر.

لكن يجب أن يكون Scenario-Based.

لا يكفي البحث عن إجابة "غريبة".

يجب اختبار ما إذا كان النظام يستطيع إحداث ضرر واقعي ضمن الصلاحيات التي يملكها.

أمن GenAI للموظفين

أحد أكثر المخاطر شيوعًا ليس هجومًا معقدًا.

هو استخدام الموظف أداة عامة وإرسال بيانات لا يجب إرسالها.

لذلك تحتاج المؤسسة إلى:

قائمة أدوات معتمدة.

سياسة بيانات.

تدريب.

Controls تقنية عند الحاجة.

ومسار طلب سريع للأدوات الجديدة.

Shadow AI

إذا كانت الأدوات الرسمية سيئة أو الإجراءات بطيئة، سيستخدم الناس بدائل شخصية.

هذا يجعل الحظر وحده غير كافٍ.

يجب جعل المسار الآمن عمليًا وقابلًا للاستخدام.

Secure by Design

الأمن يجب أن يبدأ من التصميم.

قبل اختيار النموذج يجب معرفة:

حالة الاستخدام.

البيانات.

الأثر.

الاعتماديات.

الصلاحيات.

المورد.

وآلية الفشل.

إضافة الأمن بعد اكتمال البنية غالبًا أكثر تكلفة وأقل فاعلية.

Privacy by Design

AI Security وPrivacy يتداخلان.

تخفيض كمية البيانات يقلل أثر الاختراق.

فصل البيانات يقلل التسرب.

تحديد الاحتفاظ يقلل مساحة الخطر.

لذلك يجب ألا تعمل فرق الأمن والخصوصية كمسارين منفصلين.

Cyber Readiness

إطار الجاهزية السيبرانية الموجود تحت الاستشارة يشير إلى اتجاه نحو Baseline أكثر تنظيمًا.

لكن حتى صدوره نهائيًا، يجب ألا تدعي المؤسسة "الامتثال" له باعتباره معيارًا نهائيًا.

يمكن استخدامه داخليًا كمصدر استرشادي فقط إذا كان النص متاحًا وواضحًا، مع توثيق أنه غير نهائي.

National AI Framework

الإطار الوطني للذكاء الاصطناعي قيد الاستشارة يمكن أن يخلق لاحقًا جسرًا بين AI Governance والأمن.

لكن حتى صدور النسخة النهائية يجب إبقاء الفصل واضحًا بين:

الممارسات المقترحة.

والمتطلبات المعتمدة.

هذا مهم خصوصًا في تقارير الامتثال.

Security Governance Model

يمكن أن تتوزع المسؤوليات كالتالي:

CISO أو وظيفة الأمن: المخاطر الأمنية والاختبارات والاستجابة.

AI Owner: الغرض والأداء والاستخدام.

Data Owner: الوصول والجودة.

Business Owner: القرار والأثر.

Vendor Management: الطرف الثالث.

Legal/Privacy: المعالجة والالتزامات.

هذه المسؤوليات يجب أن تتقاطع دون أن تذوب في بعضها.

بوابة أمن AI

قبل الإنتاج، يجب مراجعة:

Architecture.

Data Flow.

Identity.

Permissions.

Model Provider.

RAG Sources.

Tools.

Logging.

Threat Model.

Incident Plan.

Fallback.

كل نظام لا يحتاج المستوى نفسه، لكن النظام العالي الأثر يحتاج مراجعة أعمق.

Threat Modeling

Threat Model يجب أن يبدأ من أصول النظام.

ما الذي نحميه؟

بيانات؟

قرار؟

نموذج؟

خدمة؟

هوية؟

ثم نحدد المهاجم ومسارات الهجوم والأثر.

هذا أكثر فائدة من قائمة Controls موحدة لكل مشروع.

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

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

ولا ينبغي وصف مشروع قانون الأمن السيبراني بأنه قانون نافذ.

ولا ينبغي وصف Cyber Readiness Framework بأنه نهائي.

ولا ينبغي وصف National AI Framework بأنه معتمد.

ولا ينبغي وصف Privacy & Security Guidelines بأنها لائحة نافذة.

هذه الفروق جزء من النزاهة التنظيمية للمحتوى.

ماذا يجب أن تفعل المؤسسة الآن؟

يمكن للمؤسسة اللبنانية أن تبدأ دون انتظار انتهاء كل الاستشارات.

أولًا، حصر أنظمة AI.

ثانيًا، تصنيفها حسب الأثر.

ثالثًا، رسم Architecture وData Flows.

رابعًا، إجراء Threat Modeling.

خامسًا، تقليل الصلاحيات.

سادسًا، تقييم الموردين.

سابعًا، اختبار سيناريوهات AI-specific.

ثامنًا، ربط Incident Response بالأنظمة الجديدة.

وتاسعًا، مراقبة تطور الأطر اللبنانية غير النهائية وتحديث الضوابط عند اعتمادها.

الخلاصة التنفيذية

المشهد اللبناني للأمن السيبراني في 2026 لم يعد مقتصرًا على استراتيجية 2019.

هناك طبقة جديدة من التطوير التنظيمي تقودها MITAI:

🔴 مشروع قانون للأمن السيبراني ما يزال في مرحلة Drafted for Submission.

🔴 إطار للجاهزية السيبرانية تحت الاستشارة.

🔴 إطار وطني للذكاء الاصطناعي تحت الاستشارة.

🔴 إرشادات للخصوصية والأمن تحت الاستشارة.

هذه الأدوات مهمة لأنها تشير إلى انتقال لبنان نحو نموذج أكثر تفصيلًا لحوكمة البيئة الرقمية وAI.

لكنها ليست نهائية.

لهذا يجب على المؤسسات العمل على مسارين بالتوازي:

تطبيق ضوابط أمنية قوية اليوم، اعتمادًا على المخاطر والبنية والاستراتيجية الوطنية القائمة.

ومراقبة الأطر الناشئة دون تقديمها كمتطلبات ملزمة قبل اعتمادها.

الأمن الجيد لا ينتظر القانون.

لكنه أيضًا لا يخترع القانون قبل صدوره.