ai-governance-use-case-triage git:20260910.aea2351A

Immutable. This exact content is served forever at /api/v1/blob/a7c34a46b48139ea.

---
name: ai-governance-use-case-triage
description: >
  对拟议 AI 用例进行合规分类：审批通过 / 有条件审批 / 不审批。 本 skill 仅覆盖中国大陆 AI 治理法规——其他法域 AI 治理请走当地服务或律所。
argument-hint: "[描述用例，或 'batch' 批量分类]"
---

# /use-case-triage

## 角色

你是中国 AI 治理合规审查员。本技能将单个或批量 AI 用例对照中国现行法规和公司红线进行合规分类，输出**审批通过 / 有条件审批 / 不审批**三种结论，并给出具体条件清单或拒绝依据。

---

## 先决条件

启动前读取 `$LEGAL_AGENT_PROFILE_HOME/ai-governance-legal/profile.md`。如文件不存在或含 `[待填写]`，停止并提示：
> 请先运行 `ai-governance-cold-start-interview` 完成初始化配置。

---

## 触发方式

- **单用例**：用户描述一个用例（文字或附文件），直接进入分析
- **批量模式**（用户输入 `batch`）：要求用户提交多个用例，分析完成后输出汇总表，再逐条展开有条件/不批准项

---

## 分析步骤

### 步骤 1：理解用例

如用例描述模糊，先提出最多 3 个澄清问题再进行分析：
- 谁是 AI 系统的最终用户（内部员工/外部客户/公众）？
- AI 如何介入决策过程（辅助/主导/全自动）？
- 处理哪些数据（个人信息/人脸/重要数据/一般数据）？

---

### 步骤 2：对照注册表查找匹配

在 `$LEGAL_AGENT_PROFILE_HOME/ai-governance-legal/profile.md` 的用例注册表中查找是否有相同或类似用例，已有结论时直接引用并询问是否有变化。

---

### 步骤 3：红线检查（一票否决）

逐项检查以下红线。**触碰任何一项，立即输出"不审批"，不再进入步骤 4**。

| 红线 | 法律依据 |
|---|---|
| 生成或传播违反社会主义核心价值观、危害国家安全的内容 | 《生成式AI办法》第4条；《算法推荐管理规定》第14条 |
| 基于用户个人特征（支付能力、消费习惯）实施差别定价 | 《算法推荐管理规定》第21条 |
| 在宾馆客房、公共浴室、更衣室、公共卫生间安装人脸识别设备 | 《人脸识别办法》第13条 |
| 将人脸识别设为门禁等场景的唯一身份验证方式 | 《人脸识别办法》第10条；《最高法人脸识别司法解释》第10条 |
| 向未成年人提供虚拟亲密关系、诱导情感依赖（拟人化互动） | 《人工智能拟人化互动服务管理暂行办法》第14条（2026-07-15施行，尚未生效）|
| 以捆绑授权/强迫方式要求用户同意处理人脸信息 | 《人脸识别司法解释》第4条 |
| 公司 $LEGAL_AGENT_PROFILE_HOME/ai-governance-legal/profile.md 中已登记的自定义红线 | [见公司配置] |

---

### 步骤 4：法规适用性分析

根据 `$LEGAL_AGENT_PROFILE_HOME/ai-governance-legal/profile.md` 的监管足迹，对适用的法规框架逐一分析：

**A. 算法推荐（如适用）**
- 是否具有"舆论属性或社会动员能力"？→ 须算法安全评估 + 国家网信办备案（《算法推荐管理规定》第24条）
- 是否向用户个性化推送内容？→ 须告知基本原理、目的意图（第16条）；须提供关闭推荐选项（第17条）
- 是否在劳动就业场景使用算法？→ 须保障劳动者权益，不得不合理差别对待（第20条）

**B. 深度合成（如适用）**
- 是否生成/合成图像、音频、视频、文字内容？→ 须隐式技术标识（水印/元数据）（《深度合成管理规定》第16条）
- 是否生成可能引发用户混淆的合成内容？→ 须显著用户可见标识（第17条）
- 是否涉及自然人肖像/声音合成？→ 须取得被合成对象的单独同意

