Operational Guide

amotivv · advisory guidance

AI Usage Discovery

A guide for your leadership team to run internally. Governance requires visibility, so the first step is a clear picture of which AI tools the team uses and the purpose each one serves.

Run it internally Amnesty, not audit Visibility before policy

Purpose and sequencing

Governance requires visibility. Start there.

This document addresses the question of where to begin on AI governance. Governance requires visibility.

The first step is to establish a clear picture of which AI tools the team uses and the purpose each one serves. The purpose is the operative detail. Every tool in use addresses a real need, and understanding that need defines the requirements an approved tool would have to meet in order to replace it.

This guide is designed to be run internally. It requires no external facilitation. It requires a designated owner and a few hours of team participation.

This exercise should be conducted as an amnesty. No individual is subject to penalty for the tools they currently use. The objective is to identify better-supported versions of tools the team already relies on, rather than to audit individual behavior. The leader introducing this exercise should state the amnesty framing explicitly. If the team perceives the exercise as an enforcement action, reporting will be incomplete, and the visibility gaps this work is intended to close will persist.

Process overview

Six steps, completed within a focused week.

Leadership alignment (30 minutes). Confirm the amnesty framing, designate one owner, and decide who introduces the exercise to the team. The framing holds only when it is communicated by someone with organizational standing rather than as an IT directive.
IT and engineering lead completes Part A (approximately 15 minutes). This establishes how much of the inventory can be confirmed from logs versus how much relies on self-report.
Part B is distributed to team leads (approximately 10 minutes each). This is the tool inventory.
Engineering completes Part C. This covers the agent, connector, and credential surface, which is the highest-stakes area.
Team leads conduct the Part D conversations with their teams. This is where the purpose behind each tool is established.
Findings are synthesized into the map described in the final section. This becomes the foundation for subsequent governance decisions.

The total effort for an organization of approximately 50 people is modest. It can be completed within a focused week, largely on an asynchronous basis.

Part A · Visibility baseline

How much can be verified from data versus self-report.

Owner: IT, security, or engineering lead. This section determines how much of the remaining work can be verified from data versus self-report.

A1. Which of the following data sources are available to query today? (Check all that apply and note the specific tool.)

Network and DNS logs: firewall, DNS resolver, or a secure web gateway or SASE platform (Netskope, Zscaler, Cato). Tool:

Endpoint and device management: Intune, Jamf, Kandji, or an EDR platform (CrowdStrike, SentinelOne). Tool:

Identity and SSO logs: Okta, Entra, Google Workspace admin. Tool:

OAuth and connected-app grants: the list of third-party applications employees have connected to Google Workspace, GitHub, or your data stores. Location:

DLP: any data-loss prevention tooling monitoring outbound data. Tool:

None of the above is currently queryable

Rationale: The available data sources determine the method. With network, identity, and endpoint data, the inventory can be built from logs and confirmed through self-report. With identity and SSO data alone, the connected-app surface remains visible, though usage via personal accounts will not appear in the data and must be captured through the Part D conversations. If no data source is available, that gap constitutes the first finding, and standing up basic AI discovery capability becomes an early item on the governance roadmap. Most organizations of this size fall in the middle range. Documenting the visibility gaps honestly is the objective.

A2. Who holds the authority to disable an AI tool today?

Name the individual or function. If the authority is undefined or distributed across several parties, document that. Diffuse ownership is a valid finding and is common.

A3. Does a written AI policy currently exist?

Yes or No. If yes, retain it for reference. If no, that is expected. A written policy is an output of this work rather than a prerequisite.

Part B · Tool inventory

One row per tool. "Not sure" is an acceptable answer.

Owner: team leads or all staff. One row per tool. Complete the fields you can. "Not sure" is an acceptable answer for the data-handling columns.

Scope reminder. The term "AI tool" extends beyond ChatGPT. Include the following categories:

