Shadow AI Exposed (1/2): What organizations don't know about the AI tools their employees use

When I look at how data actually leaves Microsoft 365 environments today, the pattern I see most often isn’t compromised credentials or misconfigured sharing settings. It’s employees doing their jobs, in tools that IT has never seen.

Most organizations I work with don’t have a shadow AI problem in the sense of a known, contained risk they’re managing. They have a visibility problem: workflows that depend on external AI tools have formed organically, without going through IT, and the data flowing through those workflows is invisible to every control the organization has in place.

That’s the structure of this problem. Not malicious insiders. Not sophisticated attacks. Ordinary employees doing legitimate work with tools that are faster or better than what IT provides, and nobody has a clear picture of what data is involved.

This is part one of two. It covers what shadow AI looks like as a data risk: why employees use unauthorized tools, what categories of data end up in them, and why the standard security stack doesn’t catch it. Part two covers what a governance program looks like in practice.

Key Takeaways

• Most organizations don’t have a shadow AI problem they’re managing. They have a visibility problem: the tools are already in use and nobody knows which ones
• The biggest blind spot isn’t which tools employees use. It’s that most of the data flows through personal accounts, which sit entirely outside your DLP and CASB policies
• Shadow AI incidents don’t start with someone deciding to take a risk. They start with someone deciding to get work done
• Blocking AI tools without providing a sanctioned alternative doesn’t reduce the behavior. It makes it less visible

Why employees use AI tools that IT hasn’t approved

The reason isn’t carelessness, and it’s rarely a deliberate policy violation. In most organizations I work with, there is no policy. The tools arrived before anyone thought to govern them.

What drives adoption is straightforward. External AI tools are faster and produce better output than most internal alternatives. Employees find them, use them for a task, get good results, and incorporate them into their workflow. That process happens at the individual level, then at the team level, long before it surfaces as an organizational question. By the time IT is aware there’s a usage question to answer, the tools are already embedded in how people work.

What I find in practice is that the awareness gap runs in both directions. Employees often don’t know what data they’re not supposed to share with external tools, because nobody has told them. IT doesn’t know which tools employees are using, because nobody has mapped it. The result is a large volume of unsupervised data movement that nobody considers a problem until something goes wrong.

Shadow AI use is also self-reinforcing. The tools are too useful to stop using, and telling a manager about them feels risky: it can look like an admission that the work would otherwise be too slow. So the use continues, and it stays invisible.

Part of what makes this hard to scope is that “AI tool” has become a broad category. Harmonic Security analyzed enterprise usage across Q1 2025 and found the average organization interacted with 254 AI-enabled applications. That number isn’t 254 ChatGPT-style tools. It includes every application that has incorporated a generative AI feature: LinkedIn’s writing suggestions, Canva’s AI image generation, Grammarly’s rewriting engine, Slack AI’s message summaries, Microsoft 365 Copilot, coding assistants like GitHub Copilot and Replit, and dozens of others. Most employees don’t think of these as “AI tools” at all. They’re just features inside products they already use. And most of them aren’t on anyone’s approved list, because nobody thought to make them a governance decision.

The number is based on enterprise environments, but smaller organizations aren’t insulated. Research from Reco AI across 2025 shows that companies with 11 to 50 employees have the highest shadow AI density of any company size: more unauthorized AI tool interactions per user than mid-market or large enterprises. The pattern is familiar: smaller IT teams, less tooling, faster informal adoption. The NSW Reconstruction Authority that appears later in this article had roughly 215 employees. It isn’t an edge case.

The BYOD layer adds another dimension that most organizations don’t account for. When employees use their personal phones for work, every AI feature on that device is in scope: Siri summarizing a message thread, Google Assistant reading a calendar item aloud, the AI writing assistant built into the phone’s keyboard. None of those interactions appear in any enterprise log. Nobody submits a request to use them. They’re ambient.

What data actually ends up in those tools

What ends up in those tools follows a predictable pattern. Legal and financial documents are the most common: contracts, invoices, internal financial reports. Source code is a close second. Beyond that you find HR records, strategic plans, and customer data. The mix reflects the tasks employees are actually trying to complete. It’s not random. And a significant portion of it moves through personal accounts, which sit entirely outside any enterprise DLP or CASB policy boundary.

The personal account figure is the one most organizations underestimate. When employees use AI tools through a personal account, the data they submit is invisible to the organization’s security stack. There’s no way to detect it, no way to enforce policy against it, and no record of it in any log.

The nature of the data submitted follows a consistent pattern regardless of category. Employees don’t paste fragments. They paste what the tool needs to do its job: the full contract, the complete function, the entire spreadsheet. AI tools reward completeness. The actual data exposure per incident is almost always larger than the task description would suggest.

How it actually happens: the NSW Reconstruction Authority

In March 2025, a contractor working for NSW Reconstruction Authority in Australia was processing applications under the Northern Rivers Resilient Homes Program, a disaster recovery initiative for flood-affected homeowners. To manage the workload more efficiently, she uploaded a Microsoft Excel spreadsheet to ChatGPT.

The spreadsheet contained 12,000 rows of applicant data: full names, contact details, residential and mailing addresses, dates of birth, health information, and financial commentary. The final confirmed count of affected individuals was 2,031. The data had been submitted to OpenAI’s servers via the standard consumer interface, with no enterprise data processing agreement in place.

NSW Reconstruction Authority disclosed the breach on October 6, 2025, seven months after the incident. The 2,031 affected people received notification letters through ID Support NSW. Most of them were flood disaster victims who had trusted a government agency with some of the most sensitive information they hold: health status, financial situation, home address.

