Ivanti Blog

Il reparto IT invisibile: come offrire esperienze senza attriti con l'AI agentica

Thu, 18 Jun 2026 19:42:35 Z

Ogni azienda ha acquistato soluzioni di AI, ma molte stanno ancora aspettando che l'investimento dia i suoi frutti. Il 2026 AI Maturity Report di Ivanti ha rilevato che solo il 2% delle organizzazioni afferma di non utilizzare attualmente l'AI in alcun modo. Mentre la maggior parte delle organizzazioni supera la fase di sperimentazione dell'AI, il vero elemento di differenziazione competitiva è capire se quell'AI stia generando valore aziendale continuo e su larga scala.

Le aziende implementano chatbot che gli utenti ignorano. Introducono agenti di cui nessuno si fida e distribuiscono strumenti "basati sull'AI" che i dipendenti finiscono per aggirare o trascurare, ricorrendo a strumenti personali di shadow AI. Il problema non è ciò che l'AI può fare, ma ciò che chiedi agli utenti di fare con essa. La maggior parte delle organizzazioni considera l'AI come una funzionalità da distribuire anziché come un'esperienza da progettare. Si concentra su ciò di cui l'AI è capace invece che su ciò di cui gli utenti hanno realmente bisogno. Il risultato è un'altra soluzione inutilizzata che genera più frustrazione che valore.

L'esperienza digitale è l'anello mancante che separa le implementazioni AI riuscite da quelle fallimentari. Le organizzazioni che danno priorità all'esperienza utente dell'AI possono individuare le insidie di implementazione che compromettono la fiducia degli utenti e sviluppare un framework pratico per distribuire AI agentica in grado di apportare miglioramenti senza interruzioni. AI e IT funzionano al meglio quando agiscono come superpoteri invisibili. Gli utenti non notano la tecnologia; notano con quanta facilità riescono a svolgere il proprio lavoro.

Il paradosso dell'adozione dell'AI

Una ricerca del MIT suggerisce che circa il 95% delle iniziative AI aziendali non riesce a generare un ROI misurabile, con la maggior parte che si blocca in fase pilota invece di scalare verso un reale valore di business.

Come accade: La leadership approva un'iniziativa AI, l'IT implementa la tecnologia, vengono pianificate sessioni di formazione, si monitorano le metriche di adozione e, nel giro di sei mesi... nessuno la usa. Il chatbot resta inattivo, l'assistente AI non viene utilizzato e i dipendenti sviluppano soluzioni alternative per evitare proprio quegli strumenti che avrebbero dovuto semplificare il loro lavoro.

Non si tratta di un fallimento del change management, ma del risultato di una scarsa comprensione di ciò che gli utenti sperimentano realmente quando si aggiunge l'AI a tutto il resto della tecnologia presente sul posto di lavoro.

Gli utenti non vogliono l'AI fine a sé stessa. Vogliono che il laptop si avvii più rapidamente, che le applicazioni non si blocchino durante una presentazione, che le videochiamate non abbiano ritardi e che i problemi si risolvano prima ancora che si accorgano che qualcosa non va. Quando li costringi a interagire con un'interfaccia AI per ottenere tutto questo, hai già perso.

Per saperne di più: Come l'AI agentica per ITOps sblocca valore su larga scala

Perché la maggior parte delle implementazioni AI fallisce sull'esperienza utente

Entra in qualsiasi ambiente IT aziendale e troverai lo stesso schema. La checklist di implementazione dell'AI viene seguita alla lettera:

Fornitore tecnologico selezionato
Piattaforma implementata
Integrazioni configurate
Utenti formati
Go-live completato

Ma sei mesi dopo, la realtà si impone. Un sondaggio EY del 2025 ha rilevato che il 64% dei dipendenti ha segnalato un aumento dei carichi di lavoro nonostante le implementazioni AI, mentre solo il 5% ha dichiarato di sfruttare l'AI al massimo per trasformare davvero il proprio lavoro.

L'IT ha fatto tutto correttamente secondo il manuale, ma il problema è che quel manuale è stato scritto da chi vende AI, non da chi la utilizza.

Considera la tipica implementazione di un chatbot AI pensata per "potenziare il self-service" e "ridurre il volume dei ticket". Nella pratica, significa che i dipendenti che prima inviavano un rapido messaggio su Slack all'IT ora devono:

Accedere a un portale separato
Capire come formulare la domanda in modo che il bot la comprenda
Scorrere articoli della knowledge base irrilevanti proposti dall'AI
Alla fine rinunciare e aprire comunque un ticket, ormai irritati e con quindici minuti di ritardo sulla tabella di marcia

Il ticket viene comunque creato e il problema deve comunque essere risolto, ma ora c'è attrito dove prima non c'era, perché hai aggiunto passaggi invece di eliminarli.

Questo è l'errore fondamentale: trattare l'AI come un'interfaccia con cui gli utenti devono interagire, invece che come un'infrastruttura che lavora per loro. Nel momento in cui chiedi agli utenti di cambiare comportamento per adattarsi alla tua AI, stai creando resistenza, non adozione.

Esperienza digitale: dove l'AI dimostra il suo valore

Le organizzazioni che ottengono valore reale dall'AI hanno smesso di chiedersi "Come facciamo a far adottare agli utenti questo strumento di AI?" e hanno iniziato a chiedersi "Come possiamo usare l'AI per migliorare ciò che gli utenti fanno già?" È un cambiamento sottile, ma dalle implicazioni enormi.

Nella gestione dell'esperienza digitale, l'AI non si interpone tra l'utente e il suo lavoro. Si interpone tra l'utente e il caos: vale a dire il degrado delle prestazioni, i malfunzionamenti delle applicazioni, i rallentamenti misteriosi, i problemi che non sono ancora emersi ma lo faranno nei prossimi 30 minuti.

È qui che l'AI agentica cambia radicalmente ciò che è possibile. Gli strumenti di monitoraggio tradizionali avvisano le persone quando qualcosa si rompe. L'AI agentica, invece, previene il guasto prima che si verifichi. È la differenza tra un rilevatore di fumo e un sistema antincendio.

Le operazioni IT tradizionali misurano la risposta agli incidenti in ore o persino giorni. L'AI agentica con remediation autonoma sta cambiando radicalmente questa equazione, riducendo il tempo medio di risoluzione da ore a minuti o secondi grazie al rilevamento dei pattern e all'esecuzione delle correzioni prima che i problemi si aggravino.

Ecco come appare nella pratica:

IT Ops tradizionale:

Il laptop di un utente inizia a mostrare i primi segnali di guasto del disco.
Gli strumenti DX tradizionali segnalano il problema e creano un ticket.
Un analista IT dovrebbe esaminare l'avviso, valutarne la gravità, pianificare la manutenzione e infine contattare l'utente.
Tempo totale di risoluzione: diversi giorni.
Impatto sull'organizzazione: downtime pianificato, migrazione dei dati e perdita di produttività.

AI agentica

Con l'AI agentica, il pattern viene rilevato prima che l'utente si accorga che qualcosa non va.
L'agente attiva autonomamente processi di backup automatizzati, effettua il provisioning di un dispositivo sostitutivo, prepara le applicazioni e i dati dell'utente e pianifica la sostituzione durante un periodo di bassa attività.
L'utente riceve un'email: "Il tuo nuovo laptop ti aspetterà alla reception domani mattina. La configurazione esistente è stata trasferita."
Nessun ticket creato, nessuna escalation necessaria, nessuna interruzione subita.

È lo stesso problema, ma con un'esperienza radicalmente diversa.

Creare un framework di implementazione AI senza attriti

Raggiungere un'AI invisibile richiede di ripensare il modo in cui implementi, misuri e porti su scala le iniziative di esperienza digitale. Le organizzazioni che ottengono un ROI reale dall'AI agentica seguono un modello coerente che dà priorità all'esperienza rispetto alle funzionalità.

Parti dal problema, non dalla possibilità

Le peggiori implementazioni AI iniziano con la domanda: "Che cosa può fare questa AI?" Le migliori partono da: "Che cosa oggi è doloroso, ripetitivo o rallenta inutilmente gli utenti?"

Mappa i punti critici dell'esperienza digitale prima di mappare le capacità dell'AI:

Dove gli utenti attendono più a lungo la risoluzione dei problemi?
Quali problemi generano ticket ricorrenti?
Quali degradi delle prestazioni si verificano in modo prevedibile ma non vengono intercettati proattivamente?
Dove l'IT dedica più tempo ad attività che non richiedono giudizio umano?

Questi sono problemi di esperienza utente che l'AI può eliminare, non semplici "casi d'uso dell'AI", e la distinzione è importante. Quando parti dal problema, arrivi a soluzioni che gli utenti desiderano.

Implementa l'AI dietro l'esperienza

Gli utenti non dovrebbero mai dover decidere se interagire con la tua AI, perché questo è il tuo compito come implementatore. Nella pratica, significa:

Agenti autonomi che rilevano e risolvono i problemi prima che sia necessario chiedere aiuto invece di un bot a cui gli utenti devono chiedere supporto.
Un motore di insight predittivi che propone soluzioni agli utenti prima che le cerchino invece di un portale self-service con ricerca basata sull'AI.
Sistemi autoriparanti che eseguono automaticamente le raccomandazioni entro guardrail approvati invece di raccomandazioni basate sull'AI che gli utenti devono mettere in pratica.

Il modello è coerente: ridurre i punti decisionali per l'utente, eliminare passaggi aggiuntivi e rimuovere la necessità di un'ampia alfabetizzazione sull'AI. La tua AI agentica dovrebbe richiedere zero formazione agli utenti, perché gli utenti non dovrebbero mai interagire direttamente con essa.

Misura l'esperienza utente, non le prestazioni dell'AI

È qui che la maggior parte delle implementazioni prende la direzione sbagliata: misura le prestazioni dell'AI invece dei risultati per gli utenti

Se stai monitorando il numero di interazioni con l'AI, il tempo di risposta dell'AI, i punteggi di accuratezza del modello o il tasso di automazione, stai misurando le cose sbagliate.

Piuttosto:

Monitora la riduzione del tempo medio di risoluzione per i problemi degli utenti finali. Il 2026 AI Maturity Report di Ivanti ha rilevato che il 45% dei professionisti IT afferma che l'AI ha reso il loro lavoro più rapido e migliore.
Monitora la soddisfazione dichiarata dagli utenti rispetto alla reattività dell'IT.
Monitora la percentuale di problemi risolti prima che gli utenti se ne accorgano.
Monitora il tempo risparmiato sulle richieste ripetitive.
Monitora la riduzione del volume dei ticket, non perché stai deviando i problemi, ma perché li stai prevenendo.

Il framework di governance che abilita l'autonomia dell'AI

Ciò che rallenta davvero la maggior parte delle implementazioni di AI agentica non è un problema tecnico: è fare in modo che gli stakeholder si sentano a proprio agio con un'AI che agisce senza chiedere prima il permesso.

Livello di autonomia	Livello di rischio	Azioni di esempio
Autonomia completa	Basso	Pulizia della cache, riavvii dei servizi, ottimizzazione delle prestazioni, patching di routine
Autonomia con notifica	Medio	Reimpostazioni dei profili utente, reinstallazioni delle applicazioni, aggiornamenti dei driver
Approvazione umana richiesta	Alto	Modifiche di configurazione importanti, migrazioni dei dati, modifiche dell'infrastruttura
Guidata dall'uomo, assistita dall'AI	Critico	Risposta agli incidenti di sicurezza, decisioni di compliance, approvazioni di budget

La chiave è riconoscere che ciò che è "ad alto rischio" si riduce nel tempo man mano che gli agenti AI dimostrano affidabilità e il monitoraggio rileva pattern che inizialmente non avevi previsto. Le organizzazioni che trattano la governance dell'AI come statica finiscono con un'AI che non può fare abbastanza per incidere davvero. Quelle che trattano la governance come dinamica ottengono un'AI che amplia continuamente il proprio impatto mantenendo la sicurezza.

Che aspetto ha il successo

Le organizzazioni che implementano esperienze di servizio basate sull'AI stanno registrando aumenti significativi della soddisfazione. Una ricerca PwC ha rilevato che le implementazioni leader hanno ottenuto miglioramenti dell'NPS del 10-15%, insieme a efficienze operative.

La conversazione sull'AI cambia. Gli utenti smettono di parlare dell'IT come di qualcosa che li ostacola e iniziano a non parlare affatto dell'IT, ed è esattamente questo il punto. L'IT diventa infrastruttura: invisibile, affidabile e presente solo quando serve intenzionalmente.

Il service desk nota per primo il cambiamento, ad esempio:

Il volume dei ticket diminuisce non perché stai deviando i problemi, ma perché li stai prevenendo
Le escalation diminuiscono perché l'AI intercetta e risolve i problemi in fasi progressivamente più precoci
Il tempo degli analisti viene riallocato dalla gestione reattiva delle emergenze al miglioramento proattivo dei sistemi
Il tempo medio di risoluzione si riduce perché la remediation spesso avviene più rapidamente di quanto avvenisse il rilevamento nel vecchio modello

Per gli utenti finali, l'esperienza è più semplice: le cose funzionano, le applicazioni sono reattive, i sistemi sono disponibili e i rallentamenti non si trasformano in guasti. E quei misteriosi problemi di prestazioni di cui si lamentano i colleghi, in qualche modo, non capitano a loro: non perché siano fortunati, ma perché gli agenti AI ottimizzano continuamente la loro esperienza in modi che non vedranno mai.

La vera metrica di adozione è questa: quando gli utenti smettono di pensare all'IT. Non perché lo ignorino, ma perché non c'è nulla a cui pensare.

La vera scelta: AI invisibile o AI ignorata

Ogni organizzazione implementerà l'AI nella gestione dell'esperienza digitale. La domanda non è se lo farà, ma come, e soprattutto se gli utenti ne trarranno davvero beneficio o si ritroveranno semplicemente un altro strumento imposto dall'alto.

Questo richiede di ripensare radicalmente il modo in cui implementi, misuri e porti su scala le iniziative AI. Se lo fai nel modo giusto, trasformi il modo in cui la tua organizzazione percepisce l'IT: da centro di costo a vantaggio competitivo, da gestione reattiva delle emergenze ad abilitazione proattiva, da sovrastruttura necessaria a infrastruttura invisibile che funziona e basta.

La migliore AI, come il miglior IT, è quella che non vedi mai. Gli utenti non sperimentano la tua tecnologia, ma l'assenza di problemi. Ed è proprio questo il punto.

Pronto a migliorare la tua esperienza digitale con l'AI agentica?

Scopri come Ivanti Neurons for ITSM implementa AI agentica che lavora dietro le quinte, prevedendo i problemi, risolvendoli autonomamente e ottimizzando le esperienze prima che gli utenti si accorgano che qualcosa non va.

Shadow IT e punti ciechi della discovery IA: cosa sfugge agli strumenti legacy

Mon, 15 Jun 2026 13:32:02 Z

Chiedi a tre team quali asset esistono nel tuo ambiente e otterrai tre risposte diverse. Alla maggior parte delle organizzazioni non mancano gli strumenti. Manca un allineamento su ciò che esiste davvero nel loro ambiente. I dati su asset, endpoint e cloud esistono, ma sono frammentati, obsoleti e considerati affidabili in modo diverso dai team di ogni reparto e funzione.

Il motivo di questa disconnessione? Nell’era dell’IA, gli ambienti cambiano più rapidamente di quanto la discovery legacy sia progettata per gestire. I workload cloud vengono creati e scompaiono in pochi minuti, spesso con provisioning automatico per test, scalabilità o progetti a breve termine. Ma oggi il divario si amplia ulteriormente a causa di servizi IA, copiloti, API e modelli integrati, oltre a strumenti basati su browser e workflow di automazione, che i team adottano senza passare dal provisioning IT standard.

Quando gli strumenti di discovery tradizionali analizzano l’ambiente, queste risorse potrebbero essere già scomparse o potrebbero non comparire mai nei sistemi su cui l’IT fa affidamento come unica fonte di verità — senza lasciare alcun record, alcun proprietario e alcun contesto operativo condiviso. Nel frattempo, l’adozione del SaaS continua a crescere in ogni reparto, i dispositivi remoti raramente si collegano alla rete aziendale e identità, integrazioni e flussi di dati contano ormai quanto i dispositivi. Eppure molte organizzazioni si affidano ancora ad approcci di discovery pensati per un mondo di endpoint statici e perimetri prevedibili.

Il risultato è una visibilità parziale nel migliore dei casi, con punti ciechi in aumento ovunque altrove.

Nel 2026, il divario di visibilità è ormai diventato un abisso e i dati sono chiari. Secondo la ricerca di Ivanti sulla gestione autonoma degli endpoint, il 45% dei professionisti IT dichiara di non disporre di dati sufficienti sullo shadow IT e il 38% afferma di avere dati insufficienti sui dispositivi che accedono alla rete. Il problema si amplifica negli ambienti cloud.

Secondo la ricerca 2025 di SecPod, il 67% delle organizzazioni ha difficoltà con i punti ciechi nei propri inventari degli asset cloud, a conferma del fatto che anche le organizzazioni dotate di strumenti IT e di sicurezza moderni operano ancora con una visibilità incompleta.

Questi punti ciechi creano più di semplici lacune nell’inventario. Quando i team non riescono a concordare quali asset siano reali, attivi o dismessi, l’IT e la sicurezza lavorano su tempistiche divergenti. La risposta agli incidenti rallenta. La prioritizzazione dell’esposizione si indebolisce. I team di sicurezza inseguono avvisi senza contesto. I responsabili IT consumano ore a riconciliare fogli di calcolo invece di ridurre il rischio.

A rendere tutto questo particolarmente oneroso non sono solo i dati mancanti, ma anche l’azione ritardata. Quando i team non possono fidarsi di ciò che esiste nel loro ambiente, ogni risposta rallenta: gli incidenti richiedono più tempo per essere risolti, gli audit impongono riconciliazioni manuali e le decisioni sul rischio vengono prese con un contesto incompleto. Le lacune di visibilità non aumentano soltanto l’esposizione; assorbono tempo, attenzione e fiducia operativa in ambito IT e sicurezza.

Nell’esperienza maturata da Ivanti con grandi aziende ibride, è emerso un modello chiaro. Le lacune di visibilità raramente esistono perché i team non implementano la discovery, ma perché questi strumenti non sono mai stati progettati per condividere o riconciliare i dati alla velocità richiesta dagli ambienti moderni.

Gli strumenti legacy non sono semplicemente superati. Sono fondamentalmente incompatibili con la velocità e la complessità dell’IT moderno.

Dove gli strumenti legacy restano indietro

I limiti degli strumenti di discovery legacy rientrano in cinque categorie, ciascuna delle quali amplifica le altre:

Visibilità frammentata

Secondo il report 2025 Securing the Borderless Digital Landscape di Ivanti, 2 dispositivi edge su 5 sono attualmente al di fuori della gestione e della supervisione dell’IT. Oggi quasi ogni organizzazione dispone di account cloud non autorizzati, ma le soluzioni di discovery tradizionali non riflettono questa realtà. La maggior parte degli strumenti puntuali acquisisce solo una porzione dell’ambiente, ma raramente la riconcilia in una vista operativa condivisa. Per i direttori IT, questa frammentazione significa dover gestire più dashboard durante interruzioni e audit. Per i CIO, significa spesa sprecata e decisioni ritardate. Quando nessun team considera i dati abbastanza affidabili da agire con sicurezza, l’intera organizzazione rallenta.

Dipendenza dagli agent

La discovery basata su agent continua a svolgere un ruolo importante nell’IT moderno, soprattutto per raccogliere telemetria approfondita dagli endpoint gestiti. Il problema nasce quando la discovery diventa esclusivamente basata su agent. Negli ambienti ibridi, molti asset non possono supportare un agent. I workload cloud temporanei possono esistere per pochi minuti o poche ore. Le applicazioni SaaS e i servizi gestiti non consentono affatto la distribuzione di agent. I dispositivi dei contractor, gli endpoint personali e i sistemi non gestiti spesso restano al di fuori delle policy di controllo aziendali.

Di conseguenza, questi asset non compaiono mai negli inventari che si basano esclusivamente sulla raccolta tramite agent. Il difetto non è negli agent in sé, ma nell’affidarsi a un unico metodo di raccolta che non può coprire l’intero perimetro degli ambienti moderni.

Questa limitazione strutturale contribuisce direttamente alle lacune di visibilità che le organizzazioni continuano ad affrontare. Secondo la ricerca 2025 di Trend Micro, quasi 3 organizzazioni su 4 hanno subito incidenti di sicurezza causati da asset sconosciuti o non gestiti. Questi dati dimostrano come la discovery basata solo su agent lasci sistematicamente non monitorate aree significative dell’ambiente.

Il report 2025 Digital Employee Experience di Ivanti ha rilevato che il 27% dei lavoratori d’ufficio utilizza regolarmente strumenti e applicazioni non autorizzati, spesso per frustrazione nei confronti della tecnologia fornita dal datore di lavoro. Questo comportamento amplia la superficie di attacco più rapidamente di quanto i metodi di discovery tradizionali riescano a reagire.

Punti ciechi di rischio ed esposizione

Quando parti dell’ambiente restano invisibili, le organizzazioni perdono la capacità di mantenere controlli di sicurezza coerenti. Dispositivi non monitorati, risorse cloud non riconosciute e servizi SaaS non autorizzati spesso aggirano patching, baseline di configurazione e applicazione delle policy. Questi punti ciechi aprono percorsi che gli aggressori possono sfruttare attraverso configurazioni errate, workload non aggiornati o asset dimenticati.

Scansioni lente e puntuali

Le scansioni periodiche non riescono a stare al passo con la velocità del cloud o con il ricambio del SaaS. SecPod ha rilevato che solo il 42% delle organizzazioni dispone di monitoraggio in tempo reale, lasciando ampie finestre in cui le configurazioni errate passano inosservate. Incidenti di grande rilievo che coinvolgono bucket di storage cloud esposti, endpoint API non protetti e controlli di accesso configurati in modo errato continuano a dimostrare come risorse di breve durata o tracciate in modo inadeguato possano introdurre rischi molto prima che i team sappiano della loro esistenza.

Riconciliazione manuale

I dati provenienti da fogli di calcolo, ITSM, CMDB e strumenti disconnessi raramente coincidono. Secondo una ricerca sulla cybersecurity del 2025 condotta da Bedrock Security, l’82% delle organizzazioni segnala lacune di visibilità nel proprio panorama di asset, dovute a fonti dati frammentate e a una responsabilità non coerente. Questi punti ciechi rendono difficile normalizzare e riconciliare gli inventari cloud, SaaS e on-premise, lasciando i team di sicurezza e IT nell’incertezza sulla completezza o accuratezza dei dati sugli asset.

Questi limiti rallentano le operations, indeboliscono la sicurezza e creano punti ciechi persistenti nell’intero patrimonio IT: esattamente i problemi che gli strumenti di discovery legacy non sono mai stati progettati per risolvere.

Un modello di visibilità governato dalla piattaforma per il mondo moderno

Aumentare semplicemente la frequenza delle scansioni o implementare un’altra soluzione puntuale non eliminerà il divario di visibilità. L’ambiente odierno richiede un approccio fondamentalmente diverso.

Gli ambienti moderni richiedono il passaggio dalla discovery periodica a un’intelligence continua e condivisa, di cui più team possano fidarsi. Un modello di visibilità governato dalla piattaforma stabilisce un sistema di riferimento condiviso per i dati di asset e configurazione in ambito IT e sicurezza, un sistema che normalizza, riconcilia e distribuisce costantemente un contesto operativo affidabile.

La discovery attiva e passiva operano insieme per far emergere dispositivi gestiti, endpoint non gestiti, workload cloud, app SaaS, asset remoti e le identità a essi collegate. In pratica, ciò richiede una base dati operativa condivisa in grado di governare l’intelligence su asset e configurazioni tra i vari sistemi, affinché i team lavorino a partire dalle stesse viste anziché da record frammentati o in conflitto.

Dati core della piattaforma e sistema di riferimento

La Ivanti Neurons Platform funge da layer di dati operativi autorevole per IT e sicurezza, governando asset, endpoint e stato di configurazione attraverso un sistema di riferimento aggiornato in modo continuo. Questo layer di dati operativi governato dalla piattaforma mantiene una vista costantemente aggiornata dell’inventario di asset e dispositivi, del contesto e delle relazioni di supporto e delle informazioni sul parco software.

Un motore di discovery continua acquisisce costantemente segnali da tutto l’ambiente e li normalizza, deduplica e riconcilia in dati operativi puliti e coerenti. Questa base dati governata è ciò su cui automazione e IA fanno affidamento per agire in modo sicuro e accurato, assicurando che le decisioni si basino sulla realtà operativa attuale anziché su input frammentati o in conflitto.

Quando i sistemi di esecuzione utilizzano questi dati governati dalla piattaforma, i team possono agire con fiducia in ambito IT e sicurezza. Laddove l’IT service management rientra nell’ambito, questi stessi dati operativi possono estendersi ai workflow ITSM e CMDB, supportando anche i casi d’uso ITAM come il monitoraggio del ciclo di vita e la gestione dei diritti software.

Normalizzare e riconciliare in modo continuo

Un layer di intelligence unificato pulisce, deduplica e correla record e segnali di utilizzo da ogni fonte, creando un dataset condiviso degli asset, aggiornato in modo continuo e adatto alle esigenze di audit operativo.

Mappare le esposizioni sugli asset reali

L’aggregazione delle esposizioni collega vulnerabilità e configurazioni errate ai dispositivi, agli utenti e ai responsabili dei servizi effettivamente interessati, migliorando la prioritizzazione delle vulnerabilità e accelerando la remediation.

Trasformare la visibilità in azione

Poiché gli ambienti continuano a evolversi più rapidamente di quanto gli strumenti tradizionali possano reagire, le organizzazioni devono ripensare il modo in cui la visibilità viene ottenuta e condivisa. Il percorso da seguire non inizia sostituendo ogni strumento, ma creando una base di visibilità affidabile che si integri con i sistemi esistenti e abiliti decisioni migliori in ogni altro ambito.

Questa base di visibilità live, governata dalla piattaforma, abilita Autonomous Endpoint Management. Basata sulla Ivanti Neurons Platform, agisce con fiducia attivando remediation, patching, applicazione delle configurazioni e self-healing sulla base di uno stato operativo verificato.

Per le organizzazioni vincolate da approcci di discovery legacy, questo significa:

Passare da snapshot periodici a un’intelligence continua.
Passare da strumenti isolati a un contesto condiviso.
Sostituire la riconciliazione manuale con una fiducia automatizzata.

La discovery moderna, governata dalla piattaforma non si limita a migliorare la visibilità. Crea le condizioni per l’azione, in cui l’insight può attivare in modo affidabile remediation, automazione e verifica invece di rimanere bloccato nelle dashboard.

Pronto a eliminare definitivamente i punti ciechi? Scopri come la Ivanti Neurons Platform stabilisce una visibilità affidabile su asset e configurazioni e consente a gestione autonoma degli endpoint, gestione dell’esposizione e workflow ITSM di agire su dati operativi governati negli ambienti ibridi.

Come l’AI agentica sta trasformando infrastruttura e operations

Thu, 11 Jun 2026 13:35:04 Z

I team di infrastruttura e operations (I&O) operano da tempo in un paradosso noto: più rapidamente cresce il business, maggiore è la pressione assorbita dall’I&O. Ogni nuovo deployment applicativo, ogni endpoint aggiunto e ogni workload cloud avviato generano maggiore complessità, più rischi e più ticket.

Le risposte tradizionali a questa pressione — più personale, più strumenti, più script, più API — hanno offerto, nella migliore delle ipotesi, un sollievo incrementale. Tuttavia, il problema strutturale di fondo, l’architettura sottostante delle operations reattive, è rimasto ostinatamente invariato. Fino a oggi.

L’AI agentica reinventa completamente questa architettura.

L’AI nell’IT e nelle operations (I&O) ha superato la fase di assistenza e suggerimento. Gli agenti autonomi in grado di ragionare, pianificare, eseguire e apprendere sono ormai operativi, non più solo voci nelle roadmap future. Le organizzazioni che stanno implementando intenzionalmente l’AI agentica stanno già ottenendo benefici significativi. Il nostro report di ricerca 2026 sulla maturità dell’AI ha rilevato che il 57% delle organizzazioni IT utilizza l’AI agentica per diversi workflow IT importanti, mentre il 17% vi fa affidamento per processi end-to-end estesi. Questa implementazione sta riducendo i tempi di risoluzione da ore a minuti e deviando migliaia di ticket manuali ogni trimestre.

