الذكاء الاصطناعي المسؤول في لبنان: من الإطار الوطني قيد الاستشارة إلى ضوابط مؤسسية قابلة للتنفيذ

لماذا يحتاج Responsible AI إلى مقال مستقل؟

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

خارطة MITAI الحديثة تكشف وجود طبقة أكثر تخصصًا من الأدوات:

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

إطار جاهزية الذكاء الاصطناعي.

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

هذه الأدوات مهمة لأنها تنقل النقاش من سؤال:

هل نستخدم AI؟

إلى سؤال أكثر نضجًا:

كيف نستخدمه بصورة آمنة وخاضعة للمساءلة، وهل المؤسسة جاهزة أصلًا لهذا الاستخدام؟

لكن يجب الحفاظ على حقيقة أساسية طوال القراءة:

الأطر الثلاثة ما تزال تحت الاستشارة وليست نهائية.

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

تصف خارطة MITAI الرسمية National AI Framework بأنه Guidance for safe, accountable AI adoption.

هذه صياغة واضحة من حيث الاتجاه.

لبنان يتجه نحو بناء مرجع أكثر تخصصًا للتبني الآمن والخاضع للمساءلة للذكاء الاصطناعي.

لكن الحالة المنشورة حتى تاريخ التحقق هي:

Currently Under Consultation.

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

ماذا يعني Safe and Accountable AI؟

المصطلحان مهمان.

Safe AI يعني أن النظام لا يخلق مستوى غير مقبول من الضرر أو عدم الموثوقية في سياقه الفعلي.

Accountable AI يعني أن المسؤولية لا تختفي داخل النموذج أو المورد.

يجب أن نستطيع معرفة:

من يملك حالة الاستخدام؟

من وافق عليها؟

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

من يتحمل القرار؟

من يراقب النظام؟

ومن يتصرف عند الفشل؟

المساءلة تبدأ بتوزيع المسؤوليات قبل تشغيل النموذج.

🔴 إطار جاهزية الذكاء الاصطناعي

خارطة MITAI تعرض أيضًا AI Readiness Framework باعتباره أداة لإعداد الوزارات لقدرات AI.

وحالته كذلك:

Currently Under Consultation.

الفرق بينه وبين National AI Framework مهم.

الإطار الوطني يتجه نحو كيفية التبني الآمن والخاضع للمساءلة.

أما إطار الجاهزية فيتعلق بالسؤال الذي يسبق ذلك:

هل المؤسسة تمتلك أصلًا القدرة على التبني؟

الجاهزية ليست امتلاك نموذج

يمكن لمؤسسة شراء اشتراك في نموذج متقدم خلال يوم واحد.

هذا لا يجعلها جاهزة للذكاء الاصطناعي.

الجاهزية المؤسسية قد تشمل:

وضوح العمليات.

جودة البيانات.

البنية التقنية.

الأمن.

المهارات.

القيادة.

الحوكمة.

المشتريات.

وإدارة الموردين.

المؤسسة غير الجاهزة قد تستطيع إطلاق Pilot ناجح، لكنها ستواجه صعوبة عند الانتقال إلى Production.

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

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

MITAI تصفها بأنها Controls for Digital Services.

هذه الإرشادات مهمة لـResponsible AI لأن معظم أنظمة AI المؤسسية تعمل داخل خدمات رقمية وتعالج بيانات أو تعتمد على موردين ومنصات خارجية.

لكنها:

ليست نهائية.

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

ولا يجب أن تعرض كالتزام تنظيمي نافذ.

الطبقة النهائية القائمة

إلى جانب الأدوات غير النهائية، توجد طبقات لبنانية قائمة ونهائية يمكن البناء عليها.

منها:

خارطة MITAI المنشورة بصيغتها الحالية.

استراتيجية التحول الرقمي الوطنية 2020–2030.

وقانون 81/2018 بشأن المعاملات الإلكترونية والبيانات ذات الطابع الشخصي.

هذه الوثائق لا تشكل مجتمعة قانونًا شاملاً للذكاء الاصطناعي.

لكنها توفر بيئة مؤسسية وقانونية مهمة يجب ألا يتجاهلها أي برنامج Responsible AI.