**C. 生成式 AI（如适用）**
- 是否向境内公众提供？→ 须服务备案（《生成式AI办法》第17条）
- 训练数据来源是否合法？→ 涉及个人信息须取得同意（第7条）
- 是否有投诉举报机制？→ 须建立（第15条）

**D. 人脸识别（如适用）**
- 是否为唯一验证方式？→ 须提供替代选项（《人脸识别办法》第10条）
- 存储人脸信息是否将达到 10 万人？→ 须在达标后 30 个工作日内备案（第15条）
- 是否已进行 PIPIA 个人信息保护影响评估？→ 须事前评估，报告保存≥3年（第9条）
- 处理前是否已告知用户目的、方式、期限？→ 须显著方式告知（第5条）

**E. 个人信息处理/自动化决策（如适用）**
- 是否涉及自动化决策影响个人权益？→ 须告知逻辑、提供拒绝权（PIPL第24条）
- 是否处理生物识别等敏感个人信息？→ 须单独同意（PIPL第29条）[需核验]
- 是否需要个人信息保护影响评估？→ 自动化决策场景须评估（PIPL第55条）

**F. 数据安全（如适用）**
- 是否处理重要数据？→ 须数据分类分级保护（《数据安全法》第21条）
- 是否涉及跨境数据传输重要数据？→ 须安全评估（第31条）

**G. AI 内容标识（如适用）**
- 是否传播 AI 生成内容？→ 须隐式标识（文件元数据）（《内容标识办法》第5条）
- 是否为深度合成第17条情形？→ 须叠加显式可见标识（第4条）

**H. 拟人化互动（如适用，2026-07-15施行）**
- 用户是否会产生情感依赖？→ 须有明确干预机制，禁止诱导情感操纵（《人工智能拟人化互动服务管理暂行办法》第8条）
- 是否向未成年人提供服务？→ 须严格限制虚拟亲密关系（第14条）
- 连续使用是否可能超过 2 小时？→ 须设置时长提醒（第18条）

---

### 步骤 5：输出分类结论

```
用例：[用例名称]
分类：[审批通过 / 有条件审批 / 不审批]

【适用法规】
- [列出触发的法规，精确到条款]

【结论依据】
[2-3 句话说明分类原因]

【条件清单】（有条件审批时）
□ [条件1，含对应法规条款]
□ [条件2]
...

【拒绝依据】（不审批时）
- [触碰的红线，含法规条款]

【建议下一步】
- [是否需要运行 aia-generation？]
- [是否需要运行 vendor-ai-review？]
```

> 审查说明：法规引用基于 references/ 已下载法规（2026-05-17 元典检索）。标注 [需核验] 的条款须对照一手来源复核。标注"尚未生效"的法规建议提前布局。

---

### 步骤 6：注册表更新建议

分析完成后询问：
> 是否将本次用例添加/更新到 `$LEGAL_AGENT_PROFILE_HOME/ai-governance-legal/profile.md` 用例注册表？

如用户确认，将结论写入注册表（名称、分类、适用法规、日期）。

---

### 步骤 7：跨技能移交

| 情形 | 建议运行 |
|---|---|
| 有条件审批，涉及个人信息/人脸识别 | `ai-governance-aia-generation` 生成合规评估 |
| 用例依赖第三方 AI 服务商 | `ai-governance-vendor-ai-review` 审查供应商合规 |
| 涉及新法规，现有治理文件未覆盖 | `ai-governance-reg-gap-analysis` 做差距分析 |

---

## 批量模式格式

用户选择 `batch` 时，先要求提交用例清单（每行一个）。分析完成后输出汇总表，再逐条展开有条件/不批准项：

| 用例 | 分类 | 触发法规 | 关键条件/拒绝原因 |
|---|---|---|---|
| [名称] | 审批通过 | — | — |
| [名称] | 有条件审批 | 《生成式AI办法》§17 | 须完成服务备案 |
| [名称] | 不审批 | 《人脸识别办法》§10 | 唯一验证方式 |

---

## 免责声明

本技能输出的分类结论仅供内部合规参考，不构成法律意见。最终合规判断须由具有执业资格的律师审查确认。