Inoltre, l’89% delle organizzazioni che ha scalato l’AI a un livello ampio o business-critical ha dichiarato che l’AI aiuta spesso i team a rilevare i problemi prima ancora che gli utenti finali se ne accorgano, rispetto al 43% nella fase iniziale di sperimentazione. Questo cambiamento sta portando l’I&O da un approccio reattivo a uno proattivo e intelligente.

La domanda che rimane è con quale rapidità la tua organizzazione possa compiere la transizione verso l’implementazione dell’AI agentica nel proprio ambiente I&O su larga scala.

Scopri di più:Trasformare l’IT con l’AI agentica: l’alba di un servizio accelerato e autonomo

Perché abbiamo raggiunto il limite dell’automazione tradizionale

Per comprendere l’importanza dell’AI agentica, è utile valutare ciò che l’ha preceduta e perché non è mai stato sufficiente.

L’automazione tradizionale nell’I&O è stata estremamente preziosa. I runbook hanno codificato la conoscenza istituzionale. Gli script hanno standardizzato i processi ripetitivi. I bot di Robotic Process Automation (RPA) gestiscono workflow strutturati basati su regole. Questi strumenti hanno ridotto lo sforzo manuale ai margini e hanno consentito ai team di fare di più con lo stesso organico. Ma sono sempre stati fondamentalmente fragili: dipendenti da istruzioni esplicite, incapaci di adattarsi a situazioni nuove e impossibilitati ad agire senza un intervento umano alla guida.

Considera uno scenario classico: un deployment di patch non riesce su un sottoinsieme di endpoint alle 2 del mattino. Un’automazione basata su regole potrebbe registrare l’errore e creare un ticket. Uno script più complesso potrebbe tentare un nuovo tentativo. Ma nessuno dei due può diagnosticare se l’errore deriva da un’applicazione in conflitto, da un agente danneggiato, da un problema di segmentazione della rete o da una deriva nella configurazione delle policy. Nessuno dei due può adattare in tempo reale la propria strategia di risoluzione. Nessuno dei due può comunicare il contesto al service desk, aggiornare il CMDB o eseguire un’escalation intelligente in base alla criticità degli asset interessati. Un ingegnere umano viene chiamato in reperibilità. Il ciclo continua.

Questo è il limite dell’automazione tradizionale: esegue istruzioni, ma non pensa. Automatizza attività, ma non può orchestrare risultati. E, con l’aumento esponenziale della complessità degli ambienti infrastrutturali — tra architetture on-premise, multi-cloud, edge e ibride — il divario tra ciò che l’automazione basata su regole può gestire e ciò di cui i team I&O hanno bisogno si è trasformato in un abisso.

L’AI agentica è la risposta per colmare questo divario.

Cosa significa l’AI agentica per l’I&O

I sistemi di AI agentica possono definire obiettivi in modo indipendente, sviluppare piani per raggiungerli, intraprendere azioni multi-step su strumenti e sistemi, valutare i risultati e adattare il proprio approccio, il tutto senza richiedere l’intervento umano a ogni passaggio. A differenza di un chatbot che risponde a una domanda o di uno script che esegue un workflow predefinito, un sistema agentico è orientato agli obiettivi e adattivo. Opera lungo l’intero ciclo di vita di un’attività, dall’identificazione alla risoluzione.

Nel contesto I&O, questo significa che un agente autonomo può fare ciò che prima richiedeva un ingegnere qualificato oppure una catena complessa e fragile di script di automazione: correlare segnali provenienti da sistemi di monitoraggio eterogenei, identificare la causa principale di un incidente, eseguire la risoluzione appropriata, verificare che la correzione abbia funzionato, aggiornare i record pertinenti e chiudere il ciclo, il tutto nel tempo che una persona impiegherebbe ad aprire un ticket.

Il cambiamento non è solo operativo, ma anche filosofico. Passiamo da un modello in cui le persone avviano l’azione e l’automazione la esegue, a un modello in cui gli agenti intelligenti avviano, eseguono e verificano l’azione, mentre le persone garantiscono supervisione e governance. Per i leader I&O, non si tratta di una minaccia per il team. È il più grande moltiplicatore di capacità che il tuo team abbia mai avuto.

L’AI agentica abilita l’I&O su larga scala

La coda dei ticket del service desk è il sintomo più evidente di una funzione I&O sotto pressione. Reimpostazioni delle password, installazioni software, provisioning degli accessi, risoluzione dei problemi di connettività: queste richieste ad alto volume e bassa complessità consumano una quota enorme del tempo degli analisti e aumentano i costi operativi. Sono anche profondamente frustranti per i dipendenti che hanno bisogno di una risoluzione immediata, non dopo una finestra SLA di 48 ore.

Scopri di più:Da gestore di ticket a team leader: gestire una forza lavoro IT agentica

Eliminare il predominio della coda dei ticket

L’AI agentica elimina la coda come collo di bottiglia. Immagina di avere un agente AI conversazionale, come Ivanti Neurons AI Self Service Agent, che non si limita a recuperare una risposta da una knowledge base: convalida l’identità, verifica le policy di conformità, esegue il workflow di provisioning, conferma la modifica nel system of record e notifica il richiedente, tutto in pochi minuti. Il ticket non arriva mai a un analista umano. Il tempo dell’analista viene recuperato per attività che richiedono giudizio umano.

Ora immagina di dare a un analista più tempo per gestire attività complesse. Un collega digitale basato su AI agentica lavora al fianco di un agente umano per offrire insight proattivi, consigliare il modo migliore per risolvere il problema e automatizzare tramite azioni intelligenti.

Le organizzazioni che implementano l’AI agentica nel service desk segnalano costantemente riduzioni significative del volume dei ticket, spesso entro il primo anno di implementazione e con ulteriori incrementi man mano che il sistema matura e apprende. Questa non è automazione nel senso tradizionale. È orchestrazione intelligente su larga scala.

Risoluzione proattiva prima che gli utenti ne avvertano l’impatto

Gli incidenti più costosi nell’I&O sono quelli che si sarebbero potuti prevenire. Capacità disco non osservata finché non ha raggiunto il 100%. Scadenze dei certificati non monitorate finché i servizi non si sono interrotti. Vulnerabilità software non corrette finché non sono state sfruttate. Questi errori erano quasi sempre prevedibili a posteriori: i segnali c’erano. Il problema era che nessuno monitorava tutto, in ogni momento.

Autonomous Endpoint Management con AI agentica monitora continuamente la telemetria su endpoint, reti, applicazioni e infrastruttura cloud. Gli agenti rilevano anomalie, correlano segnali deboli e avviano la risoluzione prima che un problema si manifesti come interruzione o incidente di sicurezza. Un disco che si avvicina al limite di capacità viene ampliato. Un certificato in scadenza viene rinnovato. Un endpoint vulnerabile viene corretto con una patch durante la successiva finestra di manutenzione, prima che lo sfruttamento diventi un rischio.

Questo passaggio dal reattivo al proattivo è la capacità di maggior valore che l’AI agentica porta all’I&O. Non si limita a ridurre il costo degli incidenti: previene gli incidenti, i tempi di inattività, l’interruzione del business e il danno reputazionale che li accompagnano. Per i leader I&O, questo cambiamento ridefinisce il significato di successo operativo. Sposta la misurazione dal tempo medio di risoluzione, una metrica reattiva, al tempo medio di prevenzione: la frequenza con cui il tuo ambiente rileva e corregge prima che si verifichino impatti sul business.

Scalare senza aumentare l’organico

Gli ambienti IT aziendali crescono più rapidamente dei budget IT. Il rapporto tra endpoint e ingegneri continua ad aumentare. I workload cloud si moltiplicano. I requisiti di sicurezza si intensificano. In questo contesto, la leva tradizionale “assumere più persone” non è né finanziariamente sostenibile né operativamente sufficiente: il mercato dei talenti semplicemente non può fornire il volume di ingegneri qualificati richiesto.

L’AI agentica ridefinisce l’equazione della scalabilità. Un agente autonomo non ha orari di lavoro standard, limiti di capacità cognitiva o tempi di onboarding. Può gestire centinaia di attività simultanee su migliaia di endpoint senza degrado di prestazioni o qualità. Man mano che l’ambiente cresce, l’agente scala con esso: non in modo lineare, ma esponenziale. Un agente autonomo ben configurato può coprire il carico di lavoro precedentemente distribuito tra più analisti junior, liberando gli ingegneri senior affinché si concentrino su architettura, innovazione e iniziative strategiche invece che sulla risoluzione ordinaria.

Non si tratta di sostituire le persone. Si tratta di consentire loro di operare al livello che le loro competenze meritano.

Il system of record come fondamento del successo

Implementare efficacemente l’AI agentica richiede più di un motore AI capace. Richiede una base di dati affidabile e completa: tale base è il tuo system of record integrato nella piattaforma Ivanti Neurons, che contiene una fonte autorevole di dati, tra cui intelligence sui dispositivi, vulnerabilità ed esposizioni, inventario software e informazioni di gestione dei servizi. Un system of record che sa quali asset esistono, chi ne è il proprietario e se sono conformi.

Un system of record nel contesto I&O è la fonte autorevole di verità per il tuo ambiente IT: ogni asset hardware e software, ogni configurazione, ogni relazione, ogni policy, ogni modifica. È il livello di intelligence che consente a un agente autonomo di prendere decisioni con sicurezza. Senza di esso, un agente che opera nel tuo ambiente procede per tentativi. Con esso, ragiona a partire dai fatti.

Il più efficace system of record per l’AI agentica nell’I&O riunisce diversi elementi critici. I dati del Configuration Management Database (CMDB) devono essere accurati, aggiornati e arricchiti: non il repository obsoleto e aggiornato manualmente che la maggior parte delle organizzazioni ha ereditato, ma un record mantenuto dinamicamente del tuo ambiente reale. L’IT Asset Management (ITAM) consente di gestire gli asset dalla creazione alla dismissione e di garantire il mantenimento di una titolarità accurata.

I workflow di service management devono essere pienamente integrati, in modo che gli agenti possano creare, aggiornare e risolvere ticket come parte del loro flusso di esecuzione. I dati su identità e accesso devono essere accessibili, consentendo agli agenti di prendere decisioni conformi alle policy in materia di provisioning e diritti. Inoltre, i flussi di telemetria provenienti da strumenti di monitoraggio, vulnerabilità e prestazioni devono confluire in un contesto unificato che gli agenti possano interrogare in tempo reale.

Quando questi elementi sono presenti, gli agenti autonomi operano con precisione. Sanno quali asset sono critici e quali no. Sanno quali modifiche richiedono approvazione e quali rientrano nei confini di automazione definiti. Conoscono la storia di un asset — errori precedenti, patch in sospeso, software installato, vulnerabilità attive — e applicano quel contesto a ogni decisione.

Le organizzazioni che tentano di implementare l’AI agentica senza investire nel proprio system of record in genere riscontrano che i loro agenti producono risultati incoerenti o richiedono correzioni umane costanti. L’AI è intelligente solo quanto i dati a cui può accedere. Investire nella qualità e nell’integrazione dei dati non è un prerequisito che può essere rimandato: è il lavoro che determina se l’AI agentica offre valore trasformativo o un miglioramento marginale.

Valore per il business: oltre le metriche di efficienza

I benefici operativi dell’AI agentica nell’I&O sono convincenti di per sé. Tempi di risoluzione più rapidi. Volumi di ticket più bassi. Riduzione del tempo medio di rilevamento e risoluzione. Sono metriche che parlano ai leader I&O e giustificano l’investimento sulla base della pura efficienza dei costi.

Ma il valore per il business va ben oltre la dashboard del service desk.

Quando i team I&O vengono liberati dal lavoro reattivo e ripetitivo, reindirizzano la propria capacità verso iniziative che favoriscono la differenziazione competitiva: accelerare il deployment delle applicazioni, rafforzare la postura di sicurezza, abilitare programmi di trasformazione digitale e costruire l’infrastruttura resiliente e scalabile di cui il business ha bisogno per crescere. La funzione I&O evolve da centro di costo che assorbe il rumore operativo a facilitatore strategico che plasma i risultati di business.

L’esperienza dei dipendenti è una dimensione di questo valore spesso sottovalutata. Quando i dipendenti ricevono risposte istantanee e intelligenti alle loro richieste invece di attendere giorni in una coda di ticket, la loro produttività aumenta e la frustrazione verso l’IT diminuisce. In un mondo in cui l’esperienza dei dipendenti è un fattore di differenziazione competitiva per l’acquisizione e la fidelizzazione dei talenti, una funzione IT fluida e reattiva è un vero asset per il business.

L’AI agentica offre inoltre una riduzione significativa del rischio. In un ambiente in cui un singolo incidente ransomware può costare milioni in tempi di inattività e risoluzione, e in cui le sanzioni normative per la non conformità alla sicurezza aumentano, la gestione proattiva delle vulnerabilità e l’applicazione automatizzata delle policy forniscono una mitigazione del rischio quantificabile, rilevante ben oltre l’organizzazione IT, a livello di consiglio di amministrazione e nell’ufficio del CFO.

Infine, l’AI agentica accresce il proprio valore nel tempo. Ogni interazione, ogni risoluzione, ogni decisione di escalation genera dati che migliorano le prestazioni future dell’agente. A differenza dell’automazione statica, che si degrada con il cambiamento degli ambienti, i sistemi agentici si adattano e migliorano, offrendo rendimenti crescenti sull’investimento iniziale.

Il percorso da seguire

Infrastruttura e operations stanno attraversando una trasformazione cruciale. I sistemi che supervisioniamo oggi sono più complessi, distribuiti e vitali per il successo del business che mai nel panorama dell’IT aziendale. Le richieste sull’I&O sono ai massimi storici. Tuttavia, il modello operativo convenzionale, che si basa su interventi manuali reattivi e su un’automazione fragile guidata da regole, ha raggiunto il suo massimo potenziale.

L’AI agentica offre un modello fondamentalmente migliore: un modello in cui agenti intelligenti e autonomi gestiscono il lavoro ad alto volume, sensibile al tempo e sempre più complesso della gestione dell’infrastruttura, in modo continuo, accurato e su larga scala, mentre i tuoi ingegneri si concentrano sul lavoro strategico che rende la tua organizzazione più competitiva e resiliente.

Le organizzazioni che investono oggi in questa capacità non stanno semplicemente migliorando le proprie operations IT. Stanno costruendo una funzione I&O in grado di rispondere alle esigenze del prossimo decennio della tecnologia aziendale. Crediamo che questo sia lo standard a cui ogni leader I&O dovrebbe puntare e che l’AI agentica sia lo strumento più potente disponibile per arrivarci.

Scopri come le funzionalità di AI agentica di Ivanti aiutano i team I&O a trasformare le proprie operations in Affrontare il passaggio all’AI agentica nell’IT Service Management.

Per elevare la maturità della sicurezza, ripensate le capacità di remediation delle vulnerabilità

Thu, 28 May 2026 14:00:05 Z

I team di sicurezza sono sommersi dalle vulnerabilità. Parliamo di decine di migliaia di rilevamenti ogni trimestre. Centinaia di migliaia nelle organizzazioni più grandi. Gli ambienti IT di oggi non hanno confini e si estendono su ogni piattaforma OS. Gestire e proteggere questo patrimonio in modo lineare non è più sostenibile, così come non lo è un processo di remediation delle vulnerabilità che tratta ogni correzione come un’attività semplice e a basso impatto.

La prioritizzazione basata sul rischio aiuta a fare chiarezza in questo rumore introducendo il contesto delle minacce e il contesto di business nel processo di remediation delle vulnerabilità. È stato un passo avanti significativo. Ma molte organizzazioni che hanno adottato la prioritizzazione basata sul rischio continuano a non rispettare gli SLA, a generare attriti con l’IT e a vedere accumularsi eccezioni più rapidamente delle remediation.

Sapere cosa correggere per primo è solo una parte dell’equazione.

La parte più complessa, e quella che molti programmi ancora non hanno, è comprendere quale sarà l’impatto reale di quella correzione. E, soprattutto, come accelerare la remediation, passando da una cadenza mensile a un processo continuo, bilanciando rischio e impatto.

Questa è la remediation bilanciata a livello operativo: la pratica di valutare l’impatto reale di una correzione prima di implementarla. È il tassello critico mancante in molti programmi di remediation delle vulnerabilità e uno degli indicatori più chiari della maturità nella gestione dell’esposizione. Il Modello di maturità della gestione dell’esposizione di Ivanti la identifica come una delle sei capacità fondamentali che distinguono i programmi di sicurezza maturi da quelli reattivi.

Che cos’è la remediation bilanciata a livello operativo?

Il modello di maturità la definisce in modo semplice: la capacità di correggere o mitigare le esposizioni in modo efficace e praticabile. L’urgenza della sicurezza viene bilanciata con le realtà dell’IT, come la disponibilità dei sistemi, il test delle patch e la continuità operativa.

In pratica, si riduce a un’equazione: rischio di sicurezza più impatto reale uguale decisione di remediation informata. Identificare le esposizioni non ha valore se non è possibile porvi rimedio. E una remediation che causa downtime non pianificato, compromette i sistemi di produzione o attiva rollback non ha ridotto il rischio: lo ha solo spostato.

Il percorso di maturità della remediation delle vulnerabilità: da reattiva a strategica

Fase 1: gestione tradizionale delle vulnerabilità (l’era scan-and-patch)

È da qui che è iniziata la remediation delle vulnerabilità per molte organizzazioni, e dove molte si trovano ancora. La prioritizzazione è guidata dal CVSS e segue il criterio first-in-first-out. Lo scanner indica “Hai 10.000 CVE” senza alcun contesto su quali siano davvero rilevanti.

Le eccezioni restano non documentate. Le scansioni delle vulnerabilità e i workflow di remediation risiedono in strumenti separati, con un’integrazione minima.

Il risultato è una modalità reattiva: inseguire l’ultima divulgazione di alto profilo invece di affrontare ciò che rappresenta il rischio maggiore per l’ambiente.

Fase 2: prioritizzazione delle vulnerabilità basata sul rischio (aggiungere contesto)

La prioritizzazione basata sul rischio ha introdotto due domande migliori: “Questa vulnerabilità viene sfruttata attivamente?” e “Quanto è critico l’asset interessato?”. Combinare la gravità con la threat intelligence e la criticità degli asset ha offerto ai team di sicurezza un focus più preciso per le attività di remediation delle vulnerabilità. L’intelligence sulle vulnerabilità basata sull’AI e il punteggio di affidabilità delle patch hanno accelerato ulteriormente questo processo riducendo il carico di analisi manuale che in passato costringeva i team di sicurezza a prendere decisioni di prioritizzazione con dati incompleti.

Ma manca ancora un tassello. La prioritizzazione basata sul rischio indica alla sicurezza cosa correggere. Non dice nulla su ciò che l’IT deve mantenere in funzione. La collaborazione tra i due team avviene ancora spesso caso per caso, e l’impatto della remediation sulle operazioni IT resta un aspetto secondario o, più spesso, un freno che impedisce alle organizzazioni di accelerare le attività di remediation.

Fase 3: il tassello mancante — remediation bilanciata a livello operativo

Per le organizzazioni che hanno sviluppato la maturità necessaria a comprendere i rischi reali di un’esposizione, la domanda successiva è: “Quale sarà l’impatto di questa correzione sui sistemi che dobbiamo mantenere in funzione, e possiamo permetterci di lasciarla esposta?”

Quando la remediation delle vulnerabilità viene imposta senza considerare gli effetti a valle, il risultato è downtime, resistenza da parte dell’IT e un backlog crescente di eccezioni che compromettono proprio gli obiettivi di sicurezza alla base dell’urgenza.

Il report State of Cybersecurity 2026 di Ivanti ha rilevato che il 48% dei professionisti della sicurezza afferma che i team IT non rispondono con urgenza alle problematiche di cybersecurity, mentre il 40% ritiene che l’IT non comprenda la tolleranza al rischio della propria organizzazione. È ciò che accade quando sicurezza e IT operano con priorità diverse e senza un modo condiviso per risolverle.

I programmi più maturi affrontano questo aspetto non solo attraverso l’allineamento dei processi, ma anche tramite l’automazione, che elimina i passaggi manuali in cui si accumulano gli attriti. Le capacità automatizzate di self-healing possono rilevare, diagnosticare e risolvere proattivamente i problemi di endpoint e di igiene informatica. Questo riduce fin dall’inizio il volume di vulnerabilità che richiedono triage manuale. Quando la remediation è integrata nel funzionamento degli endpoint, anziché aggiunta a posteriori, il divario tra l’urgenza della sicurezza e la capacità dell’IT si riduce naturalmente.

L’indicatore di maturità, in questo caso, è chiaro: KPI condivisi tra sicurezza e IT, processi di eccezione documentati e un sistema di monitoraggio della remediation delle vulnerabilità che tenga conto sia della riduzione del rischio sia della continuità operativa. Per ottenere tutto questo in modo continuativo, IT e sicurezza devono operare a partire da dati e workflow condivisi.

Quando la visibilità sugli asset, l’aggregazione delle esposizioni, la prioritizzazione basata sul rischio e la remediation operano su una piattaforma unificata, l’allineamento richiesto dalla Fase 3 diventa una proprietà strutturale del sistema, anziché un risultato culturale ottenuto con grande fatica.

In che modo la remediation bilanciata a livello operativo si differenzia dalla prioritizzazione basata sul rischio

Il modo più semplice per vedere la progressione è osservare le domande a cui ciascun approccio può rispondere.

Approccio	Domande a cui risponde	Cosa manca
VM tradizionale	Quante vulnerabilità esistono?	Contesto e prioritizzazione
Prioritizzazione basata sul rischio	Quali vulnerabilità rappresentano il rischio maggiore?	Fattibilità e impatto operativi
Remediation bilanciata a livello operativo	Quali vulnerabilità dovremmo correggere per prime, considerando sia il rischio di sicurezza sia i vincoli operativi? In che modo l’automazione può garantire che tali correzioni vengano eseguite in modo efficiente e senza interruzioni?	Approccio più completo

Questo approccio aggiunge un livello di contesto alla gestione della remediation delle vulnerabilità: requisiti di test delle patch, dipendenze dei sistemi, finestre di manutenzione, potenziale downtime e capacità di rollback. Questi elementi determinano se una correzione regge o se crea nuovi problemi che richiedono un rollback.

Perché la remediation bilanciata a livello operativo è centrale nella gestione dell’esposizione

Il modello di maturità identifica sei capacità fondamentali: visibilità sugli asset, importanza degli asset, valutazione delle vulnerabilità nel mondo reale, prioritizzazione delle vulnerabilità guidata dal business, remediation bilanciata a livello operativo e integrazione di dati/workflow.

Tra queste, la remediation bilanciata a livello operativo è il livello di esecuzione che rende tutto il resto attuabile.

Senza di essa, la gestione dell’esposizione resta teorica. È possibile creare inventari degli asset perfetti, assegnare punteggi a ogni vulnerabilità con precisione e produrre dashboard dall’aspetto convincente.

Ma se il processo di remediation delle vulnerabilità resta separato, crea attrito tra sicurezza e IT, i rischi noti si accumulano, le patch vengono ritardate e le metriche su quelle dashboard smettono di riflettere la reale postura di rischio.

La progressione della maturità va dalla prioritizzazione ad hoc (Fase 1), alla collaborazione caso per caso (Fase 2), fino alla remediation guidata da KPI condivisi (Fase 3) e, infine, a retrospettive sottoposte ad audit con un ciclo di miglioramento continuo (Fase 4). Non tutte le organizzazioni devono raggiungere la Fase 4 in ogni capacità. Ma il passaggio da una remediation ad hoc a una remediation condivisa e guidata dai KPI è il punto in cui si ottengono i benefici reali.

Il business case: bilanciare sicurezza e obiettivi operativi

I costi nascosti della remediation senza contesto operativo

Quando la remediation delle vulnerabilità è guidata esclusivamente dall’urgenza della sicurezza, i costi si accumulano in modi che restano invisibili finché non diventano sistemici.

Il downtime non pianificato è il costo più evidente: sistemi business-critical messi offline senza un’adeguata valutazione dell’impatto. Ma gli effetti a valle sono altrettanto dannosi.

I team IT creano soluzioni alternative quando le imposizioni della sicurezza sono impraticabili, generando processi ombra che aumentano il rischio invece di ridurlo. La stanchezza da eccezioni prende piede quando le eccezioni superano i casi conformi, rendendo gli SLA privi di significato. E la fiducia tra sicurezza e IT si erode quando ciascuna parte vede l’altra come avventata o ostruzionista.

La ricerca di Ivanti conferma quanto sia diffuso questo attrito. Il 39% dei professionisti della cybersecurity afferma di avere difficoltà a prioritizzare la remediation del rischio e la distribuzione delle patch, mentre il 35% segnala difficoltà nel mantenere la conformità delle patch.

Nel frattempo, solo il 60% utilizza l’analisi dell’impatto sul business per orientare la prioritizzazione del rischio, e appena il 51% utilizza un punteggio di esposizione alla cybersecurity o un indice basato sul rischio.

Molti si affidano ancora a metriche di processo, come il tempo medio di remediation o la percentuale di esposizioni risolte, che possono apparire positive se considerate isolatamente ma dicono poco sul fatto che il processo di remediation delle vulnerabilità stia effettivamente migliorando la postura di rischio.

Il ROI della remediation automatizzata delle vulnerabilità bilanciata a livello operativo

Quando le organizzazioni compiono questo passaggio, i risultati emergono rapidamente. I KPI condivisi favoriscono tempistiche di remediation realistiche, che a loro volta migliorano la conformità agli SLA. Il tempo mediano di remediation diminuisce quando le barriere alla distribuzione sono previste, anziché scoperte a rollout già avviato.

Le correzioni durano perché tengono conto delle dipendenze dei sistemi e delle finestre di manutenzione, invece di creare nuovi problemi che richiedono un rollback. La distribuzione ad anelli è un buon esempio: le patch vengono distribuite a gruppi progressivamente più ampi e convalidate in ogni fase prima dell’espansione. È questo che rende praticabile la remediation bilanciata.

Combinati con workflow automatizzati che gestiscono correlazione, triage e orchestrazione della distribuzione, questi meccanismi trasformano la remediation bilanciata da concetto a sistema operativo continuo. Quando la piattaforma gestisce la complessità operativa, i team di sicurezza dedicano meno tempo alla gestione del processo di remediation e più tempo alla convalida dei risultati.

Le organizzazioni alla Fase 3 o alla Fase 4 di maturità nel modello Ivanti monitorano la remediation delle vulnerabilità con metriche che riflettono sia i risultati di sicurezza sia quelli operativi:

SLA suddivisi per vulnerabilità sfruttate note rispetto alle severità tradizionali
Tempo mediano di remediation (MTTR) per le vulnerabilità sfruttate
Percentuale di richieste di eccezione esaminate congiuntamente da sicurezza e IT
Riduzione delle eccezioni ricorrenti nel tempo

Il valore strategico va oltre. Quando la gestione della remediation delle vulnerabilità tiene conto di ciò che l’IT deve mantenere in funzione, la sicurezza smette di essere percepita come un ostacolo e inizia a operare come abilitatore del business. È questo cambiamento a sbloccare investimenti sostenuti e supporto esecutivo per la gestione dell’esposizione.

Dalla prioritizzazione all’esecuzione: colmare il divario

La prioritizzazione delle vulnerabilità basata sul rischio è stata un’evoluzione necessaria. Ma ha risolto solo metà del problema. Sapere cosa correggere per primo ha un valore limitato se l’atto stesso di correggerlo genera downtime, resistenze o un accumulo crescente di eccezioni non documentate.

La remediation bilanciata a livello operativo colma il divario facendo lavorare sicurezza e IT sulla base dello stesso playbook. Questo si traduce in KPI condivisi, eccezioni chiaramente definite e finestre di manutenzione che proteggono la continuità operativa. Significa anche automatizzare i workflow di remediation in grado di individuare ed evitare potenziali downtime prima che diventino un problema.

Con prioritizzazione, generazione di insight e orchestrazione, la remediation può tenere il passo con l’ambiente invece di restare indietro. E con una piattaforma unificata che collega i dati degli endpoint e della sicurezza, i team non combattono contro i silos: si muovono in modo sincronizzato.

Per un approfondimento su come valutare la maturità attuale della vostra organizzazione e costruire un piano di crescita mirato, consultate il Modello di maturità della gestione dell’esposizione di Ivanti.

