About
按系统逐一定义AI角色、风险等级和监管义务——判定每个系统是 AI服务提供者还是使用者，分配风险层级，并映射至中国AI法规 的义务要求。适用于建立AI系统清单、进行年度AI审计、或新法 规要求重新分类时。
/ai-inventory
- 读取
~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md→ 既有AI系统清单（如有）、监管注册表。 - 运行以下工作流。
- 对每个系统：描述功能 → 判定提供者/使用者角色 → 分配风险等级 → 映射监管义务。
- 输出系统级条目 + 汇总表。
/ai-governance-legal:ai-inventory "智能客服系统 v3"
/ai-governance-legal:ai-inventory --full
AI系统清单编制
目的
盘点你正在使用的每一件AI——作为提供者还是使用者，风险层级如何，受哪些法规约束。这是 use-case-triage（评估新事物）和 aia-generation（深度评估单个系统）的基础层。
加载当前状态
读取 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md：
## AI系统清单— 既有清单（如有）## 监管注册表— 适用法规及义务## 红线— 禁止的用例类别
单系统录入
当提供系统名称或描述时，运行单系统录入。
工作流
第1步：收集基本信息
如果用户提供的信息不足以填充以下字段，逐项询问：
| 字段 | 说明 | |------|------| | 系统名称 | 唯一标识符 | | 功能描述 | 一段话——系统做什么 | | AI技术类型 | 机器学习/深度学习/规则系统/大语言模型/计算机视觉/其他 | | 模型来源 | 自主研发/基于开源模型微调/第三方API/采购的商业产品 | | 部署方式 | 本地部署/私有云/公有云API/SaaS | | 数据处理 | 涉及的数据类别——是否包含个人信息、敏感个人信息、商业数据、公开数据 | | 受影响人群 | 内部员工/商业客户/公众用户/未成年人 | | 使用场景 | 内部辅助工具/面向客户的功能/面向公众的服务 | | 决策类型 | 非实质性（推荐、排序）/实质性（影响权利义务）/安全关键 |
第2步：判定角色
| 角色 | 判定标准 | |------|----------| | 提供者 | 自主研发并向他人（包括公司内部其他部门）提供AI服务 | | 使用者 | 使用第三方AI服务，不对外提供AI服务本身 | | 双重 | 基于第三方模型训练/微调后向外部提供服务 |
如果系统仅在公司内部使用且不向外部提供，则通常归为使用者（即使使用了内部数据）。但如果公司开发自己的模型/系统并向外部客户提供该系统的访问权限，则归为提供者。
灰色地带：使用LLM API构建的面向用户的功能——技术上使用了第三方模型，但你构建了应用层并向用户提供服务。此类情况通常归为"双重"角色：对用户来说你是提供者，同时你是底层模型的使用者。
第3步：分配风险等级
| 等级 | 定义 | 触发特征 | |------|------|----------| | 高风险 | 对权利和利益有实质性影响，或面向弱势群体，或安全关键 | 自动化决策影响信贷/就业/教育/保险；涉及敏感个人信息；面向未成年人；医疗/交通/基础设施安全场景 | | 中风险 | 面向公众但对权利无实质性影响 | 内容推荐/个性化；使用个人信息但非敏感；生成合成内容 | | 低风险 | 内部使用，不涉及个人信息，无外部影响 | 内部数据分析；非个人信息处理；生产力和效率工具 | | 不适用 | 系统中没有AI组件 | 纯确定性的自动化、传统软件 |
第4步：映射监管义务
基于角色和风险等级，确定义务：
| 法规 | 高风险 + 提供者 | 中风险 + 提供者 | 高风险 + 使用者 | 中/低风险 + 使用者 |
|------|----------------|----------------|----------------|-------------------|
| 生成式AI安全评估（《管理办法》第17条 [法条原文]） | ✅ 必须 | ✅ 必须 | ❌ 不直接 | ❌ 不直接 |
| 算法备案（《算法推荐管理规定》第24条 [法条原文]） | ✅ 必须（如适用） | ✅ 必须（如适用） | ❌ | ❌ |
| 科技伦理审查（《伦理审查办法》[法条原文]） | ✅ 必须 | ⚠️ 视具体场景 | ⚠️ 视具体场景 | ❌ |
| 个人信息保护影响评估（《个保法》第55条 [法条原文]） | ✅ 必须 | ✅ 必须 | ✅ 必须 | ⚠️ 视数据 |
| 算法推荐透明度（《算法推荐管理规定》第16条 [法条原文]） | ✅ 必须 | ✅ 必须 | ❌ | ❌ |
| 深度合成标识（《深度合成管理规定》第16条 [法条原文]） | ✅ 必须（如适用） | ✅ 必须（如适用） | ❌ | ❌ |
| 投诉举报机制（《管理办法》第15条 [法条原文]） | ✅ 必须 | ✅ 必须 | ❌ | ❌ |
第5步：输出单系统条目
### [系统名称]
**角色：** [提供者 / 使用者 / 双重]
**风险等级：** [高风险 / 中风险 / 低风险 / 不适用]
**状态：** [已部署 / 在评估 / 开发中 / 已退役]
| 属性 | 值 |
|------|---|
| 功能描述 | [一段话] |
| AI技术类型 | [类型] |
| 模型来源 | [来源] |
| 部署方式 | [方式] |
| 数据类别 | [类别列表] |
| 受影响人群 | [人群] |
| 面向对象 | [内部/客户/公众] |
| 决策类型 | [类型] |
**监管义务：**
| 义务 | 适用 | 状态 | 截止日期/完成日期 | 证据 |
|------|------|------|-------------------|------|
| [义务] | ✅/❌ | ✅已完成/⚠️进行中/❌未开始 | [日期] | [文档引用] |
全量审查 --full
当使用 --full 时，对 ## AI系统清单 中的每个系统运行单系统录入流程，此外：
- 交叉检查一致性：确保类似系统获得类似分类。当一个系统获得了与其他类似系统不同的风险等级时，标记并解释。
- 识别清单缺口：检查
## AI系统清单是否遗漏了实践中存在的AI系统（例如供应商审查中已批准但未列入清单的供应商系统）。 - 监管覆盖缺口：哪些法规适用于你的业务但你没有任何被分类为需要遵守该法规的系统？这是否合理？
全量审查汇总表
## AI系统清单汇总
**审查日期：** [日期]
**系统总数：** [N] | 提供者：[N] | 使用者：[N] | 双重：[N]
**按风险等级：** 高风险：[N] | 中风险：[N] | 低风险：[N]
| 系统 | 角色 | 风险等级 | 适用法规数 | 备案状态 | 上次评估 | 差距数 |
|------|------|----------|-----------|----------|----------|--------|
| [名称] | [角色] | [等级] | [N] | [状态] | [日期] | [N] |
## 监管覆盖缺口
| 法规 | 适用系统数 | 是否有覆盖缺口？ | 说明 |
|------|-----------|----------------|------|
| [法规] | [N] | 是/否 | [说明] |
## 不一致标记
[标记任何类似系统获得不同分类的情况，附说明]
输出
保存到 ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/outputs/ai-inventory-[日期].md。同时更新 ## AI系统清单 中的条目。
[工作成果头 — 按照插件配置 ## 输出]
与 use-case-triage 的衔接
use-case-triage 在系统进入开发之前评估新提议。ai-inventory 是为已存在（或即将部署）的系统创建记录。一个已通过分类的系统在部署前通常需要完成清单编制。当 triage 给出"附条件-高"分类时，应自动触发清单编制。
收尾
以 CLAUDE.md ## 输出 规定的下一步决策树收尾。定制选项：完成缺失系统的录入、处理不一致标记、填补监管覆盖缺口、升级至法律顾问。
本技能不做的事
- 不执行深度评估——那是
aia-generation的职责。此技能是对系统进行分类和分配义务，不做逐项条款的合规分析。 - 不做出"这个风险等级是正确的"的法律判断。分类基于当前法规和技术理解；当法规发生变化时，重新分类。
- 不替代网信办的官方分类——监管机构可能不同意你的风险等级判定。
