Build a small-business AI inventory with named owners

Your business may use AI in more places than its owner can name. A writing feature inside an existing application, a saved prompt used by an assistant, and a workflow that classifies requests can all create operating dependencies. An inventory makes those uses visible so someone can answer what each one does, what information it receives, and who takes responsibility when it changes or fails.

The inventory should help people make decisions, rather than become a list of brand names. Start with actual business uses and give each a named owner. This guide provides a practical register, a discovery routine, and a hypothetical small-team example. You can maintain the register in a first-party spreadsheet or document without buying an AI governance product.

Inventory uses rather than just subscriptions

A single application may support several different tasks. Drafting marketing copy has different inputs and consequences from summarising a confidential customer request. Conversely, one business workflow may use multiple technical components. Listing each supplier once would hide both distinctions.

Create a separate inventory entry when the purpose, information, authority, or accountable owner differs materially. You do not need one entry for every individual prompt run. A stable use such as “prepare internal customer request summaries” can have a single entry with linked prompt versions and operating instructions.

Include experiments, paused workflows, and embedded features where they affect business information. Mark their status clearly. An experiment with synthetic material is different from an approved customer-facing process. A paused workflow may still have credentials, stored examples, or scheduled tasks that need attention.

Begin with a short discovery exercise

Ask staff which tasks they complete with AI and which applications now offer AI features. Frame the exercise around understanding work and providing useful boundaries. If people think the inventory exists only to assign blame, informal use may become harder to discover.

Review purchased subscriptions, browser-based tools used for work, existing workflow diagrams, training materials, and shared prompt documents. Ask the technical owner to identify automated jobs and credentials. Do not collect passwords or secret keys in the register; record where authorised administrators can manage them.

Trace a few ordinary tasks from start to finish. A colleague may say they “write the update,” while actually copying a customer thread into an AI drafting tool. The relevant inventory item is that information-processing use, not just the final document. The process mapping guide offers a useful way to uncover these hidden handoffs.

Use a register that supports operating decisions

Keep the first version compact enough to finish. The following fields provide a useful starting point. Add detail when it changes a decision, rather than filling the register with information nobody can maintain.

Record unknowns honestly. An empty or uncertain field should create a follow-up task with an owner, rather than a guessed answer. “Retention setting not yet confirmed” is more useful than “private” when nobody has checked the actual arrangement.

Assign ownership to a business role and a person

The business owner explains the task’s purpose, acceptable outcome, and decision limits. The technical owner maintains its configuration, access, and operating controls. The people can be the same in a small business, but both responsibilities should be explicit. The software supplier is not your internal process owner.

Name a backup and check that the backup can perform the necessary work. Being listed in a spreadsheet does not create access or knowledge. A backup should be able to find the current procedure, recognise the operating status, and activate the documented fallback without depending on the absent owner’s memory.

Use the small-business process owner guide to distinguish responsibility for outcomes from day-to-day task execution. Ownership should include deciding when the use is no longer needed. Otherwise, a temporary experiment can remain active simply because nobody considers retirement part of their job.

Describe information and access precisely

Avoid labels such as “customer data” without detail. Identify the fields or document types involved, whether real customer material is permitted, and which categories are excluded. A task may use only public product descriptions, synthetic training examples, or restricted support messages. Those are different information boundaries.

Record where input and output can appear, including logs, saved conversations, exports, and test examples. Link to the applicable settings or assessment rather than copying sensitive source material into the inventory. The register should help staff find the authorised information path without becoming a new confidential archive.

OWASP’s AI Agent Security Cheat Sheet discusses least privilege, memory controls, monitoring, and data protection for agents. For this register, the operating question is concrete: does this task have more access than its purpose requires? The AI tool permissions guide develops that question into a review routine.

Distinguish drafts from actions

State what the workflow can actually do. A draft assistant that cannot send a message differs from an assistant connected to a live outbound channel. A summary shown to a person differs from a value written directly into a customer record. Do not describe both as “helps with administration.”

List actions explicitly: read, propose, create a draft, update a record, send externally, release a file, or request a financial operation. Record where human approval is required and what evidence establishes approval. A setting that currently disables an action should be visible, along with who can enable it.

Flag consequential uses for the appropriate business and professional review. Do not turn an inventory into an automatic permission system based on one risk score. A small business still needs to understand context, contractual authority, confidentiality, and applicable rules. The register supports that decision; it does not make it by itself.

Record dependencies that can change behaviour

Identify the prompt or instruction version, model or service configuration, source collection, input form, output validation, and connected tools where relevant. A shared source document can affect several workflows. A model update can affect a use even when no staff member edits the prompt.

Link related entries to a common component reference. If three tasks rely on the same internal policy collection, record that relationship once and point each use to it. When the policy changes, the owner can find affected tasks instead of discovering them through inconsistent answers later.

The AI workflow change control guide explains how to manage these updates. The inventory’s role is to show which uses need attention and who should participate. It should not duplicate every test result, prompt revision, or technical log when those records already have a controlled home.

Work through a hypothetical five-person business

Imagine a five-person consultancy conducting its first inventory. The owner initially lists two AI subscriptions. The discovery exercise finds four uses: public marketing drafts, internal meeting action proposals, customer request summaries, and a trial document extraction process using synthetic files.

