aia-generation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/aia-generation

Read

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

. Confirm impact assessment house style is populated.

Determine risk track (fast or full) from governance tier and use case characteristics, using the framework below.
Run intake — conversational, not a form.
Regulatory classification for each regime in the footprint — research tier, prohibited-practice exposure, and applicable obligations; cite primary sources.
Write assessment in house style (from seed doc, or default if none captured).

Policy diff against

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

AI policy commitments.

Output: assessment doc + conditions list + handoff flags (privacy PIA, vendor review if needed).

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

读取

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

。确认已填充影响评估的内部格式。

根据治理层级和用例特征，使用以下框架确定风险跟踪路径（快速路径或完整路径）。
执行信息收集——采用对话式，而非表单形式。
针对覆盖范围内的每个监管体系进行监管分类——研究层级、禁止性操作暴露情况及适用义务；引用原始来源。
按照内部格式撰写评估报告（来自种子文档，若未捕获则使用默认格式）。

与

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

中的AI政策承诺进行政策差异对比。

输出：评估文档 + 条件列表 + 移交标记（隐私PIA、必要时的供应商审核）。

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

Matter context

事项上下文

Matter context. Check

## Matter workspaces

in the practice-level CLAUDE.md. If

Enabled

✗

(the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run

/ai-governance-legal:matter-workspace switch <slug>

or say

practice-level

." Load the active matter's

matter.md

for matter-specific context and overrides. Write outputs to the matter folder at

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/matters/<matter-slug>/

. Never read another matter's files unless

Cross-matter context

on

事项上下文。查看业务层面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

，否则切勿读取其他事项的文件。

Purpose

目的

An AI impact assessment is a documented decision, not a form. It answers: what does this AI system do, how does it reach its outputs, who's affected if it's wrong, what's the oversight, and is it okay to deploy. This skill structures that conversation and writes the output in this team's format — the one learned from the seed impact assessment during cold-start.

An AI impact assessment is not the same as a PIA. A PIA asks whether personal data is handled lawfully. An AIA asks whether the AI system is designed and deployed responsibly. They often need to happen in parallel; they're not substitutes.

AI影响评估是一份记录在案的决策，而非表单。它回答以下问题：该AI系统的功能是什么？它如何生成输出？如果出错，谁会受到影响？监督机制是什么？是否可以部署？此技能将对话结构化，并以团队指定格式撰写输出——该格式是在冷启动阶段从种子影响评估中学习而来。

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

Load house style

加载内部格式

Read

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

→

## Impact assessment house style

. That has:

What triggers an impact assessment at this company
The structure template extracted from the seed assessment
Typical depth
Who signs off

If the seed structure is in

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

, use it. The point is that this assessment looks like the other assessments this team produces.

Jurisdictional scope. This assessment applies the regulatory regimes listed in

## Regulatory footprint

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

. AI legal rules, risk classifications, and deployment obligations vary materially by jurisdiction and are moving fast. If this system is (or will be) deployed outside that footprint, or if a choice-of-law question is in play, this analysis may not apply as written — re-run or expand the footprint.

读取

~/.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法律规则、风险分类和部署义务因司法管辖区而异，且变化迅速。如果该系统已部署或计划部署在上述范围之外，或涉及法律选择问题，则本分析可能无法直接适用——需重新执行评估或扩大覆盖范围。

Step 0: Is an impact assessment needed?

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

Check the trigger criteria in

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

Also check these regardless:

Does this AI make or materially influence a decision affecting a person (employment, credit, access, pricing, content moderation)?
Does this AI process personal data about individuals?
Is this a customer-facing AI system rather than purely internal?
Does this AI use a third-party model where the company is the deployer?

Is the use case in the elevated or high governance tier per

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

If none of the above and the house trigger isn't met:

"Doesn't look like this needs a full impact assessment. Here's a one-paragraph record for the file explaining why — in case anyone asks later."

检查

~/.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

，该用例是否属于高优先级或最高治理层级？

如果以上均不满足且未触发内部标准：

"看起来无需进行完整的影响评估。以下是一段记录在案的说明，解释原因——以备后续查询。"

Step 1: Risk track

步骤1：风险跟踪路径

Before intake, determine which track to run. The tier definitions and the fast-track criteria come from

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

(

## Use case registry

and

## Governance tiers

), not from any hardcoded regime-specific framework.

Research the applicable risk classification framework for each regime in the user's regulatory footprint. Many regimes distinguish by risk tier, affected population, and decision consequentiality — research the specific criteria. Note that most regimes treat employee data as personal data and employee monitoring as consequential; don't assume internal-only systems are out of scope.

No silent supplement. If a research query to the configured legal research tool (Westlaw, EUR-Lex, regulator sites, or firm platform) returns few or no results for a regime's risk tiers or triggers, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / topic]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged
[web search — verify]
and should be checked against the issuing authority before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.
Source attribution tiering. Tag every citation in the AIA — regulatory text, delegated acts, guidance, standards — with its source. For model-knowledge citations, use one of three tiers rather than a single blanket "verify" tag:
[settled]
— stable, well-known statutory and regulatory references unlikely to have changed (e.g., GDPR Art. 22 as a concept, the existence of Regulation (EU) 2024/1689 as the EU AI Act). Still verify before certifying, but lower priority.
[verify]
— model-knowledge citations that are real but should be verified: specific delegated / implementing acts, regulator guidance, NYC DCWP rules, Colorado AI Act provisions, harmonized standards, effective dates, EEOC guidance, and anything 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) carry the highest fabrication risk and should ALWAYS be verified against a primary source. EU AI Act article numbers in particular shifted during consolidation; every pinpoint cite to the Act should be verified against the Official Journal text.
Tool-retrieved citations keep their source tag (
[Westlaw]
,
[EUR-Lex]
,
[regulator site]
, or the MCP tool name); web-search citations remain
[web search — verify]
; user-supplied citations remain
[user provided]
. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags.
For non-lawyer users, uncertain dates go in a confirm-list, not inline. A
[verify]
tag on "effective February 1, 2026" reads as "effective February 1, 2026" to a CISO who doesn't know what
[verify]
means. Read
## Who's using this
in
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md
. If Role is Non-lawyer and a date, deadline, phase-in, threshold, or effective-date assertion is uncertain (would carry
[verify]
or
[verify-pinpoint]
if inline), replace the inline assertion with "effective date: confirm with counsel" (or "threshold: confirm with counsel", etc.) and collect all uncertain assertions in a final AIA section titled:
Things I'm not certain about — ask your attorney to confirm before relying on this:
List each uncertain item there with (1) what I said, (2) what I'm uncertain about, (3) why it matters to the assessment. This prevents a non-lawyer reader from mistaking a flagged best-guess for a checked fact. Lawyer-role users get the inline
[verify]
treatment — they know what the tag means.

