Nvidia و Azure تدفعان Confidential Computing نحو التيار الرئيسي

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

يعكس السوق هذا التحول: يقدّر المحللون سوق الحوسبة السرية بنحو 16.7 مليار دولار في 2026، ارتفاعًا من نحو 12.3 مليار دولار في 2025، بمعدل نمو يتجاوز 35% سنويًا. تمثل الخدمات المالية قرابة نصف التبني في المؤسسات، والرعاية الصحية أكثر من الثلث، وتستخدم حوالي ثلاثة أرباع الوكالات الفيدرالية الأمريكية اليوم بعضًا من تقنيات البيئات الآمنة Secure-Enclave للأعباء الحساسة. لم يعد الأمر مجرد مربع امتثال متخصص — بل أصبح شرطًا أساسيًا لأي شخص يدير الذكاء الاصطناعي على بيانات لا يمكنه قانونًا أو تعاقديًا كشفها.

ما الذي تغير بالفعل

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

هذه هي المشكلة المحددة التي تحلها بيئات التنفيذ الموثوقة Trusted Execution Environments (TEEs): مناطق ذاكرة معزولة ومشفرة بواسطة العتاد، حيث تكون الشيفرة والبيانات محمية حتى من مشرف افتراضي مخترق، أو مشغل سحابة، أو مستخدم جذر. في عام 2026، يمتد جذر الثقة العتادي هذا إلى ما بعد المعالج CPU وصولًا إلى GPU لأول مرة على نطاق واسع.

العتاد: كل من المعالجات CPU وGPU تقوم بذلك الآن

أربع بنى لـ TEE تهيمن على النشر الحالي:

• Intel TDX (Trust Domain Extensions) — يعزل الأجهزة الافتراضية الكاملة، يُستخدم بكثافة على مثيلات Azure و Google Cloud الخاصة بالأجهزة الافتراضية السرية.
• AMD SEV-SNP (Secure Encrypted Virtualization–Secure Nested Paging) — الخيار الأكثر انتشارًا عبر AWS و Azure و Google Cloud، مفضل لتراجع الأداء الأقل في أعباء الحساب بفضل تسريع تشفير الذاكرة عبر عتاد AES-NI.
• ARM CCA (Confidential Compute Architecture) — أحدث، يستهدف الأجهزة المحمولة والحافة حيث يحتاج الاستدلال السري إلى الحدوث خارج مركز البيانات بالكامل.
• Nvidia Hopper confidential computing — كان H100 أول GPU مزود بـ TEE قائم على العتاد ومَرتكز على جذر ثقة على الشريحة؛ ويمد H200 هذا الأمر. هذه هي القطعة التي جعلت استدلال الذكاء الاصطناعي السري ممكنًا، لأنها تحمي البيانات وأوزان النموذج بينما يقوم GPU بالحساب فعليًا، وليس فقط عندما تكون في ذاكرة المعالج.

قصة الأداء هنا أفضل مما يفترضه معظم المهندسين. في أعباء العمل المرتبطة بالحساب على المعالج، تبلغ نسبة التراجع في الأداء لكل من SEV-SNP و TDX حوالي 1-5% تقريبًا. في وضع GPU السري من Nvidia، تظهر المقاييس المعيارية المستقلة أن استدلال النماذج اللغوية الكبيرة LLM يصل إلى 95-99% من الإنتاجية الأصلية — بالنسبة لمعظم الاستعلامات، يبقى التراجع أقل من 5%، ويقترب من الصفر للنماذج الأكبر والتسلسلات الأطول، حيث أن تكلفة التشفير تُوزَّع على كمية حساب أكبر لكل بايت يُنقل عبر الحدود بين CPU وGPU.

من يدير هذا فعليًا في الإنتاج

جميع مزودي السحابة الفائقة الثلاثة الكبار يشحنون اليوم بنية تحتية للذكاء الاصطناعي السري، وليس كميزة على خارطة الطريق. Azure Confidential Computing يزاوج بين Intel TDX و AMD SEV مع أجهزة افتراضية سرية على GPU مبنية على H100، مسوقة خصيصًا لنشر النماذج اللغوية الكبيرة في القطاعات الخاضعة للتنظيم. AWS تقدم Nitro Enclaves إلى جانب عائلات مثيلات EC2 المدعومة بـ SEV-SNP. Google Cloud من خلال Confidential Space و Confidential VMs تستهدف نفس حالة الاستخدام، موضوعة للتعاون على البيانات بين أطراف متعددة حيث لا يستطيع أي طرف واحد رؤية مدخلات الأطراف الأخرى.

