Where your company data actually goes when employees use AI

start from the flow, not the tool

The reason "is AI dangerous" fails as a question is that danger is not a property of the tool. The same model can be harmless or a serious exposure depending entirely on what data reaches it and what the vendor does with that data.

A marketing manager asking a chatbot to rewrite a public blog post is not a risk. The same manager pasting an unreleased contract into the same chatbot on a free tier is. The tool did not change. The data flow did.

So the unit of analysis is the flow. For every AI tool in use, the questions are the same. What data can reach it. By what path. What happens to that data once it arrives. Answer those three for each flow and you have a map. The map is what you govern.

One number sets the baseline. 78% of employees who use AI at work bring their own tools to the job (Microsoft, 2024). The flows already exist in your environment. The choice is whether you see them.

the five flow patterns

Most AI data exposure in a mid-market company falls into one of five patterns. They differ in how the data travels and in how visible the path is. For each, the thing to understand is what happens to the data once it leaves.

1. consumer and free tiers

An employee signs up for the free or personal version of an AI tool and starts using it for work. This is the most common pattern and the easiest to miss. On most consumer and free tiers, inputs may be used to train the model and may be retained for a period the user does not control. The default on a free tier is rarely "we do nothing with your input." The contrast that matters is with the enterprise or business tier of the same product, which commonly offers no-training terms, defined retention, and a Data Processing Agreement. The model is identical. The data treatment is not. This is why approving "ChatGPT" or "Gemini" as a tool means nothing on its own. The plan tier is the control point.

2. prompts pasted with sensitive data

An employee copies a customer record, a block of source code, or a clause from a contract and pastes it into a prompt. The intent is harmless: summarize this, fix this, translate this. The data leaves the moment it is sent. There is no draft state, no recall. Once the request reaches the vendor, the content is on their infrastructure and subject to their terms. If the tier trains on inputs, that customer record may now sit in a training corpus. This is the pattern that produces the headlines, and it is also the most ordinary. Pasting a contract into a chatbot is a data transfer to a third party, even though nobody doing it thinks of it that way.

3. connectors and OAuth grants

An employee connects an AI tool to a company system. They click "connect to Google Drive" or "add to Slack" or "authorize GitHub," approve the permission screen, and move on. This is different in kind from a paste. A paste sends one thing once. A connector grants ongoing access: the AI tool can read mail, pull documents, scan a repository, on its own schedule, without the employee initiating each transfer. The access is standing, not a one-time event. It persists until someone revokes the grant, which in most environments nobody does. A read grant to a drive full of contracts is a continuous pathway from your most sensitive content to an external model. The employee approved it in three seconds and forgot about it.

4. browser-based AI tools and extensions

An employee installs an AI browser extension or uses an AI tool that lives in the browser. Many of these read the content of the page you are on: an internal dashboard, a customer record in your CRM, an email thread, a document in a web app. The extension reads it to do its job, and in doing so it sends that content to its own backend. Some can intercept typed text. Some can reach session tokens. The governance problem here is location: these tools live on the endpoint, inside the browser. They do not appear in your identity provider's OAuth list because many of them never request an OAuth grant. If your visibility comes from the IdP alone, this entire category is invisible to you.

5. agentic tools with standing access

An agentic AI tool does not just answer. It acts. It sends emails, files tickets, updates records, runs steps in a workflow. To do that it holds credentials or connections with standing access to the systems it operates in. The agent reads and writes across whatever it is connected to, often with the permissions of the user who set it up. The data flow runs in both directions and continuously. An over-permissioned agent can reach anything its credentials reach, without a human initiating each action. This is the newest pattern and the one with the least settled practice. The principle is the same as for any standing access: define the scope before deployment, keep it least-privilege, and know what the agent can reach.

what to ask about each flow

For every flow you find, the same set of questions tells you how exposed it is. The answers come from the vendor's terms, their trust or security page, and their DPA. If a vendor cannot answer these, that is itself an answer.

