إدارة وحوكمة الشركات: الاستخدام الفردي واستخدام المؤسسات، هما أمران مختلفان تمامًا

📚 التنقل في السلسلة: لخصت المقالة السابقة 〔38 قاموس المصطلحات〕 جميع المصطلحات البرمجية والتقنية التي وردت في السلسلة في قاموس ميسر للرجوع إليه في أي وقت — وهو مخصص لمساعدتك في فهم المصطلحات. وتعتبر هذه المقالة المقالة الأخيرة في سلسلة Codex، وهي مقالة اختيارية: موجهة لـ مديري الفرق والمسؤولين التقنيين، لتوضيح كيفية إتاحة Codex للفريق بالكامل بشكل آمن وقابل للتحكم والتدقيق. وإذا كنت مستخدمًا فرديًا، يمكنك تجاوز هذه المقالة مباشرة، فالمقالات الـ 38 السابقة كافية لعملك؛ ولكن إذا أصبحت مسؤولاً عن إتاحة وتفعيل الأداة لفريق عملك مستقبلاً، فلن يضرك الرجوع لقراءة هذه المقالة. ويمثل هذا نهاية المطاف، وسأقوم في نهاية المقالة بعمل مراجعة شاملة لسلسلة Codex بالكامل.

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

فعند استخدامك الفردي، تتركز اهتماماتك حول «هل النموذج ذكي، وهل استجابته سريعة، وهل كتابته ممتازة». ولكن بمجرد أن تصبح الشخص المسؤول عن اتخاذ قرار «توفير الأداة لـ 200 مهندس برمجيات في الشركة»، فلن تكون الأسئلة الأولى في ذهنك حول جودة الكتابة، بل ستكون — «هل سيتم استخدام كود شركتنا لتدريب النماذج؟ وهل يمكنني تتبع ومعرفة من قام بكل إجراء؟ وإذا قام مطور بالخطأ بتشغيل أمر rm -rf لملفات الإنتاج، هل يمكنني منعه؟»

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

توضح هذه المقالة هذا الشرط الأساسي بالتفصيل.

بعد قراءة هذه المقالة، ستحصل على:

• الفروق الجوهرية بين النسخة الفردية ونسخة الفرق / المؤسسات — فبعض قدرات الحوكمة ليست مجرد خيارات إعداد، بل هي متطلبات ترتبط بنوع باقة الاشتراك
• كيفية توحيد التفعيل وإدارة الحسابات: ما الذي تعنيه مصطلحات SSO و SCIM و RBAC للمديرين عمليًا
• الإجابات عن أهم الأسئلة الأمنية: هل يتم استخدام الكود للتدريب، وأين تحفظ البيانات، وكم تظل محفوظة وفقًا للتعهدات الرسمية
• كيفية توجيه «ملف سياسات موحد مركزيًا» لفرض حدود أمنية صارمة للفريق بأكمله، دون الحاجة لضبط كل جهاز على حدة
• التدقيق والامتثال: كيفية استخراج سجلات توضح من قام بالعمليات، وأي النماذج استخدم، ومتى تم إنشاء الـ tokens لمطابقتها وفحصها
• كيفية مراقبة وإدارة التكلفة وحدود الاستخدام، لتفادي صدمة الفواتير نهاية الشهر
• قائمة «التحقق الذاتي للمدير قبل البدء» لمراجعتها وتأكيدها قبل إتاحة الأداة للفريق

⚠️ تعتمد الصفحات والأوامر والخيارات والسلوك الافتراضي لاحقًا على مستندات إعداد مسؤولي الشركات لـ Codex؛ وتتغير أسماء النماذج والباقات وحدود الميزات مع التحديثات وشروط عقد شركتك، واعتمد دائمًا على ما تظهره لوحة تحكم الإدارة الخاصة ببيئتك فعليًا. وتتطلب أغلب قدرات حوكمة الشركات الاشتراك في باقات ChatGPT Business / Enterprise، ويرتبط ظهور هذه الخيارات بنوع باقتك وصلاحيات حسابك.

---

01 استوعب أولاً: الفارق بين النسخة الفردية ونسخة المؤسسات ليس في القدرات، بل في «إمكانية الحوكمة»

يظن البعض أن نسخة الشركات هي مجرد «النسخة الفردية مع رصيد استخدام أكبر». هذا خطأ.

تشبيه: مطبخ المنزل مقابل المطبخ المركزي. عند الطهي في مطبخ منزلك، تحدد بمفردك مواقع السكاكين، وقوة شعلة الموقد، ومدى حاجتك لغسل يديك؛ ولا يراقبك أحد ولا تحتاج لمراقبة. ولكن في المطبخ المركزي لسلسلة مطاعم، لا يقتصر الأمر على «القدرة على الطهي» — بل يجب وضع إرشادات تشغيل موحدة (تمنع الطهي العشوائي)، وبوابات وصلاحيات دخول (لتحديد من يدخل لكل قسم)، وكاميرات مراقبة (لتتبع وتحديد المسؤول عند حدوث خطأ)، وسجلات فواتير التوريد (لمطابقة التكلفة). وتمثل ميزات الشركات في Codex هذا المطبخ المركزي وقدرات «الحوكمة والتحكم»، وليست مجرد زيادة للقدرة على البرمجة.

