小型团队如何落地 AI 编程治理

10–100 人的团队用上 Claude Code、Cursor、Codex 或 Copilot 后，迟早要回答：哪些工具能碰公司仓库，哪些数据不能发，出事谁接警，又拿什么证明规则确实执行了？

作者给出的答案是一页制度、明确的责任人和每周 30 分钟复查。它的价值在于把规则落到具体控制，同时提醒你：装了 hook、接了网关，并不代表所有操作都受控。

一页制度要解决五件事，关键是有人负责

作者认为，小团队没必要照搬完整的 NIST AI RMF 或 ISO/IEC 42001 项目。这里的前提是：团队购买模型服务，没有专门的风险管理部门，眼前要解决的是编码代理访问公司代码的边界。

保留「识别、衡量、管理」的思路可以，但无需先写一份 40 页政策。

一页制度需要回答五个问题：

1. 批准哪些工具和套餐。 作者建议使用带管理能力的团队版或企业版，禁止个人版、免费版访问公司仓库。工程经理提案，CTO 批准；员工私下使用的工具，还要单独盘点。
2. 允许模型看到哪些数据。 技术负责人起草规则，CTO 对结果负责。不能只写一句「不要上传敏感信息」，还得明确文件和数据类型。
3. 哪些动作直接阻断。 密钥文件读取、未获准的外发、未获准的 MCP server 都要写清。平台人员或安全顾问实施，CTO 批准允许列表；例外必须记录原因和到期时间。
4. 告警发给谁。 P0 发给值班人员或安全负责人，覆盖缺口交给 IT 或平台人员。告警正文只能放会话标识、文件路径类别、检测器标识等证据指针，不能再次泄露密钥。
5. 保留什么证据。 运维或合规负责人维护，CEO/CTO 对留存期限和法律保全负责。

作者用 RACI 表强调责任分配：执行者和最终负责者可以不同，但后者不能空着。原文提供了各项职责说明，没有展示完整的 RACI 表，照搬时仍需补上本团队的人员安排。

规则有没有执行，最终要能追到具体负责人。

数据分级之后，还要确认失败时会发生什么

原文把数据分成三类。

绝不能发送的，包括真实密钥，如 .env、云密钥、数据库 URL，也包括无法说明处理必要性的受监管个人数据，以及合同禁止交给模型的客户材料。

谨慎发送的，包括应用源码、内部服务名和日志中的客户元数据。可以发送的，包括公开文档、合成测试数据和脱敏代码片段。源码并没有被作者一概归为「可以随便发」。

执行这些规则，首先可以使用目录排除和拒绝规则，例如 Claude 的 Read(./.env)、Copilot content exclusion。但作者提醒，符号链接和部分 agent 路径存在已知缺口。

ReclaimLLM 的本地脱敏层采用字符串替换和目录排除，没有进行语义分类。它可以处理已识别的模式，不能据此推断所有敏感业务内容都能被识别。

更关键的是失败行为。按作者说明，hook 正常运行时，识别到的 .env / *.env 读取会被脱敏或拒绝，这一类操作采用失败即阻断（fail-closed）。但 hook 崩溃、超时或外发后端报错时，仍可能失败后放行（fail-open）。

安装器没有为注入的 hook 设置 Claude 的 onFailure: "block" 或 Cursor 的 failClosed: true。团队需要更严格的行为时，要自行补上这些配置。

正常情况下能拦住，与控制组件故障时仍能拦住，是两个验收问题。

四层控制各管一段，网关看不到所有操作

作者建议按四层实施，而不是一开始就购买治理平台。

第一层是厂商原生设置。先部署 managed settings、Cursor team admin、Copilot org policies，以及 Codex sandbox requirements，让工具自身具备的管理能力先到位。

第二层是 hook，负责操作边界上的检查。原文称 ReclaimLLM 支持 Claude Code、Cursor、Codex、Copilot 和 Antigravity，提供数据防泄漏（DLP）及外发控制。这里描述的是产品能力，没有给出逐项测试结果。

