Copilot 管理員現在要處理的，不只是「要不要開新模型」。假設研發組織想用 MAI-Code-1-Flash 處理低風險修 bug，資料敏感團隊只能用已審核模型，外包組織還不能從未核准 marketplace 安裝 Copilot CLI 插件，單一 enterprise-wide model setting 很快會失效。
GitHub 5 月先把 targeted model rules 放進 public preview，讓 enterprise owner 依 organization 指定可用 Copilot models。6 月 26 日，GitHub 又宣布 MAI-Code-1-Flash 已對 Copilot Business 與 Copilot Enterprise generally available；6 月 25 日的 strictKnownMarketplaces 則補上 VS Code 與 GitHub Copilot CLI 的插件來源管控。
這三個更新應一起看。模型政策決定「誰能用哪個模型」，organization 規則決定「哪些團隊可以試」，插件 marketplace 規則決定「工具執行前能接哪些來源」。如果只把 MAI-Code-1-Flash 當成一個新選項開給全公司，成本、資料邊界與插件風險會混在一起，事後很難查清楚是哪一層出了問題。
已經在整理 Copilot 方案、費用與個人模型選擇的讀者，可以先看 GitHub Copilot 費用與模型選擇；如果重點是 Auto mode 與 MAI-Code-1-Flash 的任務分流，延伸閱讀 GitHub Copilot Auto mode：MAI-Code-1-Flash 進 Chat 後怎麼選模型？。企業管理員的可行做法，是把 Model Rules、MAI-Code-1-Flash 與 plugin governance 放進同一套導入節奏。
先切成三層治理
很多 Copilot 治理問題，源頭是把不同風險塞進同一個開關。模型能力、資料敏感度、插件來源與例外審批，最好分成三層處理。
第一層是 enterprise default model availability。它決定全企業預設哪些 Copilot models 可用，以及模型是 Enabled 還是 Optional。5 月 targeted model rules 公告提到，GitHub 同時更新了 default model availability 的管理體驗，讓 enterprise owner 更容易在同一頁看見並設定預設模型狀態。
第二層是 organization model rules。它處理的是不同 organization 的風險差異：核心研發、受監管資料團隊、外包組織與實驗小組，不一定該看到同一組模型。Targeted model rules 的價值就在這裡，管理員可以針對指定 organizations 允許特定 Copilot models，而不是把一組 enterprise-wide default 套給所有人。
第三層是 plugin marketplace allowlist。strictKnownMarketplaces 管的是 VS Code 與 GitHub Copilot CLI 能從哪些 marketplaces 安裝插件。這一層看似和模型無關，但它會影響模型回答能否接到工具執行；工具來源沒有控管時，模型政策很容易被未審核插件繞開。
對大型企業，順序應該是先定義企業基線，再把需要更嚴或更寬的 organization 拆出來，最後限制插件入口。對小團隊，較輕的做法是先維持 enterprise-wide default，整理敏感 repo 與外包權限清單，每月檢查一次是否需要升級到 organization rules。
MAI-Code-1-Flash 進 Business／Enterprise 後，仍要先設政策
GitHub 6 月 26 日說，MAI-Code-1-Flash 是 Microsoft AI 的 in-house coding model，已對 GitHub Copilot Business 與 Copilot Enterprise generally available。GitHub 將它描述為針對 GitHub Copilot 最佳化、適合快速低延遲回應，尤其適合高頻、反覆迭代的 agentic coding workflows。
管理員要注意兩個限制。Copilot Enterprise 與 Copilot Business plan administrators 必須先在 Copilot settings 啟用 MAI-Code-1-Flash policy，使用者才可存取。GitHub 也說這個模型依 usage-based billing 的 provider list pricing 計費；打開新模型前，需要先放進費用監控與模型政策裡。
比較安全的導入方式，是把 MAI-Code-1-Flash 放在低敏感、可回滾、容易 review 的工作流。例如小型測試補強、錯誤訊息解釋、低風險 refactor 初稿、重複性程式碼整理，都比資料庫 migration、權限邏輯、安全修補或客戶資料處理更適合先試。任務失敗會牽動資料、金流、法規或跨服務契約時，模型速度不能降低審查層級。
strictKnownMarketplaces 補的是工具來源風險
GitHub 6 月 25 日說，enterprise-managed settings 已支援 strictKnownMarketplaces，且目前是 public preview。管理員可以把 strictKnownMarketplaces 加到 enterprise-managed settings.json，讓 GitHub Copilot CLI 與 VS Code 只允許從明確定義的 marketplaces 安裝插件。GitHub 也說，這些設定會自動拉取並套用到 Copilot Business 或 Copilot Enterprise 授權使用者。
這個更新的重點在「工具執行前」先約束插件來源。Copilot CLI、VS Code、桌面代理與雲端代理都可能把模型回答延伸成工具動作；如果插件來源沒有控管，使用者可能在模型政策看似合規的情況下，接入沒有審核過的工具。稽核問題會從「哪個模型回答」變成「哪個外部工具被執行」。
因此 strictKnownMarketplaces 應和 model rules 一起進導入表。若某個 organization 只允許已審核模型，也應限制可用插件來源；若某個研發實驗組織可以試 MAI-Code-1-Flash，仍要明確列出哪些 marketplaces 可以安裝。模型和插件分開管，才能在問題發生時快速判斷是模型輸出、工具權限還是插件來源造成風險。
先為三種 organization 設不同規則
企業不需要一次做出完美政策。比較務實的做法，是先把 organization 分成三種風險輪廓，再用 Model Rules 套上不同模型範圍。
低敏感研發團隊可以先拿到 MAI-Code-1-Flash 或 Auto mode 的試跑權限，但任務範圍要限制在低風險 repo、小 diff、可回滾修改與明確測試。管理員要看的是回應採用率、返工時間、premium request 或 usage-based billing 變化，不是只問開發者覺得快不快。
受監管或資料敏感團隊應先使用已批准模型與更嚴的審查流程。金融、醫療、法務、資安或處理客戶資料的 organization，即使看到新模型回應速度更好，也要等資料邊界、code review、測試與事件回報流程清楚後再放寬。這類團隊也應搭配 GitHub Copilot data residency 與 FedRAMP 指南 檢查資料處理位置與合規要求。
外包、臨時專案或實驗 organization 則要特別注意權限生命週期。這類團隊常有 repo 邊界複雜、工具來源難追蹤的問題。建議先把可用模型與可安裝插件都收窄，允許例外但要求有 owner、期限、原因與回收日期。這樣可以讓實驗繼續進行，又不會把臨時需求變成長期風險。
7 天試跑要驗證政策能否落地
如果企業第一次導入 targeted model rules，可以用一週完成低風險驗證。目標是確認政策、成本、例外流程與插件管控都能落地，而不是證明新模型永遠更好。
Day 1 先選 1 個低敏感 organization，確認 MAI-Code-1-Flash policy 與 default model availability 狀態。通過訊號很具體：使用者能看見可用模型，管理員知道哪些人被納入試跑。
Day 2 選三種低風險任務，例如錯誤解釋、測試補強、小型 refactor 初稿。每個任務都要有 PR、測試或人工 review 作為驗證，避免只用聊天體感判斷模型品質。
Day 3 套用 strictKnownMarketplaces，或至少列出允許 marketplaces。目標是讓使用者不能任意安裝未定義來源的插件，並記錄哪些必要工具會因限制而失敗。
Day 4 檢查用量與成本訊號。若團隊已在使用 Copilot 使用量 API，應同步看活躍使用者、AI credits 或 premium request 變化；單次回應變快，不代表總成本一定下降。
Day 5 收集失敗案例與升級規則。回答明顯漏掉 repo 約束、沒有測試、過度簡化安全議題，或在工具執行前需要更嚴格確認時，都要記錄為「切回指定模型」或「升級審查」訊號。
Day 6 檢查外包、受監管與資料敏感 repo 是否被排除。高風險場景沒有被新模型試跑誤納入，才代表 organization rules 有被正確執行。
Day 7 決定擴大、維持或收回。每個決定都要有 owner、期限、例外流程與下一輪檢查日期。若同時評估 cloud agent 成本，則要把 Copilot cloud agent 省錢模型分流 放進同一張治理表，因為長任務代理會放大模型選錯與工具權限過寬的影響。
先不要擴大的訊號
如果管理員還不知道哪些 repo 含有客戶資料、哪個 organization 有外包帳號、哪些插件來源已經被審核，先不要把 MAI-Code-1-Flash 或其他新模型擴大到全公司。這是為了避免模型政策只停在文件上，實際操作時無法追蹤資料與工具邊界。
如果開發者常把 Copilot 產生的修改直接推進大型 PR，也不適合先擴大。模型速度會讓變更量增加，review 成本可能跟著上升。這時應先建立 PR 大小限制、測試要求、rollback 訊號與「何時升級到指定模型」規則，再談 organization model rules。
如果 strictKnownMarketplaces 還沒有可用清單，也不要把 Copilot CLI 或 VS Code 插件開放當成模型試跑的附帶福利。先讓一個小組列出必要 marketplaces、驗證插件來源、記錄安裝失敗案例，再把設定推到更大範圍。
管理員開會時要填的欄位
導入討論最容易卡在抽象詞，例如「高風險」、「快一點」、「比較便宜」。把會議改成具體欄位，決策會快很多。每個 organization 至少要填：組織名稱、repo 與資料敏感度、可用模型、可用插件來源、允許任務、需升級審查的任務、驗證方式、例外批准者、例外期限與回收日期。
欄位不需要一次填到完美。先讓低敏感研發組織跑一輪，保留失敗案例，再把經驗複製到其他 organization。好的模型治理會讓不同風險的團隊拿到剛好的能力與約束，而不是只留下全開或全關兩個選項。
常見決策問題
MAI-Code-1-Flash 已經進 Business／Enterprise，仍不代表它適合所有企業任務。GitHub 的公告確認它已 generally available，並說它適合快速、低延遲、高頻迭代的 agentic coding 工作流；這是模型定位，不是風險豁免。企業仍應依 repo 敏感度、任務副作用、測試與 review 成本決定是否開放。
Targeted model rules 也不用和 enterprise-wide setting 二選一。enterprise-wide setting 適合當基線，targeted model rules 適合處理不同 organization 的風險差異。小團隊可以先維持基線；多業務單位、受監管資料、外包混合團隊或跨國開發團隊，才更需要細分。
strictKnownMarketplaces 不能取代模型治理。它管的是 VS Code 與 Copilot CLI 的插件安裝來源，目標是減少未受信任插件在工具執行前進入工作流。模型治理仍要處理可用模型、任務風險、資料邊界、成本與審查流程。
只要開始試跑新模型或 Auto mode，就該看 Copilot usage metrics。單次回應變快不代表總成本下降；使用頻率增加、代理任務變長或返工率上升，都可能讓總成本與 review 成本增加。至少在試跑第一週檢查每日使用量、活躍使用者、成本訊號與失敗案例。
結論：把新模型當成權限設計
GitHub Copilot 的模型治理正在從單一開關變成多層路由：enterprise default 決定基線，targeted model rules 決定組織差異，strictKnownMarketplaces 決定插件入口，MAI-Code-1-Flash 則提供新的低延遲 coding model 選項。
企業最安全的路徑，是先讓低敏感團隊試跑，明確列出可用模型、可用插件、禁止任務、驗證方式與例外期限。受監管、資料敏感、外包或長任務代理場景則維持較窄權限，等成本、品質與回滾流程有證據後再擴大。這樣新模型帶來的是可控的效率，而不是事後才補的治理債。