الحوسبة السحابية وبنية الذكاء الاصطناعي في سوريا: من مراكز البيانات إلى السيادة والمرونة التشغيلية

لماذا أصبحت السحابة جزءًا من حوكمة AI؟

الذكاء الاصطناعي الحديث يعتمد بصورة كبيرة على البنية الحاسوبية.

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

لهذا لا يمكن فصل AI Governance عن Cloud Governance.

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

السياسة السحابية تجيب عن أسئلة البنية والاستضافة والتشغيل.

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

السياق السوري في 2026

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

ناقشت وزارة الاتصالات وتقانة المعلومات مع منظمة التعاون الرقمي تطوير البنية التحتية للحكومة الرقمية ومراكز البيانات والحوسبة السحابية ضمن محاور تتضمن أيضًا التشريعات والحوكمة.

وفي سبتمبر 2026 أُطلقت في دمشق خدمات سحابية محلية تتضمن الاستضافة والحلول السحابية والنسخ الاحتياطي وأمن المعلومات وحلول الذكاء الاصطناعي.

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

السياسة الوطنية للحوسبة السحابية

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

لكن وجود سياسة سحابية لا يعني أن كل Dataset أو AI workload يمكن نقله إلى أي Cloud Service.

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

ولا ينبغي نسبة متطلبات تفصيلية إلى السياسة لم يتم التحقق منها من نصها الكامل.

Public Cloud وPrivate Cloud وHybrid

لا يوجد نموذج واحد مناسب لكل الحالات.

Public Cloud يوفر مرونة وسرعة وصول إلى خدمات متقدمة.

Private Cloud يعطي المؤسسة قدرة أعلى على التحكم في بعض طبقات البنية.

Hybrid Cloud يسمح بتوزيع الأحمال وفق الحاجة.

لكن الاختيار الصحيح لا يجب أن يكون أيديولوجيًا.

السؤال الحقيقي هو:

ما الذي نحاول تشغيله؟

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

ما أثر توقف الخدمة؟

هل توجد قيود على موقع البيانات؟

وما مستوى الاعتماد المقبول على المزود؟

تصنيف AI Workloads

قبل اختيار البنية يجب تصنيف حمل AI نفسه.

يمكن أن نسأل:

هل النظام يستخدم بيانات عامة؟

هل يعالج بيانات شخصية؟

هل يعتمد على معلومات حكومية حساسة؟

هل يؤثر في خدمة حرجة؟

هل يحتاج إلى GPU مستمر؟

هل النموذج داخلي أم خارجي؟

هل هناك اتصال دائم بمزود دولي؟

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

موقع البيانات

Data Residency لا يساوي تلقائيًا Data Sovereignty.

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

لذلك يجب رسم البيئة كاملة.

أين قاعدة البيانات؟

أين النسخة الاحتياطية؟

أين Logs؟

أين Vector Database؟

أين تتم عملية Inference؟

ومن يستطيع إدارة البيئة؟

AI APIs والخدمات الخارجية

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

في هذه الحالة، جزء من المعالجة يخرج من البيئة المحلية.

يجب تحديد:

ما الذي يُرسل؟

هل تحتوي Prompts على بيانات حساسة؟

هل يحتفظ المزود بالمدخلات؟

هل تستخدم لتحسين النموذج؟

ما المنطقة التي تتم فيها المعالجة؟

وما البديل عند توقف الخدمة؟

الهوية وإدارة الوصول

البنية السحابية القوية لا تعني شيئًا إذا كانت الصلاحيات واسعة وغير مضبوطة.

AI workloads غالبًا تستخدم Service Accounts وAPI Keys وMachine Identities.

يجب تطبيق Least Privilege.

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

ويجب أن تكون كل هوية تقنية قابلة للتعطيل والتدوير والتدقيق.

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

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

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

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

فصل البيئات

Development وTesting وProduction يجب ألا تصبح بيئة واحدة.

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

يمكن استخدام بيانات مصغرة أو مجهولة أو تركيبية عندما يكون ذلك مناسبًا.

GPU Infrastructure

AI Infrastructure قد تحتاج إلى موارد حوسبة متخصصة.

لكن شراء GPU لا يجب أن يكون الهدف.

السؤال هو معدل الاستخدام الفعلي.

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

أما الأحمال المستمرة والحساسة فقد تبرر بنية مخصصة.

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

مراكز البيانات

مركز البيانات يمثل جزءًا من البنية وليس الحوكمة كلها.

وجود مركز حديث لا يحل مسائل:

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

الوصول.

الموردين.

الاختبار.

مراقبة النموذج.

أو القرارات المؤثرة.