第三层是企业 LLM gateway。团队级密钥让模型供应商凭据留在服务端，也方便集中管理模型策略。但网关只能检查经过自己的流量，本地文件读取、没有经过代理的 MCP 流量，都不在它的视野里。

第四层是检测。作者列出 AD-004、egress guard、AD-015 外发异常，以及网关异常，用来补充预防措施。原文没有提供误报率、漏报率或检测延迟，不能据此评估实际效果。

覆盖检测则回答「控制现在还在不在」。它能报告缺口，但不会远程重装 hook，也不会锁住笔记本。因此，coverage 不能当作强制执行，更不能当作移动设备管理（MDM）的替代品。

以下模板把制度压缩成可直接填写的一页：

Approved tools: [list plans + admin owner]
Forbidden on company repos: personal/free tiers, unapproved MCP servers
Data never sent: live secrets, regulated personal data, restricted client material
Blocked actions: secret-file reads, unallowlisted egress, unallowlisted MCP servers
Alerts: P0 to on-call/security lead; coverage gaps to IT/platform; weekly summary to engineering managers
Evidence: sessions, file access reviews, admin audit log, access review campaigns
Review: weekly 30 minutes; quarterly access review and policy refresh

要盯住 Blocked actions 这一行：每个禁止动作都应对应实际配置、实施者和检查方式。写进文档只是起点。

作者建议每周拿出 30 分钟，从 dashboard 和 Signals 列表复查，需要对客户或审计提供材料时再导出 CSV。原文没有进一步列出这 30 分钟的详细议程。

每季度则检查 gateway keys、org API keys 和成员权限，对应决定是 keep、revoke、modify、rotate；同时重读供应商条款中的训练和留存约定。新增 MCP marketplace plugins 或云端 agent 功能，也要更新制度。

证据至少包括会话、文件访问审查、管理审计日志和权限审查活动。产品边界也要看清：Paid/Enterprise 提供项目级文件沿袭，管理审计日志支持 365 天导出；会话内容存放在 US 或 EU，组织选定区域后不能更改。付费会话采用带组织恢复密钥的加密存储，并非零知识存储。作者称 SOC 2 Type II 目标是 2027 年初，原文发布时尚未获证。

我的判断

这套方法最有用的地方，是把「允许使用 AI」拆成工具、数据、动作、告警和证据五项决定。对没有专职安全团队的小公司，这比只在 wiki 写一句「禁止泄密」更容易实施。

但「一页」压缩的是决策入口，底下仍需要配置、例外记录和证据。团队如果连设备上用了哪些 agent 都不清楚，先写完一页制度也无法证明覆盖完整。

文章同时带有明显的产品推广目的。ReclaimLLM 的功能、套餐边界和失败行为由作者自行陈述，没有提供小团队实施前后的事故数量、维护成本，也没有与纯厂商设置方案做对照。因此，「每周 30 分钟就够」应当理解为作者建议的运营节奏，属于经验之谈。

我的取舍是先用原生管理设置落实规则，再根据跨工具管理和审计需求补 hook、网关。原文引用的加拿大 Cyber Centre ITSAP.00.041、OPC 原则和 PIPEDA 讨论可以帮助理解其隐私责任语境，但不能直接回答国内团队的合规问题。它自身也明确限定为运营模型，没有提供法律结论。

能拿来做什么

• 给前端或全栈团队列一张实际使用清单，把 Claude Code、Cursor、Codex、Copilot 的套餐、管理员和适用仓库写清，同时盘点已启用的 MCP server。
• 从真实仓库整理数据规则，分别处理 .env、云密钥、数据库 URL、客户日志和测试数据，并核对目录排除、拒绝规则及脱敏配置是否对应得上。
• 检查 hook 崩溃、超时和后端不可用时的行为，明确采用阻断还是放行；涉及 Claude 和 Cursor 时，核对 onFailure: "block"、failClosed: true 的配置。
• 固定每周 30 分钟查看告警、覆盖缺口和未到期例外，每季度复查密钥与成员权限，将保留、撤销、修改、轮换的决定留下记录。