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

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

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

الاستضافة الذاتية تحل مشكلة السيادة. أما الاستنتاج على الجهاز فيحل المشكلتين معاً. هذه هي النسخة الأكثر دقة لأطروحة هذا المقال، وهي التي سندافع عنها في بقية أجزائه.
خيار واحد يستحق الاستبعاد قبل طرحه: لماذا لا يتم تشغيل الاستنتاج مباشرة على البيانات المشفرة باستخدام التشفير المتماثل بالكامل، والحصول على قدرات السحابة دون أي ثقة على الإطلاق؟ لأنه لا يعمل بهذا النطاق بعد؛ حيث يقدر خبير التشفير ماثيو جرين أن أفضل الأنظمة المتاحة تتعامل فقط مع نماذج صغيرة جداً، وهي النوع الذي يمكنك تشغيله بالفعل على جهاز عميل ضعيف. التشفير المتماثل بالكامل هو الحل الصحيح مستقبلاً، وليس حلاً يمكنك طرحه في عام 2026.
إن القول بأن الاستدلال السحابي يكسر التشفير من طرف إلى طرف ليس مجرد وجهة نظر تسويقية للشركات، بل هو موقف معلن لأشخاص لا يملكون منتجاً لبيعه.
ورقة بحثية صدرت في ديسمبر 2024 عن باحثين في جامعتي نيويورك وكورنيل — كيف نفكر في التشفير من طرف إلى طرف والذكاء الاصطناعي — تجادل بأن دمج مساعدي الذكاء الاصطناعي يجبرنا إما على إعادة تعريف ماهية "نقطة النهاية"، أو الاعتراف بأن حدود التشفير قد تم توسيعها. وهناك ثلاث توصيات من الورقة تستحق الاهتمام هنا:
- التدريب أمر مستبعد. استخدام المحتوى المشفر من طرف إلى طرف لتدريب نماذج الذكاء الاصطناعي المشتركة يتعارض تماماً مع مبدأ التشفير من طرف إلى طرف. هذه ليست منطقة رمادية، وليست مشكلة موافقة، بل هو تعارض جوهري.
- المعالجة ممكنة، بشروط. تشغيل ميزات الذكاء الاصطناعي على محتوى مشفر من طرف إلى طرف لا يتوافق مع ضمانات الخصوصية إلا إذا "أعطيت الأولوية للمعالجة المحلية على الجهاز حيثما أمكن"، وفقط إذا لم يتمكن أي طرف ثالث من رؤية المحتوى أو استخدامه في أي مرحلة.
- معطلة افتراضياً. يجب أن تأتي ميزات الذكاء الاصطناعي في الأنظمة المشفرة معطلة بشكل افتراضي، ولا يتم تفعيلها إلا بموافقة صريحة من المستخدم، بدلاً من فرضها كقرار تقني نيابة عنه.
هذا الشرط الأوسط هو ما تجاهلته الصناعة بهدوء. الاستدلال على الجهاز ليس مجرد تفضيل تسويقي، بل هو البند الأول في قائمة خضعت لمراجعة الأقران حول ما يلزم لتعايش الذكاء الاصطناعي مع التشفير من طرف إلى طرف.
رسمت سيجنال (Signal) خطاً فاصلاً حاداً. فقد وصفت رئيستها ميريديث ويتاكر الذكاء الاصطناعي الوكيل بأنه "وضع عقلك في جرة"، بحجة أن المساعد الذي يتمتع بذكاء كافٍ للتصرف نيابة عنك يحتاج إلى صلاحيات وصول شبه كاملة لقواعد بيانات كل تطبيق، وعادة ما تكون البيانات مكشوفة، ومن المؤكد تقريباً أنه سيعالج تلك البيانات في السحابة. وتخلص إلى أن منح مثل هذا الوصول من شأنه أن يقوض قدرة سيجنال على توفير الخصوصية على مستوى التطبيق تماماً. ولهذا لم تطرح سيجنال أي ميزات للذكاء الاصطناعي التوليدي.
هذه إجابة متماسكة لهذه المشكلة، لكنها ليست الإجابة الوحيدة.
من المهم وضع الأمور في نصابها: البنيتان التاليتان تمثلان الحالة المثالية — أي كيف يبدو الهندسة الجادة عندما تتعامل الشركة مع المشكلة بجدية. أما الوضع الافتراضي فلا يزال هو الاستدلال السحابي العادي، حيث تكون الإخفاقات أمراً روتينياً وليست استثنائية. اكتشف مستخدمو ميتا للذكاء الاصطناعي (Meta AI) أن مطالباتهم كانت عامة بسبب ميزة مشاركة أسيء فهمها. لم يكن هناك عطل تقني، بل إن البنية التحتية ببساطة لم تكن تمتلك أي وسيلة لمنع ذلك.
هناك شركتان قامتا بعمل حقيقي في هذا المجال:
- نظام الحوسبة السحابية الخاصة من Apple (يونيو 2024) هو بنية أمنية للذكاء الاصطناعي السحابي هي الأكثر شفافية على الإطلاق. أحد التزاماته الخمسة تفرضه التشفير بدلاً من الوعود: لن يرسل جهاز Apple بيانات إلا إلى عقدة يمكنها إثبات تشغيلها لبرمجيات مدرجة علنًا من خلال التشفير. وقد نشرت Apple صور البناء، وأصدرت الكود المصدري، وأنشأت بيئة بحثية للفحص الخارجي، ووسعت نطاق برنامج مكافآت الثغرات الأمنية ليشمل هذا النظام.
- المعالجة الخاصة في WhatsApp تعتمد على بيئة التنفيذ الموثوقة (TEE)، وهي عديمة الحالة واختيارية، وتستخدم بروتوكول HTTP الغامض وبيانات اعتماد مجهولة الهوية حتى لا تتمكن Meta من ربط الطلب بحساب معين. كما نشرت Meta الجملة الأكثر فائدة في هذا المجال - وهي تحذير بشأن بنيتها الخاصة: "لقد أثبت باحثو الثغرات الأمنية مرارًا وتكرارًا القدرة على تجاوز ضمانات بيئة التنفيذ الموثوقة (TEE)."
إذا كان لا بد من إجراء الاستدلال السحابي، فهذه هي الطريقة الصحيحة للقيام بذلك. وهو ما يجعل ما وجده المدققون أكثر أهمية، وليس العكس.
قامت شركة Trail of Bits بتدقيق المعالجة الخاصة قبل الإطلاق وأبلغت عن 28 مشكلة، ثماني منها ذات خطورة عالية. النقطة الأكثر دلالة هي: أن النظام كان يحمل ملفات التكوين التي تحتوي على متغيرات البيئة بعد إجراء قياس المصادقة. كان بإمكان موظف داخلي خبيث في Meta حقن متغير LD_PRELOAD لتحميل كود عشوائي داخل المنطقة المحمية (enclave)، ومع ذلك كانت المصادقة ستظل صالحة. قامت Meta بإصلاح الثغرات، وأضافت رموزاً فريدة لكل جلسة (nonces) لمنع إعادة تشغيل المصادقة، و نشرت التقارير. كما أشار المدققون إلى أن عمليات البناء القابلة للتكرار بالكامل لصور المنطقة المحمية لا تزال صعبة التحقيق، مما يحد من التحقق المستقل. وخلصوا إلى أن "بيئات التنفيذ الموثوقة (TEEs) ليست حلاً سحرياً". الدرس الأعمق يكمن في تلك النتيجة الأولى: المصادقة تغطي فقط ما تقيسه، وكل ما يتم تحميله بعد ذلك يقع خارج نطاق الضمان.

