Company AI Usage Inventory: How to Find and Classify Every Tool

Company AI Usage Inventory: How to Find and Classify Every Tool

Build a company AI usage inventory step by step: find tools, data and shadow use, classify each by risk, and record a decision, with a checklist.

••

Want to apply this in your company?

Book a call with Juan →

Company AI Usage Inventory: How to Find and Classify Every Tool

To build a company AI usage inventory, list every tool, who uses it, for what, and which data goes into it, including what people use without approval. Then classify each use by the sensitivity of the data and the consequence of a wrong answer, and record one decision: allow, allow with limits, review or ban. The starting point is talking to the teams, not only checking with IT.

Key takeaways

  • An inventory is not a list of subscriptions. It covers tools, data, people, purpose and the decision made for each use.
  • The biggest risk is usually informal use: personal accounts, browser extensions, and AI features built into software the company already pays for.
  • Classification stays simple when it combines two questions: what data goes in, and what happens if the answer is wrong.
  • Surveying without punishing is a condition for honest answers. An amnesty for what people declare is worth more than any technical scan.
  • The inventory only works if it has a review date and an owner. Without them it becomes an outdated spreadsheet within a few months.

Why does the inventory come before the policy?

Many companies write an AI usage policy before they know what is actually happening. The result is a document that bans what nobody does and ignores what everybody does. Decision makers need a picture of real use to choose where to allow, where to limit and where to invest in a safe alternative.

