By · Last updated 2026-03-13

Torna al BlogSicurezza IA

Samsung ha perso codice sorgente su ChatGPT tre volte

Nell'aprile 2023, tre diversi team di ingegneria Samsung hanno incollato codice proprietario e dati riservati in ChatGPT. Ogni incidente ha messo in luce una vulnerabilità diversa.

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

Aggiornato per il 2026

Tre team, tre fughe, un mese

Nell'aprile 2023, Samsung Semiconductor ha reso noti tre incidenti distinti. Nell'arco di un mese, tre team diversi avevano trasmesso dati proprietari a un chatbot IA. Gli episodi non erano correlati: persone diverse, ruoli diversi, giorni diversi.

Avevano solo due tratti in comune: ciascuno stava usando lo strumento per un lavoro reale, e ciascuno aveva involontariamente inviato dati che Samsung non intendeva condividere fuori dall'azienda.

Incidente 1 — Codice sorgente. Un ingegnere software stava eseguendo il debug del codice di un impianto. Ha incollato nel chatbot codice sorgente proprietario di semiconduttori contenente proprietà intellettuale legata alla produzione.

Incidente 2 — Verbale di riunione. Un dipendente stava preparando il riassunto di una riunione e ha inviato i propri appunti per una sintesi automatica. Quegli appunti contenevano dettagli riservati su strategie e roadmap aziendali.

Incidente 3 — Query del database. Un terzo dipendente cercava aiuto con una query lenta e ha condiviso la struttura del database e la logica della query, che faceva riferimento a schemi proprietari e regole di business.

Tre incidenti. Tre divulgazioni. Un mese.

Perché i dipendenti l'hanno fatto

Nessuno dei tre stava agendo con superficialità. Usavano uno strumento IA per attività per cui è progettato: revisione del codice, sintesi di testi, ottimizzazione delle query. Ciascun compito era legittimo.

Mancava un blocco tecnico. Nessun sistema ha impedito l'invio prima che raggiungesse un server esterno. Nessun filtro ha intercettato gli identificatori proprietari prima che uscissero dalla rete. Nulla si frapponeva tra il bisogno reale del dipendente e il servizio esterno.

Esisteva un avviso di policy — ma un avviso non è una barriera. Il rischio di un errore accidentale era astratto e remoto; il beneficio in produttività era concreto e immediato. I lavoratori, razionalmente, hanno scelto la produttività.

Il risultato era prevedibile: tre incidenti in trenta giorni, tre divulgazioni di proprietà intellettuale, una crisi aziendale che ha innescato blocchi in tutto il settore.

La reazione del settore

Samsung ha reagito rapidamente, bloccando l'accesso agli strumenti IA sui dispositivi aziendali.

Altre organizzazioni hanno seguito l'esempio. Tra quelle che hanno annunciato restrizioni: Bank of America, Citigroup, Goldman Sachs, JPMorgan Chase, Apple e Verizon. Il settore finanziario è stato il più rapido. Grandi banche e aziende tecnologiche sono giunte alla stessa conclusione: gli strumenti IA senza controlli tecnici rappresentano un rischio di conformità inaccettabile.

Tutte sono arrivate allo stesso verdetto: i dipendenti non sono il problema, e gli avvisi di policy non bastano. I dati hanno lasciato le reti aziendali perché nulla li ha fermati — la policy da sola non può creare un blocco tecnico.

Il tasso di elusione del 71,6%

L'approccio del divieto ha un tasso di fallimento misurabile. Una ricerca LayerX del 2025 ha rilevato che il 71,6% dei dipendenti soggetti a divieti aziendali di IA ha continuato a usare strumenti IA, attraverso account personali o dispositivi personali.

Il motivo è semplice: uno strumento che offre un valore reale viene usato comunque. Le persone trovano alternative piuttosto che rinunciarvi. L'IA può dimezzare i tempi di lavoro — un avviso di policy non cambia questo calcolo. I lavoratori accedono da telefono o laptop personale, e i team di sicurezza non vedono quel traffico.

Il risultato pratico è il peggiore scenario possibile. I dati aziendali raggiungono comunque i fornitori IA, ma ora transitano su canali senza alcuna supervisione. Il traffico sui dispositivi aziendali poteva almeno essere registrato; l'uso da account personali è invisibile.

I tre incidenti di Samsung sono avvenuti su dispositivi aziendali. I dipendenti che aggirano il divieto fanno la stessa cosa — inviano dati di lavoro ai modelli IA — ma ora attraverso canali senza visibilità aziendale.

La soluzione tecnica che affronta la causa radice

Gli incidenti di Samsung non sono stati causati da persone incaute, ma da un'architettura priva di un livello di intercettazione. Non c'era nulla tra il prompt del dipendente e il server del fornitore.

L'architettura Model Context Protocol (MCP) colma questa lacuna, inserendo un proxy trasparente nel percorso dei dati. Gli sviluppatori che usano Claude Desktop o Cursor IDE sono il pubblico principale — e sono esattamente gli strumenti usati per il tipo di debug del codice alla base del primo incidente Samsung. Il Server MCP si inserisce nel percorso del protocollo per entrambi.

Prima che il testo raggiunga il modello IA, il Server MCP lo sottopone a un passaggio di anonimizzazione. Il codice sorgente viene scansionato alla ricerca di identificatori proprietari: nomi di funzioni, nomi di variabili e endpoint API vengono sostituiti con token strutturati. Anche i dettagli dello schema del database e i valori di configurazione vengono sostituiti — il tutto prima che il codice lasci la rete.

Uno sviluppatore che esegue il debug di codice proprietario invia il codice attraverso il client MCP con gli identificatori sensibili già tokenizzati. Il modello IA è comunque utile per il debug — ma i dettagli proprietari non raggiungono mai i server del fornitore.

L'incidente 1 diventa tecnicamente impossibile. Il codice sorgente esce dalla rete già anonimizzato; l'ingegnere ottiene l'aiuto di cui ha bisogno, mentre la proprietà intellettuale resta sotto il controllo aziendale.

La stessa logica vale per l'incidente 2: la sintesi degli appunti di riunione tramite strumenti basati su browser è gestita dall'estensione Chrome e dai suoi controlli aziendali. L'incidente 3 è coperto dall'anonimizzazione MCP in qualsiasi interfaccia IA per la programmazione.

Divieti vs. controlli tecnici

Vietare strumenti che il 71,6% dei dipendenti aggira già non riduce il rischio: lo sposta su canali invisibili.

Il confronto tra strumenti DLP per browser esamina le opzioni di intercettazione per l'uso di IA basato su browser. Per le organizzazioni che confrontano l'anonimizzazione con altri prodotti DLP, il confronto Nightfall vs. anonym.legal tratta direttamente il compromesso tra blocco e anonimizzazione.

Gli incidenti Samsung sono stati un segnale precoce. La causa radice era un'assenza: nessun livello di intercettazione, nessun controllo tecnico. Quella lacuna è oggi colmabile — la domanda è se le aziende implementeranno la soluzione o continueranno ad affidarsi a divieti che la maggioranza dei dipendenti aggira già.

Fonti

Pronto a proteggere i tuoi dati?

Inizia ad anonimizzare i PII con oltre 285 tipi di entità in 48 lingue.

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.