Trasforma l’IT con l’IA agentica: l’alba di un servizio accelerato e autonomo

Tue, 19 May 2026 14:49:37 Z

Il settore della gestione dei servizi IT (ITSM) si trova a un vero punto di svolta. Per decenni, i service desk hanno operato secondo un modello fondamentalmente reattivo: i dipendenti riscontrano problemi, aprono ticket e attendono che gli analisti li diagnostichino, li classifichino e li risolvano. L’automazione ha migliorato la produttività all’interno di quel modello, ma non ha mai messo in discussione il modello stesso.

Il punto di svolta: perché l’ITSM non sarà più lo stesso

L’IA agentica cambia completamente le regole del gioco. Invece di limitarsi ad accelerare la velocità con cui le persone elaborano le richieste, i sistemi agentici comprendono l’intento, raccolgono informazioni contestuali, scelgono un percorso d’azione, operano sui diversi strumenti aziendali e confermano i risultati senza attendere che una persona prema “approva” a ogni passaggio. Stiamo assistendo alla transizione dalla gestione dei servizi IT all’autonomia dei servizi IT, con implicazioni profonde per ogni CIO, CISO e leader IT.

I numeri confermano l’urgenza. Gartner prevede che, entro la fine del 2026, circa il 40% delle applicazioni aziendali integrerà agenti IA specifici per attività, rispetto a meno del 5% nel 2025. La ricerca Gartner prevede inoltre che il 70% delle aziende implementerà agenti IA agentici per gestire simultaneamente la propria infrastruttura IT entro il 2029, rispetto a meno del 5% di oggi.

Non si tratta di cambiamenti incrementali. Rappresentano una reinvenzione radicale del modo in cui le organizzazioni tecnologiche erogano, proteggono e ottimizzano i servizi.

Dai bot con script agli agenti autonomi: l’evoluzione dell’intelligenza nell’ITSM

Per capire dove sta andando il settore, è necessario comprendere da dove proviene. L’evoluzione dell’IA nell’ITSM segue un percorso chiaro, che si sposta dalla logica deterministica basata su script verso un ragionamento realmente autonomo.

Fase uno: automazione basata su regole

La prima ondata di automazione ITSM si basava su workflow con script: se un ticket corrispondeva a determinate parole chiave, veniva indirizzato a una coda predefinita; se un asset risultava non conforme, veniva avviato automaticamente uno script di remediation. Queste automazioni offrono guadagni di efficienza misurabili eliminando processi manuali costosi e rendendo le operazioni più conformi e sicure. Tuttavia, rimanevano rigide. Ogni nuova situazione richiedeva una nuova regola e il sistema non era mai in grado di gestire l’ambiguità o di apprendere dai propri risultati.

Fase due: gestione dei servizi assistita dall’IA

L’arrivo del machine learning e dell’IA generativa ha introdotto un livello più adattivo. L’IA ha iniziato a classificare automaticamente i ticket, riepilogare gli incident per gli analisti e generare articoli di knowledge base a partire dai dati storici di risoluzione. Circa il 40% delle organizzazioni ha ormai adottato l’IA per favorire una risoluzione dei ticket più efficiente.

Chatbot e assistenti virtuali hanno portato in azienda interfacce conversazionali di livello consumer, consentendo ai dipendenti di interagire con il supporto IT tramite linguaggio naturale anziché attraverso moduli strutturati. Queste capacità hanno rappresentato un passo avanti significativo, ma l’IA operava ancora principalmente come assistente. L’IA potenziava il processo decisionale umano, anziché sostituirlo.

Fase tre: IA agentica e workflow autonomi

È qui che si trova oggi il settore, sulla soglia di una terza fase, molto più trasformativa. I sistemi di IA agentica non attendono istruzioni. Osservano, ragionano, pianificano e agiscono.

In termini di ITSM, un sistema agentico può rilevare un’anomalia su un endpoint, correlarla a pattern di vulnerabilità noti, avviare una sequenza di ripristino, aggiornare il Configuration Management Database (CMDB) e chiudere il ticket risultante, il tutto prima che il dipendente interessato si accorga del problema. Gartner ha formalizzato questa traiettoria, prevedendo che entro il 2028 almeno il 15% delle decisioni lavorative quotidiane sarà preso autonomamente tramite IA agentica, rispetto allo 0% del 2024, e che il 33% delle applicazioni software aziendali includerà IA agentica entro lo stesso anno.

La distinzione cruciale è l’agentività. Gli strumenti di IA precedenti rispondevano ai prompt. I sistemi agentici perseguono obiettivi. Mantengono memoria tra le interazioni, ragionano sul percorso migliore per raggiungere un risultato ed eseguono workflow in più passaggi su sistemi aziendali integrati. È il salto architetturale che trasforma l’ITSM da una disciplina incentrata sull’elaborazione delle richieste a una disciplina incentrata sull’erogazione di risultati.

L’anatomia dell’ITSM agentico: intelligenza basata su persona e su attività

Con la maturazione dell’IA agentica, la sua applicazione nell’ITSM si sta consolidando attorno a due architetture complementari: agenti basati su persona e agenti basati su attività. Insieme, formano ciò che molti osservatori del settore definiscono la “porta d’ingresso conversazionale” all’IT: un’interfaccia unificata e intelligente che sostituisce portali, moduli e alberi telefonici frammentati con interazioni naturali e adattive.

Agenti basati su persona

Gli agenti basati su persona sono progettati intorno alle esigenze di specifici ruoli utente. Un agente self-service, ad esempio, funge da primo punto di contatto per i dipendenti. Invece di obbligare gli utenti a navigare in un catalogo dei servizi e compilare moduli strutturati, un agente self-service conversazionale utilizza la comprensione adattiva dell’intento e la raccolta guidata dei dati per tradurre una richiesta in linguaggio naturale in un ticket completamente strutturato e attivabile. Il risultato è una drastica riduzione degli attriti per i dipendenti e un significativo miglioramento della qualità dei dati per i team di servizio. L’impatto di questo approccio è considerevole: le organizzazioni che implementano agenti di supporto virtuale basati sull’IA hanno registrato riduzioni del volume delle chiamate dal 50% al 70%, insieme a tassi di adozione da parte dei dipendenti compresi tra l’80% e l’85%.

Agenti per il service desk

Al contrario, un agente per il service desk potenzia l’analista in tempo reale. Fornisce indicazioni consapevoli del contesto durante la gestione dei ticket, accelera triage e classificazione e offre coaching in tempo reale, portando gli analisti meno esperti al livello di competenza dei professionisti più navigati.

La sintesi degli incident guidata dall’IA fa risparmiare agli analisti molto tempo, condensando automaticamente cronologie complesse dei ticket in brief operativi. L’analista rimane nel ciclo, ma il ciclo è più stretto, più rapido e più informato.

Agenti basati su attività

Gli agenti basati su attività gestiscono funzioni operative discrete, come la ricerca di conoscenza, la creazione di incident, l’evasione delle richieste di servizio, la sintesi e le domande e risposte. Questi agenti operano all’interno di un framework agentico che include definizione degli obiettivi, modellazione dell’ambiente, memoria, ragionamento ed esecuzione delle azioni. Gli standard di interoperabilità che stanno emergendo intorno alla comunicazione Agent-to-Agent (A2A) e al Model Context Protocol (MCP) sono particolarmente significativi. Segnalano un settore che si muove verso ecosistemi multi-agente, in cui agenti specializzati collaborano per risolvere problemi complessi e trasversali tra domini: ciò che alcuni analisti definiscono “squadre di agenti”.

La roadmap di Gartner conferma questa traiettoria. Entro il 2027, si prevede che un terzo delle implementazioni di IA agentica combinerà agenti con competenze diverse per gestire attività complesse all’interno di ambienti applicativi e dati. L’implicazione per l’ITSM è chiara: il service desk del futuro non è un singolo sistema monolitico, ma un insieme orchestrato di agenti specializzati, ciascuno dei quali contribuisce con un’intelligenza specifica di dominio a un’esperienza di servizio unificata.

Self-healing, self-securing, self-service: i 3 pilastri dell’IT autonomo

La promessa strategica dell’IA agentica nell’ITSM poggia su tre capacità interconnesse che, considerate insieme, definiscono come si presenta nella pratica un’erogazione dei servizi realmente autonoma.

Self-healing

Il self-healing rappresenta il distacco più evidente dal supporto reattivo tradizionale. Grazie al rilevamento delle anomalie e alla diagnosi automatizzata, le piattaforme moderne possono identificare problemi di endpoint e sicurezza prima che incidano sugli utenti. I bot basati sul cloud e alimentati dall’iperautomazione non si limitano ad avvisare il personale IT dei problemi: risolvono attivamente criticità precedentemente non segnalate o ignorate, accelerando in modo proattivo il rilevamento, risolvendo automaticamente gli incident e liberando l’IT perché possa concentrarsi sull’innovazione. La traiettoria del settore è inequivocabile. Con la maturazione delle capacità di self-healing delle organizzazioni, il volume di ticket gestiti da persone diminuirà costantemente e il ruolo del service desk si sposterà dalla risoluzione alla governance e al miglioramento continuo.

Self-securing

Il self-securing affronta la realtà per cui cybersecurity e operation IT non possono più operare in silos. La visibilità guidata dall’IA su dispositivi, strutture organizzative ed esperienze digitali rafforza la postura di sicurezza identificando proattivamente potenziali vulnerabilità in base ai trend sociali e al punteggio di vulnerabilità.

Mantenere un inventario software costantemente riconciliato aiuta a identificare le esposizioni prima che diventino opportunità di violazione. La convergenza tra ITSM e security operations sta accelerando, poiché l’IA agentica fornisce il tessuto connettivo tra rilevamento delle minacce, gestione delle vulnerabilità e workflow di remediation.

Le organizzazioni che unificano IT e sicurezza attraverso una piattaforma guidata dall’IA sono posizionate per offrire ciò che il settore descrive sempre più spesso come “sicurezza invisibile ma inevitabile”: una protezione che opera in modo continuo senza creare attriti per gli utenti finali.

Il self-service viene ripensato dalle fondamenta. I portali self-service tradizionali soffrivano di scarsa adozione perché imponevano all’utente la logica del sistema, invece di adattarsi al suo intento. L’IA conversazionale inverte questa dinamica.

I dipendenti interagiscono tramite linguaggio naturale e il sistema gestisce dietro le quinte la complessità di routing, classificazione ed evasione. Gli assistenti virtuali basati sull’IA offrono esperienze eccellenti aumentando produttività e soddisfazione, portando nel luogo di lavoro la semplicità degli assistenti virtuali consumer e al tempo stesso massimizzando l’adozione e riducendo i volumi di chiamate. Guardando al futuro, il self-service evolverà ulteriormente man mano che l’automazione vocale, le interfacce mobile-first e le notifiche proattive creeranno un’esperienza di supporto omnicanale che raggiunge i dipendenti ovunque lavorino: alla scrivania, in reparto produttivo o in movimento.

Le implicazioni strategiche: cosa significa per la leadership IT

L’ascesa dell’IA agentica nell’ITSM comporta implicazioni che vanno ben oltre il service desk. Per CIO e leader IT, diversi temi strategici richiedono attenzione.

Il passaggio da centro di costo a centro di valore

Quando gli incident di routine si risolvono da soli e l’IA gestisce il triage di primo livello, il service desk non è più definito dal volume di ticket e dal tempo medio di gestione. Al contrario, i team IT sono liberi di concentrarsi su iniziative strategiche: trasformazione digitale, innovazione dell’esperienza dei dipendenti e automazione dei processi aziendali. La domanda per i leader IT non è più “Come gestiamo più ticket più rapidamente?”, ma “Come riallochiamo la capacità che il servizio autonomo crea?”

L’imperativo di governance e fiducia

La stessa ricerca Gartner che prevede una crescita esplosiva dell’IA agentica lancia anche un avvertimento: oltre il 40% dei progetti di IA agentica potrebbe essere annullato entro la fine del 2027 se costi, chiarezza del valore o controlli del rischio si rivelassero inadeguati. Le implementazioni di successo richiederanno compliance integrata, regole di visibilità e aderenza alle policy fin dal primo giorno. La governance dell’IA non è un problema da aggiungere in seguito: è un requisito di progettazione fondamentale. Le organizzazioni che integrano guardrail, workflow di approvazione e verificabilità nelle proprie architetture agentiche realizzeranno valore sostenibile; quelle che considerano la governance un aspetto secondario andranno incontro a costosi passi indietro.

La convergenza tra operation IT e sicurezza

I silos di dati tra i team IT e sicurezza hanno indebolito a lungo la resilienza organizzativa. Le piattaforme di IA agentica che unificano gestione dei servizi, gestione degli endpoint ed exposure management creano un sistema di riferimento, abilitando una risposta coordinata e intelligente in domini tradizionalmente separati. Questa convergenza non è solo una questione tecnologica: richiede allineamento organizzativo, metriche condivise e un impegno culturale ad abbattere le barriere funzionali.

L’esperienza dei dipendenti come vantaggio competitivo

La capacità di misurare e quantificare l’esperienza digitale dei dipendenti, su dispositivi, gestione dei servizi, sicurezza e applicazioni, tramite analisi del sentiment guidata dall’IA trasforma l’esperienza dei dipendenti da aspirazione astratta a disciplina basata sui dati. Le organizzazioni che offrono esperienze IT fluide e di livello consumer attireranno e tratterranno i talenti in modo più efficace rispetto a quelle che considerano il supporto IT una funzione di back-office. Il punteggio Digital Employee Experience (DEX) sta emergendo come KPI critico, offrendo agli analisti del service desk la visibilità necessaria per fornire supporto personalizzato ed empatico su larga scala.

Enterprise service management oltre l’IT

Forse l’implicazione più sottovalutata dell’IA agentica è il suo potenziale di estendere l’erogazione intelligente dei servizi oltre l’IT, verso HR, facility, finance e altri dipartimenti aziendali. Quando la piattaforma sottostante supporta no-code, progettazione dei workflow e integrazioni preconfigurate con sistemi esterni, i modelli comprovati nella gestione dei servizi IT diventano template per una trasformazione a livello enterprise. I dipartimenti aziendali che dipendono ancora da e-mail ad hoc, fogli di calcolo datati o documenti cartacei possono trarre enormi benefici dalle stesse capacità agentiche che stanno rimodellando l’IT.

L’imperativo del servizio autonomo

La trasformazione della gestione dei servizi IT attraverso l’IA agentica non è una possibilità lontana: è una realtà attiva e in accelerazione. Le organizzazioni che prospereranno saranno quelle che riconosceranno questo cambiamento per ciò che è: non solo un aggiornamento tecnologico, ma una reinvenzione fondamentale del modo in cui i servizi vengono progettati, erogati e vissuti in tutta l’azienda.

Il ruolo umano cambierà, non scomparirà. L’IA agentica non eliminerà i professionisti IT: li valorizzerà. Gli analisti passeranno da elaboratori di ticket a supervisori dell’IA, architetti della governance e designer dell’esperienza. I professionisti IT più preziosi del prossimo decennio saranno quelli capaci di progettare, addestrare e governare sistemi autonomi, anziché gestirli manualmente.

Il percorso da seguire richiede una strategia lucida. Iniziate dalle basi dell’automazione: workflow intelligenti, classificazione assistita dall’IA e interfacce self-service che riducono gli attriti e migliorano la qualità dei dati. Evolvete verso capacità autonome: endpoint self-healing, ambienti self-securing e agenti conversazionali che risolvono i problemi end-to-end. E investite nella governance, nella cultura e nello sviluppo dei talenti che sosterranno operation autonome su scala enterprise.

La domanda per i leader IT non è più se l’IA agentica rimodellerà la gestione dei servizi. La domanda è quanto rapidamente e con quanta strategia la vostra organizzazione riuscirà a renderla operativa. L’era del servizio autonomo è iniziata e il vantaggio competitivo appartiene a chi si muove con decisione, non a chi attende una certezza che non arriverà mai.

La scomoda verità sulla gestione dei dati per l'IA (e cosa fare al riguardo)

Tue, 12 May 2026 16:23:42 Z

I dati non saranno mai del tutto puliti. È solo una questione di grado.

L'ho capito fin dal primo giorno del mio master in data science, quando un professore ci avvertì che circa l'80% del nostro tempo sarebbe stato dedicato alla pre-elaborazione e alla pulizia dei dati, non alla creazione di modelli.

Anni dopo, nel mio ruolo di Principal Product Manager per IA, ML e analytics in Ivanti, ho constatato che quel principio si conferma sorprendentemente valido nella pratica.

Mentre io e il mio team lavoriamo per portare l'IA fuori dal laboratorio e in produzione per i team IT e di sicurezza, la gestione dei dati per l'IA è più importante che mai. Il Technology at Work Report 2025 di Ivanti ha rilevato che il 42% degli impiegati utilizza strumenti di IA generativa al lavoro, con un aumento di 16 punti percentuali in un solo anno. Tra i professionisti IT, l'adozione ha raggiunto il 74%.

L'interesse c'è. Così come le esitazioni. Molti responsabili IT sanno che i loro dati non sono puliti, i sistemi sono frammentati e la governance non è ancora al passo. La buona notizia: non servono dati perfetti per adottare l'IA.

Serve una strategia chiara di gestione dei dati per l'IA, costruita attorno a ciò che già si possiede.

Perché i dati IT non sono mai perfetti

Nell'IT aziendale, i problemi di qualità dei dati non sono anomalie. Sono la realtà di base dell'IA e della gestione dei dati. I ticket vengono categorizzati in modo incoerente. Gli inventari degli asset sono incompleti. Le informazioni critiche restano isolate in silos tra i sistemi. E il testo non strutturato nei ticket di supporto e nelle risposte ai sondaggi sfugge a una categorizzazione ordinata.

Le ricerche Ivanti confermano la portata del fenomeno. Il nostro Autonomous Endpoint Management Advantage Report 2026 ha rilevato che l'89% dei professionisti IT afferma che i dati in silos incidono negativamente sulle operazioni, mentre il 39% sostiene che i silos causano un utilizzo inefficiente delle risorse.

Il nostro Tech at Work Report racconta una storia simile:

Il 38% dei professionisti IT indica la complessità tecnologica come una barriera significativa all'efficacia operativa, con un aumento di quattro punti percentuali anno su anno.
Quasi la metà (46%) afferma che le nuove implementazioni software finiscono in realtà per aumentare il volume dei ticket, invece di ridurre il rumore di fondo.

Se si aggiunge che il 48% delle organizzazioni utilizza ancora software a fine vita, il quadro diventa chiaro: questo è un ambiente dati disordinato per sua stessa natura.

Come mi ha detto David Pickering, Product Marketing Director di Ivanti: quando i dati sono formattati in modo diverso tra i sistemi, inseriti in modo incoerente, isolati per reparto e modellati da anni di acquisizioni, i workflow di IA agentica che attraversano questi sistemi incontrano rapidamente difficoltà. Non si può indicare a un'IA di quali dati fidarsi se non lo si sa in prima persona. E senza queste basi, anche automazioni ben progettate finiranno per cedere nei punti di giunzione.

In altre parole: il principio "garbage in, garbage out" è ancora valido. Ma dati immacolati non arriveranno a breve. Qualsiasi approccio serio alla gestione dei dati master e al machine learning deve tenere conto del disordine, non aspettare che si risolva da sé.

Il framework decisionale: scegliere la strategia di gestione dei dati

Esistono due percorsi principali per la gestione dei dati per l'IA nell'IT. Entrambi sono validi, entrambi comportano compromessi e molte organizzazioni li useranno entrambi per casi d'uso diversi.

Percorso 1: pulizia manuale/programmatica

Quando il mio team ha introdotto la classificazione dei ticket per il sistema ITSM di Ivanti, stavamo addestrando un modello per categorizzare le richieste di servizio. Questo richiedeva dati di training puliti e ben etichettati. Abbiamo quindi inserito nel workflow un passaggio che offriva agli amministratori la possibilità di rivedere e pulire i dati prima che alimentassero il modello. Quella revisione umana ha prodotto una differenza misurabile in termini di accuratezza.

Questo percorso funziona al meglio quando si addestra o si perfeziona un modello personalizzato, si importano dati in una knowledge base o si lavora con dataset strutturati per i quali è possibile definire standard di qualità. Il compromesso riguarda tempo e risorse. Il risultato è un'elevata accuratezza e il pieno controllo.

Funziona meglio anche quando l'igiene di base dei dati è già presente. Molte organizzazioni non sono ancora a quel punto: solo il 35% monitora l'età dei dispositivi o la posizione, e solo il 37% monitora lo stato delle patch.

Percorso 2: elaborazione con IA generativa

A volte la pulizia manuale non è praticabile. L'ho imparato lavorando sull'analisi dei sondaggi di Ivanti. Le risposte ai sondaggi sono tra i dati più disordinati che un team IT possa incontrare: testo libero, formattazione incoerente, livello di dettaglio estremamente variabile. Pulirli manualmente su larga scala non è realistico.

Abbiamo invece utilizzato modelli linguistici di grandi dimensioni per identificare temi, pattern e sentiment in input incompleti e non strutturati. Potevamo sintetizzare interi sondaggi, evidenziare i driver di soddisfazione e far emergere rapidamente insight utili.

Questo percorso è ideale per dati non strutturati ad alto volume, per situazioni in cui la pulizia manuale semplicemente non è possibile o per qualsiasi scenario in cui il costo della pulizia supera il valore dell'output. Richiede però l'accesso a modelli linguistici di grandi dimensioni adeguati e la verifica che il caso d'uso sia adatto.

Scegliere tra le due strategie

La decisione dipende da volume e varietà dei dati, vincoli di tempo, requisiti di accuratezza e dal livello di controllo necessario su dove vanno i dati e su come vengono elaborati.

Serve perfezionare un modello in cui la precisione è critica? Investite nella pulizia. Lavorate con grandi volumi di input non strutturati, dove la velocità è determinante? Puntate sull'IA generativa. L'obiettivo è una scelta deliberata, non l'inazione perché i dati non sono perfetti.

Costruire un'infrastruttura pronta per l'IA per la gestione dei dati

I servizi cloud sono essenziali in questo contesto, e non lo dico alla leggera. Quando il mio team ha creato un punteggio di esperienza digitale per misurare, quantificare e migliorare la digital employee experience, il cloud è stato l'abilitatore critico. Ha svolto il ruolo di hub di integrazione, riunendo ticket di servizio, telemetria dei dispositivi, performance delle applicazioni e segnali di sicurezza.

Questo livello di integrazione multi-sorgente non è realizzabile su larga scala senza un'infrastruttura cloud. Il cloud ci ha inoltre consentito di eseguire un modello di IA ibrido che elabora simultaneamente testo e telemetria numerica. Supportare migliaia di dispositivi e utenti a quel livello di complessità non è fattibile on-premise.

Oltre alla capacità di calcolo, un'infrastruttura pronta per l'IA significa affrontare la gestione dei dati master per il machine learning. Le organizzazioni hanno bisogno di un'unica fonte di verità tra i sistemi. I formati dei dati devono essere standardizzati, in particolare quando la crescita tramite acquisizioni introduce piattaforme legacy con convenzioni diverse.

La governance dei dati complica ulteriormente il quadro. Regolamenti come GDPR e CCPA impongono requisiti rigorosi su come vengono trattati i dati personali e su dove possono essere trasmessi. Per le organizzazioni globali, questo significa che le pipeline di IA devono tenere conto delle differenze giurisdizionali regionali, soprattutto quando si valuta se utilizzare servizi di IA esterni o mantenere l'elaborazione internamente.

La nostra ricerca sull'Autonomous Endpoint Management ha rilevato che solo il 32% dei professionisti IT utilizza un sistema di unified endpoint management. Senza una visibilità consolidata, l'IA e l'automazione non possono esprimere il loro potenziale. Una gestione efficace dei dati per l'IA inizia dalla visibilità: non si può automatizzare ciò che non si vede.

Best practice per i team IT che implementano l'IA

Quando si parla di gestione dei dati per l'IA, adottare strumenti senza sviluppare i processi necessari a supportarli è uno degli errori più comuni che riscontro.

Definire pratiche di Knowledge Management

La piattaforma ITSM di Ivanti utilizza l'IA per generare articoli della knowledge base a partire da ticket passati e risoluzioni degli incidenti. Il guadagno di produttività è reale. Ma non elimina la necessità di disciplina gestionale.

Gli articoli richiedono comunque cicli di revisione e approvazione, controllo delle versioni e una chiara titolarità.

Sebbene l'86% dei professionisti IT concordi sul fatto che l'IA sia importante per l'efficienza operativa, meno della metà la utilizza per scenari ad alto valore come la manutenzione predittiva o la risposta automatizzata agli incidenti. Il divario nell'IA e nella gestione dei dati non è tecnologico. È una questione di maturità dei processi.

Validazione e governance

La validazione è importante sul lato dell'output quanto la qualità dei dati lo è sul lato dell'input. I risultati generati dall'IA devono essere verificati, soprattutto mentre le organizzazioni si orientano verso l'IA agentica, in cui sistemi autonomi agiscono in base alle decisioni in tempo reale. La domanda non è solo se i dati restituiti sembrano corretti. È se il sistema sta intraprendendo le azioni giuste.

Anche misurare le performance dell'IA è importante: quanto spesso viene utilizzata, quanto è accurata e dove fallisce. Lo State of Cybersecurity Report 2026 di Ivanti ha rilevato che il 92% dei professionisti della sicurezza afferma che l'automazione riduce efficacemente il tempo medio di risposta. Questa efficacia, tuttavia, dipende da monitoraggio e ottimizzazione continui.

Usare l'IA come catalizzatore per migliori pratiche sui dati

L'IA non si limita a consumare buone pratiche sui dati. Le promuove. Abbassando le barriere alla creazione e all'analisi dei contenuti, l'IA libera i team per costruire i framework di governance che avevano rimandato. Quando generare un articolo della knowledge base richiede minuti invece che ore, il team può investire quel tempo in workflow di approvazione e controllo qualità.

Questo è particolarmente utile quando i tecnici junior ricevono indicazioni dall'IA in tempo reale, potendo contribuire a un livello più elevato mentre il personale senior si concentra sulla strategia.

Il nostro Autonomous Endpoint Management Advantage Report ha rilevato che il 62% dei professionisti IT si sente sopraffatto dalle attività quotidiane e che uno su quattro afferma che un collega si è dimesso a causa del burnout. Un'IA che potenzia le competenze umane aiuta i team a scalare senza pagare quel prezzo.

Il percorso non è sempre chiaro, ma la strategia può esserlo

I dati perfetti sono un mito. Questo non dovrebbe fermarvi.

Pulizia manuale per casi d'uso strutturati e ad alta precisione. IA generativa per scenari non strutturati e ad alto volume. Entrambi richiedono investimenti mirati in infrastruttura cloud, governance e sviluppo dei processi.

Man mano che i modelli di IA continueranno a evolversi, incorporando non solo il riconoscimento statistico dei pattern ma anche regole esplicite e ragionamento strutturato, la barriera alla gestione dei dati pronta per l'IA continuerà ad abbassarsi. Le organizzazioni che si muovono ora, consapevoli delle imperfezioni dei propri dati e dotate di una strategia per gestirle, otterranno il massimo valore.

Da gestore di ticket a team leader: gestire una forza lavoro IT agentica

Thu, 30 Apr 2026 13:00:02 Z

La promessa dell’IA nella gestione dei servizi IT circola da anni. Chatbot che deviano i ticket. Agenti virtuali che rispondono alle domande frequenti. Automazione che indirizza le richieste. Sono strumenti utili, ma probabilmente non la visione ideale che vi era stata prospettata all’inizio.

A fare la differenza oggi è l’arrivo dell’IA agentica: sistemi che non si limitano a rispondere alle istruzioni, ma ragionano, agiscono e si adattano in workflow articolati in più passaggi, con conseguenze reali. Per i leader IT, la domanda non è più se adottare l’ITSM agentico. È come governarlo abbastanza bene da operare alla velocità richiesta.

Gli agenti IA non stanno per arrivare nel vostro service desk: sono già lì. Ivanti Neurons for ITSM è al centro di questo cambiamento, integrando gli agenti IA direttamente nella gestione degli incidenti, nelle richieste di servizio e nella gestione della conoscenza.

Il service desk agentico in azione

