aia-generation

/aia-generation

1. 阅读 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md。确认已填写影响评估的格式规范。
2. 根据治理等级和用例特征，使用下方框架确定风险路径（快速或完整）。
3. 开展访谈——以对话方式进行，而非填写表单。
4. 对适用范围内的每项法规进行监管分类——研究级别、禁止实践风险和适用义务；引用一手资料。
5. 按照团队格式撰写评估（采用种子文档中的格式；如未记录，则使用默认格式）。
6. 对照 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中的 AI 政策承诺进行政策差异分析。
7. 输出：评估文档 + 条件清单 + 交接标记（如有需要，进行隐私 PIA、供应商审查）。

/ai-governance-legal:aia-generation "AI résumé screening for HR"

---

事项背景

事项背景。 检查实践级 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 影响评估是一项有文档记录的决策，而非一份表单。它要回答：这个 AI 系统做什么、如何生成输出、如果出错会影响谁、如何进行监督，以及是否可以部署。这项技能会引导这场对话，并按照团队的格式编写输出——该格式是在冷启动期间从种子影响评估中学习得来的。

AI 影响评估与 PIA 并不相同。PIA 关注个人数据的处理是否合法。AIA 关注 AI 系统的设计和部署是否负责任。两者通常需要并行开展，但不能相互替代。

加载格式规范

阅读 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## Impact assessment house style。其中包括：

• 本公司触发影响评估的条件
• 从种子评估中提取的结构模板
• 通常的详细程度
• 审批人

如果 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中包含种子结构，请使用该结构。重点是让本次评估的格式与团队制作的其他评估保持一致。

司法辖区范围。 本评估适用 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中 ## Regulatory footprint 列出的监管制度。各司法辖区的 AI 法律规则、风险分类和部署义务存在重大差异，且变化迅速。如果该系统已在此范围之外部署（或将部署），或者涉及法律选择问题，本分析可能不适用于实际情况——请重新分析或扩大适用范围。

---

步骤 0：是否需要影响评估？

检查 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中的触发条件。

另请一并检查以下各项：

• 此 AI 是否会作出或实质性影响会影响个人的决定（就业、 信贷、访问权限、定价、内容审核）？
• 此 AI 是否会处理有关个人的个人数据？
• 这是面向客户的 AI 系统，而非纯内部系统吗？
• 此 AI 是否使用第三方模型，且公司是部署者？
• 根据 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md，该用例是否属于较高或高治理等级？

如果以上均不符合，且未达到团队的触发条件：

“看起来不需要进行完整的影响评估。下面是一段供存档的简要说明，解释原因——以备日后有人询问。”

---

步骤 1：风险路径

在 intake 前，确定要运行哪条路径。层级定义和快速通道标准来自 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md（## Use case registry 和 ## Governance tiers），而不是任何硬编码的特定监管体系框架。

针对用户监管范围内的每项监管制度，研究适用的风险分类框架。许多监管制度会根据风险等级、受影响人群和决策的重要程度进行区分——请研究具体标准。请注意，大多数监管制度都将员工数据视为个人数据，并将员工监控视为具有重大影响；不要假设仅供内部使用的系统不在适用范围内。

不得默默补充。 如果针对某项制度的风险等级或触发条件，向已配置的法律研究工具（Westlaw、EUR-Lex、监管机构网站或律所平台）发起研究查询后，返回的结果很少或没有结果，请报告已找到的内容，然后停止。未经询问，切勿通过网络搜索或模型知识来填补空缺。请这样说：“从 [tool] 返回了 [N] 条结果。[regime / topic] 的资料覆盖似乎不足。可选方案：(1) 扩大搜索查询范围，(2) 尝试其他研究工具，(3) 搜索网络——结果将标记为 [web search — verify]，依赖这些结果之前应先对照发布机构核实，或 (4) 标记为未经核实并停止。您希望怎么做？”律师决定是否接受可信度较低的来源。

来源归属分级。 为 AIA 中每条引用标注其来源，包括监管文本、授权法案、指导意见和标准。对于来自模型知识的引用，请使用以下三个等级之一，而不是统一标记为“需核实”：

