AI 治理不是一份原则清单，而是一套运行机制

“公平、透明、安全、以人为本”可以写进一页原则，却不能决定一个招聘筛选模型要测什么、谁能批准上线、出现误判后如何暂停。原则只有被翻译成责任、门禁、证据和处置动作，才会改变产品行为。

治理的核心不是给所有项目增加相同表格，而是把有限审查资源放在影响更大、难以逆转的系统上，同时让低风险实验有清晰的快速通道。它应该是一套随着系统变化而运行的机制，而不是发布前一次签字。

先建立系统清单，再谈原则落地

组织首先要知道哪些产品、内部工具和第三方服务正在使用 AI。清单至少记录用途、影响对象、模型与供应商、输入数据、输出如何进入决策、负责人、部署地区和当前状态。没有清单，模型升级、供应商替换或监管变化都无法确定影响范围。

NIST AI RMF Core用 Govern、Map、Measure、Manage 组织风险活动，并强调 Govern 贯穿其他功能。这里的启示不是照抄四个标题，而是让业务情境、测量证据和处置决策保持关联。

按影响分级，而不是按模型名称分级

同一个基础模型可以用于润色内部邮件，也可以用于影响贷款、就业或医疗服务。风险来自用途、规模、数据和后果，不来自产品宣传中的“生成式”或“智能体”标签。分级至少考虑影响对象、错误严重度、可逆性、人工复核、使用规模和敏感数据。

欧盟《人工智能法案》正式文本采用基于风险和具体用途的监管结构；具体适用范围和时间表仍应依据经营地区与最新官方指引判断。内部风险分级不能替代法律意见，但可以让产品、法务和安全团队使用同一张系统地图开展判断。

一个可操作的三级例子是：低风险为内部润色且不影响权益；中风险为给人员提供建议并可能影响服务质量；高风险为直接影响机会、资金、安全或基本权利。每一级对应不同的批准人、评测深度、日志保留和人工监督，且允许风险与用途变化时重新分级。

控制点	产品负责人	工程/数据	风险与法务	业务负责人
用途与影响分级	R	C	C	A
数据来源与权限	C	R	A	I
评测和红队测试	A	R	C	C
高风险上线批准	R	C	C	A
事故暂停与通知	R	R	C	A

一项任务只能有一个清晰的最终负责角色；表格中的部门名称可按组织结构调整。

把证据包嵌入发布流程

每个进入生产的系统都应有最小证据包：用途与禁止用途、数据来源与处理方式、模型和提示版本、评测集、分组结果、已知限制、人工监督、监控指标、供应商依赖和回滚方案。证据应链接到真实测试与变更记录，而不是复制模板句子。

NIST 生成式 AI 风险管理配置文件列出生成式系统特有风险及对应行动，适合作为风险发现来源；ISO/IEC 42001则把 AI 管理放进持续改进的管理体系。两者都不能替组织决定可接受风险，却能帮助团队避免只审模型、不审流程。

证据包应随模型、数据、提示、工具或用途的重大变化更新。供应商静默升级模型也可能改变输出，因此合同、版本锁定和回归测试属于治理，而不只是采购细节。

第三方模型不能把责任完全转移给供应商。采购审查应确认数据是否用于训练、子处理方、事件通知、版本变更、删除与导出、可用性承诺和终止后的迁移。供应商无法提供的证据，需要由部署方用限制用途、增加监控或保留人工决定来补偿。

评测要覆盖损害，而不只是平均准确率

平均分可能掩盖少数群体、罕见场景或高后果错误。评测设计应从影响路径倒推：谁可能受损，错误如何发生，是否能被发现和纠正。对于自动摘要，关键风险可能是遗漏限制条件；对于权益决策，则要检查不同群体表现、解释、申诉和人工复核。

在发布门禁中定义明确阈值：哪些指标未达标必须阻止上线，哪些问题可以在有限流量下观察，哪些变化需要重新批准。不能把所有指标汇成一个总分，让无关优势抵消不可接受的安全问题。

评测材料本身也要治理：谁设计样本、是否包含真实受影响群体、标签如何解决分歧、多久更新。只用开发团队编写的理想提示，往往低估误用、语言差异和无障碍场景。高影响系统应让业务、风险和受影响视角参与样本审查。

上线后监控的是风险信号

生产监控除了延迟和错误码，还要覆盖输入漂移、拒答率、人工推翻率、权限拒绝、敏感信息泄露、异常工具调用和投诉。高风险系统需要抽样复核和分组指标；无法直接看到真值时，可以用人工标注、延迟反馈或业务结果建立代理信号。

每项信号都应绑定动作：超过阈值后降级到只读、切回旧模型、扩大人工复核或暂停功能。只有告警没有处置权限，治理仍然停留在看板上。

治理团队自身也需要指标，但不应只统计完成了多少审核。更有意义的是高风险系统清单覆盖率、变更后回归完成率、告警到止损时间、重复事故比例和责任人空缺。指标目标是发现控制失效，而不是制造更多合规活动。

事故机制要允许先止损、后归因

AI 事故可能来自模型、数据、提示、权限、界面或人员误用。处置流程应保留输入、版本、工具调用和影响对象，在保护隐私的前提下复现事件。严重事件先缩小影响面，再讨论根因和责任，避免等待完美解释才停止系统。

复盘结果要回到评测集、风险清单和发布门禁：新失败样本进入回归测试，缺失控制补进责任表，供应商问题形成升级或替换条件。这样治理才会随着真实事件变强。

小团队也能运行的最小治理闭环

规模不大的团队可以从五项动作开始：维护 AI 系统清单；为每个用途指定业务负责人；按影响分三级；上线前保存最小证据包；为高风险功能设置暂停开关和事故联系人。低风险内部工具可以轻量审查，高风险外部决策则增加独立复核。

每季度复查清单和风险等级，每次重大模型、数据、工具或用途变更触发即时复查。已经停用的系统也要确认密钥、数据副本和自动任务确实关闭，避免“下线”只发生在界面上。

治理不是让每个实验都变慢，而是让实验知道边界、让上线拥有证据、让事故有人处置。它还应让人员和用户知道如何质疑、申诉和纠正系统决定，并能追踪纠正是否真正完成。治理记录必须能被复核，而不是只供项目组自我声明。原则说明组织相信什么，运行机制才决定这些原则在预算、进度和事故压力下是否仍然有效。