Chat assistants (ChatGPT, Claude, Gemini, Copilot, Perplexity, DeepSeek)
Coding assistants (Cursor, Copilot, Claude Code, Windsurf)
Note-takers and meeting summarizers (Otter, Fathom, Granola, Zoom AI)
Browser extensions with AI features
AI features embedded in existing tools (CRM, support desk, design, documents, BI)
Image, design, and writing tools (Canva AI, Midjourney, Grammarly)
Transcription, research, and data tools
Any agent or automation that runs independently (covered in Part C)

Tool	Team or owner	Purpose	Data input	Account type	Data handling known?
e.g. ChatGPT	Marketing (3 people)	Draft and edit campaign copy	Public and draft copy	Personal / free	Not sure
e.g. Cursor	Engineering (most)	Code completion and refactor	Source code	Personal paid	Not sure

Account type is one of: company or paid, personal or free, personal or paid, or embedded in another tool.

Data input should accurately reflect sensitive categories: customer information, financial or regulated data, PII, source code, credentials, internal documents, or public information only.

Part C · Agent, connector, and credential surface

The highest-stakes area, and the least visible in logs.

Owner: engineering. Exposure concentrates in this area, and log visibility is limited here. An agent operating server-to-server does not appear in DNS logs the way a person entering text into a chatbot does. Internal knowledge and OAuth and token logs are the primary sources of visibility for this section. It warrants the most careful attention.

C1. Coding assistants. Identify which AI tools access the codebase. For each, determine whether it has access to private repositories, whether it can execute commands or open pull requests, and whether code is eligible to train the vendor's model under the current plan.

C2. Agents and automations. List anything that runs AI independently, including scheduled jobs, workflow automations (n8n, Zapier with AI steps), and internal agents. For each:

Identify which systems and data it can reach. Flag anything that touches sensitive, regulated, financial, or customer data.
Identify the credentials it holds and their scope. Distinguish broad administrative keys from narrowly scoped credentials.
Identify the owner and confirm whether a kill switch exists.

C3. OAuth-connected applications. Pull the connected-app list from Google Workspace, GitHub, and your data platforms. Identify which AI tools employees have connected to company data via OAuth. These retain their access after an individual stops using the tool.

C4. API tokens and service credentials issued to AI tools. Identify any personal access tokens, API keys, or service accounts provided to an AI tool or agent. Document the scope of each and whether it remains in use.

C5. MCP connectors and servers. Identify any MCP servers exposing internal systems or APIs to AI clients, whether internal or third-party. Document what each exposes and to whom.

Part D · The conversations

Where the purpose behind each tool is established.

Conducted by team leads and leadership with their teams. The inventory establishes what is in use. These conversations establish the purpose, which is the unmet need that defines what an approved tool would have to satisfy. Keep the conversations open and non-judgmental. This is the core of the amnesty.

TeamsQuestions for team leads to ask their teams

Describe a normal day. Where does AI appear in your work?
What would you lose if your primary AI tool became unavailable tomorrow?
Where do the company-approved tools fall short of what you require?
Have you entered information into an AI tool and later reconsidered it?
If an approved tool performed the same function, would you discontinue the personal account?

EngineeringAdditional questions for engineering leads

How are agents and automations built here? Is there a central process, or does each person create one as needed?
When an agent is connected to a system, how is its level of access determined?
Where does AI touch sensitive, regulated, or financial data, directly or indirectly?

LeadershipQuestions for leadership to discuss

What should responsible AI use look like here one year from now?
What is the organization's tolerance for risk relative to speed on this matter?

Deliverables

Four outputs for leadership.

The synthesis of Parts A through D produces four outputs for leadership:

A tool, purpose, and data-sensitivity map.
Every AI tool in use, the need it serves, and the sensitivity of the data flowing through it. This is the basis for every subsequent decision.
A visibility-gap finding.
The areas where self-report was the only available source, documented explicitly, with discovery capability flagged as a roadmap item where it is absent.
An ownership finding.
Who holds, or does not hold, the authority to govern and disable AI use.
A basis for selecting approved tools.
A precise definition of what an approved option must do to displace the unsanctioned ones, replacing guesswork with requirements.

This exercise is discovery rather than the final destination. It is the foundation that makes subsequent governance decisions defensible, and it reframes the work from policing the team to enabling it.