AI Tool Inventory

What an AI Tool Inventory is

An AI tool inventory is a single list of the AI tools actually in use across a business, who uses each one, what for and on what kind of data. The word actually matters. It is a record of what is happening, not of what was approved.

The site’s definition adds two things the list has to include: tools staff pay for themselves, and AI features switched on inside software the business already has. Both are easy to miss. Neither would appear on a purchase list.

The inventory is the starting point for everything else in governance. The governance article says governance starts with an inventory and not with a policy written against an assumption. This page explains why, what goes in the list, how to collect it and what it feeds.

Why it comes first

The governance article reports an estimate that 77% of small businesses using AI have no written AI policy at all. That covers guidelines on what data staff can share, a review step before output goes out, an approved tool list and a person formally responsible when something goes wrong.

The article’s point is that writing a policy faster does not solve this. A policy is solved by writing it against an accurate picture of what is happening, which is the step most organisations skip. Put to every team, one short question, what AI tools do you actually use, for what, and on what kind of data, usually returns an answer longer and more varied than leadership expects. It is the only foundation a policy can be built on and not guessed at.

The article puts the cost of skipping it in one line: a policy built on a guess gets rewritten within a month. A policy written after the conversation names the actual exposure. A policy written before it is, in the article’s words, a guess wearing the shape of a control.

What goes in the list

The ownership article describes the result as a single page. The minimum is tool, who uses it and what it is used for. The site’s definition adds the kind of data each use touches, and the ownership article’s one-page record, written in week three, adds what the tool can reach and the date of its next review.

A workable row therefore answers five questions:

1. What is the tool?
2. Who uses it?
3. What is it used for?
4. What data can it reach?
5. When was it last checked, and when is it next due?

Keep it short enough that it will be read. The ownership article says the same of the record: a long document that nobody opens is not a control.

Two rows deserve extra attention. The first is any use that is automating a decision and not merely a task. The ownership article says a tool that decides needs closer supervision than one that drafts, and that the record has to say who checks, and how often. The human in the loop page covers what a checkpoint has to be. The second is any process that only runs because one person knows something nobody else has had to explain. The governance article calls that a key-person dependency and says to log it in the same pass, and not discover it the day that person is unavailable.

What it has to include

The definition’s two inclusions are worth spelling out, because they are where lists fail.

Tools staff pay for themselves. Personal subscriptions and personal sign-ups do not show up in any purchase record. The governance article reports that 81% of employees and 88% of security leaders say they use unapproved AI tools at work, so a list built from approved tools alone leaves out a large share of real use. This is the shadow AI problem, and the inventory is how it becomes visible.

AI features inside software the business already has. The banning article notes that generative AI now sits inside email clients, meeting software, document editors and browsers, often switched on by default in products the business already pays for. A rule or a list that names only standalone AI apps has no clear edge. The inventory has to ask about features, not only products.

The governance article adds a further instruction on honesty: record the answer, including the tool a manager would rather not have mentioned. A list that leaves out the awkward entries is an inventory of what people are willing to say.

How to collect it

The ownership article gives week one of its thirty-day route to the list. The method is to ask people rather than scan accounts, and to make it plain that the aim is to understand use and not to punish it.

The banning article explains why the tone matters and adds a practical detail. It says to open each team conversation with the reassurance that nobody is being disciplined for an honest answer, and to mean it. The conversation also surfaces something a scan cannot: what the approved tool lacks. A team that says it uses a personal account for meeting summaries has told you what to fix. The article says that is more useful than a scan, and that it works on the accounts a scan cannot reach.

Asking every team the same question, in the same words, is what makes the answers comparable. The governance article says the list does not need software to run and does not need to be exhaustive on the first pass. It needs the same plain question put to every team and an honest record of the answers.

A worked example

This is an illustration, not a real client. A 25-person business asks each of its three teams the same question. The sales team names an assistant it pays for personally, used to draft follow-up emails from call notes. The finance team names an AI feature in its spreadsheet software that it had not thought of as AI. The operations team names a meeting summary tool on a personal account.

The one-page list now has three rows. Each shows the user, the purpose and the data. The sales row touches client names. The operations row touches client calls. The finance row touches supplier figures. Nobody had a full picture before. The business now has the starting point for a one-page rule, a named owner for each tool and a decision about whether the personal accounts should move to an approved route.

What the list feeds

The inventory is the first step in a sequence. Each step needs the one before it.

Risk classification. Each listed use is sorted by what could go wrong. The risk classification page covers the sort, and the governance article says a drafting assistant and a system that screens job applications are not the same problem.

Ownership. Each tool gets one named person with authority to pause it. The ownership article’s week two says to choose a person, not a team, and says that if nobody can be found who is willing to be accountable for a tool, that is a finding in itself and a reason to reconsider whether the tool should be in use. The AI ownership page covers the role.

Policy. The rules are written once the list exists. The banning article’s version is a one-page rule drawn by data and not by tool, with a short record of which tools and uses were approved and when. The AI governance page covers the policy.

The Act. A list of uses is what shows whether the business holds the deployer role for any high-risk system. The duties presume a named person, so the list and the owner come before the deadline.

Keeping it Current

A list written once goes stale. The ownership article puts a quarterly review in the calendar for each tool, and a second trigger for whenever the vendor announces a change to the model, the features or the terms. The banning article gives the reason: new tools and new features keep arriving, so a rule filed once goes stale within months.

The ownership article also describes why the tool itself does not stay as it was installed. The vendor updates the model behind it, the documents it draws on change, new features switch on and staff find uses nobody planned. The drift page covers what happens when nobody keeps looking. The review date on each row is the answer.

The ownership article reports a related figure: 70% of senior technology executives said teams were deploying technology faster than IT could track. A list with an owner and a review date is how a business keeps pace with that.

Using it with the team

An inventory is also a communication tool. The team-briefing article says that if an organisation already has an AI governance policy or an AI tool inventory, the briefing should say where each lives and who to ask. A list nobody knows about does not change what anybody does.

The tool-value article uses the list for a different purpose. It says that part of the difficulty in knowing whether a tool saves time is simply not knowing what is in use, and that a plain AI tool inventory is the quickest way to find out which tools are in play and which tasks they touch before you try to time any of them. The same list serves governance and measurement.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is listing only the approved tools. The second is scanning accounts and calling the result complete, when a scan misses personal accounts and the features inside existing software. The third is treating the list as a one-off, when it needs a review date. The fourth is writing the policy first and the list afterwards.

How we use it

The ownership article says an audit lists every tool in use, checks what each one handles and gives each one an owner and a review date. That is the inventory done across every team and not just one. The AI audit page sets out what it checks, and it is a diagnostic and not a legal opinion.

See AI governance for small and mid-sized businesses for why the list comes first, and what happens when nobody owns the AI you have rolled out for the thirty-day route. If you would rather have the whole estate mapped by someone outside the business, a discovery call is where it starts. Whichever route you take, the ownership article’s advice is to start with one name against one tool this week.

Sources

• AI governance for small and mid-sized businesses: why governance starts with an inventory, the 77% figure, the shadow AI figures and the key-person dependency.
• What happens when nobody owns the AI you have rolled out: the thirty-day route, the one-page record, the review rhythm and the 70% figure.
• Why banning AI tools at work does not work: AI inside existing software, asking before auditing and the one-page rule.
• Is your AI tool actually saving time? and How to brief a team on AI: using the list for measurement and for the team briefing.
• Risk classification, AI ownership and shadow AI: what the list feeds and what it brings into view.