التشغيل البيني الحكومي وحوكمة الذكاء الاصطناعي في لبنان: من LGIF وLGIRA إلى تكامل آمن وقابل للتدقيق

لماذا التشغيل البيني مهم لحوكمة AI؟

الذكاء الاصطناعي الحكومي لا يعمل في نظام واحد معزول.

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

قد يحتاج النظام إلى التحقق من هوية مستخدم، وقراءة سجل من جهة، والحصول على حالة من جهة أخرى، ثم دعم قرار داخل مؤسسة ثالثة.

إذا لم تكن هذه الأنظمة مصممة للتكامل بصورة منظمة، يتحول مشروع AI إلى شبكة من الاتصالات الخاصة والحلول المؤقتة.

وهذا يخلق صعوبة في:

الأمن.

المساءلة.

تتبع البيانات.

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

والتدقيق.

لهذا فإن التشغيل البيني ليس موضوعًا تقنيًا ثانويًا.

هو أحد شروط الحوكمة الفعلية.

ما هو LGIF؟

إطار التشغيل البيني الحكومي اللبناني LGIF هو إطار رسمي منشور من OMSAR.

الإطار يحدد مبادئ وقواعد لدعم قدرة الجهات الحكومية على العمل معًا رقميًا.

من بين المبادئ المهمة:

التركيز على المستخدم.

الأمن والخصوصية.

الشفافية.

الانفتاح.

إعادة الاستخدام.

الحياد التقني.

والفعالية.

هذه المبادئ ليست AI Controls بحد ذاتها.

لكنها توفر بيئة أكثر نضجًا لبناء AI حكومي.

ما هي LGIRA؟

LGIRA هي الهيكلية المرجعية للتشغيل البيني الحكومي اللبناني.

إذا كان LGIF يحدد مبادئ وأطر التشغيل البيني، فإن LGIRA تساعد في تحويل ذلك إلى بنية معمارية أكثر وضوحًا.

الهيكلية المرجعية تساعد على تنظيم العلاقة بين:

الأنظمة.

الخدمات.

الواجهات.

البيانات.

المكونات المشتركة.

وقنوات التكامل.

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

الفرق بين التكامل والتشغيل البيني

Integration يعني أن نظامين يستطيعان الاتصال.

Interoperability أوسع.

هو أن يتمكن نظامان أو أكثر من تبادل المعلومات والخدمات مع فهم مشترك كافٍ للمعنى والسياق والقواعد.

هذا الفرق مهم في AI.

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

القيمة النصية وحدها لا تكفي إذا كانت الدلالة مختلفة.

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

Semantic Interoperability يعني أن معنى البيانات يبقى مفهومًا ومتسقًا عبر الأنظمة.

هذه نقطة حاسمة للذكاء الاصطناعي.

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

لذلك يجب إدارة:

قاموس البيانات.

التعريفات.

الرموز.

الحالات.

القيم المرجعية.

والوحدات.

AI لا يستطيع تصحيح غموض المعنى تلقائيًا.

العقود البيانية

عند تبادل البيانات عبر الخدمات أو APIs، من المفيد أن توجد Data Contracts واضحة.

العقد يجب أن يحدد:

اسم الحقل.

المعنى.

النوع.

القيم الممكنة.

هل هو إلزامي؟

من هو المصدر الرسمي؟

كم مرة يتحدث؟

ما مستوى الجودة المتوقع؟

هذا يقلل خطر أن يعتمد AI على افتراضات غير موثقة.

مصدر الحقيقة

في بيئة حكومية مترابطة يجب تحديد System of Record.

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

AI الذي يستخدم نسخة ثانوية قد يعمل على بيانات متأخرة أو غير محدثة.

لذلك يجب أن يكون مصدر الحقيقة واضحًا لكل عنصر مهم.

APIs كبوابات حوكمة

API ليست مجرد واجهة تقنية.

يمكن أن تصبح نقطة تحكم.

من خلالها يمكن فرض:

الهوية.

الصلاحيات.

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

التسجيل.

التحقق من الطلب.

القيود على الحجم.

والمراقبة.

