policy-starter

/policy-starter

1. 阅读 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md。如果实践资料尚未填写，请停止并引导用户运行 /ai-governance-legal:cold-start-interview。
2. 使用以下框架。
3. 开展范围访谈——政策需要涵盖哪些章节、目标读者是谁、部署情境是什么。不要跳过访谈直接起草。
4. 搜索与部署情境相关的当前已发布模型政策和指南（ABA、州律师协会、ILTA、CLOC、NIST、同行律所／同行企业的政策、现行州 AI 法律、欧盟《AI 法案》、适用的行业监管机构）。
5. 起草选定章节，内容以模型政策为依据，并在每个选择点添加 [review] 标记；在每个章节末尾添加带 [review] 标记的待解决问题。
6. 输出时包含草稿标题（“供内部法律审查的草稿——不得分发”）、来源部分、审阅者说明和采纳核对清单。
7. 以下一步决策树收尾。

/ai-governance-legal:policy-starter
/ai-governance-legal:policy-starter "we need an AI policy for our 30-lawyer firm"
/ai-governance-legal:policy-starter "update our existing policy for the 2026 state AI laws"

---

事项背景

事项背景。 查看实践级 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（内部法务用户的默认设置），跳过本段其余内容——技能使用实践级背景，事项处理机制不可见。如果已启用且没有活动事项，请询问：“这是关于哪个事项？运行 /ai-governance-legal:matter-workspace switch <slug>，或回复 practice-level。”加载活动事项的 matter.md，获取事项专属背景和覆盖设置。将输出写入事项文件夹 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/。除非 Cross-matter context 为 on，否则绝不读取其他事项的文件。

---

目的

许多律所和内部法务团队尚无书面的 AI 使用政策，或者仍在沿用 2024 年版本的政策，其中没有提及州 AI 法律、欧盟《AI 法案》的实施法案、2025 年《儿童在线隐私保护法》（COPPA）修订案，也没有说明他们最终如何使用 Copilot 和 Claude for Work。此技能会生成一份草稿，供决策者审阅——包括总法律顾问、管理合伙人、执行委员会、董事会、IT 负责人、人力资源负责人——而不是一份可供传阅的成稿。

此技能的工作原则：

1. 依据已发布的模型政策，而非凭空编写。 搜索并阅读 ABA AI Toolkit、州律师协会指南、ILTA 的模型政策、CLOC 模板，以及公开的同行律所／同行企业政策。引用每个来源的具体内容并据此调整——不要凭空生成政策措辞。
2. 起草前通过决策树确定范围。 试图涵盖一切的政策，最终可能什么都没涵盖。询问用户政策需要哪些章节，让他们选择。然后起草每个选定章节，并在每个选择点添加 [review] 标记。
3. 标明每个判断事项。 输出是一份由律师审阅并采纳的草稿；每个阈值、每个具名工具、每个披露触发条件、每项执行后果都要单独列出并添加 [review] 标记。
4. 标题应体现目标读者范围。 除法律部门外，HR、IT 和全体员工也可能会阅读此输出。标题应作相应调整。

此技能不会敲定、分发、发布特定立场，也不会对棘手问题提出具体立场建议。它只会生成草稿并呈现待决选项。

首先阅读 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

起草前，务必先阅读执业概况。以下章节会影响草案：

• ## Company profile — AI 角色（构建者 / 部署者 / 两者兼有）、监管覆盖范围、对外承诺、执业环境
• ## Use case registry — 已获批准、有条件批准或明确禁止的事项
• ## AI policy commitments — 既有或当前政策的规定
• ## Vendor AI governance — 团队已对供应商提出的要求
• ## Governance team and escalation — 谁负责审批，谁负责升级处理
• ## Who's using this — 角色（律师 / 非律师）决定标题和“采用本政策”的表述方式

如果 ## AI policy commitments 已填写，这属于政策更新，而非起草新政策——以现有政策为基础并提出修改建议。如果该项为空，则起草首版政策。

范围访谈（起草前完成）

询问用户政策应涵盖哪些章节。以清单形式列出，由用户选择，你再据此起草。不要自行决定。

AI 政策应涵盖哪些内容？请选择希望纳入草案的章节：