تفاصيل الاختلافات نوضحها في الجدول التالي:

البعد	النسخة الفردية (Plus / Pro وغيرها)	نسخة الفرق / الشركات (Business / Enterprise)
صلاحية الاستخدام	أنت بمفردك، والقرار بيدك	يتحكم المسؤول في تفعيلها أو إيقافها من لوحة التحكم، وتوزيع الصلاحيات للمجموعات
طريقة تسجيل الدخول	حسابك الشخصي وكلمة المرور	فرض استخدام SSO (الدخول الموحد)، و MFA (التحقق الثنائي)، والمزامنة التلقائية للحسابات عبر SCIM
الحدود الأمنية	إعداد الـ sandbox والموافقة محليًا على جهازك	توزيع مركزي للسياسات من المسؤول يلتزم به الجميع ويمنع تعديله محليًا (requirements.toml)
تدريب البيانات	يعتمد على إعدادات حسابك الشخصي	تعهد صريح بعدم استخدام بيانات الشركات لتدريب النماذج
التدقيق	غير متوفر تقريبًا	إمكانية تصدير سجلات الأنشطة وتتبع العمليات لمطابقة الامتثال
مراقبة الاستهلاك	عرض عام تقريبي في واجهتك	لوحة تحكم تحليلات مخصصة (Analytics) + واجهات API لتفكيك الاستهلاك حسب المطورين أو المنتجات
المسؤول عن الإدارة	لا توجد وظيفة إدارة	دور مخصص للمسؤول (Codex Admin) لإدارة السياسات وبيئات العمل والتحليلات

هل لاحظت الفارق؟ يمثل الجانب الأيمن بالكامل قدرات «حوكمة وتحكم». لا يحتاجها المستخدم الفردي، ولكنها المكونات الجوهرية لمدير الإدارة.

ونشير لتفصيل هام قد يسبب لبسًا في البداية: ينقسم Codex لبيئتين منفصلتين: «المحلية (local)» و «السحابية (cloud)»، ويتم تفعيلهما بشكل مستقل.

تضم بيئة Codex local (المحلية) تطبيق سطح المكتب، وواجهة CLI، وإضافات الـ IDE، وتعمل عمليات الوكيل داخل الـ sandbox للأجهزة الشخصية للمطورين. وتضم بيئة Codex cloud (السحابية) المهام السحابية، ومراجعة الكود (Code Review)، وإصدار iOS وغيرها، وتعمل عمليات الوكيل داخل حاويات (containers) سحابية مستضافة، وتتطلب ربط مستودعات الكود الخاصة بالشركة (تتطلب مستودعات GitHub السحابية حاليًا).

ويمكن للمسؤول تفعيل البيئة المحلية فقط، أو السحابية فقط، أو تفعيلهما معًا. ويحدد هذا الاختيار «البيئة والأجهزة التي يتم فيها معالجة وقراءة الكود»، وهو القرار الأول الذي يجب حسمه عند مراجعة الجوانب الأمنية للبيانات. وأثناء تقييمي لصديقي، واجهنا عقبة حفظ الكود على مستودع GitLab محلي خاص بالشركة، وتسبب ذلك في تعذر استخدام البيئة السحابية للشركات، واضطررنا للتركيز على البيئة المحلية والـ SDK فقط، وتغير اتجاه التقييم بالكامل.

💡 الخلاصة في جملة واحدة: توفر نسخة الشركات إمكانية الحوكمة والتحكم التي يحتاجها المدير — الصلاحيات، والسياسات، والتدقيق، والتكلفة — وليست مجرد زيادة للقدرة على البرمجة.

---

02 توحيد التفعيل وإدارة الحسابات: حزمة SSO و SCIM و RBAC

عند بدء استخدام أي أداة على مستوى الفريق، تبرز المشكلة الأولى المتمثلة في «كيفية إتاحة الحسابات لعدد كبير من المستخدمين، وإيقاف الصلاحيات بكفاءة عند离职 المطورين». فإضافة الحسابات يدويًا واحدًا تلو الآخر عملية مرهقة ومزعجة للغاية، خاصة مع تكرار نسيان إلغاء حسابات من غادروا الفريق.

وهذه هي المشكلة التي تهدف حزمة SSO و SCIM و RBAC لحلها.