Una forza lavoro ITSM agentica non è un chatbot con qualche passaggio in più. In Ivanti Neurons, gli agenti IA sono progettati per specifiche figure ITSM: valutano e classificano gli incidenti nel momento in cui arrivano, eseguono workflow di change approvati end-to-end, interrogano e riconciliano il CMDB senza intervento degli analisti e propongono articoli della knowledge base che risolvono davvero i problemi, non si limitano a segnalarli.

Questi agenti operano in tutto lo stack tecnologico esistente. Gli agenti di IA agentica dovrebbero lavorare lungo l’intero stack tecnologico, non in modo isolato. La nostra visione è avere agenti in ambito ITSM, gestione degli endpoint, gestione delle patch e sicurezza, per abilitare l’azienda autonoma.

Ecco come i leader IT più lungimiranti governano, scalano e ottengono risultati concreti con una forza lavoro ITSM agentica.

Risultati concreti, non progetti pilota

Le organizzazioni che hanno superato la fase di sperimentazione con Ivanti Neurons for ITSM stanno registrando ritorni crescenti man mano che gli agenti IA maturano in produzione. Secondo la ricerca AITSM di Ivanti:l’86% dei professionisti IT afferma che la tecnologia basata sull’IA è fondamentale per rendere le organizzazioni IT più efficienti e l’85% ritiene che le soluzioni di IA e automazione, come l’analisi delle cause principali e la manutenzione predittiva, possano contribuire a ridurre il volume dei ticket IT.

Questi risultati confermano la portata dell’opportunità. In particolare, il 58% delle organizzazioni utilizza già l’IA per la reimpostazione delle password e il 52% per l’onboarding dei dipendenti: attività di routine che assorbono ore degli analisti e offrono scarso valore strategico.

Gli analisti stimano che il costo medio per risolvere un ticket IT sia compreso tra 15 e 17 dollari, con costi molte volte superiori per le richieste inoltrate a livelli superiori. Gli agenti IA che gestiscono la fascia ad alto volume e bassa complessità di quella coda non riducono solo i costi. Liberano le persone migliori per il lavoro che fa davvero avanzare il business.
— Ivanti AI: The Future of ITSM Automation Report.

Questa trasformazione è già in corso nei settori in cui Ivanti Neurons for ITSM è implementato:

Sanità: Provisioning dei dispositivi e richieste di accesso agli EHR risolti autonomamente in ambienti multi-sito, riducendo ritardi che in precedenza prolungavano le finestre di servizio.
Servizi finanziari: Il rischio di change valutato dall’IA evidenzia i segnali critici per il CAB, riducendo i tempi di revisione e mantenendo audit trail completi senza interventi manuali.
Produzione: I segnali sullo stato degli endpoint vengono correlati automaticamente agli incidenti aperti, riducendo l’MTTR negli ambienti OT e IT convergenti.

La governance non è solo un limite di sicurezza: è il motore

Le organizzazioni ITSM agentiche con le migliori prestazioni condividono una caratteristica: trattano la governance degli agenti IA con lo stesso rigore del change management. Gli agenti ben governati non si limitano a eseguire: migliorano. Gli agenti privi di governance degradano silenziosamente, deviando man mano che evolvono i modelli dei ticket; gli articoli della knowledge base diventano obsoleti e il cambiamento organizzativo supera le ipotesi del modello.

Com’è, in pratica, una buona governance degli agenti ITSM?

Confini di autonomia definiti. I team IT devono configurare con precisione quali passaggi del workflow sono completamente autonomi, quali richiedono conferma umana e quali devono sempre essere oggetto di escalation.
Miglioramento continuo attraverso cicli di feedback in ogni punto di contatto. Gli agenti apprendono dalle correzioni degli analisti, dai punteggi di soddisfazione degli utenti finali e dagli esiti delle risoluzioni. Questi segnali emergono in forma aggregata, così il vostro team non si limita a chiudere ticket: migliora anche i propri processi.
Audit trail per ogni azione degli agenti. Ogni decisione di un agente IA dovrebbe essere registrata con il contesto completo: che cosa l’ha attivata, quali dati ha utilizzato, quale azione ha eseguito. La compliance è integrata, non aggiunta a posteriori.
Escalation che funziona davvero. Gli agenti conoscono i propri limiti. Quando il livello di confidenza scende al di sotto di una soglia configurabile, la tecnologia IA deve indirizzare senza interruzioni la richiesta alla persona giusta, allegando tutto il contesto, in modo che l’analista non debba ripartire da zero.
Informazioni affidabili. Gli agenti IA devono utilizzare dati di cui vi fidate, anziché affidarsi a fonti esterne sconosciute o ad allucinazioni. Mantenere il controllo sulle fonti dei dati è essenziale per garantire informazioni affidabili.

Le nuove competenze richieste alla leadership IT

Il passaggio a una forza lavoro ITSM agentica cambia il significato di essere un manager IT efficace. La competenza centrale non è più il throughput dei ticket o la conformità ai processi, ma la capacità di orchestrare un team ibrido di persone e agenti, valutare le prestazioni degli agenti con lo stesso sguardo critico che si applicherebbe a un collaboratore diretto e ottimizzare continuamente il sistema in base alle esigenze in evoluzione del business.

Il Technology at Work Report 2025 di Ivanti e il DEX Report 2025 mettono in evidenza questa sfida:

Il 46% dei professionisti IT segnala un aumento del volume dei ticket dovuto a nuove implementazioni software.
Il 34% degli help desk indica le attività ripetitive e dispendiose in termini di tempo e i lunghi tempi di risoluzione come principali criticità.

Sono esattamente queste le pressioni che l’IA agentica è progettata per assorbire, ma solo se i leader sviluppano la capacità gestionale necessaria per guidarla.

I leader IT che utilizzano l’IA agentica con l’ITSM dovrebbero prendere in considerazione la creazione di ritmi settimanali per la revisione delle prestazioni degli agenti, nello stesso modo in cui potrebbero esaminare i KPI degli analisti, ponendo domande come:

Quali agenti stanno ottenendo prestazioni inferiori alle attese e perché?
Quali workflow sono pronti per estendere l’autonomia dell’IA?
Quali schemi di escalation suggeriscono una lacuna di conoscenza nel modello?

Le organizzazioni all’avanguardia nell’IA agentica devono andare oltre la valutazione isolata di analisti e agenti IA. Misurare davvero le prestazioni significa valutarli insieme, come un unico team integrato di persone e IA che lavora verso un obiettivo condiviso.

L’adozione lenta è debito tecnico

Nell’IT c’è la tendenza a considerare l’adozione dell’IA come qualcosa da perfezionare prima di scalare. L’istinto è comprensibile, perché l’ITSM tocca ogni parte dell’organizzazione e gli errori sono visibili. Ma il calcolo del rischio si è ribaltato. Nel 2026, il costo di procedere lentamente non è un rischio evitato. È la distanza accumulata rispetto alle organizzazioni che aumentano il proprio vantaggio agentico trimestre dopo trimestre.

La ricerca di Ivanti individua le vere barriere: il 42% dei professionisti IT cita le preoccupazioni relative a sicurezza e compliance come la principale sfida per l’automazione IT. Inoltre, il 44% delle organizzazioni ha investito nell’IA, ma afferma che i dipendenti non dispongono di competenze o formazione adeguate per utilizzare questi strumenti in modo efficace. Sono problemi risolvibili, ma solo quando la leadership si assume il compito di affrontarli.

La barriera all’ITSM agentico è raramente tecnica: è organizzativa. Una responsabilità poco chiara sui risultati dell’IA, incentivi non allineati e la resistenza culturale degli analisti che temono la sostituzione invece dell’augmentation ostacolano l’adozione dell’IA su larga scala.

Vale la pena notare che il 74% dei professionisti IT utilizza già strumenti di IA generativa nel 2025, rispetto al 66% dell’anno precedente. La forza lavoro si sta muovendo. La domanda è se l’organizzazione si stia muovendo con essa o stia creando attriti che spingono questa adozione verso canali non governati.

I principi che guidano la vera trasformazione

Le organizzazioni che puntano a costruire operazioni IT realmente agentiche condividono una filosofia operativa comune:

Partite dai risultati, non dai casi d’uso. Individuate una metrica strategica — conformità agli SLA, MTTR, rapporto analisti-ticket — e procedete a ritroso fino ai workflow agentici in grado di migliorarla.
Trattate gli agenti IA come membri del team con piani di onboarding. I nuovi agenti vengono supervisionati, guidati con feedback e dotati di autonomia crescente quando le prestazioni lo giustificano: non vengono rilasciati in produzione e dimenticati.
Misurate le prestazioni degli agenti come quelle delle persone. Tasso di risoluzione, tasso di escalation, soddisfazione degli utenti finali e contributo alla conoscenza vengono monitorati per ogni workflow degli agenti, non solo a livello aggregato di service desk.
Investite nelle capacità umane insieme a quelle dell’IA. Il service desk migliora, e con esso anche le persone che ne fanno parte. I migliori analisti non vengono sostituiti: vengono riqualificati come coach dell’IA, architetti di workflow e gestori delle eccezioni.
Costruite la governance prima che sia necessaria. Configurate soglie di autonomia, logiche di escalation e policy di audit nella prima implementazione, non dopo il primo incidente.
Trattate agenti IA e analisti come un unico team. Trattate gli agenti IA e gli analisti umani come un unico team: pianificando, eseguendo e valutando insieme. Guidate questo team combinato attraverso il framework di sviluppo del team Forming, Storming, Norming e Performing per costruire la fiducia e la coesione che generano risultati concreti.

L’era del service desk passivo sta finendo. Basta attendere un ticket, lavorare su una coda e misurare il successo in base al tasso di chiusura. Le organizzazioni che definiranno il prossimo decennio delle operazioni IT stanno costruendo attività di service management proattive che percepiscono, ragionano e agiscono: dove gli agenti IA gestiscono il volume e le persone migliori si occupano del futuro.

Ivanti Neurons for ITSM è progettato per quel service desk. La domanda è se la vostra organizzazione è pronta a guidarlo.

Pronti a costruire la vostra forza lavoro IT agentica?

Scopri come Ivanti Neurons for ITSM integra gli agenti IA nei workflow del service desk esistenti, fin dal primo giorno. Scopri di più.

Siamo nell’apocalisse delle patch. Ecco perché queste tre scuse IT non funzioneranno più.

Wed, 29 Apr 2026 14:00:07 Z

Il 7 aprile, Anthropic ha annunciato che il suo modello Claude Mythos Preview aveva identificato autonomamente migliaia di vulnerabilità zero-day ad alta gravità e critiche in tutti i principali sistemi operativi e browser web. Oltre il 99% non era stato corretto con patch il giorno della divulgazione.

Due settimane dopo, il 21 aprile, Mozilla ha dichiarato di aver utilizzato lo stesso modello per individuare e correggere con patch 271 vulnerabilità nell’ultima release di Firefox. La valutazione di Mozilla: “Finora non abbiamo trovato alcuna categoria o complessità di vulnerabilità che gli esseri umani possano individuare e che questo modello non sia in grado di trovare”.

271 è solo la prima ondata. Chrome, Edge, Windows, macOS, Linux, FreeBSD: la falla di esecuzione di codice da remoto vecchia di 17 anni in FreeBSD divulgata dal red team di Anthropic (CVE-2026-4747) è un primo esempio di ciò che sta arrivando. Ogni vendor nell’ambito del Project Glasswing di Anthropic è nella posizione di rilasciare correzioni a un ritmo mai visto prima nel settore. Tutte queste correzioni diventano CVE pubbliche con patch disponibili, e finiscono tutte nello stesso posto: il tuo ambiente.

Anche la storia del contenimento presenta una crepa. Il 21 aprile, Bloomberg ha riferito che un gruppo collegato a Discord ha ottenuto accesso non autorizzato a Mythos tramite l’ambiente di un vendor di terze parti. Anthropic afferma che l’attività non si è estesa oltre quel vendor. Indipendentemente dal fatto che capacità simili siano già o meno nelle mani degli attaccanti, il margine di manovra difensivo è più breve di quanto lasciasse intendere l’annuncio del 7 aprile.

Mythos è arrivato in un mondo che stava già andando in questa direzione. Il Global Threat Report 2026 di CrowdStrike ha documentato nel 2025 un aumento dell’89% su base annua degli attacchi abilitati dall’AI. Questa tendenza era precedente a Mythos.

Chiamiamola apocalisse delle patch. Quella operativa, concreta: il volume e la cadenza delle CVE pubbliche con patch disponibili stanno per superare il modo in cui oggi lavora la maggior parte dei team IT e di sicurezza.

Il NIST sta già subendo gli effetti dell’apocalisse delle patch. Ad aprile, l’agenzia ha annunciato un importante cambiamento nelle operazioni del National Vulnerability Database (NVD) in risposta a un aumento del 263% delle segnalazioni. Il NIST non fornirà più un arricchimento dettagliato per tutte le vulnerabilità inviate e lo farà invece solo per quelle che soddisfano criteri di rischio elevato, come le vulnerabilità presenti nel catalogo CISA Known Exploited Vulnerabilities o quelle che interessano software governativo critico. Il NIST farà affidamento sulle CVE Numbering Authorities (CNA), come Ivanti, anziché condurre una propria valutazione indipendente.

Dall’annuncio, ho sentito tre versioni della stessa risposta da clienti e colleghi. Tutte e tre sono varianti di un programma pensato per un mondo più lento.

“Abbiamo uno scanner di vulnerabilità”

Qualys, Rapid7 e Tenable svolgono bene l’attività di discovery delle vulnerabilità. Gli scanner individuano, segnalano, assegnano punteggi ed elencano. Distribuzione, verifica, gestione dei riavvii e rollback sono fuori dal loro ambito. Quel lavoro deve comunque essere svolto da qualche parte. Nella maggior parte dei programmi avviene in uno strumento separato, con un team separato, seguendo una cadenza separata.

Con la finestra di exploit ormai misurata in ore e la coda di Glasswing destinata quasi a raddoppiare il backlog, uno scanner che produce 587 vulnerabilità critiche e passa l’elenco a un team umano diventa una responsabilità. La scelta pratica è collegare lo scanner che già possiedi a un motore di remediation in grado di agire automaticamente sui risultati. Una piattaforma di gestione autonoma degli endpoint (AEM), con distribuzione ad anelli e rollback, e intelligence sulle vulnerabilità per fornire un contesto basato sul rischio a supporto di decisioni di remediation efficienti, così l’elenco si riduce senza che siano gli esseri umani a prendere ogni decisione.

“Gestiamo le approvazioni tramite il nostro sistema di ticketing”

A proposito di esseri umani che devono prendere decisioni… I lunghi processi di approvazione lineari rallenteranno in modo significativo la remediation. Quand’è stata l’ultima volta che hai dovuto decidere se distribuire l’ultimo aggiornamento del sistema operativo o del browser?

Le organizzazioni sanno già che distribuiranno questi aggiornamenti. Spesso il processo di approvazione è dovuto a complesse dinamiche interne e a un disallineamento sugli obiettivi di sicurezza. Il risultato? Un processo molto lineare che richiede lo scanner di vulnerabilità citato in precedenza, un analista che approvi ciò che sai già debba essere fatto, ticket inviati ai responsabili di business per l’approvazione e lasciati nelle caselle di posta in attesa, e in definitiva tempo prezioso sprecato per una decisione che era sostanzialmente già chiara e non doveva essere presa.

Il passaggio del mercato all’Exposure Management affronta questo processo in modo molto diverso, concentrandosi sulla definizione della propensione al rischio di un’organizzazione e sul monitoraggio della postura di rischio. La prossima volta che verrà rilasciato un aggiornamento del sistema operativo Windows, saprai già che lo distribuirai, con quale pianificazione lo farai e con quali SLA e metriche di conformità misurerai il successo. Quello che vuoi davvero sapere è:

1. Devo muovermi più rapidamente perché l’aggiornamento include vulnerabilità note sfruttate attivamente?

Oppure

2. L’aggiornamento sta impattando le operazioni e dobbiamo rallentare (per fortuna la piattaforma di Autonomous Endpoint Management include la distribuzione ad anelli con rollback)?

“Abbiamo Intune”

Microsoft Intune presenta due limiti di ambito che qui contano.

In primo luogo, gestisce solo i dispositivi registrati. Gli endpoint non registrati e non gestiti — server, laptop di collaboratori esterni, shadow IT, dispositivi edge trascurati — restano completamente fuori dalla sua visibilità. Nei periodi di aumento del volume di vulnerabilità, questi punti ciechi si moltiplicano più rapidamente di quanto i team possano gestire manualmente.

In secondo luogo, sebbene Intune semplifichi la distribuzione e gli aggiornamenti delle applicazioni, la copertura delle applicazioni di terze parti e la profondità della prioritizzazione sono più limitate di quanto la maggior parte degli amministratori immagini. Intune può dirti cosa non è aggiornato, ma non cosa aumenta davvero la tua esposizione––costringendo i team ad applicare patch a tutto in modo reattivo, oppure basandosi su ipotesi quando il tempo è poco.

La maggior parte degli ambienti enterprise non è esclusivamente Windows, completamente registrata o basata su uno stack applicativo ridotto e omogeneo. Quando le divulgazioni di vulnerabilità aumentano improvvisamente, instradare il patching lascia lacune e si trasforma in un rischio sistemico.

Mantieni Intune. Affiancalo a un livello di discovery e remediation che trovi gli asset che Intune non riesce a vedere, dia priorità alle vulnerabilità più importanti e applichi le patch con fiducia nelle applicazioni che Intune non copre.

Cosa fare

L’automazione è il modello operativo. Deve essere integrata nel workflow.

I professionisti conoscono questo principio da tempo. Si manifesta in tre aree:

Triage continuo. Le vulnerabilità note sfruttate attivamente possono seguire un percorso di risposta zero-day, soprattutto nelle aree meno sicure dell’organizzazione, come i sistemi degli utenti finali. Inoltre, definisci applicazioni specifiche, come browser e app di telecomunicazione, da aggiornare su un percorso prioritario controllato settimanalmente o anche quotidianamente. Tutto il resto può attendere la finestra di manutenzione ordinaria.
Distribuzione ad anelli con rollback automatizzato. Anello di test, anello early adopter, produzione estesa, sistemi mission-critical. La sequenza è poco entusiasmante, ma funziona per la maggior parte delle attività di manutenzione. Ciò che è cambiato è che alcuni aggiornamenti dovranno essere compressi per rientrare nella finestra di exploit, anziché attendere la manutenzione mensile. L’anello di test deve essere automatizzato e strumentato: una checklist umana non può muoversi a quella velocità.
Verifica a ciclo chiuso. La patch non è distribuita finché non viene verificata l’installazione sull’endpoint, e la CVE non viene chiusa finché una nuova scansione non lo conferma. La maggior parte dei team salta questo passaggio, ed è per questo che la prova di conformità diventa un’emergenza la settimana prima dell’audit. È per questo che questa settimana abbiamo rilasciato la conformità continua nella nostra piattaforma: così le evidenze di conformità vengono prodotte in modo continuo e automatico man mano che le patch vengono distribuite, mentre l’automazione gestisce le decisioni di prioritizzazione per cui la maggior parte dei team non ha capacità disponibile.

Le 271 vulnerabilità di Firefox individuate da Mozilla sono un’anticipazione. Ogni principale vendor software sotto Glasswing sta per iniziare a correggere più vulnerabilità e a un ritmo accelerato, e gli attaccanti con la stessa classe di capacità cercheranno esattamente quelle aperture ogni volta che avranno accesso a un modello simile. La conseguente corsa agli armamenti basata sull’AI avrà un effetto diretto sul numero e sulla frequenza degli aggiornamenti che le organizzazioni dovranno gestire con attività di remediation, e a un ritmo accelerato. L’automazione è ciò che consente a un programma di reggere. I team che ancora applicano patch solo su base mensile si troveranno ad affrontare un periodo difficile.

Se gestisci un programma IT o di sicurezza, vale la pena fare ora un’autovalutazione. Prendi l’ultima patch critica che hai distribuito. Ancora meglio: se uno zero-day uscisse di venerdì, riusciresti a risolverlo entro lunedì? Misura il tempo dalla pubblicazione della CVE all’installazione verificata sull’ultimo endpoint. Se quel numero si misura in settimane, l’apocalisse delle patch ti raggiungerà.

Ivanti lancia l’IA agentica sul sistema di riferimento di cui ti fidi

Mon, 20 Apr 2026 22:00:02 Z

Investitori e aziende si stanno finalmente ponendo la domanda che avevano evitato: quali software company sopravvivranno alla rivoluzione dell’IA e quali diventeranno obsolete? La risposta è sempre più chiara. Le aziende che fungono da sistema di riferimento, la fonte autorevole di verità da cui dipende la stessa IA, sono essenziali.

Oggi Ivanti annuncia il rilascio controllato di Ivanti Neurons AI Self-Service Agent, la nostra prima soluzione di IA autonoma. Partiamo da una posizione di forza strategica, introducendo inizialmente la nuova soluzione nel nostro framework di IT Service Management (ITSM) e facendo leva sulla nostra lunga esperienza nell’automazione intelligente attraverso workflow integrati, l’infrastruttura di bot Neurons, strumenti di IA generativa e ora un agente autonomo pienamente conversazionale.

Creare le basi per scalare l’IA

Non mancano certo le discussioni su ciò che l’IA potrà fare in futuro, ma quel potenziale non ha valore senza una solida base a supporto.

Operazionalizzare l’IA autonoma e scalarne l’impatto in tutta l’organizzazione richiede cinque capacità fondamentali.

Sapere cosa esiste: l’IA deve operare su dati di discovery accurati, non su supposizioni. Senza visibilità in tempo reale su dispositivi, utenti, configurazioni e dipendenze, le azioni autonome diventano rischiose.
Mantenere la memoria istituzionale: l’IA ha bisogno di un contesto persistente che sopravviva ai cambiamenti organizzativi. Relazioni, cronologia e dipendenze devono essere preservate in un sistema di riferimento.
Assumere la responsabilità: ogni azione autonoma richiede una titolarità chiara e una traccia decisionale. Quando l’IA agisce per conto dell’organizzazione, qualcuno deve esserne responsabile.
Applicare le policy: l’IA deve distinguere tra ciò che è tecnicamente possibile e ciò che è consentito dall’organizzazione. L’ottimizzazione senza governance crea rischi di compliance.
Garantire l’auditabilità: ogni azione o decisione presa tramite l’IA deve essere tracciabile, spiegabile e difendibile in sede di audit.

Non è un limite di un singolo modello, ma la natura stessa del funzionamento dell’IA. L’IA è potente, ma opera sui dati. E se questi dati sono frammentati, imprecisi o privi di governance, lo sarà anche l’IA costruita su di essi.

È proprio questo che Ivanti Neurons Platform è stata progettata per offrire. La nostra Neurons Platform funge da solido sistema di riferimento e pannello di controllo per le operazioni IT e di sicurezza. Il nostro Discovery Engine stabilisce la fonte attendibile dei dati. La nostra CMDB preserva relazioni, dipendenze e cronologia delle modifiche. Le nostre funzionalità di IT Asset Management (ITAM) assegnano titolarità, ciclo di vita e responsabilità. Il nostro Software Estate Management applica ciò che è consentito rispetto a ciò che viene semplicemente rilevato.

È molto più di un’architettura di prodotto. È la base di cui la tua organizzazione ha bisogno per operare in modo sicuro e intelligente.

Il percorso verso l’erogazione autonoma dei servizi

L’IA agentica non è nata dall’oggi al domani. In Ivanti ci abbiamo lavorato con intenzionalità, mantenendo un focus costante su fiducia, governance e ripetibilità.

Il nostro percorso verso l’erogazione autonoma dei servizi è stato strategico e intenzionale.

Automazione tradizionale: workflow basati su regole che eseguono attività predefinite in sequenza.

IA cognitiva: ha introdotto intelligenza tramite bot, machine learning e analisi predittiva, portando l’IT da un approccio reattivo a uno proattivo.

IA generativa: ha introdotto modelli linguistici di grandi dimensioni e l’interazione in linguaggio naturale.

IA conversazionale: ha approfondito le interazioni aggiungendo riconoscimento dell’intento, rilevamento del sentiment e guardrail di sicurezza, trasformando l’IA da strumento a partner interattivo.

E ora, agenti autonomi che non si limitano a rispondere, ma orchestrano azioni tra sistemi mantenendo la governance in ogni fase.

Ogni fase è stata costruita sulla precedente. E ogni fase ha generato valore concreto per l’azienda solo perché era basata su dati accurati, governance e responsabilità. È questa base che rende possibile l’annuncio di oggi.

Presentiamo Ivanti Neurons AI Self-Service Agent

Il problema è noto a ogni responsabile IT: i dipendenti faticano a trovare risposte disperse in sistemi di conoscenza scollegati. I ticket di base sovraccaricano il service desk. Gli utenti abbandonano portali complessi per frustrazione. I team IT restano intrappolati in un ciclo continuo di ticket, svolgendo attività ripetitive invece di dedicarsi ai progetti strategici che fanno davvero progredire il business. I portali self-service tradizionali non hanno risolto il problema. Sono rigidi, frustranti e spesso creano più problemi di quanti ne risolvano.

Ivanti Neurons AI Self-Service Agent è diverso. Abbiamo visto tutti i chatbot, ma qui si tratta di qualcosa di diverso. È un vero agente di IA conversazionale. Conversa, indaga, risolve ed effettua escalation solo quando necessario. La prima release si concentra sulla ricerca intelligente della conoscenza, sull’escalation degli incidenti e sulla possibilità di richiedere qualcosa all’IT usando il linguaggio naturale. È semplice come inviare un messaggio.

Questa release iniziale offre tre funzionalità eseguite in modo eccellente: ricerca intelligente della conoscenza, escalation degli incidenti quando la conoscenza non è sufficiente e possibilità di effettuare richieste da un catalogo dei servizi senza la complessità dei moduli dei portali self-service.

Sappiamo che tempo, velocità e precisione sono imprescindibili nell’era digitale e abbiamo creato queste funzionalità tenendolo ben presente. L’AI Self-Service Agent interagisce in modo naturale, pone le domande giuste, interroga fonti interne ed esterne approvate e propone risposte verificate. Se questo processo da solo non risolve il problema, l’agente effettua l’escalation e acquisisce un incidente strutturato dalla conversazione senza chiedere all’utente di ripetere la richiesta, garantendo un’esperienza utente senza attriti.

Questa soluzione è basata su un framework di IA progettato per crescere con essa mentre realizziamo la nostra visione completa per la gestione autonoma degli endpoint.

Generare risultati reali, misurabili e davvero importanti

Questo lancio favorisce direttamente risultati strategici per i nostri clienti: aumentare la produttività IT, migliorare la digital employee experience e connettere team e funzioni aziendali in un’unica piattaforma unificata. Ecco cosa significa:

Per il business, significa incrementi di produttività misurabili, un costo per ticket più basso e un IT che opera come motore di risultati strategici anziché come collo di bottiglia operativo.

L’autonomia richiede una base di cui ti puoi fidare

Ciò che rende il nostro approccio all’IA autonoma affidabile e realizzabile è il fatto che l’AI Self-Service Agent è costruito su un sistema di riferimento come parte della Ivanti Neurons Platform. Questo garantisce che:

La nostra IA agentica non improvvisa, ovvero non produce allucinazioni. Opera a partire da dati di discovery accurati, informazioni sugli asset validate e workflow governati.
Sa quali dispositivi esistono, chi ne è responsabile, quale software è consentito e quali policy si applicano.
Mantiene uno stato persistente e applica la responsabilità in ogni azione che intraprende.

Il modello operativo è semplice, ma potente: rilevare continuamente i problemi prima che impattino sugli utenti. Decidere utilizzando dati affidabili dal sistema di riferimento. Agire attraverso un’automazione governata entro confini definiti.

È questa la differenza tra un’IA che genera risposte e un’IA di cui le organizzazioni possono fidarsi in produzione, su scala enterprise.

Il futuro che stiamo costruendo

Questo lancio è al tempo stesso una tappa fondamentale e una base per ciò che verrà. Stiamo creando capacità autonome sul sistema di riferimento da cui dipende la stessa IA. Questo rende la nostra piattaforma più resiliente, le relazioni con i clienti più durature e il valore che offriamo più forte nel tempo.

Il futuro dell’IT è anticipatorio, autonomo e strategico. I responsabili IT non sono gestori reattivi di ticket. Sono orchestratori di infrastrutture intelligenti e autoriparanti. Gli agenti autonomi gestiscono le attività di routine, apprendono continuamente ed effettuano l’escalation dei casi complessi agli esperti umani, il tutto entro guardrail di governance applicati dal sistema di riferimento.

