Samsung, ChatGPT and corporate secrets: the data leak that did not look like one

How an ordinary copy-paste into a chatbot exposed one of the most overlooked risks of AI at work.

In 2023, some Samsung employees did something that millions of people do every day.

They took material they were working on.

They copied it.

They pasted it into ChatGPT.

And they asked the AI for help.

They were not trying to steal information from the company.

They had not clicked a phishing link.

They had not installed malware.

They had not lost a password.

They were simply trying to work faster.

That is exactly what makes the case worth examining.

According to reports published at the time, employees in Samsung's semiconductor division entered sensitive company information into ChatGPT in three separate incidents. One employee uploaded source code from an internal program to ask for help fixing an error. Another used code related to identifying faulty equipment and asked the chatbot to optimize it. A third converted a recording of an internal meeting into text and sent it to the chatbot to create minutes.

A few weeks later, Samsung intervened.

In May 2023, the company temporarily restricted the use of generative AI tools such as ChatGPT, Google Bard and Bing on company devices. The reported concern was that information sent to external services could be difficult to retrieve or delete after leaving the company infrastructure.

The most interesting point is not that Samsung restricted ChatGPT.

It is understanding how the data left the company.

The simplest data leak does not look like a data leak

When we think about information leakage, we usually imagine an attack.

An exposed database.

A vulnerability.

Ransomware.

A malicious employee.

Generative AI introduces another possibility.

Data can leave the company perimeter through a perfectly ordinary action:

copy → paste → send

For the person doing the work, the gesture is almost invisible.

There is a piece of code that does not work.

They paste it into the AI.

They receive an explanation.

The problem is solved.

From a productivity perspective, this is excellent.

From a data-governance perspective, something much more important has happened:

company information has been transferred to another system.

That distinction matters.

A conversational interface makes a chatbot feel like a colleague we can ask for help.

Technically, however, we are sending information to a software service.

The problem is not limited to source code

The information documented in the Samsung case was primarily confidential company information, such as source code and internal content.

It would therefore be inaccurate to turn the case into a story only about personal data protection.

But change the industry and the same issue immediately applies to PII.

Imagine a lawyer who needs to understand a contract clause quickly.

They copy the contract into an LLM and ask:

Summarize the main obligations of the parties and identify any problematic clauses.

That document might contain:

• names;
• addresses;
• tax identifiers;
• email addresses;
• telephone numbers;
• bank details;
• financial information;
• information about a dispute.

Or consider an accountant interpreting a notice, a recruiter summarizing a CV, a support operator drafting a response from a customer ticket, or a technical team pasting application logs into an AI assistant to find a bug.

An organization may also be building a RAG pipeline over thousands of internal documents.

The principle is the same.

The AI may need the information contained in a document without needing to know the identity of the people mentioned in it.

Does an LLM really need to know that Mario Rossi is Mario Rossi?

Suppose we want a model to summarize this text:

Mr. Mario Rossi, tax code RSSMRA80A01H501U, resident at 24 Via Roma in Milan, informs the company that...

To understand the meaning, the model could receive this instead:

Mr. [PERSON_1], tax code [FISCAL_CODE_1], resident at [ADDRESS_1], informs the company that...

The semantic structure remains.

The subject still exists.

The tax code is still recognizable as a concept.

The address still has a role in the document.

But the model does not necessarily need the real values.

This is a simple but important distinction:

protecting data does not necessarily mean removing meaning from the document.

Does “we do not use data for training” solve the problem?

Partly.

But not completely.

The business offerings of major providers now have much stronger controls than they did during the first months of the generative AI boom.

For example, OpenAI currently states that, by default, inputs and outputs from ChatGPT Business, Enterprise, Edu and the API platform are not used to train or improve models.

That is an important protection.

It is also important not to spread the opposite misconception:

“Anything you write in ChatGPT will end up in training.”

That is not necessarily true.

But training is only one part of the problem.

