ai-inventory

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/ai-inventory

/ai-inventory

When this runs

触发场景

The user wants to manage their AI system inventory under the EU AI Act. The core idea the skill exists to enforce: role and tier are per-system, not per-company. A single organization can be a provider of System A, a deployer of System B, and an importer of System C. Each combination triggers a different set of obligations under the AI Act. The inventory exists so those assessments are tracked where you can find them — the obligations themselves are derived in conversation, not from a table.
用户希望在欧盟AI法案框架下管理其AI系统库存。本技能的核心执行原则:角色和等级是针对单个系统而非公司的。同一机构可能是系统A的provider、系统B的deployer,同时也是系统C的importer。每种组合在AI法案下对应的义务各不相同。库存的作用是追踪这些评估结果,便于查询——而义务本身需通过对话推导,而非从表格中直接获取。

What to do

操作步骤

  1. Read the config. Read
    ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md
    . If it doesn't exist or still has
    [PLACEHOLDER]
    markers, direct the user to
    /ai-governance-legal:cold-start-interview
    first.
  2. Read the inventory. Inventory lives at
    ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/ai-systems.yaml
    . If it doesn't exist, create it with an empty
    systems:
    list when the first
    add
    runs.
  3. Dispatch on the argument:
    • No argument, or
      list
      → show the inventory table (see List below).
    • add
      → run the Add flow.
    • edit <id>
      → show the current record, ask what to change, update one field, confirm, write.
    • classify <id>
      → run the Classification walk-through on an existing record, updating role, tier, role_basis, and tier_basis.
    • show <id>
      → show the full record.
  4. On list, offer the dashboard: "Want the full dashboard? Filter by status / tier / EU nexus / owner. Say the word."
  5. Close every action with a hook into the lawyer's work. After any write, say:
    Recorded. When you're ready to walk through obligations for this system, just ask — I'll do it in-conversation and flag where the AI Act article mapping needs your verification. I don't derive obligations from a table because the mapping is complex and changing.
  1. 读取配置文件:读取
    ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md
    。若文件不存在或仍包含
    [PLACEHOLDER]
    标记,先引导用户执行
    /ai-governance-legal:cold-start-interview
  2. 读取库存文件:库存存储于
    ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/ai-systems.yaml
    。若文件不存在,在首次执行
    add
    操作时创建该文件,并初始化空的
    systems:
    列表。
  3. 根据参数执行对应操作
    • 无参数或参数为
      list
      → 展示库存表格(详见下方列表格式)。
    • 参数为
      add
      → 执行添加流程
    • 参数为
      edit <id>
      → 展示当前记录,询问需修改的内容,更新单个字段,确认后写入文件。
    • 参数为
      classify <id>
      → 对现有记录执行分级引导流程,更新role、tier、role_basis和tier_basis字段。
    • 参数为
      show <id>
      → 展示完整记录。
  4. 展示列表时提供仪表盘选项: "需要查看完整仪表盘吗?可按状态/等级/欧盟关联度/负责人筛选。直接告知即可。"
  5. 所有操作结束后关联法务工作: 完成任何写入操作后,告知用户:
    已记录。当您准备梳理该系统对应的义务时,随时告知我——我会通过对话为您分析,并标记需要您验证的AI法案条款映射内容。我不会从表格中推导义务,因为条款映射复杂且处于动态变化中。

List format

列表格式

Render as a compact table:
IDNameOwnerStatusEU nexusRoleTierNext review
sys-001Resume screeningHR / Jamiein_productionyesdeployerhigh_risk2026-08-01
sys-002Email drafting assistantIT / Priyain_productionnodeployerlimited2026-12-01
Under the table, show counts by tier and a line: "N systems flagged for review within 30 days."
以紧凑表格形式展示:
ID名称负责人状态欧盟关联度角色等级下次审核时间
sys-001简历筛选HR / Jamiein_productiondeployerhigh_risk2026-08-01
sys-002邮件起草助手IT / Priyain_productiondeployerlimited2026-12-01
表格下方展示各等级的系统数量,并显示一行文字:"N个系统需在30天内审核。"

Add flow (interview)

添加流程(访谈式)

Ask, one field at a time (or accept a paste). The required fields are
name
,
owner
,
description
,
status
,
eu_nexus
. The rest can be deferred — say so explicitly: "you can come back to classification with
/ai-governance-legal:ai-inventory classify <id>
."
  1. Name. Short label for the system.
  2. Owner. Person or team accountable for it day-to-day.
  3. Description. One or two sentences. What does it do, and against what data?
  4. Status.
    planned | in_development | in_production | deprecated
    .
  5. EU nexus. Is the system deployed in the EU/EEA, offered to users in the EU/EEA, or used to produce outputs that affect people in the EU/EEA? If any of these are true, EU AI Act analysis applies.
  6. Proceed to classification? Offer to run the walk-through now, or skip and come back later.