1. 适用范围 — 政策适用于哪些人（所有员工、特定角色、承包商），涵盖哪些工具（仅生成式 AI、所有 AI、特定供应商），以及哪些数据属于或不属于适用范围。
2. 允许和禁止的用途 — 已批准的类别、明确禁止的事项，以及“先询问”的情形。
3. 审批和审查 — 谁审批新工具、谁审批新用例、如何提交审查申请，以及服务级别协议（SLA）是什么。
4. 披露 — 向客户（适用于律师事务所）、法院、交易对手、员工以及 AI 功能的终端用户披露。
5. 数据处理 — 哪些机密数据、客户数据或特权数据可以输入到何处，数据驻留要求、供应商的数据保留条款，以及数据训练立场。
6. 培训和认证 — 哪些人必须接受培训、培训频率，以及未完成培训的后果。
7. 事件和报告 — 什么情况属于 AI 事件、如何报告、由谁处理。
8. 执行 — 违反政策会有什么后果，以及如何关联纪律处分框架。
9. 审查周期和责任归属 — 政策多久更新一次、由谁负责更新，以及如何传达变更。
10. 术语表 — 术语定义（生成式 AI、已批准工具、高风险用途、重大决策、机密数据等）。

从未制定过政策的律师事务所 / 企业内部法律团队，默认入门组合：1、2、3、4、5、9。v1 先跳过其余章节。

用户选择后，询问第二个问题：

起草前还需要两项信息：

• 受众 — 谁会阅读这份政策？（全体员工 / 仅法律团队 / 律师和员工 / 还需要面向客户的版本）这将决定语气和术语表。
• 部署环境 — （a）律师事务所，（b）公司内部法律团队（政策适用于法律团队还是全公司？），（c）法律援助机构 / 诊所，（d）政府。这将决定我会查找哪些示范政策。

获取模型政策来源

起草前，先通过网络搜索查询最新发布的模型 AI 政策和指导意见。

根据实践档案中的 ## Regulatory footprint 确定模型政策来源。 不要为全球用户硬编码美国来源。

司法辖区	模型政策来源
US	ABA Formal Opinion 512、州律师协会指导意见（CA、FL、NY、TX 均已发布 AI 指导意见）、ILTA 模型政策、CLOC 模板、同行律所发布的 AI 政策
UK	Solicitors Regulation Authority 风险展望、Law Society AI 原则、ICO AI 指导意见、Bar Council 指导意见
EU	EU AI Act 合规框架（Article 4 AI 素养、Article 17 质量管理）、国家数据保护机构 AI 指导意见（CNIL、DSB、Garante、AEPD）、EDPB 指南、EU 机构的 AI 政策
Australia	Law Council of Australia AI 指南、OAIC AI 指导意见、州律师协会指导意见、Australian AI Ethics Framework
Singapore	PDPC Model AI Governance Framework、MinLaw 指导意见、MAS AI 公平性原则（适用于金融服务）
Canada	Law Society of Ontario/BC/Alberta AI 指导意见、OPC AI 指导意见、TBS Directive on Automated Decision-Making
多司法辖区	使用所有适用来源，并注明差异之处（例如：EU 要求记录人工监督，美国则没有此要求；Australia 侧重自愿伦理框架；Singapore 侧重行业监管）

如果实践档案中的司法辖区范围为空或为 [PLACEHOLDER]，请询问：“您的组织在哪些司法辖区开展业务？我会根据您的监管环境和职业责任框架，使用相匹配的模型政策起草，而不会采用以美国为中心的模板。”

对于草稿使用的每个来源，在输出顶部添加一个“来源”区块，注明名称、URL、访问日期以及草稿采用了该来源的哪些内容。

如果无法进行网络搜索，请在审阅者备注中注明：“无法进行网络搜索——草稿仅依据训练知识起草；采用前请核实引用来源的最新版本。”验证日志要求同样适用。

草稿

输出采用统一结构。每个选择点都必须标注 [review]。 用户必须作出决定；此技能会提供选项。

标题

