CloseIT  /  AI governance · Shadow AI
AI governance · Inventory

You can’t govern AI you can’t see

Someone asked how many AI systems the company runs, and the honest answer was a spreadsheet nobody trusts. Here is why every hand-maintained AI register decays, where AI actually hides, and the pattern that keeps a list honest without policing anyone.

Short answer

The gap between your AI register and reality is not a discipline problem. A register maintained by hand is a snapshot, while AI arrives through the ordinary flow of work — vendor releases, team sign-ups, pilots that never ended. Nothing in that flow forces the list to update. The fix is structural: discovery → human triage → a living registry, where adding a system is part of introducing it rather than a favour to the compliance team.

Why the spreadsheet is already wrong

Most AI inventories start the same way: a request from the board or an auditor, a round of emails, a tab per department, a list. The list is accurate for roughly as long as it takes to circulate it. That is not carelessness — it follows from how the list is produced.

Where AI actually hides

“Shadow AI” suggests something furtive. In practice it is almost always mundane, and it clusters in five places:

WhereWhat it looks likeWhy it stays invisible
Vendor features you already pay forAn AI assistant, summariser or triage feature enabled in a SaaS tool by a releaseNo purchase, no project, no ticket — nothing that triggers a review
Team-level sign-upsA low-cost tool paid on a card or a free tier, adopted by one departmentBelow procurement thresholds, so it never reaches a central process
Pilots that never endedA proof of concept from two quarters ago, still running because it worksIt was approved as an experiment and was never re-classified as production
Model calls inside internal codeA script or service calling a model API with a key someone createdIt is engineering plumbing, not a system anyone thinks to register — and the riskiest kind: wire that API into a high-risk use, say screening job candidates, and under Article 25 of the EU AI Act your company can stop being a mere user and take on a provider’s obligations for the system it just built
Components nobody calls AIScoring, ranking, matching, forecasting or classification logic inside an existing productThe word “AI” was never used, so no AI question was ever asked

One more reason shadow AI is not a “wait for the high-risk deadlines” problem: transparency duties under Article 50 — chatbot disclosure, labelling of synthetic content — have applied since 2 August 2026 to systems of any risk category. A customer-facing chatbot a team switched on without telling anyone is not a future compliance question. It is a live one.

The last row matters most and gets the least attention. Scope questions in regulation and in audits follow what a system does and the context it does it in, not the vocabulary a team happens to use for it. A register built by asking people to list their AI tools will systematically miss that category.

The inventory question is not “which tools”, it is “which uses”. One vendor platform can hold three AI capabilities pointed at three different populations, with three different risk pictures. A register with one row per product hides exactly the distinctions that decide what applies.

Discovery → triage → registry

The pattern that holds up is a loop of three steps, and each step has a job the others cannot do.

1. Discovery: pull from sources that update themselves

Stop asking people what they remember and start reading records that change on their own: SaaS and vendor admin consoles (which AI features are enabled, per tenant and per project), expense and procurement data, cloud and model API usage, code repositories and dependency manifests, identity provider app lists. Add one deliberately low-friction route for people to declare something themselves — a form that takes a minute beats a policy nobody reads.

2. Triage: a person decides what it is

Discovery produces candidates, not answers, and plenty of noise. A human decides which candidates are real, what each one is used for, who owns it, and whether it matters. This is judgement work and it stays judgement work.

3. Registry: record the outcome so it survives

Each accepted candidate becomes an entry with an owner, a purpose, a status and a date. The entry carries its own history, so the next cycle can tell what changed. The register is honest when adding a system is a normal part of introducing it — not an extra task performed for someone else’s benefit.

Then the loop runs again. Discovery is never finished, because adoption is never finished.

The part you cannot automate

It is tempting to buy a scanner and declare the problem solved. Discovery tooling genuinely helps with reach, but three things stay human, and they are the three that decide whether the register is worth anything:

Free, no sign-up

Once you have the list, the next question is what attaches to each entry

The EU AI Act compliance checklist takes one system through classification and lists the obligations that follow, with the evidence each one expects. Run it on the two or three entries you are least sure about — it is the fastest way to find out whether your register is carrying a real question.

Open the checklist

The first step: one list with owners

Not a platform decision, not a tool selection. A first pass that takes days rather than a quarter:

  1. Define what you are counting, in one sentence, and write it down. Whatever the definition, it must be applied the same way twice or the list is not comparable over time.
  2. Harvest three sources you already have — vendor admin consoles, the expense ledger, and the model API accounts. That usually produces more candidates than the email round did.
  3. Give every entry an owner by name. An entry without an owner is a rumour. If no owner can be found, that is itself the finding.
  4. Mark the unknowns explicitly. “Suspected, unconfirmed” is useful information. Silent omission is not.
  5. Decide where the list will live next month. If the answer is a file on someone’s drive, you have rebuilt the thing that decayed.
Track this in your Jira

Put the registry where work already happens

Model Inventory for Jira makes each AI system a work item in the Jira your teams already use: owner, purpose, classification and status on the item, triage as normal workflow, and an immutable change history behind every edit. Discovery and judgement stay yours; what the inventory adds is that the answer lives where the work is, with dates attached, instead of in a file that ages quietly.

See how it works

FAQ

What is shadow AI?

AI in use inside the organisation that no central function knows about. Usually it arrives through ordinary routes — an enabled vendor feature, a team sign-up, a pilot that never stopped — rather than through anyone hiding anything. The risk is not the tool; it is that no owner, no assessment and no oversight attach to it.

Why do manual AI inventories go stale?

Because the list is maintained by a side activity while adoption is driven by the main one. Nothing in the normal flow of work forces an update, and a stale register produces no visible error — it fails silently, in front of an auditor or a customer.

How do you build an AI inventory that stays current?

Treat it as a loop: automated discovery from sources that update themselves, human triage for scope, ownership and materiality, and a registry that records the outcome with dates and history. Then run it again, because adoption does not stop.

This page is a practical explanation, not legal advice. Where regulatory scope is in question, confirm it against the official text of Regulation (EU) 2024/1689 and the rules that apply to your sector.