Assign an ID:
sys-NNN
where NNN is the next integer in the file.
逐个字段询问(或接受批量粘贴)。必填字段为
name
owner
description
status
eu_nexus
。其余字段可延后补充——需明确告知用户:"您可后续通过
/ai-governance-legal:ai-inventory classify <id>
完成分级。"
  1. 名称:系统的简短标识。
  2. 负责人:日常负责该系统的人员或团队。
  3. 描述:1-2句话说明系统功能及处理的数据类型。
  4. 状态
    planned | in_development | in_production | deprecated
  5. 欧盟关联度:该系统是否在欧盟/欧洲经济区部署、向欧盟/欧洲经济区用户提供,或其输出会影响欧盟/欧洲经济区的人员?若任一情况为真,则需适用欧盟AI法案分析。
  6. 是否立即进行分级? 提供选项:立即执行分级引导流程,或跳过后续再处理。
为系统分配ID:
sys-NNN
,其中NNN为文件中的下一个整数序号。

Classification walk-through

分级引导流程

The walk-through produces
role
,
role_basis
,
tier
,
tier_basis
. Both bases are tagged
[verify against current AI Act text]
— not because the skill is hedging, but because the article mapping is complex and the AI Act is still phasing in. The lawyer owns verification.
该流程将生成
role
role_basis
tier
tier_basis
字段。两个basis字段均需标记
[verify against current AI Act text]
——并非技能存疑,而是因为条款映射复杂,且AI法案仍在分阶段实施中,最终验证需由法务人员完成。

Step 1: Role

步骤1:确定角色

Who does what to this system?
Options, with the distinguishing test:
  • Provider — you develop it (or have it developed) and place it on the EU market or put it into service under your own name or trademark.
  • Deployer — you use it under your own authority, not for personal non-professional use. (Most common inside companies.)
  • Importer — you bring an AI system into the EU from a provider established outside the EU.
  • Distributor — you make an AI system available on the EU market without being the provider or importer.
  • Authorized representative — you act on behalf of a non-EU provider and are established in the EU.
  • Product manufacturer — you put a general-purpose AI system (or another AI system) into a product under your own name/trademark. Treated as provider for the product.
Dual-role flag. If the user substantially modifies a vendor system (fine-tunes on their own data, changes the intended purpose, rebrands), they may become a provider of the modified system even if they started as a deployer. Call this out when they describe any modification beyond configuration.
[verify against current AI Act text — Article 25, provider obligations and substantial modification]
Write the role. Write
role_basis
in one sentence.
您在该系统中承担什么角色?
选项及区分标准:
  • Provider — 您开发(或委托开发)该系统,并以自身名义或商标将其投放欧盟市场或投入使用。
  • Deployer — 您在自身权限范围内使用该系统,且并非用于个人非专业用途。(企业内部最常见的角色。)
  • Importer — 您将来自欧盟外provider的AI系统引入欧盟。
  • Distributor — 您在欧盟市场提供AI系统,但并非该系统的provider或importer。
  • Authorized representative — 您代表欧盟外的provider开展业务,且自身位于欧盟境内。
  • Product manufacturer — 您将通用AI系统(或其他AI系统)集成到产品中,并以自身名义/商标推出该产品。在产品层面将被视为provider。
双角色标记:若用户对供应商系统进行实质性修改(如用自有数据微调、更改预期用途、重新品牌化),即使最初是deployer,也可能成为修改后系统的provider。当用户描述任何超出配置范围的修改时,需明确指出这一点。
[verify against current AI Act text — Article 25, provider obligations and substantial modification]
写入role字段。用一句话写入role_basis字段。

Step 2: Tier

步骤2:确定风险等级

What does the system do, and does the use case fall into a regulated category?
Check in order:
A. Article 5 prohibited practices.
[verify against current AI Act text — Article 5]
Summaries, not definitive text:
  • Subliminal or deceptive techniques materially distorting behavior
  • Exploiting vulnerabilities (age, disability, socio-economic status) to materially distort behavior
  • Social scoring by public authorities leading to detrimental treatment
  • Real-time remote biometric ID in publicly accessible spaces for law enforcement (narrow exceptions)
  • Biometric categorization inferring race, political opinions, union membership, religious or philosophical beliefs, sex life, or sexual orientation
  • Emotion recognition in the workplace or education (medical and safety exceptions)
  • Facial image database scraping from the internet or CCTV
  • Predictive policing based solely on personality traits