The inventory also supports obligations the company already has. If a tool receives personal data from customers or employees, the LGPD (Brazil's data protection law) requires you to know the purpose, who processes the data and on what legal basis. Without an inventory, you cannot answer those questions with confidence. For the design of the policy itself, read Company Policy for Employee ChatGPT Use: What to Allow and Ban, which assumes the usage map already exists.

The NIST AI Risk Management Framework organizes the work into functions such as govern, map, measure and manage. The inventory is, in practice, the first step of mapping: if you do not know where AI is, there is nothing to measure or manage.

Where do you look for AI tools nobody declared?

AI use shows up in different places, and each source reveals a different kind of finding. Combine several, because none of them shows everything on its own.

  • Contracts and corporate cards: subscriptions to assistants, image generators, transcription services and writing tools.
  • The app list in your identity provider (single sign-on, Google Workspace, Microsoft): apps that employees authorized with their company account, including through OAuth.
  • Browser extensions installed on company computers: page summarizers, email assistants, AI grammar and text tools.
  • AI features switched on inside existing software: CRM, ERP, support desk, document editing, video conferencing with automatic summaries.
  • Automations in n8n, Make, Zapier and similar tools that call language models through an API.
  • API keys in code repositories, password vaults and server environment variables.
  • WhatsApp: team numbers that use bots, audio transcription or suggested replies from third-party apps.
  • Coding tools: programming assistants, agents and MCP servers installed by developers.

With MCP servers and coding agents, the risk is not only in the text someone types but in the actions and access they are granted. If that applies to you, How to Audit an MCP Server Before Installing It at Your Company details what to check.

How do you uncover informal use without creating fear?

Informal use only surfaces if people feel safe saying so. If the inventory looks like a hunt for culprits, answers will be vague and the use will simply move to personal accounts and phones. The approach below works for small and mid-sized companies.

  • State the goal clearly: understand what helps people work, protect customers, and decide what the company will offer safely.
  • Declare an amnesty window: during the survey, no declared use leads to a warning. What matters is knowing.
  • Send a short questionnaire, about five minutes, with open questions: which tasks do you do with AI help, in which tool, with what kind of information.
  • Talk to one representative from each department for twenty or thirty minutes. Ask them to show the use on screen instead of describing it from memory.
  • Cross-check the answers against the technical sources in the previous section. Gaps show where undeclared use exists.
  • Consolidate everything in a single spreadsheet, with one owner per row, and share the results with the teams along with the first decisions.

One important detail: also ask what people would like to do with AI but do not because they are unsure. This reveals unmet demand and helps you prioritize approved alternatives.

Which fields should you record for each use?

A useful inventory records the use, not just the tool. The same tool can be harmless for drafting a blog post and risky for summarizing contracts that contain customer data. That is why the unit of the spreadsheet is the pair of tool and purpose.

  • Tool and plan type: free, personal, business or via API.
  • Account type: company account, personal account or shared key.
  • Department and owner: who uses it and who is accountable for the decision.
  • Purpose: the concrete task, written in one sentence.
  • Data going in: public, internal, confidential, personal data, sensitive personal data, trade secret or source code.
  • Data coming out and where it goes: is the result copied into an email, sent to a customer, written to a system?
  • Actions the tool is allowed to take: does it only generate text, or also send messages, change records, run commands?
  • Training and retention: does the vendor use the data to train models? How long does it keep it? Check this in the vendor's own documentation and contract.
  • Human review: does someone check the output before it takes effect?
  • Decision, date and next review.

If the tool processes personal data, check who is the processor and who is the controller in the contract. Data Controller vs Processor in an AI Vendor Contract (LGPD) helps with that reading, and the ANPD website is the official reference for data protection guidance in Brazil.

How do you classify each use by risk?

A classification nobody can apply is worse than none. Use two simple axes and a mental decision table. The first axis is the data: what goes into the tool. The second is the effect: what happens if the output is wrong or leaks.

Define four risk levels and a default decision for each:

  • Low: public or non-sensitive internal data, with output reviewed by a person before any use. Decision: allow, on a company-approved account.
  • Moderate: relevant internal data, or output that influences decisions, with human review. Decision: allow with written limits, such as no customer data and a business plan required.
  • High: personal data, customer data, contracts, financial information, or output that reaches a customer without review. Decision: review before continuing, assessing the contract, retention and, where appropriate, an impact assessment.
  • Critical: sensitive personal data (health, for example), decisions about people, irreversible actions in systems, or broad access to internal databases. Decision: suspend until a controlled design exists, with human approval and a record of every action.

Three tiebreaker questions help when a case is ambiguous:

  • Does the tool act on its own or only suggest?
  • Is a mistake easy to undo?
  • Would someone outside the company be affected?

If the answer points to autonomous action, a hard-to-undo error or external impact, move up one level. For high-risk uses involving personal data, Data Protection Impact Assessment for AI Projects (LGPD RIPD) explains when an impact assessment makes sense. For risks specific to applications built on language models, such as sensitive information leaks and prompt injection, the OWASP Top 10 for LLM Applications is a good checklist reference.

Illustrative scenario: three uses in the same company

Imagine a services company with sales, finance and support teams. The survey finds three uses. This is an illustrative example, unrelated to any real case.

  • The sales team uses a personal account on an AI assistant to improve proposal text, pasting excerpts that include the client's name and commercial terms. Data: confidential, with client identification. Account: personal. High risk. Decision: move to a business account and instruct people to replace the client name with a placeholder before pasting.
  • Finance switched on the AI feature of a management system that suggests categories for ledger entries. The responsible person checks before approving. Data: internal, financial. Human review exists. Moderate risk. Decision: allow, record the vendor's confirmation about data use, and review at the next scheduled date.
  • Support installed an extension that transcribes customer voice messages in WhatsApp Web. Data: personal, possibly sensitive. Unknown vendor. Critical risk. Decision: suspend the use and evaluate a controlled alternative, looking at retention and purpose.

The value of the inventory shows here: the three situations call for different decisions, and none of them would be solved by a blanket ban. For the voice message case, Transcribe WhatsApp Voice Messages With AI: Accuracy, Cost, Privacy discusses what to evaluate.

How do you keep the inventory alive, and what comes next?

The inventory loses value fast if it sits still. Give each department an owner, each row a review date, and everyone a simple path for new requests: whoever wants to use a new tool fills in a row first, and the answer comes within an agreed time. When approval is easy, informal use declines on its own.

The approach we use in AI projects has four steps that fit here. Map: survey uses, data and owners, as described above. Limit: define which data and which actions each tool may have. Pilot: choose one real moderate-risk workflow, replace the informal use with an approved solution, with logs and an agreed success metric. Transfer: hand the operation to the company's team and decide whether to expand, adjust or stop.

What you do not need to do is solve everything at once. Start with the uses classified as high and critical, resolve them one by one, and leave the low ones to a general rule of a few lines.

Frequently asked questions

How long does the first inventory take? It depends on the size of the company and how many technical sources exist, but a useful first version usually fits in a few weeks if someone is clearly responsible. It is better to deliver an imperfect first version and revise it than to wait for a complete survey that never ends.

Do I need a specialized tool for this? For most small and mid-sized companies, no. A shared spreadsheet, the app panel of your identity provider and conversations with the teams already deliver the essentials. Access management and security tools help discover undeclared use, but they do not replace classification done by people who know the process.

What should I do about people who use AI on a personal account? Treat it as information, not as a violation, especially during the survey. Understand the task, offer an approved alternative and set a deadline for the migration. If the use involves customer data or sensitive data, immediately suspending the highest-risk part is reasonable until the alternative is ready.

Does the inventory replace the LGPD analysis? No. It is the foundation for it, because it shows where personal data passes through AI tools, but legal bases, contracts and impact assessments remain separate steps. For an overview of the obligations, see LGPD and Artificial Intelligence for Companies: What to Do and validate concrete cases with your data protection officer or legal counsel.

Sources

AI governanceAI inventoryShadow AIAI riskLGPD