سيادة البيانات في أفريقيا والخليج: نظرة مهندس معماريات البرمجيات

اسأل مدير أنظمة المعلومات في شركة بالدار البيضاء أو داكار أو نيروبي: أين توجد بيانات عملائكم فعلياً؟ في الغالب يأتي الجواب بعد لحظة تردد: في مكان ما في أوروبا، وربما في الولايات المتحدة، "في السحابة". وهذا ليس لوماً. فلسنوات طويلة لم يكن السؤال مطروحاً أصلاً. كانت الأدوات جيدة ورخيصة وسهلة النشر، ولم يكن أحد يطالب بتوضيحات.

لكن الوضع يتغير. الجهات التنظيمية أصبحت أكثر صرامة، والعملاء كذلك، ودخول الذكاء الاصطناعي (AI) إلى المؤسسات نقل الموضوع من مكاتب الشؤون القانونية إلى طاولة الإدارة العامة.

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

عن ماذا نتحدث بالضبط؟

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

• أين؟ في أي بلد وفي أي مركز بيانات تُخزَّن معلوماتك وتُعالَج؟
• من؟ من يستطيع الوصول إليها، بما في ذلك مزوّدو الخدمات لديك والمتعاقدون معهم من الباطن؟
• بأي قانون؟ أي تشريع يُطبَّق إذا طلبت محكمة أو إدارة أو حكومة أجنبية الاطلاع عليها؟

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

الموقع والتحكم والاختصاص القضائي: ثلاث خصائص منفصلة

كثيراً ما تختلط المصطلحات، وهذا أول مصدر لأخطاء التصميم. أميّز أربع خصائص لا تُستنتج إحداها من الأخرى.

• إقامة البيانات (Residency): الموقع الفعلي للبايتات، في حالة السكون وأثناء المعالجة. هذا ما يقيسه إعداد مثل region = "...".
• التحكم التشغيلي: من يستطيع التصرف في الخوادم والخدمات: مديرو المزوّد، فرق الدعم، المتعاقدون من الباطن، الأتمتة.
• التحكم التشفيري: من يملك المفاتيح وبالتالي يستطيع فك التشفير.
• الاختصاص القضائي: أي قانون يستطيع إلزام أي طرف بتقديم ماذا.

الاستضافة داخل البلد تحلّ الأولى فقط. ولا تحلّ الثانية (فمشغّل أجنبي يستطيع إدارة مركز بيانات محلي عن بُعد)، ولا الثالثة (قد تكون المفاتيح بيده)، ولا الأخيرة (فالقانون المطبّق على الشركة التي تشغّل الخدمة لا يتوقف على عنوان المبنى).

إطار قانوني يتشكّل

يزداد عدد الدول الأفريقية التي اعتمدت قانوناً لحماية البيانات الشخصية. المغرب بالقانون 09-08 وهيئة المراقبة CNDP، والسنغال وتونس بقوانينهما الخاصة، وكينيا بقانون حماية البيانات لسنة 2019، ونيجيريا بقانون حماية البيانات (NDPA) الموقّع في يونيو 2023 والذي أنشأ لجنة حماية البيانات النيجيرية، وجنوب أفريقيا بقانون POPIA. وعلى مستوى القارة، دخلت اتفاقية الاتحاد الأفريقي بشأن الأمن السيبراني وحماية البيانات الشخصية، المعروفة باتفاقية مالابو والمعتمدة سنة 2014، حيز التنفيذ في 8 يونيو 2023، بعد ثلاثين يوماً من إيداع التصديق الخامس عشر. غير أن أقلية فقط من الدول الأعضاء صدّقت عليها، ما يحدّ من أثرها العملي حالياً.

ويسير الخليج في الاتجاه نفسه بنصوص حديثة: المرسوم بقانون اتحادي رقم 45 لسنة 2021 في الإمارات العربية المتحدة (ساري منذ 2 يناير 2022)، ونظام حماية البيانات الشخصية (PDPL) في المملكة العربية السعودية الذي حُدّد تاريخ نفاذه في 14 سبتمبر 2023 بعد تعديل، تلتها فترة امتثال مدتها سنة. وتختلف المصادر في بعض تواريخ النشر الدقيقة، لذلك يجب في أي ملف حقيقي الرجوع إلى المصدر الرسمي.

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

الخطر الذي لا نراه: الاعتماد على الآخرين

بعيداً عن الامتثال، هناك سؤال أبسط: ماذا يحدث يوم يغيّر مزوّدك قواعد اللعبة؟

