Most small businesses cannot manage AI risk because they cannot answer a basic question: Where is AI actually being used?
The answer rarely sits in one system. A marketing team may use a writing assistant, customer support may switch on an AI feature inside its help desk, a manager may connect a meeting bot to calendars, and a developer may call a model through an API. Some tools are purchased centrally; others appear through free accounts, browser extensions or features added to software the company already owns.
An AI system inventory turns that scattered activity into a living register. It records each tool and use case, who owns it, what data it receives, what it produces, what it can do and when it must be reviewed.
NIST’s AI Risk Management Framework includes an explicit outcome for mechanisms that inventory AI systems and resource them according to risk priorities. A small business does not need enterprise governance software to begin. A controlled spreadsheet with clear owners, required fields and review triggers can be enough for a useful first version.
Key takeaway: Inventory the use case, not just the product name. The same AI service can be low risk when drafting generic social posts and much higher risk when it receives customer records or influences decisions about people.
What an AI system inventory is
An AI system inventory is a structured list of the AI-enabled systems and work practices an organization develops, buys, configures or uses. It includes obvious tools, such as a standalone chatbot, and embedded features, such as automatic summaries inside a customer relationship platform.
The inventory is not the same as an AI risk register. The inventory answers what exists, where it is used and who owns it. A risk register tracks specific risks, treatments, residual exposure and acceptance decisions. The two should link to each other, but combining them into one oversized sheet often makes both harder to maintain.
It is also not a one-time survey. AI products change quickly. Vendors add models, connectors and autonomous actions; employees discover new tools; pilot projects become business processes. A useful inventory therefore has a defined update owner and event-based review triggers.
Why small businesses need one now
An inventory creates four practical benefits.
Visibility. It reveals duplicate subscriptions, forgotten pilots and tools purchased outside the normal process.
Data control. It shows where customer information, confidential files, personal data or intellectual property may be sent.
Accountability. It assigns a named business owner instead of leaving responsibility with “IT” or an unnamed vendor.
Faster decisions. When a vendor changes its terms or a security issue appears, the company can identify affected workflows without interviewing every employee again.
The current search landscape reflects this operational intent. Results for “AI system inventory template” are dominated by ready-to-use registers that emphasize owners, vendors, purpose, data, risk tier and review dates. Readers are not looking for a conceptual essay alone; they want fields they can copy and a process that keeps the data current.
What belongs in the inventory
Include a record when software uses an AI model to create, classify, recommend, predict, decide, extract or act as part of work. That covers:
standalone chatbots and content tools;
AI features inside office, CRM, help-desk, HR, design or analytics platforms;
browser extensions and meeting assistants;
vendor systems that use AI behind the scenes for a business process;
internal models, automations and API integrations;
prototypes and time-limited pilots;
retired systems whose evidence must be retained.
Do not create a separate record for every casual prompt if the tool, purpose, data and controls are the same. Create a new record when the use case changes materially—for example, when a public writing assistant moves from generic ideation to processing customer support transcripts.
Copyable 20-field AI system inventory template
Use one row per distinct AI use case. These fields are intentionally practical for a small team.
| Field | What to record | Example |
|---|---|---|
| 1. System ID | Stable unique identifier | AI-014 |
| 2. Tool or system | Product or internal system name | Support summarizer |
| 3. Use case | Specific business task | Draft ticket summaries |
| 4. Business owner | Person accountable for the outcome | Support lead |
| 5. Technical administrator | Person who manages access or configuration | IT manager |
| 6. Vendor or developer | Provider or internal team | Vendor name |
| 7. Acquisition route | Approved purchase, embedded feature, free account, API or pilot | Embedded feature |
| 8. Users and team | Who can use it | 12 support agents |
| 9. Lifecycle state | Proposed, pilot, approved, restricted, suspended or retired | Pilot |
| 10. Intended inputs | Normal data supplied to the system | Ticket text |
| 11. Sensitive-data flag | Personal, confidential, regulated or credential data | Personal data: yes |
| 12. Output or action | What it produces or changes | Summary added to ticket |
| 13. People affected | Customers, employees, applicants, public or none | Customers |
| 14. Human review | Who checks output before use | Assigned agent |
| 15. Integrations and permissions | Apps, folders, connectors and action rights | Help-desk read/write |
| 16. Processing and retention | Known hosting, training-use and retention terms | Region and retention link |
| 17. Approved boundaries | Allowed tasks and data | Support tickets only |
| 18. Prohibited uses | Explicitly disallowed tasks | No account decisions |
| 19. Triage tier | Low, moderate, high or critical | Moderate |
| 20. Evidence and review | Approval link, last review, next review and open issues | Review due 2026-12-15 |
If one field regularly holds several unrelated facts, split it. For example, a growing company may separate “last review,” “next review” and “evidence link” into three columns. The important point is consistent ownership and controlled values, not an arbitrary column count.
A simple risk-triage calculation
A small business can prioritize review without pretending to perform a full risk assessment. Score four factors from 0 to 3:
Impact: 0 = internal convenience; 3 = materially affects a person, money, safety, employment or access to a service.
Data sensitivity: 0 = public or synthetic; 3 = highly confidential, credential, sensitive personal or regulated data.
Autonomy: 0 = suggestion only; 3 = the system can take consequential action without a person confirming each step.
External exposure: 0 = isolated internal use; 3 = public-facing, shared with third parties or connected to external accounts.
Triage score = Impact + Data sensitivity + Autonomy + External exposure
| Score | Working tier | Minimum response |
|---|---|---|
| 0–3 | Low | Owner approval and annual review |
| 4–6 | Moderate | Data and security review; review every six months |
| 7–9 | High | Cross-functional approval, testing and quarterly review |
| 10–12 | Critical | Pause by default; specialist legal, security and operational review |
This score is a queueing tool, not a compliance determination. A single red flag—such as processing credentials or making an unreviewed decision about a person—can justify escalation even when the arithmetic produces a lower number.
How to discover shadow AI
Shadow AI is work-related AI use that has not entered the organization’s approval or inventory process. Discovery should be transparent and proportionate, not a surprise surveillance exercise.
Start with five sources:
Team interviews: Ask what tools employees use, what problem each solves and what data goes in.
Expense and subscription records: Look for individual purchases, reimbursements and duplicate AI subscriptions.
Browser and identity administration: Review approved application lists, single sign-on assignments and extensions where company policy permits.
Existing software: Ask major vendors which AI features are enabled by default, optional or newly added.
Workflow observation: Map how a task moves from source data to final decision; AI may appear inside a step even when nobody bought an “AI tool.”
Create a short disclosure route that does not punish employees for reporting a useful unapproved tool. If disclosure automatically triggers blame, people will hide use and the inventory will be less accurate.
Build the inventory in six steps
. Define scope and ownership
Name one inventory steward and one executive sponsor. Define AI broadly enough to capture embedded features and vendor services, but keep the register focused on work uses rather than every algorithm in ordinary software.
Write simple inclusion rules. For example: “Record any tool or feature that generates content, predicts, recommends, classifies, decides or acts using an AI model and is used with company work or data.”
. Collect tools and use cases
Send a short survey to team leads and combine the responses with purchasing, identity and vendor information. Record the task, not just the brand. A single vendor may need multiple rows when different teams use it with different data and controls.
Do not wait for perfect information. Mark uncertain fields as “unknown—owner action required” rather than guessing. Unknown processing location or retention is itself a review issue.
. Validate data and permissions
Meet the business owner and technical administrator. Confirm actual inputs, outputs, integrations, user groups and action rights. Distinguish what the vendor contract permits from what employees are doing in practice.
For generative AI, check whether prompts or uploaded files may be retained, reviewed by people or used to improve models. For agents, list every connector and whether it can read, create, modify, send or delete.
. Assign a triage tier
Apply the four-factor score, then use professional judgment. Systems affecting employment, eligibility, health, safety, legal rights or essential services need specialist review. Small businesses should not use the template as proof that a high-stakes use is safe or lawful.
. Decide and document
Use clear states: proposed, pilot, approved, restricted, suspended and retired. Link each decision to evidence such as a vendor review, test results, data-protection assessment, security approval or policy exception.
Approval should name boundaries. “Approved” is too vague; “approved for drafting internal product descriptions from public specifications, with human review and no customer data” is operational.
. Review and retire
Review on a schedule and when something changes. Useful triggers include a new model, connector, data category, business process, user group, public interface, autonomous action, vendor term or reported incident.
Retirement is a workflow, not a status label. Remove accounts and integrations, revoke tokens, export required evidence, confirm deletion or retention obligations, update downstream procedures and record the retirement date.
Three worked examples
| Use case | Factor scores: impact / data / autonomy / exposure | Total | Initial tier |
|---|---|---|---|
| Public-product social captions | 1 / 0 / 0 / 2 | 3 | Low |
| Customer-support ticket summaries | 2 / 2 / 1 / 1 | 6 | Moderate |
| Automated applicant approval or rejection | 3 / 3 / 3 / 2 | 11 | Critical |
The table shows why the product name alone is insufficient. The first two rows could use the same model, yet the data, affected people and degree of automation produce very different review priorities.
Common mistakes
Listing vendors instead of use cases. This hides material differences in data and impact.
Ignoring embedded AI. The most consequential feature may arrive inside software the company already trusts.
Leaving ownership with IT. Technical administration and business accountability are different roles.
Treating “no personal data” as proof of low risk. Confidential strategy, source code or autonomous actions can still create high exposure.
Inventing details to complete the sheet. Unknown terms should produce a question for the vendor or owner, not a fictional answer.
Never closing records. Retired tools need access removal and evidence retention, not silent deletion from the inventory.
A 30-day rollout plan
Days 1–5: Define scope, fields, state labels and owners. Create the spreadsheet and two sample records.
Days 6–12: Survey teams and review subscription, identity and vendor-feature lists. Capture uncertain entries without scoring them yet.
Days 13–20: Validate the highest-impact and highest-data uses first. Record connectors, human review and processing terms.
Days 21–26: Apply the triage method. Approve bounded low-risk uses, assign actions for moderate uses and escalate high or critical ones.
Days 27–30: Publish a short intake form, set review reminders and report gaps to leadership. Track coverage as validated active records ÷ discovered active records × 100. A rising coverage rate is more useful than claiming the inventory is “complete” forever.
Frequently asked questions
Is an AI tool the same as an AI system?
Not always. A tool is a product or component. An AI system includes the tool, configured use case, users, data, integrations, human oversight and operating process. Inventorying the system gives better visibility than listing product names alone.
Should free browser-based AI tools be included?
Yes, when they are used for company work or data. Record the use even if there is no paid contract. Free accounts can still create data, confidentiality and access risks.
How often should the inventory be reviewed?
Set a risk-based schedule and review immediately after material changes. A practical starting point is annual for low-risk uses, six-monthly for moderate uses and quarterly for high-risk uses, with event-triggered reviews for all tiers.
Who should own the inventory?
One person should steward the register, but each record needs a business owner. In a small company, the steward may be the operations, security, privacy or IT lead. Leadership should sponsor the process and resolve exceptions.
Is a spreadsheet enough?
It can be enough for an initial inventory if access, required fields, controlled values and review reminders are managed. Move to a database or governance platform when the sheet becomes difficult to validate, link to evidence or audit.
Does this template prove compliance with AI laws?
No. It supports visibility and triage. Legal duties vary by jurisdiction, role and use case. Obtain qualified advice for regulated or high-impact deployments.
