Samsung, ChatGPT e i segreti aziendali: il data leak che non sembrava un data leak

Come un normale copia-incolla dentro un chatbot ha mostrato uno dei problemi più sottovalutati dell'AI in azienda.

Nel 2023 alcuni dipendenti Samsung fecero qualcosa che oggi milioni di persone fanno ogni giorno.

Presero del materiale su cui stavano lavorando.

Lo copiarono.

Lo incollarono in ChatGPT.

E chiesero all'AI di aiutarli.

Non stavano tentando di sottrarre informazioni all'azienda.

Non avevano cliccato su un link di phishing.

Non avevano installato malware.

Non avevano perso una password.

Stavano semplicemente cercando di lavorare più velocemente.

Ed è proprio questo che rende il caso interessante.

Secondo le ricostruzioni pubblicate all'epoca, in tre episodi distinti dipendenti della divisione semiconduttori di Samsung inserirono in ChatGPT informazioni aziendali sensibili. Un dipendente caricò codice sorgente relativo a un programma interno per chiedere aiuto nella risoluzione di un errore. Un altro utilizzò codice relativo all'identificazione di apparecchiature difettose per chiederne l'ottimizzazione. Un terzo trasformò la registrazione di una riunione aziendale in testo e la inviò al chatbot per generarne il verbale.

Poche settimane dopo Samsung intervenne.

Nel maggio 2023 l'azienda limitò temporaneamente sui dispositivi aziendali l'utilizzo di strumenti di AI generativa come ChatGPT, Google Bard e Bing. La motivazione riportata internamente era il rischio che informazioni inviate a servizi esterni fossero difficili da recuperare o eliminare una volta trasferite fuori dall'infrastruttura aziendale.

Ma il punto più interessante della storia non è che Samsung abbia vietato ChatGPT.

È capire come quei dati siano usciti dall'azienda.

Il data leak più semplice non sembra un data leak

Quando pensiamo a una fuga di informazioni immaginiamo normalmente un attacco.

Un database lasciato aperto.

Una vulnerabilità.

Un ransomware.

Un dipendente malintenzionato.

Con l'intelligenza artificiale generativa esiste però un'altra possibilità.

Il dato può lasciare il perimetro aziendale attraverso un'azione perfettamente normale:

copia → incolla → invia

Per la persona che sta lavorando, il gesto è quasi invisibile.

Ha davanti un pezzo di codice che non funziona.

Lo incolla nell'AI.

Riceve una spiegazione.

Problema risolto.

Dal punto di vista della produttività è fantastico.

Dal punto di vista della governance del dato, però, è successo qualcosa di molto più importante:

un'informazione aziendale è stata trasferita a un altro sistema.

E questa distinzione è fondamentale.

L'interfaccia conversazionale ci fa percepire un chatbot come se fosse un collega a cui chiedere aiuto.

Tecnicamente, però, stiamo inviando informazioni a un servizio software.

Il problema non riguarda soltanto il codice sorgente

Nel caso Samsung le informazioni documentate erano soprattutto dati aziendali riservati, come codice sorgente e contenuti interni.

Non è quindi corretto trasformare artificialmente il caso in una storia esclusivamente sulla protezione dei dati personali.

Ma basta cambiare settore per vedere immediatamente lo stesso problema applicato alla PII.

Immaginiamo un avvocato.

Deve capire rapidamente una clausola contrattuale.

Copia il contratto dentro un LLM e chiede:

Riassumi le obbligazioni principali delle parti e indicami eventuali clausole problematiche.

Quel documento potrebbe contenere:

• nome e cognome;
• indirizzo;
• codice fiscale;
• email;
• numeri di telefono;
• dati bancari;
• informazioni economiche;
• informazioni relative a un contenzioso.

Oppure prendiamo un commercialista che vuole interpretare una comunicazione.

Un recruiter che vuole sintetizzare un CV.

Un operatore del customer support che vuole far generare una risposta a partire dal ticket di un cliente.

Un team tecnico che inserisce log applicativi in un assistente AI per trovare un bug.

Un'azienda che costruisce una pipeline RAG su migliaia di documenti interni.

Il principio rimane lo stesso.

L'AI può aver bisogno dell'informazione contenuta nel documento senza avere necessariamente bisogno dell'identità delle persone presenti nel documento.

Un LLM deve davvero sapere che Mario Rossi è Mario Rossi?

Supponiamo di voler chiedere a un modello di riassumere questo testo:

Il sig. Mario Rossi, codice fiscale RSSMRA80A01H501U, residente in Via Roma 24 a Milano, comunica alla società che...

Per comprendere il significato della frase, il modello potrebbe ricevere invece:

Il sig. [PERSON_1], codice fiscale [FISCAL_CODE_1], residente in [ADDRESS_1], comunica alla società che...

La struttura semantica rimane.

Il soggetto continua a esistere.

Il codice fiscale continua a essere riconoscibile come concetto.

L'indirizzo continua ad avere un ruolo nel documento.

Ma il modello non deve necessariamente conoscere i valori reali.

Questa è una distinzione semplice ma importante:

proteggere il dato non significa necessariamente togliere significato al documento.

"Non usiamo i dati per il training" risolve il problema?

In parte.

Ma non completamente.

Oggi le offerte aziendali dei principali provider dispongono di controlli molto migliori rispetto ai primi mesi dell'esplosione dell'AI generativa.

Per esempio, OpenAI dichiara attualmente che, per impostazione predefinita, input e output di ChatGPT Business, Enterprise, Edu e della piattaforma API non vengono utilizzati per addestrare o migliorare i modelli.