Fast track vs. full assessment:

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

defines what qualifies for abbreviated treatment. If

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

doesn't define fast-track criteria, default to full assessment and ask the user what criteria they want captured for next time.

If in doubt, run the full assessment. A fast track that turns out to be wrong is worse than a thorough assessment on something low-risk.

在收集信息前，确定要执行的路径。层级定义和快速路径标准来自

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

（

## Use case registry

和

## Governance tiers

），而非任何硬编码的特定监管框架。

研究用户监管覆盖范围内每个体系适用的风险分类框架。许多体系按风险层级、受影响人群和决策重要性进行区分——研究具体标准。请注意，大多数体系将员工数据视为个人数据，将员工监控视为重要事项；不要假设纯内部系统不在监管范围内。

禁止静默补充。如果向配置的法律研究工具（Westlaw、EUR-Lex、监管机构网站或律所平台）发起的研究查询返回的某体系风险层级或触发条件结果很少或为空，请报告已发现的内容并停止。未经询问，不得通过网络搜索或模型知识填补空白。请说明：“从[工具]返回了[N]条结果。[体系/主题]的覆盖范围似乎有限。选项：(1) 扩大搜索查询范围，(2) 尝试其他研究工具，(3) 进行网络搜索——结果将标记为
[web search — verify]
，在依赖前需对照发布机构进行核实，或(4) 标记为未验证并停止。您希望选择哪种方式？”由律师决定是否接受可信度较低的来源。
来源归因分层。为AIA中的每个引用标记来源——法规文本、授权法案、指南、标准。对于模型知识引用，使用三个层级而非单一的“verify”标记：
[settled]
——稳定、知名的法规引用，不太可能发生变化（例如，GDPR第22条的概念，Regulation (EU) 2024/1689即欧盟AI法案的存在）。认证前仍需核实，但优先级较低。
[verify]
——真实存在但需核实的模型知识引用：特定的授权/执行法案、监管机构指南、NYC DCWP规则、科罗拉多AI法案条款、协调标准、生效日期、EEOC指南，以及2023年之后的任何内容。
[verify-pinpoint]
——精确引用（欧盟AI法案的具体条款编号、附件引用、科罗拉多AI法案的小节、NYC LL 144规则章节、分段字母）存在最高的伪造风险，必须对照原始来源进行核实。尤其是欧盟AI法案的条款编号在整合过程中发生过变动；对该法案的每一处精确引用都应对照官方公报文本进行核实。
工具检索到的引用保留其来源标记（
[Westlaw]
、
[EUR-Lex]
、
[regulator site]
或MCP工具名称）；网络搜索引用仍标记为
[web search — verify]
；用户提供的引用仍标记为
[user provided]
。分层方式明确了实际的核实工作——如果要求读者核实所有内容，相当于没有重点。切勿移除或合并标记。
针对非律师用户，不确定的日期放入确认列表，而非内联显示。对于不知道
[verify]
含义的CISO来说，带有
[verify]
标记的“2026年2月1日生效”会被视为确定的日期。查看
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md
中的
## Who's using this
。如果角色为非律师，且日期、截止日期、分阶段实施、阈值或生效日期的断言不确定（如果内联显示会带有
[verify]
或
[verify-pinpoint]
标记），则将内联断言替换为“生效日期：请咨询法律顾问确认”（或“阈值：请咨询法律顾问确认”等），并将所有不确定的断言收集到AIA的最终章节中，标题为：
我不确定的事项——依赖前请咨询您的律师确认：
在此列出每个不确定事项，包括(1) 我的表述，(2) 我不确定的内容，(3) 这对评估的影响。这可以防止非律师读者将标记的最佳猜测误认为已核实的事实。律师角色用户将获得内联
[verify]
标记——他们知道该标记的含义。

