Riesci a indovinare cosa c’era nel prompt

Negli ultimi mesi, diversi studi hanno dimostrato che non serve molto per risalire al contenuto originale di un embedding. Uno degli articoli più citati è quello di IronCore Labs, che mostra come sia possibile ricostruire un prompt testuale a partire dai suoi embeddings utilizzando tecniche di inversione basate su modelli di linguaggio open source. In altre parole, se conservi i vettori generati da un LLM, potresti non aver davvero oscurato i dati sensibili. Potresti averli solo codificati in una forma apparentemente opaca, ma ancora leggibile. La notizia ha riaperto un dibattito cruciale per chi lavora con i dati aziendali. È davvero sicuro archiviare embeddings nei propri sistemi? Che tipo di rischio stiamo introducendo se questi vettori permettono di risalire a informazioni private, personali o sensibili?

Gli embeddings non sono una cassaforte

Un embedding è una rappresentazione vettoriale di un contenuto, costruita in modo che elementi simili siano vicini nello spazio. Funziona molto bene per fare clustering, ricerca semantica, classificazione. Ma non è una codifica irreversibile. Anzi, per come sono progettati i modelli che li generano, l’obiettivo è proprio mantenere una corrispondenza semantica densa tra il testo e il suo embedding. È questo che rende possibile l’inversione. Basta addestrare un modello a partire da un numero sufficiente di coppie embedding-testo per ottenere una rete neurale capace di risalire al contenuto originario con un buon grado di accuratezza. Il risultato non sarà perfetto, ma spesso è sorprendentemente vicino. In alcuni casi è sufficiente per identificare nomi, domande, intenti. E per molte applicazioni aziendali, è più che sufficiente per rappresentare un rischio concreto.

Dove rischia davvero un’azienda

Se usi embeddings per potenziare un motore di ricerca interno, abilitare una chat su documenti riservati o migliorare la navigazione in un sistema knowledge-based, è probabile che tu stia archiviando i vettori risultanti da contenuti sensibili. Molti li trattano come “dati trasformati”, e quindi non soggetti a protezione specifica. Ma se questi dati possono essere ricostruiti, allora non sono davvero anonimizzati. E il rischio di esposizione è tutt’altro che teorico.

Alcune domande da porsi:

• “Gli embeddings sono generati da un modello proprietario o da un provider esterno”

• “Vengono archiviati in chiaro, su storage permanente”

• “Sono associati a ID, metadati o timestamp che permettono di risalire all’origine”

• “Sono usati in ambienti dove utenti o modelli possono accedervi indirettamente”

Tutte queste condizioni aumentano il potenziale di leakage e rendono più difficile sostenere, in caso di audit o ispezione, che il trattamento sia sicuro o compliant.

Non è un problema solo tecnico

La soluzione non può essere semplicemente “hashiamo tutto”. Funziona con dati statici, come una password o un codice fiscale, che devono essere verificati ma non confrontati semanticamente. Ma un embedding serve proprio a questo, ovvero deve essere misurabile, confrontabile, indicizzabile. Se lo hashiamo, ne annulliamo la funzione. Servono invece policy chiare, modelli di retention coerenti, controlli sugli accessi e soprattutto consapevolezza nei team che li usano. Chi lavora con i dati ha il dovere di riconoscere che dato trasformato non significa dato protetto. E che il fatto di non vedere immediatamente un nome o un codice fiscale non equivale a dire che quel dato è al sicuro.

Conclusione

L’inversione degli embeddings non è un esperimento da laboratorio. È un rischio reale, già documentato, che merita attenzione. Perché ogni volta che automatizziamo l’accesso, la ricerca o la classificazione su contenuti aziendali sensibili, è facile dimenticare che dietro ogni vettore c’è una storia leggibile. E spesso, una persona reale.