تشبيه: نظام بوابات الدخول والبطاقات في الشركات. يمثل نظام SSO «استخدام بطاقة دخول موحدة لفتح كل الأبواب» (تفادي حفظ كلمات مرور متعددة لكل تطبيق)؛ ويمثل SCIM «الربط مع نظام الموارد البشرية لفتح وإغلاق بوابات الدخول تلقائيًا للموظف الجديد ومن يغادر الشركة» (تحديث الحسابات تلقائيًا بناءً على حالة الموظف دون تدخل يدوي)؛ ويمثل RBAC «تحديد الصلاحيات المطبوعة على بطاقة الدخول — فيسمح للمتدرب بدخول صالة العمل فقط، ويسمح للمسؤول المالي بدخول غرف الحسابات».

نوضح مفاهيمها بعبارات بسيطة:

نظام SSO (Single Sign-On /单点登录) — استخدام الموظفين لحساب الشركة الموحد (مثل Okta أو Azure AD) لتسجيل الدخول في Codex، دون الحاجة لإنشاء حسابات مستقلة. مع إمكانية فرض التحقق الثنائي MFA لمنع مخاطر كلمات المرور الضعيفة.

نظام SCIM (مزامنة الحسابات تلقائيًا) — ربط مجموعات مستخدمي Codex مع مزود الهوية الخاص بشركتك (IdP). وعند انضمام موظف جديد وإضافته في مزود الهوية، يتم إنشاء حسابه وإضافته للمجموعات المقابلة وتفعيل صلاحياته تلقائيًا؛ وعند مغادرة موظف وحذفه من مزود الهوية، يتم إلغاء صلاحيات وصوله فورًا. وفائدته الجوهرية هي «إمكانية التدقيق والتحكم المركزي» — لتتبع تغييرات الحسابات وتفادي الاعتماد على ذاكرة الموظفين.

نظام RBAC (Role-Based Access Control /基于角色的访问控制) — وهو النظام الأهم لمدير الإدارة. وتقدم التوجيهات الرسمية هيكل مجموعات متميز يفضل اتباعه:

• إنشاء مجموعة باسم «Codex Users» تضم جميع المطورين المصرح لهم باستخدام Codex؛
• إنشاء مجموعة مستقلة باسم «Codex Admin» تضم العدد المحدود من المسؤولين عن إدارة السياسات والتكوين؛
• قصر صلاحية «إدارة إعدادات Codex» على مجموعة Codex Admin فقط.

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

أما من الجانب العملي، فتتمثل خطوات التفعيل للمسؤول في التالي (تعتمد الصفحات على واجهة لوحة تحكم إدارتك):

1. الدخول للوحة تحكم إدارة ChatGPT ← Workspace Settings ← Settings and Permissions
2. تفعيل خيار «Allow members to use Codex Local» ← لإتاحة استخدام الأدوات المحلية (App/CLI/IDE)
3. للبيئة السحابية: تفعيل خيار «Allow members to use Codex cloud» + ربط مستودع GitHub
4. الدخول لقسم Custom Roles، وإنشاء مجموعتي Codex Users و Codex Admin وتوزيع الصلاحيات لهما
5. ربط المجموعتين بمزود الهوية IdP الخاص بشركتك عبر SCIM لمزامنة المطورين تلقائيًا

وتعمل البيئة المحلية Codex local بشكل مفعل افتراضيًا للمجلدات الجديدة؛ وإذا واجه مطور خطأ يمنعه من الدخول مثل 403 - Unauthorized. Contact your ChatGPT administrator for access.، فيشير هذا لعدم تفعيل خيار استخدام البيئة المحلية من جهة لوحة التحكم، أو عدم إدراج حسابه في المجموعة المصرح لها.

💡 الخلاصة في جملة واحدة: يتحكم SSO في «طريقة الدخول»، ويتحكم SCIM في «مزامنة الحسابات تلقائيًا»، ويتحكم RBAC في «توزيع صلاحيات لوحة التحكم» — وقصر صلاحيات المسؤول على أقل عدد ممكن من الأفراد هو القاعدة الذهبية.

---

03 حوكمة البيانات: هل سيتم استخدام كودك البرمجي لتدريب النماذج؟

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

• عدم استخدام بيانات الشركات لتدريب النماذج (No training on enterprise data)
• تدعم الأدوات المحلية الثلاث (App، CLI، IDE) سياسة عدم الاحتفاظ بالبيانات (Zero Data Retention) وحفظ الكود داخل الأجهزة الشخصية للمطورين
• تخضع سياسات حفظ وموقع البيانات (residency) لخيارات اتفاقية ChatGPT Enterprise الخاصة بشركتك
• تشفير البيانات الثابتة بالاعتماد على معيار AES-256، وتشفير البيانات المنقولة بالاعتماد على TLS 1.2+
• إمكانية استخراج سجلات التدقيق والأنشطة عبر واجهات Compliance API

ونوضح إجابات هذه التعهدات لثلاثة أسئلة هامة للمدير:

أولاً: هل يتم استخدام البيانات لتدريب النماذج؟ لا يتم استخدام بيانات الشركات لتدريب النماذج مطلقًا. ويمثل هذا التعهد فارقًا جوهريًا لنسخة الشركات مقارنة بالنسخ الفردية.