The practical consequence is harder to contain than the breach itself. NSW Reconstruction Authority’s own public breach register lists the exposure period as “ongoing.” That’s not bureaucratic language. It means the authority cannot confirm that the data was deleted from OpenAI’s systems. No public statement from OpenAI about this incident has been found, and there is no confirmed information about what happened to the data. Without an enterprise agreement, there are no contractual obligations to delete it, no audit rights, and no way to know whether it was included in model training.

Seven months after uploading a spreadsheet to help process a government backlog, 2,031 flood victims received a letter telling them their health data was in a system nobody controls, and that the government itself cannot say what happened to it.

What actually happened to those 2,031 people? No documented misuse has been reported. NSW Reconstruction Authority states there is no evidence the data was accessed by a third party. Cyber Security NSW has been monitoring the dark web since the incident and found nothing. Nobody stole the data in any conventional sense, and no fraud or identity theft has been attributed to it.

But that’s not the same as the data being safe. Whether it ended up in a training dataset, whether it could surface in a model’s responses, whether it was cached or retained in any form. None of that has a definitive answer. The question doesn’t close. That’s what “ongoing” means on the breach register.

That’s the consequence of shadow AI. Not a headline breach. Not a criminal actor. A contractor doing a difficult job with the best tool available, and a data trail that can’t be traced, recalled, or confirmed safe.

Why security tools don’t catch it

The visibility problem isn’t a gap you can close with configuration. It’s structural.

In the tenants I work with, there is no log entry for “employee uploaded contract to ChatGPT.” That event doesn’t exist in Defender, Purview, or Entra ID unless you’ve specifically configured Entra Internet Access for shadow AI detection. Even then, what you see is a signal: traffic to an AI service. Not the content. You know the destination. You don’t know what went.

CASB tools monitor the applications you’ve sanctioned. They inspect traffic to your approved SaaS stack. They have no visibility into what happens in a browser tab on a personal Google or Microsoft account. That’s not a misconfiguration. That’s how CASB is designed: it enforces policy on corporate-managed identities and sanctioned services. Shadow AI largely doesn’t use either.

DLP policy runs into the same boundary from a different angle. Enterprise DLP is built to detect known patterns: document classification labels, PII formats, credit card numbers, moving toward known risky destinations. A contract summarized in a chat prompt doesn’t match those rules. Source code pasted into a chat interface doesn’t trigger a keyword filter. The data is sensitive. The signature for that specific act isn’t there.

What makes this particularly difficult to address after the fact is the detection window. When there’s no alert, there’s no investigation. By the time anyone thinks to look, usually during an incident review rather than a routine audit, the data has been on the external service for months. The NSW breach sat undetected for seven months in a government environment with active security oversight.

What this means for how you approach the problem

When I advise organizations on this, the instinct is almost always to block. Block ChatGPT at the firewall. Restrict personal accounts. Flag AI domains in the URL filter.

That’s not wrong, and in some configurations it’s a necessary first step. But I’ve seen what happens when organizations block without providing an alternative: the behavior shifts, it doesn’t stop. People use their phone’s hotspot. They use a browser extension that proxies through a different domain. They find a tool the URL filter hasn’t categorized yet. Harmonic’s 2025 data shows the average organization encounters 23 previously unknown AI tools per quarter. That number holds even in environments with active controls.

The reason is the same as the reason shadow AI exists in the first place. There’s a productivity gap, and employees fill it. Blocking one tool doesn’t close the gap. It just makes the fill less visible.

The NSW contractor wasn’t trying to circumvent anything. There was no policy to circumvent. The data left the building because the gap between what she needed and what the organization provided was filled by ChatGPT, and nobody had thought to make that a decision point.

Part two covers what closing that gap looks like: an approved AI catalog, DLP policy structured for AI-specific data patterns, and how to address the personal account problem that technical controls alone won’t reach. If you’re working with Purview and Entra Internet Access, the previous article on blocking shadow AI with Microsoft tools covers the detection layer. The governance layer is what makes it sustainable.

Frequently Asked Questions

Does uploading company data to ChatGPT always count as a data breach?

Not automatically. Whether it qualifies depends on your jurisdiction, the data type involved, and whether the provider’s processing terms meet your legal obligations. In the EU, submitting personal data without a valid data processing agreement can trigger GDPR notification requirements. The NSW incident involved health information and personal identifiers under Australian privacy law, which triggered the formal mandatory notification process. The practical risk is the same regardless of the legal classification: data leaving the organization without your knowledge or control.

If we block AI tools company-wide, doesn’t that solve the problem?

Blocking addresses the most visible surface, but not the underlying behavior. Employees find other routes: personal devices, browser extensions, tools the filter hasn’t caught yet. Harmonic’s data shows the average organization encounters 23 previously unknown AI tools per quarter, even with controls in place. A blocking strategy without a sanctioned alternative shifts the shadow AI use to less visible methods. The data still leaves. You just stop seeing where it goes.

Which data categories carry the most risk in shadow AI scenarios?

Legal and financial documents are the most commonly submitted sensitive data in enterprise AI use at 30.8% of sensitive submissions, followed by source code at 10.1% (Harmonic, 2025). Both carry significant IP and competitive risk if retained on external servers without a data processing agreement. What makes the exposure larger in practice is that employees submit complete documents, not excerpts. They share exactly what the tool needs to be useful.

---

Shadow AI isn’t primarily a security problem. It’s a governance gap: the space between what employees need and what the organization has provided, filled by tools that nobody is watching.

Shadow AI incidents don’t look unusual when they happen. The data leaves not because someone decided to take a risk, but because nobody decided anything at all. That’s what makes them hard to prevent and harder to contain after the fact.

Part two addresses what you do about it: building a governance program that closes the gap rather than just blocking one entrance to it.