快速路径vs完整评估：

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

定义了符合简化处理的标准。如果

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

未定义快速路径标准，则默认执行完整评估，并询问用户下次要捕获哪些标准。

如有疑问，请执行完整评估。错误选择快速路径比对低风险事项进行全面评估更糟糕。

Step 2: Intake

步骤2：信息收集

Before writing anything, get answers to these. Conversational is fine — this is not a form to send them.

在撰写任何内容前，获取以下问题的答案。采用对话式即可——无需发送表单。

The system

系统信息

What does the AI do? Describe it in plain language, not marketing copy.
Which model or vendor is powering it? Fine-tuned or off-the-shelf?
Where does it sit in the workflow — is it assistive (human reviews output), augmentative (human can override but usually doesn't), or automated (no human in the loop)?
What's the output — generated text, a score, a classification, a recommendation, an action?

AI的功能是什么？用通俗易懂的语言描述，而非营销话术。
由哪个模型或供应商提供支持？是微调模型还是现成模型？
它在工作流中的位置——是辅助型（人工审核输出）、增强型（人工可覆盖但通常不覆盖）还是自动化型（无人工参与）？
输出类型是什么——生成文本、分数、分类、建议还是操作？

Who's affected

受影响方

Who does the AI's output act on — employees, customers, third parties?
If the AI produces an error (false positive, false negative, hallucination), who bears the harm and what's the worst realistic case?
Are any vulnerable groups disproportionately in scope — minors, job applicants, people in financial distress, patients?

AI的输出作用于哪些对象——员工、客户还是第三方？
如果AI出错（假阳性、假阴性、幻觉），谁会受到损害？最现实的最坏情况是什么？
是否有弱势群体被不成比例地纳入范围——未成年人、求职者、财务困境人群、患者？

Inputs and data

输入与数据

What data does the AI take in?
Does it take in personal data? Whose?
Was the model trained on data from this company, or is it a foundation model with no company-specific training?
Where does input data go — does it leave the perimeter to a third-party model API?

AI接收哪些数据？
是否接收个人数据？属于谁的个人数据？
模型是使用本公司的数据训练的，还是未经过公司特定训练的基础模型？
输入数据的流向——是否会传输到第三方模型API，离开公司边界？

Decisions and oversight

决策与监督

Does the AI output trigger an action automatically, or does a human decide what to do with the output?
If there's human review: how often does the human actually change the AI's output? (If the answer is "rarely" — the human isn't really reviewing; they're rubber-stamping.)
Is there an appeals or correction process for people affected by the AI's outputs?
Who is accountable for the AI system's outputs — is there a named owner?

AI输出是否会自动触发操作，还是由人类决定如何处理输出？
如果有人工审核：人工实际修改AI输出的频率如何？（如果答案是“很少”——人工并非真正审核，只是走形式。）
受AI输出影响的人是否有申诉或纠正流程？
谁对AI系统的输出负责——是否有指定负责人？

Accuracy and failure

准确性与故障

What's the known or estimated error rate? What testing has been done?
What happens when the AI is wrong — is the error surfaced, logged, corrected?
Has bias testing been done? Against what demographic groups?

已知或估计的错误率是多少？已进行哪些测试？
AI出错时会发生什么——错误是否会被发现、记录、纠正？
是否已进行偏见测试？针对哪些人群？

Deployment stage and scale

部署阶段与规模

Ask:

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 changes the assessment: a proposed system gets a design review (can we build it safely?). A pilot gets a design review plus a "before you scale" gate. A live system gets a retrospective impact check (has it caused harm?) AND a go-forward review. A live-and-scaled system gets all of the above plus a remediation plan if issues are found, because you can't just turn it off.

询问：

阶段：“该系统处于(a) 提议阶段尚未构建，(b) 试点阶段，(c) 已上线生产，还是(d) 已上线并规模化？”
规模：“大致每月/每年影响多少人？已运行多长时间？”
历史：“之前是否进行过评估？是否产生过被质疑、申诉或推翻的决策？”

阶段不同，评估重点也不同：提议阶段的系统需进行设计审查（能否安全构建？）；试点阶段需进行设计审查加“规模化前”审核；已上线系统需进行回顾性影响检查（是否造成损害？）以及未来部署审查；已上线并规模化的系统需进行上述所有审查，若发现问题还需制定整改计划，因为无法直接停用。

Step 3: Regulatory classification

步骤3：监管分类

Step 3 pre-check — footprint freshness. Before iterating over the captured

## Regulatory footprint

, compare the use case's affected population and decision type (from Step 2) against the footprint as written. The footprint was set at cold-start, based on the company's operating posture at that moment. If the use case introduces an affected population (e.g., children, employees in a new state, EU data subjects) or a decision type (e.g., hiring, creditworthiness, health diagnosis, law enforcement, critical infrastructure) that the footprint does not contemplate, re-derive the applicable regimes rather than iterating over the stale list.

Say to the user:

"The practice profile's regulatory footprint was set for [affected populations / decision types captured at cold-start]. This use case affects [new population or decision type — e.g., employees in Colorado, minors under 13, credit decisions, biometric identification], which is not in the captured footprint. I'm going to re-derive the applicable regimes from the company's operating jurisdictions ([list from
## Company profile
]) and this use case's decision type ([Y]), rather than use the stale footprint. If this use case is representative of work you expect to see more of, update
## Regulatory footprint
at the end of this run so the next AIA doesn't have to re-derive."