هذا يجعل API Governance عنصرًا مهمًا في AI Governance.

AI لا يجب أن يصل مباشرة لكل قاعدة بيانات

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

هذا يزيد التعقيد والمخاطر.

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

بهذا يمكن التحكم في:

ما الذي يراه النموذج.

كمية البيانات.

تواتر الوصول.

ومن يستطيع استدعاء الخدمة.

مبدأ أقل صلاحية

النظام يجب أن يحصل على أقل قدر من الصلاحيات اللازمة.

إذا احتاج AI إلى حقلين، لا يحتاج إلى قاعدة كاملة.

إذا كان يحتاج إلى قراءة فقط، لا يجب منحه Write Access.

كل صلاحية إضافية توسع أثر الخطأ أو الاختراق.

هوية النظام

الهوية لا تخص المستخدم فقط.

كل Service أو Application يحتاج إلى هوية.

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

أي تطبيق طلب البيانات؟

أي نموذج؟

أي بيئة؟

أي نسخة؟

هل الطلب جاء من Production أم Test؟

هذه المعلومات ضرورية لأثر التدقيق.

الخدمات المشتركة

الحكومة الرقمية الناضجة لا تعيد بناء نفس الوظيفة في كل جهة.

يمكن أن توجد Shared Services للهوية، التحقق، الإشعارات، التكامل، السجلات، أو البيانات المرجعية.

هذه الخدمات تقلل التكرار.

لكنها تخلق Dependence مشتركة.

إذا فشلت خدمة مركزية، قد تتأثر عدة جهات.

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

AI كخدمة مشتركة

يمكن مستقبلاً تقديم بعض قدرات AI كخدمة مشتركة بدل بناء نموذج منفصل في كل وزارة.

لكن هذا النموذج يحتاج إلى حوكمة أقوى.

يجب تحديد:

من يملك الخدمة؟

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

ما البيانات المسموحة؟

كيف تفصل بيانات الجهات؟

كيف تتم المراقبة؟

ومن يتحمل المسؤولية عن النتيجة؟

فصل البيانات بين الجهات

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

يجب الحفاظ على الحدود المؤسسية.

قد تكون هناك حاجة إلى:

Tenant Separation.

Logical Segmentation.

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

أو خدمات وسيطة.

الهدف هو مشاركة القدرة دون فقدان التحكم.

التشغيل البيني والخصوصية

LGIF يضع الأمن والخصوصية ضمن مبادئه.

هذا مهم لأن زيادة التكامل تعني زيادة حركة البيانات.

كل اتصال جديد يخلق احتمالًا جديدًا للوصول أو الخطأ.

لذلك يجب مراجعة Data Flow عند إضافة أي تكامل جديد.

الربط بين الأنظمة

قبل ربط نظام AI بخدمة حكومية يجب تقييم:

الغرض.

نوع البيانات.

الحساسية.

الحجم.

التواتر.

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

ومدة الاحتفاظ.

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

Data Lineage

عندما تنتقل البيانات عبر عدة أنظمة، تصبح Data Lineage أكثر تعقيدًا.

يجب معرفة:

من أين بدأت؟

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

ما الأنظمة التي مرت بها؟

هل تم دمجها؟

هل تم تغيير الصيغة؟

هل فقدت أي سياق؟

هذه المعرفة مهمة إذا أثرت البيانات في قرار AI.

جودة البيانات عبر الحدود المؤسسية

جهتان قد تستخدمان مستويات مختلفة من الجودة.

نظام AI قد يجمع بيانات من مصدر عالي الجودة مع مصدر ضعيف دون تمييز.

لذلك يجب أن تنتقل Metadata عن الجودة مع البيانات نفسها.

من المفيد أن تصبح جودة المصدر جزءًا من قرار النموذج أو من عملية المراجعة.

إدارة الإصدارات

APIs تتغير.

Data Schemas تتغير.

الخدمات تتغير.

إذا كان AI يعتمد على واجهة معينة، يجب إدارة Versioning.

تغيير صغير في Schema قد يؤدي إلى خطأ صامت.

لذلك يجب تحديد:

الإصدار.