لا تزال ضمانات بيئة التنفيذ الموثوقة (TEE) تفشل أيضاً على مستوى الأجهزة. في أكتوبر 2025، قام باحثون في معهد جورجيا للتكنولوجيا وجامعة بوردو ببناء جهاز وسيط لناقل ذاكرة DDR5 بأقل من 1000 دولار، ونشروا ما تمكنوا من اختراقه:
- Intel SGX و Intel TDX و AMD SEV-SNP — بما في ذلك SEV-SNP مع تفعيل خاصية إخفاء النص المشفر (Ciphertext Hiding)
- مفاتيح توقيع ECDSA خاصة، مستخرجة من تطبيق OpenSSL يعمل بزمن ثابت داخل جهاز افتراضي من نوع SEV-SNP
- مفتاح اعتماد التزويد (Provisioning Certification Key)، مستمد من خادم Xeon محدث بالكامل وفي حالة موثوقة
- عملية التصديق (Attestation) بحد ذاتها، تم تزويرها — وبما أن الأجهزة الافتراضية السرية هي الركيزة التي يعتمد عليها حوسبة NVIDIA الرسومية السرية، فقد تم تزوير تصديق وحدة معالجة الرسومات (GPU) معها أيضاً.
توضيح صريح: يتطلب هذا الهجوم وصولاً مادياً إلى الخادم. وهذا يستبعد المهاجمين عن بُعد، لكنه لا يستبعد مشغل السحابة، أو فني مركز البيانات، أو أي شخص قادر على إجبارهم على التعاون. بمعنى آخر، ينطبق هذا التهديد تماماً على نموذج التهديدات الذي وُجدت الحوسبة السرية لمعالجته.
كما أن هذا الأمر يقترب من أحدث عمليات النشر لدى شركة Apple.
في يونيو 2026، وسعت Apple نطاق "الحوسبة السحابية الخاصة" (Private Cloud Compute) ليشمل بنية Google Cloud التحتية التي تعمل بوحدات معالجة رسومات NVIDIA السرية وتقنية Intel TDX، مما جعل عملية التصديق تستند إلى مصدرين مستقلين على الأقل للثقة من الموردين. إن تصميم الجذر المزدوج هذا يمثل تخفيفاً حقيقياً للمخاطر، وهو أكثر مما قد يبنيه معظم الموردين. لكن سلسلة الثقة أصبحت الآن أطول مما كانت عليه في معالجات Apple، وليست أقصر.
الاستنتاج ليس أن بيئات التنفيذ الموثوقة (TEEs) عديمة الفائدة. بل هو استنتاج أكثر تحديداً:
تقلل الاستدلالات السحابية السرية من مساحة الثقة. أما الاستدلال على الجهاز نفسه فيلغي الحاجة إلى مزود الخدمة تماماً.
يعبر ماثيو غرين عن هذا المبدأ بشكل أفضل مما يمكننا فعله. فلعقود من الزمن، كما يكتب، كان الهدف من التشفير هو إزالة الثقة، "لاستبدال عبارة 'أعدك ألا أنظر' بعبارة 'لا أستطيع النظر'". وهو يعتقد أن الحوسبة السرية تعمل على الأرجح ضد الخصم الذي صُممت للحماية منه. ومع ذلك، يظل حكمه نابعاً من المبدأ ذاته: "الحوسبة السحابية الخاصة" توفر ضماناً أضعف بكثير من التشفير، لأن أمنها يعتمد على صحة قدر كبير من الأجهزة والبرمجيات بدلاً من الاعتماد على رياضيات التشفير.

