grcskills
Menu

AI system inventory

Use this skill when a company needs to know what AI it builds, buys or uses, before an AI governance programme, an AI regulation review or a customer questionnaire, and asks "list our AI systems", "build an AI register", "AI inventory", "where are we using AI", "find shadow AI", "which of our vendors use AI" or "what AI do we have before the AI Act". Discovers AI systems from procurement, single sign-on, code and teams, records one entry per use case with owner, purpose, data, affected people and the company's role, and writes a CSV register plus notes of borderline cases and open questions.

AI systemsEU AI ActISO 42001

Use this when there is no AI register, or when the one that exists lists two tools and an internal model and nothing else. You get two files in a new folder, ./ai-system-inventory/: a spreadsheet you can open in Excel listing every use of AI in the company, one row per use, with its owner, the data it touches and who it affects (ai-register.csv), and a short notes document explaining what counts as AI, where each finding came from and the questions for each owner (inventory-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Every later AI governance step (classification, impact assessment, vendor review) reads this register, so a gap here is a gap everywhere.

Inputs to gather

Read before asking: the vendor or procurement list, expense or card exports for software, the single sign-on application catalogue, the product documentation and website feature pages, the code repositories the agent can reach, the data processing records, and any existing AI policy. Then ask the reader, in one message: which teams build or fine-tune models, which customer-facing features use AI, which teams are known to use AI tools without going through IT, and who will own the register.

Step 1: agree what counts as an AI system

Write the boundary test into the notes document (inventory-notes.md) before collecting anything. For the EU scope, use the definition in EU AI Act Art. 3(1) as the test: a machine-based system that infers from its input how to generate outputs such as predictions, content, recommendations or decisions, with some autonomy. Check the current consolidated text, since the Act was amended in 2026, and record in the notes which version you relied on. Rule-based scoring written by hand usually falls outside; a model trained on data usually falls inside. Record borderline cases with the reasoning instead of dropping them; a reviewer can move a borderline entry out later, but a missing entry stays invisible.

Step 2: discover from five sources

Search each source and tag every finding with where it came from:

  • Procurement and expenses: subscriptions to AI tools, and AI add-ons sold inside existing software (helpdesk, CRM, HR, recruiting, note-taking, meeting transcription).
  • Single sign-on and browser extensions: assistants and writing tools people connected themselves.
  • Code: model provider SDKs, calls to model APIs, model files, vector databases, notebooks, fine-tuning jobs.
  • Product: features described as smart, predictive, generated or automated on the website and in release notes.
  • People: ask two or three team leads per department what they use AI for. This is where shadow use shows up.

AI features switched on inside software the company already pays for are the most common miss. Check the release notes of the ten largest suppliers.

Step 3: record one entry per use case

Each entry is a row in the register spreadsheet (ai-register.csv). The unit is the use case, not the vendor. The same assistant used for drafting marketing copy and for screening job applicants is two entries, because the people affected and the risk differ. For each entry fill:

  • id, name, short description, source of discovery
  • owner role (a business owner who can stop the use, not "IT")
  • build, buy, or embedded in another product; vendor and underlying model where known
  • the company's role: for the EU AI Act, provider or deployer (Art. 3 defines both; Art. 25 says when a deployer becomes a provider); for the management system, run a framework lookup on the role terms it uses
  • purpose and the decision or output it feeds, and who acts on it; for customer-facing features, copy the company's own marketing or release-note wording, because that is what a regulator reads as the intended purpose
  • data in: personal data categories, customer data, confidential data; for built or fine-tuned models, where training data came from, any labelling vendor, and on what basis it was acquired
  • people affected: staff, customers, applicants, the public
  • level of autonomy: suggestion a human reviews, or output that acts without review
  • status: idea, pilot, production, retired; approved or discovered unapproved
  • whether it is used in, or affects people in, the EU
  • a classification flag left at "to classify" for the next step

Step 4: sanity checks and handover

  • Count entries by source. If everything came from procurement, engineering and shadow use were missed; go back to step 2.
  • Every unapproved discovery stays in the register, marked as such. Deleting it hides the risk without removing it.
  • Every owner role is a person who can approve or stop the use.
  • Reconcile both ways with the records of processing: every use case that touches personal data should appear there too, and a mismatch either way goes to the privacy owner.
  • List questions per owner in inventory-notes.md, and propose how the register stays current: a check at vendor onboarding, at feature launch, and a sweep each quarter that confirms each owner is still in post. Retired uses move to "retired" with a date instead of being deleted.

What good looks like

  • The first thing a strong practitioner checks is the embedded features: transcription in the meeting tool, ranking in the recruiting tool, auto-replies in the helpdesk. They are where people are affected and nobody asked.
  • The common mistake is a register of vendor names ("we use two chatbots and one model"). It cannot be classified, because risk depends on the use case, not the product.
  • The tell that it went wrong: no entry is marked discovered unapproved, every owner is IT, and nothing affects applicants or customers. Real companies always have at least one of each.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-ai-system-inventory

Rules

  • MUST record one entry per use case and cite the source of each discovery.
  • MUST keep discovered unapproved uses in the register, marked as such.
  • MUST write outputs only inside ./ai-system-inventory/ and ask before overwriting.
  • NEVER classify a system's legal risk level in this skill; leave it for the classification step.
  • NEVER switch off, block or report a tool or a person; the register informs owners, it does not act.
  • NEVER put names of individual users in the register; use roles and teams.