Finding Out Which AI Tools Your Team Is Already Using

A short, genuinely non-punitive survey asking which AI tools people currently use for work, with an explicit promise that honest answers won't lead to discipline, usually surfaces far more than an IT audit of company-issued devices. Employees using personal accounts on personal devices for work tasks are invisible to most technical monitoring, and the survey is often the fastest way to see the real picture.

Expect the list to be longer and more varied than you'd guess. Different teams tend to gravitate toward different tools for different tasks, and a policy written around only the tools leadership happens to know about will miss most of what's actually happening. A sales team and an engineering team, for instance, will usually name almost entirely different tools when asked honestly.

Not every shadow AI use is equally risky. A tool used to brainstorm blog topics carries very different risk than one where someone has pasted a customer contract or financial data for summarization. Sort discovered tools by the sensitivity of the data involved, and focus your first policy pass on the categories that actually touch customer or financial information, rather than trying to regulate every use case at once.

A simple three-column sort works for most teams: tools that never see anything beyond public information, tools that see internal but non-sensitive material, and tools that see customer, financial, or legal data. Only that last column needs urgent attention in a first policy pass.

A policy that says "no unapproved AI tools" without an approved list just pushes usage further underground, since employees still have real work to get done and will find a way to use tools that help them. A workable policy names specific approved tools for specific tasks, a clear process for requesting a new one, and specific categories of data that can never go into any AI tool regardless of which one, phrased in plain language rather than legal boilerplate nobody reads.

Keep the request process genuinely short, a form with three or four questions rather than a lengthy security questionnaire, or people will simply skip it and keep using the unapproved tool they already had working. A process that's harder than just not asking defeats its own purpose.

A policy people can follow includes these parts:

• A named list of approved tools for specific tasks, so employees are not left guessing what is allowed.
• A short request process for new tools, with three or four questions instead of a lengthy security questionnaire.
• Specific categories of data that can never go into any AI tool, regardless of which tool is used.
• Plain language rather than legal boilerplate, so employees actually read the policy and follow it.

Most small and mid-sized companies don't have a security team to enforce an AI policy through technical controls alone. A compliance and evidence platform like Vanta or Drata can help track which tools have been reviewed and approved as part of a broader vendor and risk program, but the underlying work, actually reviewing each tool's data handling before approving it, still needs a person to do.

For example, a fifty-person company without a security team can assign one operations lead to own the approved tool list. When an employee requests a new tool, the owner checks how it handles and retains data, records the decision alongside other vendor reviews, and either adds the tool to the list or explains why not. A common mistake is approving a tool once and never revisiting it, even though vendors change their data terms over time. Add a review date to each entry and re-check the tools tied to sensitive data first. This keeps governance lightweight while still putting a person's judgment behind every approval.

The AI tool landscape moves fast enough that a policy written once and never updated goes stale within months. Put a recurring review on the calendar, tied to your broader vendor review cadence, where newly requested tools get evaluated and the approved list gets updated, rather than letting the policy quietly become a document nobody references anymore.

A policy that hasn't been touched in six months is a strong signal to run the anonymous survey again, since a static approved list in a fast-moving category almost always means real usage has drifted ahead of what's written down.