Ai InventorySAFE

A suite of plugins for legal workflows

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: ai-inventory
description: >
  EU AI Act per-system inventory — track each AI system's role (provider,
  deployer, importer, distributor, authorized representative, product
  manufacturer) and risk tier (prohibited, high-risk, limited, minimal,
  GPAI, GPAI+systemic). Role and tier are assessed per system, not per
  company. Use when the user says "ai inventory", "add an ai system",
  "what systems do we have", "classify this ai system", "eu ai act
  register", or "ai system registry".
argument-hint: "[list | add | edit <id> | classify <id> | show <id>]"
---

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

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

## List format

Render as a compact table:

| ID | Name | Owner | Status | EU nexus | Role | Tier | Next review |
|----|------|-------|--------|----------|------|------|-------------|
| sys-001 | Resume screening | HR / Jamie | in_production | yes | deployer | high_risk | 2026-08-01 |
| sys-002 | Email drafting assistant | IT / Priya | in_production | no | deployer | limited | 2026-12-01 |

Under the table, show counts by tier and a line: "N systems flagged for
review within 30 days."

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

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

### Step 1: Role

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

### Step 2: Tier

> **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
- Soci

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.

[![ModelsAtlas audit: Ai Inventory](https://modelsatlas.com/skills/anthropics/ai-inventory/badge.svg)](https://modelsatlas.com/skills/anthropics/ai-inventory/)

Not your listing, or something out of date? Claim or update your listing.