Abbiamo dedicato anni a costruire questo momento. Sono orgoglioso di ciò che il nostro team ha realizzato e ancora più entusiasta di ciò che verrà.

Sovranità digitale e cloud sovrano: proteggere i dati cloud dell’UE per la resilienza operativa

Fri, 17 Apr 2026 12:30:01 Z

La protezione tradizionale dei dati seguiva un principio semplice: i dati archiviati nel Paese A sono protetti dalle leggi del Paese A; i dati archiviati nel Paese B sono protetti dalle leggi del Paese B. Ma nell’economia globale di oggi, il luogo in cui i dati risiedono fisicamente non determina più quali governi possano richiederne l’accesso.

L’infrastruttura cloud ha introdotto una nuova complessità giurisdizionale. L’ubicazione fisica dei data center, la nazionalità della sede centrale del provider cloud e l’entità che controlla le operazioni possono generare rivendicazioni giurisdizionali concorrenti, consentendo potenzialmente a più governi di richiedere l’accesso agli stessi dati.

Che cos’è la sovranità digitale?

Questa sfida ha un nome: sovranità digitale. La sovranità digitale è il principio in base al quale le organizzazioni mantengono il controllo completo dei propri dati nel quadro giuridico della giurisdizione di appartenenza. Questo concetto è diventato una necessità per la resilienza organizzativa, mentre le aziende operano in un contesto geopolitico più frammentato e caratterizzato da minore fiducia. Le organizzazioni private e pubbliche hanno bisogno di un accesso sicuro a piattaforme basate sul cloud che siano conformi ai requisiti normativi locali e protette dai rischi geopolitici, noti o sconosciuti, che interessano la loro area geografica.

In che modo il CLOUD Act statunitense incide sulla residenza dei dati nell’UE

Il CLOUD Act statunitense del 2018 (Clarifying Lawful Overseas Use of Data) ha ulteriormente rafforzato queste preoccupazioni per le organizzazioni dell’UE. Questa legge conferisce alle autorità di contrasto statunitensi il potere di obbligare qualsiasi provider cloud con sede negli Stati Uniti a fornire dati archiviati in qualunque parte del mondo, indipendentemente dalla posizione fisica dei dati o dalla nazionalità del cliente.

Sia il CLOUD Act statunitense sia il Foreign Intelligence Surveillance Act (FISA) hanno dato motivo di preoccupazione alle aziende dell’Unione europea. Attraverso queste due normative, le autorità statunitensi potrebbero accedere ai dati contenuti nelle piattaforme cloud di qualsiasi organizzazione con sede centrale negli Stati Uniti, anche quando il data center cloud si trova in un altro Paese.

Per le aziende con sede nell’UE, l’utilizzo di strumenti statunitensi comporta specifici obblighi GDPR perché i dati personali escono dall’UE. Inoltre, da quando lo Scudo UE-USA per la privacy è stato invalidato (decisione nota come “Schrems II”), le aziende dell’UE hanno bisogno di altre misure di protezione. Le clausole contrattuali standard (SCC) restano valide, ma sono condizionate e complesse, poiché richiedono una valutazione caso per caso.

Da allora è stato introdotto un successivo Data Privacy Framework, ma la fiducia di fondo tra le nazioni coinvolte ha comunque dei limiti. Queste dinamiche hanno aumentato la pressione per garantire la protezione dei dati, rendendo necessarie soluzioni di cloud sovrano per assicurare la resilienza operativa.

Ivanti Neurons for MDM – Sovereign Edition: progettata per la sovranità cloud dell’UE

Per i nostri partner e clienti nell’UE, Ivanti Neurons for MDM Sovereign Edition risponde a questi requisiti attraverso un’architettura e un modello operativo radicalmente diversi. Situata in Germania e gestita in modo indipendente, questa soluzione è stata progettata per allinearsi al Cloud Sovereignty Framework della Commissione europea ed è stata valutata dall’autorevole cyberintelligence.institute, la cui valutazione esperta ha spiegato:

“Ivanti Sovereign Cloud dimostra un elevato livello di controllo europeo nelle aree dell’elaborazione dei dati, della sicurezza e della governance della conformità. Nella sua configurazione attuale, Ivanti Sovereign Cloud raggiunge almeno la certificazione SEAL 2, il che significa che la sovranità dei dati è garantita in tutte le aree. Inoltre, Ivanti Sovereign Cloud soddisfa i requisiti per la certificazione SEAL 3 in molte aree rilevanti, conseguendo così la resilienza digitale.”

È possibile leggere la valutazione tecnica completa per saperne di più.

Raggiungere la conformità alla sovranità dei dati con fiducia

Neurons for MDM – Sovereign Edition – EU offre alle aziende europee una base strategica per la loro piattaforma IT e di sicurezza, fornita da un leader affidabile, mantenendo al contempo le protezioni giurisdizionali locali per la gestione del rischio. Ciò significa che le entità pubbliche e private possono proseguire la propria trasformazione digitale con la certezza che i dati nel cloud resteranno sicuri e che le loro operazioni acquisiranno maggiore resilienza.

Prossimi passi? Leggi il nostro whitepaper Il cloud sovrano come necessità strategica per le organizzazioni europee per scoprire in che modo Ivanti Neurons for MDM Sovereign Edition raggiunge e supera la certificazione SEAL 2 e offre l’architettura di cloud sovrano di cui le organizzazioni europee hanno bisogno per mantenere la sovranità dei dati, abilitando al contempo una trasformazione digitale sicura.

Non tutti gli agenti sono uguali: implementare correttamente l’IA agentica per l’IT

Wed, 08 Apr 2026 13:00:06 Z

Tre mesi fa, una CIO mi ha detto che la sua organizzazione aveva “già implementato degli agenti”. Il suo team endpoint pensava si riferisse ai client di telemetria presenti su ogni laptop gestito. Il service desk pensava intendesse i chatbot basati su IA. Nel frattempo, il suo architetto della sicurezza ha inteso “processo decisionale autonomo”. Avevano tutti ragione, ma stavano parlando di cose diverse.

Questo è il problema della confusione sugli agenti. Può sembrare una questione semantica, ma crea un disallineamento reale quando i team iniziano a prendere sul serio l’implementazione dell’IA agentica. Facciamo quindi chiarezza.

Tre tipi di “agenti” per l’IT e come si integrano tra loro

1. Agenti endpoint

Gli agenti endpoint sono client leggeri che operano silenziosamente sui dispositivi gestiti da decenni: raccolgono telemetria, eseguono policy e applicano patch. Se utilizzi una moderna piattaforma di gestione degli endpoint, sono già distribuiti in tutto il tuo parco dispositivi e svolgono un lavoro continuo e discreto. Sono il tuo livello infrastrutturale: sempre in ascolto e sempre pronti a generare report, ma non prendono decisioni.

2. Bot di automazione e workflow

I bot di automazione e i workflow gestiscono i processi ripetitivi e strutturati su cui si basa l’IT: identificazione proattiva dei problemi, self-healing, reimpostazione delle password, sblocco degli account, provisioning del software, catene di approvazione. Non sono limiti legacy di cui scusarsi. Un bot ben progettato per la reimpostazione delle password è rapido, prevedibile e perfettamente adatto a quel compito. È il tuo livello di esecuzione: affidabile, verificabile e progettato per uno scopo preciso.

3. Agenti IA

Gli agenti IA sono qualcosa di realmente diverso. Mentre gli agenti endpoint raccolgono dati e i bot di automazione eseguono attività, gli agenti IA coordinano entrambi. Orchestrati da modelli linguistici di grandi dimensioni (LLM), comprendono l’intento, ragionano sul contesto proveniente da più sistemi, pianificano azioni in più passaggi e decidono quando è necessario inoltrare un problema a competenze umane.

Ma ecco la sfumatura davvero importante: un agente IA ben progettato non sostituisce il bot di automazione: lo richiama. Quando un dipendente chiede di reimpostare la propria password tramite un’interfaccia conversazionale, l’IA gestisce il dialogo, verifica l’identità, applica la logica delle policy e quindi attiva il workflow esistente per l’esecuzione. È l’intelligenza che orchestra l’automazione. Questa è l’architettura verso cui vale la pena orientarsi. Aggiungendo la telemetria degli endpoint, il quadro diventa ancora più completo.

Ecco come si presenta nella pratica:

Un dipendente scrive: “Il mio laptop è lentissimo dall’ultima patch.”

L’agente IA:

Interpreta l’intento e riconosce che si tratta di un problema di prestazioni potenzialmente causato da una modifica recente.
Recupera dal livello endpoint i dati in tempo reale su carico della CPU, utilizzo del disco e processi di avvio.
Attiva una correzione mirata. Non un’ipotesi. Un’azione basata sui dati e verificabile.

È così che si presenta un IT autoriparante a livello conversazionale.

Cosa rende efficace l’IA agentica per l’ITSM

Implementare correttamente l’IA per la gestione dei servizi IT in chiave agentica dipende da alcune basi fondamentali.

Parti da conoscenze pulite e aggiornate

Un agente IA è valido quanto ciò che conosce e il contesto di cui dispone. Prima di abilitare qualsiasi funzionalità agentica, esegui un audit della tua knowledge base e poniti queste domande chiave:

È aggiornata?
È classificata per caso d’uso?
Viene mantenuta dopo modifiche importanti?

Conoscenze obsolete portano a risultati errati che compromettono rapidamente la fiducia dei dipendenti. Detto questo, gli stessi agenti IA possono essere utilizzati anche per accelerare la creazione di conoscenza. Ogni ticket risolto è una bozza di articolo. Ogni domanda a cui l’agente non riesce a rispondere con sicurezza è una lacuna di conoscenza che ha appena evidenziato per te. L’agente diventa un contributore della tua knowledge base, non solo un suo fruitore.

Fornisci contesto

La sola conoscenza non basta. Gli agenti hanno bisogno di contesto in tempo reale sull’intero ambiente IT. Questo include i dati dei dispositivi dalla CMDB, le informazioni su ruoli e accessi dai sistemi HR e la cronologia dei ticket dall’ITSM. Con questo livello di contesto, è possibile passare da un bot che sembra intelligente a un agente in grado di chiudere il ciclo.

Definisci guardrail di governance

Disporre di controllo e guardrail per l’IA non è facoltativo. È necessario stabilire con precisione cosa l’agente gestisce in autonomia, cosa richiede un passaggio di approvazione umana e cosa deve essere sempre inoltrato. Avere una persona coinvolta nel processo non significa essere eccessivamente prudenti. È piuttosto una scelta progettuale deliberata e intelligente. Per qualsiasi elemento sensibile dal punto di vista della sicurezza, come modifiche MFA, adeguamenti dei privilegi o richieste di accesso ai dati, l’agente dovrebbe far emergere la decisione, non prenderla unilateralmente. Le aziende devono definire queste soglie fin dall’inizio, non cercare di aggiungerle in un secondo momento.

Gestione del cambiamento

Anche con una configurazione perfetta, l’implementazione fallisce quando le aziende non considerano la gestione del cambiamento.

Il team del service desk ha bisogno di un modello mentale chiaro di ciò che l’agente gestisce e di quando deve intervenire. Puoi considerarlo come qualsiasi altra divisione del lavoro: non devono esserci sovrapposizioni. Non vuoi che le persone sprechino tempo su attività che l’agente può completare all’istante, e certamente non vuoi che l’agente prenda decisioni quando la policy prevede il coinvolgimento di una persona. Confini chiari consentono a entrambe le parti di lavorare dove generano il massimo valore.

I tuoi dipendenti devono poter confidare che il contesto non vada perso a metà conversazione quando un problema viene inoltrato dall’agente a una persona. Consentire subito agli agenti di andare oltre il supporto di base è il modo in cui un progetto pilota promettente si trasforma in un rollback complesso. Inizia con un ambito ristretto e conquista gradualmente il diritto di espanderti.

Come si presenta il successo

Per dimostrare il ROI dell’IA agentica, le organizzazioni dovrebbero concentrarsi su metriche operative che riflettono un impatto reale e che possono essere migliorate tramite una migliore orchestrazione.

La deflessione dei ticket mostra con quanta efficacia gli agenti risolvono le richieste comuni end-to-end senza intervento umano. L’auto-riparazione evidenzia quando i sistemi possono diagnosticare i problemi e intraprendere azioni correttive approvate, riducendo il lavoro manuale e il volume delle code. Il Mean Time to Resolution (MTTR) riflette quanto il sistema accorci il percorso dalla richiesta al risultato, eliminando passaggi di consegne e cambi di strumento.

Nel loro insieme, queste metriche indicano se l’IA agentica sta davvero riducendo il lavoro, non semplicemente spostandolo. Ma la misura più importante è la soddisfazione dell’utente finale (CSAT). La velocità senza soddisfazione crea solo attriti più rapidi.

La migliore IA agentica è invisibile. I dipendenti chiedono aiuto, ottengono ciò di cui hanno bisogno e proseguono senza notare i workflow, i controlli o le azioni automatizzate dietro le quinte. Le organizzazioni che ottengono risultati progettano intenzionalmente sistemi agentici, con guardrail chiari e una solida comprensione di come l’autonomia rimodella le operazioni.

Prossimi passi

Se stai valutando il ruolo dell’IA agentica self-service nel tuo ecosistema IT, un punto di accesso conversazionale è spesso il modo più pratico per iniziare. Consolidare la creazione degli incidenti, le richieste di servizio, l’accesso alla conoscenza e i controlli di stato in un’unica interfaccia può ridurre gli attriti per i dipendenti, rispettando comunque le policy e i workflow esistenti.

Questo approccio getta le basi per una piattaforma agentica più ampia. Per i leader IT sotto pressione perché devono fare di più con meno risorse, questo è il momento di definire in modo consapevole come dovrebbe operare l’IA, dove l’autonomia aggiunge valore e dove sono necessari guardrail.

Pronto a compiere il passo successivo nel tuo percorso verso l’IA agentica? Scarica il nostro whitepaper per ottenere il framework, il modello di maturità e la roadmap di implementazione di cui hai bisogno per avere successo.

Vedere tutto o rischiare tutto: la verità sulla visibilità IT

Mon, 06 Apr 2026 12:00:02 Z

Nella vita quotidiana, ignorare ciò che non si vede può sembrare innocuo. Nell’IT, crea un falso senso di sicurezza e un’illusione costosa.

Sebbene molte organizzazioni utilizzino una qualche forma di rilevamento degli asset, la ricerca sulla sicurezza 2026 di Ivanti rivela che oltre 1 professionista IT su 3 (38%) dichiara di avere dati insufficienti sui dispositivi che accedono alle proprie reti, mentre il 45% afferma di non disporre di informazioni adeguate sullo shadow IT. Questa mancanza di visibilità espone gli asset critici al rischio di non essere rilevati né gestiti.

Eppure gli ambienti ibridi oggi si estendono tra uffici, abitazioni, cloud e data center. Man mano che dispositivi, identità, workload cloud e strumenti SaaS si muovono attraverso questi spazi, molti di essi restano fuori dal perimetro dei metodi di rilevamento tradizionali. I laptop non gestiti rimangono sulla rete. Gli strumenti SaaS vengono adottati senza supervisione. Le risorse cloud compaiono e scompaiono prima che la CMDB venga aggiornata. Il risultato è un ambiente pieno di asset presenti, influenti e completamente invisibili.

Il costo di una visibilità parziale è molto più elevato di quanto la maggior parte delle organizzazioni immagini. Qualsiasi asset che non viene tracciato o compreso diventa una fonte di rischio, spesa non pianificata e inefficienza operativa.

La portata di questa sfida è illustrata chiaramente nel report Ivanti 2025 Securing the Borderless Digital Landscape:

3 lavoratori IT su 4 affermano che l’uso di dispositivi personali, o BYOD, è una pratica regolare nella propria organizzazione. Tuttavia, solo il 52% dello stesso gruppo dichiara che le proprie organizzazioni lo consentono esplicitamente.
Nelle aziende in cui il BYOD non è consentito, il 78% dei dipendenti ignora completamente il divieto.

Il problema della tecnologia shadow aumenta ulteriormente con la crescita esponenziale dell’uso dell’IA sul posto di lavoro. Secondo lo stesso studio Ivanti, quasi un terzo (32%) delle persone che utilizzano strumenti di IA generativa al lavoro ammette di tenere nascosto al datore di lavoro il proprio uso dell’IA.

La buona notizia: una visibilità completa e continua è possibile, e le organizzazioni che la raggiungono riducono i costi operativi, eliminano i rischi dovuti ai punti ciechi e rafforzano la preparazione alla compliance. Gli approcci moderni al rilevamento offrono ora all’IT la capacità di vedere ogni asset, comprenderne il contesto e gestirlo con fiducia.

I costi nascosti della visibilità IT parziale

Molte organizzazioni ritengono che ottenere visibilità sulla “maggior parte” dei propri asset sia sufficiente; tuttavia, quando alcuni asset restano invisibili e non gestiti, rischi critici possono rimanere nascosti senza essere notati. Esempi di comuni punti ciechi di visibilità includono laptop non rilevati che possono comparire solo a intermittenza negli scanner IT, strumenti SaaS appena acquisiti adottati senza il coinvolgimento dell’IT, workload cloud orfani che non arrivano mai nella CMDB e identità con privilegi eccessivi che passano inosservate e non vengono corrette.

Quando anche una piccola parte dell’ambiente resta non censita, emergono subito quattro grandi problemi:

1. La sicurezza si indebolisce

Gli asset invisibili o visibili solo a intermittenza non ricevono patch, saltano le scansioni e creano varchi per gli attaccanti. I punti ciechi rallentano la risposta agli incidenti e rendono difficile allineare le priorità di patching. Secondo uno studio globale 2026 di Ivanti, il 38% dei lavoratori IT afferma che dati inaccessibili e isolati rendono difficile monitorare lo stato delle patch e i rollout.

2. La compliance vacilla

In aggiunta a queste sfide di sicurezza, lo stesso report rileva che il 35% delle organizzazioni IT ritiene che le lacune nella visibilità dei dati rendano molto più difficile mantenere la compliance.

Le evidenze di audit finiscono frammentate tra strumenti disconnessi, fogli di calcolo e caselle di posta. Senza la capacità di tracciare con sicurezza dove risiedono i dati, dimostrare la compliance diventa impossibile.

3. La spesa per il software perde valore

Anche con strumenti di gestione SaaS o di inventario in uso, dati incompleti su utilizzo e diritti generano spese eccessive. Secondo il SaaS Management Index 2025 di Zylo, le aziende perdono circa il 25% dei propri budget SaaS in diritti inutilizzati, strumenti ridondanti e licenze sottoutilizzate.

La ricerca Technology at Work 2025 di Ivanti ha rilevato che quasi un lavoratore IT su tre (31%) afferma che la propria organizzazione non monitora le licenze software inutilizzate o sottoutilizzate, forse perché potrebbe non avere un inventario completo del totale. Inoltre, il 39% dei team IT dichiara che l’hardware obsoleto alimenta sprechi nel budget IT.

Ogni risorsa che non è possibile vedere — o verificare — prosciuga silenziosamente il budget.

4. Le operation perdono efficienza

Dati conflittuali o incompleti costringono i team a ricontrollare le informazioni sui dispositivi, inseguire record obsoleti e risolvere problemi sugli asset sbagliati. Questo rallenta l’erogazione dei servizi e aumenta le rilavorazioni.

La visibilità parziale non si limita a oscurare la realtà. Crea rischi nascosti, costi nascosti e ritardi nascosti.

Perché le lacune nella visibilità IT continuano a crescere

Purtroppo, per molte aziende le lacune di visibilità si stanno ampliando. Con l’aumento di organici, dispositivi, identità e utilizzo del SaaS, per i team IT diventa sempre più difficile mantenere una visibilità completa. Diversi fattori contribuiscono alla crescita dei problemi di visibilità, tra cui:

Shadow IT e proliferazione del SaaS che accelerano più rapidamente di quanto l’IT riesca a gestire.
Risorse cloud che compaiono e scompaiono nell’arco di pochi minuti.
Lavoratori remoti e ibridi che si connettono a reti esterne alla rete aziendale.
Proliferazione delle identità su decine di app e piattaforme.
Strumenti di rilevamento legacy che acquisiscono solo una frazione dell’ambiente.

Queste pressioni si sommano rapidamente. I dipendenti adottano strumenti comodi prima che l’IT possa approvarli. Quando dispositivi, server o app vengono creati in ambienti cloud ed eliminati in pochi minuti, possono sfuggire ai controlli di sicurezza e al monitoraggio. Di conseguenza, queste risorse di breve durata potrebbero non ricevere patch né protezione, creando punti ciechi che gli attaccanti potrebbero sfruttare prima che qualcuno se ne accorga. I lavoratori remoti potrebbero non connettersi mai alla rete aziendale. Gli ecosistemi SaaS, di identità e di dispositivi si espandono molto più rapidamente di quanto gli strumenti di rilevamento legacy siano stati progettati per tracciare. Senza visibilità continua e multi-sorgente, le organizzazioni restano indietro quasi immediatamente.

Per colmare queste lacune crescenti, le organizzazioni devono passare da inventari reattivi e puntuali a un modello basato su visibilità continua, contestuale e in tempo reale. È qui che comprendere e ottenere una vera visibilità sull’intero parco IT diventa fondamentale.

La visibilità IT è molto più di un semplice inventario

La vera visibilità non è un elenco di asset. È intelligence completa, aggiornata e affidabile su cui ogni team può agire. La visibilità totale richiede di identificare ogni dispositivo, app SaaS, identità, workload cloud, configurazione e segnale di utilizzo, indipendentemente da dove si trovi o da quanto a lungo esista.

Significa anche comprendere le relazioni: chi possiede un asset, quali dati tocca, il suo livello di rischio, il suo impatto sulla compliance e se viene effettivamente utilizzato. Questa è la base che trasforma il rilevamento da semplice informazione a controllo operativo.

Come la visibilità completa trasforma i workflow

Quando la visibilità diventa continua e contestuale, l’intero ambiente si trasforma. Gli ambienti IT moderni richiedono più di una semplice osservazione passiva. Con minacce, workload e asset che crescono a una velocità senza precedenti, le organizzazioni hanno bisogno di azioni intelligenti e automatizzate per trasformare la visibilità in risultati concreti. Insight basati sull’IA e workflow automatizzati consentono ai team di affrontare in modo proattivo le minacce alla sicurezza, risolvere i problemi e ottimizzare le operation senza attendere interventi manuali.

Con il giusto approccio, le organizzazioni possono superare la visibilità parziale e finalmente vedere:

ogni dispositivo, applicazione, identità e workload cloud.
dati normalizzati e riconciliati presentati come un’unica fonte di verità.
vulnerabilità associate agli asset e ai proprietari esatti interessati.
workflow automatizzati che attivano patching, quarantene, aggiornamenti della CMDB e chiusura dei ticket con prove a supporto.
rilevamento che combina metodi agent, agentless, attivi e passivi per coprire ogni angolo dell’ambiente ibrido.

Come ogni team trae vantaggio dalla visibilità unificata degli asset

Con dati sugli asset unificati e affidabili, ogni team ne trae vantaggio:

La sicurezza può mappare le esposizioni sugli asset reali e rispondere più rapidamente.
Le operation IT possono chiudere il ciclo dal rilevamento alla correzione fino alla verifica.
I team endpoint possono applicare le policy in modo coerente.
I team ITAMpossono ottimizzare la spesa utilizzando insight accurati su utilizzo e diritti, eliminando gli sprechi.
I team di compliance possono produrre evidenze automatizzate e pronte per l’audit senza attività manuali.

Ottenere oggi una visibilità IT completa

Questo livello di chiarezza è raggiungibile già oggi. Utilizzando approcci moderni al rilevamento che combinano metodi agent, agentless, attivi e passivi, l’intelligence unificata sugli asset assicura ai team IT una visibilità completa, anche quando gli ambienti diventano più complessi e distribuiti.

L’intelligence unificata sugli asset acquisisce dati aggiornati da ogni area dell’organizzazione, inclusi dispositivi, identità, applicazioni SaaS, workload cloud e segnali di rete. Questi dati vengono normalizzati e consolidati in un’unica fonte di verità affidabile.

Invece di gestire inventari parziali o frammentati da più strumenti, le organizzazioni ottengono una vista olistica in tempo reale. Ogni asset è rappresentato accuratamente con i suoi dettagli e il suo contesto principali, eliminando i punti ciechi e consentendo ai team di proteggere e gestire con fiducia l’intero ambiente, eliminando le congetture, riducendo il rischio e ripristinando il controllo.

Scopri come Ivanti Neurons for Discovery può offrire una visibilità completa sul tuo ambiente.

Dall’inventario all’intelligence: come IA e automazione migliorano la visibilità degli endpoint

Fri, 03 Apr 2026 13:00:09 Z

La visibilità degli endpoint è sempre stata fondamentale per l’IT e la sicurezza. Non è possibile proteggere, applicare patch o supportare ciò che non si vede.

Ma con ambienti sempre più distribuiti e complessi, il significato di visibilità si è evoluto. Non basta più sapere che un dispositivo esiste: i team IT e le organizzazioni nel loro complesso devono comprenderne lo stato, la postura di rischio e l’impatto sia sulla sicurezza sia sull’esperienza utente.

È qui che IA e automazione degli endpoint iniziano a fare una differenza concreta. Portando la visibilità degli endpoint da un inventario statico a un’intelligence continua, le organizzazioni possono passare dal rilevamento reattivo a operazioni proattive, persino autonome.

Perché le pratiche tradizionali di rilevamento non sono più sufficienti

Le pratiche tradizionali di rilevamento sono state progettate per una realtà IT molto diversa. Il loro approccio è pensato per ambienti relativamente statici, perimetri chiaramente definiti e processi manuali. Questa strategia non è facilmente scalabile nell’attuale mondo ibrido e cloud-first.

I workflow di rilevamento manuale producono spesso inventari incompleti o obsoleti. L’Autonomous Endpoint Management Advantage Report 2026 di Ivanti conferma questa realtà: solo il 52% delle organizzazioni dichiara di utilizzare oggi una soluzione di gestione degli endpoint , lasciando molti ambienti con una visibilità centralizzata limitata e punti ciechi persistenti tra dispositivi non gestiti o shadow IT.

Nella pratica, questa frammentazione si manifesta in modi molto familiari. I team spesso devono gestire più inventari: uno proveniente da uno strumento di gestione client on-premise, un altro da una piattaforma MDM e un altro ancora da sistemi di identità o accesso, creando lacune che si ampliano man mano che gli ambienti diventano più complessi.

Sfide comuni nel rilevamento manuale dei dispositivi

Il rilevamento manuale dipende fortemente dall’intervento umano, introducendo incoerenze ed errori. Man mano che gli ambienti diventano più distribuiti, questi processi faticano a evolvere di pari passo, rendendo difficile mantenere inventari accurati quando i dispositivi vengono aggiunti, riassegnati o accessi da remoto. Riconciliare le modifiche in parchi dispositivi estesi diventa un’attività lunga e fragile, aumentando la probabilità che alcuni dispositivi scompaiano completamente dalla vista.

Nel tempo, queste limitazioni si sommano. Il rilevamento diventa episodico anziché continuo e la visibilità resta indietro rispetto alla realtà. Quando gli inventari vengono riconciliati, l’ambiente è già cambiato.

Lacune di visibilità e rischi per la sicurezza

Queste lacune non sono teoriche. Le ricerche di Ivanti mostrano che molte organizzazioni faticano ancora con una visibilità degli endpoint di base anche dopo aver implementato più strumenti di gestione. I dati degli endpoint sono distribuiti tra scanner, piattaforme MDM e sistemi di accesso, ma raramente sono centralizzati, aggiornati in modo continuo o considerati affidabili dai diversi team. Di conseguenza, shadow IT, dispositivi non gestiti e percorsi di accesso sconosciuti restano fonti persistenti di rischio per sicurezza e conformità.

I punti ciechi creano rischi concreti. Molte organizzazioni faticano a identificare quali dispositivi siano vulnerabili o stiano persino accedendo attivamente ai loro ambienti.

Quando i team non riescono a comprendere in modo affidabile l’esposizione dei dispositivi o i modelli di accesso, le decisioni di sicurezza vengono prese sulla base di dati incompleti o obsoleti, aumentando il rischio e ritardando la remediation. Il report Ivanti citato evidenzia infatti quanto siano comuni questi punti ciechi:

