The Approved AI Tools List: A Register People Actually Use (Template Included)

TL;DR: Every other governance artifact points at this one. The acceptable-use policy says “use approved tools”, this is the list. The security review produces verdicts, this is where they land. The list works when it records scoped approvals (which tier, which data, which integrations, whose problem) rather than binary yes/no, and when getting a tool onto it takes days, not quarters. This page covers building it, the maintenance loop, and ends with a complete template you can copy into a spreadsheet this afternoon.

Why a list, and why most lists fail

The approved-tools list solves a specific, daily problem: an employee about to paste something into a tool needs to know, in under a minute, whether that’s fine. If the answer requires judgment, they’ll guess. If it requires asking permission and waiting, they’ll skip asking. The list converts the question into a lookup.

Most lists fail in one of three ways, all avoidable:

• Binary approvals. “Slack: approved” tells you nothing about whether the AI summarization feature can see the legal channel. Approval without scope is a false comfort, the scope columns below are the actual product.
• Slow intake. If a new tool takes six weeks to approve, employees stop requesting and start using. The list then documents an approved fiction while real usage happens elsewhere. Governance that loses to convenience always loses.
• No maintenance. Vendor terms change, tools get acquired, features gain write access. A list last touched fourteen months ago is a historical document that people mistake for a current one, which is worse than no list.

The design below counters each: scoped rows, a five-day request lane, and a six-month recheck cadence.

Building it: four steps

Step 1: Inventory what’s actually in use, amnesty first

You are not starting from zero; you’re starting from unknown. Run a short survey, what AI tools do you use for work, on what account, for what tasks?, paired with an explicit no-consequences window: anyone declaring current usage gets their tools evaluated, not their conduct. This mirrors the amnesty logic of the acceptable-use policy rollout, and it works for the same reason: your heaviest shadow users are your most informed users, and you want them inside the system.

Supplement with what you can observe, SSO and OAuth grant logs, expense lines, browser extension inventories, and the AI features already embedded in software you own (meeting tools, CRM, office suites, inventory these explicitly; they’re tools whether or not anyone “adopted” them).

Step 2: Categorize

Group the inventory into categories, because approval criteria differ by category more than by brand:

Step 3: Evaluate against standard criteria

Each candidate goes through the AI security review, the five-minute pre-screen kills weak candidates cheaply, the five-part review handles the rest. The criteria that determine listing, condensed:

1. Business tier with contractual no-training terms and a signable DPA, the non-negotiable core, argued in full in AI and data privacy.
2. Identifiable, attestable vendor (SOC 2 / ISO 27001 or a credible equivalent posture, published subprocessors).
3. Admin controls: SSO/MFA, role scoping, centralized offboarding, audit logs.
4. Scoped integrations: the tool can be granted only what the use needs.
5. A business owner internally willing to own the relationship, no orphan tools.

Step 4: Record scoped approvals

The output of evaluation is a row, and the row’s power is its scope columns: approved tier, approved data classes, approved integrations. “Approved for confidential business data on the Enterprise plan, no email integration” is a usable answer. “Approved” is not. High-stakes applications of a listed tool, hiring, anything customer-facing and autonomous, additionally route through the use-case risk assessment; the list clears tools, not every conceivable use of them.

Maintaining it: the two loops

The fast loop, requests (continuous). One short form (tool, tier, use case, data classes, integrations), answered within five business days. Possible outcomes: approved (new row), approved with conditions (row with tight scope), trial (time-boxed pilot row), declined with reasons and, where possible, a pointer to the listed alternative that covers the need. The declined-with-alternative pattern matters: every “no” without a “use this instead” is a future shadow tool.

The slow loop, recheck (every six months). For each row: re-read the vendor’s current data terms (they change quietly, the single most valuable fifteen minutes in this whole system), confirm the attestation is current, check usage (retire rows nobody uses; every stale row erodes trust in the list), and confirm the owner still exists and still owns it. Event triggers reopen a row immediately: vendor acquired, terms changed, security incident, or the tool ships a feature that expands its access.

Publish the list where work happens, the intranet page, the pinned channel, never as an attachment. The list is a product with users; treat discoverability as a feature.

The template

Copy this into a spreadsheet or table today. Three parts: the register itself, the status vocabulary, and the request form that feeds it.

Part 1: The register columns

APPROVED AI TOOLS LIST, [COMPANY NAME]
Owner: [name, role] · Last full review: [date] · Next review: [date +6 months]
Request a tool: [link to form / email] · Answers within 5 business days

