GitHub Copilot Global Model Policy：Default availability 設定
GitHub Copilot Business 與 Enterprise 的管理介面現在多了一個容易被忽略的控制面：Default availability for released models。Global model policy 從 2026 年 8 月 26 日開始逐步推出，並在 9 月 1 日前後於不同 enterprise 陸續生效；先前沒有個別設定的新模型，會跟著這個預設政策走。
這代表「模型剛 GA」不再等於「管理員必須逐一打開」，也不代表既有明確選擇會被覆寫。真正要先決定的是：未來符合條件的新模型，應該預設 Enabled 還是 Disabled；再對需要額外審核的模型做明確例外。
先看四種狀態，不要只看模型名稱
政策生效後，模型設定會出現以下狀態：
| 狀態 | 意義 | 管理上的重點 |
|---|---|---|
Enabled | 你明確把模型打開 | 這是持久的個別選擇 |
Disabled | 你明確把模型關閉 | 這是持久的個別選擇 |
Delegate to enterprise teams/apps or organizations | 遵循上層 enterprise team 或 organization 設定 | 先到上層查真正的生效值 |
Delegate to default policy | 遵循 Default availability policy | 改全域政策時，這些模型會動態跟著變 |
最容易誤判的是最後一項：Delegate to default policy 不是當下複製一次 Enabled 或 Disabled，而是 live、dynamic 的繼承狀態。今天把 Default availability 設成 Enabled，明天新模型或既有 delegate 模型就可能跟著開放；改成 Disabled 時，它們也會一起收斂。
相反地，若管理員曾經對某個模型做過明確 Enabled 或 Disabled，GitHub 說明 Global model policy 不會覆寫這個選擇。這讓政策設計可以分成「預設值」與「例外清單」兩層，而不必把所有模型都當成同一種狀態。
想避免新模型自動開放，設定順序要反過來
若團隊的優先順序是變更可控、模型先審後用，建議依序做：
- 由 enterprise 或 organization 管理員開啟 Copilot 的模型設定，找到 Default availability for released models。
- 先將預設政策設為
Disabled，保存後確認介面顯示的實際狀態。 - 對已完成審核的模型逐一做明確
Enabled，不要只依賴 delegate。 - 對需要限制的模型保留明確
Disabled，並把理由與審核日期記入團隊變更紀錄。 - 在 enterprise、organization、team／app 多層設定中各看一次，確認沒有上層或下層 delegate 造成誤解。
如果團隊希望快速採用符合政策的新模型，則可以把預設政策設為 Enabled，但仍要對資料保留、供應商、費用或用途有要求的模型做明確例外。重點不是哪個值永遠正確，而是要讓 default 與 exceptions 都是刻意做出的決定。
Open-weight 與資料保留是另一條規則
GitHub 說明，open-weight 模型，以及需要資料保留但不在 GitHub data retention agreement 覆蓋範圍內的模型，不會因為全域政策是 Enabled 就自動開放；官方舉的例子包括 DeepSeek、Kimi K2 與 Fable 5。
這個例外不能拿來取代團隊自己的審核。模型是否 open-weight、是否符合目前的 retention 條件，會隨支援政策與模型版本變化；而且「沒有被預設開放」和「永遠不能使用」是兩件事。管理員仍要參考 Copilot Gemini 模型變更整理 與 GitHub 官方支援模型清單，確認目前可用性、政策與方案範圍。
Business 與 Enterprise 的檢查方式
這次 Global model policy 主要針對 Copilot Business 與 Enterprise。實際 UI 可能依你是在 enterprise、organization 或 team／app 層級管理而不同，但檢查邏輯相同：
Enterprise 層
Enterprise owner 先確認 Default availability 的全域意圖，再檢查是否有 model-specific 的明確 Enabled／Disabled。若看到 Delegate to enterprise teams/apps or organizations，表示目前畫面不是最後的生效位置，要沿著繼承關係往下查。
Organization 層
Organization owner 需要確認 organization 是否沿用 enterprise policy，或已經對模型做自己的明確選擇。不要只截圖模型名稱；把狀態一起記下來，因為 Delegate to default policy 會隨之後的 default 改動。
團隊與 App 層
若企業有不同團隊或應用程式的模型權限，先確認它們是否應該繼承上層。高敏感度用途可以使用明確 Disabled；一般用途則可以保留 delegate，減少日後新模型上線時的維護量。
用一張變更表留下決策
管理模型政策時，建議至少保存這些欄位：
| 欄位 | 範例 |
|---|---|
| Policy scope | enterprise / organization / team |
| Model | canonical model name |
| Current state | Enabled / Disabled / Delegate |
| Decision owner | team 或個人 |
| Reason | data retention、成本、品質或用途 |
| Reviewed at | 2026-09-02 |
這張表不是 GitHub 的必要設定，而是用來回答「為什麼這個模型現在能用」和「改 Default availability 後哪些模型會一起變」。它也能避免把 Copilot 政策與計費變更 誤當成模型可用性設定；模型 policy 和 seat／premium request billing 是不同控制面。
結論：先定預設，再管理明確例外
Global model policy 的核心不是多一個開關，而是把模型管理拆成 default、explicit choice 與 inheritance。先決定未來 GA 模型的 Default availability，再檢查四種狀態、敏感模型例外與 enterprise／organization 的繼承關係。若你的團隊不希望新模型在審核前自動出現，Disabled default 加上明確 Enabled allowlist 會比事後追查 delegate 狀態更容易治理。
常見問題
Q: 把 Default availability 設為 Disabled，會關掉所有目前已啟用的模型嗎？
A: 不會直接覆寫已做出的明確選擇。GitHub 說明 explicit Enabled／Disabled 會被保留；主要受影響的是未配置、目前跟隨 default policy 的模型。
Q: Delegate to default policy 是一次性的設定嗎？
A: 不是。它是動態繼承狀態，Default availability 改變時，適用的模型會跟著改變。需要固定結果時，應對該模型做明確 Enabled 或 Disabled。
Q: Open-weight 模型被排除在 default enablement 之外，代表管理員不能使用嗎？
A: 不代表一定不能使用。它表示不會因全域 default policy 而自動開放；實際能否使用仍要看 GitHub 目前的模型支援、資料保留條件、方案與管理員的個別設定。
參考資料：
Global model policy generally available
回報錯字、失效連結，或告訴我你想看的延伸主題。