Il 45% delle organizzazioni segnala difficoltà nell’identificare lo shadow IT
Il 41% fatica a identificare le vulnerabilità sui dispositivi
Il 35% afferma che i punti ciechi nei dati rendono difficile determinare la conformità delle patch.

Rilevamento dei dispositivi e monitoraggio dello stato dei dispositivi

Il rilevamento è solo il primo passo. Sapere che un dispositivo esiste non indica se sia sicuro, conforme o persino funzionante correttamente. È qui che il monitoraggio dello stato dei dispositivi diventa fondamentale.

Il rilevamento indica cosa è presente. Il monitoraggio dello stato aggiunge il contesto che conta davvero, dalle prestazioni e dalla deviazione della configurazione fino alla postura di sicurezza complessiva. La ricerca contenuta nel report 2025 Securing the Borderless Digital Landscape di Ivanti sottolinea quanto queste lacune di visibilità restino significative: due professionisti IT su cinque (38%) dichiarano di non avere dati sufficienti sui dispositivi che accedono alla rete e il 45% segnala una visibilità insufficiente sullo shadow IT.

BYOD e dispositivi edge, in particolare, sono motivo di preoccupazione. Possono essere online e rappresentare comunque un rischio significativo. Potrebbero non avere patch critiche, eseguire software obsoleto, discostarsi dagli standard di configurazione o presentare problemi di prestazioni che impattano gli utenti.

I dati di presenza rispondono alla domanda: “È presente?” I dati sullo stato rispondono: “È sicuro, conforme e utilizzabile?” Senza informazioni sullo stato, le organizzazioni gestiscono di fatto gli endpoint al buio.

Indicatori chiave dello stato degli endpoint

Per gestire gli endpoint in modo proattivo, le organizzazioni hanno bisogno di una visibilità continua sugli indicatori chiave dello stato.

Tra questi rientrano:

Versioni del sistema operativo e delle applicazioni
Stato delle patch e dell’antivirus
Deviazione della configurazione
Postura di sicurezza complessiva

Anche i segnali relativi all’esperienza utente, come arresti anomali, latenza e degrado delle prestazioni, forniscono avvisi precoci che qualcosa non va.

Le piattaforme moderne unificano questi segnali in un’unica vista, consentendo ai team IT e di sicurezza di capire non solo quali dispositivi esistono, ma anche come stanno funzionando e dove sta emergendo il rischio.

Il rischio di monitorare solo la presenza dei dispositivi

Quando le organizzazioni si concentrano solo sulla presenza dei dispositivi, si espongono a rischi sia di sicurezza sia operativi. La visibilità senza contesto porta a rilevamenti tardivi, requisiti di conformità mancati e gestione reattiva.

Impatto negativo su sicurezza e conformità

Monitorare solo la presenza aumenta la probabilità che malware, configurazioni errate o violazioni delle policy passino inosservati. I dispositivi non registrati nella gestione o non conformi possono comunque accedere a risorse sensibili, creando lacune nell’applicazione dei controlli. Quando le decisioni di accesso non sono legate allo stato del dispositivo, l’applicazione dei controlli diventa incoerente per impostazione predefinita.

Una solida visibilità degli endpoint, unita ad accesso e sicurezza, garantisce che solo i dispositivi gestiti e conformi possano raggiungere sistemi e dati sensibili.

Collegare l’accesso allo stato di gestione e conformità è fondamentale. Accesso condizionale, VPN e controlli zero trust sono efficaci solo quando visibilità e registrazione vengono applicate in modo coerente su tutti gli endpoint.

La gestione delle patch è una delle aree in cui una visibilità limitata crea il maggiore carico operativo. La nostra ricerca su IT e sicurezza mostra che molti team IT faticano a monitorare lo stato delle patch nell’intero parco endpoint e a mantenere la conformità man mano che gli ambienti diventano più distribuiti. Ad esempio, tra le persone intervistate,

Il 38% dei professionisti IT e della sicurezza dichiara di avere difficoltà a monitorare lo stato e il rollout delle patch.
Il 35% dei team fatica a mantenere la conformità.

Queste sfide non riguardano solo la disponibilità delle patch. Derivano da lacune nella visibilità sullo stato dei dispositivi, sulla proprietà e sull’esposizione reale, rendendo difficile stabilire le priorità e verificare la remediation.

Inefficienze operative

Dal punto di vista operativo, una visibilità limitata genera inefficienza. I team IT dedicano tempo alla risoluzione di problemi che l’automazione potrebbe gestire, alla ricerca di dispositivi che avrebbero dovuto essere rilevati automaticamente e alla reazione agli incidenti invece che alla loro prevenzione.

Senza dati sullo stato, i team sono costretti a operare in modalità emergenza, rispondendo ai problemi dopo che hanno impattato gli utenti anziché affrontarli in modo proattivo.

È proprio qui che IA e automazione possono iniziare a cambiare le regole del gioco.

Come IA e automazione degli endpoint migliorano la visibilità degli endpoint

IA e automazione trasformano la visibilità degli endpoint da un’attività di rilevamento una tantum a una capacità continua e autosostenuta. Consentono ai team di unificare i dati, rilevare anomalie e mantenere inventari accurati senza intervento manuale.

Telemetria unificata da più fonti

Le moderne piattaforme di gestione degli endpoint con funzionalità di IA e automazione consolidano la telemetria proveniente da strumenti di rilevamento, UEM, MDM, patching, vulnerabilità e sicurezza in una vista unificata e aggiornata di continuo. Questa telemetria unificata elimina la necessità di riconciliare inventari isolati e offre una vista condivisa e affidabile sia per l’IT sia per la sicurezza.

Normalizzando i dati tra dispositivi desktop, mobile, server e IoT, le organizzazioni ottengono una visibilità olistica che supporta decisioni più rapide e sicure.

La nostra ricerca sull’autonomous endpoint management (AEM) mostra inoltre che le organizzazioni fanno maggiori progressi quando la visibilità degli endpoint viene trattata come un obiettivo condiviso. I team che monitorano metriche quali tempo di rilevamento, percentuale di endpoint completamente gestiti e durata dell’esposizione tramite dashboard condivise riescono meglio ad allineare IT e sicurezza sugli stessi dati. Questa visibilità condivisa trasforma la gestione degli endpoint da reporting a silos in un processo coordinato e guidato dai dati.

Automazione basata sull’IA e bot autonomi

L’automazione svolge un ruolo fondamentale nel mantenere aggiornata la visibilità. I bot basati sull’IA possono rilevare nuovamente i dispositivi in automatico, riconciliare i duplicati, aggiornare proprietà e posizione e rilevare anomalie nell’ambiente.

Quando gli agenti smettono di inviare report o i profili si interrompono, i workflow automatizzati possono ripararli o reinstallarli senza intervento umano. Questo garantisce che la visibilità non si degradi nel tempo e riduce il carico operativo sui team IT.

Workflow di autoriparazione per la produttività IT

I workflow di autoriparazione estendono l’automazione all’endpoint stesso. Problemi comuni come aggiornamenti non riusciti, servizi arrestati o deviazioni della configurazione possono essere rilevati e risolti automaticamente, spesso prima che gli utenti notino un problema.

L’automazione degli endpoint consente a questi workflow di autoriparazione di operare continuamente in background, risolvendo problemi comuni senza attendere l’intervento umano.

Risolvendo questi problemi senza ticket, le organizzazioni riducono i tempi di inattività, migliorano l’esperienza utente e liberano il personale IT per concentrarsi su iniziative di maggior valore. Infatti, oltre due terzi dei team IT oggi ritengono che IA e automazione nell’ITSM consentiranno loro di offrire esperienze di servizio migliori e di avere più tempo per supportare gli obiettivi aziendali.

Impatto più ampio su sicurezza, produttività ed esperienza utente

Quando IA e automazione vengono integrate nella visibilità degli endpoint, i benefici si estendono oltre le operazioni IT. La postura di sicurezza migliora, gli utenti subiscono meno interruzioni e la produttività aumenta.

Combinando visibilità e controllo degli endpoint, le organizzazioni possono ridurre il rischio continuando al tempo stesso a supportare produttività e modelli operativi flessibili.

Colmare le lacune di visibilità

Gli insight guidati dall’IA eliminano i punti ciechi monitorando continuamente l’attività e lo stato degli endpoint. Invece di affidarsi a scansioni periodiche o controlli manuali, le organizzazioni mantengono una consapevolezza in tempo reale del proprio ambiente endpoint.

Questa visibilità continua trasforma la gestione degli endpoint da un progetto di inventario statico a una capacità viva e dinamica, che si adatta ai cambiamenti dell’ambiente.

Migliorare le operazioni IT e la soddisfazione degli utenti finali

L’automazione riduce il volume dei ticket e accelera i tempi di risoluzione, mentre l’analisi predittiva aiuta a prevenire i tempi di inattività prima che impattino gli utenti. Distribuzioni ad anelli, finestre di manutenzione e cataloghi self-service consentono di introdurre modifiche con un’interruzione minima.

Quando gli utenti ricevono supporto più rapido e subiscono meno interruzioni, la resistenza alla gestione degli endpoint diminuisce e l’adozione migliora. Nel tempo, questo crea un ciclo di feedback più sano, in cui visibilità, automazione ed esperienza utente si rafforzano a vicenda invece di competere.

È qui che l’autonomous endpoint management porta le organizzazioni a fare il passo successivo. La visibilità diventa continua anziché episodica. L’automazione mantiene accurati gli inventari, aggiornati i segnali sullo stato e visibile il rischio in tempo reale.

Con dati condivisi e una chiara titolarità, i team IT e di sicurezza smettono di reagire ai problemi a posteriori e iniziano a gestire gli endpoint in modo proattivo. Questo passaggio dall’inventario all’intelligence è ciò che rende possibile l’autonomous endpoint management, che sta rapidamente diventando lo standard per le moderne operazioni IT.

In che modo l’automazione basata sull’AI risolve i silos nella gestione delle patch

Thu, 02 Apr 2026 15:37:11 Z

"Vediamo 10.000 vulnerabilità critiche!"

"Abbiamo installato tutte le patch la scorsa settimana!"

Questa conversazione avviene ogni giorno nei reparti IT aziendali. I team di sicurezza presentano dashboard piene di avvisi rossi. I team IT mostrano report di distribuzione con un successo del 98%. Entrambi i team osservano dati reali. Entrambi hanno pienamente ragione. Ed entrambi sono del tutto all’oscuro di ciò che accade realmente nell’ambiente endpoint.

Non è un problema di persone: i vostri team non sono incompetenti. Non è un problema di processo: i vostri workflow non sono compromessi. È un problema tecnologico: state chiedendo a due team di gestire lo stesso rischio usando sistemi che mostrano loro realtà diverse.

Ai team di sicurezza viene fornita una versione della realtà tramite scanner di vulnerabilità e threat intelligence. Nel frattempo, i team IT vedono le cose in modo diverso quando consultano i report sulla gestione dei dispositivi e sulla distribuzione delle patch.

L’aspetto complesso è che entrambe le visioni possono essere corrette se considerate separatamente e comunque risultare fuorvianti nella pratica. È così che si arriva al consueto stallo: la sicurezza segnala migliaia di vulnerabilità critiche; l’IT riferisce che le patch sono state distribuite correttamente. La disconnessione nasce nello spazio tra questi sistemi.

Perché IT e sicurezza non sono allineati sul patching

La maggior parte delle organizzazioni affronta il disallineamento sul patching tra IT e sicurezza migliorando la comunicazione tra IT e sicurezza. Programmano più riunioni. Creano percorsi di escalation. Implementano SLA. E sei mesi dopo, si ritrovano a discutere esattamente dello stesso problema, con slide PowerPoint migliori.

Ecco ciò che nessuno vuole ammettere: non si può risolvere un problema di frammentazione dei dati semplicemente collaborando di più. Quando IT e sicurezza lavorano a partire da inventari fondamentalmente diversi di ciò che esiste, di ciò che è vulnerabile e di ciò che è stato corretto, aggiungere ulteriore coordinamento non fa che rallentare un processo già inefficace.

Ecco perché la stessa conversazione si ripete continuamente all’interno di molte organizzazioni. Entrambi i team sono sicuri dei propri dati ed entrambi hanno “ragione” nel contesto ristretto degli strumenti su cui fanno affidamento.

Ed è proprio questo il problema. Anche se entrambe le visioni sono “corrette”, nessuna riflette l’intero ciclo di vita del rischio. I dati sulle vulnerabilità non indicano sempre se i dispositivi interessati siano gestiti o raggiungibili. I report sulle patch non tengono sempre conto degli endpoint non gestiti, classificati in modo errato o scoperti di recente che hanno ancora accesso alle risorse aziendali. Ciò che manca è una risposta affidabile all’unica domanda che conta davvero: quali endpoint sono esposti in questo momento?

I silos tecnologici creano realtà contrastanti

La maggior parte delle aziende gestisce gli endpoint attraverso un insieme eterogeneo di sistemi evoluti in modo indipendente nel tempo, ognuno dei quali acquisisce solo un frammento della realtà.

Un sistema può evidenziare un’esposizione critica senza sapere se il dispositivo sia gestito. Un altro può confermare una remediation riuscita senza considerare endpoint scoperti di recente o classificati in modo errato che hanno ancora accesso. Il risultato? Nessun modo affidabile per tracciare il rischio dal rilevamento alla distribuzione fino all’esposizione effettiva.

Considerate questo dato: secondo il Securing the Borderless Digital Landscape Report di Ivanti, un’organizzazione media gestisce solo il 60% dei propri dispositivi edge. Ciò significa che il 40% dei potenziali punti di ingresso esiste al di fuori della visibilità dell’IT e dei relativi workflow di patching. La sicurezza li vede. L’IT no. Questo è il vostro divario di vulnerabilità. Senza questa continuità, i team sono costretti a riconciliare manualmente viste parziali. I dati vengono discussi invece di diventare azione.

Viste dei dati diverse generano attrito

Immaginate che sia lunedì mattina: la sicurezza scopre una zero-day critica in un client VPN ampiamente utilizzato. Invia all’IT un avviso urgente: "Rilevati 30.000 endpoint vulnerabili: applicare subito le patch."

L’IT controlla la console di distribuzione: "Client VPN già aggiornato su 28.000 dispositivi giovedì scorso."

Entrambe le affermazioni sono vere. La sicurezza esegue la scansione dell’intera rete, inclusi laptop di appaltatori, dispositivi BYOD e sistemi che si sono connessi brevemente alla VPN ma non sono gestiti dall’IT. L’IT ha installato le patch su tutto ciò che era presente nel proprio inventario dei dispositivi.

Nel frattempo, 2.000 endpoint realmente vulnerabili rimangono esposti perché esistono nella vista della sicurezza ma non in quella dell’IT. La patch che avrebbe dovuto richiedere 24 ore ora richiede tre giorni di riconciliazione manuale.

Quando IT e sicurezza operano da fonti di dati diverse, le priorità di gestione delle vulnerabilità disallineate sono inevitabili. I team di sicurezza si concentrano sul numero di vulnerabilità, sui punteggi di gravità e sull’intelligence sugli exploit. I team IT danno priorità al successo della distribuzione, alla stabilità dei sistemi e all’impatto sugli utenti. Entrambe le prospettive sono necessarie, ma senza un quadro di riferimento condiviso spingono in direzioni diverse.

Ciò che ne deriva non è solo tensione; è paralisi decisionale. La remediation rallenta mentre i team riconciliano gli inventari, convalidano i risultati e discutono sull’ambito. Le vulnerabilità rimangono aperte più a lungo del dovuto, non perché le patch non siano disponibili, ma perché non esiste un’unica vista che colleghi rilevamento, distribuzione ed esposizione.

Il rischio delle priorità di patching disallineate

Il disallineamento rallenta la collaborazione, ma soprattutto crea un rischio misurabile che va ben oltre l’attrito interno.

La ricerca di Ivanti sull’Autonomous Endpoint Management riflette questa sfida nella pratica:

Il 38% dei professionisti IT segnala difficoltà nel monitorare lo stato delle patch.
Il 35% fatica a rispettare le tempistiche di remediation a causa di una visibilità incompleta sugli endpoint.

Quando le vulnerabilità rimangono aperte più a lungo del necessario, la finestra di esposizione aumenta. Gli aggressori non aspettano. Il catalogo CISA KEV rivela una verità difficile da ignorare: il 30% delle vulnerabilità attualmente sfruttate attivamente è stato inizialmente divulgato più di cinque anni fa.

Questo non è un problema di patching; è un problema di visibilità. Le organizzazioni non stanno ignorando le patch disponibili; non individuano gli endpoint che ne hanno ancora bisogno.

Finestre di esposizione prolungate e rischio di violazione

La frammentazione estende le finestre di esposizione in modi poco evidenti. I dispositivi mai registrati nelle piattaforme di gestione, come il BYOD shadow, i dispositivi non protetti degli appaltatori o gli endpoint remoti al di fuori del perimetro tradizionale, spesso passano inosservati.

Una ricerca di Ivanti mostra che solo un datore di lavoro su tre ha implementato l’accesso di rete zero trust per i lavoratori da remoto, lasciando lacune significative nella visibilità degli ambienti distribuiti. Gli endpoint scoperti di recente compaiono dopo la generazione dei report sulle patch. I sistemi escono dalla conformità tra un ciclo di scansione e l’altro. Ogni ritardo amplifica il rischio, estendendo il tempo a disposizione degli aggressori per trasformare vulnerabilità note in armi.

Problemi comuni post-patch e sovraccarico dei ticket IT

Anche quando le patch vengono distribuite nei tempi previsti, il patching manuale spesso crea problemi a valle. Aggiornamenti non riusciti, agenti malfunzionanti, problemi di prestazioni e riavvii imprevisti generano ticket di supporto e interventi di emergenza. Ciò che nasce come attività di sicurezza si trasforma rapidamente in un onere operativo.

I team IT dedicano tempo a risolvere guasti prevedibili invece di migliorare la postura degli endpoint. I team di sicurezza vedono i ritardi come rischi non risolti. Gli utenti associano il patching a interruzioni. Questo attrito persiste tra i team, anche quando i loro obiettivi sono allineati.

Trasformare la gestione delle patch con la gestione autonoma degli endpoint

AI e automazione affrontano le disconnessioni fondamentali nella gestione delle patch unificando la visibilità e riducendo il coordinamento manuale. Quando individuazione degli endpoint, dati sulle vulnerabilità, integrità dei dispositivi e stato delle patch vengono correlati in una vista unificata, i team IT e di sicurezza possono lavorare sugli stessi fatti invece di riconciliare dati parziali tra strumenti diversi.

Gestione autonoma degli endpoint (AEM) porta chiarezza nella complessità utilizzando intelligence basata sull’AI e automazione per offrire a IT e sicurezza una vista unica e aggiornata continuamente degli endpoint, della loro integrità e della loro esposizione.

Come l’AI migliora le decisioni di patching

L’AI migliora le decisioni di patching assegnando priorità alle vulnerabilità in base al rischio reale, non solo ai punteggi di gravità. Tenendo conto dell’attività di exploit, della criticità degli asset e del contesto di esposizione, i team possono allinearsi su cosa correggere per primo e concentrare gli sforzi dove ridurranno il rischio più rapidamente.

Con la gestione autonoma degli endpoint, lo stesso scenario del lunedì mattina si svolge in modo diverso:

La vulnerabilità viene rilevata e l’AI la confronta immediatamente con un inventario unificato degli endpoint. Identifica 1.560 dispositivi che eseguono la versione vulnerabile, inclusi 217 dispositivi precedentemente non gestiti.

I workflow automatizzati per le patch eseguono simultaneamente queste attività: registrano i dispositivi non gestiti e assegnano priorità al patching in base al rischio di esposizione e alla criticità degli asset. Quindi pianificano la distribuzione durante le finestre di utilizzo ridotto e avviano il rollout per anelli.

Quando il team di sicurezza invia l’avviso, l’IT dispone già di una dashboard in tempo reale che mostra la remediation in corso — con lo stesso conteggio dei dispositivi, gli stessi dati di esposizione e la stessa logica di prioritizzazione. Nessuna riconciliazione necessaria.

Come l’automazione accelera la remediation

L’automazione trasforma quindi queste decisioni in azione. I workflow delle patch possono essere orchestrati end-to-end: identificazione dei dispositivi interessati, distribuzione degli aggiornamenti e convalida della remediation senza interventi manuali continui.

La pianificazione intelligente delle patch basata sull’AI riduce al minimo l’impatto sugli utenti allineando le distribuzioni ai modelli di utilizzo dei dispositivi, alle finestre di manutenzione e ai vincoli operativi. I rollout per anelli consentono di convalidare le patch su gruppi più piccoli prima di una distribuzione più ampia, riducendo le interruzioni e accelerando la remediation. Il risultato è un patching più rapido, meno downtime e un processo più prevedibile per entrambi i team.

I workflow di autoriparazione rilevano e risolvono automaticamente problemi comuni, come il riavvio dei servizi, la reinstallazione degli agenti o la correzione di configurazioni errate. Questi workflow prevengono incidenti evitabili prima che si trasformino in ticket di supporto.

Dalle discussioni sui dati a un’intelligence unificata e a una visibilità condivisa

Le piattaforme basate sull’AI unificano la visibilità sugli endpoint correlando dati di individuazione, contesto delle vulnerabilità, integrità dei dispositivi e stato delle patch in un unico record endpoint, con registrazione e controlli di accesso che garantiscono che i dispositivi siano costantemente individuati e gestiti durante tutto il loro ciclo di vita. I team IT e di sicurezza vedono gli stessi dispositivi, la stessa esposizione e lo stesso stato di remediation in tempo reale.

Questa intelligence unificata elimina le discussioni su quali dati siano corretti e le sostituisce con un accordo sui rischi da affrontare per primi. Integrando la remediation in workflow endpoint più ampi, i team riducono lo sforzo manuale e mantengono risultati di patching coerenti su larga scala. Integrando la remediation in workflow endpoint più ampi, i team riducono lo sforzo manuale e mantengono risultati di patching coerenti su larga scala.

Responsabilità condivisa sulle patch: potenziare la collaborazione tra IT e sicurezza

AI e automazione migliorano la gestione delle patch solo quando sono associate a una responsabilità condivisa. Quando i team IT e di sicurezza operano sugli stessi dati endpoint e sugli stessi workflow di remediation, la responsabilità passa dalla difesa dei singoli report alla riduzione congiunta dell’esposizione.

Un processo di patching basato sui dati parte da obiettivi condivisi. Invece di misurare il successo in strumenti isolati, le organizzazioni allineano IT e sicurezza intorno a metriche comuni che riflettono il rischio reale e l’impatto operativo. Questa misurazione condivisa crea chiarezza sulle priorità ed elimina l’ambiguità sulla responsabilità.

Una collaborazione efficace dipende da metriche di cui entrambi i team si fidano e su cui agiscono insieme. I KPI comuni includono:

Tempo medio di remediation (MTTR): la rapidità con cui vengono risolte le vulnerabilità critiche
Tassi di conformità delle patch: su endpoint sia gestiti sia precedentemente non gestiti
Durata dell’esposizione: per quanto tempo le vulnerabilità ad alto rischio rimangono aperte
Visibilità sugli endpoint: percentuale di dispositivi completamente individuati e gestiti

Queste metriche spostano le conversazioni dal volume delle patch ai risultati misurati in termini di rischio e aiutano i team a concentrarsi sugli esiti anziché sulle attività.

La responsabilità congiunta richiede workflow che coprano l’intero ciclo di vita delle patch. Le piattaforme basate sull’AI supportano questo approccio automatizzando le attività di routine e facendo emergere le eccezioni che richiedono il giudizio umano.

I leader IT e della sicurezza definiscono criteri di controllo per l’automazione, inclusi soglie di approvazione, requisiti di test e vincoli di rollout. Entro questi limiti, l’automazione esegue la remediation in modo coerente e su larga scala, senza coordinamento manuale costante. Nel tempo, la fiducia nel processo aumenta, l’onere di coordinamento diminuisce e il patching diventa una responsabilità operativa collaborativa anziché un punto di attrito.

Visitate la nostra pagina delle soluzioni per scoprire come le soluzioni Ivanti per la gestione autonoma degli endpoint offrano ai team IT e di sicurezza la visibilità unificata di cui hanno bisogno per eliminare i silos di patching e chiudere più rapidamente le vulnerabilità.

Elimina i costi reali della documentazione cartacea

Thu, 26 Mar 2026 12:00:06 Z

Attestazione dello stato: esiste da decenni e serve a verificare l’integrità di qualsiasi cosa, dai beni materiali alle attrezzature pesanti, fino a una vasta gamma di asset intermedi. Nato come processo cartaceo, nel tempo è stato accompagnato da fotografie, timbri e firme.

Eppure, è difficile credere che, a un quarto del XXI secolo, con dispositivi mobili ormai onnipresenti, così tanti di questi processi continuino a rimanere su clipboard. E questa documentazione cartacea può impiegare ore, giorni o persino di più per passare dal punto di compilazione a un destinatario in grado di intervenire sulle informazioni riportate.

Anche nel migliore dei casi, un modulo di ispezione portato a mano dalla banchina di carico all’ufficio del responsabile di magazzino o a un addetto alla logistica richiederà alcuni minuti: minuti durante i quali l’oggetto della documentazione potrebbe aver cambiato custodia o persino aver lasciato la struttura per la tappa successiva nella supply chain.

Scopri i risparmi

Con i costi della supply chain in continuo aumento, dove possono i team operativi trovare risparmi passando da questi documenti cartacei ai moduli digitali?

Attestazione dello stato: Tempo e denaro si perdono quando merci danneggiate arrivano alla banchina di carico e, considerando che oltre il 10% di tutte le unità di carico presenta un certo grado di danno all’arrivo al centro di distribuzione, questi costi reali si accumulano rapidamente. Vale anche il contrario: evitare i chargeback documentando che prodotti/pallet sono stati consegnati in buone condizioni protegge l’integrità dello spedizioniere e riduce il rischio di resi fraudolenti in ogni fase della catena.

Ispezioni pre-viaggio: Eseguire un’ispezione pre-viaggio non è solo prudente, ma spesso obbligatorio. Tuttavia, il suo valore dipende dalle azioni intraprese a seguito dell’ispezione. Se l’ispezione cartacea viene esaminata solo dopo che il veicolo ha lasciato il piazzale, guasti costosi o controlli su strada potrebbero bloccare le consegne e, di conseguenza, i ricavi.

Controlli di sicurezza: Possono assumere molte forme: dall’ispezione del carrello elevatore o del transpallet all’inizio di un turno di lavoro, alla documentazione di infortuni o quasi incidenti. Sono essenziali per la sicurezza dei lavoratori e possono anche costituire documentazione obbligatoria che deve essere prontamente disponibile per eventuali audit.

Trasforma digitalmente l’esperienza (e i risparmi)

Quelli sopra riportati sono solo alcuni ambiti comuni in cui i team operativi traggono vantaggio dal passaggio ai moduli digitali. Alcuni, e mi riferisco alla documentazione di attestazione dello stato come esempio, offrono un’opportunità immediata per misurarne il valore in termini finanziari. Evitare i chargeback è un modo concreto per contribuire ai risultati economici.

In altri casi, il risparmio riguarda maggiormente l’evitare costi. Quando un’ispezione pre-viaggio identifica un rischio e tale rischio viene affrontato prima che il veicolo lasci la banchina, le merci vengono consegnate in tempo e si evitano multe (o conseguenze peggiori). Lo stesso vale per garantire che le attrezzature di lavoro siano in buone condizioni operative prima che un lavoratore sia esposto a un pericolo.

Dai un’occhiata a questa infografica (e condividila con il tuo team) per ulteriori conferme su come la digitalizzazione della documentazione consenta di ottenere risparmi. Quindi, valuta una consulenza di processo con il tuo partner Ivanti Wavelink per la supply chain per iniziare a utilizzare i moduli digitali. All’interno della piattaforma Velocity, i flussi di lavoro possono includere Velocity Forms come passaggio obbligatorio del processo, ad esempio imponendo la compilazione di una dichiarazione di attestazione dello stato, con foto incluse, come parte del processo di ispezione in ingresso quando le merci vengono scaricate dal camion sulla banchina di carico.

Colmare il divario tra il completamento della documentazione e l’azione sul documento è uno dei motivi principali per abbandonare la carta e passare ai moduli digitali. Le informazioni vengono indirizzate ai destinatari appropriati per la revisione in modo tempestivo, pertinente e operativo: un aspetto essenziale per controllare i costi nelle operazioni, quando ogni secondo conta.