The team creates four entries. Marketing drafts have an editorial owner and may use approved public service descriptions. Meeting action proposals require attendees to verify assignments before tasks become commitments. Customer summaries are paused until the information boundary is reviewed. The extraction trial remains marked testing, with no permission to change operating records.

The register exposes a gap: nobody is responsible for a shared prompt document last edited by a former contractor. The owner assigns a review, removes obsolete instructions, and records a current version. It also reveals that the backup for meeting notes has no access to the procedure. That becomes a coverage task, rather than an assumption that “someone can handle it.”

This example is hypothetical. It illustrates useful inventory outcomes without claiming a measured productivity improvement. The immediate value is a clearer list of uses, owners, boundaries, and unresolved decisions. The team can then decide which uses should operate, remain in testing, or stop.

Prioritise unknowns without inventing precision

An inventory often begins with incomplete answers. Prioritise the questions that could change a material decision: whether restricted information is being copied, whether an action can occur externally, whether anyone can stop the task, and whether the use supports a consequential decision about a person or transaction.

Create a short action list linked to the relevant entry. Each task needs an owner and a review date. Avoid assigning every unknown a dramatic numerical score that implies precision you do not have. A plain reason such as “customer material in an unreviewed account” can make the next action clearer.

NIST’s AI Risk Management Framework is intended for voluntary use across AI design, development, use, and evaluation. The inventory worksheet here is an original business operating tool; completing it does not establish certification or prove that a use is appropriate. It makes the information needed for further decisions easier to find.

Build review into existing business routines

Choose a review cadence that fits the pace and consequences of change. Also define event triggers: a new AI feature, a new data category, an external action, a changed model, a departed owner, or a significant incident. A calendar reminder alone can miss the moment that a boundary actually changes.

Keep the review focused. Confirm that the use still exists, the owner and backup are correct, the current version is known, access fits the task, and unresolved actions have progressed. Ask operators whether they use the tool differently from the written description. Real working habits are more informative than a register that remains accurate only on paper.

Measure inventory health using useful gaps: entries without owners, overdue reviews, unknown permissions, missing fallback procedures, and retired uses with remaining access. Do not celebrate the number of entries as a success metric. A smaller, accurate inventory can serve the business better than an expansive list that nobody trusts.

Retire a use completely

Retirement involves more than changing the status field. Stop scheduled processing, remove unneeded access through the authorised administrator, identify stored material, and follow the applicable retention and deletion decisions. Preserve the limited evidence needed to explain earlier actions or obligations. Do not delete records blindly to make the entry disappear.

Update procedures and staff guidance so people do not continue using an old prompt or bookmark. Redirect pending work to the replacement or manual process. Check whether another workflow still depends on the retired component before removing shared access or source documents.

Record the retirement date, decision owner, remaining obligations, and evidence of completed actions. If a future colleague asks why a workflow stopped, they should find a clear explanation rather than an abandoned spreadsheet row. This also helps prevent old experiments from being restarted without reviewing their original limitations.

Use the inventory during staff and contractor changes

An owner leaving the business can reveal whether the register is an operating tool or merely a catalogue. Review the entries they own before access changes take effect. Identify pending cases, saved prompts, source collections, scheduled tasks, and administrative settings that the replacement must understand.

Transfer responsibility through a short practical exercise. Ask the incoming owner to locate the current procedure, describe the permitted inputs and actions, and explain how they would pause the use. If they cannot do those things from the linked records, improve the handover before assuming that changing a name in the register completes it.

Keep credentials out of the handover document. The authorised administrator should manage access through the actual account controls, while the register records the responsible role and management location. Shared personal logins can make it difficult to establish who changed a workflow or whether departed staff still have access.

Contractor changes deserve the same attention. A freelancer may have built an experiment in their own account or retained a working copy of source material. Clarify ownership, authorised copies, continuity, and removal through your agreement and appropriate process. Mark unresolved dependencies honestly so the business does not mistake a named replacement for a fully transferred capability.

Start with a one-hour first pass

Choose a short working session with the people closest to daily operations. List the uses, identify owners, describe the inputs and actions, and mark unknowns. Do not spend the entire session debating the perfect scoring system. The first useful deliverable is an honest register and a small list of decisions that need attention.

Then complete one entry end to end. Find its procedure, verify its configuration with the technical owner, check the fallback, and confirm the review route. Use what you learn to improve the worksheet before filling every possible field for every use. A register shaped by actual operating questions will be easier to maintain.

Your inventory is working when a new colleague can identify an AI use, understand its boundary, find its owner, and know what to do when it changes or fails. Maintain those answers as part of running the business, and the register becomes a practical map of responsibility rather than a one-off administrative exercise.

Sources and editorial method

Primary sources checked on October 15, 2026: NIST: AI Risk Management Framework and OWASP: AI Agent Security Cheat Sheet. The register fields, discovery sequence, hypothetical consultancy, and maintenance measures are original practical analysis. No operating results, certification, or tested vendor integrations are claimed. Apply appropriate local and sector requirements when deciding whether a use may operate.