يبقى المزوّد الأمريكي خاضعاً للقانون الأمريكي حتى لو كانت خوادمه في بلد آخر. فقانون CLOUD Act الموقّع في 23 مارس 2018 يعدّل قانون الاتصالات المخزّنة (Stored Communications Act): يمكن إلزام مزوّد خدمات اتصالات إلكترونية أو حوسبة عن بُعد خاضع للقانون الأمريكي بتقديم البيانات الموجودة في "حيازته أو عهدته أو سيطرته"، سواء كانت داخل الولايات المتحدة أو خارجها. وقد نشأ عن القضية التي جمعت الولايات المتحدة بشركة Microsoft بشأن خوادم في دبلن. كما يفتح النص سبلاً محدودة للطعن، خصوصاً عندما يتعارض الطلب مع قانون حكومة أجنبية "مؤهَّلة". ولدى دول أخرى قواعد مماثلة. هذه ليست نظرية مؤامرة، بل نصوص قانونية مكتوبة.

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

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

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

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

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

classes:
  public:
    examples: [brochures, FAQ]
    location: any
    keys: provider_managed
  internal:
    examples: [wiki, non-customer tickets]
    location: region_or_country
    keys: customer_managed
  confidential:
    examples: [customer files, contracts]
    location: country
    keys: customer_managed_dedicated_hsm
    logging: full_access
  restricted:
    examples: [health data, banking secrecy, government files]
    location: country_controlled_infrastructure
    keys: outside_provider
    leaves_country: forbidden_without_written_waiver

رسم خريطة التدفقات هو التمرين الذي يخلّف أكبر المفاجآت. فمخطط البنية يُظهر التطبيق وقاعدة بياناته، وينسى ما يخرج: السجلات المرسلة إلى خدمة مراقبة SaaS (وفيها معرّفات العملاء)، وتقارير الأخطاء الحاملة للبيانات، والنسخ الاحتياطية المنسوخة افتراضياً إلى منطقة أخرى، ورسائل البريد الآلية، والتصديرات إلى أداة تحليل، والطلبات المرسلة إلى واجهة AI. أسجّل لكل تدفق المصدر والوجهة وفئة البيانات والمسار الشبكي ومن يستطيع فك التشفير في نهاية المسار وتحت أي قانون يقع هذا المستلم.

قاعدة عملية: عاملوا التدفقات الخارجة كقائمة بيضاء. كل تدفق يخرج نحو طرف ثالث يجب أن يكون معلناً ومرتبطاً بفئة. وجدار حماية تطبيقي أو بوابة خروج ترفض افتراضياً يحوّل الخريطة إلى رقابة فعلية، لا إلى وثيقة فقط.

التشفير: ما الذي يحلّه وما الذي لا يحلّه

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

النمط الشائع هو التشفير بالمغلّف (envelope encryption): يُشفَّر كل كائن بمفتاح بيانات (DEK)، يُشفَّر هو بدوره ("يُغلَّف") بمفتاح تشفير المفاتيح (KEK) المحفوظ في KMS أو HSM.

write : random DEK -> encrypts the object -> KEK wraps the DEK
        stored: encrypted object + wrapped DEK
read  : KMS call (unwrap DEK, logged) -> decrypts the object

الفائدة: لا يغادر مفتاح KEK أبداً نظام KMS أو HSM، وكل قراءة تمر عبر استدعاء مسجَّل وقابل للإلغاء. فيصبح سؤال السيادة: من يتحكم في KMS، ومن يستطيع أن يطلب منه فك التشفير؟

إدارة المفاتيح: أربعة نماذج

يُتداول BYOK وHYOK والمفاتيح التي يديرها العميل، وتختلف المصطلحات من مزوّد إلى آخر. أصف النماذج بما يهم: موقع مادة المفتاح وموقع العملية التشفيرية.

• مفاتيح يديرها المزوّد: يولّد المزوّد المفاتيح ويخزّنها ويستعملها. بسيط، لا شيء تشغّله، والتحكم التشفيري عائد له.
• مفاتيح يديرها العميل داخل KMS المزوّد (CMK): تتحكم في سياسة الوصول والتدوير والإلغاء، لكن مادة المفتاح والعملية تعيشان في بنية المزوّد.
• BYOK (أحضر مفتاحك): تولّد المفتاح في مكان آخر وتستورده. يمنحك ذلك نسخة مرجعية وإمكانية سحبه، لكن بعد الاستيراد يُستعمل داخل بنية المزوّد.
• HYOK أو مخزن مفاتيح خارجي: يبقى المفتاح في HSM أو مدير مفاتيح تشغّله أنت، وتُفوَّض كل عملية تشفير أو فك تشفير إلى نظامك. توثيق AWS KMS يصف هذا النموذج باسم "external key store" (XKS): لا يتحدث KMS إلا مع وسيط (proxy) تقدّمه أنت، ويصف المزوّد نفسه هذا الخيار بأنه خروج كبير عن نموذج المسؤولية المشتركة مع عبء تشغيلي إضافي، ويوصي بحصره في أعباء العمل التي تتطلبه.