• Does it train on inputs? · Why it matters: If yes, your data may enter a corpus you cannot reach or delete. Enterprise tiers commonly disable this; free tiers commonly do not.
• What is retained, and for how long? · Why it matters: Retention defines how long your data sits on their infrastructure and whether you can have it removed.
• Who are the sub-processors? · Why it matters: The vendor may pass your data to others. Each sub-processor is another party holding it and another jurisdiction it may sit in.
• Where is the data hosted? · Why it matters: For EU personal data this is a direct GDPR question. Processing location and transfer mechanism both matter.
• Is there a DPA? · Why it matters: A Data Processing Agreement is the baseline for using any tool with personal data under GDPR. No DPA, no personal data.
• For connectors: what is the scope of the grant? · Why it matters: A read grant to one folder is not a read grant to all of Drive. Scope defines exactly what the standing access can reach.

These six questions are the vetting core. They apply to a chatbot, a connector, a browser extension, and an agent alike. The flow changes; the questions do not.

how to map your flows

A map is a list of the AI in use and, for each one, what data can reach it and by what path. You do not need a platform to start. You need to look in the right places and be honest about the part you cannot see.

List the AI in use. Start with your identity provider. Pull the full list of OAuth grants and filter for AI-related apps. This surfaces a large share of connector-based and SSO-based AI use, including tools that never went through IT. Then check DNS logs for known AI domains, which catches browser-based tools that left no OAuth footprint. Then review the browser extension inventory on managed devices. Each source covers a different pattern. Together they give you most of what is visible.

For each tool, trace the path. Write down what data can reach it and how. A pasted prompt is one path. A connector with a Drive grant is another. A browser extension reading the active tab is a third. The path tells you which of the five patterns you are dealing with, and the pattern tells you what to ask.

Be honest about what the directory cannot see. A personal AI account, opened on a personal device or in a personal browser profile, used outside your directory entirely, leaves no trace in any of the sources above. There is no OAuth grant, no managed extension, no corporate DNS record. The flow is real and your tooling cannot see it. The blind spot calls for two additions the directory cannot provide. A short staff survey asks people directly what AI tools they use and how; people answer honestly when the framing is "we are mapping this, not hunting you." A clear policy tells people what is allowed, so the part you cannot observe is governed by a rule people understand rather than by chance.

how to control the flows

Once the flows are mapped, control is a set of decisions about what may go where. Five of them carry most of the load.

A data-classification rule. Decide which classes of data may go to which classes of tool. This does not need to be elaborate. It needs to be specific enough that an employee can look at what they are about to paste and know the answer. A workable starting set: personal data covered by GDPR, NDA-covered material, source code, unreleased financial data, internal strategy. The rule states, for each class, whether it may go to an external AI tool at all and if so to which tier. A classification an employee can apply in the moment is worth more than a long taxonomy nobody reads.

Enterprise tiers with no-training terms and a DPA. Where a tool is genuinely useful, move it onto the tier that treats data correctly: the enterprise or business plan with training disabled, defined retention, and a signed DPA. The free tier of the same tool does not belong in your environment. This single move converts a number of risky flows into acceptable ones without removing the tool people want.

Connector scope review and least privilege. Go through the OAuth grants AI tools hold and check the scope of each. Many will hold more than they need. Reduce them to least privilege. Revoke the grants nobody uses. For new connectors, review the scope before approving, not after. A connector is standing access, so it deserves the same scrutiny you would give any account with that reach.

An approved-tools list. Maintain a named list of AI tools cleared for work use, with the conditions on each: enterprise tier required, no personal data, internal use only. The list gives employees a sanctioned route, which is what keeps them off the informal one. Pair it with a lightweight vetting process and a named owner, so a request to add a tool gets an answer rather than disappearing.

AI literacy. People follow rules they understand. A short explanation of why a free tier is a problem, what a connector actually grants, and why a pasted contract is a data transfer does more for behavior than a list of prohibitions. The goal is that someone facing an edge case the policy did not name can still make the right call, because they understand the mechanism.

why this matters now

Two numbers frame the stakes without inflating them. Data leaks through generative AI are now the top generative-AI concern, cited by 30% of respondents (WEF, 2026). The concern maps directly onto the flows described above, recognized by the people managing them. And when shadow AI was involved in a breach, it added an average of USD 670,000 to the cost (IBM, 2025). The premium is the price of a flow nobody mapped: a tool nobody approved, holding data nobody classified, on terms nobody read. Neither number is a reason to ban anything. They are a reason to map the flows and control them.