AI 治理正在从“发布一份负责任 AI 政策”转向“在系统运行时持续证明策略确实生效”。微软近期提出了一套覆盖九个治理领域的 AI 治理架构，并将治理能力归纳为四项职能：政策、控制、可见性和证明。
这套思路的关键，不是增加一层静态审批流程，而是把治理要求接入 AI 应用和智能体的实际执行路径：身份验证、权限控制、安全检测、运行时策略、持续评估、可观测性以及审计证据共同形成闭环。对正在生产环境部署 AI 的组织来说，治理因此从文档管理问题变成了系统工程问题。
治理不应停留在政策文档
传统治理往往以制度文件为中心。团队定义哪些数据不能发送给模型、哪些任务需要人工审核、哪些输出属于高风险，然后把要求交给开发人员自行实现。问题在于，政策和实际行为之间很容易出现偏差：
- 应用可能调用了未经批准的模型或工具。
- 智能体可能在用户权限之外读取数据或执行操作。
- 高风险请求可能绕过人工审批，直接进入下游系统。
- 审计人员能够看到一份政策，却无法证明某次生产请求确实遵循了政策。
运行时治理要求系统在请求发生时做出判断。例如，网关可以检查调用者身份和数据分类，策略引擎可以决定是否允许工具调用，输出检测器可以识别敏感信息，审计系统则记录策略版本、决策结果和相关证据。
这意味着治理规则需要拥有机器可执行的表达形式，并且必须能够绑定到具体的请求、模型、工具和用户身份上。
四项职能构成治理闭环
微软总结的四项职能可以理解为一条从“要求”到“证据”的链路。
政策：定义什么是允许的
政策描述组织希望达到的目标，例如：
- 哪些模型可以用于生产流量。
- 哪些数据类型不能发送到外部模型。
- 哪些操作必须经过人工批准。
- 哪些风险等级需要更严格的监控和留痕。
政策层应该尽量保持稳定、清晰，并且能够映射到具体控制项。只写“不得滥用个人数据”还不够，需要进一步说明系统如何识别个人数据、在哪个边界拦截、谁可以批准例外。
控制：在运行时执行要求
控制是治理真正进入产品的地方。常见控制包括身份认证、基于角色的授权、模型和工具白名单、输入输出过滤、速率限制、人工审批以及紧急停止机制。
控制不能只部署在前端。任何会影响数据访问、外部操作或业务状态的规则，都应在服务端、工具网关或智能体运行时再次验证，因为客户端提示词和界面限制都不具备足够的安全边界。
可见性：知道系统正在做什么
没有可见性，组织无法判断控制是否覆盖了真实流量。可观测性至少应关联以下信息：
- 请求者、服务账号或智能体身份。
- 使用的模型、模型版本和策略版本。
- 输入输出的数据分类或风险标签。
- 调用过的工具、目标资源和执行结果。
- 策略命中、拒绝、升级人工审核等决策。
对智能体系统来说，仅记录最终答案通常不够。开发和审计人员还需要知道它访问了哪些工具、进行了哪些高影响动作，以及每一步是由哪项策略授权的。
证明：让治理结果可审计
证明不是简单保存一份日志，而是建立可以复核的证据链。一次重要的 AI 操作至少应能回答：谁发起了请求，系统使用了什么配置，哪些策略参与决策，最终采取了什么动作，以及是否发生了人工干预。
证据还需要考虑完整性、保留期限、访问权限和敏感信息脱敏。把完整提示词和模型输出永久写入普通日志，可能会引入新的隐私风险；但只记录一个“允许”状态，又可能无法支持事故调查。因此，证据设计需要在可审计性和数据最小化之间取得平衡。
九个治理领域需要互相连接
覆盖九个领域的架构说明，AI 治理不能由单一团队或单一产品独立完成。政策管理、身份、数据、模型安全、应用安全、风险评估、监控、合规和审计之间需要共享上下文。
例如，一条“禁止高敏感数据发送到外部模型”的规则，至少依赖四类能力：数据分类系统提供标签，身份系统确认调用者，模型网关识别目标模型，审计系统记录最终决策。如果其中任何一环无法关联，治理要求就可能停留在理论层面。
持续评估也很重要。模型版本、提示词、工具权限和业务数据都会变化，发布前通过的测试不能代表生产环境长期合规。组织可以定期运行红队测试、策略回归测试、越权测试和输出质量评估，并将结果与生产遥测数据结合起来。
可以这样实现一个运行时治理门
下面是一个可直接运行的 Python 示例。它不是某个具体平台的官方实现，而是一个最小化实践，用来展示如何把数据分类、模型白名单、风险等级和人工审批接入请求路径。
运行前只需要安装 Python 3.9 或更高版本，将代码保存为 governance_gate.py 后执行 python governance_gate.py。
from dataclasses import dataclass, asdict
from typing import Dict, List
import json
@dataclass
class Request:
user_id: str
model: str
data_classification: str
risk_level: str
action: str
POLICY = {
"allowed_models": {"gpt-4o", "internal-safe-model"},
"blocked_data": {"restricted", "secret"},
"approval_required_risk": {"high", "critical"},
"approval_required_actions": {"send_email", "transfer_money", "delete_record"},
}
def evaluate(request: Request) -> Dict[str, object]:
reasons: List[str] = []
decision = "allow"
if request.model not in POLICY["allowed_models"]:
decision = "deny"
reasons.append("model_not_approved")
if request.data_classification in POLICY["blocked_data"]:
decision = "deny"
reasons.append("data_classification_blocked")
needs_approval = (
request.risk_level in POLICY["approval_required_risk"]
or request.action in POLICY["approval_required_actions"]
)
if decision == "allow" and needs_approval:
decision = "require_human_approval"
reasons.append("human_approval_required")
return {
"decision": decision,
"reasons": reasons,
"policy_version": "2025-01-01",
"subject": request.user_id,
"request": asdict(request),
}
if __name__ == "__main__":
samples = [
Request("alice", "gpt-4o", "internal", "low", "summarize"),
Request("bob", "external-model", "internal", "low", "summarize"),
Request("carol", "gpt-4o", "internal", "high", "send_email"),
Request("dave", "gpt-4o", "secret", "low", "summarize"),
]
for sample in samples:
print(json.dumps(evaluate(sample), ensure_ascii=False))
在真实系统中，可以将 evaluate 放在模型网关、工具调用网关或智能体执行器之前，并进一步补充：
- 从企业身份系统获取用户和服务账号属性。
- 从数据发现或 DLP 系统获取数据分类。
- 使用集中式策略服务管理策略版本。
- 对每次决策写入结构化审计事件。
- 对高风险动作生成审批任务，而不是只返回错误。
- 将拒绝率、策略命中率和人工审批结果接入监控系统。
关键点是让“允许”也成为一个可解释的决策，而不是默认行为。这样，审计人员既能检查被拒绝的请求，也能抽样验证被允许的请求确实满足了当时生效的条件。
落地时先建立证据链
企业不必一开始就建设覆盖所有场景的大型治理平台。可以选择一个高影响工作流，例如客服智能体读取客户资料并创建工单，然后完成一条端到端链路：确认身份，分类数据，限制工具权限，评估风险，拦截不合规请求，记录策略决策，并保存足够的审计证据。
落地过程中需要特别注意三点。第一，策略版本必须随请求记录，否则规则变更后很难还原历史决策。第二，人工审批不能成为无限期的旁路，应设置审批人、有效期和动作范围。第三，日志中的提示词、文件内容和个人信息需要按敏感等级脱敏和分级访问。
可以用下面的清单检查一个 AI 工作流是否具备基本运行时治理能力：
- 每个请求和工具调用都有可验证的身份。
- 生产模型和工具都有明确的允许列表。
- 敏感数据分类能够参与运行时决策。
- 高风险操作会被阻断或升级人工审批。
- 输入、输出和工具调用具备持续评估机制。
- 关键决策关联策略版本和审计证据。
- 监控能够发现策略失效、异常调用和越权行为。
- 紧急情况下可以撤销模型、工具或智能体权限。
AI 治理的成熟度，最终取决于组织能否在系统运行时回答“为什么允许这次行为”以及“如何证明它符合要求”。把政策、控制、可见性和证明连接起来，才能让治理从文档承诺变成生产系统中的可验证能力。