السيادة على البيانات
أين توجد بيانات العملاء — بما في ذلك البيانات الوصفية وبيانات القياس عن بُعد؟ من يمكنه الوصول إليها، وبأي صلاحيات، وهل يُسجَّل هذا الوصول بلا ثغرات؟ ولا يُعتدّ بالتشفير إلا إذا كانت إدارة المفاتيح محسومة أيضًا.
يحوّل EU Cloud & AI Development Act — واختصارًا CADA — نقاشًا استراتيجيًا إلى متطلب قابل للتدقيق: أربعة Union Assurance Levels متدرّجة، من موقع البيانات حتى السيطرة الفعلية على كل مكوّن برمجي. نحن نرتقي ببيئتكم السحابية وأدلة الإثبات لديكم وعقودكم إلى هذه المستويات.
الأرقام مأخوذة من المذكرة التفسيرية لـ Cloud & AI Development Act، مقترح المفوضية COM(2026) 502 final بتاريخ 3 يونيو 2026. لا يزال التشريع قيد الإجراءات التشريعية — وقد تتغير المعايير والمواعيد.
ظلّت «السيادة» لسنوات وعدًا في عروض المزوّدين. ومع Cloud & AI Development Act (CADA) تتحول إلى قائمة معايير يمكن لجهة تدقيق التحقق منها بندًا بندًا — وإلى شرط يحدد من سيحصل أصلًا على العقود العامة.
يغيّر CADA معيار التدقيق: لم يعد السؤال فقط أين توجد البيانات، بل من يستطيع في الحالات الحرجة التصرف فيها وفي التشغيل وفي البرمجيات. ويجب على الجهات العامة تحديد أحد مستويات CADA الأربعة لكل حالة استخدام، ولا يجوز لها إلا شراء الخدمات المعترف بها؛ ويمكن للجهات الحيوية بمفهوم توجيه NIS2 تطبيق المنطق ذاته. وبذلك تصبح السيادة الرقمية متطلبًا يجب توثيقه وتدقيقه وتأمينه تعاقديًا — وهنا تحديدًا نبدأ.
من يتحدث فقط عن مواقع مراكز البيانات يغطي ثلث الموضوع. أما البُعدان الآخران فيحسمان المستويات الأعلى في CADA.
أين توجد بيانات العملاء — بما في ذلك البيانات الوصفية وبيانات القياس عن بُعد؟ من يمكنه الوصول إليها، وبأي صلاحيات، وهل يُسجَّل هذا الوصول بلا ثغرات؟ ولا يُعتدّ بالتشفير إلا إذا كانت إدارة المفاتيح محسومة أيضًا.
من يشغّل الخدمة فعليًا؟ اعتبارًا من المستوى 2 يُعتدّ بموقع الموظفين وقنوات الدعم، واعتبارًا من المستوى 3 بجنسية موظفي التشغيل — وحيثما تُمسّ المعلومات المصنّفة — بالتدقيق الأمني الوطني.
من يقدّم الشيفرة، ومن يحق له تعديلها غدًا؟ يشترط المستوى الأعلى إثبات السيطرة الفعلية على التصميم والصيانة والإصلاحات الأمنية والتطوير لكل مكوّن برمجي ذي صلة.
يتضمن كل مستوى في Cloud & AI Development Act المستوى السابق ويشدّده. اختاروا مستوى — وتُظهر المصفوفة المعيار الذي يُضاف فيه.
اعتبارًا من هنا تتولى التدقيقَ جهةُ تدقيق مستقلة. والجديد هو أن يكون الموظفون والدعم حصرًا من داخل الاتحاد، وشهادة أوروبية للأمن السيبراني لا تقل عن مستوى «جوهري»، وحظر استخدام بيانات التشغيل لتدريب ذكاء اصطناعي تابع لدول ثالثة، إضافةً إلى SBOM كاملة مع تدقيق الشيفرة المصدرية للمكوّنات القادمة من دول ثالثة.
جديد في هذا المستوىيسري دون تغيير
إقامة البيانات بداية جيدة — وتغطي تحديدًا أدنى مستويات CADA. وتوفّر هذه المقارنة كثيرًا من سوء الفهم في المناقصات.
ثلاثة أسئلة لتوجيه أولي. أما التصنيف الملزم فيحدده تقييم المخاطر وفق المادة 29 من Cloud & AI Development Act.
لا يغني هذا التقدير عن الاستشارة القانونية ولا عن تقييم المخاطر. بل يُظهر النطاق الذي تقعون فيه على الأرجح — أما الإثبات الموثوق فنعدّه معًا.
ستة مكوّنات على امتداد Cloud & AI Development Act — يمكن طلب كل منها منفردًا، متناسقة فيما بينها ومصمّمة بحيث يُحتسب كل دليل إثبات أكثر من مرة.
نرصد بيئتكم السحابية ونقيّمها وفق الأبعاد الثلاثة: السيادة على البيانات، والسيادة على التشغيل، والسيادة التقنية. بما في ذلك الأسئلة التي نادرًا ما ترد في استبيان المزوّد — تدفقات البيانات الوصفية، ومسارات الدعم، وهيكل الملكية.
النتيجة: ملف سيادة لكل Workload مع تصنيف مبدئي للمستوى
نقارن وضعكم الحالي بالمستوى المستهدف، ونحدد حجم الفجوة كميًا، ونرتّب الأولويات حسب الجهد والاعتمادية ومدة العقد. ليس برنامجًا شاملًا مبالغًا فيه، بل تسلسل يمكن تنفيذه فعليًا.
النتيجة: خطة إجراءات مرتّبة الأولويات مع الجهد والتسلسل والمسؤوليات
نبني مسار SBOM الذي يشترطه المستوى 2، ونُعلّم المكوّنات القادمة من دول ثالثة، ونحدد آلية التعامل مع تدقيق الشيفرة المصدرية، ونوثّق وظائف الصيانة عن بُعد التي يجب تعطيلها.
النتيجة: توثيق لسلسلة التوريد قابل للتدقيق ويخدم CRA في الوقت نفسه
خطة ترحيل موثّقة لحالة تعطل أحد المورّدين ليست مجرد معيار للمستوى 2، بل إدارة فعلية للإسناد الخارجي. نحن لا نكتبها فحسب — بل نختبرها معكم.
النتيجة: خطة خروج مُختبَرة بدلًا من إعلان نوايا في الملحق
نصوغ متطلبات السيادة الرقمية بحيث ترتبط بموضوع التعاقد وتكون موثّقة ومن ثمّ صامدة أمام الاعتراضات — من توطين البيانات بما يشمل القياس عن بُعد حتى حقوق التدقيق وبنود الفصل.
النتيجة: بنود تعاقدية متينة ومعايير ترسية قابلة للتطبيق
نُعدّكم للتدقيق القادم: BSI C5 بوصفه شهادة تدقيق راسخة، وBSI C3A لبُعد السيادة، والعمل التمهيدي لمخطط أوروبي مستقبلي لاعتماد الخدمات السحابية.
النتيجة: ملف أدلة يصمد أمام تدقيق مستقل من طرف ثالث
يتشابك إطار السيادة في Cloud & AI Development Act مع لوائح تستوفونها أصلًا — ويشترط في جزء كبير منه أدلة الإثبات ذاتها.
يتبع تصنيف المستويات منطق القطاعات في توجيه NIS2. ومن صُنّف هناك بالفعل يعرف نطاق تطبيقه.
إلى الخدمةDORAتغطي التزامات السجل واستراتيجيات الخروج ومخاطر التركّز في DORA جزءًا كبيرًا من أدلة إثبات السيادة.
إلى الخدمةCRAالتزام SBOM هو من حيث المضمون الالتزام ذاته الذي يفرضه Cyber Resilience Act أصلًا. بناء واحد يخدم لائحتين.
إلى الخدمةBSI C5توفّر شهادة تدقيق C5 جزءًا كبيرًا من الأدلة التي تريد جهة التدقيق رؤيتها للمستويات 2 إلى 4.
إلى الخدمةBSI C3Aيتناول كتالوج معايير C3A تحديدًا أسئلة السيطرة التي سيجعلها الإطار الأوروبي إلزامية مستقبلًا.
إلى الخدمةEU AI Actتُعدّ أنظمة الذكاء الاصطناعي المستضافة والمشغّلة عن بُعد صراحةً خدمات سحابية — أي أن منطق المستويات يسري أيضًا على Managed-AI.
إلى الخدمةست خطوات مجدية بصرف النظر عن نتيجة الإجراءات التشريعية لـ CADA — لأن الأدلة ذاتها مطلوبة منذ زمن بموجب NIS2 وDORA وCRA.
ليس فقط «أي خدمة، وأي منطقة»، بل: من يملك المزوّد، وأين يوجد موظفو التشغيل، وأي متعاقدين من الباطن يكمنون في الحزمة التقنية؟
صنّفوا حالات الاستخدام لديكم تجريبيًا وفق المستويات الأربعة. ويُظهر هذا التمرين خلال ساعات قليلة أحمال العمل التي لا يوجد لها اليوم مزوّد مطابق.
قوائم المواقع، وسجلات الوصول، ومخططات تدفق البيانات، وSBOM: أدلة الملحق III محددة على نحو مدهش — وغير مكتملة في معظم المؤسسات.
توطين البيانات بما يشمل البيانات الوصفية، وقنوات الدعم، والفصل عن أجزاء المجموعة في دول ثالثة، وحقوق التدقيق. مكان ذلك جولة التفاوض القادمة، لا التي تليها.
الخطة التي لم تُجرَّب قط لا تساوي في التدقيق أكثر من إعلان نوايا. وتمرين واحد سنويًا يكفي لإحداث الفرق.
تجميع الأدلة، وتسمية المسؤوليات، وتوثيق مسار التدقيق — حتى لا تتحول المناقصة الأولى إلى عجز عن الإثبات.
أكثر ما يسألنا عنه صنّاع القرار بشأن CADA والسيادة السحابية.
لا. قدّمت المفوضية المقترح في 3 يونيو 2026؛ وهو يمر بالإجراء التشريعي العادي. ووفق المسودة تدخل اللائحة حيّز النفاذ في اليوم العشرين بعد نشرها في الجريدة الرسمية وتُطبَّق بعد ذلك بعام. وقد تتغير المعايير والمواعيد حتى ذلك الحين — أما الاستعداد لها فلا يتغير.
الملزَمون مباشرةً هم الجهات العامة وهيئات الاتحاد. ويجوز للجهات الواقعة ضمن نطاق توجيه NIS2 إجراء تقييمات مماثلة طوعًا، ويمكن للمفوضية لاحقًا جعل ذلك إلزاميًا لقطاعات معيّنة شديدة الحساسية. وبصرف النظر عن ذلك يضع الإطار معيارًا للسوق: فما يُشترط في المناقصات ينتهي، بحسب التجربة، في استبيانات المورّدين الخاصة أيضًا.
إنها تساعد كثيرًا، لكنها لا تغطي الإطار بالكامل. يتناول C5 أمن المعلومات في التشغيل السحابي، بينما يتناول إطار السيادة إضافةً إلى ذلك الملكية والسيطرة وموقع الموظفين وسلسلة توريد البرمجيات. وبالنسبة لبُعد السيطرة فإن كتالوج معايير C3A الصادر عن BSI هو الأقرب مقابلةً.
لم يُعتمد حتى اليوم مخطط اعتماد أوروبي خاص بالخدمات السحابية؛ وتُعدّ المفاوضات بشأنه متعثرة. ويعالج المقترح ذلك بقاعدة انتقالية: ما دام لا يوجد مخطط للاتحاد تسري المخططات الوطنية، وحيث تغيب هذه أيضًا يجب على المزوّد إثبات أعلى المعايير وفق قانون الاتحاد. وعمليًا يعني ذلك: بناء شهادات التدقيق الوطنية الآن مع مراعاة التوافق الأوروبي.
بالنسبة لبيئة سحابية متوسطة الحجم نقدّر من أسبوعين إلى أربعة أسابيع حتى الوصول إلى ملف السيادة، تبعًا لمدى متانة توثيق العقود والتشغيل لديكم. ويُبنى تحليل الفجوات عليه مباشرةً.
في الغالب لا — وبالتأكيد ليس على عجل. الأجدى هو فرز أحمال العمل الخاصة بكم، وتحسين وضع الإثبات، وبناء موقف تفاوضي للدورة التعاقدية القادمة. والتغيير خيار من بين عدة خيارات، لا نقطة الانطلاق.
مصادر أولية حول Cloud & AI Development Act للاطلاع — وصفحات المعرفة لدينا حول الموضوع.
ثلاثون دقيقة، ومحفظتكم الحقيقية، وتقدير صريح: نقارن بيئتكم السحابية بمستويات Union Assurance Levels الأربعة في Cloud & AI Development Act ونسمّي الفجوات التي يمكن سدّها اليوم.