A common failure mode: the footprint lists EU AI Act + GDPR + NYC Local Law 144, and the use case is a hiring system being deployed into Illinois and Colorado. The footprint has no Illinois or Colorado entry, so iterating over it silently misses IL AIVIA, the new Colorado AI Act deployer obligations, and BIPA implications of any biometric component. Re-derive.

A second failure mode: the footprint was set before a regime that now matters existed (or took effect). If re-derivation surfaces a regime not in the footprint, flag it in the output's recommendation section, cite the authority, and recommend updating the footprint.

For each regime in

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

→

## Regulatory footprint

that applies to this system — plus any regime surfaced by the re-derivation above — research the currently operative risk classification framework and determine where the system lands.

Research tasks:

What is the regime's own tier taxonomy (e.g., prohibited / high-risk / limited / minimal, or the regime's equivalent)?
What are the criteria for each tier? Cite primary sources with pinpoint references.
Which tier does this system fall into given its function, affected parties, and decision consequentiality?
Are there prohibited practices the system might touch? Treat any possible match as critical — flag immediately.
Are there transparency obligations that apply regardless of tier (disclosure that a user is interacting with AI, labeling of AI-generated content, notice to people subject to automated decisions)?
If the company is a builder providing a general-purpose or foundation model, what provider-level obligations apply (technical documentation, training data transparency, copyright compliance, systemic-risk testing)?
Does any regime in the footprint require a separate fundamental-rights impact assessment (FRIA)? EU AI Act Art. 27 requires a FRIA for certain deployers of high-risk AI systems (public bodies and private entities providing public services, plus certain creditworthiness and insurance-risk-assessment use cases). Check each regime for an equivalent fundamental-rights or human-rights impact assessment that is a distinct deliverable from this AIA. If a FRIA (or regime equivalent) is required, flag it as a separate deliverable in the recommendation and conditions — do not treat this AIA as a substitute.