Columns:
1.  Tool, product name
2.  Category, general assistant / embedded feature / notetaker /
                      coding / content / vertical / agent-automation
3.  Vendor, legal entity you contract with
4.  Plan/tier, the exact approved plan (approval is tier-specific;
                      the free tier of an approved tool is NOT approved)
5.  Status, Approved / Conditional / Trial / Under review /
                      Declined / Retired   (see vocabulary below)
6.  Approved data, highest data class permitted:
                      P  = public only
                      I  = internal business data
                      C  = confidential business data
                      S  = personal/client-confidential/regulated data
                      (classes align with the data rules in the AUP)
7.  Integrations, which connections are permitted, named explicitly
                      (e.g., "Drive: /Marketing folder only", "none")
8.  Autonomy, suggest-only / act-with-approval / autonomous
                      (autonomous requires a red-tier risk assessment on file)
9.  Business owner, internal person accountable for this tool
10. Security review, date completed + link to the review record
11. DPA / terms, DPA signed (date) + link; no-training clause Y/N
12. Terms recheck, date data terms were last re-read
13. Accounts, how users get access (SSO group / request to owner)
14. Conditions, any restrictions in plain words
                      (e.g., "no client names in prompts", "announce in
                      external meetings", "output requires review before send")
15. Notes, anything the next reviewer needs to know

Part 2: Status vocabulary

Approved      Cleared for listed scope. Use freely within columns 6-8.
Conditional   Cleared with restrictions, read column 14 before using.
Trial         Time-boxed pilot for a named group; expires [date]; not
              approved for anyone else.
Under review  Requested, being evaluated. Not yet approved for any
              company data.
Declined      Evaluated and rejected; reason on file. Do not use with
              company or client data. Alternative: [listed tool].
Retired       Formerly approved; migrate off by [date]. Access revoked after.

Part 3: The request form

NEW AI TOOL REQUEST, sent to [owner]
1. Tool and vendor:
2. Plan/tier you want:
3. What you'd use it for (one or two sentences):
4. Data it would touch (P / I / C / S, see the list's data classes):
5. Integrations it needs (name systems and scope, or "none"):
6. Would it act on its own (send/edit/execute), or only suggest?
7. Is there a listed tool that almost covers this? Why isn't it enough?
8. How many people would use it?

You'll get an answer within 5 business days: approved, approved with
conditions, trial, or declined with a reason and an alternative.

Example rows (illustrative)

The fourth row is deliberate: declined tools belong on the list. The register’s job is answering the question people actually have, and “can I use the free one?” is the most-asked question there is. A visible “Declined, use [approved tool] instead” answers it forever.

FAQ

What is an approved AI tools list?

A living register of vetted AI tools recording, per tool: the approved plan tier, permitted data classes, permitted integrations, autonomy level, internal owner, security-review and DPA status, and any conditions. It’s the operational core of an acceptable-use policy, the lookup that replaces per-incident judgment calls.

How do we find out which AI tools employees are already using?

A declaration survey with explicit amnesty gets you the truth fastest: people report tools and use cases, tools get evaluated, nobody gets punished for the past. Add observable sources, SSO/OAuth logs, expenses, extension inventories, and inventory the AI features embedded in software you already own, which are tools whether or not anyone consciously adopted them.

Should approval be per-tool or per-use?

Layered. The list grants per-tool scope: tier, data classes, integrations, autonomy ceiling. Applications with real stakes, decisions about people, autonomous external output, additionally pass a use-case risk assessment. A tool approved for internal drafting has not thereby been approved to screen candidates; the risk lives in the use.

How often should the approved-tools list be reviewed?

Requests continuously, with answers inside five business days. The full register every six months: re-read each vendor’s data terms, confirm attestations, retire dead rows, confirm owners. Individual rows reopen immediately on triggers, acquisition, terms change, incident, or a feature that expands the tool’s access.

What happens when someone uses a tool that isn’t on the list?

Public data only: tolerated, redirected to the request path. Company or client data: a violation handled under the acceptable-use policy’s graduated enforcement, correction and coaching for honest mistakes, escalation for knowing misuse, and explicit leniency for prompt self-reporting. Structurally, the fix is a request lane fast enough and approved tools good enough that going around the list stops being worth it.

Rolling this out and want a hand? Webisoft helps companies implement AI safely, get in touch.