Chi è responsabile della gestione degli endpoint? Definire la governance di sicurezza e IT

Thu, 05 Mar 2026 13:30:01 Z

La gestione degli endpoint è una delle aree più critiche, e più contese, della governance aziendale. Ogni organizzazione dipende dagli endpoint, ma molte faticano ancora a rispondere a una domanda fondamentale: a chi spetta davvero la responsabilità di questi dispositivi?

In molti ambienti, i team IT e di sicurezza sono entrambi convinti di agire correttamente, ma continuano a non capirsi fino in fondo. La sicurezza guarda uno scanner e vede 10.000 vulnerabilità critiche; l’IT guarda un report sulle patch e vede che tutto è stato distribuito. Hanno ragione entrambi, ma parlano linguaggi diversi.

Il risultato sono iniziative di remediation dei rischi bloccate, attriti sulle policy e frustrazione crescente. I team discutono su quali dati siano accurati invece di colmare le lacune. Quando la gestione degli endpoint è governata congiuntamente, con visibilità e responsabilità condivise, i team possono spostare l’attenzione dalla riconciliazione dei dati al miglioramento dell’esecuzione.

Con la crescita degli ambienti endpoint, anche la governance dipende dall’automazione. Le funzionalità basate sull’AI possono aiutare a normalizzare i dati tra strumenti isolati, individuare i dispositivi non gestiti e mettere in evidenza le lacune di visibilità degli asset, rendendo possibile una responsabilità condivisa senza affidarsi alla riconciliazione manuale.

Perché la responsabilità della gestione degli endpoint è importante

Gli endpoint sono il luogo in cui lavorano gli utenti, in cui si accede ai dati e in cui iniziano molti incidenti di sicurezza. Quando la responsabilità della gestione degli endpoint non è chiara, iniziano a comparire le prime fratture.

Il report Autonomous Endpoint Management Advantage di Ivanti mostra che queste lacune di visibilità sono diffuse e rilevanti. Poco più della metà delle organizzazioni dichiara di utilizzare soluzioni di gestione degli endpoint che offrono visibilità centralizzata, il che significa che molti team faticano ancora a vedere l’intero panorama dei dispositivi. Questi punti ciechi vanno oltre i dispositivi IT non gestiti.

Il 45% dei professionisti della sicurezza e dell’IT indica lo shadow IT come una lacuna di dati chiave.
Il 41% segnala difficoltà nell’identificare le vulnerabilità.
Il 38% non è in grado di stabilire con affidabilità quali dispositivi accedano effettivamente alla rete.

La maggior parte delle organizzazioni crede di sapere cosa c’è sulla propria rete, finché non attiva un rilevamento adeguato. La realtà è che gli elenchi dei dispositivi sono di solito isolati: uno proviene dall’MDM, un altro dagli strumenti on-premise e un altro ancora dal provider di identità.

Di conseguenza, diventa difficile rispondere a domande di base: quali dispositivi sono completamente gestiti, quali sono conformi e quali possono accedere a risorse sensibili senza controlli.

L’automazione basata sull’AI può aiutare a correlare continuamente i dati degli endpoint tra gestione, identità e soluzioni di sicurezza degli endpoint, riducendo i punti ciechi che i processi manuali normalmente non individuano.

Ma la visibilità ha valore solo quando è condivisa e governata. Non è possibile proteggere, applicare patch o supportare ciò che non si vede. Senza una visione condivisa e affidabile e una chiara governance degli endpoint, anche gli sforzi ben intenzionati portano comunque ad attriti, ritardi e aumento del rischio. Ecco perché la gestione degli endpoint è, in ultima analisi, un problema di governance, non solo tecnico.

La sicurezza non è l’unico problema legato a questi punti ciechi. L’applicazione delle patch rallenta, il supporto si complica e l’applicazione delle policy viene compromessa. Quando i team IT e di sicurezza si basano su set di dati diversi, i disaccordi su rischio e remediation sono inevitabili.

Una responsabilità chiara cambia questa dinamica. Quando la gestione degli endpoint è governata congiuntamente, con visibilità e responsabilità condivise, le organizzazioni sono in una posizione migliore per passare dal dibattito sui dati alla chiusura delle lacune. La gestione degli endpoint diventa una base per applicare le policy in modo coerente, accelerare la remediation e migliorare la collaborazione tra i team.

Punti di attrito comuni tra team IT e di sicurezza

La maggior parte degli attriti tra IT e sicurezza non nasce da cattive intenzioni. Nasce dal disallineamento.

Anche la nostra ricerca sull’autonomous endpoint management suggerisce che questo disallineamento non è astratto: è misurabile e costoso. Abbiamo rilevato che:

Il 56% dei professionisti IT afferma che la spesa IT inefficiente è un problema.
E il 39% indica il supporto tecnologico inefficiente come un’area di spreco.

Quasi nove intervistati su dieci segnalano inoltre che i dati isolati hanno un impatto negativo sulle operazioni IT, causando un uso inefficiente delle risorse, una collaborazione ridotta e un rischio più elevato di non conformità.

Nella pratica, questo disallineamento tende a emergere in alcuni punti di attrito ricorrenti e costanti:

Strumenti frammentati

La frammentazione degli strumenti è un ostacolo importante. Molte organizzazioni gestiscono contemporaneamente un vecchio strumento client on-premise, un MDM separato per il mobile e una soluzione diversa per le patch. Il risultato è una proliferazione tecnologica che peggiora il problema.

Quando questa disconnessione si manifesta nella pratica, i team di sicurezza e IT spesso si affidano a strumenti e set di dati diversi per valutare gli stessi endpoint, arrivando a conclusioni molto diverse su rischio e stato della remediation.

L’analisi basata sull’AI può aggiungere contesto a questi set di dati, aiutando i team IT e di sicurezza a interpretare l’esposizione attraverso una prospettiva condivisa, anziché tramite report in competizione.

Impatto sugli utenti

L’impatto sugli utenti è un’altra fonte di tensione. I controlli sugli endpoint sono spesso percepiti come restrittivi e sollevano preoccupazioni su prestazioni, downtime o privacy, soprattutto sui dispositivi bring-your-own (BYOD). I team IT devono bilanciare l’applicazione dei controlli con l’esperienza utente, mentre la sicurezza spinge per controlli più rigorosi.

Vincoli di risorse

I vincoli di risorse rendono tutto più difficile. I team sono cauti nell’introdurre nuove piattaforme o policy che sembrano complesse o dirompenti, soprattutto quando sono già sotto pressione.

Senza una governance chiara, questi problemi portano ad applicazione incoerente, remediation bloccata e decisioni di policy non ufficiali. La gestione degli endpoint resta reattiva. La buona notizia è che il problema può essere risolto.

Bilanciare requisiti di sicurezza e flessibilità aziendale

Una delle sfide più difficili nella gestione degli endpoint è bilanciare sicurezza e flessibilità aziendale. I team di sicurezza vogliono controlli coerenti per ridurre il rischio. I leader aziendali vogliono interruzioni minime e la libertà di lavorare senza attriti. I team IT si trovano spesso nel mezzo.

Quando questo equilibrio non è definito chiaramente, le policy sugli endpoint diventano fonte di conflitto. Controlli rigorosi applicati indistintamente possono rallentare la produttività, frustrare gli utenti e incoraggiare soluzioni alternative. Troppa flessibilità, d’altra parte, aumenta l’esposizione e rende incoerente l’applicazione.

Il vero problema è che le organizzazioni non concordano in anticipo ciò che è obbligatorio e dove la flessibilità è accettabile. Senza questa chiarezza, le organizzazioni negoziano le decisioni di policy caso per caso e reagiscono agli incidenti invece di gestire il rischio in modo proattivo.

Una governance efficace degli endpoint riformula la conversazione. Definendo in anticipo i requisiti di base e allineandoli al rischio, le organizzazioni possono proteggere gli asset critici continuando a supportare diverse esigenze degli utenti e modelli operativi. Questo cambiamento consente a sicurezza e IT di passare da compromessi continui a un processo decisionale strutturato. È allora che la relazione cambia radicalmente, passando dall’attrito all’allineamento.

Chi dovrebbe essere responsabile della governance degli endpoint?

La governance degli endpoint non può essere affidata a un solo team. Richiede una responsabilità condivisa tra IT, sicurezza e business.

Nelle organizzazioni di successo, la governance degli endpoint è definita da un gruppo che include operation IT, sicurezza e stakeholder aziendali chiave. Questo gruppo definisce i diritti decisionali, concorda le priorità e stabilisce un framework di policy comune entro cui tutti operano.

La sicurezza porta il contesto del rischio e la consapevolezza delle minacce. L’IT porta competenze operative e considerazioni sull’impatto sugli utenti. I leader aziendali offrono una prospettiva su workflow, produttività e livelli accettabili di interruzione. Quando queste prospettive vengono allineate fin dall’inizio, le policy sugli endpoint sono più facili da applicare e meno inclini a essere aggirate.

La governance chiarisce le responsabilità. Risponde a domande come chi decide cosa è obbligatorio, come vengono gestite le eccezioni e come vengono risolti i conflitti. Con questa struttura, la gestione degli endpoint diventa un programma coordinato anziché una serie di decisioni isolate.

Definire priorità e tempistiche di remediation dei rischi

Una governance efficace degli endpoint dipende da un accordo chiaro su priorità di remediation dei rischi e tempistiche. Senza questo accordo, i team IT e di sicurezza spesso non si comprendono, dando priorità al volume invece di concentrarsi su ciò che conta davvero.

Il problema del patching è la definizione delle priorità, e la ricerca sull’autonomous endpoint management di Ivanti conferma che non si tratta solo di un problema teorico, ma di una sfida operativa misurabile:

Il 39% dei team IT fatica a dare priorità alla remediation dei rischi e alla distribuzione delle patch.
Il 38% ha difficoltà a monitorare lo stato e i rollout delle patch.
E il 35% fatica a mantenere la conformità nel patching.

Sono tutti risultati che derivano in larga misura da lacune di visibilità e strumenti incoerenti, rendendo più difficile focalizzare gli sforzi di remediation.

Gli approcci tradizionali si basano su punteggi CVSS e lunghi fogli di calcolo che non riflettono affatto il rischio reale. Il contesto conta: se un dispositivo è esposto a Internet, chi lo usa, quali dati tratta e quanto è probabile lo sfruttamento, con l’analisi basata sull’AI che aiuta i team a valutare continuamente quel contesto su larga scala.

La governance aiuta a trasformare la remediation da un esercizio guidato dal volume a un approccio basato sul rischio. Definendo in anticipo tempistiche di patching, percorsi di escalation e responsabilità, le organizzazioni possono allineare IT e sicurezza su priorità condivise. Invece di discutere su quali problemi affrontare per primi, i team possono concentrarsi sull’esecuzione.

Tempistiche chiare riducono gli attriti rendendo la remediation prevedibile anziché reattiva. Questa coerenza migliora la responsabilità, riduce le finestre di esposizione e rafforza la fiducia tra i team.

Elementi non negoziabili vs. aree di flessibilità

Uno dei risultati più importanti della governance degli endpoint è la chiarezza su ciò che è richiesto e su dove la flessibilità è consentita.

Gli elementi non negoziabili sono la base. Questo include la crittografia del disco, tempistiche specifiche di gestione delle patch e l’enrollment obbligatorio prima che un dispositivo possa accedere a dati sensibili. Definire questi controlli in anticipo elimina l’ambiguità e garantisce una postura di sicurezza coerente.

Le aree di flessibilità riconoscono che non tutti gli endpoint sono uguali. Team, ruoli e modelli operativi diversi possono richiedere policy personalizzate, soprattutto in ambienti con BYOD, contractor o lavoratori frontline. La governance definisce dove sono consentite le eccezioni, come vengono approvate e come viene gestito il rischio quando viene concessa flessibilità.

Senza questa distinzione, le organizzazioni finiscono per limitare eccessivamente gli utenti o consentire eccezioni incontrollate. Con questa distinzione, la gestione degli endpoint diventa al tempo stesso applicabile e adattabile.

I team di sicurezza sanno quali controlli non possono essere compromessi, mentre l’IT e il business mantengono la flessibilità necessaria per supportare la produttività. Questo equilibrio rende la governance degli endpoint applicabile e pratica.

Costruire fiducia attraverso dashboard condivise e trasparenza

Anche il miglior framework di governance degli endpoint si indebolisce senza visibilità condivisa. Quando i team IT e di sicurezza operano con dashboard e report diversi, la fiducia si erode e prendono piede decisioni non ufficiali.

Queste disconnessioni sono spesso radicate in pipeline di dati frammentate, in cui le informazioni sugli endpoint sono incomplete, obsolete o aggiornate in modo incoerente tra strumenti e sistemi. Le dashboard condivise cambiano questa dinamica solo quando sono basate su dati costantemente aggiornati e riconciliati. Autonomous Endpoint Management, basato sull’AI, contribuisce a renderlo possibile correlando automaticamente i segnali degli endpoint tra origini dati di discovery, conformità, vulnerabilità e remediation.

Quando entrambi i team si basano sugli stessi dati — inventario dei dispositivi, stato di conformità, esposizione alle vulnerabilità e avanzamento della remediation — le conversazioni si fondano sui fatti anziché sulle supposizioni. I disaccordi passano da “Quali dati sono corretti?” a “Quale problema dobbiamo affrontare ora?”

La trasparenza dei dati trasforma la cultura, passando dall’attribuzione delle colpe alla collaborazione tra IT e sicurezza. Invece di una sicurezza che afferma di aver trovato altri laptop non gestiti, la conversazione diventa: “Abbiamo una lacuna di visibilità: come la colmiamo?”

Metriche congiunte di IT e sicurezza, come tempo di discovery, percentuale di endpoint completamente gestiti e durata dell’esposizione, creano un linguaggio comune per il processo decisionale. L’automazione basata sull’AI aiuta a mantenere queste metriche accurate e aggiornate. Le dashboard condivise rafforzano la responsabilità.

Quando progressi e lacune sono visibili a tutti gli stakeholder, la governance degli endpoint smette di essere una discussione astratta sulle policy e diventa uno sforzo misurabile e collaborativo. È questa visibilità a trasformare la governance dall’intenzione all’esecuzione.

Misurare l’efficacia della governance degli endpoint

La governance degli endpoint funziona solo se le organizzazioni possono misurare se stia effettivamente riducendo il rischio e migliorando le operation. Senza KPI chiari e dati accessibili, la governance diventa rapidamente un esercizio di policy anziché una disciplina pratica.

Nella pratica, una misurazione efficace copre visibilità, rischio e performance operative.

Metriche di visibilità e copertura

Una misurazione efficace parte dalla visibilità. Queste metriche mostrano se gli endpoint sono governati nella pratica, non solo sulla carta.

Percentuale di endpoint completamente gestiti
Tempo necessario per individuare dispositivi nuovi o precedentemente sconosciuti
Numero e persistenza di endpoint non gestiti o sconosciuti

In questo ambito, l’automazione basata sull’AI supporta la misurazione continua monitorando nel tempo le tendenze di copertura e deriva delle policy, anziché affidarsi a report puntuali.

Metriche di rischio ed esposizione

Le metriche basate sul rischio aiutano i team ad andare oltre il volume e a concentrare la remediation su ciò che conta di più.

Tempo di esposizione per vulnerabilità critiche
Dispositivi con il rischio più elevato in base a contesto e accesso
Allineamento dell’attività di remediation alla sfruttabilità reale

Queste metriche aiutano i team IT e di sicurezza a dare priorità alle azioni con un chiaro impatto sul business, invece di inseguire soltanto conteggi di patch o percentuali di conformità.

Metriche di performance operativa

Le metriche operative indicano se la governance degli endpoint sta migliorando l’esecuzione quotidiana e l’esperienza utente.

Riduzione degli incidenti di sicurezza legati agli endpoint
Onboarding e offboarding più rapidi di utenti e dispositivi
Meno ticket di supporto legati a problemi di configurazione degli endpoint o di patching

Nel tempo, i miglioramenti di questi indicatori mostrano se automazione, self-healing e applicazione delle policy stanno generando valore misurabile.

I KPI della governance degli endpoint devono essere esaminati congiuntamente, con IT e sicurezza che guardano gli stessi dati e correggono la rotta quando necessario. Questo rafforza la responsabilità e consente il miglioramento continuo. Man mano che gli ambienti evolvono, anche policy, priorità e controlli dovrebbero evolvere con essi. La governance degli endpoint non è statica: è un processo continuo che si adatta al cambiamento di rischio, tecnologia ed esigenze aziendali.

Definire la responsabilità per scalare la gestione degli endpoint

La gestione degli endpoint non fallisce per mancanza di tecnologia. Fallisce quando la responsabilità non è chiara e la governance è frammentata.

Mentre gli endpoint continuano a diversificarsi e il lavoro diventa più distribuito, la questione di chi sia responsabile della gestione degli endpoint non può più restare ambigua. Sicurezza, IT e business hanno tutti un interesse diretto, e una governance efficace riunisce queste prospettive in un framework condiviso.

Quando le organizzazioni stabiliscono responsabilità chiare, definiscono gli elementi non negoziabili e operano da una visione condivisa degli endpoint, l’automazione basata sull’AI aiuta la gestione degli endpoint a passare dalla gestione reattiva delle emergenze alla riduzione proattiva del rischio. Dashboard condivise, tempistiche di remediation concordate e misurazione continua sostituiscono decisioni ad hoc e policy non ufficiali.

Il successo nasce dal trattare la gestione degli endpoint come un programma unificante, orientato prima di tutto all’automazione. Nella pratica, lo schema è chiaro: quando visibilità, responsabilità condivisa e governance convergono, gli endpoint passano da punto di attrito a fondamento di resilienza e collaborazione.

Trusted Ownership: come Ivanti Application Control va oltre l'allowlisting

Wed, 25 Feb 2026 14:25:15 Z

Il controllo applicazioni è uno di quei temi di sicurezza su cui molte persone conservano vecchie convinzioni. L'allowlisting tradizionale sembra sicuro, ma diventa rapidamente un onere di manutenzione. Il blocklisting appare reattivo e incompleto. E se strumenti come Microsoft AppLocker hanno portato molti a credere che un allowlisting rigoroso sia lo standard di riferimento, gli attacchi moderni hanno dimostrato il contrario. Gli attaccanti si affidano sempre più a strumenti legittimi e firmati — utilizzati nel contesto sbagliato — per aggirare completamente i controlli basati su elenchi.

Quando quindi le organizzazioni valutano Ivanti Application Control o Ivanti Neurons for App Control e incontrano Trusted Ownership, inizialmente potrebbe sembrare simile al blocklisting, perché sono possibili blocchi espliciti. In realtà, Trusted Ownership è un modello di applicazione molto più ampio e molto più leggero dal punto di vista operativo, ispirato alla provenienza, che controlla l'esecuzione in base all'origine, non solo all'identità.

Invece di gestire elenchi in continua crescita, applica la sicurezza in base a chi ha inserito il software nel sistema, allineandosi in modo naturale alle moderne pratiche di distribuzione del software e ai principi zero trust. È più corretto considerarlo non come un ulteriore meccanismo basato su elenchi, ma come un modello di applicazione ispirato alla provenienza che controlla l'esecuzione in base all'origine, non solo all'identità.

Questo cambio di prospettiva porta a una domanda più efficace per il controllo applicazioni moderno: non solo che cosa sia un file, ma come sia arrivato lì.

Oltre gli elenchi: perché il controllo della provenienza oggi è importante

La domanda su come un file sia arrivato sul sistema è al centro del controllo della provenienza. Invece di considerare attendibili i file solo in base a editore, percorso o hash, il controllo della provenienza valuta l'origine e il processo che li hanno introdotti. Chi ha scritto il file su disco? Attraverso quale meccanismo? L'installazione ha seguito un workflow IT controllato? Questa valutazione sposta il controllo applicazioni dalla fiducia nell'oggetto alla fiducia nel processo, creando un perimetro di sicurezza molto più solido.

In Ivanti Application Control, il controllo della provenienza viene implementato come Trusted Ownership. Qualsiasi file inserito da un proprietario attendibile viene consentito; qualsiasi elemento introdotto da un utente viene negato per impostazione predefinita. Questo vale in modo coerente per eseguibili, DLL, programmi di installazione e script. Poiché identità come SYSTEM, TrustedInstaller e Administrators sono attendibili per impostazione predefinita, il software distribuito tramite canali di deployment standard come MS Intune, MECM, Ivanti Endpoint Manager (EPM) o altri strumenti enterprise viene eseguito immediatamente, senza manutenzione delle regole o eccezioni.

Questo rappresenta una rottura fondamentale rispetto all'allowlisting classico. Le regole di AppLocker dipendono da definizioni esatte di editore, percorso o hash. Non valuta l'origine dell'installazione e non considera automaticamente attendibili i meccanismi di deployment. Il software distribuito da Intune richiede comunque una regola di autorizzazione preesistente, spesso basata su impostazioni predefinite ampie che consentono le directory Program Files o Windows.

Questa distinzione è importante perché gli attacchi moderni trasformano sempre più spesso strumenti legittimi in armi, usandoli in contesti impropri. Il controllo della provenienza neutralizza gran parte di questo rischio applicando la fiducia a come arriva il software, non solo a che cosa sia. Si allinea ai principi zero trust, riduce l'esposizione della supply chain e restringe drasticamente, per impostazione predefinita, le opportunità di abuso Living off the Land (LotL).

Una volta compresa l'importanza dell'origine, la domanda successiva diventa: come applicarla su larga scala?

La risposta: applicare la provenienza in modo coerente a tutti i modi in cui il software viene eseguito e a tutti i modi in cui viene distribuito.

Oltre le blocklist: una copertura ampia progettata per il deployment software moderno

Il controllo della provenienza sposta la sicurezza applicativa dalla gestione di elenchi interminabili alla convalida del processo con cui il software arriva sul sistema. Una volta adottata questa prospettiva, diventa chiaro che Trusted Ownership non è un approccio basato su blocklist. È un perimetro di fiducia basato sull'origine, che si comporta in modo molto diverso dall'allowlisting tradizionale.

Un equivoco comune è che Trusted Ownership assomigli al blocklisting perché gli amministratori a volte aggiungono regole di negazione mirate per strumenti Windows noti. In pratica, queste regole di negazione sono misure di hardening difensivo contro le tecniche Living off the Land. Ogni metodo serio di controllo applicazioni utilizza restrizioni mirate di questo tipo. Il nucleo di Trusted Ownership è l'opposto del blocklisting. Il software distribuito tramite un processo controllato e attendibile è consentito per impostazione predefinita, mentre il contenuto introdotto dall'utente è negato per impostazione predefinita.

Un elemento di differenziazione più importante è la copertura. Molte organizzazioni che si affidano agli allowlist classici finiscono per concentrarsi quasi esclusivamente sui file eseguibili. Spesso evitano di applicare lo stesso controllo a DLL, script e pacchetti MSI perché questi tipi di file rendono la manutenzione delle regole molto più complessa. Questo crea lacune che gli attaccanti moderni sfruttano di frequente.

Trusted Ownership evita queste lacune applicando lo stesso controllo basato sull'origine all'intera catena di esecuzione. Eseguibili, DLL, script, programmi di installazione MSI e componenti correlati vengono valutati attraverso lo stesso modello di fiducia. Poiché la fiducia è determinata da chi ha introdotto il file, non servono criteri separati per ogni tipo di file. Uno script nella cartella Download, una DLL creata in una directory di build temporanea o un EXE eseguito da un profilo utente ricevono tutti lo stesso trattamento di negazione predefinita quando hanno origine al di fuori di un processo di installazione controllato.

Questo modello di fiducia si allinea inoltre in modo naturale al modo in cui le moderne piattaforme di gestione degli endpoint distribuiscono il software. Soluzioni come Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager e sistemi simili installano in genere le applicazioni utilizzando l'identità SYSTEM o un altro account di servizio attendibile.

Poiché queste identità sono già Trusted Owner, il software distribuito tramite questi canali viene eseguito immediatamente senza creare regole di autorizzazione, mantenere percorsi file o aggiornare criteri. Solo quando si utilizzano intenzionalmente account di installazione alternativi, come agenti DevOps personalizzati o installazioni tramite script nel contesto utente, è necessario identificare tale identità come Trusted Owner.

Il risultato è un modello con una copertura ampia e coerente su tutti i tipi di file rilevanti. Funziona senza interruzioni con le moderne distribuzioni software ed evita l'overhead operativo associato agli allowlist classici, che si concentrano principalmente sui file eseguibili.

Trusted Ownership colloca la fiducia non nei singoli oggetti, ma nei processi controllati attraverso cui il software viene distribuito, creando un approccio al controllo applicazioni più scalabile e più sicuro.

Il ruolo di WDAC (App Control for Business)

Microsoft mantiene due tecnologie di controllo applicazioni: AppLocker e App Control for Business (in precedenza WDAC). Sebbene entrambe esistano ancora, Microsoft è chiara sui rispettivi ruoli. AppLocker aiuta a impedire agli utenti di eseguire applicazioni non approvate, ma non soddisfa i criteri di manutenzione per le funzionalità di sicurezza moderne ed è quindi classificato come meccanismo di difesa in profondità piuttosto che come controllo di sicurezza strategico.

La direzione futura di Microsoft per il controllo applicazioni è App Control for Business e Microsoft afferma esplicitamente che AppLocker è feature-complete e non è più in sviluppo attivo, oltre agli aggiornamenti di sicurezza essenziali. Ciò significa che tutte le nuove funzionalità vengono fornite solo in WDAC e non in AppLocker.

App Control for Business introduce il concetto di Managed Installer. Questo consente a Windows di considerare automaticamente attendibili le applicazioni installate tramite piattaforme di deployment designate, come Intune o MECM. La fiducia deriva dal canale di distribuzione anziché dai singoli file, riducendo in modo significativo la manutenzione delle regole.

Questo si allinea strettamente al modello Trusted Ownership di Ivanti Application Control. Entrambi gli approcci considerano attendibile il software in base al processo controllato che lo ha installato, anziché in base ad attributi discreti dei file. Tuttavia, Trusted Ownership applica questo concetto in modo più semplice e più accessibile dal punto di vista operativo. Ivanti considera attendibili identità come SYSTEM e gli account di servizio designati, senza richiedere livelli di policy complessi, definizioni XML o competenze approfondite su WDAC.

Ivanti sente da molte organizzazioni che l'operatività di WDAC è complessa. I criteri WDAC richiedono una progettazione attenta, test prolungati in modalità audit, gestione delle eccezioni per driver e kernel e manutenzione continua di più set di criteri. Questo spesso porta le organizzazioni a combinare WDAC con AppLocker per coprire sia l'applicazione a basso livello sia il controllo quotidiano dello spazio utente, finendo per generare overhead amministrativo.

Ivanti Application Control offre un'alternativa unificata. Attraverso Trusted Ownership, Trusted Vendors e la convalida delle firme digitali, fornisce un modello di negazione predefinita basato sulla provenienza, con copertura coerente su eseguibili, DLL, script e pacchetti MSI.

Invece di mantenere due piani di controllo Microsoft con ambiti diversi, le organizzazioni gestiscono un unico criterio semplificato che applica la fiducia in base a come il software viene introdotto nel sistema. Questo consente di raggiungere molti degli obiettivi pratici che i clienti cercano di ottenere con un deployment combinato di WDAC e AppLocker, ma con minore complessità operativa e un modello di fiducia coerente.

LOLBins e controllo a livello di argomenti

Una volta stabilita una copertura ampia, il tema diventa come gestire gli strumenti legittimi già presenti su ogni macchina, che gli attaccanti amano sfruttare.

Gli attaccanti moderni spesso evitano di utilizzare malware tradizionale e si affidano invece agli strumenti già presenti su ogni dispositivo Windows. Questi strumenti Living off the Land (LOLBins) sono legittimi e necessari per le normali operazioni, il che li rende difficili da bloccare senza incidere sulla produttività. L'allowlisting tradizionale fatica in questo contesto, perché blocchi troppo ampi interrompono i workflow, mentre autorizzazioni troppo ampie lasciano pericolose lacune.

Un modello basato sulla provenienza come Trusted Ownership cambia questa dinamica. Anche se un attaccante tenta di utilizzare uno strumento integrato, il contenuto che prova a eseguire di solito non proviene da un processo di installazione attendibile. Poiché Ivanti valuta l'origine di quel contenuto, la maggior parte dei tentativi di uso improprio fallisce automaticamente. Lo strumento può essere legittimo, ma il contenuto che gli viene chiesto di eseguire non lo è, e Trusted Ownership lo blocca prima dell'esecuzione.