When using an AI service, we still need to consider:

• which data we are sending;
• where it is processed;
• how long it is retained;
• which intermediate systems receive it;
• what is written to logs;
• which subprocessors are involved;
• which permissions users have;
• what happens if an application has a bug;
• what happens if the data is later inserted into a vector database or knowledge base.

The question should not only be:

“Will the provider use this data to train the model?”

There is a question that comes first:

“Does the provider really need to receive this data?”

The real problem is where we put the control

One response is to ban AI.

That is understandable. It is also what several large companies did during the first phase of generative chatbot adoption.

But banning a technology that can save people hours of work is difficult to sustain over time.

People will still want to:

• summarize documents;
• fix code;
• analyze text;
• generate replies;
• query knowledge bases;
• classify information;
• automate repetitive work.

A second response is training:

Do not enter confidential information into AI systems.

Training is necessary, but it has a limit.

It requires every person to recognize every piece of information that should not be transferred, every time.

In a twenty-page document, it only takes one forgotten name, IBAN, tax identifier, email address or internal ID.

A third option is to put the control directly in the data flow.

Before the content reaches the AI.

The pattern can be very simple

Instead of:

Document → LLM

we can build:

Document → sensitive-data detection → policy → pseudonymization → LLM

And in a RAG system:

Documents → PII detection → pseudonymization → chunking → embeddings → vector database → LLM

The architectural difference is important.

In the first case, we must protect the original data throughout the entire chain.

In the second, we can reduce the amount of sensitive information before it passes through most of the infrastructure.

This does not make a system automatically secure. It does not remove the need for access control, encryption, audit, retention, classification, policies and careful provider selection.

But it applies one of the oldest principles in information security:

reduce what needs to be protected.

From “do not paste sensitive data” to automatic control

The Samsung case has another lesson.

Policies depend on people.

Automatic controls depend on the system.

A policy can say:

Do not send sensitive data to external AI tools.

A technical control can inspect the content before sending it and say:

This text contains a tax identifier, two email addresses, a phone number and an IBAN.

The organization can then decide what to do:

Block the operation.

Show a warning.

Redact the values.

Pseudonymize them.

Apply different policies by department.

Allow some data and prohibit other data.

Record the event without retaining the original content.

The difference is that protection no longer depends exclusively on the user's memory.

This is where Pseudora comes in

Pseudora is built around this idea.

Not to prevent companies from using ChatGPT, Claude, Gemini or other AI systems, and not to claim that cloud services are inherently wrong.

The goal is more pragmatic:

reduce sensitive data before it enters AI workflows.

Pseudora can act as an intermediate layer that detects and pseudonymizes information before it reaches:

• AI chatbots;
• LLM APIs;
• RAG pipelines;
• vector databases;
• document systems;
• automated workflows;
• internal AI tools.

The model still receives the context it needs.

The real identity can remain separate.

The question to ask before the next copy-paste

The Samsung case became famous because it involved one of the world's largest technology companies.

But its most significant aspect may be how ordinary the behavior was.

An employee had a problem.

They had an effective tool available.

They used it.

That is exactly what we want people to do with technologies that improve productivity.

The answer therefore cannot simply be:

“Do not use AI.”

We need systems that make AI useful without turning every prompt into a security decision left to an individual user.

Before sending the next contract, ticket, CV, log or document to an AI model, it may be worth asking one simple question:

What information does the AI actually need to do this work?

Everything else may have no reason to reach it.

---

Sources

• Bloomberg, Samsung Bans Staff's AI Use After Spotting ChatGPT Data Leak, 2 May 2023.
• Cybersecurity Dive, Samsung employees leaked corporate data in ChatGPT: report, 10 April 2023.
• TechCrunch, Samsung bans use of generative AI tools like ChatGPT after April internal data leak, 2 May 2023.
• OpenAI, Business data privacy, security, and compliance, accessed in 2026.