الحدود الحقيقية

بعض الوقائع التي تُغفَل عادة في العروض.

1. الجاهزية تصبح مشكلتك. مع HYOK، إذا تعطل HSM أو الاتصال الشبكي به فالبيانات المشفّرة غير مقروءة. زمن استجابة إضافي في كل استدعاء، وتوافر عالٍ يجب تصميمه، وإجراءات استرجاع يجب اختبارها.
2. المعالجة تحتاج غالباً إلى النص الصريح. إذا كانت خدمة المزوّد تقرأ البيانات لفهرستها أو تحليلها أو تقديمها، فإنها تفكّ تشفيرها في الذاكرة مهما كانت طريقة توفير المفتاح. المفاتيح الخارجية تحمي أساساً البيانات الساكنة في خدمات لا تحتاج إلى النص الصريح.
3. توافق غير متساوٍ. لا تدعم كل خدمات المزوّد كل نماذج المفاتيح؛ يجب التحقق خدمة بخدمة، في تاريخ اتخاذ القرار.
4. المفتاح المسحوب ليس ضماناً قانونياً. يجعل البيانات غير مقروءة للمزوّد، لكنه لا يمنع سلطة من مطالبتك أنت بالمفتاح أو بالبيانات الصريحة، إذا كنت خاضعاً لذلك القانون.
5. من يحمل المفتاح مهم. تعدّ التوجيهات الأوروبية بشأن تدابير النقل التكميلية (توصيات 01/2020 الصادرة عن المجلس الأوروبي لحماية البيانات EDPB) التشفير فعالاً فقط إذا بقيت المفاتيح تحت السيطرة الحصرية للمصدِّر أو لكيان في إقليم يُعدّ كافياً. النص أوروبي، لكن المنطق مفيد: الحماية التشفيرية تساوي قيمة اختصاص من يحمل المفاتيح. لم أطّلع إلا على تعليقات حول هذا النص لا على مضمونه الكامل: يجب التحقق منه مباشرة قبل الاعتماد عليه.

الحوسبة السرية: مفيدة لكنها ليست سحراً

تستهدف الحوسبة السرية (Confidential Computing) البيانات "قيد الاستخدام": تُنفَّذ المعالجة داخل بيئة تنفيذ موثوقة (TEE) مدعومة بالعتاد ومُصادَق عليها. يحدد تحالف Confidential Computing Consortium ثلاث خصائص مستهدفة: سرية البيانات وسلامة البيانات وسلامة الشيفرة. وتتيح المصادقة (attestation) لطرف ثالث أن يتحقق عن بُعد من الشيفرة التي تعمل في البيئة المعزولة قبل تسليمها مفتاحاً.

النمط المفيد للسيادة هو هذا: لا يُفرج KMS الخاص بك عن المفتاح إلا لعبء عمل تطابق مصادقته قياساً متوقعاً. وعندئذ لا يستطيع مزوّد البنية قراءة ذاكرة الآلة الافتراضية.

الحدود، بصراحة:

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

أوصي بها كطبقة للحالات التي يكون فيها مزوّد البنية جزءاً من نموذج التهديد، لا كبديل عن التحكم في المفاتيح والموقع.

الذكاء الاصطناعي يغيّر حجم المشكلة

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

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

وهناك رهان ثانٍ أقل وضوحاً. فالنماذج الكبرى مدرّبة أساساً على بيانات قادمة من أمريكا الشمالية وأوروبا وآسيا. وهي لا تفهم جيداً الدارجة أو الولوف أو السواحيلية، فضلاً عن الواقع الإداري والضريبي المحلي. وإذا استُعملت البيانات الأفريقية لتدريب أنظمة صُمِّمت في الخارج، فإن القيمة التي تنتجها تذهب إلى الخارج أيضاً. التحكم في البيانات يعني كذلك الحفاظ على إمكانية بناء أدوات تفهم السوق المحلية فعلاً.

السيادة لا تعني أن تفعل كل شيء بنفسك

لنكن صريحين: لا تحتاج أي مؤسسة إلى بناء مركز بيانات خاص بها لتكون سيادية. كما أن البيانات ليست كلها بالأهمية نفسها. الكتيّب التسويقي يمكن استضافته على أي خدمة إلكترونية. أما البيانات الصحية أو المعلومات البنكية أو ملفات وزارة، فلا.

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

التسجيل وقابلية التدقيق

وعد السيادة من دون دليل لا يساوي إلا قدر الثقة التي يقوم عليها. ثلاثة عناصر تجعل الإثبات ممكناً.

