Quando un assistente AI entra nel cuore della produttività aziendale, ogni difetto logico diventa un rischio reale. Negli ultimi giorni Microsoft ha confermato un problema in Microsoft 365 Copilot che ha permesso al sistema di accedere e riassumere email etichettate come confidenziali e teoricamente protette da DLP e sensitivity labels. L’evento è tracciato con il codice interno CW1226324 e non è un dettaglio da forum, è un caso scuola su come i modelli linguistici si intrecciano con i controlli di sicurezza enterprise.
Che cosa è successo davvero
Copilot Chat, nello specifico la vista Work tab, indicizza e interroga contenuti aziendali per costruire risposte contestuali. In condizioni normali, l’indicizzazione dovrebbe rispettare le etichette di Microsoft Purview e le policy di Data Loss Prevention. In questo incidente, invece, alcune email etichettate come Confidential presenti in Sent Items e Drafts sono finite comunque nella pipeline, sono state processate dal motore di recupero e sintetizzate dall’LLM. Il tutto senza che i filtri di esclusione facessero il loro mestiere.
Non parliamo di un attacco esterno o di una fuga di dati in stile esfiltrazione. È un difetto di logica server side: i controlli che avrebbero dovuto fermare i contenuti sensibili prima della fase di inferenza non hanno applicato correttamente le regole. Risultato pratico: utenti legittimati hanno ottenuto sintesi che non avrebbero dovuto esistere, e i team sicurezza non hanno ricevuto un preavviso automatico.
Perché è importante
Questo incidente mette a fuoco tre aspetti che ogni azienda dovrebbe avere già sul tavolo.
Enforcement delle policy dentro le pipeline AI
Le DLP tradizionali nascono per bloccare l’uscita dei dati o gli utilizzi non autorizzati. Qui il problema è interno al servizio, quindi invisibile agli strumenti che guardano la frontiera verso l’esterno. Se la policy non viene rispettata lungo la catena di indicizzazione, l’AI può produrre un output corretto dal punto di vista funzionale ma sbagliato dal punto di vista del rischio.
Confini di fiducia dei LLM
Un modello linguistico non è un processo isolato. Vive di retrieval, cache, orchestratori che passano dati avanti e indietro. Se un’anomalia di labeling o di filtro passa a monte, l’LLM farà il suo lavoro con i dati che riceve. La regola d’oro resta valida: i dati riservati non dovrebbero mai raggiungere la fase di inferenza, e i controlli che lo garantiscono devono essere espliciti, verificabili e indipendenti.
Compliance e accountability
Anche senza un’esportazione verso terzi, la generazione di sintesi da contenuti coperti da etichette di riservatezza può collidere con principi di privacy by design e con requisiti di controllo degli accessi previsti da GDPR o da regolazioni settoriali. Non è solo un tema tecnico, è un tema di governance.
La timeline in breve
Secondo quanto ricostruito pubblicamente, il comportamento anomalo inizia il 21 gennaio 2026 ed emerge tramite telemetria interna. Tra fine gennaio e inizio febbraio il problema si manifesta in più tenant, poi a febbraio parte una correzione server side, con comunicazioni mirate ai clienti per confermare la remediazione. Tempi e modalità contano perché ci dicono due cose: la rilevazione è avvenuta in casa e la fix non richiede interventi client, quindi il difetto era nella logica del servizio centrale.
Che cosa fare adesso, in concreto
Al netto della patch, questo è il momento di mettere alla prova il proprio disegno di sicurezza per l’AI. Alcune azioni pragmatiche aiutano a trasformare la lezione in controllo operativo.
- Test di policy pre LLM: verifica con dataset sintetici etichettati che contenuti riservati non vengano indicizzati né passino al layer di inferenza. Non basta controllare l’accesso al file, serve validare l’intera catena di retrieval.
- Audit e telemetria dedicati: traccia quando un assistente AI accede a classi di dati che dovrebbero essere escluse. Servono log specifici per le pipeline AI e alert su scope violation, non solo regole su SIEM e XDR generici.
- Trust boundaries espliciti: stabilisci punti di blocco verificabili prima della fase di prompt e completamento. Le decisioni di esclusione non devono vivere solo dentro l’indicizzatore, vanno duplicate e validate a monte.
- Risk ownership: tratta l’AI come un asset con un profilo di rischio autonomo. Aggiorna il registro rischi, definite controlli compensativi e un piano di test regressivi ogni volta che cambia la configurazione o il servizio cloud.
La sostanza
Questa non è la solita nota di rilascio con un bugfix. È un promemoria che l’AI nei workflow aziendali chiede un modello di sicurezza che conosca i comportamenti dei LLM e le loro dipendenze. I controlli classici restano fondamentali, ma non bastano se non vengono proiettati dentro le pipeline di retrieval e generazione. La chiamata all’azione è chiara: bisogna trattare i modelli linguistici come componenti di rischio a sé, con policy misurabili in ogni punto in cui toccano dati sensibili.
Analisi di Vasily Kononov – Threat Intelligence Lead, CYBEROO