ثانياً: أين تحفظ البيانات وكم تظل محفوظة؟ تدعم الأدوات المحلية سياسة عدم الاحتفاظ بالبيانات (ZDR) — ويعني هذا معالجة الكود داخل أجهزة المطورين وتفادي حفظ كودك البرمجي في خوادم OpenAI. بينما تتطلب البيئة السحابية ربط مستودع الكود في حاويات (containers) سحابية مستضافة، وتخضع سياسات حفظ وموقع البيانات فيها لشروط وتفاصيل اتفاقية Enterprise الخاصة بشركتك. لذا يحدد اختيار «البيئة المحلية أو السحابية» مسار وتدفق كودك البرمجي.

ثالثاً: هل يمكن تحديد النطاق الجغرافي لحفظ ومعالجة البيانات (residency)؟ نعم، يتيح ملف السياسات استخدام خيارات مثل enforce_residency (مثل تعيين enforce_residency = "us") لإلزام معالجة البيانات في نطاقات جغرافية محددة. وتعتمد الخيارات المتاحة على شروط عقد شركتك و مستندات تهيئة خيارات الشركات لـ Codex.

ونشير لتفصيل هام لتجنب اللبس: تختلف سجلات التدقيق (audit logs) عن «سياسة عدم الاحتفاظ بالكود». فعند تشغيل العمليات بالاعتماد على حساب ChatGPT للشركات، يتم تسجيل الأنشطة في سجلات تدقيق (تستخدم لمطابقة معايير الامتثال، وسنوضحها في القسم التالي) وتحتفظ بها الشركة لمدة 30 يومًا بحد أقصى؛ بينما تمثل سياسة «عدم التدريب والـ ZDR» تعهدات بعدم حفظ الكود البرمجي الخاص بشركتك لاستخدامات OpenAI. ويغطي البند الأول «إمكانية المراجعة والتتبع»، بينما يغطي البند الثاني «حماية الملكية الفكرية والخصوصية»، وهما تعهدان منفصلان تمامًا.

تشبيه: كاميرات المراقبة في البنك ومبدأ عدم التصرف في الودائع. تمثل كاميرات المراقبة (سجلات التدقيق) إجراءً أمنيًا يتم الاحتفاظ بتسجيلاته لفترة محددة للرجوع إليها عند الحاجة؛ ويمثل مبدأ عدم التصرف في الودائع (الـ ZDR وعدم التدريب) التزامًا أمنيًا بحماية أصولك وعدم استخدامها للآخرين. وكلاهما هام للعمل، ولكنهما تعهدان منفصلان.

💡 الخلاصة في جملة واحدة: تلتزم التعهدات بحماية خصوصية كود الشركات ومنع تدريب النماذج عليه، وتدعم البيئة المحلية سياسة ZDR لحفظ الكود محليًا؛ وتختلف سجلات التدقيق التي تحفظ لمدة 30 يومًا عن سياسات حماية الكود.

---

04 التوزيع المركزي للسياسات: فرض حدود أمنية صارمة للفريق بأكمله دون إعداد فردي

تحدثنا في المقالتين 15 و 16 عن إعدادات الـ sandbox والموافقة وملف requirements.toml محليًا — وكان هذا يمثل «كيفية إعدادك للصلاحيات على جهازك الشخصي». ولكن كمدير تقني، لا يمكنك الذهاب لـ 200 جهاز لضبط الإعدادات لكل مطور يدويًا.

ويتمثل حل الشركات في: توزيع وإدارة السياسات مركزيًا، ومنع المطورين من تعديلها محليًا.

تشبيه: دليل التشغيل الموحد الموزع من الإدارة العامة لفروع المحلات. يملك مدير الفرع صلاحية تحديد «المنتجات المعروضة اليوم»؛ ولكن القواعد الصارمة مثل «تاريخ صلاحية الأطعمة، وطرق إقفال الحسابات اليومية» تصدر مركزيًا من الإدارة وتلتزم بها كل الفروع دون تعديل. وتمثل سياسات الشركات في Codex هذا الدليل الموحد الموزع من الإدارة.

تنقسم الإعدادات الموزعة مركزيًا إلى نوعين هامين:

النوع	طبيعة العمل	هل يمكن للمطور تعديله محليًا؟
الاشتراطات الصارمة (Requirements)	الحدود الأمنية المفروضة من الإدارة: كالأوضاع المسموحة للموافقة والـ sandbox، وحالة الشبكة، وخوادم MCP المسموحة...	يمنع تعديله محليًا، وفي حال حدوث تعارض يقوم Codex بتفعيل القيمة الأمنية المحددة تلقائيًا مع إظهار تنبيه للمطور
الخيارات الافتراضية المدارة (Managed defaults)	الإعدادات الافتراضية التي يبدأ بها Codex مع كل جلسة	يمكن للمطور تعديلها مؤقتًا أثناء الجلسة، ولكن تتم إعادتها للقيم الافتراضية مع كل تشغيل جديد

