企业 AI 治理从哪里开始？权限、人工审核、日志与责任的落地清单

企业 AI 治理首先要回答：谁能把什么资料交给哪个系统，得到的结果给谁看，由谁批准行动，出了问题谁处理。它需要进入实际流程与配置，不能只以一份原则文件存在。本文讨论工程和管理实践，不替代特定业务的法律合规审查。

先画出资料到行动的路径

以知识助手为例，链路包括资料采集、处理、检索、模型上下文、结果呈现、对话记录、日志和导出。如果还能调用工具，就增加写回业务系统的路径。每一步都可能扩大访问范围或改变资料用途。

为每类用户记录读取、处理、输出查看、日志查看、导出和执行权限。外部顾问、开发人员、普通用户和管理员不应默认拥有同样权限。账户结束项目后如何撤销，也需要预先安排。

读取控制为什么还不够

资料一旦被获准读取，可能被生成到答案、导出到文件或记录在日志。保护原文件的规则，不一定会自动限制全部派生结果。

不同平台的权限传播机制不同，有的控制可以随派生数据传播，有的只在读取时过滤。不能据此推定下游输出和写回已被保护，实施时应核实具体系统与配置。

珞瑜建议独立检查派生内容，而不是把一句“遵守源权限”当作完整方案。

最小治理清单

这些记录不必一开始都采用复杂平台实现，但必须有人维护，并能与真实配置核对。写了控制却没有执行，与没有控制并无实质区别。

人工审核怎样避免流于形式

审核人需要看到来源、关键判断、不确定项和拟执行动作，而不是只得到一个批准按钮。对于高后果操作，应明确审核所需专业能力和时间，不让责任落到无法判断的人身上。

还要记录人工修改与否决原因，它们可以帮助发现持续性问题。但不能把所有点击都解释为充分理解。若审核量过大导致机械确认，应缩小自动化范围或改进流程，而不是简单增加免责声明。

日志应记录什么

日志服务于追踪问题、责任和成本，应包含必要的用户或角色、版本、时间、工具操作与结果状态。是否保存原始问题和完整资料，应按用途与客户约定决定，避免为了调试复制过多敏感内容。

日志同样需要访问限制、保留期限和处理程序。测试账户拥有全部日志读取权，不应成为正式环境的默认配置。故障分析需要临时提高权限时，也应留下审批与恢复记录。

变更和异常如何管理

模型、提示、检索配置、资料和接口变化都可能引入问题。先按影响范围测试，再决定发布；出现异常时应能够暂停受影响功能、恢复已知版本或转人工。

将责任、使用情境、测量和处置安排连接起来，持续检查控制是否有效。框架本身不是项目合规证明，也不能替代具体要求和客户政策。

从小试点到大企业怎样升级

小试点先明确授权、范围、人工复核和基本记录。扩大用户时，增加角色、环境与资料隔离测试；进入跨部门运行时，补齐变更、事故、恢复和持续维护资源。

不能把小范围可接受的人工控制直接复制到全公司，也不应为了治理而一开始采购与场景无关的大平台。每项要求应能解释它控制什么风险、由谁执行、如何检查。

项目开始前问服务商什么

谁会接触资料，第三方模型是否获准处理，如何测试越权，哪些动作必须审批，问题如何暂停，结束合作后如何交接？答案需要对应流程和配置，而不只是“我们重视安全”。采购问题可继续参考AI 服务商评估清单。