È importante capire non solo quali strumenti vengono eseguiti, ma anche che cosa viene chiesto loro di fare. Molti interpreti e runtime, come PowerShell, Python o Java, possono essere perfettamente sicuri in un contesto e rischiosi in un altro. Un'applicazione aziendale può basarsi su Java per avviare un processo specifico e approvato, mentre un file JAR scaricato da un utente rappresenta uno scenario completamente diverso.

Ivanti gestisce questo aspetto con un approccio a livelli. Un file JAR viene prima valutato tramite Trusted Ownership, che lo blocca immediatamente se è stato introdotto da un utente anziché tramite un processo di deployment controllato. Oltre a questo, gli amministratori possono creare semplici regole di autorizzazione che specificano esattamente quali comandi Java sono consentiti, garantendo che vengano eseguite solo applicazioni basate su Java legittime, mentre i tentativi di avviare file JAR non approvati vengono negati in modo silenzioso.

Lo stesso principio si applica anche ad altri strumenti. I criteri possono approvare il comportamento esatto di cui l'organizzazione ha bisogno, bloccando al contempo le attività che escono da quei limiti. Questo evita regole ampie e fragili e mantiene fluido il lavoro quotidiano.

Il risultato è un approccio equilibrato e moderno. Trusted Ownership blocca per impostazione predefinita i contenuti non attendibili. L'hardening mirato si allinea alle best practice governative e della community per ridurre gli abusi living off the land, mentre i controlli consapevoli dell'intento assicurano che i processi legittimi continuino a funzionare senza aprire porte agli attaccanti.

Questo approccio è strettamente allineato alle attuali linee guida della community e degli enti governativi sulla mitigazione delle tecniche living off the land. Agenzie come CISA, NSA, FBI e l'Australian Cyber Security Centre sottolineano l'importanza di ridurre le opportunità per gli attaccanti di usare strumenti integrati, controllando come vengono utilizzati e limitando i contenuti non attendibili su cui operano. Le loro linee guida congiunte evidenziano che gli attacchi LOTL dipendono dall'abuso di strumenti nativi e sottolineano la necessità di controlli che limitino questo uso improprio senza bloccare i processi di sistema legittimi.

Il modello di Ivanti riflette queste linee guida. Trusted Ownership blocca automaticamente i contenuti non attendibili su cui gli attaccanti fanno affidamento, mentre un numero limitato di restrizioni mirate interviene sul piccolo insieme di strumenti che richiede particolare attenzione.

Trusted Ownership in azione: scenari reali

Ecco alcuni esempi operativi di come Ivanti Application Control e Trusted Ownership funzionano nella pratica.

Un'applicazione portatile viene copiata nel profilo utente. Ivanti la blocca perché è di proprietà dell'utente. AppLocker la blocca solo se esistono regole corrispondenti. Senza le regole di percorso o editore corrette, il comportamento può variare.
Un allegato email avvia uno script PowerShell dalla cartella Download. Ivanti lo nega a causa della proprietà utente. AppLocker dipende dalle regole sugli script e, in caso di eventi di blocco, forza PowerShell in Constrained Language Mode, che eseguirà comunque lo script.
Abuso di strumenti del sistema operativo come rundll32 o mshta. Entrambi i modelli richiedono un hardening di negazione mirato. Ivanti lo combina con il controllo della provenienza, che in genere riduce il numero di eccezioni necessarie. AppLocker si basa su set di negazione curati e richiede una regolazione periodica.
Un aggiornamento di un fornitore distribuisce nuovi file firmati. Ivanti consente l'aggiornamento quando arriva tramite il canale di deployment attendibile grazie a Trusted Ownership. AppLocker può gestire questo caso con regole basate sull'editore, ma il riutilizzo della firma su più prodotti o percorsi di installazione insoliti spesso comporta manutenzione aggiuntiva e una fiducia più ampia del previsto.
Un utente scarica un file JAR e tenta di eseguirlo con Java. Ivanti blocca il tentativo perché il JAR è introdotto dall'utente e non supera Trusted Ownership. Se necessario, gli amministratori possono consentire solo l'invocazione approvata esatta confrontando l'intera riga di comando. AppLocker non può confrontare gli argomenti e si basa su regole di editore, percorso o hash.

Conclusione

Il controllo della provenienza sposta il controllo applicazioni da un problema di gestione a un modello di fiducia. Invece di considerare attendibili i singoli file, considera attendibile il processo con cui il software arriva su un sistema, rendendo la sicurezza sia scalabile sia praticabile.

Trusted Ownership si inserisce pienamente in questo approccio. Non è né una blocklist né un allowlist classico, ma un modello in cui il software che arriva tramite un processo IT controllato è consentito per impostazione predefinita, mentre tutto ciò che resta fuori da quel processo viene negato per impostazione predefinita. Applicando i controlli sull'origine e sulla proprietà anziché su file ad hoc, Ivanti Application Control e Ivanti Neurons for App Control si allineano molto meglio alle tecniche di attacco moderne e all'attuale distribuzione del software.

Se si continua a trattare il controllo applicazioni come un esercizio di gestione degli elenchi, l'onere amministrativo si farà sentire. Se lo si considera come un perimetro di fiducia, si ottengono scalabilità, sicurezza e praticabilità operativa.

Come implementare un framework di governance dell'AI con guardrail sicuri, etici e affidabili

Tue, 24 Feb 2026 13:00:02 Z

Durante la mia esperienza in Ivanti, ho potuto constatare in prima persona come l'AI agisca da moltiplicatore di forza nelle organizzazioni aziendali. Se implementata in modo strategico, l'AI accelera il processo decisionale e l'esecuzione operativa su larga scala in una misura che i team semplicemente non possono sostenere manualmente. Tuttavia, senza guardrail AI chiari e applicabili, implementare l'AI espone le organizzazioni a nuovi rischi significativi.

Il report Ivanti State of Cybersecurity 2026 evidenzia un divario crescente che ho osservato in tutto il settore: l'ottimismo nei confronti dell'AI aumenta, ma governance e preparazione non tengono il passo. Attualmente, solo il 50% delle organizzazioni dichiara di avere guardrail formali per guidare l'implementazione e il funzionamento di sistemi e agenti AI.

Poiché l'adozione accelera più rapidamente della governance, vedo le organizzazioni affrontare rischi interni crescenti: uso di shadow AI, qualità dei dati incoerente, output distorti e formazione disomogenea dei dipendenti, solo per citarne alcuni.

Dal mio punto di osservazione, che abbraccia ambiti legali, di sicurezza e HR, posso affermare questo: la governance dell'AI non è un esercizio astratto di compliance. È un requisito fondamentale per fiducia, responsabilità e controllo.

Lo stato dell'AI aziendale: un Far West rischioso

Un'AI responsabile su larga scala richiede una governance intenzionale con guardrail applicabili a tutti i dipendenti. Ignorare questo aspetto farà continuare a crescere l'uso della shadow AI. Il nostro report di ricerca Technology at Work 2025 ha rivelato che il 46% degli impiegati utilizza strumenti di AI non forniti dal datore di lavoro. Ancora più preoccupante, quasi un terzo dei dipendenti (32%) nasconde ai propri datori di lavoro l'uso di strumenti di AI sul lavoro.

Troppe organizzazioni implementano l'AI senza una governance complessiva, e le conseguenze di questo approccio sono concrete. Le organizzazioni possono esporre dati sensibili. Possono violare obblighi normativi. Potrebbero potenzialmente erodere la fiducia del mercato. Un team implementa una piattaforma AI senza guardrail adeguati e, all'improvviso, si ritrova con output distorti o prestazioni degradate. Senza supervisione umana, i sistemi AI generano raccomandazioni inaccurate o attivano azioni inappropriate. Tutto questo crea una pericolosa falsa fiducia nei risultati guidati dall'AI.

Che cos'è un framework di governance dell'AI?

Un framework di governance dell'AI è il modello di riferimento per progettare, implementare e supervisionare i sistemi AI lungo tutto il loro ciclo di vita. Il suo scopo è allineare l'uso dell'AI agli obiettivi aziendali, agli obblighi legali e alla tolleranza al rischio dell'impresa, integrando trasparenza e responsabilità fin dal primo giorno.

In Ivanti, il nostro framework chiarisce:

Chi è responsabile delle decisioni e dei risultati dell'AI
Come vengono identificati i rischi, valutati e mitigati
Quali guardrail devono essere predisposti prima che i sistemi AI entrino in produzione
Come prestazioni, comportamento e impatto dell'AI vengono monitorati nel tempo

In pratica, la governance abilita la scalabilità. Framework chiari ci consentono di superare i progetti pilota frammentati e rendere operativa l'AI in tutta l'azienda. Senza governance, l'adozione si blocca.

La nostra posizione è semplice: la governance non blocca l'innovazione. La rende sostenibile.

3 livelli di guardrail AI in un framework di governance dell'AI

In qualità di membro dell'AI Governance Council di Ivanti, ho imparato che un framework completo richiede più livelli di guardrail. Ciascuno affronta una diversa categoria di rischio. Insieme, costituiscono la base per un uso sicuro e affidabile dell'AI.

Guardrail tecnici

I guardrail tecnici mantengono i sistemi AI entro parametri operativi e di sicurezza predefiniti.

Guardrail per i dati: i guardrail per i dati proteggono l'integrità dei dati e garantiscono che i sistemi AI siano addestrati e gestiti sulla base di input affidabili. Questi guardrail sono in genere di competenza dei team dati e sicurezza, che definiscono standard per l'origine dei dati, la convalida, i controlli degli accessi e il monitoraggio continuo della qualità. La scarsa qualità dei dati resta un ostacolo importante all'implementazione efficace dell'AI, in particolare nella sicurezza, dove dati incompleti, distorti o non convalidati possono alterare i risultati e degradare nel tempo l'accuratezza del rilevamento.

Guardrail per i modelli: i guardrail per i modelli affrontano robustezza, spiegabilità e rilevamento dei bias per garantire che i sistemi AI si comportino nel tempo come previsto. Questi guardrail sono in genere progettati dai team di sicurezza, data science e piattaforma, che definiscono i requisiti di test per drift, bias e degrado delle prestazioni prima dell'implementazione e in modo continuativo anche dopo, soprattutto quando i modelli vengono riaddestrati o esposti a dati operativi in evoluzione.

Guardrail per applicazioni e output: i guardrail per applicazioni e output convalidano gli output generati dall'AI, in particolare in scenari di supporto decisionale o risposta automatizzata. Questi guardrail sono in genere implementati dai team di sicurezza e operation, che definiscono soglie di approvazione, percorsi di escalation e controlli human-in-the-loop. Senza di essi, i sistemi possono generare raccomandazioni inaccurate o intraprendere azioni inappropriate, rafforzando una falsa fiducia nell'automazione.

Guardrail per l'infrastruttura: i guardrail per l'infrastruttura proteggono i sistemi che ospitano e supportano i workload AI e sono in genere di competenza dei team IT e sicurezza. Questi team applicano pratiche di implementazione sicura, controlli degli accessi, logging e auditabilità negli ambienti cloud e on-premise, garantendo al contempo che i servizi AI siano integrati nel monitoraggio della sicurezza esistente e nei flussi di lavoro di risposta agli incidenti.

Guardrail etici

I guardrail etici allineano il comportamento dell'AI agli standard dell'organizzazione e definiscono la responsabilità quando l'AI incide su persone, clienti o risultati aziendali.

L'AI Governance Council di Ivanti svolge qui un ruolo centrale. Affrontiamo le “aree grigie” degli agenti autonomi. Riuniamo leader legali, di sicurezza, HR e di business per definire uso accettabile, percorsi di escalation e responsabilità. Quando devono intervenire gli esseri umani? Come vengono sottoposte ad audit le decisioni? Chi è, in ultima analisi, responsabile dell'esito quando qualcosa va storto?

Quando questa governance manca, le conseguenze si aggravano rapidamente.

Incidenti recenti mostrano il costo di guardrail etici poco chiari. Ad esempio, Grok, un chatbot AI sviluppato da xAI, ha attirato critiche diffuse dopo aver generato immagini inappropriate di persone reali senza il loro consenso. Il fallimento non è stato solo tecnico: era legato alla governance, a causa di confini etici non sufficientemente definiti.

Lo stesso problema si presenta all'interno delle aziende. Quando l'AI blocca un account utente, segnala un dipendente o limita l'accesso di un cliente, dobbiamo sapere chi è responsabile della decisione se è sbagliata. Che l'AI venga utilizzata nella sicurezza, nelle risorse umane o nei sistemi rivolti ai clienti, i principi etici restano coerenti. La governance garantisce che la responsabilità sia definita prima che l'automazione provochi danni.

Guardrail normativi e legali

I guardrail normativi e legali garantiscono che l'uso dell'AI sia conforme alle normative globali in evoluzione, alle regole di settore e alle leggi sulla protezione dei dati. Poiché questi requisiti cambiano rapidamente, i team non possono operare in silos funzionali.

L'ufficio legale deve guidare la governance dell'AI fin dalle prime fasi. In Ivanti collaboriamo strettamente con i team sicurezza e IT per interpretare gli obblighi e tradurli in controlli applicabili. Il successo dipende dall'allineamento fin dall'inizio, per garantire che i requisiti di compliance siano integrati nella progettazione e nell'implementazione dell'AI.

Incidenti recenti dimostrano perché i guardrail normativi non possano essere considerati a posteriori. Le autorità di regolamentazione europee e britanniche hanno confermato che le attività di riconoscimento facciale di Clearview AI, basate sullo scraping di miliardi di immagini, erano soggette a leggi sulla privacy come il GDPR e hanno adottato azioni di enforcement sulla base delle violazioni, mostrando il rischio legale che le organizzazioni affrontano quando la governance non è allineata alle aspettative normative.

La lezione è chiara. I team legali e di sviluppo prodotto devono collaborare fin dalle prime fasi per integrare gli obblighi normativi nella progettazione, nell'implementazione e nelle operation dell'AI. La governance garantisce che i requisiti di compliance siano applicati per impostazione predefinita, non retroattivamente dopo l'avvio di controlli da parte delle autorità.

Governance dell'AI e gestione del rischio AI a confronto

Governance e gestione del rischio sono strettamente correlate ma distinte. Il mio punto di vista è questo: la governance stabilisce le regole e le strutture di responsabilità. La gestione del rischio si concentra sull'identificazione e sulla mitigazione di minacce specifiche legate all'AI lungo tutto il ciclo di vita del sistema.

I rischi AI più comuni includono perdita di dati, bias, output inaffidabili, eccessivo affidamento su decisioni automatizzate e debolezze di sicurezza introdotte da strumenti o integrazioni non gestiti. Man mano che i sistemi AI diventano più autonomi, questi rischi si sommano.

Integrare la mitigazione del rischio AI nella governance garantisce che i rischi non vengano affrontati in modo isolato. Li valutiamo insieme all'impatto sul business, alla resilienza operativa e alla propensione al rischio dell'organizzazione. Questo ci consente di dare priorità ai controlli dove contano di più ed evitare restrizioni generalizzate che rallentano i progressi senza ridurre il rischio.

Le sfide nella scalabilità della governance dell'AI

Molte organizzazioni iniziano con progetti pilota AI circoscritti a singoli team. Passare a un'adozione su scala aziendale introduce nuove sfide

I silos sono il modo più rapido per indebolire la governance. I team sicurezza, IT, legale e business operano spesso sulla base di presupposti in conflitto. Serve una responsabilità condivisa tra i team. Come spiega il mio collega Sterling Parker, una visione di successo richiede il coinvolgimento degli stakeholder di tutta l'azienda per prevenire la “proliferazione dell'AI”.

Questa transizione richiede un modello operativo incentrato sulle persone. Il nostro organismo di governance definisce chiaramente dove l'AI può amplificare i ruoli esistenti, dove è necessaria ulteriore formazione e dove la supervisione umana resta essenziale. Il feedback continuo dei dipendenti aiuta a garantire che l'AI venga applicata dove crea valore, senza generare lacune in termini di responsabilità o fiducia. Diamo priorità all'upskilling per sostituire la paura con un'adozione attiva.

La nostra ricerca sulla cybersicurezza mostra che le organizzazioni mature affrontano queste sfide in modo diverso. Le organizzazioni che si classificano come le più avanzate in cybersicurezza (Level 4) hanno quasi 3 volte più probabilità di utilizzare guardrail AI completi rispetto alle organizzazioni con un livello intermedio di maturità in cybersicurezza (Level 2).

Investono presto nella governance, allineano la leadership intorno a framework condivisi e trattano l'AI come una capacità strategica anziché come un insieme di strumenti. Queste organizzazioni hanno molte più probabilità di rendere operativa l'AI in tutta l'azienda mantenendo fiducia e controllo.

Come implementare un'AI responsabile

Costruire il framework è solo il punto di partenza. È nell'esecuzione che prende forma la governance dell'AI.

Iniziare con policy chiare su uso accettabile ed escalation. Devono essere pratiche e direttamente collegate alle strutture di rischio esistenti.

La governance deve essere accessibile. L'AI responsabile è un mandato esteso a tutta l'azienda, non un silo specialistico. Una formazione mirata garantisce che ogni utente comprenda il proprio ruolo nel mantenere questi guardrail.

Adottare un approccio governato all'abilitazione dell'AI. “L'abilitazione governata” presuppone che l'AI sia già in uso in tutta l'azienda e definisce dove e come possa operare in sicurezza. Richiede monitoraggio e applicazione continui per garantire che i sistemi restino allineati alle policy man mano che utilizzo e rischi evolvono. È una disciplina continuativa, non un progetto una tantum.

Il futuro dell'AI responsabile inizia ora

L'AI sta trasformando il modo in cui le organizzazioni operano a un ritmo che non può essere ignorato. La domanda non è più se adottarla, ma come scalarla in sicurezza. Le organizzazioni con una governance solida crescono senza sacrificare la fiducia. Quelle che rimandano ampliano il divario tra minacce e preparazione.

In Ivanti, ci impegniamo a costruire una governance dell'AI che abiliti l'innovazione proteggendo al contempo ciò che conta di più: le nostre persone, i nostri clienti e le nostre operation. È un lavoro fondamentale e il momento di agire è adesso.

Per saperne di più sul divario nell'implementazione dell'AI e su come le organizzazioni leader lo stiano colmando, consulta il report Ivanti State of Cybersecurity 2026.

Come i CEO vogliono che i CISO comunichino la strategia di gestione del rischio di cybersicurezza

Tue, 17 Feb 2026 13:00:01 Z

La maggior parte dei CEO sa citare i benchmark trimestrali e i ricavi fino all’ultima cifra decimale, ma se si chiede loro dell’esposizione al rischio cyber della propria organizzazione, le risposte diventano più vaghe. Non è che i CEO di oggi non si interessino alla sicurezza: la cybersicurezza è tra le principali preoccupazioni di consigli di amministrazione e team executive. Il problema è più profondo: una rottura fondamentale nel modo in cui i rischi di sicurezza vengono spiegati ai leader aziendali, che trascura il loro impatto sui risultati di business.

La maggior parte dei problemi di comunicazione tra CISO e CEO non dipende da una mancanza di competenza. Derivano da un problema noto: la maledizione della conoscenza. La maledizione della conoscenza è una sfida comune in cui gli esperti, in questo caso i responsabili della sicurezza, possono dare per scontato che tutti i presenti abbiano una comprensione di base delle informazioni e della terminologia tecnica; di conseguenza, non riescono a spiegare rischi complessi in un linguaggio semplice né a inserirli in un contesto concreto.

Il Report sullo stato della cybersicurezza 2026 di Ivanti evidenzia questa disconnessione. Quasi sei professionisti della sicurezza su dieci affermano che i loro team sono solo moderatamente efficaci nel comunicare l’esposizione al rischio alla leadership executive.

Quando CEO e CISO non parlano la stessa lingua, vulnerabilità aziendali critiche possono essere oscurate dal gergo tecnico. Quando la comunicazione si interrompe, le organizzazioni sprecano tempo e denaro in investimenti non correttamente indirizzati, mentre le lacune nella protezione passano inosservate finché una violazione non costringe ad affrontare il tema.

Con l’aumento dei livelli di minaccia, gli attacchi abilitati dall’AI diventano sempre più sofisticati e le violazioni dei dati finiscono ogni settimana sui giornali. La posta in gioco per una comunicazione chiara tra CISO e leadership executive non è mai stata così alta.

Per capire perché questo divario comunicativo persiste, dobbiamo esaminare sia le sfide fondamentali sia le metriche utilizzate per misurare il successo.

Perché la comunicazione del rischio cyber fallisce: la maledizione della conoscenza

Questa disconnessione tra CEO e CISO non è causata da una mancanza di dati. Semmai, è vero il contrario. Dal punto di vista del CEO, la sfida non riguarda l’attenzione o l’intenzione. Consiste piuttosto nel vedere dashboard, metriche, acronimi e punteggi di gravità senza comprendere l’impatto di questi risultati sull’intera azienda.

I responsabili della sicurezza devono partire dal presupposto che molti dei presenti non comprendano le implicazioni di termini come punteggi CVSS, superfici di attacco e vulnerabilità zero-day. I CEO vogliono più di dashboard piene di metriche, acronimi e punteggi di gravità.

I briefing sulla cybersicurezza devono fare un passo in più e dimostrare le implicazioni finanziarie, legali e reputazionali di questi risultati per l’azienda. Un CISO potrebbe riferire "587 vulnerabilità critiche rilevate questo mese", mentre ciò che il CEO deve davvero sapere è: "Quali di queste minacciano la nostra capacità di servire i clienti e qual è il nostro piano per affrontarle?"

I KPI di cybersicurezza che contano per i CEO

I KPI utili collegano chiaramente le attività di gestione delle vulnerabilità al rischio aziendale. Tuttavia, la nostra ricerca sulla cybersicurezza rileva che i KPI più utilizzati dai team di sicurezza non riescono a riflettere il contesto del rischio.

Attualmente, solo la metà delle aziende (51%) monitora i punteggi di esposizione alla cybersicurezza o altri indici basati sul rischio. Molti team di sicurezza si affidano ancora a metriche di processo, come il tempo medio di correzione (47%) o la percentuale di esposizioni risolte (41%).

Metriche come MTTR, velocità di applicazione delle patch e percentuale di correzioni effettuate sono importanti per i team di sicurezza, ma misurano l’efficienza operativa, non l’esposizione aziendale o il potenziale impatto finanziario. Considerate isolatamente, possono sembrare rassicuranti, pur oscurando la vera domanda: stiamo gestendo il nostro rischio in modo efficace?

Queste metriche, incentrate su rapidità e copertura, possono apparire positive da sole, ma dicono poco sul fatto che le attuali attività di correzione migliorino davvero la postura di rischio. Conta meno quanto rapidamente le vulnerabilità vengono corrette e quante ne vengono affrontate. Ciò che conta di più è se vengono affrontati i problemi giusti.

Una comprensione condivisa tra team di sicurezza, consiglio di amministrazione e C-Suite richiede di collegare metriche poco leggibili a conseguenze concrete. Per i CEO, questo significa allinearsi con il proprio CISO sui rischi più importanti per la specifica organizzazione: la vostra organizzazione è un istituto finanziario che affronta spesso schemi di frode sofisticati, rigorosi requisiti di conformità come PCI-DSS e SOX e la minaccia costante di ransomware che prendono di mira i dati finanziari dei clienti? Oppure un’organizzazione sanitaria alle prese con la protezione di una rete in espansione di dispositivi medici connessi, mantenendo al contempo rigorosi standard di conformità per proteggere i dati sensibili dei pazienti?

Illustriamo la differenza tra un briefing executive sulla sicurezza che si basa solo su metriche tecniche e uno che aggiunge contesto e impatto sul business.

Cosa dice il CISO:

"Abbiamo rilevato 11.000 vulnerabilità".
"L’MTTR è sceso da 25 a 15 giorni".
"Abbiamo raggiunto un tasso di correzione dell’88% sulle CVE critiche".

Cosa deve davvero sapere il CEO:

"Abbiamo identificato dieci vulnerabilità critiche che potrebbero avere un impatto sui sistemi che generano ricavi".
"Se venissimo attaccati oggi, potremmo ripristinare le operazioni critiche in sei ore, rispetto alle 48 ore dello scorso anno".
"Questa protezione ci consente di puntare all’espansione nell’UE senza ulteriori rischi di conformità".

Costruire un framework di propensione al rischio a livello executive

La comunicazione executive dipende da framework condivisi e da un punto di riferimento comune per definire, misurare e discutere il rischio. Per eliminare incoerenze e confusione, tutti gli stakeholder dovrebbero essere coinvolti nella creazione e nell’applicazione di un framework di propensione al rischio.

Uno degli obiettivi principali di queste conversazioni è aiutare i leader aziendali a comprendere che lo scopo del programma di cybersicurezza non è essere completamente “senza rischio”: è impossibile per qualsiasi organizzazione moderna diventare completamente priva di rischi. In altre parole, i CEO devono saper distinguere tra la loro propensione al rischio e la postura di rischio.

1. Propensione al rischio: il livello di rischio che l’azienda è attualmente disposta a tollerare nel perseguimento dei propri obiettivi generali.

2. Postura di rischio: la realtà dell’attuale esposizione al rischio dell’organizzazione.

La maggior parte delle organizzazioni riconosce ormai la necessità di formalizzare il livello di rischio cyber che è disposta ad accettare. La ricerca di Ivanti mostra che oltre l’80% delle organizzazioni dispone di un framework di propensione al rischio documentato.

Tuttavia, meno della metà delle organizzazioni afferma che questi framework vengono seguiti attentamente nelle operazioni quotidiane. Quando i framework esistono sulla carta ma non guidano le decisioni effettive, è molto probabile che la propensione al rischio e la postura di rischio della vostra organizzazione non siano allineate.

In che modo la gestione dell’esposizione colma il divario comunicativo

La gestione dell’esposizione è un approccio basato sul rischio che identifica, prioritizza e convalida in modo continuo la portata delle potenziali minacce nell’intera superficie di attacco. Praticare la gestione dell’esposizione aiuta a unire responsabili della sicurezza e leader executive attorno a una strategia unica e completa, che riorienta la cybersicurezza sul rischio critico per il business.

Invece di trattare tutte le vulnerabilità come equivalenti, la gestione dell’esposizione si concentra sull’identificazione e sulla prioritizzazione dei rischi più elevati per l’organizzazione ponendo queste domande:

Quali esposizioni attuali vengono sfruttate attivamente dagli attori delle minacce?
Quali asset devono essere prioritizzati in base alle attuali operazioni aziendali?
Quali asset, se compromessi, avrebbero il maggiore impatto in termini di danni reputazionali, per i clienti o legali?

Il report di ricerca di Ivanti mostra che quasi due terzi delle organizzazioni investono oggi nella gestione dell’esposizione e che la comprensione da parte della leadership è aumentata anno su anno. Ma l’esecuzione è ancora in ritardo: solo circa un quarto delle organizzazioni valuta come eccellente la propria capacità di valutare l’esposizione al rischio.

Per colmare questo divario e rendere operativa in modo efficace la gestione dell’esposizione, i CISO dovrebbero basare la comunicazione executive su tre principi

1. Tradurre i segnali tecnici in contesto aziendale. Invece di riportare il numero di vulnerabilità, spiegate quali esposizioni incidono sui sistemi che generano ricavi, sui dati dei clienti o sugli ambienti regolamentati.

2. Prioritizzare le minacce emergenti in base all’impatto, non al volume. Gli executive non devono monitorare ogni nuova tecnica di attacco. Devono capire quali situazioni potrebbero interrompere in modo significativo l’attività aziendale e quanto l’organizzazione sia pronta a rispondere.

3. Usare scenari, non fogli di calcolo. Narrazioni basate sui dati, che collegano causa, impatto e risultato, aiutano i leader a interiorizzare il rischio e a prendere decisioni più rapide.

Questo approccio sposta la strategia di mitigazione del rischio da una difesa reattiva a un processo decisionale proattivo.

La strada da seguire

Quando executive e responsabili della sicurezza parlano la stessa lingua, la maledizione della conoscenza può essere superata e la cybersicurezza diventa un abilitatore strategico che protegge il valore aziendale, favorisce la crescita e trasforma la forza della sicurezza in vantaggio competitivo.

La maledizione della conoscenza può essere superata: una metrica tradotta, una conversazione incentrata sul business e una decisione chiara alla volta.