يجب ألا تتحول مشاريع البنية إلى بديل عن بناء نظام Governance.

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

الذكاء الاصطناعي الذي أصبح جزءًا من خدمة عامة يحتاج إلى خطة عند الفشل.

ماذا يحدث إذا انقطعت السحابة؟

إذا توقف Model API؟

إذا تعطلت الشبكة؟

إذا فقد النظام الوصول إلى Vector Store؟

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

المرونة تبدأ من تحديد Maximum Tolerable Downtime لكل حالة استخدام.

Multi-Region لا يعني Resilience تلقائيًا

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

لكن إذا كانت المناطق تعتمد على نفس الهوية ونفس المورد ونفس Control Plane، يبقى هناك Concentration Risk.

المرونة تحتاج إلى تحليل نقاط الفشل المشتركة.

Vendor Concentration

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

يجب مراقبة التركّز مثلما نراقب مخاطر المورد الفردي.

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

Exit Strategy

قبل الدخول في العقد يجب معرفة طريقة الخروج.

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

هل يمكن نقل Vector Store؟

هل يمكن استبدال Model API؟

هل التطبيق مبني على خدمات Proprietary يصعب تحويلها؟

وكم يستغرق الانتقال؟

خطة الخروج ليست تشاؤمًا؛ هي جزء من إدارة الاعتماد.

Portability

من الأفضل الفصل قدر الإمكان بين Business Logic والمورد.

إذا كانت كل وظيفة في التطبيق مرتبطة بخدمة خاصة بمزود واحد، تصبح تكلفة الانتقال أكبر.

واجهات واضحة وطبقات Abstraction قد تساعد، لكن يجب موازنة ذلك مع التعقيد الإضافي.

سلسلة الموردين

Cloud Provider ليس بالضرورة المورد الوحيد.

قد تستخدم البيئة:

Model Provider.

Vector Database.

Monitoring Platform.

Security Service.

Open-source packages.

ومزود Connectivity.

يجب أن تعرف المؤسسة Dependency Chain الفعلية.

Shadow Cloud وShadow AI

الموظف أو الفريق قد يستطيع فتح حساب Cloud أو Model Service دون المرور بالمسار الرسمي.

بهذا تصبح البيانات موزعة خارج رؤية المؤسسة.

المنع فقط لا يكفي.

يجب أن يكون المسار الرسمي سريعًا بما يكفي حتى لا يصبح تجاوزه الخيار الأسهل.

Logging وObservability

AI workload يحتاج إلى مراقبة البنية والنموذج معًا.

على مستوى البنية نراقب:

CPU/GPU.

Latency.

Errors.

Availability.

على مستوى AI نراقب:

Quality.

رفض الطلبات.

Token Usage.

Tool Calls.

حوادث التسريب.

والانحراف.

جمع المنظورين يعطي صورة أكثر واقعية عن الخدمة.

الكلفة كعنصر حوكمة

تكلفة AI يمكن أن تتغير بصورة سريعة مع الاستخدام.

Service مفتوحة دون حدود قد تنتج فاتورة ضخمة أو استنزاف موارد GPU.

FinOps يصبح جزءًا من حوكمة AI.

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

البنية السيادية

مصطلح Sovereign AI لا يجب استخدامه بسهولة.

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

السيادة هنا درجة من التحكم في البيانات والبنية والنموذج والمهارات وسلسلة التوريد، وليست صفة ثنائية.

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

ابدأ من Use Case وليس من Cloud Product.

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

صنف الحساسية.

ارسم Data Flow.

حدد RTO وRPO.

اعرف الموردين.

حدد Exit Strategy.

ثم اختر Architecture.

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

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

لا ينبغي اعتبار السياسة الوطنية للحوسبة السحابية إطار AI Governance.

ولا يجب وصف كل استضافة محلية بأنها Sovereign AI.

ولا يعني توفر Cloud Service أن كل البيانات مناسبة لها.

ولا يعني تشغيل النظام على بنية حديثة أنه آمن أو محكوم.

الخلاصة

توسع البنية السحابية ومراكز البيانات في سوريا يرفع السقف التقني لما يمكن للمؤسسات تشغيله.

لكن كل قدرة جديدة تخلق طبقة Governance إضافية.

الحوسبة السحابية الجيدة تجعل AI أكثر قابلية للتوسع.

والحوكمة الجيدة تجعل هذا التوسع قابلًا للتحكم.

القرار الصحيح لا يبدأ بالسؤال: أي Cloud نختار؟

يبدأ بالسؤال: ما النظام الذي نبنيه، وما البيانات والقرارات والاعتماديات التي نحاول حمايتها؟