Quasi 24 ore di problemi su Microsoft 365 bastano a trasformare una dipendenza invisibile in un blocco operativo: email irraggiungibile, calendari in errore e funzioni di Teams e Copilot degradate. Nelle stesse ore, una nuova vulnerabilità Windows ha mostrato come un controllo di sicurezza possa diventare parte della catena d’attacco, mentre LangChain ha raccolto 300 milioni di dollari puntando sulla governance degli agenti AI. Tre notizie diverse, una sola conseguenza per le PMI: l’affidabilità non coincide con il nome del fornitore.
Microsoft 365: il cloud non elimina il fermo
Il disservizio Microsoft 365 iniziato il 12 novembre ha interessato Outlook e alcune funzioni di Teams, Copilot e calendario. Microsoft ha attribuito l’incidente a un problema introdotto durante un precedente aggiornamento della capacità di rete, emerso dopo una modifica successiva. Non era un attacco informatico né un problema causato da agenti AI. Il ripristino è stato graduale per verificare la stabilità a ogni fase, secondo l’aggiornamento riportato da MacRumors; la pagina ufficiale di stato Microsoft resta il riferimento per l’operatività corrente.
La lezione non è “abbandonare Microsoft 365”. È preparare un percorso minimo quando il tenant non risponde: elenco contatti esportato, canale alternativo già autorizzato, copie locali dei documenti critici e una procedura che dica chi decide il passaggio al fallback. Un piano mai provato è soltanto un file in più. Per email e collaborazione vale lo stesso criterio discusso nel confronto tra server interno e Microsoft 365: prima si definiscono dipendenze e tempo massimo tollerabile, poi si sceglie lo stack.
SignDrop: il privilegio locale resta decisivo
Il 13 novembre Ars Technica ha documentato SignDrop, una vulnerabilità nel Common Log File System di Windows. Un utente locale con privilegi ordinari può indurre un processo privilegiato, come Windows Defender, ad aprire un contenitore CLFS costruito ad arte e arrivare all’elevazione a SYSTEM. Il ricercatore Will Dormann ha riprodotto l’exploit, ma ha precisato che le condizioni non risultano presenti su tutte le installazioni di Windows 11.
Microsoft ha dichiarato di essere al lavoro sull’analisi, di non avere evidenze di sfruttamento attivo e che Defender blocca i tentativi potenziali. Questo riduce l’urgenza, non sostituisce il controllo. Per un responsabile IT significa verificare versione e configurazione, limitare gli account amministrativi, raccogliere i log degli endpoint e preparare la distribuzione della correzione. La vulnerabilità richiede accesso locale: segmentazione e privilegi minimi restano barriere concrete, non formule da policy.
LangChain finanzia il livello di controllo
LangChain ha annunciato il 13 novembre un round Series C da 300 milioni di dollari con valutazione di 3 miliardi. Il dato interessante non è soltanto finanziario. L’azienda presenta LangSmith come livello indipendente da framework e modello per runtime, valutazione, osservabilità e governance degli agenti. Dichiara oltre 7.000 organizzazioni utilizzatrici e concentra il messaggio su controllo di strumenti, dati, autenticazione, budget e fallback.
Il mercato sta quindi assegnando valore alla parte meno spettacolare dell’AI: sapere che cosa ha fatto un agente, con quali permessi, quanto è costato e come fermarlo. La scelta non è automaticamente “comprare LangSmith”. Anche uno stack più piccolo deve conservare trace, test di regressione, limiti di spesa e una modalità manuale. Prima di concedere accessi estesi, conviene applicare la stessa domanda posta per sandbox e accesso totale degli agenti AI: qual è il danno massimo se il workflow sbaglia?
La take operativa: progettare il degrado
Cloud, endpoint e agenti AI condividono lo stesso errore progettuale: considerarli affidabili finché non si fermano. Per una PMI imposterei tre gate questa settimana: un test di indisponibilità di Microsoft 365, una verifica degli account locali e amministrativi Windows, e un log completo di almeno un workflow AI in produzione. Ogni gate deve produrre un responsabile, una soglia di stop e un fallback verificabile.
La continuità non richiede duplicare tutto. Richiede distinguere ciò che può attendere da ciò che blocca vendite, assistenza o consegne. Se il processo critico non può proseguire senza un singolo cloud, un singolo account privilegiato o un agente non osservabile, il problema non è la probabilità dell’incidente: è che il costo è già stato accettato senza misurarlo.