If matched → tier is
prohibited
. Flag the use case as stop and route to the governance team's prohibited-practice workflow.
B. Annex III high-risk areas.
[verify against current AI Act text — Annex III]
Summaries:
  1. Biometric identification and categorization
  2. Critical infrastructure (digital infrastructure, road traffic, supply of water / gas / heating / electricity)
  3. Education and vocational training (access, evaluation, proctoring, monitoring prohibited behavior)
  4. Employment, worker management, self-employment access — recruitment, selection, promotion, termination, task allocation, monitoring, performance
  5. Essential private and public services (public benefits, credit scoring for individuals, risk assessment and pricing for life/health insurance, emergency dispatch)
  6. Law enforcement (risk assessment, polygraphs, deepfake detection, reliability of evidence, profiling)
  7. Migration, asylum, border control (risk assessment, travel document verification, examination of applications)
  8. Administration of justice and democratic processes (research and interpretation, influencing elections)
If matched → tier is
high_risk
. Note the Annex III area and subsection.
C. GPAI.
[verify against current AI Act text — Article 51 and surrounding]
  • GPAI: model trained on broad data at scale, designed for generality, capable of competently performing a wide range of distinct tasks.
  • GPAI + systemic risk: cumulative compute > 10^25 FLOPs, or designated by the Commission.
D. Limited risk. Chatbots interacting with natural persons, deepfakes, emotion recognition and biometric categorization systems outside Article 5 scope — transparency obligations apply.
E. Minimal risk. Everything else.
Write the tier. Write
tier_basis
in one sentence, citing the article or Annex entry that matched, tagged
[verify against current AI Act text]
.
该系统的功能是什么?其使用场景是否属于受监管范畴?
按以下顺序排查:
A. 第5条:禁止性实践
[verify against current AI Act text — Article 5]
概述(非法定原文):
  • 使用潜意识或欺骗性手段实质性扭曲行为
  • 利用(年龄、残疾、社会经济地位等)脆弱性实质性扭曲行为
  • 公共机构进行社会评分并导致不利待遇
  • 执法部门在公共可访问区域实时远程生物识别身份(极窄例外情况)
  • 通过生物识别分类推断种族、政治观点、工会成员身份、宗教或哲学信仰、性生活或性取向
  • 在工作场所或教育场景中进行情绪识别(医疗和安全例外情况)
  • 从互联网或闭路电视中抓取人脸图像数据库
  • 仅基于人格特征的预测性警务
若匹配 → 等级为
prohibited
。标记该使用场景需立即停止,并引导至治理团队的禁止性实践工作流程。
B. 附件III:高风险领域
[verify against current AI Act text — Annex III]
概述:
  1. 生物识别与分类
  2. 关键基础设施(数字基础设施、道路交通、水/气/暖/电供应)
  3. 教育与职业培训(准入、评估、监考、违规行为监控)
  4. 就业、员工管理、自雇准入——招聘、选拔、晋升、解雇、任务分配、监控、绩效评估
  5. 重要私人与公共服务(公共福利、个人信用评分、人寿/健康保险风险评估与定价、紧急调度)
  6. 执法(风险评估、测谎、深度伪造检测、证据可靠性分析、画像)
  7. 移民、庇护、边境管控(风险评估、旅行证件验证、申请审核)
  8. 司法与民主程序管理(研究与解读、影响选举)
若匹配 → 等级为
high_risk
。记录匹配的附件III领域及子项。
C. GPAI
[verify against current AI Act text — Article 51 and surrounding]
  • GPAI:基于大规模通用数据训练的模型,设计用于通用场景,能够胜任多种不同任务。
  • GPAI + 系统性风险:累计计算量>10^25 FLOPs,或由欧盟委员会指定。
D. 有限风险:与自然人交互的聊天机器人、深度伪造、第5条范畴外的情绪识别和生物识别分类系统——需遵守透明度义务。
E. 极低风险:所有其他场景。
写入tier字段。用一句话写入tier_basis字段,并引用匹配的条款或附件条目,标记
[verify against current AI Act text]

Step 3: Recommendations

步骤3:后续建议

Offer three next steps:
  1. "Want me to walk through obligations for this system? I'll do it in conversation — I don't derive them from a table."
  2. "Want to run
    /ai-governance-legal:aia-generation
    to produce a full impact assessment?"
  3. "Want to set a next review date? I'll add it to the inventory."
