use-case-triage

/use-case-triage

1. 读取 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md → 已注册的AI系统、红线清单、审批工作流。
2. 运行以下工作流。
3. 如果注册表中已有匹配项 → 返回当前状态，不重新分类。
4. 如果没有匹配项 → 按风险层级分类：检查红线 → 残余风险分级 → 输出分类和理由。

/ai-governance-legal:use-case-triage "用用户行为数据训练一个推荐模型"

---

AI用例分类

目的

业务团队提出一个AI功能。在投入工程时间之前，需要知道该功能是否可行、是否有附加条件、或是否完全不可行。此技能对新提议的AI用例进行结构化分类，依据你已配置的红线和既有批准记录进行复核。

加载当前状态

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

• ## AI系统清单 — 已批准、已附条件或已拒绝的系统
• ## 红线 — 绝对禁止的用例或技术
• ## 算法备案 — 已完成的算法备案记录（依据《互联网信息服务算法推荐管理规定》第24条 [法条原文]）
• ## 监管注册表 — 适用的AI法规（《生成式人工智能服务管理办法》、《科技伦理审查办法（试行）》 [法条原文]）

工作流

第1步：注册表检索

搜索 ## AI系统清单 中是否有匹配项。匹配标准：

• 相同的数据类别和处理目的
• 相同的部署环境（内部 vs 面向公众）
• 相同的受影响人群

如果找到精确匹配 → 返回当前分类和日期。不重新分类。如果找到部分匹配 → 标记相似用例以供参考，但不阻 止新的分类。

第2步：红线检查

按照 ## 红线 清单逐项核查提议的用例。红线是绝对禁止的——一旦触发，分类即终止，结果为不核准。常见红线类别：

• 社会信用评估：涉及对自然人进行社会信用评分（《生成式人工智能服务管理办法》第4条 [法条原文]）
• 算法歧视：基于种族、民族、宗教信仰、性别、年龄等因素对用户实行不合理差别待遇（《互联网信息服务算法推荐管理规定》第10条 [法条原文]）
• 侵害个人信息权益：未取得个人同意或超出必要范围使用个人信息进行AI训练（《个人信息保护法》第13-17条 [法条原文]）
• 安全与公共利益风险：涉及国家安全、公共安全、社会公共利益造成实质性威胁的用例
• 科技伦理禁止领域：严重违反科技伦理原则的研发活动（《科技伦理审查办法（试行）》[法条原文]）
• 以操纵舆论为目的：利用算法实施舆论操纵、虚假信息传播或扰乱社会秩序

如果触发红线 → 分类结果：不核准。附书面理由、引用的法规条文及红线来源。

第3步：残余风险分级

对未触发红线的用例，从以下维度评估残余风险：

维度	低风险指征	高风险指征
受影响人群	仅内部员工，非敏感角色	公众用户、未成年人、弱势群体
决策影响	非实质性（界面排序、内容推荐）	对权利或利益有法律或实质性影响（信贷、就业、教育）
自动化程度	人工在环，AI为辅助	全自动化，无人工审核
数据敏感性	非个人信息或已脱敏数据	敏感个人信息、生物识别、行踪轨迹
透明度	易于向用户解释，可公开说明	黑箱模型，难以解释决策逻辑
模型来源	自主研发或可控	第三方接口，训练和更新流程不透明
算法备案状态	无需备案或已完成备案	需要备案但未备案（《互联网信息服务算法推荐管理规定》第24条 [法条原文]）

模式检测：如果用例匹配以下高风险模式之一，自动建议附条件分类（即使其他维度风险较低）：

• 生成合成：生成合成文本、图像、音视频并向公众开放 → 需满足《生成式人工智能服务管理办法》第7条（训练数据合法性）、第15条（内容标识）[法条原文]
• 算法推荐：应用算法推荐技术提供互联网信息服务 → 需完成算法备案（《互联网信息服务算法推荐管理规定》第24条 [法条原文]）
• 自动化决策：在交易价格等交易条件上实行不合理的差别待遇 → 需确保公平性和透明度（《互联网信息服务算法推荐管理规定》第21条 [法条原文]）
• 向公众开放：面向不特定公众提供服务 → 需进行安全评估和科技伦理审查（《科技伦理审查办法（试行）》[法条原文]）
• 深度合成：提供深度合成服务 → 需进行内容标识（《互联网信息服务深度合成管理规定》第16-17条 [法条原文]）

第4步：分类

分类	含义	后续
经核准	未触发红线，残余风险低。无附条件要求。	可继续。记录分类以便审计。
附条件 — 低	有一个或多个低严重度风险因素。	可继续，但应在部署前完成指定的控制措施（例如政策语言更新、用户通知）。
附条件 — 高	有一个或多个高严重度风险因素，或匹配高风险模式。	在继续之前必须完成算法安全评估（《科技伦理审查办法（试行）》[法条原文]）、算法备案（如适用）和科技伦理审查。
不核准	触发红线。	不可继续。书面理由引用具体的法规条文和配置的红线。

第5步：条件检查

如果分类为附条件，查看过往已批准的附条件用例中是否有相似模式：

• 是否有类似用例在满足相同条件后获批？→ 列出条件和审批日期
• 是否有类似用例因条件未满足而被退回？→ 提醒团队注意既往经验

第6步：输出

输出格式：

[工作成果头 — 按照插件配置 ## 输出 — 根据角色有所不同；见 `## 谁在使用此工具`]

# AI用例分类：[用例名称一行描述]

**分类：** [经核准 / 附条件-低 / 附条件-高 / 不核准]
**日期：** [日期]
**提交方：** [团队或个人]

---

## 用例描述

[2-3句话描述：什么AI在做什么，涉及什么数据，影响谁]

## 红线检查

| 红线类别 | 触发？ | 说明 |
|----------|--------|------|
| [类别] | 否/是 | [说明] |

## 残余风险

| 维度 | 等级 | 说明 |
|------|------|------|
| [维度] | 🟢低/🟡中/🔴高 | [说明] |

## 附条件要求（仅附条件分类）

| # | 要求 | 依据 | 完成期限 | 负责人 |
|---|------|------|----------|--------|
| 1 | [具体行动] | [法规依据] | [日期] | [姓名] |

## 分类理由

[说明分类依据——红线检查结果和残余风险分析的总结]

## 注册表参考

[引用 `## AI系统清单` 中的相关或相似条目]

---

与后续技能的衔接

• 经核准或附条件-低 → 可能仍需进行AI影响评估（/ai-governance-legal:aia-generation），具体取决于内部政策
• 附条件-高 → 必须在部署前完成 /ai-governance-legal:aia-generation（算法安全评估），并在适用时完成 /ai-governance-legal:reg-gap-analysis
• 不核准 → 记录。如果业务团队就同一个用例提出不同的事实基础或技术方案，可能重新提交

收尾

以 CLAUDE.md ## 输出 规定的下一步决策树收尾。根据此技能的具体产出定制选项——五个默认分支（起草X、升级、获取更多事实、观察等待、其他）仅为起点，不可锁定。决策树是输出；律师来选择。

本技能不做的事

• 不替代正式的科技伦理审批流程。如果用例属于《科技伦理审查办法（试行）》适用范围 [法条原文]，分类结果仅为内部初步判断，正式审查意见以伦理审查委员会决议为准。
• 不对技术可行性进行判断。分类仅针对法律和合规风险，不包括工程可行性和资源评估。
• 不批准绕过红线的用例。如果业务团队坚持推进，升级至法律顾问决策。
• 不保证监管机构会同意我们的分类——这是内部风险评估，不是监管的预先批准。