I team di sicurezza non hanno un problema di detection. Hanno un problema di remediation e un problema di comunicazione, e sono questi i due punti in cui l'AI nella sicurezza ripaga davvero. Uno scanner moderno ti consegna volentieri 800 finding rispetto a un benchmark di conformità. I finding non sono la parte difficile. La parte difficile è che la maggior parte non viene mai corretta, e quelli che vengono corretti restano invisibili alle persone che approvano il budget. Questo post è un 101 sulle due funzionalità AI che secondo me affrontano il problema in modo diretto: remediation automatizzata con un gate di approvazione e reportistica generata dall'AI per lettori non tecnici. Userò Aether365, una piattaforma di sicurezza per Microsoft 365, come esempio ricorrente. Trasparenza totale fin da subito: Aether365 è un mio prodotto. Giudicate gli argomenti nel merito.

Un principio prima di iniziare: read-only è il default. Nulla ottiene accesso in scrittura al tuo tenant senza un consenso separato ed esplicito.

Le due lacune che ogni scanner di sicurezza lascia aperte

Esegui una scansione di postura su un tenant Microsoft 365 reale, benchmark CIS, EIDSCA, CISA ScuBA, e ottieni sempre la stessa forma di output: una lunga lista di controlli falliti con le rispettive severità. A quel punto succedono due cose prevedibili.

Primo, la coda dei finding sopravvive all'attenzione di chiunque. Ogni fix significa cercare l'admin center giusto, il cmdlet PowerShell giusto o la chiamata Microsoft Graph giusta, e poi applicare una modifica in un sistema di identità in produzione dove un errore chiude fuori persone in carne e ossa. Moltiplica per qualche centinaio di finding e la coda diventa un backlog, e i backlog sono il posto dove i finding vanno a invecchiare.

Secondo, il report della scansione non esce mai dal team di sicurezza. È scritto in ID di controllo e percorsi di configurazione. Le persone che decidono organico e budget non ne vedono nulla, oppure vedono un punteggio di conformità senza alcuna storia dietro. Un tenant può restare al 60 percento di conformità per un anno, e il management scoprirà cosa significava solo durante la retrospettiva dell'incidente.

Nota che nessuna delle due lacune riguarda la qualità della detection. Una detection migliore allarga la prima lacuna. Il punto conta perché gran parte del marketing su "AI nella sicurezza" parla di rilevare di più. Il lavoro interessante sta a valle della detection.

AI Pilot: remediation con un gate di approvazione umano

AI Pilot è la risposta di Aether365 alla prima lacuna, e il suo design è un caso di studio utile su come dovrebbe funzionare la remediation agentica, chiunque la costruisca. Il ciclo ha quattro fasi: scansione, proposta, approvazione, applicazione e verifica.

La scansione produce i finding. Per ogni finding, il sistema genera un fix concreto mappato sull'esatta modifica Microsoft Graph che verrà eseguita, non un suggerimento in prosa, la mutazione vera e propria. Poi esamini ogni modifica proposta una per una e la approvi o la rifiuti singolarmente. Solo le modifiche approvate vengono applicate, e ogni modifica applicata viene verificata e scritta in un audit trail.

La lezione da 101 qui è il modello di permessi, perché è il punto in cui i sistemi agentici in produzione si guadagnano la fiducia oppure la perdono. L'accesso in sola lettura è il default e resta il default. AI Pilot richiede una connessione Microsoft di consenso in scrittura separata ed esplicita, a cui aderisci volontariamente. Se non la abiliti mai, la piattaforma non può fisicamente modificare il tuo tenant. È questo che rende lo strumento usabile per i tenant UE e regolamentati che devono restare in sola lettura: il percorso di scrittura non è un interruttore dentro l'app, è un confine di consenso applicato dal layer di autorizzazione di Microsoft stesso.

Confrontalo con la modalità di fallimento: un agente completamente autonomo con accesso in scrittura permanente che corregge le cose man mano che le trova. Sembra efficiente finché non "corregge" una policy di Conditional Access alle 2 di notte e l'ingegnere di turno non riesce ad accedere per capire perché. L'autonomia senza un gate di approvazione per singola modifica trasforma uno strumento di remediation in un admin non auditato con pazienza infinita. Il gate non è una limitazione dell'AI. È la funzionalità.

Business Impact Reports: il layer di traduzione

La seconda lacuna è la comunicazione, ed è oggi l'uso meno appariscente e più difendibile degli LLM nella sicurezza. I modelli linguistici sono davvero bravi in una cosa in cui gli strumenti di sicurezza sono sempre stati scarsi: tradurre uno stato tecnico in una narrazione su cui un lettore non tecnico può agire.

Business Impact Reports prende i finding grezzi della scansione e produce un documento pronto per il board: un executive summary in linguaggio semplice, cosa significa il punteggio di conformità per il business, quali unità di business portano più rischio, una roadmap prioritizzata del tipo "fai prima questo" e una mappatura dei finding sugli obblighi GDPR, NIS2 e ISO 27001. Viene generato in una qualsiasi di 24 lingue, cosa che conta più di quanto sembri: un CFO a Monaco riceve il report in tedesco mentre il team di sicurezza lavora in inglese, dagli stessi dati di scansione.

Due avvertenze appartengono a qualsiasi 101 onesto. Il report vale quanto la scansione che ci sta sotto; un LLM che racconta dati sbagliati produce sciocchezze piene di sicurezza, con tanto di numeri di pagina. E la reportistica generata dall'AI richiede una posizione chiara sul trattamento dei dati. Quella di Aether365 è: i tuoi dati di scansione non vengono mai usati per addestrare o fare fine-tuning di alcun modello, l'AI gira solo per generare il tuo report sul momento e tutto resta sotto supervisione umana, in linea con l'EU AI Act. Qualunque strumento tu scelga, pretendi queste risposte per iscritto.

Una checklist 101 per qualsiasi funzionalità AI di sicurezza

Togli il branding e valuta qualsiasi funzionalità "AI più sicurezza" con cinque domande:

  • L'accesso in scrittura è opt-in e con un consenso separato? Sola lettura di default è il minimo indispensabile. Un percorso di consenso in scrittura separato è il vero test.
  • Posso approvare ogni modifica singolarmente? L'approvazione in blocco di 300 modifiche è un timbro, non un gate.
  • Esiste un audit trail verificato? Applicato non è la stessa cosa di verificato. Servono entrambi, per ogni modifica.
  • L'AI prende decisioni o prepara presentazioni? Un'AI che redige fix e report per l'approvazione umana è a basso rischio. Un'AI che agisce senza supervisione sull'infrastruttura di identità non lo è.
  • I miei dati vengono usati per l'addestramento? Se la risposta richiede più di una frase, la risposta è sì.

AI Pilot e Business Impact Reports sono, per me, la versione onesta dell'AI nella sicurezza: il modello fa la mappatura tediosa e la traduzione, gli umani mantengono l'autorità. La detection non è mai stata il collo di bottiglia. Correggere e spiegare lo erano, ed è esattamente lì che questa generazione di strumenti dovrebbe puntare.

Leggi questo dopo

Per il lato infrastrutturale di questa storia, perché un tenant Microsoft 365 va trattato come qualsiasi altro patrimonio cloud, leggi Controllare il cloud con il cloud: M365 Security Posture Scanning 101 su ercan.cloud. Per consulenza su AI, cloud e lavoro di piattaforma, o anche solo per un saluto, parti da ercanermis.com.

Riferimenti