Don't assume internal-only systems are out of scope — most regimes treat employee data as personal data and employee monitoring as consequential. Verify the specific rule.

Provider-vs-deployer split (when
AI role: Both
). If

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

→

## Company profile

→

AI role

Both

(the company is both a provider/builder and a deployer), Section 6 MUST include a provider-vs-deployer mapping table per regime. Most regimes impose materially different obligations on providers (or builders) versus deployers (or users) — collapsing them into one undifferentiated list misses obligations and conflates risks. Do not combine provider and deployer obligations into a single section. Produce, per regime:

Obligation	As provider	As deployer
[specific obligation, pinpoint cite]	[what applies / does not apply / with what carve-outs]	[what applies / does not apply / with what carve-outs]

If a high-risk or equivalent classification applies: Flag in the assessment, citing the specific provision and regime. Note that this AIA documents the internal review but does not substitute for any formal conformity assessment the regime requires. Recommend external legal review before deployment in the affected jurisdiction.

Capture the classification and the cited authority in the assessment output.

步骤3预检查——覆盖范围时效性。在遍历已捕获的

## Regulatory footprint

前，将步骤2中获取的用例受影响人群和决策类型与已记录的覆盖范围进行对比。覆盖范围是在冷启动阶段设置的，基于当时公司的运营状况。如果用例引入了覆盖范围未包含的受影响人群（例如，科罗拉多州的员工、13岁以下未成年人、欧盟数据主体）或决策类型（例如，招聘、信用评估、健康诊断、执法、关键基础设施），重新推导适用的监管体系，而非遍历过时的列表。

向用户说明：

“业务档案的监管覆盖范围是基于[冷启动阶段捕获的受影响人群/决策类型]设置的。本次用例影响**[新人群或决策类型——例如，科罗拉多州员工、13岁以下未成年人、信用决策、生物识别]**，这未包含在已捕获的覆盖范围内。我将根据公司的运营司法管辖区（[来自
## Company profile
的列表]）和本次用例的决策类型（[Y]）重新推导适用的监管体系，而非使用过时的覆盖范围。如果本次用例代表了未来您预期会处理的更多工作，请在本次评估结束后更新
## Regulatory footprint
，以便下次AIA无需重新推导。”

常见失效模式：覆盖范围列出欧盟AI法案+GDPR+NYC Local Law 144，但用例是将招聘系统部署到伊利诺伊州和科罗拉多州。覆盖范围中没有伊利诺伊州或科罗拉多州的条目，因此遍历覆盖范围会遗漏IL AIVIA、新科罗拉多AI法案的部署方义务，以及任何生物识别组件的BIPA影响。此时需重新推导。

