AI 治理正在从“写一份政策文件”转向“让系统在运行时执行政策”。Microsoft 最近介绍了一套覆盖九个治理领域的架构，并将治理工作归纳为四项功能：政策（policy）、控制（control）、可见性（visibility）和证明（proof）。
这套思路的关键不在于增加更多审批表，而在于把治理要求接入 AI 应用和智能体的真实运行过程：请求是否允许发送、调用哪个模型、能访问哪些数据、输出是否需要评估、异常是否被记录，以及组织能否在审计时拿出可验证的证据。
从静态政策到运行时控制
传统治理通常停留在文档层面。例如，企业规定“敏感数据不得发送给未经批准的模型”，但真正执行请求的应用可能没有数据分类、模型白名单或阻断机制。结果是政策存在，行为却无法验证。
运行时治理需要把一条政策拆成几个可执行问题：
- 谁在发起请求？用户、服务账号还是某个智能体？
- 请求要访问什么数据？数据是否包含个人信息、财务信息或内部机密？
- 请求将发送到哪个模型或外部服务？该目标是否经过批准？
- 输入和输出是否需要脱敏、内容安全检查或人工复核？
- 这次决策是否留下了足够的日志和证据？
可以把一次 AI 调用抽象成一个需要被治理的运行时事件：
身份 -> 数据分类 -> 策略匹配 -> 风险评估 -> 允许/拒绝/升级 -> 记录证据
这样，政策不再只是供员工阅读的规则，而是由网关、策略引擎、身份系统、评估服务和审计存储共同实现的控制流程。
四项功能如何协同
1. Policy：定义组织允许什么
政策层描述目标和边界，例如：
- 只有经过批准的模型才能处理企业数据。
- 高风险场景必须进行人工复核。
- 个人信息不能进入公共模型请求。
- 智能体只能调用其身份被授权的工具。
政策应尽量包含可判断的条件。比如，“谨慎使用客户数据”无法直接执行，而“数据分类为 restricted 时，只允许调用模型组 internal-approved”更适合落地为规则。
2. Control：在运行时执行决定
控制层负责实际动作。它可以允许请求，也可以拒绝、脱敏、降级到其他模型，或者将请求转交人工审核。
对 AI 应用而言，控制点通常分布在多个位置：API 网关负责模型和服务访问，数据层负责权限与过滤，工具调用层负责智能体行动边界，输出层负责安全检查和发布策略。
3. Visibility：知道系统正在发生什么
没有可见性，组织很难回答“哪些模型被使用”“哪些请求被阻断”“风险集中在哪些应用”这些问题。可观测性至少应覆盖：
- 应用、用户、服务账号和智能体身份
- 模型、版本、区域和供应商
- 输入输出的风险分类与评估结果
- 策略命中、拒绝、升级和例外情况
- 延迟、成本、错误率以及工具调用链
日志不应只记录“调用失败”。对于治理而言，策略版本、数据分类、决策结果和关联请求 ID 往往同样重要。
4. Proof：证明控制确实生效
证明是治理体系容易被忽视的一环。组织不仅要说明“我们有政策”，还要能证明“政策在生产环境中被执行过”。
可用的证据包括：策略版本和发布时间、模型审批记录、访问控制变更、运行时决策日志、持续评估报告、人工复核记录，以及异常处理结果。
证据应具备可追溯性：给定一次请求，能够关联到调用方、数据分类、策略版本、决策结果和后续动作。对于敏感场景，还需要考虑日志脱敏、访问权限和保留周期，避免为了审计而复制一份新的敏感数据。
一个可改造的运行时策略示例
下面是一个简化的 YAML 策略示例。它不是某个特定产品的配置格式，但可以作为网关或策略引擎的设计起点。运行前需要根据实际系统替换模型名称、身份字段和数据分类标签。
version: "2025-01"
name: "enterprise-ai-runtime-policy"
models:
internal-approved:
- "company-chat-prod"
- "company-reasoning-prod"
public:
- "public-chat"
rules:
- id: "block-restricted-data-on-public-model"
when:
data_classification: "restricted"
model_group: "public"
decision:
action: "deny"
reason: "Restricted data cannot be sent to a public model"
- id: "require-review-for-high-risk-agent"
when:
application_type: "agent"
risk_level: "high"
decision:
action: "require_human_review"
queue: "ai-risk-review"
- id: "allow-approved-model-for-internal-data"
when:
data_classification: "internal"
model_group: "internal-approved"
decision:
action: "allow"
audit_event: "ai.request.allowed"
logging:
required_fields:
- "request_id"
- "principal_id"
- "application_id"
- "model_id"
- "policy_version"
- "data_classification"
- "decision"
redact:
- "prompt"
- "response"
一个最小的服务端决策流程可以这样实现：
from dataclasses import dataclass
@dataclass
class Request:
principal_id: str
application_id: str
data_classification: str
model_group: str
application_type: str
risk_level: str
def decide(request: Request) -> dict:
if (
request.data_classification == "restricted"
and request.model_group == "public"
):
return {
"action": "deny",
"reason": "Restricted data cannot be sent to a public model",
}
if request.application_type == "agent" and request.risk_level == "high":
return {"action": "require_human_review", "queue": "ai-risk-review"}
return {"action": "allow"}
request = Request(
principal_id="svc-support-agent",
application_id="ticket-summarizer",
data_classification="restricted",
model_group="public",
application_type="agent",
risk_level="high",
)
print(decide(request))
运行这段代码会返回拒绝结果，因为 restricted 数据不能发送到 public 模型。生产实现还需要补充身份验证、策略签名、策略版本管理、日志发送、超时处理和默认拒绝策略。尤其不能只在前端显示警告，真正的阻断必须发生在调用模型或工具之前。
持续评估比一次性审批更重要
AI 应用会变化：提示词会更新，模型会换版本，工具权限会扩大，数据源也可能发生变化。因此，初次上线审批不能替代持续评估。
可以把评估分成三个层次：
- 部署前评估：检查模型、提示词、工具和数据源是否符合目标场景。
- 运行中监测：观察策略命中、越权访问、内容安全风险、输出质量和异常调用链。
- 变更后复评：模型版本、策略、身份权限或外部服务发生变化时重新评估。
这也解释了为什么治理架构需要同时连接策略、控制、可见性和证明。只有策略，没有执行会变成文档；只有执行，没有观测会变成黑箱；只有日志，没有持续评估则很难判断控制是否仍然适用。
落地时的边界与取舍
运行时治理并不意味着所有请求都必须经过昂贵的人工审批。企业可以根据风险设置不同路径：低风险请求自动放行，中风险请求增加脱敏和监测，高风险请求暂停并要求复核。
同时要注意几个工程问题：
- 延迟：策略检查和安全评估应有明确的超时与降级策略。
- 可用性：治理服务不可用时，应根据风险选择故障关闭或故障开放，敏感操作通常更适合默认拒绝。
- 隐私：审计证据需要可追溯，但不等于保存完整提示词和响应。
- 策略漂移：策略文件、模型配置和实际部署状态必须定期比对。
- 权限边界：智能体的模型权限、数据权限和工具权限应分别管理，不能只依赖一个总开关。
一个实用的启动清单是：先选一个高价值且风险明确的 AI 工作流，建立统一请求 ID 和身份信息，再增加模型白名单、数据分类、运行时决策日志和阻断规则。等这些基础能力稳定后，再扩展到持续评估、自动化证据收集和跨应用治理。
结语
Microsoft 提出的方向反映了 AI 治理正在发生的变化：治理不再只是合规团队维护的政策集合，而是生产系统中的一组可执行控制。把政策连接到运行时强制执行、持续评估、可观测性、身份、安全和审计证据，组织才能回答两个关键问题：系统是否按规定运行，以及我们能否拿出证据证明这一点。
对于工程团队，最重要的下一步不是再写一份更长的政策，而是找出一个真实的 AI 调用链，明确它的身份、数据、模型、工具和决策点，然后让每个关键要求都能被执行、观测和验证。