Responsible AI ليس Ethics Statement

من أكثر الأخطاء شيوعًا تحويل Responsible AI إلى صفحة مبادئ جميلة.

العدالة.

الشفافية.

المساءلة.

الخصوصية.

الأمان.

هذه القيم مهمة.

لكن قيمتها العملية تبدأ عندما تتحول إلى ضوابط داخل دورة حياة النظام.

مثلاً:

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

"الأمان" إلى اختبارات ومراقبة وخطة فشل.

"الخصوصية" إلى قواعد بيانات وصلاحيات واحتفاظ.

"الإشراف البشري" إلى صلاحية فعلية للاعتراض والتدخل.

من المبادئ إلى Controls

نموذج Responsible AI المؤسسي يحتاج إلى تحويل كل مبدأ إلى سؤال قابل للتحقق.

بدل:

هل النظام شفاف؟

نسأل:

هل يستطيع المسؤول شرح الغرض والبيانات وحدود الاستخدام؟

هل يعرف المستخدم متى يؤثر AI في القرار؟

هل توجد آلية للمراجعة؟

هل يمكن تتبع القرار؟

بهذه الطريقة تتحول المبادئ إلى Evidence.

سجل أنظمة AI

لا يمكن حوكمة ما لا تعرف المؤسسة وجوده.

السجل يجب أن يشمل:

النماذج المطورة داخليًا.

الأدوات التوليدية.

خصائص AI المضمنة في SaaS.

Chatbots.

أنظمة التحليل.

أنظمة الموردين.

والنماذج التي تستخدم بصورة غير مباشرة عبر API.

السجل هو نقطة البداية للحوكمة.

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

لكل نظام يمكن تسجيل:

الغرض.

المالك.

المستخدمون.

البيانات.

المورد.

نوع النموذج.

القرارات التي يدعمها.

درجة الأتمتة.

البيئة.

التاريخ.

الحالة.

وآخر مراجعة.

كلما ارتفع أثر النظام، يجب أن تزداد التفاصيل.

تصنيف المخاطر

لا يجب أن يمر كل AI use case عبر المسار نفسه.

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

يمكن بناء تصنيف يعتمد على:

أثر القرار.

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

عدد الأشخاص المتأثرين.

درجة الأتمتة.

قابلية الرجوع عن النتيجة.

الأهمية التشغيلية.

ومستوى الاعتماد على طرف خارجي.

استخدام منخفض الأثر

قد تشمل الاستخدامات منخفضة الأثر:

المساعدة في صياغة مسودة.

تلخيص محتوى غير حساس.

تصنيف مستندات داخلية محدودة.

أو دعم بحث لا ينتج قرارًا مباشرًا.

هذا لا يعني انعدام المخاطر.

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

الاستخدام عالي الأثر

يرتفع الأثر عندما يؤثر النظام في:

حق.

خدمة عامة.

قرار مالي.

تصنيف شخص.

عملية حساسة.

أو بنية تشغيلية مهمة.

هذه الاستخدامات تحتاج إلى مستوى أعلى من:

المراجعة.

الاختبار.

التوثيق.

الإشراف.

والمراقبة.

Human Oversight

الإشراف البشري ليس مجرد وجود موظف في العملية.

يجب أن يكون الإنسان قادرًا على:

فهم سبب عرض النتيجة.

رفضها.

تعديلها.

طلب معلومات إضافية.

والتصعيد.

إذا كان الموظف مضطرًا عمليًا إلى قبول النتيجة، فإن Human Oversight شكلي.

Automation Bias

الموظف قد يميل إلى الثقة في النظام لأنه يظهر نتيجة رقمية أو تبدو لغته واثقة.

هذا يسمى Automation Bias.

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

كما يجب تصميم الواجهة بحيث لا تدفع المستخدم إلى الموافقة التلقائية.

Model Risk

مخاطر النموذج تعني احتمال أن ينتج النظام نتائج غير مناسبة بسبب:

تصميمه.

بياناته.

افتراضاته.

استخدامه خارج السياق.

تغير البيئة.