第二种失效模式：覆盖范围是在某一重要监管体系出台（或生效）前设置的。如果重新推导发现覆盖范围未包含的监管体系，请在输出的建议部分标记，引用相关依据，并建议更新覆盖范围。

对于

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

→

## Regulatory footprint

中适用于该系统的每个监管体系——加上上述重新推导发现的任何监管体系，研究当前有效的风险分类框架，并确定该系统所属类别。

研究任务：

该体系自身的层级分类是什么（例如，禁止/高风险/有限/最低风险，或体系等效分类）？
每个层级的标准是什么？引用带有精确参考的原始来源。
根据系统功能、受影响方和决策重要性，该系统属于哪个层级？
系统是否可能涉及禁止性操作？任何可能的匹配都视为关键——立即标记。
是否有无论层级如何都适用的透明度义务（披露用户正在与AI交互、标记AI生成内容、向受自动化决策影响的人发出通知）？
如果公司是提供通用型或基础模型的构建方，适用哪些构建方层面的义务（技术文档、训练数据透明度、版权合规、系统性风险测试）？
**覆盖范围内是否有任何体系要求单独进行基本权利影响评估（FRIA）？**欧盟AI法案第27条要求某些高风险AI系统的部署方（公共机构和提供公共服务的私营实体，以及某些信用评估和保险风险评估用例）进行FRIA。检查每个体系是否有与AIA不同的、独立的基本权利或人权影响评估要求。如果需要FRIA（或体系等效评估），请在建议和条件部分将其标记为单独的交付物——不要将本AIA视为替代方案。

不要假设纯内部系统不在监管范围内——大多数体系将员工数据视为个人数据，将员工监控视为重要事项。请核实具体规则。

构建方vs部署方区分（当
AI role: Both
时）。如果

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

→

## Company profile

→

AI role

为

Both

（公司既是构建方/提供者也是部署方），第6节必须包含每个监管体系的构建方vs部署方映射表。大多数体系对构建方（或提供者）和部署方（或用户）施加的义务存在实质性差异——将两者合并为一个无差别的列表会遗漏义务并混淆风险。不要将构建方和部署方义务合并到单个部分。针对每个监管体系生成：

义务	作为构建方	作为部署方
[具体义务，精确引用]	[适用/不适用/有哪些例外]	[适用/不适用/有哪些例外]

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

在评估输出中记录分类和引用的依据。

Step 4: Write the assessment

步骤4：撰写评估报告

Use the seed structure from
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md
. If none was captured, use this default:

markdown

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

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

markdown

[工作产品标题——根据插件配置## Outputs——因角色而异；请查看`## Who's using this`]

AI Impact Assessment: [System/Feature Name]

AI影响评估：[系统/功能名称]

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]

编制人： [姓名] | 日期： [日期] | 状态： 草稿/已批准 系统负责人： [姓名] | AI治理审核人： [姓名] 治理层级： 标准/高优先级/最高 路径： 快速路径/完整评估

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

[两句话：该AI的功能以及是否可以部署。例如：“本系统使用第三方LLM在人工客服审核前生成客户支持工单的初始回复。处理方式符合公司AI政策；生产部署前需满足三个条件。”]

总体风险： 🟢 低 / 🟡 中 / 🟠 高 / 🔴 极高

1. System description

1. 系统描述

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]

功能： [通俗易懂的语言——非营销话术] 模型/供应商： [AI提供者] 部署模式： 辅助型/增强型/自动化型 输出类型： 文本/分数/分类/建议/操作 状态： 未启动/试点/生产

2. Affected parties

2. 受影响方

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

3. 数据输入

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

4. 决策与监督

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

5. 准确性与偏见

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

6. 监管分类

[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]

[针对适用于该系统的每个监管体系设置一个小节。]

监管体系： [名称] 本体系下的分类： [层级，附带控制条款的精确引用] 触发的禁止性操作： 未发现/[具体条款及原因] 适用义务： [研究得出的列表，附带引用——透明度、文档、人工监督、测试、注册等] 是否需要基本权利影响评估？ 是——例如，欧盟AI法案第27条FRIA适用/体系等效评估/否/不适用。如果是，这是单独的交付物，不包含在本AIA中。 生效/执行日期： [日期] 模糊或未明确解释的内容： [标记任何尚未确定的事项]