بعد أن أصبح للاستضافة الذاتية عمودها الخاص، توقف الجدول عن كونه مجرد مقارنة بين خيارين وأصبح أداة مفيدة.
هناك صفان يستحقان التوسع، بالإضافة إلى أمر واحد لا يمكن للجدول توضيحه.
من يمكنه قراءة المحتوى. كلمة "لا أحد" في العمود الأخير تؤدي دوراً جوهرياً، وعبارة "مديروك الخاصون" في العمود الثالث ليست مجرد تلطيف لفظي. لاحظ أيضاً أن النص الصريح ليس الشيء الوحيد الذي يستحق الحماية؛ فالتضمينات (embeddings) ليست وسيلة لإخفاء الهوية. أظهر بحث قُدّم في مؤتمر EMNLP 2023 أن طريقة تُسمى Vec2Text يمكنها "استعادة 92% من مدخلات النصوص المكونة من 32 رمزاً بدقة" من متجهات التضمين الخاصة بها، واستعادت 89% من الأسماء الكاملة من مجموعة بيانات للملاحظات السريرية المضمنة. خلص المؤلفون إلى أن التضمينات يجب أن تُعامل كبيانات خاصة شديدة الحساسية وتُحمى تماماً كما يُحمى النص الخام. إذا كانت بنيتك التحتية ترسل التضمينات إلى أي مكان، حتى إلى مخزن المتجهات الخاص بك، فقد أرسلت النص فعلياً.
أوامر الاستدعاء والاحتفاظ بالبيانات. في مايو 2025، أمر قاضٍ فيدرالي أمريكي شركة OpenAI بحفظ وفصل جميع بيانات سجلات المخرجات التي كان من المفترض حذفها، بغض النظر عما إذا كان المستخدم قد طلب حذفها أو كانت لوائح الخصوصية تفرض ذلك. شمل هذا الأمر أكثر من 400 مليون مستخدم. وبحلول نوفمبر، أمرت المحكمة بتقديم 20 مليون محادثة مجهولة الهوية للمدعين في القضية الإخبارية؛ وأيد قاضي المقاطعة هذا القرار بالكامل في يناير 2026. لاحظ ما تم تجاوزه هنا: ليس مجرد سياسة شركة، بل طلب حذف صريح من المستخدم وحدود احتفاظ فرضها المنظمون. سياسات الاحتفاظ بالبيانات هي وعود، أما أوامر المحكمة فليست اختيارية.
هناك أيضاً بُعد زمني تغفله معظم نماذج التهديد. وهوالجمع الآن، وفك التشفير لاحقاً: التشفير ما بعد الكم يحمي النقل ولكنه لا يفعل شيئاً تجاه نسخة النص الصريح الموجودة في سجلات المزود، والتي لا تتطلب أي تحليل تشفيري على الإطلاق. البيانات التي لا تغادر جهازك لا تملك نافذة زمنية للجمع.
نقل الاستدلال ليعمل على الجهاز لا يلغي المخاطر. يصبح جهازك هو قاعدة الحوسبة الموثوقة بالكامل، والبرمجيات الخبيثة المقيمة على الجهاز، أو الاختراقات على مستوى نظام التشغيل، أو برامج التجسس الموجهة، تهزم الذكاء الاصطناعي على الجهاز بنفس الكفاءة التي تهزم بها التشفير من طرف إلى طرف.
أفضل مثال على ذلك هو ميزة Microsoft Recall. تعمل Recall محلياً بالكامل، بدون سحابة، وبدون مزود، وبدون نقل بيانات. وفقاً لمنطق النصف الأول من هذا المقال، كان ينبغي أن تكون مكسباً للخصوصية. بدلاً من ذلك، خزّن الإصدار الأولي فهرسه دون حماية كافية، مما دفع مايكروسوفت لسحب الميزة لإعادة بنائها. أضاف الإصدار المعاد إطلاقه التشفير أثناء التخزين، وتفعيل ميزة Windows Hello، وخيارات افتراضية تتطلب موافقة المستخدم، مع تصريح مايكروسوفت بأن البنية الجديدة ستقيد البرمجيات الخبيثة التي "تحاول استغلال مصادقة المستخدم لسرقة البيانات". في أبريل 2026، نشر الباحث الذي اخترق الإصدار الأول، ألكسندر هاجيناه، إثبات مفهوم يوضح أن ذلك لا يزال ممكناً: عبر برمجيات خبيثة تعمل بصلاحيات مستخدم عادي، دون الحاجة لصلاحيات مدير أو استغلال لنواة النظام. مايكروسوفت ترفض اعتبار ذلك ثغرة أمنية.
الدرس ليس أن الذكاء الاصطناعي المحلي سيء. فبنية Recall التي تعتمد على المحلية أولاً هي لا تزال أكثر خصوصية من إرسال لقطات الشاشة نفسها إلى بائع خارجي. الدرس هو أن "التشغيل على الجهاز" شرط ضروري، لكنه ليس كافياً. لكي يصح هذا الادعاء، يجب أن تتحقق كل الشروط التالية:
- لا يوجد بديل سحابي. ليس للاستعلامات المعقدة، أو المستندات الطويلة، أو الأجهزة ذات الذاكرة المحدودة.
- لا توجد قياسات عن بُعد للمحتوى. سجلات الأعطال، وخطوط أنابيب الجودة، وخدمات ES، والتحليلات يجب ألا تحمل أبداً محتوى الرسائل.
- تخزين محلي مشفر. ترث مخرجات النموذج وذاكرات التخزين المؤقت والفهارس حماية قاعدة بيانات الرسائل.
- قناة تحديث قابلة للتحقق. يجب ألا تسرب طلبات التحديث الميزات التي يعتمد عليها المستخدم.
- نطاق عمل صادق. التصريح بوضوح بأن اختراق الجهاز يبطل هذا الضمان.
هذه التزامات هندسية قابلة للتدقيق. فالمورد الذي يرفض توثيقها كتابةً لم يلتزم بها فعلياً.
الشرط الثالث هو الأكثر عرضة للفشل في هذا القطاع، ومن المفيد توضيح شكل هذا الفشل. في مايو 2026، كشف باحثون في Mysk أن تطبيق واتساب يخزن سجل المحادثات بالكامل في قاعدة بيانات SQLite بنص واضح داخل حاوية تطبيقات مشتركة، وهي قابلة للقراءة من قبل أي تطبيق تابع لنفس مجموعة المطورين، وهو ما يعني في حالة شركة ميتا، فيسبوك وإنستغرام. هذا ليس خطأً برمجياً، بل قرار معماري مطبق منذ سنوات ويؤثر على مليارات المستخدمين. لقد كتبنا عن ذلك في ذلك الوقت.
لاحظ ما يعنيه ذلك بالنسبة للذكاء الاصطناعي على الجهاز. إن نموذجاً محلياً يلخص الرسائل في ظل هذه البنية سيعمل على القراءة من والكتابة إلى وحدة تخزين يمكن لشركة أخرى الوصول إليها بالفعل. ستكون عبارة "يعمل على هاتفك" صحيحة ولكنها عديمة القيمة. لا يحقق الاستدلال المحلي مكسباً في الخصوصية إلا إذا كانت البيانات المحلية التي يتعامل معها مشفرة في حالة السكون ومعزولة عن التطبيقات الأخرى، وهذا هو السبب في أننا بنينا تلك الطبقة قبل سنوات من بناء النماذج، ولهذا السبب نحن مستعدون لتشغيل الاستدلال عليها الآن.
هناك نمط فشل آخر خاص بهذه البنية، ومن الأفضل طرحه هنا بدلاً من أن يكتشفه القارئ بنفسه. يسميه سايمون ويليسون "الثلاثية القاتلة": الوصول إلى البيانات الخاصة، والتعرض لمحتوى غير موثوق، والقدرة على إرسال اتصالات خارجية. اجمع بين الثلاثة، وستحصل على آلة لتسريب البيانات، لأن المهاجم يمكنه إخفاء تعليمات داخل المحتوى غير الموثوق وجعل النموذج ينفذها. يأخذ القطاع هذا الأمر على محمل الجد في الممارسة العملية؛ ففي يونيو 2026، أطلقت OpenAI وضع القفل الذي يقطع ببساطة البحث عبر الويب لمنع تسرب المستندات من خلال حقن الأوامر.
يتمتع مساعد المراسلة على الجهاز بالركيزتين الأوليين ويفتقر عمداً إلى الثالثة. الرسائل الواردة هي محتوى غير موثوق تماماً؛ ويمكن للنموذج بالتأكيد قراءة محادثاتك الخاصة. ولكن مع عدم وجود مخرج للشبكة، لا توجد قناة لخروج البيانات المستخرجة. هذا ليس صدفة في التصميم، بل هو السبب وراءه.

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

