Get Free AI Implementation Playbook
.svg)
In May 2023, a group of senior engineers at Samsung needed to debug some faulty semiconductor source code. Rather than wait for an internal solution, they pasted the code directly into ChatGPT. A second engineer did the same with proprietary software designed to detect defective manufacturing equipment. A third recorded a confidential internal meeting on their phone, transcribed it, and uploaded the entire document to generate meeting minutes.
Three separate incidents, three different employees, all within weeks of each other.
Because they used the public version of ChatGPT, and because the platform's default policy uses prompts to train its models, Samsung's most sensitive intellectual property ended up on OpenAI's servers, as reported by Cybersecurity Dive. The company responded by banning all generative AI tools company-wide and capping upload sizes at 1,024 bytes per prompt while they worked to contain the damage.
None of those engineers were trying to cause harm. They were trying to move faster. That's Shadow AI, and it's already happening at your company.
Shadow AI refers to employees using AI tools, including LLMs, image generators, coding assistants, and open-source APIs, outside any IT governance or security framework. No approval, no oversight, no visibility.
It evolved from a familiar concept: Shadow IT, the practice of employees using unsanctioned software or devices. The key difference is what the technology does with your data. Shadow IT stores or transfers it. Shadow AI actively processes it, interprets it, and in many cases ingests it to train the underlying model. A file sitting on an unauthorized Dropbox account is a containable risk. Proprietary source code submitted to a public LLM may never fully leave that system.
Most security teams are focused on the wrong layer. They've audited vendor contracts, deployed monitoring tools, and tightened network access. Meanwhile, someone in finance is summarizing a client acquisition memo in ChatGPT, and someone in marketing just uploaded the customer list to generate campaign segments.
According to IBM research, 80% of American office workers now use AI professionally, but only 22% rely exclusively on tools their employer officially provisioned. Furthermore, Netskope's Cloud and Threat Report 2026 found that 47% of employees who use AI tools at work do so through personal, unmanaged accounts, meaning security teams have zero visibility into what those sessions contain. That's not a few rogue employees. That's a default behavior across your organization.
Before writing a policy, it helps to understand why Shadow AI spreads so consistently, because the reason directly shapes what an effective response looks like.
The same IBM research found that 97% of American office workers believe AI improves their productivity, with 75% reporting moderate to significant improvements in daily output. Nearly a third say it saves them up to six hours per week. When a free, browser-based tool eliminates hours of manual work and the official procurement process takes months, employees don't wait. Furthermore, among employees aged 18 to 24, 35% say they would likely use only personal AI tools for corporate work, actively refusing company-approved alternatives. For 30% of that same group, strict IT policies register not as a reasonable safeguard, but as an obstacle to getting their job done.
Organizational structure makes things worse. Nutanix research found that 82% of IT executives believe fragmentation between business units and central IT makes it extremely difficult to execute secure technology initiatives. When an engineering team needs an AI-assisted code review tool and IT's queue is already three months deep, that team goes and finds something on its own. Blocking access to specific tools doesn't change any of this dynamic. It just makes the behavior harder to see.
Most leaders picture a dramatic breach or a deliberate leak when they think about Shadow AI risk. The damage is more expensive and more gradual than that, and it falls into three distinct categories.
1. Data that can't be retrieved
When an employee submits proprietary information to a public LLM, it leaves the security perimeter immediately. Consumer AI platforms frequently use prompts as training data by default, unless a user explicitly opts out, which most don't know to do. Trade secrets, client data, internal strategy documents, unreleased financial forecasts: once submitted, they're out of your control. In Samsung's case, source code for semiconductor equipment could theoretically surface in a response generated for another user, including a direct competitor.
2. Violations that compound fast
According to Netskope's 2026 annual threat report, prompt volume sent to generative AI tools inside organizations grew sixfold in a single year, from an average of 3,000 prompts per month to 18,000. As a result, organizations now detect an average of 223 data policy violations per month tied to AI usage. Among the highest-risk organizations, that number exceeds 2,100 incidents monthly. The most common violations involve regulated data, source code, and intellectual property, often submitted through the same casual interfaces employees use for everything else.
3. Breach costs that run well above average
IBM's 2025 Cost of a Data Breach Report, based on research across 600 organizations in 17 industries, found that organizations with high Shadow AI involvement paid an average of $670,000 more per breach than those with low or no involvement. The primary cause of that premium is detection time: because security teams have no visibility into unsanctioned AI tools, containing a Shadow AI breach takes significantly longer than a standard incident. The same report found that 97% of organizations that experienced an AI-related breach had no proper AI access controls in place, and 63% had no AI governance policy at all.
There's also a regulatory dimension that compounds everything else. GDPR, HIPAA, CCPA, and the Gramm-Leach-Bliley Act weren't written with generative AI in mind, but they apply to it fully. The moment a healthcare administrator pastes patient notes into an unapproved LLM, Protected Health Information has been transmitted to a third party without a Business Associate Agreement. Most public LLM APIs don't offer BAAs or guarantee de-identification, meaning any prompt containing PHI is a direct federal violation. Healthcare breaches have averaged $7.42 million per incident for 14 consecutive years, the highest of any industry in the IBM report.
Samsung is the most widely documented case, but the pattern repeats across industries.
Banking
In February 2023, JPMorgan Chase restricted employee access to ChatGPT across the entire firm. As reported by Bloomberg, the decision reflected compliance concerns around third-party software: employees handling confidential client data and trading information were submitting it to a system with no contractual data protections. Within weeks, Bank of America, Goldman Sachs, Citigroup, Deutsche Bank, and Wells Fargo had all implemented similar restrictions. In every case, the discovery came after the fact. Employees were already using the tools before any governance existed.
Technology and Telecommunications
In May 2023, Apple restricted employees from using ChatGPT and GitHub Copilot, citing concerns that employees could inadvertently expose confidential product roadmaps or proprietary code. What makes Apple's response notable is what came alongside the restriction: the company simultaneously accelerated development of its own internal AI tools, a direct acknowledgment that the demand was legitimate and had to be met somewhere. Verizon followed with a company-wide ban, with its CEO citing Samsung's incident directly, noting that employees typing customer information or internal documents into ChatGPT could lose organizational control over that data entirely. Both stories were reported by Fortune.
The consistent sequence across all of them
In every documented case, the companies discovered the problem after their employees had already adopted the tools. Not one identified the risk in advance and built a governed alternative before enforcement became necessary. JPMorgan banned first, then built its own internal AI research program. Samsung banned, then developed its internal Gauss model. Apple restricted, then accelerated its own AI development. The sequence is always the same: adoption comes first, governance comes second, and the gap between the two is where the exposure lives.
Standard DLP and CASB architectures were built for a different threat model. They detect file transfers, flag unusual data volumes, and block known malicious domains. They were not designed to catch an employee typing proprietary revenue projections into a chat interface over an encrypted HTTPS connection.
Effective Shadow AI governance requires capabilities most organizations haven't yet built. Secure Web Gateways need to be configured to decrypt and inspect SSL/TLS traffic, not just filter at the URL level, in order to detect data being submitted to generative AI interfaces in real time. DLP rules, furthermore, need to recognize the context of a prompt: proprietary code, financial identifiers, or PII in conversational format, not just as a structured file attachment.
Beyond network controls, organizations need active discovery tools that scan codebases and infrastructure for unauthorized AI components: hidden API calls to public LLMs, open-source models running on corporate hardware, autonomous agents operating without anyone's knowledge. Shadow AI isn't always a browser tab. Sometimes it's a containerized model a developer spun up six months ago that has been quietly processing internal data ever since. An AI Bill of Materials closes the loop on this by creating a living inventory of every sanctioned model, mapping its training data, version, and integration points across the organization. When a specific model or API is found to be compromised or non-compliant, you can identify every deployment location and act immediately, rather than guessing at the scope.
Organizations that successfully contain Shadow AI share one thing in common. They stopped treating it as a security problem to block and started treating it as a demand problem to meet. With that framing, the path forward becomes more concrete.
Step 1: Find out what's already running
Before writing a single policy, audit your actual environment. Scan your codebase and infrastructure for hidden API calls to public LLMs, unauthorized AI components, and models running in containers without IT knowledge. This step usually surprises leadership, not because the tools are obscure, but because there are so many of them.
Step 2: Understand why employees are using them
Map the specific workflows where Shadow AI is happening. Which teams are using it, for what tasks, and what capability gap is driving the behavior? This isn't an investigation. It's product research. The answer tells you exactly what a sanctioned alternative needs to do in order to be genuinely chosen over the unauthorized tool.
Step 3: Build something employees will actually use
This is where most governance efforts fail. Organizations write policies, block domains, and send warning emails, then wonder why the behavior continues. A restriction without an alternative just pushes the behavior underground. The sanctioned AI environment has to be genuinely capable: fast, connected to internal data, and easier to use than whatever employees were doing on their own. If it isn't, adoption won't follow.
Step 4: Build compliance into the architecture, not on top of it
Data privacy controls, access management, and regulatory compliance need to be structural from day one, not applied as a layer after the fact. For healthcare organizations, that means HIPAA-compliant infrastructure, proper BAAs with cloud providers, and de-identification protocols built into how the system handles data. For financial services, it means audit trails, access tiering, and model governance from the first day of deployment.
Step 5: Maintain visibility over time
Shadow AI isn't a one-time problem to solve. Models update, new tools emerge, and employees find new workarounds. Ongoing monitoring, an up-to-date AI Bill of Materials, and a cross-functional governance committee that includes IT, Legal, Compliance, and business unit leads are what keep the problem contained long after the initial work is done.
If you're working through the steps above and find that the internal capacity to execute isn't there, that's a common inflection point. Most organizations either lack the engineering depth to build compliant AI infrastructure from scratch, or they've already had an incident and need to move faster than an internal build timeline allows.
This is where we come in. At NineTwoThree, we've delivered over 150 enterprise AI projects, and Shadow AI governance runs through nearly all of them. The organizations making the most progress aren't the ones with the strictest policies. They're the ones that replaced the problem with something better.
In practice, that means building localized AI Knowledge Bases using Retrieval-Augmented Generation: systems that give employees a capable, conversational interface for working with internal data, while the underlying model never touches the public internet and draws answers exclusively from verified internal repositories. The client owns the code and the infrastructure outright.
For Consumer Reports, for instance, we built a system that is structurally prevented from generating any information that doesn't exist in their verified database. We then red-teamed it specifically to find and close any gaps in that constraint.
You can read more about this case study in our resource:
For clients in healthcare and financial services, HIPAA and SOC 2 requirements are built into the architecture from the start: proper data de-identification, principle-of-least-privilege access controls, and legally executed Business Associate Agreements with cloud infrastructure providers.
Every month without a Shadow AI governance strategy, your organization is generating hundreds of AI policy violations, transmitting prompts containing sensitive data to systems you don't control, and accumulating regulatory exposure that compounds with each interaction.
The Samsung engineers who leaked semiconductor source code weren't trying to cause harm. They were debugging faster. JPMorgan, Apple, Verizon, Goldman Sachs: they all found out the same way, after the fact, when the damage was already harder to contain. Most companies will address Shadow AI eventually. A few will do it before an incident forces their hand.
If you want to understand what your current exposure looks like and where to start, we're happy to talk it through.
If you’re interested in how to create an AI solution for your team that would not only be used but also save you a fortune, you can download our AI Strategy Toolkit.
In May 2023, a group of senior engineers at Samsung needed to debug some faulty semiconductor source code. Rather than wait for an internal solution, they pasted the code directly into ChatGPT. A second engineer did the same with proprietary software designed to detect defective manufacturing equipment. A third recorded a confidential internal meeting on their phone, transcribed it, and uploaded the entire document to generate meeting minutes.
Three separate incidents, three different employees, all within weeks of each other.
Because they used the public version of ChatGPT, and because the platform's default policy uses prompts to train its models, Samsung's most sensitive intellectual property ended up on OpenAI's servers, as reported by Cybersecurity Dive. The company responded by banning all generative AI tools company-wide and capping upload sizes at 1,024 bytes per prompt while they worked to contain the damage.
None of those engineers were trying to cause harm. They were trying to move faster. That's Shadow AI, and it's already happening at your company.
Shadow AI refers to employees using AI tools, including LLMs, image generators, coding assistants, and open-source APIs, outside any IT governance or security framework. No approval, no oversight, no visibility.
It evolved from a familiar concept: Shadow IT, the practice of employees using unsanctioned software or devices. The key difference is what the technology does with your data. Shadow IT stores or transfers it. Shadow AI actively processes it, interprets it, and in many cases ingests it to train the underlying model. A file sitting on an unauthorized Dropbox account is a containable risk. Proprietary source code submitted to a public LLM may never fully leave that system.
Most security teams are focused on the wrong layer. They've audited vendor contracts, deployed monitoring tools, and tightened network access. Meanwhile, someone in finance is summarizing a client acquisition memo in ChatGPT, and someone in marketing just uploaded the customer list to generate campaign segments.
According to IBM research, 80% of American office workers now use AI professionally, but only 22% rely exclusively on tools their employer officially provisioned. Furthermore, Netskope's Cloud and Threat Report 2026 found that 47% of employees who use AI tools at work do so through personal, unmanaged accounts, meaning security teams have zero visibility into what those sessions contain. That's not a few rogue employees. That's a default behavior across your organization.
Before writing a policy, it helps to understand why Shadow AI spreads so consistently, because the reason directly shapes what an effective response looks like.
The same IBM research found that 97% of American office workers believe AI improves their productivity, with 75% reporting moderate to significant improvements in daily output. Nearly a third say it saves them up to six hours per week. When a free, browser-based tool eliminates hours of manual work and the official procurement process takes months, employees don't wait. Furthermore, among employees aged 18 to 24, 35% say they would likely use only personal AI tools for corporate work, actively refusing company-approved alternatives. For 30% of that same group, strict IT policies register not as a reasonable safeguard, but as an obstacle to getting their job done.
Organizational structure makes things worse. Nutanix research found that 82% of IT executives believe fragmentation between business units and central IT makes it extremely difficult to execute secure technology initiatives. When an engineering team needs an AI-assisted code review tool and IT's queue is already three months deep, that team goes and finds something on its own. Blocking access to specific tools doesn't change any of this dynamic. It just makes the behavior harder to see.
Most leaders picture a dramatic breach or a deliberate leak when they think about Shadow AI risk. The damage is more expensive and more gradual than that, and it falls into three distinct categories.
1. Data that can't be retrieved
When an employee submits proprietary information to a public LLM, it leaves the security perimeter immediately. Consumer AI platforms frequently use prompts as training data by default, unless a user explicitly opts out, which most don't know to do. Trade secrets, client data, internal strategy documents, unreleased financial forecasts: once submitted, they're out of your control. In Samsung's case, source code for semiconductor equipment could theoretically surface in a response generated for another user, including a direct competitor.
2. Violations that compound fast
According to Netskope's 2026 annual threat report, prompt volume sent to generative AI tools inside organizations grew sixfold in a single year, from an average of 3,000 prompts per month to 18,000. As a result, organizations now detect an average of 223 data policy violations per month tied to AI usage. Among the highest-risk organizations, that number exceeds 2,100 incidents monthly. The most common violations involve regulated data, source code, and intellectual property, often submitted through the same casual interfaces employees use for everything else.
3. Breach costs that run well above average
IBM's 2025 Cost of a Data Breach Report, based on research across 600 organizations in 17 industries, found that organizations with high Shadow AI involvement paid an average of $670,000 more per breach than those with low or no involvement. The primary cause of that premium is detection time: because security teams have no visibility into unsanctioned AI tools, containing a Shadow AI breach takes significantly longer than a standard incident. The same report found that 97% of organizations that experienced an AI-related breach had no proper AI access controls in place, and 63% had no AI governance policy at all.
There's also a regulatory dimension that compounds everything else. GDPR, HIPAA, CCPA, and the Gramm-Leach-Bliley Act weren't written with generative AI in mind, but they apply to it fully. The moment a healthcare administrator pastes patient notes into an unapproved LLM, Protected Health Information has been transmitted to a third party without a Business Associate Agreement. Most public LLM APIs don't offer BAAs or guarantee de-identification, meaning any prompt containing PHI is a direct federal violation. Healthcare breaches have averaged $7.42 million per incident for 14 consecutive years, the highest of any industry in the IBM report.
Samsung is the most widely documented case, but the pattern repeats across industries.
Banking
In February 2023, JPMorgan Chase restricted employee access to ChatGPT across the entire firm. As reported by Bloomberg, the decision reflected compliance concerns around third-party software: employees handling confidential client data and trading information were submitting it to a system with no contractual data protections. Within weeks, Bank of America, Goldman Sachs, Citigroup, Deutsche Bank, and Wells Fargo had all implemented similar restrictions. In every case, the discovery came after the fact. Employees were already using the tools before any governance existed.
Technology and Telecommunications
In May 2023, Apple restricted employees from using ChatGPT and GitHub Copilot, citing concerns that employees could inadvertently expose confidential product roadmaps or proprietary code. What makes Apple's response notable is what came alongside the restriction: the company simultaneously accelerated development of its own internal AI tools, a direct acknowledgment that the demand was legitimate and had to be met somewhere. Verizon followed with a company-wide ban, with its CEO citing Samsung's incident directly, noting that employees typing customer information or internal documents into ChatGPT could lose organizational control over that data entirely. Both stories were reported by Fortune.
The consistent sequence across all of them
In every documented case, the companies discovered the problem after their employees had already adopted the tools. Not one identified the risk in advance and built a governed alternative before enforcement became necessary. JPMorgan banned first, then built its own internal AI research program. Samsung banned, then developed its internal Gauss model. Apple restricted, then accelerated its own AI development. The sequence is always the same: adoption comes first, governance comes second, and the gap between the two is where the exposure lives.
Standard DLP and CASB architectures were built for a different threat model. They detect file transfers, flag unusual data volumes, and block known malicious domains. They were not designed to catch an employee typing proprietary revenue projections into a chat interface over an encrypted HTTPS connection.
Effective Shadow AI governance requires capabilities most organizations haven't yet built. Secure Web Gateways need to be configured to decrypt and inspect SSL/TLS traffic, not just filter at the URL level, in order to detect data being submitted to generative AI interfaces in real time. DLP rules, furthermore, need to recognize the context of a prompt: proprietary code, financial identifiers, or PII in conversational format, not just as a structured file attachment.
Beyond network controls, organizations need active discovery tools that scan codebases and infrastructure for unauthorized AI components: hidden API calls to public LLMs, open-source models running on corporate hardware, autonomous agents operating without anyone's knowledge. Shadow AI isn't always a browser tab. Sometimes it's a containerized model a developer spun up six months ago that has been quietly processing internal data ever since. An AI Bill of Materials closes the loop on this by creating a living inventory of every sanctioned model, mapping its training data, version, and integration points across the organization. When a specific model or API is found to be compromised or non-compliant, you can identify every deployment location and act immediately, rather than guessing at the scope.
Organizations that successfully contain Shadow AI share one thing in common. They stopped treating it as a security problem to block and started treating it as a demand problem to meet. With that framing, the path forward becomes more concrete.
Step 1: Find out what's already running
Before writing a single policy, audit your actual environment. Scan your codebase and infrastructure for hidden API calls to public LLMs, unauthorized AI components, and models running in containers without IT knowledge. This step usually surprises leadership, not because the tools are obscure, but because there are so many of them.
Step 2: Understand why employees are using them
Map the specific workflows where Shadow AI is happening. Which teams are using it, for what tasks, and what capability gap is driving the behavior? This isn't an investigation. It's product research. The answer tells you exactly what a sanctioned alternative needs to do in order to be genuinely chosen over the unauthorized tool.
Step 3: Build something employees will actually use
This is where most governance efforts fail. Organizations write policies, block domains, and send warning emails, then wonder why the behavior continues. A restriction without an alternative just pushes the behavior underground. The sanctioned AI environment has to be genuinely capable: fast, connected to internal data, and easier to use than whatever employees were doing on their own. If it isn't, adoption won't follow.
Step 4: Build compliance into the architecture, not on top of it
Data privacy controls, access management, and regulatory compliance need to be structural from day one, not applied as a layer after the fact. For healthcare organizations, that means HIPAA-compliant infrastructure, proper BAAs with cloud providers, and de-identification protocols built into how the system handles data. For financial services, it means audit trails, access tiering, and model governance from the first day of deployment.
Step 5: Maintain visibility over time
Shadow AI isn't a one-time problem to solve. Models update, new tools emerge, and employees find new workarounds. Ongoing monitoring, an up-to-date AI Bill of Materials, and a cross-functional governance committee that includes IT, Legal, Compliance, and business unit leads are what keep the problem contained long after the initial work is done.
If you're working through the steps above and find that the internal capacity to execute isn't there, that's a common inflection point. Most organizations either lack the engineering depth to build compliant AI infrastructure from scratch, or they've already had an incident and need to move faster than an internal build timeline allows.
This is where we come in. At NineTwoThree, we've delivered over 150 enterprise AI projects, and Shadow AI governance runs through nearly all of them. The organizations making the most progress aren't the ones with the strictest policies. They're the ones that replaced the problem with something better.
In practice, that means building localized AI Knowledge Bases using Retrieval-Augmented Generation: systems that give employees a capable, conversational interface for working with internal data, while the underlying model never touches the public internet and draws answers exclusively from verified internal repositories. The client owns the code and the infrastructure outright.
For Consumer Reports, for instance, we built a system that is structurally prevented from generating any information that doesn't exist in their verified database. We then red-teamed it specifically to find and close any gaps in that constraint.
You can read more about this case study in our resource:
For clients in healthcare and financial services, HIPAA and SOC 2 requirements are built into the architecture from the start: proper data de-identification, principle-of-least-privilege access controls, and legally executed Business Associate Agreements with cloud infrastructure providers.
Every month without a Shadow AI governance strategy, your organization is generating hundreds of AI policy violations, transmitting prompts containing sensitive data to systems you don't control, and accumulating regulatory exposure that compounds with each interaction.
The Samsung engineers who leaked semiconductor source code weren't trying to cause harm. They were debugging faster. JPMorgan, Apple, Verizon, Goldman Sachs: they all found out the same way, after the fact, when the damage was already harder to contain. Most companies will address Shadow AI eventually. A few will do it before an incident forces their hand.
If you want to understand what your current exposure looks like and where to start, we're happy to talk it through.
If you’re interested in how to create an AI solution for your team that would not only be used but also save you a fortune, you can download our AI Strategy Toolkit.