أو سوء تفسير المخرجات.

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

AI Assurance

AI Assurance يمكن استخدامه كطبقة عملية لبناء الثقة في الأنظمة.

الضمان هنا لا يعني أن النظام مثالي.

يعني أن المؤسسة لديها أدلة معقولة على أن النظام:

مناسب للغرض.

اختُبر.

له حدود معروفة.

يمكن مراقبته.

ويمكن التحكم في فشله.

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

TEVV

TEVV يعني:

Testing.

Evaluation.

Verification.

Validation.

أي الاختبار والتقييم والتحقق والتثبت.

هذه المقاربة مفيدة للأنظمة المتوسطة والعالية الأثر لأنها تمنع اختزال التقييم في Metric واحدة.

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

لا تنسب TEVV إلى الإطار اللبناني

هذه نقطة نزاهة مهمة.

وجود TEVV كممارسة جيدة لا يعني أن National AI Framework اللبناني الحالي، وهو ما يزال تحت الاستشارة، يفرض TEVV بصيغة محددة.

لذلك يجب الفصل بين:

الممارسات العالمية أو المؤسسية المقترحة.

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

اختبار الدقة لا يكفي

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

وقد تتغير الجودة بين:

لغة وأخرى.

منطقة وأخرى.

فئة مستخدمين وأخرى.

أو بيانات حديثة وقديمة.

لذلك يجب اختيار مؤشرات تعكس الضرر المحتمل وليس الأداء المتوسط فقط.

اختبار حالات الفشل

النظام يحتاج إلى اختبارات لسيناريوهات غير مثالية:

بيانات ناقصة.

طلبات غامضة.

مدخلات غير متوقعة.

انقطاع مورد.

تغير Schema.

نتيجة غير موثوقة.

ضغط تشغيلي.

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

السؤال ليس هل النظام يفشل.

كل نظام سيفشل في نقطة ما.

السؤال هو: كيف يفشل؟

Fail-Safe

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

قد يكون:

العودة إلى مسار يدوي.

إيقاف القرار.

طلب مراجعة إضافية.

استخدام نظام بديل.

أو خفض مستوى الأتمتة.

أفضل سلوك يعتمد على أثر الحالة.

حوكمة البيانات

Responsible AI يعتمد مباشرة على Data Governance.

يجب معرفة:

مصدر البيانات.

المالك.

الجودة.

الصلاحيات.

الحساسية.

الاحتفاظ.

والغرض.

إذا كانت المؤسسة لا تعرف البيانات، فلن تستطيع تفسير سلوك النموذج بصورة جدية.

مصدرية البيانات

Data Provenance تربط النتيجة بمصدرها.

في التحقيق يجب أن نعرف:

أي نسخة من البيانات؟

من أي مصدر؟

ما التحويلات؟

متى تم جمعها؟

هل تم تصحيحها؟

هل تغيرت؟

مصدرية البيانات جزء من المساءلة.

قانون 81/2018

قانون 81/2018 يوفر طبقة قائمة لحماية البيانات ذات الطابع الشخصي.

لكن لا يجب تحويله إلى AI Law.

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

البيانات الجديدة التي يستنتجها AI

النظام قد لا يكتفي بالبيانات الأصلية.

قد ينتج:

Score.

تصنيفًا.

احتمالًا.

ملفًا سلوكيًا.

أو استنتاجًا جديدًا.

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

Generative AI

GenAI يجعل التبني أسرع من دورة الحوكمة التقليدية.

يمكن لموظف البدء باستخدام أداة خلال دقائق.

لهذا يجب أن تكون سياسة الاستخدام بسيطة وقابلة للتطبيق.

يجب تحديد:

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

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

متى تكون المراجعة البشرية إلزامية.

وما الاستخدامات التي تحتاج موافقة مسبقة.

Shadow AI

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

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

الحل ليس حظر كل شيء.

الحل توفير مسار رسمي سريع، وأدوات مناسبة، وسياسة واضحة.

Hallucination

النموذج التوليدي قد ينتج محتوى يبدو منطقيًا لكنه غير صحيح.

