Guides · Updated 2026-09-06

AI Tool Register Template: Columns, Risk Levels and Reviews

An AI tool register, sometimes called an AI inventory, is a single list of every AI system your business uses, who approved it, what data it may touch and when it was last reviewed. It is the document that makes an AI policy enforceable, because a rule that says use only approved tools means nothing until somebody writes down which tools those are. This guide explains what to record, how to keep it current and why auditors and insurers now ask to see it.

The free generator includes an AI tool register template pre-filled with the tools you tell it about, so you can start from a real inventory rather than a blank sheet.Start the free generator

What an AI tool register is and why it matters

The register is an operational document, not a policy. Where the policy sets rules, the register records facts: this tool, on this plan, approved by this person, for these uses, with this data. It lives in a spreadsheet or a shared table, it has an owner, and it is updated whenever a tool is added, changed or retired.

Businesses discover they need one at predictable moments. A client security questionnaire asks which AI services process their data. A new starter asks whether they can use a particular assistant. An incident occurs and nobody can say which tool was involved or what plan it was on. The register answers all of those in seconds, and building it is usually the most revealing part of writing an AI policy, because it exposes how many tools are already in use.

The columns your register should have

Keep the register to one row per tool and one screen wide. If you find yourself wanting a second sheet, you are probably recording things that belong in the policy or in the supplier contract instead.

  • Tool name and vendor, including the specific product where a vendor has several.
  • Plan or tier in use (free, individual, team, enterprise) and whether accounts are company-managed.
  • Category: chat assistant, coding assistant, image or video generation, meeting transcription, embedded feature in existing software, agent or automation.
  • Approved uses, in a short phrase such as drafting internal documents or summarising public research.
  • Highest permitted data class, matched to the classification in your policy (public, internal, confidential, restricted).
  • Does the vendor train on inputs, and is that setting confirmed off for your accounts?
  • Data location and retention, taken from the vendor documentation.
  • Business owner (who asked for it) and approver (who said yes).
  • Risk level: low, medium or high, using the criteria below.
  • Date approved, date of last review and date of next review.
  • Status: approved, approved with conditions, under evaluation, rejected, retired.

How to approve a tool

Approval in a small business should be a short conversation, not a procurement process, but it should follow the same questions every time. What will it be used for? What data will go in? Where does that data go, and does the vendor train on it? Can we use a company-managed account with MFA? Is there a cost, and who pays? Does it connect to any of our other systems?

If the answers are all comfortable, add the row with status approved. If the tool is useful but the data terms are not, approve it with conditions, typically limiting it to public or internal data. If the vendor cannot say where data goes or cannot turn off training, reject it and record why, so the next person who asks gets a consistent answer. Give people a route to request tools; a register that only ever says no drives usage underground.

Assigning risk levels

Risk in the register comes from two dimensions: what data the tool can reach and what the output is used for. A drafting assistant that only sees public information and produces internal notes is low risk. A meeting transcription tool that captures client conversations is medium risk because of the data, even if the output is harmless. A tool that makes or supports decisions about individuals, such as CV screening or credit assessment, is high risk regardless of the data, and in the EU may fall under the high-risk obligations of the AI Act when those apply.

Use risk level to decide the review cadence and the level of sign-off. Low-risk tools can be approved by a team lead and reviewed annually. Medium-risk tools need a director or the policy owner and a six-monthly review. High-risk tools need documented human oversight, a legal or compliance check and a quarterly review, and most small businesses should think carefully before adopting them at all.

Review cadence and keeping the register current

The register decays quickly because AI vendors change terms, add features and get acquired. Set a light review at the cadence above and a full re-check whenever a vendor changes its data terms, a tool gains a new capability such as web browsing or file access, or an incident involves the tool. The review is a five-minute check that the row is still true, not a re-approval from scratch.

Two habits keep the register honest. First, ask new starters what tools they used at their last job and add any that are unfamiliar to the evaluation queue. Second, once a quarter, look at your expense reports and single sign-on logs for AI services that nobody registered. Shadow AI is normal; the register is how you bring it into the light without punishing anyone.

Why auditors and insurers ask for it

Auditors working to ISO 27001, SOC 2 or sector frameworks treat an AI inventory the same way they treat an asset register: as evidence that the organisation knows what it operates. Cyber insurers increasingly ask, at renewal, what controls exist over data leaving the organisation through AI services. A register with data classes, training settings and review dates is a direct answer. So is its absence.

In the EU, deployer obligations under the AI Act assume you know which systems you use and what risk category they fall into. Article 4 AI literacy duties are easier to evidence when training is mapped to the tools people actually operate. The register is the document that connects the policy, the training records and the transparency notice, and it is usually the first thing a client audit asks to see.

Frequently asked questions

Do embedded AI features in existing software need to go in the register?
Yes. AI features in your email client, CRM, design tools and office suite process your data in the same way as standalone tools. Record them as a row with category embedded feature and note whether the feature can be disabled.
What tool should we use to keep the register?
A spreadsheet is fine for most businesses under 100 people. What matters is a single owner, version control and a link from the policy. Move to a governance platform only when the spreadsheet becomes unmanageable.
Who should be able to see the register?
Everyone in the business should be able to read it, because it tells them what is approved. Only the owner and approvers should be able to edit it.
How many tools does a typical small business have?
More than the owner thinks. Once embedded features, browser extensions and personal accounts are counted, ten to twenty entries is common for a company with a few dozen staff.
Should rejected tools stay in the register?
Yes, with status rejected and a one-line reason. This prevents the same evaluation being repeated and shows an auditor that decisions were made deliberately.

Generate your own in about four minutes

The free generator includes an AI tool register template pre-filled with the tools you tell it about, so you can start from a real inventory rather than a blank sheet.

Generate my policy free

Related guides

This guide is general information, not legal advice.