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

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

لماذا أصبحت استمرارية AI قضية حوكمة؟

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

قد تكون الخدمة نفسها متاحة، لكن نموذج التصنيف متوقف. وقد تعمل المنصة، بينما يتعذر الوصول إلى مزود نموذج خارجي. وقد تكون الـAPI متاحة، لكن خط البيانات الذي يغذي النموذج متعطلاً. وقد يستمر النظام تقنياً بينما تتدهور جودة المخرجات إلى مستوى يجعل الاعتماد عليه غير آمن.

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

أصدرت وزارة النقل والاتصالات وتقنية المعلومات في سلطنة عُمان سياسة استمرارية عمليات تقنية المعلومات ضمن التعميم رقم 4/2026 بتاريخ 12 أبريل 2026. وتوضح الوزارة أن السياسة تستهدف ضمان استمرارية العمليات التقنية، خصوصاً أثناء الأزمات أو حالات الطوارئ، مع التأكيد على وجود خطط داخلية، وتحليل أثر الأعمال لتحديد أولويات استعادة الأنظمة، وتحديد الأدوار والموارد اللازمة لفرق الاستمرارية داخل الوحدات الحكومية.

السياسة ليست «سياسة استمرارية للذكاء الاصطناعي».

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

ابدأ من الخدمة الحرجة لا من النموذج

من الأخطاء الشائعة البدء بالسؤال: ما النموذج المستخدم؟

في الاستمرارية، السؤال الأقوى هو:

ما الوظيفة أو الخدمة التي ستتأثر إذا توقف هذا النظام؟

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

[ممارسة تنفيذية] يمكن توثيق كل حالة استخدام AI عبر سلسلة بسيطة:

الخدمة الحكومية → العملية الحرجة → استخدام AI → الاعتماديات → سيناريو الفشل → أثر التعطل → أولوية الاستعادة → البديل

هذا يمنع التعامل مع AI كأصل منفصل عن سياق العمل.

تحليل أثر الأعمال عندما تعتمد العملية على AI

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

في بيئة AI، لا ينبغي أن يقتصر تحليل الأثر على توقف التطبيق نفسه.

من الضروري فحص أثر تعطل كل مكوّن يمكن أن يمنع الخدمة المدعومة بالذكاء الاصطناعي من أداء وظيفتها المقبولة.

ومن الأسئلة العملية:

• ماذا يحدث إذا أصبح النموذج غير متاح؟
• ماذا يحدث إذا تعطلت قاعدة البيانات أو مصدر البيانات؟
• ماذا يحدث إذا توقف مزود نموذج خارجي؟
• ماذا يحدث إذا فشلت خدمة الهوية أو المصادقة؟
• هل يمكن تنفيذ الإجراء يدوياً؟
• كم من الوقت يمكن أن تعمل الجهة دون هذا المكوّن؟
• هل يؤدي التعطل إلى تأخير فقط أم إلى توقف خدمة أساسية؟
• هل ينتج عن العودة إلى البديل انخفاض في الدقة أو مستوى الخدمة؟
• من يملك قرار التحول إلى الخطة البديلة؟

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

خريطة الاعتماديات: أين يمكن أن يفشل النظام؟

أنظمة الذكاء الاصطناعي الحديثة غالباً ليست نظاماً واحداً.

قد تتكون الخدمة من:

• تطبيق داخلي.
• نموذج داخلي أو خارجي.
• مزود سحابي.
• API لنموذج لغوي أو خدمة رؤية أو ترجمة.
• قاعدة بيانات أو مستودع وثائق.
• Vector database.
• خط معالجة بيانات.
• خدمة هوية وصلاحيات.
• نظام تسجيل ومراقبة.
• مورد أو مقاول خارجي.
• موظف أو مشرف بشري يعتمد عليه النظام عند التصعيد.

