Shadow AI: when staff paste work into public AI tools

In many organizations, someone is pasting a piece of work into a public AI chatbot: a draft contract clause, a customer email, a block of code that will not compile. They are not trying to cause a problem. They have a deadline, and the tool in the browser tab is faster than anything the organization has given them. That habit has a name, shadow AI, and it is worth understanding before deciding what to do about it.

What shadow AI is

Shadow AI is staff using AI tools the organization has not approved. The term borrows from “shadow IT,” the older habit of signing up for file-sharing or project tools without telling anyone. IBM’s Cost of a Data Breach Report 2025 describes it as the situation “where workers download or use unapproved internet-based AI tools.”

The definition is about approval, not about a particular product. The same chatbot can be sanctioned in one company and shadow AI in the next. What makes it shadow AI is that nobody responsible for the organization’s data decided it was an acceptable place for that data to go: nobody read the terms, asked how long inputs are kept, or agreed on what may be entered.

Why it happens

The plain answer is that the tools are useful. They summarize a long document in seconds, draft a first reply, explain an error message and untangle a spreadsheet formula. For a lot of everyday work that help is real, and staff notice.

Approved options can lag behind. Evaluating an AI tool takes time: security questions, contract review, deciding who gets access. Meanwhile the public version is one browser tab away and needs no request form. When the sanctioned route is slower, or missing, people may take the fast one without thinking of it as a policy decision at all.

The governance side of the gap is wide as well. Most of the organizations in IBM’s 2025 study, all of which had suffered a breach, said they had no governance policies in place to manage AI or to prevent shadow AI. Where there is no rule, there is nothing to break.

What actually goes wrong

The best-known case is Samsung. In 2023, one employee reportedly uploaded confidential source code to ChatGPT while asking for help fixing a faulty database, and another shared an entire meeting to have minutes written. Samsung then temporarily restricted generative AI tools on company devices. Its memo noted that it is difficult to retrieve and delete data held on external servers.

Nothing was hacked. The chatbot did what it was built to do with what it was given. The exposure happened at the moment of pasting: confidential material now sat on another company’s servers, under that company’s terms, and getting it back out was not something Samsung could do on its own.

A second pattern is sharing. In 2025, thousands of shared ChatGPT conversations turned up in Google search results after users ticked an option labeled “Make this chat discoverable.” That case mixes a user action with a design choice by the provider. OpenAI’s chief information security officer said the feature “introduced too many opportunities for folks to accidentally share things they didn’t intend to,” and OpenAI removed it.

The pattern shows up in breach data too. IBM’s 2025 report found that breaches at organizations with high levels of shadow AI cost more on average than breaches at organizations with low levels or none. It also found that customer personal information was compromised in a larger share of shadow AI incidents than of breaches overall.

The exposure happens at the moment of pasting, not at the moment of a breach.

Shadow AI is not a provider fault

It helps to keep two kinds of incident apart. A provider fault is a failure on the AI company’s side: a software bug, a misconfigured system, a breached supplier. Customers who used the service exactly as intended can still be affected, and the fix belongs to the provider.

Shadow AI is a choice made inside the organization, usually by someone acting in good faith. The provider may be working exactly as designed. The problem is that the material went somewhere nobody approved. Blaming the chatbot for a paste misreads what happened, and it points the remedy in the wrong direction: a better provider does not stop anyone from pasting into an unapproved one.

Why a ban is only a start

Samsung’s restriction was described as temporary, lasting until it had built security measures for using generative AI safely. That is the usual shape of the problem. A ban closes the obvious route, but the work that sent people to the tool is still there. If the summary is still due on Friday and a personal phone is still in a pocket, a rule about company devices and networks covers only part of the ground.

A more durable fix is to make the approved path the easy one, and to make the rules specific enough that people can follow them without asking.

What organizations do about it

The practical measures fit together, and each covers a gap the others leave:

• An approved-tools list. Name the AI tools staff may use for work, and for which kinds of work, so “is this allowed?” has an answer someone can look up.
• Clear rules on what may be pasted. Spell out the categories: customer records, personal data, passwords and keys, source code, contract terms, anything under a confidentiality obligation. Concrete examples help more than general principles.
• A sanctioned option that is as convenient as the public one. If the approved tool is slower, harder to reach or worse at the job, people drift back. Convenience is part of the control.
• Redaction before a prompt reaches a public tool. A filter between staff and the tool can remove personal data, credentials and source code before the prompt is sent, while the rest of the question still goes through.
• Sensitive work on systems the organization runs. For material that should not go to an outside service at all, the AI has to run somewhere the organization controls, under its own access rules.

Training and a written policy sit underneath all of it. Among the factors IBM’s 2025 report analyzed, employee training and AI governance policies were both associated with lower breach costs.

Exalt works on the last two. Exalt Guard sits between staff and public AI tools, and removes what should not leave the company before the prompt is sent. On Exalt local AI hardware, questions and answers are processed on the box, not sent to an outside AI service; how the box is isolated sets out the details.