• [settled] — 稳定且广为人知、不太可能发生变化的法定及监管参考资料（例如，GDPR 第 22 条这一概念，以及 Regulation (EU) 2024/1689（即 EU AI Act）的存在）。在出具认证前仍需核实，但优先级较低。
• [verify] — 确实存在但应予核实的模型知识引用：具体的授权法案／实施法案、监管机构指导意见、NYC DCWP 规则、Colorado AI Act 条款、协调标准、生效日期、EEOC 指导意见，以及任何 2023 年之后的内容。
• [verify-pinpoint] — 精确定位引用（具体的 EU AI Act 条款编号、附件引用、Colorado AI Act 分款、NYC LL 144 规则条款、子段落字母编号）具有最高的编造风险，必须始终对照一手来源核实。尤其是 EU AI Act 的条款编号在汇编过程中有所调整；对该法案的每一处精确定位引用，都应对照《欧盟官方公报》文本核实。

通过工具检索到的引用保留其来源标签（[Westlaw]、[EUR-Lex]、[regulator site] 或 MCP 工具名称）；网络搜索引用仍标记为 [web search — verify]；用户提供的引用仍标记为 [user provided]。分级标注能揭示真正需要核实的内容——读者如果核实所有内容，就等于什么也没核实。绝不要删除或合并这些标签。

对于非律师用户，不确定的日期应列入确认清单，不要放在正文中。 对于不了解 [verify] 含义的 CISO 来说，在“2026 年 2 月 1 日生效”后标注 [verify]，读起来仍像是在说“2026 年 2 月 1 日生效”。请阅读 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中的 ## Who's using this。如果 Role 是 Non-lawyer，且某个日期、截止日期、分阶段实施安排、门槛或生效日期的说法并不确定（如果放在正文中就应标记为 [verify] 或 [verify-pinpoint]），请将正文中的说法替换为“生效日期：请向法律顾问确认”（或“门槛：请向法律顾问确认”等），并在 AIA 的最后一节集中列出所有不确定的说法，标题为：

我不确定的事项——依赖这些内容前，请咨询您的律师予以确认：

在该部分逐项列出不确定事项，并说明：(1) 我说了什么，(2) 哪一点不确定，(3) 这为什么会影响评估。这样可以避免非律师读者把带有标记的最佳猜测误当成已核实的事实。律师角色的用户应在正文中使用 [verify] 标记——他们知道该标记的含义。

快速评估与完整评估： ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 定义了哪些情况符合简化处理的条件。如果 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 未定义快速评估标准，则默认进行完整评估，并询问用户希望下次记录哪些标准。

如有疑问，请进行完整评估。快速评估若最终证明有误，后果比对低风险事项进行全面评估更糟。

---

第 2 步：信息收集

动笔前，先获取以下问题的答案。可以采用对话方式——这不是要发给他们填写的表格。

系统

• AI 会做什么？用通俗的语言描述，不要写成营销文案。
• 它由哪个模型或供应商提供支持？是微调模型还是现成模型？
• 它在工作流中处于什么位置——是辅助型（由人审核输出）、增强型（人可以覆盖，但通常不会），还是自动化型（没有人在环路中）？
• 输出是什么——生成的文本、分数、分类、建议，还是操作？

受影响的人群

• AI 的输出会作用于谁——员工、客户还是第三方？
• 如果 AI 出错（误报、漏报、幻觉），谁会受到伤害？最坏但现实的情况是什么？
• 是否有弱势群体受到不成比例的影响——未成年人、求职者、陷入财务困境的人、患者？

输入和数据

• AI 会接收什么数据？
• 它会接收个人数据吗？是谁的个人数据？
• 模型是否使用了这家公司的数据进行训练，还是使用了未经公司特定训练的基础模型？
• 输入数据会流向哪里——会离开公司的安全边界，发送给第三方模型 API 吗？

决策和监督

• AI 的输出会自动触发操作，还是由人决定如何处理输出？
• 如果有人审核：审核者实际上会在多大比例的情况下修改 AI 的输出？（如果答案是“很少”，那这个人实际上并没有审核，只是在走过场。）
• 是否有针对受 AI 输出影响者的申诉或更正流程？
• 谁对 AI 系统的输出负责——是否有明确指定的负责人？

准确性和故障

• 已知或估计的错误率是多少？做过哪些测试？
• AI 出错时会怎样——错误会被发现、记录和纠正吗？
• 是否做过偏见测试？针对哪些人口群体？

部署阶段和规模

请询问：

• 阶段：“该系统目前是 (a) 已提出但尚未构建，(b) 试点中，(c) 已投入生产，还是 (d) 已投入生产并扩大规模？”
• 规模：“大约有多少人受到影响（按 [月/年] 计算）？系统已运行多久？”
• 历史：“以前评估过该系统吗？它是否作出过受到质疑、申诉或撤销的决定？”

