An approved AI tools list names every AI tool your organisation permits, the person accountable for each one, and the most sensitive class of data it is allowed to touch. It is a governance record, not a shortlist of good software.
Building one takes four to six weeks of part-time work. Start from the software you already pay for rather than from a request form, record five fields per tool, name one person who answers new requests inside five working days, and give every entry a review date. The spreadsheet is the output. The process behind it is the part that keeps it true.
Most guides get the first move wrong. They open with an amnesty and a request form, which surfaces the tools people chose on purpose and misses the ones that arrived on their own. Microsoft Copilot Chat did not wait for a business case. Neither did Gemini in Google Workspace, the summariser in your note-taking app, or the assistant that turned up in your CRM after a routine release. Those entries carry the widest data access and the least oversight, and no request form will ever produce them.
What you need before you start
Three things, and none of them is a finished policy. You need a named owner with about half a day a month, read access to your own billing, and a decision from someone senior about what happens to tools that fail review.
The billing access matters more than it sounds. Your finance system holds the subscription list, and the subscription list is where the AI you did not notice buying is recorded. An IT manager who can see the Microsoft 365 admin centre, the Google Admin console and the card statements can build a usable inventory in a week. One who has to ask people what they use cannot.
The senior decision matters because it is the one you cannot make yourself. If a tool the sales team relies on turns out to be processing client data on a free account, somebody has to say whether it stops on Friday or gets ninety days to migrate. Deciding that in advance, in the abstract, is far easier than deciding it while the sales director is standing in your doorway.
Step 1: Start from what you already pay for
Open your subscription list before you ask anyone anything. Every SaaS product your organisation pays for has shipped AI features in the last two years, and most switched them on by default rather than waiting to be asked.
Two examples worth checking on your own tenancy first. Microsoft's own documentation states that Copilot Chat is included with many Microsoft 365 subscriptions and requires no Copilot add-on licence, and that users can put organisational content into it by uploading a file directly. Google moved the same way in January 2025, when it confirmed that Google AI features are included in Workspace Business and Enterprise plans at no additional cost. In both cases the capability arrived with the licence you were already buying.
Work through the list in this order, because it runs from widest access to narrowest:
The office suite. Microsoft 365 or Google Workspace, which sit on top of everything.
Anything that joins meetings. Teams, Zoom, Otter.ai, Fireflies. These record conversations you have not classified.
The CRM and the service desk. HubSpot, Salesforce, Zendesk, Intercom. Customer records, by definition.
Collaboration and documents. Notion, Slack, Confluence, Canva.
Standalone AI subscriptions. ChatGPT, Claude, Perplexity, and whatever a team bought on a card in March.
Browser extensions. The category everybody forgets, and the one with the fewest contractual protections.
Only then send the amnesty note asking what else people use. Put it in writing that nobody is in trouble for answering honestly, because the alternative is an inventory built on guesses. In our experience the total lands somewhere between 15 and 25 tools rather than the five people expect, and roughly half of those were never chosen by anyone.
Step 2: Record five fields, not fifteen
Five fields per tool is the most a single part-time owner will keep current. The registers you find online run to twelve or fifteen columns, which is a reasonable design for a compliance team and a guarantee of abandonment for an ops lead with a day job.
Field | What goes in it | Why it earns a column |
|---|---|---|
Tool | Product name and the specific edition | "ChatGPT" and "ChatGPT Enterprise" are different contractual positions |
Owner | One named person, never a department | The field most often left blank, and the one that makes review possible |
Tier | Free, paid seat, or enterprise agreement | Determines what the vendor has actually promised you |
Highest data class | The most sensitive class permitted in this tool | Turns the list into something a non-specialist can apply |
Review date | A date, not an interval | An interval is an intention; a date appears in a calendar |
The data class field is the one that makes the list usable in the moment somebody needs it. If your organisation has already sorted its information into a small number of tiers, reuse those labels here rather than inventing parallel ones. If you have not written those tiers down yet, the policy section that defines your data tiers is a better place to start than the register, because the register should point at the same vocabulary your policy uses rather than inventing its own.
Resist the sixth column. Business justification, vendor security questionnaire status, DPIA reference and annual spend are all reasonable things to know and all reasons the file stops being updated in week five. Keep them somewhere else, linked from the row.
Step 3: Set the intake route and a response time you will hit
One named person answers new requests, and they answer within a stated number of working days. Five is defensible and fifteen is not, for reasons that are behavioural rather than administrative: an approval route slower than a personal credit card produces personal credit cards. That argument is made in full in the piece on approving new tools, and it is the single thing most likely to decide whether your list survives.
What belongs here instead is the mechanism. A request needs a route that takes under two minutes to use, which means a form in the place people already work rather than an email to a shared inbox. Three questions is enough: what is the tool, what task is it for, and what data would go into it. The third question is doing the real work, because it tells you whether this is a five-minute decision or a conversation with your DPO.
Publish the response time and then measure it. An advertised five days that runs at eleven is worse than an honest fifteen, because people plan around the number you gave them once and never trust it again.
Step 4: Write the one escalation rule that matters
The escalation rule is a single sentence: anything that reaches outside your own systems stops being a routine approval. A tool that reads your email, connects to your CRM, holds credentials for another system, or acts without a person reviewing the output first is a different category of decision from a tool somebody pastes text into.
The distinction is about reach, not about how clever the model is. A summariser that only sees what a user pastes into it has a blast radius of one paste. An integration with read access to a shared drive has a blast radius of the drive, and it keeps that access on the days nobody is thinking about it. The Information Commissioner's Office guidance on AI and data protection is clear that existing UK GDPR accountability obligations apply to AI systems in full, and that "we bought it as a feature" is not a category the law recognises.
In practice the rule means three or four tools a year get a real assessment and everything else gets a decision in a day. That ratio is the point. A process that treats a note-taking app and a CRM integration with the same seriousness will be routed around within a quarter.
Step 5: Handle the tools already in use
Sort them into three groups and treat each differently, because a blanket ban and a blanket amnesty are both wrong. Some of what you found is fine, some needs a migration, and a small number need to stop.
Approve as-is. The tool is appropriate for the data going into it and the tier is adequate. Record it and move on. This is usually the largest group and saying so early buys you credibility for the other two.
Approve on a paid tier. The right tool on the wrong account. A free consumer tier handling client material is the most common finding in any first inventory, and the fix is a purchase order rather than a confrontation.
Stop, with a named alternative and a date. Reserved for the small number that are not acceptable on any tier. Never remove a tool without naming what replaces it, because the work does not stop when the tool does, and a team left without a route will find one you cannot see.
Give group three a migration window with a date on it, and tell people why rather than only what. "This one keeps your prompts for training and we have no contract with them" changes behaviour. "This is not on the approved list" produces a workaround.
What this costs in time, and who owns it
Roughly 20 to 30 hours to build and about half a day a month to maintain, for an organisation of 100 to 500 people. The build splits into a week of inventory, a week of assessment, and a week of conversations with the teams affected by group three.
The owner should be whoever already runs software procurement, which in most organisations of that size is an IT manager, an ops lead or a COO. It should not be the head of L&D, who owns whether people can use the tools well, and it should not be a committee. A committee with no decision rights converts a delay into a process, which is worse than the delay.
Two related jobs are often bundled into this one and should not be. Deciding which AI tools are worth using at all is a selection problem, covered in the map of the AI tool landscape. Writing the document that states the rules is a policy problem, and its approved-tools clause describes the route rather than maintaining the record. This is the third job: the standing record of what has been signed off, by whom, for what data.
Why the list goes stale in a month
Because nothing in the process was tied to a date or a person, and both failures look fine on the day you finish. A list with an owner and review dates decays slowly. A list with neither is accurate for about three weeks, which is roughly how long it takes for one vendor to ship a feature and one team to buy something.
Four specific failure modes, in the order they show up:
The owner left and nobody inherited the file. Name a deputy on day one. This is mundane and it is the most common cause of death.
A vendor changed its terms and the row did not change. Vendor terms move faster than any review cycle, so add an event trigger: an acquisition, a pricing change or a new integration reopens the row immediately, regardless of its review date.
Approvals got slower and stopped being used. Track your own response time as a number. When it drifts past the published figure, that is the leading indicator of people going around you.
The list was never where people look. A register in a folder nobody opens is not a control. Put it where the work happens, and link it from the policy rather than the other way round.
None of these are governance problems in the interesting sense. They are maintenance problems, which is why the list is the easy part and the reason so many organisations have one that describes last spring. Risk classification, review cycles and the wider structure this sits inside are covered in the guide to developing an AI policy.
If you would rather not build this from a blank spreadsheet, our AI strategy and governance work starts with exactly this inventory. It is a conversation, not a download.