التوافق.

فترة الانتقال.

الإشعار.

والاختبارات.

اختبار التكامل

اختبار النموذج وحده غير كافٍ.

يجب اختبار End-to-End Flow.

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

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

هل الأخطاء تظهر؟

هل النظام يعرف ماذا يفعل إذا فشل مصدر خارجي؟

هل يتم تسجيل الأحداث؟

هذه الاختبارات تكشف مشاكل لا تظهر في مختبر النموذج.

الفشل الجزئي

في نظام مترابط، قد تفشل خدمة واحدة بينما تبقى بقية المكونات عاملة.

AI يجب أن يتعامل مع هذا الاحتمال.

إذا لم تصل معلومة من مصدر معين، ماذا يحدث؟

هل يكمل؟

هل يرفض القرار؟

هل يطلب مراجعة بشرية؟

Fail-Safe يجب أن يكون مصممًا مسبقًا.

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

كل اعتماد خارجي يضيف نقطة فشل.

لهذا يجب رسم Dependency Map.

ليس فقط الموردين.

بل أيضًا:

APIs.

Identity Services.

Data Services.

Network Paths.

Cloud Components.

وأي Model API.

المرونة تحتاج إلى فهم هذه السلسلة كاملة.

الأمن

كل واجهة جديدة توسع Attack Surface.

لذلك يجب حماية APIs ضد:

سوء الاستخدام.

سرقة Credentials.

الاستدعاءات الكثيفة.

الوصول غير المصرح.

والحقن.

بالنسبة إلى AI، قد تظهر أيضًا مخاطر مثل Prompt Injection أو Data Poisoning عبر الخدمات المرتبطة.

المراقبة

يجب مراقبة أكثر من أداء النموذج.

نحتاج إلى مراقبة:

زمن APIs.

معدلات الفشل.

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

التغيرات في Schema.

ارتفاع الطلبات.

وأنماط الوصول.

في الأنظمة المترابطة قد تكون المشكلة في التكامل وليس في AI نفسه.

Observability

Observability تعني القدرة على فهم ما يحدث داخل النظام الموزع.

يجب أن تكون هناك Logs وMetrics وTraces تكفي لتتبع العملية عبر عدة خدمات.

هذه القدرة مهمة عندما يمر الطلب عبر:

بوابة.

خدمة بيانات.

نموذج.

نظام قرار.

ثم قناة للمستخدم.

أثر التدقيق عبر الأنظمة

Audit Trail لا يجب أن يتوقف عند حدود النظام الواحد.

إذا انتقل الطلب بين عدة خدمات، يجب أن توجد Correlation ID أو آلية مماثلة لربط الأحداث.

بدون ذلك يصعب التحقيق في القرار النهائي.

إدارة الأخطاء

كل خدمة يجب أن تعطي أخطاء يمكن تفسيرها.

لا يكفي HTTP 500.

النظام يحتاج إلى معرفة:

هل المشكلة مؤقتة؟

هل البيانات غير موجودة؟

هل المستخدم غير مخول؟

هل Schema تغير؟

هل الطلب مرفوض؟

نوع الخطأ يؤثر على القرار التالي.

إعادة الاستخدام

LGIF يشجع إعادة الاستخدام.

هذه نقطة قوية للتحديث الحكومي.

لكن إعادة استخدام خدمة أو نموذج AI يجب أن تمر بتقييم للسياق الجديد.

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

Reuse لا يعني Approval دائم.

الحياد التقني

الحياد التقني يساعد على تجنب Lock-in.

السياسة لا يجب أن ترتبط بمزود أو Model Family واحد.

الأفضل تحديد:

وظيفة.

معايير.

واجهات.

ضوابط.

ومستوى أداء.

ثم يمكن تغيير التقنية مع الحفاظ على الحوكمة.

قابلية النقل

عندما يصبح AI جزءًا من خدمة حكومية، يجب التفكير في Portability.

هل يمكن نقل النموذج؟

هل يمكن تصدير البيانات؟

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

هل يمكن استبدال المورد؟

كلما زاد الاعتماد على خصائص خاصة بمزود واحد، أصبحت الخروج أصعب.