提供三个后续选项:
  1. "需要我为您梳理该系统对应的义务吗?我会通过对话为您分析——不会从表格中推导。"
  2. "需要执行
    /ai-governance-legal:aia-generation
    生成完整的影响评估报告吗?"
  3. "需要设置下次审核时间吗?我会添加到库存中。"

Record format

记录格式

yaml
systems:
  - id: sys-001
    name: "Resume screening tool"
    owner: "HR / Jamie"
    description: "Filters inbound CVs against job criteria"
    status: in_production          # planned | in_development | in_production | deprecated
    eu_nexus: true                 # deployed, offered, or affects people in the EU/EEA
    role: deployer                 # provider | deployer | importer | distributor | authorized_rep | product_manufacturer
    role_basis: "We license from VendorX and deploy internally [verify against current AI Act text]"
    tier: high_risk                # prohibited | high_risk | limited | minimal | gpai | gpai_systemic
    tier_basis: "Annex III(4)(a) — employment, recruitment selection [verify against current AI Act text]"
    obligations_assessed: false
    obligations_note: "To assess: as deployer of a high-risk system — human oversight, input data quality, monitoring, record-keeping, informing workers, FRIA if public body/service — see Article 26 [verify against current AI Act text]"
    next_review: "2026-08-01"
    review_trigger: "on substantial modification or annually"
    created: "2026-05-11"
    updated: "2026-05-11"
yaml
systems:
  - id: sys-001
    name: "Resume screening tool"
    owner: "HR / Jamie"
    description: "Filters inbound CVs against job criteria"
    status: in_production          # planned | in_development | in_production | deprecated
    eu_nexus: true                 # deployed, offered, or affects people in the EU/EEA
    role: deployer                 # provider | deployer | importer | distributor | authorized_rep | product_manufacturer
    role_basis: "We license from VendorX and deploy internally [verify against current AI Act text]"
    tier: high_risk                # prohibited | high_risk | limited | minimal | gpai | gpai_systemic
    tier_basis: "Annex III(4)(a) — employment, recruitment selection [verify against current AI Act text]"
    obligations_assessed: false
    obligations_note: "To assess: as deployer of a high-risk system — human oversight, input data quality, monitoring, record-keeping, informing workers, FRIA if public body/service — see Article 26 [verify against current AI Act text]"
    next_review: "2026-08-01"
    review_trigger: "on substantial modification or annually"
    created: "2026-05-11"
    updated: "2026-05-11"

Why this skill does NOT auto-derive obligations

本技能不自动推导义务的原因

The inventory stores role, tier, and the basis for each. It does NOT contain a hardcoded role × tier → obligations table.
When the user asks "what are my obligations for System X?", the skill does the analysis in conversation, tagged
[verify]
, and routes to
/ai-governance-legal:aia-generation
for the formal impact assessment if needed.
This is deliberate:
  • Article mapping is complex and the AI Act is phasing in through 2027.
  • Confident-and-wrong on a compliance obligation ends up in a board memo.
  • The inventory is a registry for the lawyer. The lawyer owns the obligation analysis.
库存存储角色、等级及对应的依据,但不包含硬编码的角色×等级→义务映射表
当用户询问“系统X对应的义务是什么?”时,技能将通过对话完成分析,标记
[verify]
,并在需要时引导至
/ai-governance-legal:aia-generation
生成正式的影响评估报告。
此设计是有意为之:
  • 条款映射复杂,且AI法案将逐步实施至2027年。
  • 若对合规义务做出错误的确定性判断,可能会被纳入董事会备忘录。
  • 库存是供法务人员使用的注册系统,义务分析的最终责任归法务人员所有。

Guardrails

约束规则

  • Never classify silently. The classification walk-through must be visible; do not auto-classify from a system description.
  • [verify]
    tags stay.
    They are not hedging — they are the point. Do not strip them in outputs.
  • Flag substantial modification. Whenever a system is modified beyond configuration, prompt the user to re-run
    /ai-inventory classify
    — modification can change role.
  • Don't declare obligations from a table. If asked, do the analysis in conversation and route to
    /aia-generation
    for anything that needs a formal record.
  • 禁止静默分级:分级引导流程必须可见,不得仅通过系统描述自动完成分级。
  • 保留
    [verify]
    标记
    :这些标记并非含糊其辞,而是核心要求。输出时不得移除。
  • 标记实质性修改:每当系统被修改超出配置范围时,提示用户重新执行
    /ai-inventory classify
    ——修改可能导致角色变更。
  • 禁止从表格推导义务:若被询问,需通过对话完成分析,并引导至
    /aia-generation
    生成任何需要正式记录的内容。