هذه ليست مشكلة يمكن حلها بعبارة "راجع الإجابة".

يجب تحديد حالات الاستخدام التي تحتاج:

مصدرًا.

تحققًا مستقلاً.

أو منعًا من استخدام المخرجات مباشرة.

درجة الضبط تعتمد على الضرر الممكن.

المسؤولية عن القرار

إذا أوصى AI بقرار، يجب أن يوجد Decision Owner.

قد يكون النظام من تطوير فريق تقني.

لكن القرار الإداري أو التشغيلي لا يجب أن ينتقل تلقائيًا إلى الفريق التقني.

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

الموردون

معظم المؤسسات لن تبني كل شيء داخليًا.

لذلك Vendor Governance جزء أساسي من Responsible AI.

قبل التعاقد يجب معرفة:

من هو المزود؟

أين تتم المعالجة؟

هل يحتفظ بالبيانات؟

هل يستخدمها للتدريب؟

من هم المعالجون الفرعيون؟

كيف يحدث النموذج؟

وكيف ننهي الخدمة؟

Third-Party AI Risk

المورد المباشر قد يعتمد على مزود آخر.

وهذا المزود قد يعتمد على Cloud Provider آخر.

هذه السلسلة تخلق Third-Party AI Risk.

يجب تقييم الاعتماديات الحرجة، لا اسم الشركة في العقد فقط.

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

النموذج قد يتغير دون مشروع جديد.

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

يجب تحديد التغييرات التي تحتاج:

إشعارًا.

اختبارًا جديدًا.

إعادة اعتماد.

أو تحديث تقييم المخاطر.

Change Management

كل نظام AI يحتاج إلى Change Management متناسب مع المخاطر.

التغيير يمكن أن يكون:

Model Version.

Prompt.

RAG Source.

Dataset.

Tool.

API.

Vendor.

أو Business Rule.

النظام الذي تغير جوهريًا لا يجب أن يبقى "معتمدًا" تلقائيًا إلى الأبد.

أثر التدقيق

Audit Trail يجب أن يجيب عن أسئلة عملية:

من استخدم النظام؟

متى؟

أي إصدار؟

ما البيانات؟

ما النتيجة؟

هل تدخل إنسان؟

من وافق؟

وفي الأنظمة عالية الأثر، قد نحتاج أيضًا إلى معرفة التغيير الذي كان نافذًا وقت القرار.

Monitoring

المراقبة بعد الإنتاج ضرورية.

قد تتغير:

البيانات.

السلوك.

المستخدمون.

النموذج.

أو البيئة.

المؤشرات يمكن أن تشمل:

نسبة الأخطاء.

الاعتراضات.

التدخلات البشرية.

الحوادث.

التغير في الأداء.

وزمن الاستجابة.

Drift

النموذج الذي كان مناسبًا وقت الإطلاق قد يتدهور.

يمكن أن يحدث Data Drift أو Concept Drift أو تغير في الاستخدام.

لذلك الاعتماد ليس قرارًا أبديًا.

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

Incident Management

حادث AI ليس دائمًا حادثًا سيبرانيًا.

قد يكون:

فشل نموذج.

خطأ بيانات.

قرارًا واسعًا غير صحيح.

تسريبًا.

انحيازًا.

فشل مورد.

أو تنفيذًا آليًا غير مقصود.

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

الاعتراض والمراجعة

في الأنظمة المؤثرة، وجود قناة للمراجعة مهم.

المستخدم أو الموظف يحتاج إلى معرفة:

كيف يطعن في النتيجة؟

من يراجعها؟

هل يمكن تصحيح البيانات؟

هل يمكن عكس القرار؟

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

الشفافية

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

قد تعني:

توضيح أن AI مستخدم.

شرح الغرض.

بيان حدود الاستخدام.

تحديد المسؤول.

إتاحة مسار للمراجعة.

والاحتفاظ بالمعلومات اللازمة للتحقيق.

مستوى الشفافية يتناسب مع أثر النظام.

Documentation

الوثائق ليست غاية في ذاتها.

لكن النظام غير الموثق يصبح سريعًا غير قابل للإدارة.

يمكن أن تتضمن الوثائق:

