企业用 Claude 的 8 个治理铁律：我给 3 家公司当过审计员

给第一家公司做审计的那周，我在他们办公室蹲了五天。每天都像挖盲盒——每拉一条日志出来，心跳就加速一次。

最后交付那份 43 页报告，CISO 看完给我发微信，就一句话：”这比我想象的还糟。”

那家公司之后三个月把治理体系重搭了一遍。我根据在他们那儿以及后来两家的经验，整出这 8 条铁律。不是网上抄的 best practice，是我亲眼见过违反之后出事儿的教训。

铁律 1：API key 必须层级化

原则：organization > workspace > project > user 四级隔离。

反面教材：我审的第一家公司，全公司 200 多个调 Claude 的服务，共用 2 个 API key。其中一个 key 是当年做 POC 时申请的，权限范围宽得能从长城外看到长城内。key 的 owner 那个哥们儿去年 10 月离职了，这个 key 还在到处跑。

修复方案：

• Organization 级：公司一个主账号，CFO + CISO + CTO 三签管理
• Workspace 级：按事业部切分，预算隔离
• Project 级：每个线上服务一个 key，带有预算硬上限
• User 级：开发调试用的个人 key，严格限额（月 $50 以内）

离职流程里加一条：”回收所有名下 API key”。这事儿要 HR 系统跟 Anthropic console 对接，或者至少有个 checklist。

铁律 2：预算硬上限 + 分级告警

原则：每个 key 必须有硬上限，告警分 50% / 80% / 100% 三级。

反面教材：第二家公司一个测试项目的 key，因为代码里的死循环，一夜从平均 $12 /天涨到 $2,847.12 /天。第二天早上发现的时候已经烧了 4 天。

修复方案：

• 50% 告警：发邮件给 project owner
• 80% 告警：发企业微信/Slack，PM 和 tech lead 都收
• 100% 告警：key 自动暂停 + 短信通知 CISO

这个机制实施以后，那家公司一个季度里拦下了 3 次类似的失控。自动暂停这条要跟 FinOps 团队吵一架才能定下来，因为业务方会担心误停。但我的经验是，误停 10 分钟可以解释，烧 $5 万没法解释。

铁律 3：审计日志保 90 天

原则：谁、在什么时间、用了什么 prompt、得到了什么输出，必须可查，保留至少 90 天。

反面教材：第三家公司被客户投诉某份文档里有错误信息，客户要求追查。他们去翻日志——没有。用的是直连 API 通过几个 Python 脚本调的，脚本里就打了”request success”这么一行。

修复方案：

审计日志至少记 8 个字段：时间戳、用户 ID、项目标签、model、输入 token 数、输出 token 数、prompt hash、完整 prompt 和 completion 的加密存储路径。

存储上用分级：30 天内热存储（随便查）、30-90 天温存储（需要工单）、90 天以上冷存储或删除（看行业合规要求，金融医疗可能要 7 年）。

查询接口要有权限控制。不是所有人都能翻别人的 prompt。审计员能翻全量，tech lead 能翻自己团队的，开发者只能翻自己的。

这个在 agent-sdk-production-deploy 里我讲过一部分生产部署时的日志架构。

铁律 4：敏感信息脱敏前置

原则：PII、PHI、PCI、商业机密，进 prompt 之前必须扫描 + 脱敏。

反面教材：第一家公司的客服系统，客服直接复制客户对话粘进 Claude 里让它帮忙写回复。客户对话里有身份证号、银行卡号、住址。这些全部原样传出去了。我发现这个问题的时候，直接让他们当天下架了那个功能。

修复方案：

在 prompt 组装的 gateway 层，用一个 PII 扫描器（presidio、aws comprehend 或自研正则库）过一遍。识别到的字段替换成占位符（[NAME_1]、[PHONE_1] 这种），Claude 返回之后再还原。

扫描器要覆盖：身份证、手机、邮箱、银行卡、地址、社保号、护照号、员工工号、客户 ID、合同编号。医疗场景再加病历号、诊断编码。

扫描不是完美的，会有 false negative。所以要配合铁律 5。

铁律 5：输出分类（3 档）

原则：Claude 的输出按敏感度分三档，分别对应不同的 review 流程。

• MUST APPROVE：涉及对外发送、法律文件、财务决策。必须人工审核 + 两人复核 + 留痕。
• 可直接用：代码生成、内部文档、日常问答。可以直接使用，但要有抽查机制（比如每天抽 5%）。
• 仅参考：探索性分析、brainstorm、脚本草稿。用户自己判断。

反面教材在第二家公司：他们的法律合同生成工具，output 直接流到了合同签署环节，中间没有律师 review。某次 Claude 生成的条款漏写了一个违约责任条款，差点签出去。