[ممارسة تنفيذية] يوصى بإنشاء Dependency Map لكل خدمة AI ذات أهمية تشغيلية، توضح المكونات الداخلية والخارجية، والمالك، وموقع الاستضافة، ونقطة الفشل، والبدائل المتاحة.

وهذه الخريطة مهمة أيضاً لمفهوم السيادة الرقمية؛ لأن اعتماد الخدمة على مزود واحد أو API واحدة أو بيئة لا يوجد لها بديل قد يحول مشكلة تقنية صغيرة إلى نقطة فشل أحادية.

لا تخلط بين التوافر والمرونة التشغيلية

قد يكون النظام متاحاً بنسبة مرتفعة، لكنه غير مرن تشغيلياً.

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

• توقف حسابها لدى المزود.
• تغيير API بصورة تكسر التكامل.
• توقف منطقة الاستضافة.
• فشل نموذج جديد بعد تحديث المورد.
• انتهاء عقد أو خدمة.
• فقدان إمكانية الوصول إلى بيانات لازمة لإعادة التشغيل.
• خروج موظف واحد يملك معرفة تشغيلية حرجة.

المرونة التشغيلية أوسع من uptime.

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

ماذا يحدث عندما يفشل مزود AI أو API خارجية؟

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

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

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

[ممارسة تنفيذية] يجب توثيق أسئلة مثل:

• هل يوجد مزود بديل؟
• ما الزمن اللازم للتحول إليه؟
• هل صيغ البيانات قابلة للنقل؟
• هل يمكن تشغيل نموذج بديل داخلياً أو في بيئة أخرى؟
• هل يسمح العقد باستخراج البيانات والسجلات المطلوبة؟
• هل تعتمد المؤسسة على خصائص خاصة بمورد واحد؟
• هل لدى المورد subprocessors أو اعتماديات إضافية؟
• ما الإجراء عند فقدان الخدمة فجأة؟
• هل يوجد تشغيل يدوي مؤقت؟

هذه ليست جميعها التزامات منصوصاً عليها حرفياً في سياسة الاستمرارية؛ بل [ممارسة تنفيذية] لترجمة هدف الاستمرارية إلى بيئة AI متعددة الموردين.

البديل اليدوي ليس دائماً بسيطاً

من الشائع كتابة «العودة إلى الإجراء اليدوي» كخطة بديلة.

لكن هذا البديل قد لا يكون قابلاً للتنفيذ فعلاً.

إذا كانت المؤسسة قد اعتمدت على AI لوقت طويل، فقد تكون:

• ألغت بعض الخطوات اليدوية.
• خفّضت عدد الموظفين القادرين على تنفيذ العملية.
• فقدت النماذج القديمة أو التعليمات.
• رفعت حجم العمل إلى مستوى لا يستطيع الفريق معالجته يدوياً.
• جعلت القرار يعتمد على معلومات لا تظهر للمستخدم خارج النظام.

لذلك يجب اختبار البديل.

[ممارسة تنفيذية] أي fallback مهم يجب أن يجيب عن أربعة أسئلة:

1. من ينفذه؟
2. ما المعلومات التي يحتاجها؟
3. كم يستوعب من حجم العمل؟
4. كم يمكن الاستمرار به قبل أن تتأثر الخدمة بصورة غير مقبولة؟

التعافي لا ينتهي عندما يعود النظام للعمل

في الأنظمة التقليدية، قد تعتبر استعادة الخادم أو التطبيق مؤشراً على انتهاء الحادث.

في AI، قد يعود المكوّن إلى العمل ولكن لا تكون الخدمة جاهزة للاعتماد عليه بعد.

مثلاً:

• تمت استعادة نسخة مختلفة من النموذج.
• تغيرت إعدادات inference.
• استعيدت بيانات غير مكتملة.
• لم تعد قاعدة المعرفة متزامنة.
• تغير إصدار embedding model.
• عادت الخدمة الخارجية بإصدار جديد.
• تعطلت بعض ضوابط المحتوى أو المراقبة.

