الخيار الافتراضي يظل قرارًا في المنتج. أضاف GitHub سياسة عامة تحدد سلوك ميزات Copilot المؤهلة التي بقيت دون ضبط في خطتي Business وEnterprise. يمكن للمسؤولين إعدادها الآن، لكنها تبدأ التأثير فعليًا في 22 أكتوبر 2026.
ماذا أعلن GitHub في 24 سبتمبر؟
يشرح إعلان GitHub ثلاثة خيارات: التفعيل، أو التعطيل، أو ترك القرار للمؤسسات الفرعية. تشمل السياسة الميزات المتاحة عمومًا وقدرات العملاء المؤهلة، وتمتد إلى سياسة مراجعة الكود في صفحة Agents وسياسة خوادم MCP داخل Copilot.
تاريخ الإعلان هو 24 سبتمبر، أما تاريخ بدء التطبيق فهو 22 أكتوبر. خلال مهلة الإعداد البالغة 28 يومًا، لا يؤدي تغيير الخيار الافتراضي الجديد إلى تغيير وصول المستخدمين مباشرة.
ماذا سيحدث في 22 أكتوبر؟
توضح وثائق الإتاحة الافتراضية أن سياسة الميزات مفعّلة افتراضيًا. إذا لم يتخذ المسؤول إجراءً، فستُفعّل الميزات المؤهلة التي ما زالت حالتها Unconfigured عندما تصبح السياسة فعالة.
تبقى القرارات الصريحة كما هي؛ فلا يستبدل الخيار العام ميزة جرى تفعيلها أو تعطيلها منفردة. وتبقى ميزات المعاينة اختيارية. وإذا انتقلت ميزة من المعاينة إلى الإتاحة العامة، تقول GitHub إن الاختيار السابق سيظل محفوظًا.
هذا لا يعني تفعيل كل قدرات Copilot دفعة واحدة. فالأهلية والقرارات السابقة والاستثناءات الموثقة كلها مؤثرة. ومن الاستثناءات المذكورة سياسات تقييد النماذج في GHE.com وسياسة تخزين جلسات Copilot CLI وVS Code المحلية في السحابة.
الميزات والنماذج ضابطان منفصلان
تميّز الوثائق بين خيار الميزات الذي سيبدأ لاحقًا وخيار النماذج الفعّال بالفعل. هذا الفرق مهم أثناء المراجعة؛ فقد تختار المؤسسة سياسة محافظة للميزات، ثم تقرر بصورة مستقلة أي النماذج المنشورة تسمح بها.
ويذكر دليل سياسات المؤسسات أن السياسة تتبع الجهة التي تمنح ترخيص Copilot. وعندما يحصل المستخدم على الوصول عبر أكثر من مؤسسة، قد تؤثر قواعد التعارض في النتيجة. كما تحتاج التراخيص المسندة مباشرة من مستوى enterprise إلى انتباه منفصل؛ لأن خيار «اترك القرار للمؤسسات» لا يحكمها بالطريقة نفسها.
تحليل هندسي: استبدل الغموض بقرار مقصود
بالنسبة للقائد الهندسي، ليست حالة Enabled هي الخطر تلقائيًا؛ بل الغموض. احصر كل سياسة ما زالت Unconfigured، ثم عيّن مالكًا وقرارًا صريحًا بناءً على وصول الميزة الفعلي إلى الكود والمستودعات والأدوات الخارجية والبيانات.
تعامل مع خوادم MCP بوصفها حدود تكامل، لا مجرد مفاتيح في الواجهة. راجع المصادقة والصلاحيات وسياق العميل ووصف الأدوات وقابلية التدقيق. يظهر المبدأ نفسه في عقود API الموثوقة: قد يتحول الخيار الضمني إلى عقد إنتاجي لم يوافق عليه أحد بوضوح.
يمكن تقسيم القدرات إلى ثلاث فئات: مناسبة للتفعيل الواسع، أو مناسبة لتجربة محدودة، أو ممنوعة مؤقتًا حتى تتوفر أدلة أكثر. هذا تصنيف تحريري مقترح، وليس متطلبًا من GitHub.
قائمة عملية قبل الموعد
ابدأ بحفظ حالة السياسات الحالية وعدد العناصر المؤهلة وغير المضبوطة الذي يظهر في تنبيه GitHub. اختر السياسة العامة، ثم اضبط الاستثناءات صراحة. اختبر مؤسسة واحدة على الأقل، ومستخدمًا حصل على الترخيص مباشرة إن وُجد، ومستخدمًا لديه تراخيص متداخلة.
بعد ذلك، وثّق من يملك صلاحية تغيير AI Controls، وراقب سجل التدقيق لأي تغييرات. أخبر مسؤولي المستودعات بتاريخ التطبيق، وحدد مراجعة بعد 22 أكتوبر لمقارنة الوصول الفعلي بما خُطط له.
لا تجعل السياسة الافتراضية بديلًا عن الصلاحيات أو إعادة التحقق من الهوية للعمليات الحساسة. يوضح تحديث GitHub المنفصل حول إثبات الحضور هذا الحد.
الخلاصة: تقلل الخيارات الافتراضية الجهد الإداري، لكنها تكتب سياسة حوكمة في الوقت نفسه. الإطلاق الآمن يحول كل خيار مهم إلى قرار ظاهر وله مالك واضح.
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
