Copilot全局模型策略：企业别再靠默认开启
企业接入多模型以后，一个非常常见的状态是：
管理员没有明确配
↓
平台新模型上线
↓
用户自动就能用了
这对个人用户很方便，对企业治理却不一定合适。
GitHub 8月26日开始逐步执行 Copilot 的 Global Model Policy，并计划在 9月1日前完成 rollout。核心变化是：
以前没单独配置过的模型
+
新上线的GA模型
会继承企业的全局默认策略。
GitHub 同时明确：
Open-weight模型默认禁用
需要数据保留、且不在GitHub数据保留协议覆盖范围内的模型默认禁用
管理员已经显式 Enabled / Disabled 的模型不会被全局策略覆盖。
这个机制真正值得企业 Agent 平台借鉴的，不是“GitHub多了一个设置”。
而是：
模型治理必须区分“明确选择”和“继承默认”。
如果系统里只有：
enabled=true/false
很多治理问题根本表达不出来。
两态模型不够
最简单：
public enum ModelState {
ENABLED,
DISABLED
}
问题是你无法知道：
是谁决定的？
是企业策略？
组织策略？
团队策略？
还是平台默认？
真正需要的是：
Decision
+
Source
一个更完整的状态
public enum ModelPolicyState {
EXPLICIT_ENABLED,
EXPLICIT_DISABLED,
INHERIT_ORG,
INHERIT_ENTERPRISE,
INHERIT_DEFAULT
}
再保存：
public record ModelPolicyDecision(
String modelId,
ModelPolicyState state,
String decidedBy,
String policyVersion,
Instant decidedAt) {
}
这样 UI 才能真正解释：
为什么这个模型现在可用
为什么“继承”必须显示出来
假设：
Model A
今天可用。
管理员以为：
之前有人批准过
实际只是：
默认策略=Enabled
下个月企业把默认策略改成：
Disabled
Model A 立刻不可用。
如果 UI 只显示：
Enabled
团队会非常困惑。
所以可用状态最好拆成：
Effective State
Policy Source
例如：
{
"model": "model-a",
"effective": "ENABLED",
"source": "ENTERPRISE_DEFAULT",
"explicit": false
}
GitHub现在有4种可见状态
公开说明里最终模型会显示类似：
Enabled
Disabled
Delegate to enterprise teams/apps or organizations
Delegate to default policy
这本质上就是：
Override
+
Inheritance
传统 IAM 和 Feature Flag 里非常常见。
模型治理也应该这么做。
企业模型目录至少要有这些字段
public record ModelCatalogEntry(
String modelId,
String provider,
ModelClass modelClass,
boolean openWeight,
DataRetentionClass retention,
Set regions,
Set capabilities,
RiskLevel riskLevel) {
}
不是只存：
name
price
context_length
因为企业决策通常取决于：
数据是否保留
是否开源权重
在哪个区域
能否调用工具
是否支持代码执行
我会把Data Retention单独建模
public enum DataRetentionClass {
ZERO_RETENTION,
CONTRACT_COVERED,
PROVIDER_STANDARD,
UNKNOWN
}
规则：
UNKNOWN
→默认不可用
而不是：
新模型先开
发现问题再关
Open-weight为什么要单独一类
GitHub 当前默认把 open-weight 模型排除在自动启用之外。
这不意味着：
open-weight = 不安全
而是它的治理属性不同。
企业可能要额外考虑：
部署位置
许可证
模型来源
权重供应链
运行环境
安全责任
所以模型目录最好把：
Distribution Model
也纳入策略。
一个Policy Rule
model_policy:
default: enabled
deny_if:
- data_retention: UNKNOWN
- region_not_allowed: true
require_explicit_approval_if:
- open_weight: true
- tool_use_risk: HIGH
这比一个总开关细得多。
新模型上线时不要直接继承“可用”
模型供应商更新速度很快。
平台每周可能新增：
Model A
Model B
Model C
如果全局默认是 Enabled，理论上用户无需任何 Review 就能开始使用。
更安全的企业策略通常是：
GA模型：
可继承
高风险模型：
必须显式
Preview：
必须显式
Unknown Retention：
禁止
Model Lifecycle也要进入治理
public enum ModelLifecycle {
PREVIEW,
GA,
DEPRECATED,
RETIRED
}
不同状态不同 Policy。
例如：
preview:
default: disabled
ga:
default: inherit
deprecated:
new_sessions: false
retired:
allowed: false
Deprecated不能只发邮件通知
如果一个 Agent 配置锁死：
model-x
模型进入 Deprecated，平台要知道：
哪些Agent依赖它
所以需要：
Model → Agent Dependency Graph
一个依赖表
create table agent_model_binding (
agent_id varchar(128) not null,
agent_version varchar(64) not null,
model_id varchar(128) not null,
routing_profile varchar(128),
primary key(
agent_id,
agent_version,
model_id
)
);
模型状态变化时，可以直接算影响面。
Policy变更前必须做Simulation
例如企业准备：
Default Enabled
→ Default Disabled
不要直接保存。
先模拟：
会影响多少用户？
多少Agent？
多少自动化？
哪些模型会变状态？
输出：
{
"models_changed": 14,
"agents_impacted": 38,
"scheduled_tasks_impacted": 112,
"users_impacted": 912
}
管理员确认后再执行。
这其实就是主线第22篇会继续展开的：
Policy Simulation
Durable Decision非常重要
GitHub 明确表示：
显式Enabled / Disabled
不会被全局默认覆盖
这叫：
Durable Override
企业内部也应该如此。
如果 Security 明确禁用：
model-x
以后 Platform Admin 改：
default=enabled
不能把它重新打开。
Override要保存Reason
public record ModelOverride(
String modelId,
boolean enabled,
String reason,
String ticketId,
String approvedBy,
Instant expiresAt) {
}
很多 Override 不应该永久。
例如：
临时PoC
可以：
30天后过期
到期重新 Review。
模型权限最好按Audience分层
Developer
Data Analyst
Finance
Legal
Security
不同团队对模型能力和数据边界要求不同。
所以：
Enterprise Default
之下还可以有：
Org / Team Overlay
例如：
enterprise:
default: enabled
legal:
deny:
- retention: PROVIDER_STANDARD
security:
allow_explicit:
- high_cyber_capability
但继承层级不能无限深
如果：
Enterprise
→ Org
→ Team
→ App
→ User
每层都有 Override，最终没人知道状态从哪来。
我会限制成：
Enterprise
→ Organization
→ Application
三层以内。
User 个人偏好不能突破管理员策略。
Effective Policy必须可解释
API：
GET /models/{id}/effective-policy
返回：
{
"model": "model-a",
"effective_state": "DISABLED",
"reason_chain": [
{
"level": "enterprise",
"state": "ENABLED"
},
{
"level": "organization",
"state": "DISABLED",
"reason": "data-retention-policy"
}
]
}
不要只返回：
403 Model unavailable
管理员排障会轻松很多。
每次Run都要保存Effective Model Policy
Agent Run：
public record ModelExecutionRecord(
String runId,
String requestedModel,
String effectiveModel,
String policyVersion,
String policyDecisionId) {
}
以后出事故能知道：
当时为什么允许这个模型
Policy Drift也需要告警
模型 Metadata 可能变化：
数据保留政策
区域
生命周期
能力
如果 Catalog 变了，现有 Policy 应重新评估。
例如：
Retention:
CONTRACT_COVERED
→ UNKNOWN
应该立即：
Re-evaluate Effective Access
不是等管理员下个月手工看。
发布新Agent也要检查Model Policy
Agent 配置：
models:
primary: model-a
fallback: model-b
发布前检查：
primary允许？
fallback允许？
目标Tenant都允许？
不要等生产 Failover 才发现备用模型被禁。
Fallback最容易绕过治理
正常：
Model A
经过批准。
出故障后：
自动切Model B
但 B 可能：
数据保留不同
区域不同
风险不同
所以 Fallback Policy 必须独立校验。
Primary Allowed
≠
Fallback Allowed
一个Model Routing Gate
public boolean canRoute(
TenantContext tenant,
ModelCatalogEntry model,
TaskRisk risk) {
return policyEngine.evaluate(
tenant,
model,
risk
).allowed();
}
Router 只能从：
Allowed Model Set
里做价格/性能优化。
最少测试这10种情况
1. 新GA模型继承默认策略
2. Explicit Disabled不被默认Enabled覆盖
3. Open-weight模型要求显式批准
4. Unknown Retention默认拒绝
5. Org策略覆盖Enterprise默认
6. 用户不能突破Org禁用
7. 模型Deprecated后新Run禁止
8. Fallback模型独立鉴权
9. Policy变更Simulation正确计算影响
10. Model Metadata变化触发Re-evaluate
企业多模型治理最危险的状态，不是：
一个模型被禁用了
而是：
大家都以为它是“有人批准后开启”，
实际只是继承了默认值。
GitHub 这次 Global Model Policy 把“显式选择”和“继承默认”分开，是一个很值得照搬的设计。
模型越来越多以后，企业真正需要管理的不是一张：
允许 / 禁止
列表。
而是一套：
Model Metadata
+
Inheritance
+
Explicit Override
+
Policy Version
+
Impact Simulation
+
Execution Audit
这才是多模型平台能够长期运转的治理基础。
更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：
https://www.zyentor.com/