أعد قراءة هذه القائمة: تلخيص الرسائل الواردة، والمساعدة في صياغة الرسائل.
هذا ليس مجرد هامش لمنتجنا، بل هو جوهر منتجنا. إن أبرز المشككين في استدلال الذكاء الاصطناعي الخاص يقر بأن هذا التكوين تحديداً آمن، لكنه ببساطة يراه مملاً.
بالنسبة للاتصالات الآمنة، الملل هو المعيار المطلوب.
لا يتمثل موقف RealTyme في أننا أضفنا ذكاءً اصطناعياً، بل في أن الذكاء الاصطناعي يعمل حيث توجد رسائلك بالفعل: على جهازك، داخل نطاق التشفير نفسه الذي يحمي المحادثة ذاتها.
من الناحية العملية، يعني هذا أربعة أمور يمكن لمسؤول الأمن التحقق منها بدلاً من قبولها كمسلمات:
1. لا يغادر أي نص واضح الهاتف. لا للاستعلامات المعقدة، ولا للمستندات الطويلة، ولا كخيار احتياطي صامت في الأجهزة ذات الذاكرة المحدودة.
2. لا توجد نقطة نهاية للاستدلال تنضم إلى محادثتك. لا يوجد طرف ثالث للمصادقة أو التدقيق أو الثقة به.
3. لا توجد سياسة احتفاظ بالبيانات تقف بين بياناتك وأي أمر قضائي. لا يوجد سجل يمكن حفظه.
4. لا حاجة لإجراء تحليل لنقل البيانات عبر الحدود. البيانات لا تعبر الحدود أبداً.
وأربعة مقايضات نقبل بها بدلاً من إخفائها:
- نموذج مخصص لما تؤديه النماذج الصغيرة بشكل جيد حقاً، دون تسويقه كأكثر من ذلك.
- حدود صادقة للهجات العربية، مع توفير أرقام دقيقة لكل لهجة عند الطلب بدلاً من الاكتفاء بمتوسطات مضللة.
- مخاطر النزاهة الناتجة عن حقن الأوامر (Prompt Injection) التي نعمل على تخفيف حدتها بدلاً من الادعاء بحلها نهائياً.
عندما يتجاوز حجم العمل ما يمكن للهاتف القيام به فعلياً، فإن الحل ليس في استخدام نقطة نهاية لنماذج خارجية، بل في نشر النموذج ضمن بيئة تتحكم فيها أنت: محلياً (on-premises)، أو عبر عقدة سيادية معزولة عن الإنترنت (air-gapped)، أو ضمن بنية تحتية سحابية وطنية داخل نطاق ولايتك القضائية، مع إدارتك الخاصة لمفاتيح التشفير. كان هذا الخيار متاحاً قبل أن نطلق نموذجاً واحداً، وسيظل هو الخيار الأمثل لأي مهام لا يمكن تنفيذها محلياً.
لا، فهي تقلل من مخاطر التعرض للبيانات بشكل كبير مقارنة بالذكاء الاصطناعي السحابي التقليدي، لكنها لا تلغيها تماماً. فقد كشفت عمليات التدقيق المستقلة، بما في ذلك مراجعة شركة Trail of Bits لمعالجة واتساب الخاصة (Private Processing)، عن ثغرات فعلية في التنفيذ (28 مشكلة، منها 8 عالية الخطورة) حتى في واحدة من أكثر بيئات التنفيذ الموثوقة شفافية في القطاع. بيئات TEE تقلص مساحة الثقة، لكنها لا تخرج مزود الخدمة منها.
نعم. في أكتوبر 2025، أثبت باحثون وجود ثغرة TEE.fail، وهي هجمة عتادية بتكلفة أقل من 1000 دولار تستخدم أداة ربط لناقل ذاكرة DDR5 لاستخراج مفاتيح التشفير وتزوير شهادات المصادقة على معالجات Intel SGX وIntel TDX وAMD SEV-SNP، بما في ذلك تقنية SEV-SNP مع تفعيل خاصية إخفاء النص المشفر (Ciphertext Hiding). تتطلب هذه الهجمة وصولاً فيزيائياً إلى الخادم، مما يحصرها في المطلعين ومشغلي مراكز البيانات بدلاً من المهاجمين عن بُعد، ولكن هذا هو بالضبط نموذج التهديد الذي صُممت بيئات التنفيذ الموثوقة لمعالجته.
لا. الذكاء الاصطناعي على الجهاز يلغي دور مزود الخدمة السحابية كطرف في المحادثة، لكن الجهاز نفسه يصبح هو قاعدة الحوسبة الموثوقة بالكامل. يمكن للبرمجيات الخبيثة الموجودة على الجهاز، أو اختراق مستوى نظام التشغيل، أو برامج التجسس الموجهة أن تهزم الذكاء الاصطناعي على الجهاز بنفس الطريقة التي تهزم بها التشفير من طرف إلى طرف. وتعد ميزة Microsoft Recall مثالاً موثقاً لبنية محلية بالكامل ومع ذلك تم إطلاقها مع ثغرات أمنية قابلة للاستغلال.
النماذج الصغيرة على الجهاز (حوالي 1-4 مليار معامل) مناسبة تماماً لتحويل النصوص التي قدمها المستخدم بالفعل، مثل الرد الذكي، وإعادة الصياغة، وتلخيص الدردشات والمستندات، وتحويل الكلام إلى نص. وهي ليست مناسبة للإجابة على الأسئلة ذات النطاق المفتوح، والتي تتطلب معرفة عالمية بمستوى النماذج الرائدة التي لا تمتلكها النماذج الصغيرة.
لا، الاستضافة الذاتية تحل مشكلة مختلفة. فهي تجيب على سؤال من يتحكم في البنية التحتية (السيادة)، وليس ما إذا كان النص الصريح يغادر الجهاز أم لا (ضمان التشفير من طرف إلى طرف). إذا قام خادمك الخاص بفك تشفير محادثة لمعالجتها، فإن تلك المحادثة لم تعد مشفرة من طرف إلى طرف بين الشخصين اللذين يجريانها؛ فقد أصبح خادمك نقطة نهاية ثالثة، حتى وإن كان خادماً موثوقاً.