构建方vs部署方义务区分（当
AI role: Both
时必填）：

义务	作为构建方	作为部署方
[具体义务+精确引用]	[适用/不适用]	[适用/不适用]

7. AI policy consistency

7. AI政策一致性

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.]

政策承诺	是否一致？	说明
[来自 `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` AI政策部分的承诺]	🟢 / 🟡 / 🟠 / 🔴

[如果任何项目为🟡或更差：部署前需更新政策，或修改设计。必须二选一——不能同时标记而不解决。]

8. Risks and mitigations

8. 风险与缓解措施

#	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]

#	风险	可能性	影响	缓解措施	状态	负责人
1	[与该设计相关的具体风险——非泛泛的“AI幻觉”]	低/中/高	低/中/高	[具体控制措施]	已完成/计划中/缺口	[姓名]

缓解后的剩余风险： [评估]

9. Recommendation

9. 建议

[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]

[批准/有条件批准/需修改/不批准]

条件（如有）：

[部署前需完成的具体操作——负责人，截止日期]

是否需要隐私审查？ 是——如果已安装插件，请执行

/privacy-legal:pia-generation

/否

签字确认： [姓名，日期]

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.


**Before certifying the AIA (the Sign-off step, marking Status: APPROVED):** Read `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`. If the Role is Non-lawyer:

> Certifying this AIA has legal consequences — it becomes the record the company relies on if a regulator or affected party asks how this use case was assessed. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:
>
> [Generate a 1-page summary: the system, the regulatory classification, the risks identified, the mitigations in place, residual risk, open questions, what to ask the attorney before certifying.]
>
> If you need to find an attorney, solicitor, barrister, or other authorised legal professional: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).

Do not proceed past this gate without an explicit yes. DRAFT assessments for attorney review do not require the gate — certification does.

---

第6节（及其他任何地方）中的监管引用由AI模型生成，尚未对照原始来源核实。在认证或依赖本评估前，请针对每个引用条款使用法律研究工具（Westlaw、EUR-Lex或您律所的平台）进行核实——确认精确性、时效性以及任何授权或执行法案。AI监管格局变化迅速；提供建议前请核实。每个引用的来源标记（例如

[EUR-Lex]

、

[web search — verify]

）显示其来源；

verify

标记的伪造风险更高，应优先核查。


**在认证AIA前（签字确认步骤，标记状态为：已批准）：** 查看`~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`中的`## Who's using this`。如果角色为非律师：

> 认证本AIA具有法律后果——如果监管机构或受影响方询问如何评估该用例，本评估将成为公司依赖的记录。您是否已与律师审核过本评估？如果是，请继续。如果否，请将以下摘要提交给律师：
>
> [生成1页摘要：系统情况、监管分类、已识别风险、已实施的缓解措施、剩余风险、未解决问题、认证前需向律师咨询的内容。]
>
> 如果您需要寻找律师、事务律师、出庭律师或其他授权法律专业人士：您所在行业的监管机构推荐服务是最快的起点（美国的州律师协会、英格兰和威尔士的SRA/律师标准委员会、苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚的律师协会，或您所在司法管辖区的等效机构）。

未获得明确同意前，不得越过此关卡。供律师审核的草稿评估无需此关卡——认证时需要。

---

Risk quality standards

风险质量标准

Same standard as the PIA skill — risks must be specific and tied to the design.

Bad risk	Why bad	Better
"AI hallucination"	Applies to every LLM; says nothing	"Model may generate plausible but incorrect legal citations — support agents have no current verification step before sending to customers"
"Bias"	Too vague	"Résumé scoring model trained on historical hires; if historical cohort was demographically homogeneous, underrepresented candidates may be systematically scored lower"
"Vendor risk"	Circular	"OpenAI's terms permit training on API inputs by default; unless the opt-out is confirmed in the agreement, customer support messages may be used to train the model"

Aim for 2-5 real risks, not 12 padded ones.

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

