By · Last updated 2026-03-13

Voltar ao BlogSegurança de IA

Como a Samsung Perdeu Código Fonte Proprietário para...

Três equipes de engenharia da Samsung colaram código proprietário e dados confidenciais no ChatGPT em abril de 2023.

March 13, 20269 min de leitura
Samsung ChatGPT leaksource code protectionenterprise AI controlsinsider data leakageMCP Server anonymization

Atualizado para 2026

Três equipes, três vazamentos, um mês

Em abril de 2023, a Samsung Semiconductor divulgou três incidentes separados. Três equipes diferentes tinham enviado dados proprietários para um chatbot de IA em um único mês. Os incidentes não estavam relacionados. Pessoas diferentes, funções diferentes, dias diferentes.

Eles compartilhavam apenas duas características. Cada pessoa usou a ferramenta para trabalho real. Cada uma enviou acidentalmente dados que a Samsung não pretendia compartilhar fora da empresa.

Incidente 1 — Código-fonte. Um engenheiro de software estava depurando código de equipamentos. Ele colou código-fonte proprietário de semicondutores no chat. O código continha propriedade intelectual de fabricação.

Incidente 2 — Notas de reunião. Um funcionário estava preparando um resumo de reunião. Ela enviou suas anotações para que a IA as condensasse. Essas notas continham informações estratégicas confidenciais e detalhes de roteiro.

Incidente 3 — Consulta de banco de dados. Um terceiro funcionário queria ajuda com uma consulta lenta. Ele compartilhou a estrutura do banco de dados e a lógica da consulta. Essa lógica referenciava esquemas proprietários e regras de negócio.

Três incidentes. Três divulgações. Um mês.

Por que os funcionários fizeram isso

Nenhum dos três agiu de forma descuidada. Eles usaram uma ferramenta de IA para tarefas para as quais ferramentas de IA são criadas. Revisão de código. Síntese de texto. Otimização de consultas. Cada tarefa era legítima.

O elemento que faltava era uma barreira técnica. Nenhum sistema bloqueou o envio antes de chegar a um servidor externo. Nenhum filtro detectou os identificadores proprietários antes de saírem da rede. Nada estava entre a necessidade real do funcionário e o serviço externo.

Existia um aviso de política. Mas um aviso não é uma barreira. O risco de um erro acidental era abstrato e distante. O benefício de produtividade era real e imediato. Trabalhadores racionais escolheram produtividade.

O resultado era previsível. Três incidentes em trinta dias. Três divulgações de propriedade intelectual. Uma crise corporativa que desencadeou proibições em toda a indústria.

A reação da indústria

A Samsung agiu rapidamente. Restringiu o acesso a ferramentas de IA em dispositivos corporativos.

Outras organizações seguiram o exemplo. Entre as que anunciaram restrições estavam Bank of America, Citigroup, Goldman Sachs, JPMorgan Chase, Apple e Verizon. O setor financeiro reagiu mais rápido. Grandes bancos e empresas de tecnologia chegaram à mesma conclusão. Ferramentas de IA sem controles técnicos representavam risco de conformidade inaceitável.

Todas chegaram ao mesmo resultado. Os funcionários não são o problema. Avisos de política não são suficientes. Os dados saíam das redes corporativas porque nada os impedia. A política sozinha não pode criar uma barreira técnica.

A taxa de evasão de 71,6%

A abordagem de proibição tem uma taxa de falha medida. Uma pesquisa da LayerX de 2025 descobriu que 71,6% dos funcionários sujeitos a proibições de IA empresarial continuaram usando ferramentas de IA. Eles usaram contas pessoais ou dispositivos pessoais.

A razão é simples. Uma ferramenta que entrega valor real é usada. As pessoas encontram soluções alternativas em vez de desistir dela. A IA pode reduzir o tempo das tarefas pela metade. Um aviso de política não vai mudar esse cálculo. Os trabalhadores entram pelo celular ou notebook pessoal. As equipes de segurança não conseguem ver esse tráfego.

O resultado prático é o pior caso. Os dados corporativos ainda chegam aos provedores de IA. Mas agora fluem por canais sem nenhuma supervisão. O tráfego de dispositivos corporativos poderia pelo menos ser registrado. O uso de contas pessoais é invisível.

Os três incidentes da Samsung aconteceram em dispositivos corporativos. Os funcionários que contornam a proibição fazem a mesma coisa. Eles enviam dados de trabalho para modelos de IA. Mas agora passa por canais sem visibilidade empresarial.

A solução técnica para a causa raiz

Os incidentes da Samsung não foram causados por pessoas descuidadas. Foram causados por uma arquitetura sem camada de interceptação. Não havia nada entre o prompt do funcionário e o servidor do fornecedor.

A arquitetura Model Context Protocol (MCP) preenche essa lacuna. Ela coloca um proxy transparente no caminho dos dados. Desenvolvedores usando Claude Desktop ou Cursor IDE são o público principal. Essas são exatamente as ferramentas usadas para o tipo de depuração de código por trás do primeiro incidente da Samsung. O servidor MCP fica dentro do caminho do protocolo para ambos.

Antes de qualquer texto chegar ao modelo de IA, o servidor MCP o processa em uma etapa de anonimização. O código-fonte é verificado em busca de identificadores proprietários. Nomes de funções, nomes de variáveis e endpoints de API são substituídos por tokens estruturados. Detalhes de esquema de banco de dados e valores de configuração também são substituídos. A troca acontece antes de o código sair da sua rede.

Um desenvolvedor depurando código proprietário envia o código pelo cliente MCP. Os identificadores sensíveis já são tokens nesse momento. O modelo de IA ainda ajuda com a tarefa de depuração. Os detalhes proprietários reais nunca chegam aos servidores do fornecedor.

O incidente 1 se torna tecnicamente impossível. O código-fonte sai da rede já anonimizado. O engenheiro recebe a ajuda que precisava. A propriedade intelectual permanece sob controle da empresa.

A mesma lógica se aplica ao incidente 2. A síntese de notas de reunião via ferramentas baseadas em navegador é coberta pela extensão Chrome e seus controles empresariais. O incidente 3 é coberto pela anonimização MCP em qualquer interface de codificação de IA.

Proibições vs. controles técnicos

Proibir ferramentas que 71,6% dos funcionários já contornam não reduz o risco. Move o risco para canais invisíveis.

A comparação de ferramentas DLP de navegador cobre as opções de interceptação para uso de IA baseado em navegador. Para organizações comparando anonimização com outros produtos DLP, a comparação Nightfall vs. anonym.legal aborda diretamente o compromisso bloqueio-versus-anonimização.

Os incidentes da Samsung foram um sinal antecipado. A causa raiz era uma ausência. Sem camada de interceptação. Sem controle técnico. Essa lacuna é corrigível agora. A questão é se as empresas implantam a solução, ou continuam dependendo de proibições que a maioria dos funcionários já contorna.

Fontes

Pronto para proteger seus dados?

Comece a anonimizar PII com mais de 285 tipos de entidades em 48 idiomas.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.