Twenty days. That’s how long it took for a single, well-intentioned productivity decision to turn into one of the most cited AI governance failures on record.
In March 2023, Samsung’s semiconductor division gave engineers the green light to use ChatGPT. By the time the month was out, the company was scrambling to contain three separate incidents of proprietary data walking out the front door, and the front door was a public chatbot with no obligation to give it back.
The Samsung case gets told often, usually as a cautionary anecdote. What it deserves is closer treatment: not just what happened, but why the semiconductor industry’s specific exposure made the incident so severe, why “the data is gone and there’s nothing you can do about it” was true in a way most employees never think through, and what a functioning AI governance program, mapped to the standards enterprises are now being held to, actually looks like in practice.
Watch the full case breakdown below, or keep reading for the regulatory context and the governance controls that would have stopped this before it started.
Why Chip Design IP Made This Worse Than a Typical Leak
Not every data leak carries the same weight, and the Samsung incident sits near the top of the scale because of what the semiconductor industry actually is. Chip manufacturing is measured in nanometers, and the source code governing measurement, defect detection, and yield sits behind years of R&D investment and enormous competitive stakes.
A leaked customer list is a compliance problem. Leaked fabrication and defect-detection code is a trade-secret problem: the kind that can shift competitive position in an industry where a handful of companies control global supply.
That distinction matters for how organizations should triage AI risk. A generic “don’t paste confidential information” policy treats a marketing draft and a chip defect algorithm as the same category of risk.
They aren’t. Mature AI governance programs classify data by sensitivity tier before they write a single acceptable-use rule, because the controls that are proportionate for internal memos are wildly insufficient for IP that took a decade to build.
The Mechanism: How Typing Into a Chatbot Becomes a Permanent Leak
The part of this story that trips people up isn’t the “what”: engineers pasting code into a chatbot is an easy scenario to picture. It’s the “why can’t you just delete it.” In 2023, the terms of service most public AI tools operated under allowed submitted content to be used to improve the underlying model unless an organization had a specific enterprise agreement stating otherwise. Once Samsung’s engineers hit enter, that source code and those meeting transcripts were sitting on infrastructure Samsung didn’t control, under terms Samsung hadn’t negotiated.
Samsung’s response, once the scope became clear, was to move fast: first restricting how much text employees could enter into ChatGPT, then banning generative AI tools on company devices outright by May 2023, a decision reported by Forbes at the time as one of the first major corporate crackdowns on generative AI tools following a confirmed leak.
This is the technical reality behind the term AI governance professionals use for this failure mode: AI data leakage, meaning confidential information that escapes an organization through an AI tool, submitted by the organization’s own people rather than through a hack or breach. There’s no intrusion to detect, no malware signature, no attacker to attribute it to.
The leak is authorized at the moment it happens, which is exactly why perimeter security tools built to catch external attackers miss it entirely, and why this category of risk needs its own controls rather than an extension of existing cybersecurity monitoring.
Where This Sits Under Today’s Governance Standards
Samsung’s incident predates most of the formal frameworks now used to evaluate exactly this kind of failure, which makes it a useful test case for how those frameworks would actually apply.
Under ISO/IEC 42001, the international standard for AI management systems, an organization is expected to maintain a live inventory of AI systems in use, including tools employees have adopted without central approval, and to have controls in place that prevent, not just document, policy violations. A written acceptable-use policy without an enforcement mechanism does not meet that bar; auditors increasingly treat policy-without-enforcement as its own finding.
The EU AI Act adds a second layer of exposure that many organizations underestimate: if unsanctioned “shadow AI” use touches a high-risk use case, an organization can become a deployer with concrete legal obligations under the Act without ever having made that decision deliberately.
In the US, state-level AI legislation is increasingly following the same logic: treating the absence of a documented AI usage policy and inventory as a governance gap regulators can point to directly, independent of whether a leak has actually occurred yet.
Frameworks like the NIST AI Risk Management Framework reinforce the same point from a different angle: governance is expected to be continuous and measurable, not a policy document filed away after it’s written. The scale of the underlying problem has only grown since 2023.
Recent industry surveys of cybersecurity leaders have found a majority of organizations suspect or have direct evidence of employees using prohibited generative AI tools, and current forecasts suggest a large share of enterprises will experience a security or compliance incident tied to unauthorized shadow AI use before the end of the decade. Samsung wasn’t an outlier. It was early.
Professionals looking to build broader expertise in AI governance can explore the Certified Professional in AI Governance (CPAIG), which covers AI risk, lifecycle governance, policy development, incident response, and regulatory requirements.
The Four Controls and What They Look Like Done Properly
The video outlines four governance controls that would have significantly reduced Samsung’s exposure. Each one maps to a specific, auditable practice, not just a good intention.
An AI Acceptable Use Policy needs to name categories, not just say “be careful.” Source code, customer data, unreleased product details, and meeting content should be explicitly listed as prohibited inputs to public AI tools, with the policy itself mapped to the framework the organization is accountable to (NIST AI RMF, ISO 42001, or sector-specific rules) so it survives an audit rather than existing as a standalone document nobody references again.
Employee awareness training has to address the specific misconception that caused Samsung’s incidents: that a chatbot conversation is private the way an internal tool is private. None of the three engineers involved were acting maliciously. They were doing their jobs faster with a tool their employer had just approved. A short, concrete training module on where submitted text actually goes closes that gap far more effectively than a policy document employees skim once.
Technical controls that block sensitive data before it leaves exist precisely because policy compliance decays under deadline pressure. Data loss prevention tooling that can recognize source code patterns, customer PII, or confidential document formats and block submission to external AI endpoints turns “employees are supposed to know better” into an actual control an auditor can test.
A safe, sanctioned alternative closes the loop. Banning AI tools without giving employees a governed alternative doesn’t eliminate the underlying demand; it pushes usage to personal devices where an organization has zero visibility, which is worse than the original problem. Samsung’s own response, after the initial ban, was to build an internal AI tool with proper data controls rather than rely on prohibition indefinitely.
A Practical Checklist for Your Own Organization
Before your organization has its own version of this story, it’s worth running through the questions a governance review would ask:
- Do you have a current, accurate inventory of every AI tool in use, including free-tier tools and AI features embedded inside SaaS products employees already have access to?
- Is your acceptable-use policy specific about data categories, or does it rely on general language like “use good judgment”?
- Do you have a technical control (not just a policy) that can detect and block sensitive data before it reaches an external AI endpoint?
- Have employees been trained on how public AI tools actually handle submitted data, specifically and recently, not as a one-time onboarding item?
- If you banned or restricted a tool, did you also provide a sanctioned alternative, or did you just move the risk somewhere you can’t see it?
If more than one of those has an uncomfortable answer, that’s the gap an incident will eventually find.
The Real Lesson Isn’t About ChatGPT
It’s tempting to read the Samsung case as a story about one company and one chatbot in 2023. The more useful reading is structural: three careful, non-malicious employees created a major IP exposure not because they broke a rule they knew about, but because no governance layer existed to catch the risk before it became irreversible. That’s the gap AI governance programs exist to close: inventory, policy, enforcement, and a viable alternative, built before the incident, not drafted in response to it.
If you’re working through what an AI acceptable use policy should actually contain for your organization, our short course walks through the process clause by clause.
And if this kind of incident analysis is useful, the rest of our AI governance case study series covers failures across retail, hiring, legal, and public sector AI deployments, each with the same structure: what happened, why it happened, and the controls that would have stopped it.
The Samsung incident shows how governance gaps can allow employees to create serious exposure through AI tools. Another example is Google’s earthquake alert system, where the governance questions are tied to the performance and oversight of an AI system in a high-impact setting.
