需要生成 AI 影响评估（AIA）时：完成分诊、风险分级…

适用于用户要求评估 AI 用例或系统、生成 AIA、记录 AI 系统或处理条件式分诊结果，并按内部房风格产出评估文档、条件清单与交接标记。

适用场景

解决思路

1. 调用命令：`/ai-governance-legal:aia-generation "AI résumé screening for HR"`；argument-hint 为 `[describe the use case or system, or pass a triage result]`。
2. 读取 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`，确认 `## Impact assessment house style` 已填充；若已有 seed structure，则后续评估必须使用该结构，使 AIA 与团队既有评估格式一致；若未捕获，使用默认结构。
3. 应用 `## Regulatory footprint` 中的 regime；AI 法律规则、风险分类、部署义务因 jurisdiction 而重大不同且变化快；若系统部署在 footprint 外或存在 choice-of-law 问题，本分析可能不适用，需重新运行或扩展 footprint。
4. 处理 matter context：检查 practice-level CLAUDE.md 中的 `## Matter workspaces`；若 `Enabled` 为 `✗`，跳过 matter 机制，使用 practice-level context；若启用且无 active matter，询问 “Which matter is this for? Run `/ai-governance-legal:matter-workspace switch <slug>` or say `practice-level`.”；加载 active matter 的 `matter.md` 获取 matter-specific context 和 overrides；将输出写入 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/`；除非 `Cross-matter context` 为 `on`，否则不读取其他 matter 的文件。
5. 判断是否需要影响评估：检查 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` 中的 trigger criteria；同时无论是否命中都检查：该 AI 是否作出或实质影响影响个人的决定（employment、credit、access、pricing、content moderation）；是否处理个人数据；是否面向客户而非纯内部；是否使用第三方模型且公司是 deployer；是否属于 elevated 或 high governance tier。若以上都不满足且 house trigger 未命中，输出一段记录说明为何无需完整影响评估，存入档案。
6. 决定风险轨道（fast 或 full）：根据 governance tier 和用例特征；tier 定义和 fast-track 标准来自 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` 的 `## Use case registry` 和 `## Governance tiers`，不要从任何硬编码的 regime-specific framework 取；研究用户 regulatory footprint 中每个 regime 的适用风险分类框架；注意多数 regime 将 employee data 视为 personal data、employee monitoring 视为 consequential，不要假设 internal-only 系统 out of scope。若 CLAUDE.md 未定义 fast-track criteria，默认 full assessment，并询问用户希望下次捕获什么标准；如有疑问，运行 full assessment。
7. 执行 intake，采用对话而非表单：询问系统——AI 做什么，用平实语言不用营销文案；模型或 vendor 是谁，fine-tuned 还是 off-the-shelf；它在工作流中是 assistive（人审输出）、augmentative（人可 override 但通常不 override）还是 automated（无 human in the loop）；输出是 generated text、score、classification、recommendation 还是 action。询问受影响方——AI 输出作用于谁（employees、customers、third parties）；若 AI 出错（false positive、false negative、hallucination），谁承担损害，最现实的最坏情况是什么；是否弱势群体不成比例地 in scope（minors、job applicants、people in financial distress、patients）。询问输入和数据——AI 接收什么数据；是否接收个人数据，谁的个人数据；模型是否用公司数据训练，还是 foundation model 无公司特定训练；输入数据去哪里，是否离开 perimeter 到第三方模型 API。询问决策与监督——AI 输出是否自动触发 action，还是人决定如何处理输出；若有人审，人多常实际改变 AI 输出（若回答是 “rarely”，人不是真正 reviewing 而是 rubber-stamping）；受影响的人是否有 appeals 或 correction 流程；谁对 AI 系统输出 accountable，是否有 named owner。询问准确性与失败——已知或估计 error rate；做过什么 testing；AI 出错时会发生什么，错误是否 surfaced、logged、corrected；是否做过 bias testing，针对哪些 demographic groups。询问部署阶段与规模——Stage：“Is this system (a) proposed and not yet built, (b) in pilot, (c) live in production, or (d) live and scaled?”；Scale：“Roughly how many individuals are affected per [month/year]? How long has it been running?”；History：“Has it been assessed before? Has it produced decisions that were challenged, appealed, or reversed?”；按 stage 调整评估：proposed 做 design review（can we build it safely?）；pilot 做 design review 加 before you scale gate；live 做 retrospective impact check（has it caused harm?）加 go-forward review；live-and-scaled 做上述全部，发现问题时加 remediation plan，因为不能直接关掉。
8. 监管分类前执行 footprint freshness 预检：在遍历 `## Regulatory footprint` 前，将 Step 2 得到的 affected population 和 decision type 与书面 footprint 对比；若用例引入 footprint 未涵盖的 affected population（如 children、employees in a new state、EU data subjects）或 decision type（如 hiring、creditworthiness、health diagnosis、law enforcement、critical infrastructure），重新推导适用 regime，而不是遍历 stale list；向用户说明该 footprint 是为 cold-start 时捕获的人群/决策类型设置的，本用例影响新人群/决策类型，将从 `## Company profile` 中的 operating jurisdictions 和本用例 decision type 重新推导；若本用例代表未来常见工作，建议在本次运行结束时更新 `## Regulatory footprint`。常见失败模式：footprint 列 EU AI Act + GDPR + NYC Local Law 144，而用例是部署到 Illinois 和 Colorado 的 hiring system，遍历旧 footprint 会漏掉 IL AIVIA、Colorado AI Act deployer obligations、biometric component 的 BIPA。第二失败模式：footprint 设置于某 regime 出现/生效前，若重新推导出现未列 regime，在 output recommendation section 中 flag、引用 authority，并建议更新 footprint。
9. 处理 no silent supplement：若向配置的法律研究工具（Westlaw、EUR-Lex、regulator sites 或 firm platform）查询某 regime 的 risk tiers 或 triggers 返回很少或无结果，报告 found 内容并停止；不要未经询问就用 web search 或 model knowledge 补缺；给出选项：(1) broaden the search query，(2) try a different research tool，(3) search the web——结果标记 `[web search — verify]`，依赖前对照 issuing authority 检查，或 (4) flag as unverified and stop；由 lawyer 决定是否接受较低置信来源。
10. 执行 source attribution tiering：给 AIA 中所有 citation（regulatory text、delegated acts、guidance、standards）打 source tag；对 model-knowledge citations 使用三档而不是单一 verify 标签：`[settled]` 用于稳定、知名、不太可能变化的 statutory/regulatory references（如 GDPR Art. 22 as a concept、Regulation (EU) 2024/1689 as the EU AI Act 的存在），certifying 前仍要 verify 但优先级较低；`[verify]` 用于真实但应验证的 model-knowledge citations：specific delegated/implementing acts、regulator guidance、NYC DCWP rules、Colorado AI Act provisions、harmonized standards、effective dates、EEOC guidance、以及任何 post-2023 内容；`[verify-pinpoint]` 用于 pinpoint citations（specific EU AI Act article numbers、annex references、Colorado AI Act subsections、NYC LL 144 rule sections、sub-paragraph letters），最高 fabrication risk，必须始终对 primary source 验证；EU AI Act article numbers 在 consolidation 期间尤其变动，每个 pinpoint cite 都要核对 Official Journal text。Tool-retrieved citations 保留 source tag（`[Westlaw]`、`[EUR-Lex]`、`[regulator site]` 或 MCP tool name）；web-search citations 保持 `[web search — verify]`；user-supplied citations 保持 `[user provided]`；不要 strip 或 collapse tags。
11. 对非律师用户处理不确定日期：读取 `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`；若 Role 为 Non-lawyer 且 date、deadline、phase-in、threshold 或 effective-date assertion 不确定（inline 会带 `[verify]` 或 `[verify-pinpoint]`），将 inline assertion 替换为 “effective date: confirm with counsel”（或 “threshold: confirm with counsel” 等），并在 AIA 最后新增 section：**Things I'm not certain about — ask your attorney to confirm before relying on this:**；对每个不确定项列出 (1) what I said、(2) what I'm uncertain about、(3) why it matters to the assessment。若 Role 为 Lawyer，则保留 inline `[verify]` 处理，因为律师知道 tag 含义。
12. 对每个适用 regime 做监管分类研究：遍历 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` → `## Regulatory footprint` 中适用于该系统的 regime，加上重新推导发现的 regime；研究当前 operative 的 risk classification framework，并确定系统落在何处。研究任务包括：该 regime 自己的 tier taxonomy（如 prohibited/high-risk/limited/minimal 或等价分类）；每 tier 的 criteria，引用 primary sources with pinpoint references；根据 function、affected parties、decision consequentiality 判断系统所属 tier；是否存在可能触及的 prohibited practices，任何可能匹配都视为 critical 并立即 flag；是否存在无论 tier 都适用的 transparency obligations（disclosure that a user is interacting with AI、labeling of AI-generated content、notice to people subject to automated decisions）；若公司是 builder providing general-purpose 或 foundation model，provider-level obligations 是什么（technical documentation、training data transparency、copyright compliance、systemic-risk testing）；是否有 regime 要求单独的 fundamental-rights impact assessment（FRIA），EU AI Act Art. 27 对某些 high-risk AI deployers（public bodies 和 private entities providing public services，加上某些 creditworthiness 和 insurance-risk-assessment use cases）要求 FRIA，检查每个 regime 是否有等价的 fundamental-rights 或 human-rights impact assessment 是独立 deliverable，若要求，在 recommendation 和 conditions 中 flag 为 separate deliverable，不要视本 AIA 为 substitute。不要假设 internal-only systems out of scope；多数 regime 将 employee data 视为 personal data、employee monitoring 视为 consequential；核实具体规则。
13. 若 `## Company profile` → `AI role` 为 `Both`，执行 provider-vs-deployer split：Section 6 必须包含每个 regime 的 provider-vs-deployer mapping table；不要将 provider 和 deployer obligations 合并成一个未分化列表；按 regime 生成表格，列为 Obligation | As provider | As deployer，每行填 specific obligation + pinpoint cite，并说明 as provider、as deployer 适用/不适用/有何 carve-outs。
14. 若 high-risk 或等价分类适用：在 assessment 中 flag，引用 specific provision 和 regime；注明本 AIA 记录 internal review，但不替代任何 regime 要求的 formal conformity assessment；建议在受影响 jurisdiction 部署前进行 external legal review；将 classification 和 cited authority 记录到 assessment output。
15. 写 assessment：使用 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` 中的 seed structure；若 none captured，使用默认 markdown template 并逐节填写：work-product header（按 plugin config `## Outputs`，因 role 不同）、标题 `# AI Impact Assessment: [System/Feature Name]`、Prepared by/Date/Status、System owner/AI governance reviewer、Governance tier、Track；Executive summary 用两句话说明 AI 做什么及是否可以部署，并给 Overall risk（🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high）；Section 1 System description（What it does、Model/vendor、Deployment mode、Output type、Status）；Section 2 Affected parties（Who it acts on、Scale、Harm if wrong、Vulnerable groups in scope）；Section 3 Data inputs（Data categories used、Personal data、Data leaves perimeter?、Model training）；Section 4 Decision-making and oversight（Human in the loop、Override mechanism、Appeals/correction for affected parties、Named owner）；Section 5 Accuracy and bias（Error rate、Failure mode、Bias testing）；Section 6 Regulatory classification（每个适用 regime 一个 subsection，含 Regime、Classification、Prohibited practices triggered、Applicable obligations、Fundamental-rights impact assessment required?、Effective/enforcement date、Ambiguity/open interpretation；若 AI role 为 Both，加 provider-vs-deployer table）；Section 7 AI policy consistency 表格（Policy commitment、Consistent?、Notes）；Section 8 Risks and mitigations 表格（#、Risk、Likelihood、Impact、Mitigation、Status、Owner，并给 Residual risk after mitigations）；Section 9 Recommendation（APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED，Conditions 用 checklist 含 owner 和 deadline，Privacy review required?，Sign-off）；Cite check 段落说明 Section 6 的 regulatory citations 由 AI 生成、未对 primary sources 验证，认证或依赖前用 legal research tool 逐条验证 pinpoint、currency、delegated/implementing acts，source tags 显示来源，`verify` tags 优先检查。
16. 认证 AIA 前执行 Sign-off gate：读取 `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`；若 Role 为 Non-lawyer，告知认证有法律后果，AIA 会成为 regulator 或 affected party 询问时公司依赖的记录；询问是否已与 attorney 审查，若 yes 继续；若 no，生成 1-page summary：system、regulatory classification、risks identified、mitigations in place、residual risk、open questions、certifying 前要问 attorney 什么；并提示可用 professional regulator 的 referral service 找 attorney、solicitor、barrister 或其他 authorised legal professional（US state bar、SRA/Bar Standards Board in England & Wales、Law Society in Scotland/NI/Ireland/Canada/Australia 或辖区 equivalent）；没有明确 yes 不得越过 gate；DRAFT assessments for attorney review 不需要 gate，certification 需要。
17. 执行 risk quality standards：风险必须 specific and tied to the design；避免泛泛风险如 “AI hallucination”“Bias”“Vendor risk”；改写示例：模型可能生成看似合理但错误的 legal citations，而 support agents 发送给客户前没有 current verification step；résumé scoring model 基于 historical hires 训练，若 historical cohort 人口同质，underrepresented candidates 可能被系统性打低分；OpenAI terms 默认允许用 API inputs 训练，除非 agreement 确认 opt-out，customer support messages 可能被用于训练模型；目标 2-5 个 real risks，不要 12 个 padded risks。
18. 执行 AI policy diff：每个 assessment 都 cross-check `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` 中的 AI policy commitments；常见 drift：policy 禁止 AI 用于某 category 而本用例属于该 category（停止）；policy 要求 human review 而本部署没有 human step（设计需改）；policy 要求向 affected parties 披露而披露机制未建；存在 approved vendor list 而本 vendor 不在名单（需要 procurement step）。Flag every mismatch；部署前必须有一方改变，不能只标记并搁置。
19. 执行 handoffs：给 product/engineering 的条件清单要含 owners and deadlines，具体如 “add a human review step before any automated email is sent, owner: [product lead], before launch”，不要只说 “add oversight”；给 privacy：若涉及 personal data，flag “Run `/privacy-legal:pia-generation [system name]` in parallel, if the plugin is installed — the AIA doesn't substitute for a PIA.”；给 vendor-ai-review：若涉及新 vendor，flag “If there's no AI addendum reviewed for [vendor], run `/ai-governance-legal:vendor-ai-review` before production.”；给 reg-gap-analysis：若出现 new regulatory obligations（EU AI Act high-risk、new sector rule），该 skill 跟踪 gap。
20. 以 next-steps decision tree 结束：按 CLAUDE.md `## Outputs`，根据本次产出定制选项；五个默认 branches（draft the X、escalate、get more facts、watch and wait、something else）是起点不是 lock-in；tree 是输出，由 lawyer 选择。
21. 遵守 “What this skill does not do”：不批准部署，由 human 签署 assessment；不构成任何 regulatory conformity assessment——若 regime（如 EU AI Act）要求 formal conformity assessment，那是 separate exercise，需要 external legal review 和技术文档，超出本处内容；不设计 mitigations，只描述需要缓解什么，engineering 设计修复；涉及 personal data 时不替代 PIA，两者都要运行。

适用边界 · 注意事项

• 当 AI 不作出或实质影响个人决定、不处理个人数据、非客户面向、非第三方 deployer 场景，且不属 elevated/high governance tier，且 house trigger 未命中时：不运行完整 AIA，只写一段记录说明原因供未来查询。
• 涉及 personal data 时不能只做 AIA；需并行运行 `/privacy-legal:pia-generation`，且 AIA 不替代 PIA。
• 当系统部署在已捕获 `## Regulatory footprint` 之外、存在 choice-of-law 问题、或用例引入新 affected population/decision type 时：不能按原 footprint 照用，需重新推导或扩展 footprint 后再分析。