الغرض.

المالك.

البيانات.

الإصدار.

المورد.

الاختبارات.

المخاطر.

الضوابط.

وقرارات الموافقة.

هذه المعلومات يجب أن تكون قابلة للتحديث.

نموذج بطاقة نظام AI

يمكن للمؤسسة استخدام بطاقة داخلية مختصرة لكل نظام.

تشمل:

Identity.

Purpose.

Owner.

Risk Tier.

Data.

Vendor.

Human Oversight.

Testing.

Known Limitations.

Monitoring.

Approval Status.

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

علاقة الجاهزية بالحوكمة

AI Readiness وAI Governance مرتبطان لكنهما مختلفان.

قد تمتلك المؤسسة سياسة ممتازة لكنها تفتقر إلى مهارات أو بيانات أو بنية.

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

النجاح يحتاج الاثنين.

تقييم الجاهزية المؤسسية

يمكن تقييم الجاهزية عبر محاور مثل:

القيادة.

الاستراتيجية.

البيانات.

البنية.

الأمن.

المهارات.

الحوكمة.

المشتريات.

والتشغيل.

الهدف ليس إنتاج Score جميل.

الهدف معرفة ما الذي يمنع الانتقال الآمن إلى الاستخدام التالي.

لا تستخدم Readiness Score كتجميل

إذا حصلت المؤسسة على 82/100 فهذا لا يعني أنها جاهزة لكل AI use case.

قد يكون لديها ضعف حرج في البيانات الشخصية أو Vendor Risk.

المتوسط يمكن أن يخفي نقطة فشل واحدة عالية التأثير.

لذلك يجب قراءة النتائج حسب المحور والمخاطر.

بوابة الموافقة

قبل دخول أي نظام متوسط أو عالي الأثر إلى Production، يمكن استخدام Gate واضح يسأل:

ما الغرض؟

ما مستوى الأثر؟

ما البيانات؟

من المالك؟

من المورد؟

ما الاختبارات؟

ما نقاط الفشل؟

ما الإشراف؟

ما خطة المراقبة؟

وما خطة الإيقاف؟

إذا لم توجد إجابات، النظام غير جاهز.

فصل الابتكار عن Production

Sandbox وPilot أدوات مهمة.

لكن التجربة لا تعني السماح التلقائي بالإنتاج.

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

هذه المرحلة تحول Prototype إلى نظام مؤسسي وتضيف:

الأمن.

الاختبار.

المراقبة.

الدعم.

والمساءلة.

Responsible Innovation

الابتكار المسؤول لا يعني إبطاء كل مشروع.

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

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

العلاقة مع MITAI Roadmap

خارطة MITAI هي الطبقة الرسمية الأوسع التي توضح اتجاه لبنان نحو DigiTech Governance وAI Policy Frameworks وDigital Ethics.

الإطار الوطني وإطار الجاهزية الموجودان تحت الاستشارة هما امتداد أكثر تخصصًا لهذا الاتجاه.

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

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

استراتيجية 2020–2030 توفر الأساس الأوسع:

الخدمات.

البيانات.

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

البنية المؤسسية.

والإصلاح القانوني.

Responsible AI يجب أن يندمج داخل هذه البيئة بدل بناء منظومة مستقلة موازية.

العلاقة مع الخصوصية والأمن

Responsible AI لا يمكن فصله عن Privacy وCybersecurity.

لكن المجالات ليست الشيء نفسه.

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

وقد يحترم الخصوصية لكنه يفشل تشغيليًا.

لذلك يجب أن تعمل الوظائف معًا دون اختزال AI Governance في الأمن أو حماية البيانات فقط.

نموذج مسؤوليات مؤسسي

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

Business Owner: الغرض والقرار.

AI/System Owner: النظام ودورة حياته.

Data Owner: البيانات والوصول والجودة.

Security: التهديدات والضوابط الأمنية.

Privacy/Legal: البيانات والالتزامات القانونية.

Risk/Assurance: التقييم والاختبارات المستقلة عند الحاجة.

Procurement/Vendor Management: الموردون والعقود.

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

مجلس AI ليس الحل دائمًا

