团队 AI 使用规范：密钥、数据、代码、审批和日志留存
团队开始使用 AI 后，最危险的状态不是“用得太多”，而是“每个人都在用，但没人知道怎么用”。
有人把生产日志粘到聊天窗口，有人把 API key 写进脚本，有人用个人账号处理客户数据，有人让 agent 自动改代码却没有审查。短期看只是效率工具，长期看就是安全、合规和工程质量风险。
一份好的 AI 使用规范不需要写成厚厚的制度文件，但必须回答几个基本问题：哪些工具能用，哪些数据能发，密钥怎么管，代码怎么审，什么情况要审批，日志留多久。
先定义适用范围
规范要先说明它管什么。否则团队很容易把“AI 使用”理解成只管聊天机器人，却漏掉代码 agent、浏览器插件、会议转写、客服自动回复、文档总结和内部脚本。
建议覆盖这些场景：
- 网页版 AI 聊天工具
- IDE 插件和代码补全工具
- 命令行 coding agent
- 通过 API 调用的大语言模型
- 会议纪要、邮件总结、知识库问答
- 连接内部系统的 AI agent
- 第三方 SaaS 中内置的 AI 功能
规范不必一开始就覆盖所有细节，但至少要明确：只要工具会接收公司数据、生成公司代码、访问内部系统或代表用户执行动作，就属于治理范围。
密钥和账号：禁止个人随意扩散
AI API key 应该像数据库密码和支付密钥一样管理，而不是像普通配置项一样随手发在群里。
基本规则可以很直接：
- 禁止把 API key 写进代码仓库、文档截图、聊天记录或工单评论。
- 生产密钥只能放在密钥管理系统或受控环境变量里。
- 开发、测试、生产环境使用不同密钥。
- 每个系统或服务使用独立密钥，避免一个 key 贯穿所有业务。
- 密钥必须有负责人、用途、创建时间和轮换计划。
- 离职、项目结束、供应商变更时要撤销或轮换密钥。
如果团队使用 AI 中转站或统一网关，也不要把它当成“共享 key 仓库”。网关应该提供用量记录、限额、权限和审计能力。否则只是把风险集中到另一个地方。
数据分级：不是所有内容都能发给模型
规范里最重要的一页，应该是数据分级。
一个简单版本可以分成四档：
| 等级 | 示例 | AI 使用规则 |
|---|---|---|
| 公开数据 | 官网文案、公开文档、公开招聘信息 | 可使用批准工具 |
| 内部数据 | 普通项目计划、内部流程、非敏感会议纪要 | 可使用公司批准工具，避免个人账号 |
| 敏感数据 | 客户资料、财务、合同、工单、业务日志 | 需要脱敏、审批或专用环境 |
| 禁止输入 | 密钥、密码、未脱敏身份信息、高风险生产数据 | 默认不得输入外部模型 |
这张表要结合公司的行业和合规要求调整。重点不是分类名字，而是员工一眼能判断：这段内容能不能发，能发到哪里，是否需要脱敏。
如果模型部署在本地或私有环境，规则也不能完全放开。本地模型仍然可能有日志、缓存、权限、越权访问和模型输出泄露问题。部署位置会影响风险，但不会自动消除风险。更多取舍可以看 本地模型和云模型怎么选？。
代码使用：AI 可以写代码，但不能绕过工程流程
AI 生成代码必须经过和人工代码一样的工程流程。
建议写清楚：
- AI 生成代码必须进入版本控制，不能直接改生产环境。
- 重要改动必须经过 code review。
- 涉及权限、支付、数据迁移、安全策略、加密、审计的代码，必须人工重点审查。
- 不能让 AI 在未授权情况下读取私有仓库、客户代码或第三方受限代码。
- 不能接受没有测试、没有解释、无法维护的大段生成代码。
- 不能用 AI 生成许可证来源不明的代码并直接合入。
这不是排斥 AI 编程工具。相反，规范越清楚，AI 越容易被安全地使用。它可以读代码、补测试、迁移样板、查调用链、修小 bug，但不能绕过审查、测试和发布流程。
审批：把高风险场景单独拎出来
不是每一次使用 AI 都需要审批。审批太重，团队会绕开流程；审批太轻，高风险场景会失控。
可以把审批集中在几类情况：
- 首次引入新的 AI 供应商或 SaaS 工具。
- 让 AI 访问内部数据库、工单、代码仓库或客户数据。
- 把敏感数据发送到外部模型。
- 让 agent 自动执行写操作，比如发邮件、改配置、提交代码、调用生产接口。
- 面向客户自动输出且可能影响权益的回答。
- 长期留存提示词、对话或用户数据用于训练、评估或分析。
审批要有记录，但不要只停留在“领导同意”。记录里应该有工具名称、数据类型、用途、负责人、保留期限、退出方式和风险控制措施。
日志留存：既要可审计，也要少存敏感内容
AI 使用日志很重要，但日志本身也可能变成敏感数据集合。
建议把日志分成两类：
- 用量和审计日志：谁在什么时候调用了什么工具、模型、业务入口、token、成本、状态、request id。
- 内容日志：完整 prompt、上下文、输出、工具返回内容。
用量日志通常应该保留得更稳定，因为它用于成本控制、审计和故障排查。内容日志要更谨慎：默认不要长期保存完整敏感内容，必要时做脱敏、采样、缩短保留期或只在受控环境可见。
如果团队在做 agent，可观测性也要纳入规范：每个 agent run 应该有 request id、步骤记录、工具调用、错误分类和最终结果。具体做法可以看 给 AI agent 做可观测性：日志、trace、token 和错误分类。
员工培训：规范要能被普通人执行
很多安全事故不是因为员工不负责，而是因为规则太抽象。
不要只说“禁止上传敏感信息”。要给具体例子：
- 可以发：公开 API 文档、脱敏后的错误信息、自己写的非敏感草稿。
- 谨慎发：内部会议纪要、客户问题、业务报表、代码片段。
- 不要发：API key、密码、未脱敏日志、身份证号、银行卡、生产数据库导出。
也要提供安全替代路径。比如告诉员工：如果要让 AI 分析生产错误日志，先用内部脱敏工具处理；如果要分析客户工单，使用公司批准的工具；如果要让 agent 访问仓库，必须用受控账号和最小权限。
一个轻量模板
一份简化版团队规范可以这样落地：
- 批准工具清单：哪些 AI 工具可以用于哪些场景。
- 数据分级表：公开、内部、敏感、禁止输入。
- 密钥管理规则：存放、权限、轮换、撤销。
- 代码使用规则：必须 review、测试和遵守许可证要求。
- 审批清单：哪些场景必须先审批。
- 日志和留存策略：记录什么、保存多久、谁能看。
- 违规处理和反馈渠道：发现问题后如何上报和修正。
这份规范不需要一次写到完美。先覆盖高风险路径，再根据实际使用和事故复盘迭代。
结论
AI 使用规范的目标不是阻止团队使用 AI，而是让团队知道怎么安全、稳定、可审计地使用 AI。
先管住密钥，再定义数据边界；允许 AI 辅助代码，但不能绕过工程流程；把高风险场景纳入审批；保留必要的用量和审计日志，同时谨慎处理完整内容日志。
规则越清楚，团队越不需要靠猜。