The AI inventory: find every AI tool in your company
October 22, 2026
Ask a business owner what AI their company uses and you'll usually get the tools they bought on purpose: the chatbot subscription, maybe the writing assistant. Ask their staff and a second list appears — the transcriber, the design tool, the free summariser, the AI features that quietly switched on inside the CRM. Both lists are incomplete, and the gap between them is where the risk lives, because every serious question about AI governance — from your own policy to a customer's due-diligence questionnaire to a certification review — starts with the same one: what AI do you use, and where? An AI inventory is the written answer. This post covers how to build one: where AI hides, what to record for each system, and how to keep it current without turning it into a project.
Quick answer
An AI inventory is a register: one row per AI system or AI feature in use, recording what it is, who owns it, what it's for, what data it touches, and when it was last reviewed.
Find the AI in four places: ask the staff (with no blame attached), check your identity/SSO and admin records, sweep expenses and subscriptions, and review the AI features inside software you already approved.
Record twelve fields per row — set out in the register template below. Tool, vendor, purpose and owner are the minimum; data types, training terms and human review are the fields every later question asks for.
Keep it alive with two habits: new AI gets a row before it gets used, and the whole register gets a review each quarter. An inventory from last year is a history document, not a control.
It's the foundation artifact: the self-assessment, a governance program, a customer questionnaire and a certification review all consume the same register.
Where AI hides
1. The tools people chose themselves
The largest category in most small businesses, and the one no dashboard shows you. Free chatbots, browser extensions, transcription and note-taking apps, image and writing tools — adopted individually because they solved a problem that week. This is shadow AI, and the only reliable discovery method is asking, with an explicit amnesty: the point of the inventory is the list, not discipline. Our shadow AI post covers the conversation itself; for the inventory, what matters is that every tool named gets a row, however unofficial it is.
2. AI features inside software you already bought
Your CRM summarises calls now. Your office suite drafts and rewrites. Your meeting platform transcribes and summarises by default. Your helpdesk suggests replies. None of these arrived as "an AI purchase," all of them process your data with AI, and vendors enable new features in updates your team accepted without a governance thought. Go through your existing stack vendor by vendor and ask one question of each: what does this product do with AI, on our plan, and can we turn it off? Each answer is a row — embedded features count as systems in the register, with the host product as the vendor.
3. The subscriptions on the company card
Expense claims, card statements and the procurement inbox catch what memory misses: the tool a departed employee signed up for, the pilot that never ended, the personal subscription being expensed monthly. If the business pays for it, it's in scope for the inventory, even if the answer turns out to be "nobody uses this anymore" — that row's action is cancellation, which is also a finding.
4. What your systems say
Your identity provider's connected-apps list, your email and collaboration admin panels, and browser-extension inventories on managed devices give you the mechanical cross-check against what people reported. Use them to complete the list, not to catch people out — the order matters, because you will need staff honesty again at the next quarterly review.
The register: what to record for every AI system
One row per system or feature. Twelve fields cover everything the frameworks, the questionnaires and your own future self will ask:
| # | Field | What to write |
|---|---|---|
| 1 | System / feature | The tool's name, or the AI feature and its host product ("call summarisation, in [CRM]") |
| 2 | Vendor | The company behind it — and the model provider behind them, if different and known |
| 3 | Purpose | What it's used for, in one plain sentence |
| 4 | Owner | The named person accountable for this use — not a team |
| 5 | Who uses it | Roles or teams, including whether customers interact with it directly |
| 6 | Data it touches | The categories: public, internal, client-confidential, personal information — and the most sensitive one wins |
| 7 | Plan and terms | Business or consumer tier; whether the vendor's terms exclude training on your data; DPA in place, yes/no |
| 8 | Human review | Where a person checks output before it takes effect — or "none," written honestly |
| 9 | Disclosure | Where users or customers are told AI is involved, if anywhere |
| 10 | Status | Approved, approved with restrictions, under review, or to retire |
| 11 | Risk note | One line: what goes wrong if this misbehaves, leaks or is switched off |
| 12 | Review date | When this row gets looked at again — quarterly for the register as a whole |
A starter version of this register is on our templates page. Twelve fields sounds like a lot until the first customer questionnaire arrives asking for nine of them; at small-business scale the whole register is a spreadsheet with ten to forty rows.
Two fields deserve emphasis. Owner (field 4) is the one most registers get wrong by naming a department — when something goes wrong with a row, a person has to be able to pause it. And plan and terms (field 7) is where shadow AI's risk actually sits: the same tool on a consumer account and a business account is two different data arrangements wearing one name, and the register is where that distinction stops being invisible.
Sorting what you find
A first inventory usually produces three piles:
Approve: real work, acceptable terms, an owner willing to own it. Most rows land here once they're on business accounts.
Restrict: keep the tool, fence the use — approved for internal drafting, not for client data; or the feature stays on, but only for teams whose work isn't confidential.
Retire: the tool nobody can justify, the duplicate, the consumer account holding client information. Retire means migrate the use to the approved alternative first, then close the account — in that order, or the use goes back underground.
Record the decision in the status field with a date. The register becomes your evidence that discovery led to judgement, which is what separates an inventory from a list.
Keeping it current
Inventories rot in two predictable ways: new tools arrive without rows, and rows outlive the tool. Two habits prevent both. First, a row before use: the route for adopting any new AI — however small — is adding its row (fields 1–7 take minutes) and getting the owner's approval; that single gate is most of an AI policy's practical force. Second, the quarterly review: an hour with the register — new rows, retired rows, review dates, any incidents since last time. This is the same rhythm as the minimum viable governance program, because the register is that program's central artifact.
Why the frameworks all start here
This isn't housekeeping for its own sake. NIST's AI Risk Management Framework calls for organizations to maintain an inventory of their AI systems and set the level of risk-management activity for each — the register is that call, answered. An ISO/IEC 42001 program expects you to show which AI systems are in scope, with owners, because the scope statement an auditor tests against is built from exactly this list. Customer AI questionnaires open with the inventory question (our guide to answering them starts there too). And the Ethicality AI Use Standard (EAUS) assesses how an organization actually uses AI — disclosed use, a human responsible for important decisions, confidential information protected — which cannot be evidenced for systems nobody has written down. Build the inventory once and four different audiences read from the same page. Start with the free self-assessment if you want to see how your current state scores before you build, or build first and assess after — the order matters less than the register existing.
Frequently asked questions
Does an AI feature inside our existing software really need its own row?
Yes — as a row naming the feature and its host product. The feature processes your data under the vendor's AI terms, which may differ from the host product's general terms, and it can be enabled, changed or retired independently of the product around it. If it summarises your client calls, it is an AI system in your business whether or not anyone "bought AI."
How do we inventory AI in products where the vendor won't say what's inside?
Record what you know and mark the gap: vendor, feature as described, data it touches, "model provider not disclosed by vendor" in the terms field. A register that honestly records an unknown is more useful — to you, and to any reviewer — than one that pretends completeness. The gap itself often drives the next vendor conversation or the renewal decision.
What about personal AI use on personal devices?
If it's used for work, it belongs on the register — with the owner being the person using it and the plan field reading "personal account," which is usually the finding that gets it migrated to a business account or retired. The inventory records reality; the status field is where you record what you're doing about it.
How detailed should the register be for a very small business?
Fields 1–7 for every row, the rest for anything touching client or personal data. A six-row register that is accurate beats a forty-field register abandoned in February. You can deepen rows as questions arrive — customer questionnaires have a way of telling you exactly which fields to add next.
Is the register itself sensitive? Who should see it?
Treat it as an internal document: it maps your tooling and your data flows, which is useful information for the wrong reader too. Keep it access-controlled like other internal registers. What you share externally are extracts — the rows relevant to a customer's work, or the summary a certification review asks for — not the whole file by default.
How does the inventory feed certification?
Directly. A certification assessment against EAUS examines your actual AI use; an applicant with a current register has already assembled the core evidence, which is part of why the application takes about ten minutes and decisions land within five business days. Applicants without one can still apply — but they'll be building the list during the process instead of before it.
One list, kept current
Every governance obligation in this space is downstream of a deceptively plain question: what AI do you use? The inventory is the answer, built once from asking, checking and writing it down — then kept true by a gate for new tools and an hour each quarter. Download the register structure from templates, run the discovery this week, and you have the foundation the rest of the program — policy, questionnaires, certification — stands on. When you're ready to have the result checked, get certified.