لذلك:

[ممارسة تنفيذية] ينبغي أن تتضمن خطة التعافي Post-Recovery Validation قبل إعادة الاستخدام الكامل، بما يتناسب مع أهمية النظام.

قد تشمل هذه المراجعة:

• فحص سلامة التكاملات.
• التأكد من النسخة والإعدادات.
• اختبار عينة من المخرجات.
• التحقق من البيانات ومصادرها.
• اختبار صلاحيات المستخدمين.
• التأكد من عودة التسجيل والمراقبة.
• اختبار آلية التدخل أو التجاوز البشري.
• توثيق قرار إعادة الخدمة.

العلاقة مع إدارة مخاطر تقنية المعلومات

نشرت الوزارة أيضاً سياسة إدارة مخاطر تقنية المعلومات في مارس 2026، ويتوافر لها دليل استرشادي يركز على منهجيات تقييم المخاطر والاستجابة لها، والأدوار والمسؤوليات، وتصنيف الأصول، وآليات التقارير، والمراجعة والتحديث المستمر.

الاستمرارية وإدارة المخاطر مترابطتان لكنهما ليستا الشيء نفسه.

إدارة المخاطر تسأل:

ما الذي يمكن أن يحدث، وما احتماله وأثره، وكيف نعالجه؟

أما الاستمرارية فتسأل:

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

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

مؤشرات فشل لا تظهر كـ«انقطاع»

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

قد يستمر النظام في الاستجابة بينما تنخفض موثوقيته.

ومن الأمثلة:

• ارتفاع معدل الخطأ.
• تدهور الدقة.
• تغير نمط البيانات.
• زيادة hallucination في نظام توليدي.
• انخفاض قدرة النظام على معالجة فئة معينة.
• ارتفاع معدل التدخل البشري.
• تغير سلوك النموذج بعد تحديث المورد.

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

لذلك يجب أن تربط الجهة بين مؤشرات الأداء وخطط الاستمرارية، وأن تعرف متى يجب خفض الاعتماد على النظام أو نقله إلى وضع بديل.

ما الأدلة التي يجب أن تستطيع المؤسسة إظهارها؟

سياسة الاستمرارية تركز على وجود خطط وأدوار وموارد وتحليل أثر الأعمال.

وعند تطبيق ذلك على خدمات تعتمد AI، فإن [ممارسة تنفيذية] حزمة الأدلة يمكن أن تشمل:

1. سجل الخدمات أو العمليات الحرجة.
2. تحديد حالات استخدام AI المرتبطة بها.
3. تحليل أثر الأعمال.
4. خريطة اعتماديات النظام.
5. سجل مزودي الخدمات الحرجة.
6. سيناريوهات الفشل.
7. خطة التعافي.
8. إجراءات fallback.
9. مسؤوليات الاستمرارية والتصعيد.
10. نتائج اختبارات أو تمارين الاستمرارية.
11. سجلات حوادث وانقطاعات سابقة.
12. نتائج التحقق بعد التعافي.
13. إجراءات التحسين الناتجة عن الاختبارات أو الحوادث.

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

اختبار الخطة أهم من وجودها

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

[ممارسة تنفيذية] يمكن اختبار استمرارية خدمة AI من خلال سيناريوهات Tabletop أو اختبارات تقنية مضبوطة، مثل:

• توقف مزود النموذج الخارجي.
• فقدان الاتصال بمصدر البيانات.
• تعطل منطقة cloud.
• فشل API أساسية.
• توقف vector database.
• اكتشاف خلل في مخرجات النموذج يتطلب إيقافه.
• فقدان مستخدم أو حساب تقني ذي صلاحيات حرجة.
• الحاجة إلى التحول إلى إجراء يدوي.

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

من يملك قرار إيقاف AI أو العودة إليه؟

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

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