إنشاء لجنة مركزية لكل قرار قد يصبح عنق زجاجة.

الأفضل غالبًا نموذج تصعيد قائم على المخاطر.

الحالات المنخفضة الأثر تمر بمسار مبسط.

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

بهذا تبقى الحوكمة قابلة للتوسع.

Evidence-Based Governance

أفضل حوكمة ليست التي تحتوي على أكبر عدد من السياسات.

هي التي تستطيع إثبات أن الضوابط تعمل.

أمثلة الأدلة:

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

سجل موافقة.

تقرير حادث.

تقييم مورد.

سجل نموذج.

مؤشر مراقبة.

وسجل مراجعة بشرية.

هذا يحول الحوكمة إلى نظام قابل للتدقيق.

ما الذي لا يمكن اعتباره متطلبًا لبنانيًا نهائيًا؟

حتى تاريخ التحقق:

🔴 National AI Framework ما يزال تحت الاستشارة.

🔴 AI Readiness Framework ما يزال تحت الاستشارة.

🔴 Privacy & Security Guidelines ما تزال تحت الاستشارة.

لذلك لا يجوز القول إن لبنان فرض رسميًا:

نموذج تصنيف مخاطر محدد.

TEVV بصيغة محددة.

AI Assurance Framework محددًا.

Model Cards إلزامية.

AI Impact Assessment محدد النموذج.

أو هيكل لجنة بعينه.

ما لم تظهر هذه المتطلبات في نص رسمي نهائي لاحق.

كيف تستخدم المؤسسة الأطر غير النهائية؟

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

لكن يجب وضع Label واضح:

Consultation.

ويمكن إجراء Gap Analysis استرشادي.

لكن لا ينبغي تسجيل نتيجة "Compliance" وكأن الأداة أصبحت نافذة.

هذه نقطة مهمة في التقارير التنفيذية والتدقيق.

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

لا تحتاج إلى انتظار النسخة النهائية كي تبدأ.

ابدأ بالأشياء منخفضة الندم:

AI Inventory.

Risk Classification.

Data Governance.

Vendor Governance.

Human Oversight.

Testing.

Logging.

Monitoring.

Incident Management.

وChange Management.

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

خارطة تنفيذ من أربع مراحل

يمكن البدء بأربع مراحل.

المرحلة الأولى: Discover.

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

المرحلة الثانية: Govern.

تحديد المخاطر والمالكين والسياسات.

المرحلة الثالثة: Assure.

الاختبار والتقييم والتوثيق قبل الإنتاج.

المرحلة الرابعة: Operate.

المراقبة والحوادث والتغيير وإعادة التقييم.

هذا النموذج لا يدعي أنه الإطار اللبناني الرسمي.

هو طريقة عملية لتحويل Responsible AI إلى تشغيل مؤسسي.

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

لبنان يتحرك في 2026 نحو طبقة أكثر تخصصًا من حوكمة الذكاء الاصطناعي.

الإشارة الأقوى هي وجود:

🔴 National AI Framework تحت الاستشارة لتوجيه التبني الآمن والخاضع للمساءلة.

🔴 AI Readiness Framework تحت الاستشارة لإعداد الوزارات والقدرات المؤسسية.

🔴 Privacy & Security Guidelines تحت الاستشارة لضبط الخدمات الرقمية.

وفي الخلفية توجد طبقات نهائية قائمة في التحول الرقمي والبيانات.

هذا المشهد لا يعني أن لبنان أصبح لديه تنظيم AI نهائي شامل.

لكنه يعني أن Responsible AI لم يعد مجرد مفهوم نظري في الاتجاه الحكومي.

المؤسسات تستطيع الاستعداد الآن دون اختراع متطلبات غير موجودة.

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

ثم ربط هذه الطبقات بالأطر اللبنانية النهائية عندما تصدر.

Responsible AI الناضج لا يقاس بعدد المبادئ المكتوبة.

يقاس بقدرة المؤسسة على إثبات من اتخذ القرار، وبأي بيانات، وبأي نظام، وما الذي اختُبر، وما الذي حدث عندما أخطأ النظام.