È una protezione importante.

Ed è importante dirlo perché il messaggio corretto non è:

"qualsiasi cosa scriviate in ChatGPT finirà nel training."

Non sarebbe vero.

Ma il training è soltanto una parte del problema.

Quando utilizziamo un servizio AI dobbiamo comunque valutare:

• quali dati gli stiamo inviando;
• dove vengono elaborati;
• per quanto tempo vengono conservati;
• quali sistemi intermedi li ricevono;
• cosa viene registrato nei log;
• quali subprocessor sono coinvolti;
• quali permessi hanno gli utenti;
• cosa succede se un'applicazione ha un bug;
• cosa succede se il dato viene successivamente inserito in un database vettoriale o in una knowledge base.

La domanda quindi non dovrebbe essere soltanto:

"Il provider userà questo dato per addestrare il modello?"

Dovrebbe esserci una domanda precedente:

"Il provider ha davvero bisogno di ricevere questo dato?"

Il vero problema è il punto in cui mettiamo il controllo

Una prima soluzione è vietare l'AI.

È una reazione comprensibile.

Ed è sostanzialmente ciò che fecero diverse grandi aziende nelle prime fasi dell'adozione dei chatbot generativi.

Ma vietare una tecnologia che permette alle persone di risparmiare ore di lavoro è difficile da sostenere nel lungo periodo.

Le persone continueranno a voler:

• riassumere documenti;
• correggere codice;
• analizzare testi;
• generare risposte;
• interrogare knowledge base;
• classificare informazioni;
• automatizzare attività ripetitive.

Una seconda soluzione consiste nella formazione:

Non inserite informazioni riservate nei sistemi AI.

È necessaria.

Ma anche questa strategia ha un limite.

Richiede che ogni persona, ogni volta, riconosca correttamente tutte le informazioni che non dovrebbero essere trasferite.

In un documento di venti pagine basta dimenticare un nome.

Un IBAN.

Un codice fiscale.

Un indirizzo email.

Un identificativo interno.

Una terza possibilità è mettere il controllo direttamente nel flusso del dato.

Prima che il contenuto raggiunga l'AI.

Il pattern può essere molto semplice

Invece di:

Documento → LLM

possiamo costruire:

Documento → rilevazione dati sensibili → policy → pseudonimizzazione → LLM

E in un sistema RAG:

Documenti → rilevazione PII → pseudonimizzazione → chunking → embedding → vector database → LLM

La differenza architetturale è importante.

Nel primo caso dobbiamo proteggere il dato originale lungo tutta la catena.

Nel secondo possiamo ridurre la quantità di informazione identificativa prima che attraversi gran parte dell'infrastruttura.

Questo non rende il sistema automaticamente sicuro.

Non elimina la necessità di:

• access control;
• cifratura;
• audit;
• retention;
• classificazione;
• policy;
• scelta di provider adeguati.

Ma applica uno dei principi più antichi della sicurezza informatica:

ridurre ciò che deve essere protetto.

Dal "non incollare dati sensibili" al controllo automatico

Il caso Samsung ha anche un'altra lezione.

Le policy dipendono dalle persone.

I controlli automatici dipendono dal sistema.

Una policy può dire:

Non inviare dati sensibili a strumenti AI esterni.

Un controllo tecnico può invece verificare il contenuto prima dell'invio e dire:

Questo testo contiene un codice fiscale, due indirizzi email, un numero di telefono e un IBAN.

A quel punto l'organizzazione può decidere cosa fare.

Bloccare l'operazione.

Mostrare un avviso.

Redigere i valori.

Pseudonimizzarli.

Applicare policy diverse in base al reparto.

Permettere alcuni dati e vietarne altri.

Registrare l'evento senza conservare il contenuto originale.

La differenza è che la protezione non dipende più esclusivamente dalla memoria dell'utente.

È qui che nasce Pseudora

Pseudora nasce esattamente da questa idea.

Non per impedire alle aziende di utilizzare ChatGPT, Claude, Gemini o altri sistemi AI.

E nemmeno per sostenere che utilizzare servizi cloud sia necessariamente sbagliato.

L'obiettivo è molto più pragmatico:

ridurre i dati sensibili prima che entrino nei workflow AI.

Pseudora può essere utilizzato come livello intermedio per rilevare e pseudonimizzare informazioni prima che raggiungano:

• chatbot AI;
• API LLM;
• pipeline RAG;
• database vettoriali;
• sistemi documentali;
• workflow automatici;
• strumenti interni basati su AI.

Il modello continua a ricevere il contesto necessario.

L'identità reale può rimanere separata.

La domanda da fare prima del prossimo copia-incolla

Il caso Samsung è diventato famoso perché coinvolgeva una delle più grandi aziende tecnologiche del mondo.

Ma probabilmente la parte più significativa è proprio quanto fosse ordinario il comportamento che lo causò.

Un dipendente aveva un problema.

Aveva a disposizione uno strumento molto efficace.

Lo ha utilizzato.

È esattamente ciò che vogliamo che le persone facciano con le tecnologie che migliorano la produttività.

Per questo la risposta non può essere soltanto:

"Non usate l'AI."

Dobbiamo costruire sistemi nei quali utilizzarla sia possibile senza trasformare ogni prompt in una decisione di sicurezza affidata al singolo utente.

Prima di inviare il prossimo contratto, ticket, CV, log o documento a un modello AI, quindi, potrebbe valere la pena fare una domanda molto semplice:

Quali informazioni servono realmente all'AI per fare questo lavoro?

Tutto il resto potrebbe non avere alcun motivo di arrivarci.

---

Fonti

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