Vendor Lock-in

الاعتماد على مورد ليس مشكلة تلقائيًا.

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

يجب أن تشمل العقود:

Data Export.

Model Artifacts إن أمكن.

Documentation.

Transition Support.

وتوقيت الخروج.

التشغيل البيني مع الموردين

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

المورد الخارجي يدخل أيضًا في Architecture.

يجب تحديد:

ما الوصول الذي يحصل عليه؟

أي APIs؟

أي بيانات؟

كيف يتم إلغاء الصلاحية؟

هل توجد Monitoring؟

هذا جزء من Third-Party Governance.

الخدمات القديمة

Legacy Systems تشكل تحديًا.

قد لا تدعم APIs حديثة.

وقد تستخدم صيغًا قديمة.

إضافة AI فوق هذه البيئة قد يخلق طبقات إضافية من التعقيد.

أحيانًا يجب تحديث التكامل أولًا قبل إضافة الذكاء الاصطناعي.

تحديث البنية تدريجيًا

ليس مطلوبًا استبدال كل الأنظمة دفعة واحدة.

يمكن بناء Integration Layer تدريجي.

لكن يجب أن تكون الخطة المعمارية واضحة حتى لا تتحول الحلول المؤقتة إلى بنية دائمة غير قابلة للإدارة.

العلاقة مع MITAI

خارطة MITAI الحديثة تضع البنية الرقمية الوطنية والبيانات والهوية والأمن ضمن محاورها.

هذا يجعل LGIF وLGIRA أكثر أهمية، لا أقل.

الأطر القديمة نسبيًا للتشغيل البيني يمكن أن تمثل Foundation يبنى فوقه التوسع في AI إذا تم تحديث التطبيق العملي بما يتناسب مع الخدمات الحديثة.

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

استراتيجية التحول الرقمي 2020–2030 تعطي التشغيل البيني دورًا مركزيًا في تحديث الإدارة العامة.

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

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

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

لا ينبغي وصف LGIF بأنه AI Governance Framework.

ولا LGIRA بأنها AI Architecture Standard.

ولا يعني Interoperability أن كل البيانات متاحة لجميع الجهات.

ولا تعني Shared Services أن المسؤولية مركزية بالكامل.

ولا يعني استخدام API أن التكامل آمن تلقائيًا.

هذه حدود مهمة.

نموذج تكامل AI حكومي

يمكن بناء نموذج بسيط:

مصدر بيانات موثوق.

API محكومة.

Identity.

Authorization.

AI Service.

Human Oversight.

Decision Service.

Audit Trail.

Monitoring.

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

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

بوابة اعتماد التكامل

قبل ربط AI بأي نظام حكومي، يجب مراجعة:

الغرض.

المصدر.

البيانات.

الصلاحيات.

المالك.

الأمن.

الاعتمادية.

الاحتفاظ.

المراقبة.

وخطة الفشل.

هذه البوابة تكمل بوابة AI Governance العامة.

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

ابدأ بخريطة الأنظمة.

حدد Sources of Truth.

وثق APIs.

حدد Data Owners.

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

أضف Service Identities.

أنشئ Logs مترابطة.

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

ثم أضف AI فوق بنية يمكن فهمها وتدقيقها.

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

LGIF وLGIRA لا ينظمان الذكاء الاصطناعي مباشرة.

لكن قيمتهما في AI Governance كبيرة لأنهما يعالجان السؤال الذي يسبق النموذج:

كيف تتواصل الأنظمة الحكومية؟

كيف تتبادل البيانات؟

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

كيف تتوزع الخدمات؟

وأين تقع الحدود بين المكونات؟

في حكومة تستخدم AI، النموذج ليس النظام الكامل.

هو مكون داخل شبكة من البيانات والخدمات والهويات والموردين.

إذا كانت هذه الشبكة غير منظمة، تصبح حوكمة AI ضعيفة مهما كان النموذج متقدمًا.

التشغيل البيني الجيد لا يجعل AI آمنًا تلقائيًا.

لكنه يجعل الحوكمة ممكنة.