Un’organizzazione può trattare un dato che non ha mai raccolto?
La domanda potrebbe apparire contraddittoria.
Un’informazione non viene richiesta all’interessato, non compare come tale in un database e non viene acquisita da una fonte esterna.
Eppure un sistema di intelligenza artificiale, analizzando altri dati, può arrivare a dedurla.
È ciò che accade quando dall’elaborazione dei dati si passa alla generazione di inferenze.
Se un sistema può ricavare informazioni ulteriori rispetto a quelle esplicitamente disponibili, cambia anche il perimetro di ciò che un’organizzazione deve conoscere, governare e proteggere.
La superficie informativa può diventare più ampia del dato materialmente raccolto.
Quando il dato nasce dall’inferenza
Un sistema di machine learning può individuare correlazioni, classificare comportamenti, riconoscere pattern e ricavare nuove informazioni.
Il dato di partenza e quello di arrivo possono quindi essere profondamente diversi.
Una sequenza di acquisti può contribuire a inferire una condizione personale. Determinate abitudini possono concorrere a costruire un profilo.
Il linguaggio utilizzato in una conversazione può essere analizzato per ricavare informazioni ulteriori sulla persona.
Il titolare potrebbe così trovarsi a disporre di una conoscenza che non era esplicitamente contenuta nei dati originari.
Il caso Myndoor: dal testo allo stress
Un esempio significativo emerge dal provvedimento del Garante per la protezione dei dati personali del 14 maggio 2026 relativo a Myndoor.
L’Autorità ha esaminato un plug-in utilizzabile nell’ambiente lavorativo che analizzava semanticamente messaggi scambiati attraverso Slack e Teams per ricavare parametri relativi allo stress degli utenti.
L’architettura descritta al Garante prevedeva che il datore di lavoro non accedesse ai contenuti delle conversazioni e agli output individuali.
Il passaggio è interessante: il dato di partenza è il testo; l’informazione ottenuta riguarda la sfera emotiva della persona.
Il Garante richiama, più in generale, la capacità dei sistemi di intelligenza artificiale di generare inferenze ulteriori rispetto ai dati originariamente trattati, talvolta non immediatamente prevedibili o controllabili.
Quando i risultati derivano da correlazioni e classificazioni difficilmente interpretabili, diventano centrali affidabilità del modello, qualità dei dati, trasparenza, explainability, verificabilità degli output e controllo umano effettivo.
Il problema, quindi, non è più soltanto che cosa entra nel sistema. Diventa anche che cosa il sistema è capace di ricavarne.
Dal dato raccolto al dato ricostruito
Le Guidelines 02/2026 on Anonymisation dell’European Data Protection Board, adottate l’8 luglio 2026 e poste in consultazione pubblica, mostrano bene perché non sia sufficiente osservare ciò che rimane visibile in un dataset.
La rimozione degli identificativi diretti non esaurisce il rischio.
Informazioni apparentemente non identificative possono consentire di isolare un soggetto, essere collegate ad altri dati oppure permettere di inferire caratteristiche ulteriori.
Anche la Corte di giustizia, nella sentenza EDPS v SRB (C-413/23 P) del 4 settembre 2025, ha evidenziato l’importanza del contesto nella valutazione dell’identificabilità dei dati pseudonimizzati e dei mezzi ragionevolmente utilizzabili per ricondurli a una persona.
La domanda, quindi, non è soltanto: abbiamo tolto il nome?
Occorre chiedersi chi dispone dell’informazione, quali altre informazioni possiede e che cosa può ragionevolmente ricavarne.
Dalla superficie di attacco alla superficie inferenziale
Nella cybersecurity siamo abituati a ragionare in termini di attack surface: endpoint, identità, servizi, applicazioni, API e infrastrutture rappresentano possibili punti attraverso i quali un sistema può essere compromesso.
L’intelligenza artificiale suggerisce di affiancare a questa prospettiva un’altra dimensione: una superficie inferenziale.
Non si tratta di una categoria normativa, ma di una lente utile per l’analisi del rischio.
Possiamo descriverla come l’insieme delle informazioni che un sistema è in grado di ricavare attraverso correlazioni, classificazioni e inferenze, anche quando tali informazioni non sono memorizzate esplicitamente come attributi dell’interessato.
Un’organizzazione potrebbe proteggere correttamente i dati grezzi e sottovalutare la sensibilità degli output prodotti dal modello.
Oppure limitare l’accesso a determinate informazioni lasciando disponibile una funzione capace di ricostruirle indirettamente.
Anche l’output diventa quindi parte del patrimonio informativo da proteggere.
Quando la funzione stessa diventa il rischio
Il provvedimento Myndoor offre un’indicazione operativa particolarmente concreta.
Il Garante richiama anche il quadro dell’AI Act relativo all’inferenza delle emozioni nel contesto lavorativo e collega il tema ai principi di protezione dei dati fin dalla progettazione e per impostazione predefinita.
Nella progettazione occorre quindi valutare anche la disattivazione di funzionalità prive di base giuridica, incompatibili con le finalità del trattamento o potenzialmente in contrasto con specifiche disposizioni.
Privacy by design può significare qualcosa di molto semplice: questa informazione il sistema non deve renderla disponibile.
O, ancora prima, questa inferenza non deve essere prodotta per quella finalità.
Dal principio al protocollo operativo
Se accettiamo l’idea di una superficie inferenziale, la governance di un sistema AI dovrebbe mappare non soltanto i dati in ingresso, ma l’intera catena attraverso la quale il dato viene trasformato in conoscenza.
Collect -> Correlate -> Infer -> Validate -> Use -> Monitor.
Collect: quali dati vengono acquisiti e per quale finalità?
Correlate: quali informazioni vengono combinate e quali relazioni può individuare il sistema? Infer: quali nuove caratteristiche, probabilità, classificazioni o profili possono essere prodotti?
Validate: quanto sono affidabili quelle inferenze?
Quali bias, errori o falsi positivi possono contenere?
Use: chi può accedere all’output, per quale finalità e con quali conseguenze sull’interessato?
Monitor: capacità del modello, dati disponibili, utilizzi e contesto possono cambiare.
Anche la valutazione del rischio deve quindi essere aggiornata.
Una domanda dovrebbe attraversare tutte queste fasi: WHAT ELSE CAN THE SYSTEM KNOW?
Non soltanto cosa abbiamo deciso di fornire al modello, ma che cosa il modello può arrivare a sapere.
Governare le inferenze prima che diventino decisioni
Un’inferenza non verificata può trasformarsi in una decisione.
Un output probabilistico può essere interpretato come un fatto; una correlazione può essere scambiata per una relazione certa; un modello può amplificare bias presenti nei dati.
La governance dell’AI deve quindi interrogarsi non soltanto su ciò che un sistema è autorizzato a conoscere, ma anche su ciò che è autorizzato a dedurre, rendere disponibile e utilizzare.
È qui che privacy, cybersecurity e AI governance smettono di essere discipline parallele e diventano parti dello stesso problema.
Il dato invisibile
Per anni abbiamo costruito sistemi di protezione attorno a domande essenziali: quali dati raccogliamo?
Dove li conserviamo?
Chi può accedervi? Per quanto tempo?
Sono domande che rimangono fondamentali.
Ma l’intelligenza artificiale ne aggiunge un’altra: quali informazioni può dedurre il sistema da ciò che già possediamo?
La risposta può modificare il risk assessment, la privacy by design, i controlli di accesso, il monitoraggio degli output e perfino la decisione di rendere disponibile una determinata funzionalità.
Proteggere il dato non significa più soltanto proteggere ciò che abbiamo raccolto.
Significa comprendere e governare ciò che da quel dato può essere ricavato.
Perché nell’era dell’intelligenza artificiale, il prossimo dato personale da proteggere potrebbe essere proprio quello che non abbiamo mai raccolto.
