What People Actually Paste Into AI Tools at Work

Most discussion of AI data leakage is speculative. People imagine what might get exposed and write policies against the imagined case.

The 2026 breach reporting cycle produced something better: analysis of a very large volume of real data-loss prevention events involving uploads to generative AI tools, ranking what was actually going out. The Verizon Data Breach Investigations Report is the widely cited source, and the finding worth carrying is the ranking.

Source code led by a wide margin. Images and structured data followed.

That ordering is instructive, and mostly not in the way security awareness training assumes.

Why Source Code Ranks First

Because pasting code into a model is an obviously useful thing to do, done constantly, by people who are entirely aware they are doing it.

A developer with a stack trace pastes the stack trace. Someone debugging a config file pastes the config file. The value is immediate and the alternative, describing the problem in prose, is worse in every way.

Nobody in that flow is being careless. They are doing their job with the best available tool. The code sometimes contains credentials, internal hostnames, customer identifiers, or proprietary logic, and that is a side effect rather than an intention.

The general lesson: exposure follows utility. Whatever your people find most useful to paste is what leaves. Policies written against imagined misuse miss it because the actual behavior is not misuse.

The Numbers Around It

Survey figures from 2026 vary by methodology and should be read as a range rather than a measurement, but they converge on a picture.

Regular AI use on corporate devices rose steeply year over year, a majority of that use runs through non-corporate accounts, and roughly a third of employees in several surveys acknowledged having put sensitive company material into consumer AI tools. Reported average incremental breach costs where shadow AI was involved run into the hundreds of thousands.

Different reports give different figures and the direction is consistent. Treat any single number with caution and the trend as reliable. The fuller set is in shadow AI statistics 2026.

Why Blocking Does Not Work

The standard response is a block list. It reliably fails, for a documented reason: the majority of AI use happens through personal accounts, and a meaningful share on personal devices.

Blocking the corporate path moves the behavior to a path with no logging, no data protection agreement, and no retention control. You have not reduced exposure; you have removed your visibility into it. That mechanism is set out in what to do when your company blocks ChatGPT.

The organizations that do better provide a sanctioned tool that is good enough that the unsanctioned path is not worth the effort. That means it has to be genuinely convenient, not a worse experience wrapped in a policy.

What Reduces Exposure

Four things, in descending order of effect.

Provide a local option for the sensitive category. A model running on the employee’s machine ends the question for that text, because there is no upload to log or classify. This is the only intervention that changes the architecture rather than adding a control on top of it.

Make the sanctioned tool the path of least resistance. A global hotkey that rewrites text in place beats opening a browser tab, logging in, pasting, copying, and coming back. If the approved route is slower, it loses.

Write a policy by category, not by tool. Tools change monthly. Categories of text do not. “Client-confidential text goes through the local model” survives a vendor change; “do not use ChatGPT” does not survive the next product launch.

Inventory before you legislate. Most organizations do not know what is in use. How to run an AI tool audit for your team is the starting point, and it usually surprises people.

Writing The Rule So People Can Follow It

Policies fail on specificity more than on strictness. A rule someone cannot apply at 18:30 on a deadline is not a rule.

Before:

Employees must not share confidential, proprietary, or sensitive company information with third-party AI services and should exercise appropriate caution and good judgment when using such tools in the course of their work.

After:

Do not paste these into any cloud AI tool: source code from private repositories, customer records, contract text, credentials, or anything under an NDA.

For those, use Wrivio in local mode. The model runs on your laptop and the text is not transmitted.

Everything else, including your own draft emails with no client names in them, can go to the approved cloud tool.

If you are unsure, it goes local. Nobody will question that choice.

The second version names the categories, names the tool, and removes the cost of choosing correctly. That last line matters more than it looks: most bad choices happen because the careful option feels like it needs justifying.

A Wrivio Context for policy writing could say:

Rewrite this as a clear internal policy. Neutral register, complete sentences. Each rule must name a specific category of information and a specific action. Keep every tool name, system name, and category exactly as written. Do not add vague guidance such as “use good judgment” or “exercise caution”, and do not soften a prohibition into a suggestion.

Press Ctrl+Shift+Space, paste the draft, and check the diff. Watch for “must not” becoming “should avoid”, which is the single most common way a rewrite quietly weakens a policy.

The Part Nobody Wants To Hear

If your people are pasting sensitive material into AI tools, the finding is that the tools are useful, not that your people are careless.

Treating it as a discipline problem produces a policy that gets ignored and a workforce that stops telling you what it uses. Treating it as an infrastructure problem produces a sanctioned path that is actually better, which is the only intervention that has been observed to move the numbers.

The one intervention that changes the architecture rather than the paperwork is giving people a model that runs on their own machine for the sensitive category. Everything else is a control on top of a behavior that will continue.

Common Questions

What gets uploaded to AI tools most often?

Source code, by a wide margin, followed by images and structured data, according to 2026 breach reporting on data-loss events involving generative AI uploads.

Does blocking AI tools reduce data leakage?

Generally no. Most AI use runs through personal accounts, so blocking the corporate path moves the behavior somewhere you cannot see it.

What is the most effective single control?

Providing a local model for the sensitive category, because it removes the upload entirely rather than trying to detect or classify it.

How should a policy be written so people follow it?

By category of information rather than by tool name, with a named alternative for each restricted category and an explicit default when someone is unsure.

Download Wrivio for Windows to give people a sanctioned local option that is faster than opening a browser tab.