نشر ملموس يدعم ذلك. قامت NTT DATA و IBM ببناء SimpliZCloud، منصة سحابية هجينة للمؤسسات المالية الهندية تستخدم الحوسبة السرية لحماية البيانات أثناء المعالجة، وليس فقط التخزين. وزارة الدفاع الأمريكية أجازت بنية تحتية سحابية مدعومة بالحوسبة السرية لعمليات حيوية عبر عدة وكالات فيدرالية. هذه ليست تجارب — بل أنظمة إنتاج مالية وحكومية حيث لم يعد "قمنا بتشفير قاعدة البيانات" كافيًا للوفاء بالمتطلبات التنظيمية أو التعاقدية.

المشكلة غير المحلولة: التوثيق Attestation

هنا يسبق السرد السائد التكنولوجيا. يعتمد نموذج الثقة للحوسبة السرية على التوثيق عن بُعد remote attestation — دليل تشفيري على أن عبء العمل يعمل بالفعل داخل بيئة TEE حقيقية غير معدَّلة قبل إرسال بيانات حساسة إليها. بالنسبة لـ TEE على المعالج فقط، يصدر بائع واحد هذا الدليل. أما بالنسبة لاستدلال الذكاء الاصطناعي السري، فأنت تحتاج الآن إلى توثيق من بائع المعالج و بائع GPU في وقت واحد، كل منهما بسلسلة توريد منفصلة، وجذر ثقة منفصل، وأدوات تحقق منفصلة. يطلق باحثو الأمن على هذه مشكلة "المُصدِّق المُركَّب" (Composite Attester)، ولا يوجد معيار واحد حتى الآن للتحقق منها من النهاية إلى النهاية.

بل إن الأمر يزداد سوءًا: تحقيق أجرته مجلة Register نُشر في 4 يوليو 2026 فصَّل كيف أن العديد من مخططات "التوثيق أثناء المصافحة" (intra-handshake attestation) المقترحة — حيث يثبت TEE نفسه أثناء مصافحة TLS — لا تزال معرضة لهجمات الترحيل (relay attacks)، حيث يتحقق العميل بنجاح من بيئة موثوقة حقيقية لكنه ينتهي به الأمر بإرسال حركة مرور مشفرة إلى بيئة أخرى خبيثة بالكامل. لم تسد أي من الطرق التشفيرية السبع التي تم اختبارها حتى الآن هذه الثغرة بالكامل. هذا ليس خطأ تنفيذ بسيطًا؛ بل هو ضعف بنيوي في كيفية تأسيس الثقة، ويعني أن "نحن نستخدم الحوسبة السرية" ليس في حد ذاته ادعاء أمنيًا كاملاً دون السؤال أيضًا عن كيفية التحقق من التوثيق ومن يقوم بذلك.

متى تحتاج هذا بالفعل

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

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

على الأرجح لا تحتاجها للتحليلات الداخلية على بنيتك الخاصة، أو لمجموعات البيانات العامة أو مجهولة المصدر بالفعل، أو كبديل للتحكم الأساسي في الوصول ونظافة التشفير — تلك المشاكل أرخص حلها بالطرق التقليدية، وTEEs تضيف تكلفة تشغيل حقيقية: حدود تطبيقات متغيرة، بنية تحتية للتوثيق، والارتباط ببائع معين لأجيال محددة من عتاد CPU/GPU.

الخلاصات

• استدلال الذكاء الاصطناعي السري جاهز للإنتاج على جميع السحابات الثلاث الكبرى اليوم، مع TEEs على GPU من H100/H200 تحقق أكثر من 95% من الأداء الأصلي لمعظم أعباء العمل — لم يعد الأداء هو العائق الذي كان عليه قبل عامين.
• التوثيق، وليس التراجع في الحساب، هو مشكلة الهندسة الحقيقية غير المحلولة. قبل تبني الحوسبة السرية، اسأل بائعك تحديدًا كيف يتعامل مع التوثيق المُركَّب لـ CPU وGPU، وهل يعتمد على أي من مخططات المصافحة الداخلية التي تم الإبلاغ عن ثغراتها ضد هجمات الترحيل.
• احتفظ بـ TEEs للحالات التي يجب فيها استبعاد مشغل البنية التحتية من نموذج التهديد — استدلال GPU تابع لطرف ثالث على بيانات منظّمة، أو حساب متعدد الأطراف. لا تنشرها كترقية عامة لتشفير حالة السكون؛ التكلفة التشغيلية لا تبرر ذلك هناك.
• خصص ميزانية لطبقة التوثيق، وليس فقط عتاد TEE. خدمات التوثيق المستقلة وأدوات التحقق مفتوحة المصدر من Confidential Computing Consortium هي حاليًا الطريقة العملية لتجنب بناء هذا من الصفر.