审查供应商 AI 条款时如何逐项比对治理立场并生成红线

当你需要审查供应商的 AI 协议、附录或服务条款（如训练数据、责任、模型变更、AI 政策一致性）时，用这套流程逐项比对内部治理立场并产出可执行红线。

适用场景

解决思路

1. 读取 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md，确认供应商治理立场已填写；若未填写则停止并引导至 setup。
2. 确认文档类型（AI 附录 / 主协议中的 AI 条款 / ToS）；若只提供了 AUP，则要求提供完整条款。
3. 逐项审查以下条款：训练数据、输入保密性、模型变更、输出 IP、责任、事件通知、人工审查权、使用限制、审计权。
4. 若已有 DPA 但无 AI 附录，执行 AI 附录缺口检查。
5. 将供应商条款与 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中的 AI 政策承诺做一致性差异比对。
6. 输出：底线结论、逐项分析、建议红线、若对方不让步时的路由。
7. 检查实践级 CLAUDE.md 中的 ## Matter workspaces：若 Enabled 为 ✗（内部用户的默认值），跳过 matter 机制；若启用且无活跃 matter，询问属于哪个 matter（运行 /ai-governance-legal:matter-workspace switch <slug> 或说 practice-level），加载活跃 matter 的 matter.md，输出写入 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/，除非 Cross-matter context 为 on，否则绝不读取其他 matter 的文件。
8. 读取 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 的 ## Vendor AI governance 与 ## AI policy commitments。
9. 若 CLAUDE.md 含 [PLACEHOLDER]，提示用户：运行 /ai-governance-legal:cold-start-interview（2 分钟）配置档案，或说 provisional 以通用默认值审查并给所有输出打上 [PROVISIONAL — configure your profile for tailored output] 标签。
10. 若用户说 provisional，按通用默认值（中等风险偏好、律师角色、美国司法辖区、无 playbook）正常运行审查，从第一性原理标记所有常见供应商 AI 风险，并在 reviewer note 和每个 finding block 打上 [PROVISIONAL] 标签，末尾追加提示运行 cold-start-interview 以校准输出。
11. 若用户未分享实际供应商条款，要求提供：AI 附录，或标注了 AI 条款的主协议；说明仅 AUP 无法揭示供应商能对输入做什么。
12. 若仅分享 AUP，说明它只说明我们不能做什么，不涉及商业条款（是否可训练我们的数据、AI 错误责任、模型变更通知），要求提供服务协议或 AI 附录。
13. 对每个核心 AI 条款，提取供应商合同实际措辞，与 CLAUDE.md 中 ## Vendor AI governance 的立场（standard / acceptable fallback / automatic no）比对。
14. 核心条款表：训练我们的数据（是否用于训练/微调/改进，是否有明确 opt-out 或禁止，默认 opt-in 还是 opt-out）；输入保密性（提示、文档、数据是否保密，是否有质量审查或人工审查例外）；模型变更（重大变更通知义务，是否可版本固定）；输出所有权/IP（AI 生成内容归谁，是否回授许可给供应商，是否有 IP 赔偿）；输出责任（AI 产生有害/错误/侵权输出时供应商是否担责，责任上限结构，例外）；事件通知（AI 系统故障、被入侵或系统性错误时如何及何时通知）；人工审查权（能否要求对特定输出人工审查，能否申诉或质疑 AI 决定）；使用限制（禁止我们做什么，是否匹配实际用途，定义性术语如 automated decision-making 是否可能涵盖预期用途）；审计/可审计性（SOC 2、第三方审计、偏见测试结果、审计权）；子处理者/模型提供方（是否使用子供应商，是否披露，适用谁的条款）；数据驻留（数据在哪里处理，推理时去向何处）；期限与终止（终止后数据如何处理，删除时间线）；堆叠供应商问责（该供应商是模型提供方还是他人模型的部署方或基础设施托管基础模型的转售方；若是后者则有两套条款，需识别训练/保留/安全由谁条款管辖、模型行为由谁合同担责、上游承诺是否 flowed down 给我们，标记任一方免责条款及对方合同是否填补缺口，不得孤立审查两份合同）。
15. 若 CLAUDE.md 未定义某条款立场，询问：默认立场、可接受 fallback、automatic no，并加入 CLAUDE.md 以保持后续审查一致。
16. 对每个条款按格式输出：条款名、🟢/🟡/🟠/🔴、Vendor says（合同实际措辞摘要）、Our position（来自 CLAUDE.md）、Gap（具体差异或 Aligned）、Proposed fix（具体红线语言或 escalate — outside fallback）。
17. 严重度评级：🟢 Aligned（达到或优于 playbook 标准立场）；🟡 Note（在 fallback 内但差于标准，提示但不阻塞）；🟠 Significant（超出标准但在 fallback 内，签署前需红线）；🔴 Critical（超出 fallback，未解决不得部署，按 CLAUDE.md 升级）。
18. 若供应商有 DPA 但无 AI 附录：说明 DPA 覆盖数据保护但不涉及训练数据、模型变更通知、AI 输出责任、AI 系统故障事件通知；对 Standard/Elevated/High 层级说明该缺口是否可接受，建议要求 AI 附录或至少在下次续约时谈判 AI 特定条款。
19. 若无任何 AI 条款：说明供应商以通用服务条款提供 AI 服务，对最高风险 AI 治理项（训练、责任、模型变更）无合同保护，对任何 Elevated 或 High 层级用例为 🔴。
20. 将供应商条款与 CLAUDE.md 中 AI 政策承诺交叉核对，标记所有不匹配：政策禁止供应商训练但条款默认允许（合同需明确禁止或确认 opt-out）；政策要求特定用例人工审查但条款称 AI 输出为最终（工作流需强制人工步骤）；批准供应商列表不含该供应商或黑名单含之；政策要求向受影响方披露但条款的保密义务阻止披露。
21. 红线粒度：在尽可能最小的粒度上编辑；默认最小编辑达成 playbook 立场：先替换词再替换短语（如 twelve (12) → twenty-four (24)）；先替换短语再替换句子（如 paid by the Buyer → paid and payable by the Buyer）；先重构子条款再替换句子（加 (a) 和 (b) 拆分复合条件）；先替换句子再替换整条；仅当对方版本与立场差距过大、外科手术式编辑比重新起草更难读时才替换整条，并在传送说明中说明。
22. 在建议签署供应商 AI 协议（公司将执行的版本）前：读取 CLAUDE.md 的 ## Who's using this；若 Role 为 Non-lawyer，提示签署有法律后果，询问是否已与律师审查；若是则继续，若否则生成 1 页摘要（供应商与用例、审查的关键条款、供应商立场与政策分歧处、接受的内容、可能出错之处、要问律师的问题），并提示可通过职业监管机构转介服务找律师（美国州律师协会、英格兰与威尔士 SRA/Bar Standards Board、苏格兰/北爱/爱尔兰/加拿大/澳大利亚 Law Society 或同等机构）；未获明确 yes 不得越过此门；审查/红线草稿供律师考虑不需此门，签署才需要。
23. 输出 markdown 报告，含：WORK-PRODUCT HEADER（按插件配置 ## Outputs，依 ## Who's using this 角色不同）；保密与特权声明（审查源自通常受 NDA 保密的供应商合同条款，可能本身受特权保护，继承来源的保密与特权状态，分发超出特权圈可能放弃特权并违反 NDA）；标题 Vendor AI Review: [Vendor Name]；Document reviewed、Reviewed 日期、Use case(s)、Governance tier；Bottom line（两句话：能否按这些条款部署，先要改什么）与 Issues 计数；Term-by-term；AI addendum status；AI policy consistency；Recommended redlines（合并草稿红线，对外发送前与律师审查，无 fallback 的关键问题标记升级而非提议语言）；If they won't move（对每个 🔴 和 🟠 给出 CLAUDE.md 的 fallback 或 escalate — outside fallback 及升级路由）。
24. 实践要点：训练数据条款是最常被遗漏的，不要凭声誉或过往经验假设任何供应商当前立场，必须从眼前具体协议中读取并以书面确认。
25. 映射 AI 栈：审查条款前先映射各层——终端用户 SaaS 应用、API 网关/编排层（Azure OpenAI Service、AWS Bedrock、Google Vertex、LangChain-hosted）、模型提供方（Anthropic、OpenAI、Google、Meta）、托管知识库/RAG 源（向量数据库、第三方数据语料、检索服务）、其他子处理者（分析、日志、微调伙伴）；询问栈的构成，然后审查每一层的条款而非仅顶层；层与层之间的每次交接都是 flow-down 风险。
26. Flow-down 测试：对每个标记的堆叠供应商条款（尤其训练数据、数据保留、子处理者变更、责任），不要只标记 check upstream terms，要执行检查：搜索合同中的 flow-down 语言（subprocessor obligations no less protective than、flow-down of data commitments、back-to-back terms、Provider shall ensure that its subprocessors are bound by、equivalent obligations）；若存在则引用、核实覆盖具体标记条款、标记可执行性（谁能执行——你，还是仅中间供应商）；若缺失则产出具体红线要求加入（Provider shall ensure that any third-party model providers, infrastructure providers, or subprocessors used in delivering the Services are bound by obligations with respect to [Customer Data / AI training / data retention / confidentiality] no less protective than those set forth in this Agreement, and shall be responsible for any breach of this Agreement caused by such third parties）；按严重度标记缺口：训练数据或责任且无 flow-down 为 🔴，较不敏感或部分 flow-down 为 🟡。
27. AUP 翻转框架：AUP 只说明你不能做什么，不说明供应商能做什么；不要让干净的 AUP 审查替代对数据使用和责任条款的阅读。
28. 续约是杠杆点：若当前协议不利且供应商不愿中期重谈，现在记录缺口并标记续约；向采购标记：本次续约在 AI 附录解决 [list] 前不应关闭。
29. Builder 语境增加一层：若公司是使用供应商模型作为基础的 builder，供应商条款也管辖公司能向自己客户提供什么；某些条款禁止特定下游用途；对照产品路线图而非仅当前内部工作流检查使用限制。
30. 以 CLAUDE.md ## Outputs 的 next-steps decision tree 结束，按本技能产出定制选项；五个默认分支（draft the X、escalate、get more facts、watch and wait、something else）是起点而非锁定；树是输出，律师来选择。
31. 本技能不做：不审查同一协议的 DPA 条款（运行 /privacy-legal:dpa-review）；不决定是否接受 fallback 之外的条款（按 CLAUDE.md 升级表路由）；不评估协议之外的供应商安全态势（属安全团队职能）。

适用边界 · 注意事项

• 仅提供 AUP 而无服务协议或 AI 附录时，无法审查商业条款（训练数据、责任、模型变更通知），应先索取完整条款。
• 用户尚未配置实践档案（CLAUDE.md 含 [PLACEHOLDER]）且未选择 provisional 模式时，不应直接输出定制化审查结果。
• Role 为 Non-lawyer 且未获律师审查明确 yes 时，不得建议签署供应商 AI 协议（审查/红线草稿不受此限）。