يتم كتابة الخيارين في ملفات بصيغة TOML، ويتعامل المدير بشكل أساسي مع ملف requirements.toml (للاشتراطات الصارمة) وملف managed_config.toml (للخيارات الافتراضية). وتتمثل الطريقة الأسهل لتوزيع هذه الملفات في «الاستضافة السحابية» — حيث يتم كتابة القواعد في لوحة تحكم سياسات Codex وربطها بالمجموعات المعنية، ويقوم Codex بتحميل وتطبيق السياسات على أجهزة المطورين تلقائيًا بمجرد تسجيل الدخول، دون الحاجة لنقل وتوزيع الملفات على الأجهزة يدويًا.

على سبيل المثال، عند الحاجة لـ منع تشغيل الأوضاع الأمنية المفتوحة بالكامل وتثبيت وضعي sandbox والموافقة في مستويات آمنة، يمكن كتابة السياسة التالية (وهي السياسة الموصى بها رسميًا):

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

وتؤدي كتابة هذين السطرين لـ: منع استخدام أوامر --ask-for-approval never و --sandbox danger-full-access (أو التجاوز الكامل عبر --yolo) — وعند محاولة أي مطور تشغيل الأداة بدون حواجز أمنية تتدخل هذه السياسة لمنعه.

وعند الحاجة لـ إغلاق الميزات التجريبية (مثل التحكم في شاشة الكمبيوتر):

[features]
browser_use = false
in_app_browser = false
computer_use = false

أو فرض طلب الموافقة قبل تشغيل أوامر هامة وحساسة:

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "推送 / 提交前必须人工确认" },
]

(Note: we preserve the Chinese string within the code block).

ملاحظة هامة: يجب أن تقتصر خيارات القرارات في ملف requirements على قيم "prompt" (طلب موافقة) أو "forbidden" (منع)، ويمنع استخدام خيار "allow" لمنح صلاحيات إضافية للمطور — حيث تم تصميم السياسات الإدارية للمؤسسات لـ «التقييد والحماية» فقط، وليس لفتح الصلاحيات.

أما في حال غياب خيارات الاستضافة السحابية والاعتماد على أدوات إدارة الأجهزة (مثل أنظمة MDM كـ Jamf Pro أو Fleet أو Kandji للشركات)، فيمكن توزيع السياسات كأكواد TOML مشفرة بصيغة base64، وحفظ الملفات في المسارات التالية للنظام: /etc/codex/requirements.toml (لأنظمة Unix) أو %ProgramData%\OpenAI\Codex\requirements.toml (لأنظمة Windows). وتذكر اختلاف المسارات بين أنظمة تشغيل الأجهزة، وتظل الاستضافة السحابية هي الخيار الأسهل والأشمل لكل الأنظمة.

💡 الخلاصة في جملة واحدة: يتيح ملف requirements.toml فرض وإدارة السياسات والحدود الأمنية مركزيًا عبر خيارات الاستضافة السحابية لمنع تعديلها محليًا، وتقتصر التعديلات على «التقييد والحماية» فقط.

---

05 التدقيق والامتثال: إمكانية استخراج سجلات توضح من قام بكل إجراء

بعد تحديد السياسات والحدود الأمنية للعمل، يجب توفير إجابات لأسئلة المراجعة «عند حدوث مشكلة، من قام بالعملية، ومتى، وبأي الموديلات، وماذا تم تعديله». وهذا هو دور التدقيق.

توفر التوجيهات الرسمية ثلاثة مستويات لمراقبة وتتبع العمليات، ونرتبها حسب تفصيل البيانات:

الأداة	الاستخدام	الفئة المستفيدة
لوحة تحكم التحليلات (Analytics)	استعراض عام فوري: المطورين النشطين، حجم الاستهلاك، وملاحظات Code Review	استخدام الإدارة والمسؤولين لمتابعة مؤشرات العمل اليومي
واجهات Analytics API	استخراج تحليلات الاستهلاك اليومي ودمجها في قواعد بيانات شركتك أو أنظمة BI	إعداد التقارير ومشاركتها مع الإدارة العليا
واجهات Compliance API	استخراج سجلات الأنشطة والعمليات بالتفصيل ودمجها في أنظمة SIEM أو DLP	فحص وإثبات الأنشطة لفريق الأمن السيبراني والامتثال القانوني

ويكفي استخدام لوحة تحكم التحليلات (Analytics) لمتابعة العمل اليومي — حيث تمكنك من مراجعة تفاصيل استهلاك الـ tokens وتعداد المستخدمين النشطين حسب بيئات التشغيل (CLI أو IDE أو المهام السحابية أو Code Review)، مع إمكانية تصدير البيانات بصيغة CSV أو JSON. وانتبه لملاحظة رسمية تفيد بتأخر تحديث بيانات لوحة التحليلات لفترة قد تصل لـ 12 ساعة، وتجنب الاعتماد عليها للمراقبة اللحظية الفورية للعمليات.