阶段会影响评估：对于拟议中的系统，要进行设计审查（能否安全地构建？）。试点系统要进行设计审查，并设置“扩大规模前”的关卡。已投入使用的系统要进行回顾性影响检查（是否造成过伤害？）并进行后续审查。已投入使用且已扩大规模的系统除了上述审查外，还要制定补救计划（如发现问题），因为不能直接将其关闭。

---

第 3 步：监管分类

第 3 步预检查——监管范围是否仍然最新。 在遍历已记录的 ## Regulatory footprint 前，请将用例涉及的受影响人群和决策类型（来自第 2 步）与当前记录的监管范围进行比较。该监管范围是在冷启动时，根据公司当时的运营情况确定的。如果用例涉及监管范围未涵盖的受影响人群（例如儿童、新州的员工、欧盟数据主体）或决策类型（例如招聘、信用风险评估、健康诊断、执法、关键基础设施），请重新推导适用的监管制度，不要继续使用过时的列表。

请对用户说：

“实践档案中的监管范围是根据 [冷启动时记录的受影响人群／决策类型] 确定的。此用例会影响 [新的人群或决策类型——例如，科罗拉多州的员工、13 岁以下未成年人、信用决策、生物识别]，而当前记录的监管范围并未涵盖这些情况。我将根据公司的运营司法辖区（[## Company profile 中的列表]）和此用例的决策类型（[Y]），重新推导适用的监管制度，而不是使用过时的监管范围。如果此用例能代表你预计会遇到的更多工作，请在本次运行结束时更新 ## Regulatory footprint，这样下一个 AIA 就不必重新推导。” 一种常见的失败模式：监管范围列出了 EU AI Act + GDPR + NYC Local Law 144，而用例是将招聘系统部署到伊利诺伊州和科罗拉多州。监管范围中没有伊利诺伊州或科罗拉多州条目，因此遍历该范围时会悄然漏掉 IL AIVIA、新颁布的 Colorado AI Act 部署者义务，以及任何生物识别组件涉及的 BIPA 影响。请重新推导监管范围。

第二种失败模式：设定监管范围时，某项如今已相关的法规尚不存在（或尚未生效）。如果重新推导后发现监管范围中未列出的法规，请在输出的建议部分标出，引用法律依据，并建议更新监管范围。

对于 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## Regulatory footprint 中适用于该系统的每项法规——以及上述重新推导后发现的任何法规——请研究目前有效的风险分类框架，并确定该系统属于哪一类。

研究任务：

• 该法规自身的分级分类体系是什么（例如：禁止／高风险／有限风险／极低风险，或该法规的同等分类）？
• 每个等级的判定标准是什么？请引用主要来源并注明具体条款。
• 根据系统的功能、受影响方和决策后果，该系统属于哪个等级？
• 系统是否可能涉及任何被禁止的行为？将任何可能符合条件的情况视为严重问题，并立即标出。
• 是否有适用于所有等级的透明度义务（例如，披露用户正在与 AI 交互、标注 AI 生成内容、向受自动化决策影响的人发出通知）？
• 如果公司是通用模型或基础模型的构建方，适用哪些提供方义务（技术文档、训练数据透明度、版权合规、系统性风险测试）？
• 监管范围中的任何法规是否要求单独进行基本权利影响评估（FRIA）？ EU AI Act 第 27 条要求某些高风险 AI 系统部署者（公共机构和提供公共服务的私营实体，以及某些信用评估和保险风险评估用途）进行 FRIA。请检查每项法规是否有同等的基本权利或人权影响评估要求，且该评估需作为独立交付成果，而非本 AIA 的组成部分。如果要求进行 FRIA（或法规规定的同等评估），请在建议和条件中将其标为单独的交付成果——不得将本 AIA 视为替代品。

不要假设仅限内部使用的系统不在适用范围内——大多数法规将员工数据视为个人数据，并将员工监控视为可能造成重大影响的行为。请核实具体规定。

提供方与部署者的职责划分（AI role: Both 时）。 如果 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → ## Company profile → AI role 为 Both（公司既是提供方／构建方，也是部署者），第 6 节必须按法规提供提供方与部署者职责对照表。大多数法规对提供方（或构建方）与部署者（或使用者）规定了实质不同的义务——将其合并为一份不加区分的清单会遗漏义务并混淆风险。不得将提供方义务和部署者义务合并到同一部分。每项法规均需提供：

义务	作为提供方	作为部署者
[具体义务及具体条款引用]	[适用／不适用／适用时的例外]	[适用／不适用／适用时的例外]

如果适用高风险或同等分类： 请在评估中标出，并引用具体条款和法规。说明本 AIA 记录的是内部审查，但不能替代法规要求的任何正式合格评定。建议在受影响司法辖区部署前进行外部法律审查。

在评估输出中记录分类及其引用的法律依据。

第 4 步：撰写评估

使用 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中的种子结构。 如果没有捕获到种子结构，则使用以下默认结构：

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

# AI Impact Assessment: [System/Feature Name]

**Prepared by:** [name] | **Date:** [date] | **Status:** DRAFT / APPROVED
**System owner:** [name] | **AI governance reviewer:** [name]
**Governance tier:** [Standard / Elevated / High]
**Track:** [Fast track / Full assessment]

---

## Executive summary

[Two sentences: what this AI does and whether it's okay to deploy. E.g., "This
system uses a third-party LLM to draft initial responses to customer support tickets
before human agent review. Processing is consistent with the company's AI policy;
three conditions required before production deployment."]

**Overall risk:** 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high

---

## 1. System description

**What it does:** [plain English — not marketing]
**Model / vendor:** [who's providing the AI]
**Deployment mode:** [Assistive / Augmentative / Automated]
**Output type:** [text / score / classification / recommendation / action]
**Status:** [Not started / Pilot / Production]

---

## 2. Affected parties

**Who it acts on:** [employees / customers / third parties]
**Scale:** [how many people, how often]
**Harm if wrong:** [most realistic worst case — specific, not generic]
**Vulnerable groups in scope:** [yes — [who] / no]

---

## 3. Data inputs

**Data categories used:** [specific fields, not "user data"]
**Personal data:** [yes — [whose] / no]
**Data leaves perimeter?** [yes — to [vendor] / no]
**Model training:** [company data used / foundation model / fine-tuned on [dataset]]

---

## 4. Decision-making and oversight

**Human in the loop:** [Always / Nominally (rubber-stamp risk) / No]
**Override mechanism:** [how a human can intervene or correct]
**Appeals / correction for affected parties:** [yes — [how] / no]
**Named owner:** [name or role]

---

## 5. Accuracy and bias

**Error rate:** [known / estimated / untested]
**Failure mode:** [what happens when it's wrong — surfaced? logged? corrected?]
**Bias testing:** [done — [results] / not done / not applicable]

---

## 6. Regulatory classification

*[One subsection per regime in the regulatory footprint that applies to this system.]*

**Regime:** [name]
**Classification under this regime:** [tier, with pinpoint citation to the controlling provision]
**Prohibited practices triggered:** [none identified / [specific provision and why]]
**Applicable obligations:** [researched list with citations — transparency, documentation, human oversight, testing, registration, etc.]
**Fundamental-rights impact assessment required?** [Yes — e.g., EU AI Act Art. 27 FRIA applies / regime equivalent / No / Not applicable. If yes, this is a separate deliverable, not subsumed by this AIA.]
**Effective / enforcement date:** [date(s)]
**Ambiguity or open interpretation:** [flag anything not yet settled]

**Provider-vs-deployer obligation split (required if `AI role: Both`):**

| Obligation | As provider | As deployer |
|---|---|---|
| [specific obligation + pinpoint cite] | [what applies / does not apply] | [what applies / does not apply] |

---

## 7. AI policy consistency

| Policy commitment | Consistent? | Notes |
|---|---|---|
| [commitment from `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` AI policy section] | 🟢 / 🟡 / 🟠 / 🔴 | |

[If any item is 🟡 or worse: policy update needed before deployment, or design needs to change.
One of them has to change — not both flagged and left open.]

---

## 8. Risks and mitigations

| # | Risk | Likelihood | Impact | Mitigation | Status | Owner |
|---|---|---|---|---|---|---|
| 1 | [specific risk tied to this design — not "AI hallucination" generically] | L/M/H | L/M/H | [specific control] | Done / Planned / Gap | [name] |

**Residual risk after mitigations:** [assessment]

---

## 9. Recommendation

**[APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED]**

**Conditions (if any):**
- [ ] [specific action before deployment — owner, deadline]

**Privacy review required?** [Yes — run `/privacy-legal:pia-generation`, if the plugin is installed /
No]

**Sign-off:** [name, date]

---

## Cite check

Regulatory citations in Section 6 (and anywhere else) were generated by an AI model and have not been verified against primary sources. Before the assessment is certified or relied on, run a verification pass against a legal research tool (Westlaw, EUR-Lex, or your firm's platform) for each cited provision — confirm the pinpoint, currency, and any delegated or implementing acts. The AI regulatory landscape shifts quickly; verify before advising. Source tags on each citation (e.g., `[EUR-Lex]`, `[web search — verify]`) show where it came from; `verify` tags carry higher fabrication risk and should be checked first.

在认证 AIA 之前（即签署步骤，将 Status 标记为 APPROVED）： 阅读 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中的 ## Who's using this。如果 Role 为 Non-lawyer：

认证这份 AIA 会产生法律后果——如果监管机构或受影响方询问如何评估此用例，它将成为公司所依据的记录。你是否已与律师审阅过？如果是，请继续。如果否，以下是供你带给律师的简要材料：

[生成 1 页摘要：系统、监管分类、已识别的风险、现有缓解措施、剩余风险、待解问题，以及认证前应向律师咨询的事项。]

如果你需要寻找律师、事务律师、大律师或其他获授权的法律专业人士：联系你所在专业监管机构的转介服务是最快的起点（美国的州律师协会、英格兰和威尔士的 SRA/Bar Standards Board、苏格兰／北爱尔兰／爱尔兰／加拿大／澳大利亚的 Law Society，或你所在司法管辖区的同类机构）。

未经明确肯定答复，不得通过此关口。供律师审阅的 DRAFT 评估不需要通过此关口——认证才需要。

---

风险质量标准

标准与 PIA 技能相同——风险必须具体且与设计相关。

不佳的风险	原因	更好的写法
“AI 幻觉”	适用于所有 LLM；没有提供具体信息	“模型可能生成貌似可信但错误的法律引文——客服人员在向客户发送内容前没有当前的核实步骤”
“偏见”	过于笼统	“简历评分模型使用历史招聘数据训练；如果历史样本在人口统计特征上较为单一，代表性不足的候选人可能会被系统性地打出较低分数”
“供应商风险”	循环论证	“OpenAI 的条款默认允许使用 API 输入进行训练；如果协议中未确认已选择退出，客户支持消息可能会被用于训练模型”

应列出 2-5 项真实风险，而不是凑出 12 项。

---

AI 政策差异

每项评估都应与 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md 中的 AI 政策承诺进行交叉核对。 常见偏差：

• 政策禁止在 [类别] 中使用 AI——此用例属于该类别。停止。
• 政策要求人工审核——此部署没有人工审核环节。需要更改设计。
• 政策要求向受影响方披露——尚未建立披露机制。
• 存在已批准的供应商名单——此供应商不在名单中。需要进行采购流程。

标明每一处不匹配。部署前必须解决其中至少一项。

---

交接事项

• 交给产品／工程团队： 列出条件及负责人和截止日期。不要写“增加监督”，而要写“在发送任何自动邮件前增加人工审核步骤，负责人：[产品负责人]，须在上线前完成。”
• 交给隐私团队： 如果涉及个人数据，请标明：“如果已安装该插件，请并行运行 /privacy-legal:pia-generation [system name]——AIA 不能替代 PIA。”
• 交给 vendor-ai-review： 如果涉及新供应商，请标明：“如果尚未审阅针对 [vendor] 的 AI 附录，请在投入生产前运行 /ai-governance-legal:vendor-ai-review。”
• 交给 reg-gap-analysis： 如果出现新的监管义务（如 EU AI Act 高风险分类、新的行业规则），该技能会跟踪相关差距。

---

以“下一步”决策树收尾

按照 CLAUDE.md ## Outputs 的要求，以“下一步”决策树收尾。根据此技能刚刚生成的内容定制选项——五个默认分支（起草 X、升级处理、获取更多事实、观察等待、其他事项）只是起点，不是固定选项。决策树就是输出；由律师选择。

此技能不会做什么

• 它不会批准部署。评估结果须由人工签署。
• 它不构成任何监管合规评估——如果某项法规（例如《欧盟人工智能法案》）要求进行正式合规评估，那就需要单独开展，并接受外部法律审查，同时准备本文未涵盖的技术文档。
• 它不会设计缓解措施。它会说明哪些问题需要缓解；具体修复方案由工程团队设计。
• 如果涉及个人数据，它不能替代 PIA。请同时进行两者。