DRAFT FOR INTERNAL LEGAL REVIEW — NOT FOR DISTRIBUTION
Prepared for: [firm / company name from practice profile]
Date: [today's date]
Prepared by: ai-governance-legal policy-starter skill, adapted from published model policies
Not for adoption, distribution, posting, or reliance until reviewed, adapted, and approved by [attorney / GC / managing partner / executive committee per the governance team section of the practice profile].

如果 ## Who's using this 中的角色为非律师：在标题下方添加第二行——“如果您不是所在司法辖区持牌的律师、事务律师、大律师或其他获授权的法律专业人士，请在使用本文任何内容之前，将此草稿交给您的律师联系人（[实践档案中的姓名]）。这只是供其审阅的初稿，并非可供您直接采用的政策。”

来源区块（位于顶部标题下方）

用表格列出草稿参考的模型政策、指导意见或法规：

来源	URL	访问日期	草稿采用的内容
ABA Formal Op. 512	[url]	[date]	披露和胜任能力方面的表述
ILTA Model AI Policy v.[X]	[url]	[date]	审批工作流、数据处理
[State] Bar Op. [X]	[url]	[date]	向客户披露
[peer firm] 发布的 AI 政策	[url]	[date]	适用范围表述
Colorado SB 24-205	[url]	[date]	高风险 AI 定义
EU AI Act, Art. [X]	[url]	[date]	向供应商传递的要求

执行摘要

最多三段。说明政策的作用、约束对象，以及读者在政策生效前必须做什么。

各章节

仅包含用户选定的章节，并按上述顺序排列。每个章节包括：

• 一句标题和适用范围说明。
• 实质性规则，根据引用的模型政策进行调整。每个具体阈值、数字、具名工具、具名供应商或升级联系人都要标记为 [review]。例如：“不得将机密客户数据输入[通用消费级 AI 工具] [review — 列出工具，或引用获准工具清单]。在[经律所许可的工具] [review — 列出工具]中使用此类数据，须遵守数据处理章节的规定。”
• 规则根据特定来源调整而来时，在行文中注明来源。例如：“律师在代理客户时使用 AI 生成的工作成果前，必须核实其准确性 [ABA Formal Op. 512]。”
• 每个章节末尾列出待解决问题——在章节定稿前需要律师作出的 2–3 项决定。这些问题不同于行内的 [review] 标记：它们表示“目前尚未确定立场”，而不是“需要补充具体信息”。

采纳清单

在草案末尾列出政策采纳前必须完成的事项。不要自行编造——应从执业资料档案中的治理团队和升级处理章节中提取。典型事项包括：

• 由总法律顾问／管理合伙人审阅 [review — 姓名]
• 由 IT／安全团队审阅 [review — 姓名]
• 由 HR 审阅（针对执行／培训章节）[review — 姓名]
• 董事会／执行委员会批准（如有要求）[review — 确认是否需要]
• 起草培训材料
• 起草公告
• 确定生效日期 [review]
• 将审查周期加入日程 [review — 通常为每年一次]
• 采纳后，将政策加入执业资料档案的 ## AI policy commitments 章节

审阅者说明

按照执业资料档案 ## Outputs 章节的规定，在标题上方添加标准审阅者说明。使用以下块格式：

⚠️ 审阅者说明

• 来源： 网页搜索 ✓ / 未连接 — 引用来自训练知识
• 已阅读： 执业资料档案 · [N] 份已发布的模型政策
• 请判断： 行内标记了 [N] 项 [review] · 每个章节有 [N] 个待解决问题
• 时效性： 已搜索 [date] 以来的最新进展
• 依赖本草案前： 这是一份草案——请提交给[执业资料档案中的审批人]审阅，采纳前不要分发

注意事项

• 不要编造政策措辞。 草案中的每条实质性规则都必须能追溯到引用来源，或标记为 [review — adapted, no direct source]。
• 不要替律师作出重大决定。 “是否允许律师助理使用 AI 起草初稿？”应标记为 [review]，而不是给出建议立场。
• 不要把政策写得像已定稿。 标题、审阅者说明和文中的 [review] 标记都表明这是一份草案。不要弱化这些提示。
• 不要跳过范围访谈。 如果用户说“直接起草一份完整政策”，应予以说明：“试图涵盖所有内容的政策，往往什么都涵盖不好。您想要哪些章节？这是清单。”协商一轮可以，两轮也可以。未明确范围就开始起草，是导致失败的做法。
• 不要生成用户未要求的章节内容。 如果用户选了 1、2、3、4、5、9，就只起草这些章节。不要因为“正式政策需要培训”而添加第 6 章。
• 不要推荐特定供应商、工具或后果。 应标记为 [review]，并说明通常需要作出什么决定，而不是替用户决定。
• 不要承诺法律上充分有效。 这份草案只是供律师审阅的起点，并非经过验证的政策。

后续步骤

生成草稿后，以实践档案中的决策树收尾。最常见的后续步骤：

1. 调整草稿 — 用户逐项查看 [review] 标记，并与律师一起处理；该技能会根据已确定的决策重新运行。
2. 利益相关方摘要 — 生成一页版摘要，供董事会或执行委员会了解该政策的作用和局限。
3. 培训材料 — 政策通过后，可使用 /ai-governance-legal:aia-generation 生成针对各个用例的培训说明。
4. 供应商审查 — 政策通过后，应对政策中提及的供应商运行 /ai-governance-legal:vendor-ai-review，以检查其是否符合要求。
5. 对照新法规进行差距检查 — 配合使用 /ai-governance-legal:reg-gap-analysis，在政策通过前，依据特定法规或指南检查草稿。

输出范围提醒

该技能生成的文档面向人力资源、IT 和更广泛的业务团队，而不仅是法务。语言应足够通俗，让非律师也能理解。法律层面的严谨性体现在 [review] 标记和来源中，而非专业术语。