An open laptop outline with a translucent page drifting out of it toward a cloud of data points

Shadow AI: When Employees Put Company Data Into ChatGPT

Shadow AI is the use of AI tools nobody approved. It is not usually malicious, and it is almost never hidden on purpose: an employee needs a summary, a draft, or a spreadsheet cleaned, and the free tool in the browser tab does it in ten seconds. The problem is what the employee pastes in to get that result, and where that data goes afterward.

The 2026 Verizon Data Breach Investigations Report puts numbers to it. In its dataset, 67% of users access AI services through non-corporate accounts on corporate devices. 45% of employees are now regular AI users, up from 15% the year before. Shadow AI is the third most common non-malicious insider action in the DLP dataset, a fourfold increase year over year. And the most common data type submitted to external models is source code.

What Shadow AI Looks Like

It looks like ordinary competence. Examples we find in real environments:

  • Law: a paralegal pastes a contract clause into a free chatbot to summarize it, including the client’s name and the counterparty.
  • Healthcare: an administrator asks a chatbot to rewrite a patient letter, pasting the original with identifiers in place.
  • Accounting: a staff accountant uploads a client’s general ledger export to a free tool to find anomalies.
  • Software: an engineer pastes proprietary source into a public model to explain an error, and the code becomes training data for a vendor.
  • Everyone: browser extensions that summarize pages, meeting recorders that transcribe and store audio, and phone apps syncing corporate mail.

None of these people think they are breaching confidentiality. They think they are being efficient, and often nobody has told them which tool is approved or why it matters.

Why Employees Do It

Four reasons, in order of frequency. The approved tool is slower or worse at the task. There is no approved tool, or nobody knows what it is. The request process takes weeks, so people route around it. And nobody explained the risk in terms of their actual work, so the privacy policy language did not land.

That last point is the one worth internalizing: shadow AI is a demand problem. If the sanctioned path is slow, people will find another. Blocking tools without providing a good alternative produces the same leaks with less visibility.

The Risks

  • Confidentiality: client data, deal terms, and source code leaving your control entirely.
  • Training and retention: many consumer tools reserve the right to use inputs for improvement, and retention periods are set by the vendor.
  • Regulated data: PHI, card data, or personal data crossing a boundary with no agreement and no record.
  • Intellectual property: source code and technical documentation are the highest-value material in the DLP data, and the easiest to paste.
  • Vendor breach: your data sits in a service with unknown security, and breach notification may reach you late or not at all.
  • Prompt injection: content the tool reads can carry instructions, which matters as soon as the tool can act rather than just answer.

Note what is not on that list: the model “learning” your secrets in a science-fiction sense. The realistic risk is mundane. Data in a service you did not vet, retained longer than you thought, disclosed in someone else’s incident.

How to Detect It Without Spying

You do not need keystroke logging. Five signals give most of the picture:

  • SSO and identity logs: OAuth grants to AI apps, new third-party consents, and sign-ins from unusual locations.
  • Egress and proxy logs: traffic to AI domains from corporate devices, by volume and by user.
  • Endpoint inventory: browser extensions and installed applications that were not in the standard image.
  • Expense reports: personal subscriptions to AI tools, which are the clearest evidence of unmet demand.
  • A short, anonymous survey asking which tools people use and why. It is faster than telemetry and more honest.

Whatever you deploy, check the employment-law constraints with counsel before monitoring individuals. The goal is a policy and a sanctioned path, not a surveillance program; the second destroys the reporting culture you need for real incidents.

What a Good AI Policy Contains

One page, five answers:

  1. Approved tools, named, with the enterprise account people should use.
  2. Prohibited data, described concretely: client identifiers, PHI, card data, source code, deal terms, credentials.
  3. Approval process for a new tool, with a named owner and a stated turnaround.
  4. Human review: which outputs require a named reviewer before they leave the firm.
  5. Incident reporting: what to do if data was pasted into the wrong place, and an assurance that reporting is not punished.

Publish it where people will see it, and revisit it when tools change. A policy nobody can find is the same as no policy.

Sanctioned Alternatives

  • Enterprise tenants of the tools people already use, with contractual terms that exclude training on your data and set retention.
  • Local models for confidential material, where data never leaves your network. See the rise of local AI inference.
  • Private retrieval over your own documents, with permissions inherited from the source system, so the assistant cannot answer with a document the user could not open.

The trade-off is real: local and private options cost more to run and are usually less capable at open-ended tasks. Say that out loud in the policy, so people understand why the approved tool exists.

Training That Changes Behavior

Annual slides do not change behavior. Short, role-specific scenarios do, and so does showing people the exact paste that would have leaked something. Ten minutes in a team meeting, with three real examples from their own workflow, beats a compliance module everyone clicks through.

Run a short refresher after any near miss, and make the reporting path obvious. Most shadow AI incidents that turn into real breaches are discovered weeks late, not because detection failed but because nobody reported the mistake.

Where to Start

Run the AI readiness check to see whether the controls exist. If you want the tooling, policy, and review steps assessed independently, an AI security assessment covers data leakage, guardrail evasion, and prompt injection. Consulting and implementation are on the AI services page, and the broader method is in the AI for business guide. For the attack class behind agent risk, read prompt injection and the 2026 AI security briefing.

Training for staff is available through our cybersecurity courses.

Schedule an AI security assessment or call 703-486-0200.

Frequently Asked Questions

Is using ChatGPT a breach?+

Not by itself. It becomes an incident when prohibited data is submitted, when the terms allow training on it, or when regulated data leaves your control without an agreement.

Can we block all AI tools?+

You can, and people will use their phones instead. Blocking without a sanctioned alternative reduces visibility, not usage.

Do we need a policy before training?+

Yes. Training without a policy tells people the risk exists but not what to do about it.

How do we detect it without monitoring everything?+

SSO and OAuth grants, egress logs, endpoint inventory, and expense reports. An anonymous survey is faster and more honest than telemetry.

What is a safe alternative?+

An enterprise tenant with no-training terms and a retention limit, a local model for confidential work, or private retrieval over your own documents.

Posted in AI, best practices, cybersecurity.