企业 AI 治理：权限、审计与数据边界

企业 AI 治理，指的是让「谁可以用 AI 访问什么、做过什么、边界在哪里」都有可执行的答案。它容易走偏的地方在于把治理理解为写文档 —— 一份没有落到系统里的原则，既拦不住越界，也解释不清已经发生的事

治理不是流程文档

文档描述的是应该怎样，治理要回答的是实际怎样。判断一份治理方案是否落地，有个简单的检验：随便抽一次历史调用，能不能还原出调用者、依据的资料和输出的内容。还原不出，说明治理还停留在纸面。

三件套的最小实现

• 权限：按任务绑定数据范围，而不是按人给一套大权限；权限定期复核，并在人员或岗位变动时同步调整。
• 审计：记录调用者、时间、依据的知识条目、模型版本与输出，且记录留存期限事先约定。
• 数据边界：写清哪些数据不出域、由谁批准例外、以及如何验证边界确实生效。

三件套里最容易被省掉的是第三件。边界如果只写在制度里，没有被系统执行，那么它的实际状态是未知的 —— 既不知道有没有发生过外发，也说不出拦截记录在哪里。

谁负责什么

• 业务负责人：确认场景价值与风险可接受度，并对结果负责。
• 技术与平台团队：落地权限系统、审计日志、输出监控与版本管理。
• 合规与法务：确认数据分级、留痕要求与保留期限。
• 场景运营：日常复核输出质量，处理异常与转人工。

四类角色不是并列的四个部门，而是同一条链路上的四个环节。缺任何一环，出问题时都会出现「不是我这边定的」这类无法收尾的讨论。

把规则写进流程

每个新场景上线前都应通过同一套检查。这比事后补记录有效得多，因为上线之后再补，往往已经缺失关键信息

• 数据：涉及哪些数据、是否涉敏、是否在允许范围内。
• 权限：谁能用、能访问哪些数据、由谁审批。
• 审计：记录哪些字段、保留多久、谁能查看。
• 回滚：出现问题时的处置方式与责任人。

三种常见走偏

• 只建制度不看日志：规则写得很完整，但没有任何记录能证明它被执行过。
• 权限一次给到底：为了省事先开大权限，之后没人记得收回，最小权限基本失效。
• 把治理当成 IT 一个部门的事：业务不参与边界口径的确认，规则就会在真实场景里被绕开。

这三种走偏的共同结果是：出问题时无法给出确定答复，只能归因为「大概是这样」。治理的价值恰恰在于把「大概」变成能查到的事实。

验收

• 任意一次历史调用都能还原调用者、依据与输出。
• 权限做过至少一次复核，且有调整记录。
• 边界有过一次被真实拒绝的请求，作为规则生效的证据。
• 异常与转人工的处置路径被真实触发过，且有处理记录。