نشرت OpenAI تدوينة عند 19:00 UTC يوم 19 أغسطس أعادت فيها تأكيد التزامها بـ Zero Data Retention على نماذج frontier، وقدّمت لمحة عن آلية تُسمى Private Safety Processing. وقد قُرئت العناوين على أنها إطلاق. ولا يصف أيٌّ من نصفي التدوينة شيئًا أُطلق فعلًا.
ما يخطئ فيه السرد الشائع
الخطأ الأول هو التعامل مع Zero Data Retention بوصفه خبرًا جديدًا. فقد كان ZDR متاحًا لعملاء API المؤهلين منذ 2023: ففي الطلبات المؤهلة لا تُخزَّن المطالبات والإجابات، ولا تُستخدم للتدريب. ولم يتغير أي شيء في هذا الترتيب في 19 أغسطس. أما الخطأ الثاني فهو تقديم Private Safety Processing على أنه ميزة خصوصية تعمل بالفعل. إنه في مرحلة المعاينة، ويُختبر مع عملاء أوائل من بينهم Microsoft وDatabricks، مع الإشارة إلى الإطلاق العام وإلى ورقة تقنية بيضاء في سبتمبر 2026.
المشكلة التي تهدف الآلية إلى حلها
أنظمة السلامة التي تفحص كل زوج من المطالبة والاستجابة على حدة تفوّت المخاطر التي لا تظهر إلا كنمط. وصاغت Aleah Houze، رئيسة سياسة المنتجات في OpenAI، الأمر على النحو التالي: المخاطر تنشأ "ليس فقط بالنظر إلى زوج واحد من المطالبة والاستجابة، بل عند النظر عبر الزمن إلى تفاعلات متعددة." وتهدف Private Safety Processing إلى تمكين أنظمة السلامة من المراقبة عبر التفاعلات ذات الصلة مع إصدار إشارات ضيقة فقط، بحيث لا يرى أي موظف في OpenAI محتوى العميل الأساسي.
الكلمة التي تتحمل العبء الأكبر هي "eligible"
تشير الإعلانات طوال الوقت إلى عملاء API المؤهلين، ولا تذكر من هو المؤهل. ولا يوضَّح ما إذا كان الاحتفاظ الصفري يشمل جميع الشرائح المدفوعة، أم يقتصر على اتفاقات المؤسسات، أم يتطلب ترتيبًا تعاقديًا محددًا. وبالنسبة لفريق المشتريات، فهذا هو السؤال الكامل — فتعهد إقامة البيانات الذي قد ينطبق على عقدك وقد لا ينطبق، ليس تعهدًا بعد.
لماذا هذا التوتر حقيقي
إن مراقبة السلامة في نماذج frontier وتعهدات إقامة بيانات المؤسسات تتجاذبان في اتجاهين متعاكسين: فالمراقبة تريد أن ترى أكثر، بينما تريد إقامة البيانات أن يرى المورّد أقل. ويحسم معظم المورّدين الأمر بالانحياز إلى أحد الجانبين. أما OpenAI فتتبنى موقفًا مفاده أن الجمع بين الأمرين ممكن في الوقت نفسه — نظريًا، على أن يُؤجَّل الإثبات إلى ورقة بيضاء لم تصدر بعد.