• سجلات الوصول إلى البيانات والمفاتيح. كل استدعاء لـ KMS (فك التشفير، التغليف، تغيير السياسة) يجب أن يُسجَّل خارج النطاق الذي يراقبه، مع هوية المستدعي والمورد المعني. وتتابع استدعاءات فك التشفير خارج الأوقات المعتادة إشارة يمكن استثمارها.
• عدم القابلية للتعديل والفصل. تُكتب السجلات على تخزين للإضافة فقط أو غير قابل للتعديل، بصلاحيات مختلفة عن صلاحيات المديرين الذين تراقبهم.
• سجلات الخروج. تُسجَّل التدفقات الخارجة نحو أطراف ثالثة (ومنها واجهات AI) مع فئة البيانات، لا مع البيانات نفسها.

فخّ كلاسيكي: السجلات نفسها تصبح بيانات حساسة، وغالباً في منطقة أو لدى مزوّد مختلف. يجب تصنيفها مثل غيرها.

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

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

بعض الفحوص الملموسة:

1. الصيغة. هل البيانات قابلة للتصدير بصيغ مفتوحة (SQL قياسي، Parquet، صيغ كائنات موثقة)، أم بصيغة مملوكة فقط؟
2. الحجم وكلفة الخروج. كم يستغرق التصدير الكامل، وما رسوم النقل الخارج؟ الحساب بسيط: الحجم مقسوماً على عرض النطاق الفعلي، مضافاً إليه مدة التحقق. يُقاس على عينة، لا يُقدَّر.
3. الخدمات المُدارة الخاصة. كلما استعملت خدمات مملوكة أكثر (قواعد بيانات، طوابير، دوال)، صار الخروج إعادة كتابة. والبنية السداسية (hexagonal) بمحوّلات بين المنطق الوظيفي والخدمات تحدّ من الضرر.
4. المفاتيح. إذا كانت بياناتك مشفّرة بمفاتيح المزوّد، فتصديرها بنص صريح يكلّفك عملية فك تشفير جماعية. أما بمفاتيح تملكها، فالخروج يتم في كتلة متماسكة.
5. التمرين الفعلي. خروج لم يُختبر قط غير موجود. أوصي بتمرين سنوي: استعادة مجموعة بيانات ممثِّلة في بيئة أخرى وقياس الزمن.

نموذج تهديد واقعي

لتقرير ما يجب إقامته، يجب تسمية الخصم. الإجراءات المكلفة (HYOK، HSM مخصص، البيئات المعزولة) لا معنى لها إلا أمام خصوم معينين. أميّز ثلاث عائلات، دون ادعاء الشمول.

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

قائمة قرار للمهندس المعماري

لكل مجموعة بيانات أو خدمة، بالترتيب:

1. ما فئتها، ومن قرّرها؟
2. ما التدفقات الخارجة الموجودة، وهل كلها في السجل؟
3. من يستطيع قراءة البايتات بنص صريح، وتحت أي نظام قانوني يقع هذا الطرف؟
4. أين المفتاح، ومن يستطيع استعماله، وماذا يحدث إذا أُلغي؟
5. هل الوصول إلى البيانات والمفاتيح مسجَّل خارج النطاق المراقَب؟
6. هل يبرّر نموذج التهديد الكلفة الإضافية (HYOK، بيئة معزولة، استضافة مخصصة)، أم يكفي CMK؟
7. كم يلزم من الوقت لاسترجاع كل شيء والانطلاق في مكان آخر، وهل اختُبر ذلك؟
8. ماذا يقول القانون المحلي والقطاعي، مؤكَّداً من شخص مؤهل لقوله؟

من أين تبدأ؟

لا حاجة إلى برنامج تحوّل ضخم للتقدم. بضع خطوات تكفي لرؤية الصورة بوضوح:

1. الجرد. حصر البيانات التي تعالجها وتحديد الحساسة منها فعلاً.
2. معرفة وجهتها. التحقق، لكل أداة ولكل مزوّد، من مكان استضافة البيانات والقانون الذي يسري عليها.
3. تأطير استخدام AI. تحديد ما يمكن للفرق مشاركته مع الأدوات الخارجية وما لا يمكن، وتوفير بديل داخلي للاستخدامات الحساسة.
4. التخطيط للخروج. قبل التوقيع، اسأل نفسك كيف ستسترجع بياناتك وتغيّر المزوّد عند الحاجة.
5. تدريب الفرق. أفضل بنية تقنية لا فائدة منها إذا لم يفهم أحد سبب وجودها.

ما يجب أن نحتفظ به

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

المراجع

• AWS KMS: External key stores
• Microsoft: What is confidential computing?
• EDPS TechSonar: Confidential computing
• Strathmore CIPIT: the African Union Convention on Cyber Security and Personal Data Protection
• KPMG Nigeria: The Nigeria Data Protection Act, 2023
• Baker McKenzie: Saudi Arabia, PDPL compliance
• WilmerHale: Congress enacts law clarifying reach of warrants for overseas data (CLOUD Act)