• مالك الخدمة.
• مالك النظام.
• فريق تقنية المعلومات.
• الأمن السيبراني.
• إدارة المخاطر.
• حوكمة البيانات أو الخصوصية.
• المورد.
• المشرف البشري أو صاحب القرار التشغيلي.

[ممارسة تنفيذية] يجب تحديد من يملك:

• إعلان حالة التعطل.
• إيقاف استخدام AI.
• تشغيل fallback.
• قبول انخفاض مستوى الخدمة مؤقتاً.
• إعادة النظام بعد التعافي.
• قبول المخاطر المتبقية.

بدون هذه الصلاحيات قد يصبح وقت الأزمة نفسه وقتاً للنقاش حول من يقرر.

نموذج تنفيذي مختصر للجهات الحكومية

يمكن تحويل الموضوع إلى دورة عمل من سبع خطوات:

1. حدد الخدمات الحرجة

ابدأ من الوظائف والخدمات التي لا يمكن تعطيلها دون أثر مهم.

2. اربط استخدامات AI بها

حدد أين يعتمد تقديم الخدمة على نموذج أو خوارزمية أو خدمة AI.

3. ارسم الاعتماديات

وثق البيانات والنماذج والسحابة والـAPIs والموردين والأنظمة الداعمة والعنصر البشري.

4. قيّم أثر التعطل

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

5. صمم الاستجابة والتعافي

حدد البدائل، وآلية التصعيد، وأولوية الاستعادة، والفريق المسؤول.

6. اختبر

اختبر الخطة وسجل النتائج والفجوات.

7. تحقق بعد التعافي وحسّن

لا تعِد النظام إلى الخدمة لمجرد أنه عاد تقنياً؛ تحقق من سلامته التشغيلية ثم حدّث الخطة بناءً على الدروس المستفادة.

أخطاء يجب تجنبها

أولاً، اعتبار AI مجرد تطبيق واحد وتجاهل سلسلة الاعتماديات خلفه.

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

ثالثاً، افتراض أن SLA المورد يساوي خطة استمرارية المؤسسة.

رابعاً، كتابة fallback غير قابل للتشغيل فعلاً.

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

سادساً، اعتبار كل ممارسة تنفيذية في هذا المقال التزاماً قانونياً صريحاً.

كيف نقرأ القوة التنظيمية في هذا الموضوع؟

لمنع الخلط بين النص الرسمي والممارسة المهنية، يمكن قراءة التوصيات بأربع درجات:

E1 — صريح: ما تذكره السياسة أو الأدلة الرسمية بوضوح، مثل وجود خطط استمرارية، تحليل أثر الأعمال، تحديد أولويات استعادة الأنظمة، وتحديد الأدوار والموارد.

E2 — مستنتج بقوة: إدخال مكوّن AI في نطاق الاستمرارية عندما تعتمد عليه فعلياً خدمة حكومية أو وظيفة تقنية حرجة.

E3 — ممارسة تنفيذية: مثل AI dependency map، runbook خاص بمزود نموذج، اختبار fallback، أو post-recovery validation.

E4 — تعزيز عبر أطر أخرى: ربط الممارسة بأطر إدارة AI أو المخاطر الدولية لتحسين النضج، دون تقديم ذلك باعتباره مطلباً عُمانياً.

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

الخلاصة

توفر سياسة استمرارية عمليات تقنية المعلومات في سلطنة عُمان أساساً واضحاً للجهات الحكومية في التخطيط للاستمرارية، وتحليل أثر الأعمال، وتحديد أولويات الاستعادة، وتحديد الأدوار والموارد.

وعندما تدخل أنظمة الذكاء الاصطناعي في خدمة حكومية، فإن هذه الأنظمة واعتمادياتها تصبح جزءاً من سؤال أكبر: هل تستطيع الجهة الاستمرار أو التعافي عندما يتعطل عنصر تعتمد عليه الخدمة؟

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

آخر مراجعة تنظيمية للمحتوى: 9 سبتمبر 2026.