修复上不难，关键是把”这个输出到底什么用”标清楚。我的建议是在 prompt 模板里就打 tag，response 里带着 tag，下游系统根据 tag 决定 review 路径。

铁律 6：外发内容 diff review

原则：任何通过 AI 生成、即将发给客户/供应商/监管的内容，必须有 diff review。

反面教材：第三家公司一个市场营销邮件，Claude 生成后 PM 改了两处，发出去之前没人看最终版本。结果那封邮件里有一段 Claude 硬塞的”优惠活动详情”——是幻觉，公司根本没有这个活动。发给了 8,400 个客户。法务加班改了两天善后。

修复方案：

外发内容过一道 review 工作流，UI 上并排显示”AI 生成版 / 人工修改版 / 最终发送版”。Review 人必须签字确认。对了，签字要跟 HR 系统联动，不能”review 人：AI 助手”这种事儿出现（真有公司干过）。

自动化一点的做法：加一个 filter 层，检测 AI 输出里可能的幻觉点（比如具体的金额、日期、人名），强制要求人工逐项确认。

铁律 7：供应商变更通告机制

原则：Claude 版本升级、API 行为变化、价格调整、条款更新，必须有对内的通告和评估流程。

反面教材：Anthropic 去年某次调整了 content filter 的默认阈值，第一家公司有个内容审核应用直接误杀率涨了一倍，用户投诉。技术团队花了两天才定位到是外部变化。

修复方案：

订阅 Anthropic 的 changelog、Bedrock/Vertex 的 release note。每周 tech lead 级别碰头 15 分钟，过一遍有没有影响的变更。重要变更在内部发通告，给业务方时间准备。

另外搞一个”黄金集”回归测试：准备 200-500 条真实业务 prompt，每次 Claude 或基础设施有变动时跑一遍，看输出有没有显著飘移。这个思路跟 skill-testing-versioning 一个路子。

铁律 8：红队演练季度化

原则：每季度至少一次红队演练，包含 prompt injection、jailbreak、data leak 测试。

反面教材：第二家公司的 customer support agent 上线半年没做过任何安全测试。我去的时候随便试了三个 prompt injection，全过了，能让它输出系统 prompt、能让它调用不该调的工具、能让它泄露其他客户的对话片段。

修复方案：

季度红队要覆盖这几类：

• Prompt injection：用户输入里夹带指令，劫持 agent 行为
• Jailbreak：让 Claude 输出违反 policy 的内容
• Data exfiltration：让 agent 把它不该说的数据吐出来
• Tool abuse：让 agent 调用不合规的工具组合

测试用例库可以参考开源的 promptfoo、garak。红队执行最好请独立团队，不能自己测自己。

关于 MCP 相关的注入风险，mcp-security-best-practice 有详细的分析。

一个差点违约的真实事件

第一家公司治理审计前一个月，发生过一件事儿。

新入职的一位销售小哥，签了一份大客户的合同，上面明写了”乙方承诺不会将甲方的任何业务数据、合同内容用于第三方 AI 服务训练或推理”。

小哥不知道。他为了写一份跟这个客户的提案，把合同原文粘进 Claude 里让它帮忙”理解客户痛点”。当时用的是消费端 claude.ai，不是企业 API。

一周后客户的法务在走访过程中，要求检查乙方的合规体系。合规负责人翻 AI 使用记录，差点冒了一身冷汗。

幸好那家公司已经部署了 DLP（数据防泄漏）系统，出口侧拦截了合同文件的上传日志，能够证明 claude.ai 那边没成功传上去，只是个失败尝试。客户最后没追究，但签了一份补充协议，这家公司花了三个月做了整套治理升级。

这个事件后来变成他们所有新员工入职培训的第一个案例。我问那位 CISO 学到了什么，他说：”规则要写给普通人能看懂，不能写给安全工程师看。”

审计 checklist

如果你是内审或外审，拿这 20 条扫一遍基本能过：

1. API key 有没有分级？有没有 owner？
2. 有没有离职回收流程？
3. 每个 key 有没有预算上限？
4. 告警阈值 50/80/100 三档是否都配置？
5. 审计日志保留多久？
6. 日志里能不能追到具体用户？
7. PII 脱敏是否前置？
8. 脱敏规则覆盖哪些字段？
9. 输出分档机制有没有？
10. MUST APPROVE 类有没有双人签字？
11. 外发内容有没有 diff review？
12. 有没有定期抽查机制？
13. 供应商变更通告订阅了吗？
14. 回归测试黄金集有没有？
15. 红队演练多久一次？
16. prompt injection 测试覆盖了吗？
17. 有没有应急预案（API 宕机、超预算、数据泄露）？
18. DPA 签了吗？
19. SOC2 报告有没有存档？
20. 员工有没有做过 AI 使用合规培训？

20 条能答对 16 条以上，算及格。