أما عند الحاجة للتحقيق في مشكلة أمنية أو إثبات الامتثال، فيتم الاستعانة بـ Compliance API. وتتميز السجلات المستخرجة منها بدقتها وتفصيلها:

حيث تشمل البيانات المستخرجة: نصوص طلبات المطورين (prompt) المرسلة لـ Codex، والردود والحلول البرمجية المقترحة منه، ومعرفات المطور والمستند والمؤسسة والتوقيت والموديل المستخدم، وتعداد tokens ومعلومات الطلب الوصفية. لتوفر إجابات واضحة حول «من قام بتشغيل هذه المهمة، ومن قام بإنشاء أو إلغاء access token محدد، وتوقيت العملية، والنموذج المستخدم».

ويمكن للمسؤول استخراج السجلات عبر واجهة API كالتالي (تعتمد العناوين والمعلمات على الإرشادات الرسمية للـ API):

curl -L -H "Authorization: Bearer YOUR_COMPLIANCE_API_KEY" \
  "https://api.chatgpt.com/v1/compliance/workspaces/WORKSPACE_ID/logs?event_type=CODEX_LOG&after=2026-03-01T00:00:00Z"

وستحصل على قائمة بملفات السجلات المتاحة للتنزيل، ويمكنك تحميلها بالاعتماد على معرف log_file_id ودمجها في نظام SIEM الخاص بشركتك للحفظ والأرشفة.

ونشير لنقطتين هامين للتأكيد عليهما:

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

ثانياً: تدخل العمليات المعتمدة على حساب ChatGPT في سجلات التدقيق والامتثال فقط. وتذكر التعهد الرسمي: لا تدرج العمليات التي تتم بالاعتماد على API key في سجلات Compliance API للشركات، وتخضع سجلات الـ API لخيارات الحساب الخاصة بـ Platform API. لذا إذا كان فريقك يستخدم سكريبتات أتمتة تعمل بالاعتماد على API key، فتأكد من تتبع استهلاكها من لوحة تحكم الـ API المنفصلة.

ونشير لأداة هامة ترتبط بالتدقيق: مفاتيح الوصول (access tokens). وهي مفاتيح يتم إنشاؤها لتشغيل المهام التلقائية (بيئات CI، المهام المجدولة، وسكريبتات codex exec) ويتم احتساب عملياتها وحفظها تحت حساب المطور الذي قام بإنشائها. ويجب على المسؤولين التعامل مع هذه المفاتيح كأصول سرية:

• حفظها في مديري المفاتيح السرية الآمنة، وتفادي كتابتها في السجلات، وإلزام تعيين فترات صلاحية محددة لها (تحديد 7 أو 30 أو 60 يومًا بدلاً من خيار الصلاحية الدائمة)، وإلغاء وتحديث المفاتيح بشكل دوري؛
• منع استخدام المفاتيح في بيئات CI العامة، أو مستودعات الكود المفتوحة للطلبات الخارجية (forked PRs)، أو أجهزة التطوير المشتركة تفاديًا لتسريبها.

وتؤكد التجربة العملية: تجنب تحديد فترات صلاحية دائمة (لا تنتهي) لمفاتيح access tokens لتبسيط العمل. فقد واجهت مشكلة تتبع مفتاح وصول قديم تم إنشاؤه قبل أشهر، واستغرق تحديد «صاحب المفتاح ووجهة استخدامه وهل ما زال مطلوبًا للعمل أم لا» فترات طويلة. وتثبيت فترات صلاحية محددة مع إلزام التحديث الدوري هو الخيار الأفضل لإدارة المفاتيح للفريق.

💡 الخلاصة في جملة واحدة: اعتمد على لوحة تحكم التحليلات للمتابعة الدورية، واستخدم واجهات Compliance API للتحقيق وإثبات الامتثال؛ وتذكر حدود حفظ السجلات لـ 30 يومًا وقصرها على العمليات المعتمدة على حسابات ChatGPT.

---

06 التحكم في التكلفة والحدود: لتفادي صدمة الفواتير نهاية الشهر

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

ويمكن تتبع التكلفة في Codex بالاعتماد على لوحة تحكم تحليلات الإدارة (Analytics) وواجهات الـ API الخاصة بها — حيث تتيح تفكيك استهلاك الرصيد (credit) والـ tokens بالتفصيل حسب بيئة العمل (CLI أو IDE أو المهام السحابية أو Code Review) وحسب المطورين، لتحديد مكامن الاستهلاك المرتفع بوضوح.