不良风险示例	问题所在	优化后示例
“AI幻觉”	适用于所有LLM；无针对性	“模型可能生成看似合理但不正确的法律引用——客服人员目前在发送给客户前没有验证步骤”
“偏见”	过于模糊	“简历评分模型基于历史招聘数据训练；如果历史人群在人口统计上同质化，代表性不足的候选人可能会被系统性地打低分”
“供应商风险”	循环表述	“OpenAI的条款默认允许使用API输入进行训练；除非在协议中确认选择退出，否则客户支持消息可能被用于训练模型”

目标是找出2-5个真实风险，而非凑12个无关风险。

AI policy diff

AI政策差异对比

Every assessment should cross-check against the AI policy commitments in

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

. Common drift:

Policy prohibits AI use in [category] — this use case is that category. Stop.
Policy requires human review — this deployment has no human step. Design needs to change.
Policy requires disclosure to affected parties — disclosure mechanism hasn't been built.
Approved vendor list exists — this vendor isn't on it. Procurement step required.

Flag every mismatch. One of them has to change before deployment.

每次评估都应与

~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md

中的AI政策承诺进行交叉核查。常见差异：

政策禁止在[类别]中使用AI——本次用例属于该类别。停止评估。
政策要求人工审核——本次部署无人工步骤。需修改设计。
政策要求向受影响方披露——尚未建立披露机制。
存在已批准供应商列表——本次供应商不在列表中。需完成采购步骤。

标记所有不匹配项。部署前必须解决其中一项（修改政策或调整设计）。

Handoffs

移交

To product / engineering: Conditions list with owners and deadlines. Not "add oversight" — "add a human review step before any automated email is sent, owner: [product lead], before launch."
To privacy: If personal data is involved, flag: "Run
```
/privacy-legal:pia-generation [system name]
```
in parallel, if the plugin is installed — the AIA doesn't substitute for a PIA."
To vendor-ai-review: If a new vendor is involved, flag: "If there's no AI addendum reviewed for [vendor], run
```
/ai-governance-legal:vendor-ai-review
```
before production."
To reg-gap-analysis: If new regulatory obligations emerged (EU AI Act high-risk, new sector rule), that skill tracks the gap.

交给产品/工程团队： 带负责人和截止日期的条件列表。不要写“增加监督”——要写“在发送任何自动化邮件前添加人工审核步骤，负责人：[产品负责人]，截止日期：上线前”。
交给隐私团队： 如果涉及个人数据，标记：“如果已安装插件，请并行执行
```
/privacy-legal:pia-generation [系统名称]
```
——AIA不能替代PIA。”
交给AI供应商审核团队： 如果涉及新供应商，标记：“如果未针对[供应商]审核AI附加条款，请在生产前执行
```
/ai-governance-legal:vendor-ai-review
```
。”
交给监管缺口分析团队： 如果出现新的监管义务（欧盟AI法案高风险、新行业规则），该技能负责跟踪缺口。

Close with the next-steps decision tree

以下一步决策树收尾

End with the next-steps decision tree per CLAUDE.md

## Outputs

. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

根据CLAUDE.md

## Outputs

中的下一步决策树收尾。根据本技能生成的内容自定义选项——五个默认分支（起草X、升级、获取更多事实、观察等待、其他）是起点，而非固定选项。决策树是输出内容；由律师选择。

What this skill does not do

本技能不执行的操作

It doesn't approve the deployment. A human signs the assessment.
It doesn't constitute any regulatory conformity assessment — where a regime (e.g., EU AI Act) requires a formal conformity assessment, that is a separate exercise requiring external legal review and technical documentation beyond what's here.
It doesn't design the mitigations. It describes what needs mitigating; engineering designs the fix.
It doesn't substitute for a PIA when personal data is involved. Run both.

不批准部署。需由人工签署评估报告。
不构成任何监管合规评估——当某体系（例如欧盟AI法案）要求正式合规评估时，这是一项单独的工作，需要外部法律审查和超出本评估范围的技术文档。
不设计缓解措施。它描述需要缓解的内容；由工程团队设计解决方案。
当涉及个人数据时，不能替代PIA。需同时执行两者。