تشبيه: تقسيم بنود الفواتير في الميزانية المنزلية. لا يفيدك معرفة «استهلاك عشرة آلاف دولار هذا الشهر» في خفض التكاليف، بل تحتاج لتفكيكها لـ «قيمة الإيجار، وتكلفة الانتقال، وتكلفة الطعام». وتفكيك استهلاك Analytics حسب المطور وبيئة العمل يمنحك هذه التفاصيل الدقيقة: لتحديد أي المجموعات تستهلك المهام السحابية بشكل مكثف، ومن يفرط في رفع قوة الاستدلال، وتستعرض البيانات بوضوح.

وتتمثل خيارات التحكم في التكلفة المتاحة للمسؤول في ثلاث:

أولاً: التحكم من خلال سياسات الأمان. يتيح إعداد وتوزيع ملف requirements.toml تقييد خيارات الاستخدام المكلفة — كمنع الأوضاع المفتوحة للـ sandbox وإغلاق الميزات التجريبية الثقيلة، مما يساعد في خفض الاستهلاك تلقائيًا.

ثانياً: التحكم من خلال خيارات النماذج وقوة الاستدلال. وضحنا في المقالة 30 أن الإفراط في رفع قوة الاستدلال للحد الأقصى هو المسبب الأكبر لزيادة التكلفة. ويمكنك كتابة قيم افتراضية متوازنة في ملف managed_config.toml للفريق (مثل تعيين model_reasoning_effort = "medium")، ليبدأ المطورون العمل من مستويات تشغيل اقتصادية، وتجنب تفعيل مستوى xhigh افتراضيًا للجميع. وتوجيه استخدام النماذج الخفيفة مثل gpt-5.4-mini للمهام الروتينية يسهم في خفض التكلفة بشكل ملحوظ.

ثالثاً: التحكم من خلال حدود الاستخدام ومستويات الخدمة. يتيح إعداد خيار service_tier في ملفات التكوين الموزعة (مثل اختيار الإعداد المتوازن وتجنب خيار fast السريع المكلف افتراضيًا) توجيه المطورين لاستخدام الخيارات الاقتصادية تلقائيًا كعادة عمل للفريق.

ونعرض فيما يلي جدولاً يلخص التوجيه المالي لإدارة الفريق مقارنة بالطرق الخاطئة:

❌ طرق إدارة التكلفة غير المستقرة	✅ الممارسة المالية الصحيحة
انتظار الفاتورة نهاية الشهر لمعرفة الاستهلاك	مراجعة لوحة تحكم التحليلات أسبوعيًا لتتبع القفزات غير المبررة للاستهلاك
ترك خيارات قوة الاستدلال لـ xhigh افتراضيًا للجميع	تعيين خيار medium كإعداد افتراضي مدار، والسماح برفعها للمهام الصعبة يدويًا فقط
فتح صلاحيات استخدام النماذج الرائدة والميزات الثقيلة للجميع دون قيود	استخدام السياسات لتثبيت مستويات اقتصادية لأغلب المطورين وقصر النماذج الرائدة على مهام معينة
غياب متابعة الاستهلاك ونسب المسؤوليات	تحديد مسؤول لمتابعة وإعداد تقارير الاستهلاك الدوري لمطابقة الميزانية

وتنصح التوجيهات الرسمية بـ: تحديد مسؤولين لمتابعة Adoption (تبني استخدام الأداة) والامتثال الأمني والتدقيق، وتثبيت معايير واضحة لـ «شكل الاستخدام الناجح للأداة» قبل إتاحتها للجميع. وتجنب فتح الصلاحيات بالكامل للفريق من البداية دون قيود ثم محاولة تقييدها لاحقًا بعد اعتياد المطورين على الإعدادات الواسعة.

💡 الخلاصة في جملة واحدة: تدار التكلفة بمتابعة لوحة تحكم التحليلات وتفكيك الاستهلاك حسب المطور وبيئة العمل، وتثبيت قيم افتراضية متوازنة لقوة الاستدلال ومستوى الخدمة لتفادي صدمة الفواتير نهاية الشهر.

---

07 ملخص

استعرضنا في هذه المقالة تفاصيل واحتياجات إدارة وحوكمة Codex على مستوى المؤسسات:

• الفارق بين النسخة الفردية ونسخة الشركات هو إمكانية الحوكمة — وتعتبر الصلاحيات، والسياسات، والتدقيق، ومتابعة التكلفة هي المكونات الجوهرية لنسخة الشركات وليست مجرد زيادة لقدرات البرمجة.
• إدارة الحسابات: تشغيل SSO لتسهيل الدخول الموحد، والمزامنة التلقائية SCIM لتحديث الحسابات مع حركة الموظفين، ونظام RBAC لحصر الصلاحيات الإدارية في أضيق نطاق.
• أمن وحوكمة البيانات: التعهد بعدم تدريب النماذج على بيانات الشركات، وحفظ الكود محليًا للأدوات المحلية (ZDR)، وتوافق خيارات حفظ البيانات مع شروط الباقة؛ مع الفصل بين سجلات التدقيق وتعهدات حماية الكود.
• التوزيع المركزي للسياسات: استخدام ملف requirements.toml الموزع مركزيًا عبر خيارات الاستضافة السحابية لفرض حدود الأمان ومنع المطورين من تعديلها محليًا.
• التدقيق والامتثال: متابعة الاستهلاك عبر لوحة تحكم التحليلات، واستخدام واجهات Compliance API للتحقيق الأمني؛ مع تذكر حدود حفظ السجلات لـ 30 يومًا وقصرها على حسابات ChatGPT.
• مراقبة التكلفة: تفكيك بنود الاستهلاك لمطابقتها، وتعيين خيارات اقتصادية لقوة الاستدلال ومستويات الخدمة كإعدادات افتراضية للفريق لتفادي الفواتير المرتفعة.

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

ونقدم قائمة التحقق الذاتي للمدير قبل البدء، لمراجعتها وتأكيدها قبل إتاحة الأداة للفريق:

• [ ] تحديد خيار تشغيل البيئة المحلية (local) أو السحابية (cloud) أو كليهما (لتحديد مسار البيانات بدقة)
• [ ] تعيين المسؤولين للثلاثة أدوار: مسؤول مساحة العمل (Workspace owner)، مسؤول الأمان (Security owner)، ومسؤول التحليلات (Analytics owner)
• [ ] إنشاء مجموعتي Codex Users و Codex Admin وقصر الصلاحيات الإدارية على أقل عدد ممكن
• [ ] ربط خيارات تسجيل الدخول والتحقق والمزامنة SSO / MFA / SCIM مع مزود هوية الشركة
• [ ] إعداد وتوزيع ملف requirements.toml لفرض الحدود الأمنية ومنع تشغيل الأوضاع الأمنية المفتوحة
• [ ] تهيئة مفاتيح واجهات Compliance API ومعرفة مسار استخراج وأرشفة السجلات ومدة الحفظ
• [ ] تحديد فترات صلاحية محددة وخطط تحديث دورية لمفاتيح access tokens المخصصة للأتمتة
• [ ] تحديد المسؤول المالي لمتابعة التكلفة ووضع معايير واضحة لـ «شكل الاستخدام الناجح للأداة» للميزانية

---

بوصولنا لنهاية هذه المقالة، نكون قد وصلنا لنهاية سلسلة Codex بالكامل.

وعند مراجعة مسيرتنا في هذه السلسلة: بدأنا من المقالة 01 «ما هو Codex» وتثبيت البيئة وتشغيل أولى المهام البرمجية؛ وتعرفنا على واجهات CLI وتطبيق سطح المكتب والـ IDE والبيئة السحابية؛ ودرسنا طبيعة عمل ملفات AGENTS.md و config.toml والـ sandbox والموافقة؛ وتناولنا ميزات MCP والوكلاء الفرعيين والمهارات والخطافات؛ وتعلمنا كيفية المفاضلة بين النماذج لرفع سرعة العمل وتجنب إعادات العمل؛ وأتممنا دمج الأداة مع Git و Slack و بيئات CI؛ ونهينا السلسلة بقاموس المصطلحات الميسر ودليل حوكمة وإدارة الشركات الحالي. 38 مقالة توجيهية + مقالة اختيارية واحدة، لتنتقل من مرحلة «سماع اسم Codex» لمرحلة «دمجه وتشغيله بثقة داخل بيئات عمل حقيقية».

نهنئك على إتمام قراءة السلسلة بالكامل — فالالتزام بإنهاء وقراءة دليل برمجى متكامل للنهاية هو سمة يتميز بها القليل من المطورين.

وبصراحة، فإن قراءة هذه التوجيهات تمثل خطوة «المعرفة»، ويتطلب إتقانها وتوظيفها خطوة «العمل الفعلي والتطبيق» التي تتولاها أنت. وننصحك بالتوقف عن جمع المقالات التعليمية الآن، وفتح الطرفية واختيار مهمة حقيقية مصغرة تواجهها حاليًا — كإصلاح خطأ برمجي، أو كتابة سكريبت، أو إعادة هيكلة كود قديم — وتفويضها لـ Codex. ستواجه بعض العقبات في البداية، ولكن تجربة إنجاز أول مهمة حقيقية بالتعاون مع الأداة وتوفير وقتك الفعلي تمنحك مهارة لا تضاهيها قراءة عشرات المقالات التعليمية.

الأدوات والبرمجيات وسيلة، وما تنجزه بها من مشاريع حقيقية هو الغاية والهدف. ابدأ التطبيق العملي الآن يا صديقي.

---

قراءات موصى بها

• التعرف على Codex وبوابات التشغيل الأربع
• كيفية اختيار النموذج: أي نموذج وأي قوة لكل مهمة
• المهارات المتقدمة وتسريع العمليات: ما يبطئ عملك ليس النموذج، بل السياق الضعيف الذي تقدمه