Le linee guida di sicurezza AI di Ivanti hanno ridotto le ore, ma la sua skill Claude ha inventato dettagli

Ivanti ha rivelato che la propria skill di analisi delle patch basata su Claude ha inventato dettagli, pur riducendo un flusso di lavoro ricorrente da ore a minuti. Durante lo sviluppo, il sistema di linee guida per la sicurezza AI di Ivanti ha confuso le edizioni di Microsoft Office e ha ripetutamente interpretato in modo errato la cadenza dei rilasci di Adobe.

Questa ammissione è rilevante perché l'output aiuta i team di sicurezza a definire le priorità delle vulnerabilità dopo il Patch Tuesday mensile di Microsoft. Un'invenzione plausibile può alterare l'ordine in cui i sistemi ricevono attenzione, anche quando ogni vulnerabilità citata è reale.

Ivanti ha risposto introducendo un controllo di approvazione umana e ha identificato pubblicamente il ruolo di Claude in un grafico di giugno. Anche CrowdStrike e Palo Alto Networks mantengono persone coinvolte nell'automazione della sicurezza con conseguenze operative, ma nessuna delle due ha descritto pubblicamente di aver rilevato un'invenzione comparabile.

La vicenda è quindi più ampia di un singolo modello che commette errori. È una prova della disponibilità dei fornitori a rivelare come l'AI plasmi le indicazioni operative, cosa verifichino realmente i loro revisori e quali errori restino invisibili.

Le linee guida di sicurezza AI di Ivanti sono entrate in produzione dopo mesi di correzioni

Ivanti ha portato in produzione la propria skill Claude solo dopo che gli sviluppatori avevano ripetutamente individuato dettagli inventati o confusi durante l'addestramento.

Chris Goettl, vicepresidente della gestione prodotto per la sicurezza degli endpoint di Ivanti, ha costruito la skill attorno a un processo che aveva svolto manualmente per circa un decennio. Il sistema acquisisce avvisi pubblicati dai fornitori e fogli di calcolo di Ivanti, quindi applica il metodo aziendale di prioritizzazione del rischio di minaccia.

In questo contesto, una skill è un insieme riutilizzabile di istruzioni, fonti e regole di flusso di lavoro fornito a un modello AI. Non significa che il modello comprenda autonomamente il sistema di divulgazione di ogni fornitore.

Goettl ha addestrato il sistema un fornitore alla volta. Microsoft è arrivata per prima perché i suoi fogli di calcolo scaricabili offrivano input relativamente strutturati. Adobe ha richiesto un approccio diverso, poiché il modello doveva interpretare singole pagine e i loro layout mutevoli.

Quella differenza ha rivelato una debolezza importante. La skill produceva ripetutamente una cadenza di rilascio Adobe errata. Inoltre, confondeva le edizioni di Microsoft Office, che Microsoft separa in diverse famiglie di prodotti.

Non si trattava di difetti stilistici. La cadenza di rilascio e l'identità del prodotto influenzano il modo in cui gli analisti interpretano attività insolite, software interessato e urgenza delle patch. Un riepilogo curato con uno schema errato può comunque indirizzare un team nella direzione sbagliata.

Goettl ha descritto di aver confrontato il sistema quando una risposta appariva palesemente priva di fondamento. Secondo il suo resoconto nella pipeline assistita dall'AI, Claude ha riconosciuto che il materiale inventato non disponeva di una base verificabile tramite fonti.

Ivanti afferma che la skill utilizza solo avvisi pubblici dei fornitori e fogli di calcolo controllati dall'azienda. Non elabora dati dei clienti e ogni output generato resta una bozza finché una persona non lo approva.

Il senior product manager Todd Schell ha rieseguito il sistema su due mesi di briefing precedentemente preparati a mano. Ivanti ha riportato un allineamento del 98%, pur riconoscendo la presenza di casi limite residui.

Questa cifra richiede un'interpretazione prudente. VentureBeat non ha verificato in modo indipendente i dati di origine, il metodo di valutazione, la tassonomia degli errori o i risultati del riesame. L'allineamento non dimostra inoltre che ogni vulnerabilità pertinente sia comparsa nell'output generato.

La prima esecuzione in produzione si è verificata nell'agosto 2026 mentre Goettl era in vacanza. Un foglio di calcolo che in precedenza richiedeva circa quattro ore a ciascuno di due dipendenti sarebbe stato completato in meno di 30 minuti.

Il flusso di lavoro mensile più ampio aveva richiesto circa 48 ore complessive attorno a ogni Patch Tuesday. Ivanti ha stimato che tale impegno rappresentasse almeno il 5% del tempo di lavoro combinato di Goettl e Schell.

Il vantaggio operativo è facile da comprendere. Una macchina può raccogliere, normalizzare e ordinare un rilascio di grandi dimensioni più rapidamente di quanto due specialisti possano copiare manualmente i campi tra fogli di calcolo.

Tuttavia, Ivanti non ha rimosso lo specialista dal processo. L'azienda ha trasformato il compito dello specialista: dall'assemblare ogni riga al riesaminare una bozza prodotta dalla macchina.

Questa distinzione definisce il conflitto centrale. L'automazione fa risparmiare tempo riducendo la costruzione manuale, mentre indicazioni di sicurezza affidabili dipendono ancora dal giudizio umano e dalla verifica a livello di fonte.

Ivanti ha inoltre lasciato una divulgazione visibile prima che emergesse la vicenda più ampia. Il suo post sul Patch Tuesday di giugno identificava un grafico come generato con Claude usando prompt progettati dall'autore e il dataset di Goettl.

Nessuna normativa richiedeva quella didascalia. Nessuno standard industriale comune ne imponeva la formulazione. La divulgazione è rimasta pubblicamente disponibile per circa tre mesi prima di ricevere un esame più ampio.

Quella discreta didascalia è diventata significativa una volta noti gli errori di sviluppo. Collegava un artefatto generato dall'AI a un modello nominato, a un autore umano, a una data e a un dataset definito.

Si tratta di una trasparenza maggiore rispetto a una generica etichetta “assistita dall'AI”. Tuttavia, non rivela quali righe siano state controllate, come sia stata misurata la completezza o se i livelli di rischio pubblicati abbiano ricevuto una convalida indipendente.

Il problema dei dati del Patch Tuesday ha reso l'automazione attraente

La pressione immediata derivava da un processo di Patch Tuesday diventato più ampio, meno standardizzato e più dipendente dall'interpretazione di ciascun fornitore.

L'8 settembre 2026, Microsoft ha rilasciato quello che diversi ricercatori di sicurezza hanno descritto come il suo più grande Patch Tuesday. Eppure i totali pubblicati differivano in modo sostanziale tra le organizzazioni che analizzavano lo stesso rilascio.

Tenable ha contato 964 vulnerabilità, comprese 104 classificate come critiche e 860 come importanti. La sua analisi di settembre ha inoltre identificato due vulnerabilità sfruttate attivamente prima che le patch diventassero disponibili.

Ivanti ne ha contate 973. Senserva ne ha contate 1.169 perché ha mappato le vulnerabilità rispetto agli articoli della knowledge base anziché usare lo stesso metodo incentrato sugli avvisi adottato da altri tracker.

La differenza tra i totali di Tenable e Senserva era di 205 vulnerabilità. Tale divario superava il precedente record di Patch Tuesday citato da Ivanti, pari a 175 vulnerabilità nell'ottobre 2025.

Queste differenze non dimostrano che un modello AI abbia commesso un errore. Possono derivare da scelte legittime relative all'ambito, a voci duplicate, varianti di prodotto, confini degli avvisi e mappature della knowledge base.

Mostrano però perché un singolo totale mensile non possa essere trattato come un fatto neutrale. Ogni conteggio pubblicato riflette ora un metodo di analisi e una definizione di ciò che appartiene all'insieme.

Microsoft ha intensificato il problema quando ha smesso di presentare un unico elenco mensile consolidato di CVE nella propria Security Update Guide. Rapid7 ha documentato il cambiamento mentre preparava la sua revisione delle patch di luglio.

Ogni fornitore di sicurezza deve ora ricostruire il rilascio a partire dai dati disponibili di Microsoft. Questa ricostruzione può coinvolgere codice deterministico, analisi manuale, un modello AI o una combinazione di tutti e tre.

Un parser deterministico segue regole esplicite e produce lo stesso risultato quando riceve input identici. Un modello linguistico di grandi dimensioni può interpretare pagine incoerenti con maggiore flessibilità, ma può anche generare relazioni prive di fondamento.

Questo compromesso diventa particolarmente importante quando l'output non è solo un conteggio. I team di sicurezza necessitano di priorità basate su sfruttamento attivo, divulgazione pubblica, gravità, esposizione degli asset e rilevanza aziendale.

Un conteggio errato può confondere la reportistica. Una priorità errata può deviare una capacità di applicazione delle patch limitata da una minaccia che gli aggressori stanno già sfruttando.

Secondo quanto riferito, il briefing webinar di Ivanti raggiunge ogni mese tra 500 e 700 partecipanti. Non è detto che tali partecipanti copino direttamente in produzione ogni raccomandazione, ma il pubblico conferisce a ogni decisione di prioritizzazione una portata significativa.

Anche la pressione sui tempi è reale. I team di sicurezza non possono esaminare con calma quasi mille voci prima che gli aggressori agiscano.

CrowdStrike ha riferito che l'88% degli sfruttamenti osservati che coinvolgevano una proof of concept pubblica è iniziato entro 48 ore. Una proof of concept è codice o documentazione tecnica pubblicamente disponibile che dimostra come una vulnerabilità possa essere sfruttata.

I requisiti federali possono essere ancora più stringenti. La Binding Operational Directive 26-04 di CISA ha stabilito una finestra di tre giorni per la correzione delle vulnerabilità a più alto rischio presso le agenzie civili federali.

In queste condizioni, i fornitori hanno un forte incentivo ad automatizzare la raccolta e la classificazione preliminare. Attendere una revisione manuale perfetta può di per sé creare rischi.

Il problema non è se le organizzazioni debbano utilizzare l'AI. È se possano dimostrare che l'accelerazione non abbia omesso vulnerabilità critiche, corrotto le mappature dei prodotti o elevato segnali deboli.

L'esperienza di Ivanti mostra perché questa prova non possa derivare dalla sola fluidità espositiva. L'output errato del modello appariva abbastanza convincente da richiedere il riconoscimento di un esperto e un confronto diretto.

Gli acquirenti di soluzioni di sicurezza subiscono quindi pressioni da entrambi i lati. Hanno bisogno di indicazioni più rapide, ma non possono presumere che un briefing più veloce e ben scritto contenga un insieme completo o accuratamente prioritizzato.

Il vero cambiamento è la divulgazione, non l'invenzione

L'aspetto sorprendente non è che Claude abbia inventato dettagli; è che Ivanti abbia descritto gli errori e mantenuto un controllo umano visibile.

I modelli linguistici di grandi dimensioni generano testo prevedendo sequenze probabili a partire dal loro addestramento e dal contesto fornito. Non garantiscono intrinsecamente che ogni affermazione corrisponda a una fonte fornita.

L'invenzione, spesso chiamata allucinazione, si verifica quando un modello presenta informazioni prive di fondamento come se fossero basate su fonti. In questo flusso di lavoro, l'errore si è manifestato come schemi errati dei fornitori e famiglie software confuse.

Queste debolezze sono già note nei sistemi AI di uso generale. Ciò che aumenta la posta in gioco è il loro inserimento in una pipeline che produce raccomandazioni di sicurezza.

Un errore di un chatbot per consumatori può far perdere tempo a un lettore. Una riga relativa a una vulnerabilità mancante nelle indicazioni operative può ritardare la correzione su un sistema esposto.

La divulgazione di Ivanti non ha eliminato quel rischio. Ha reso il rischio esaminabile.

L'azienda ha associato il nome di un modello e la responsabilità umana ad almeno un elemento grafico pubblicato. Goettl ha inoltre spiegato quali problemi sono emersi durante l'addestramento e perché il controllo di revisione sia rimasto necessario.

Quel livello di specificità aiuta i clienti a porre domande migliori. Possono distinguere la raccolta assistita dal modello dalla prioritizzazione autonoma e chiedere quale fase riceva una verifica umana.

L'ammissione complica anche i tradizionali messaggi sulla fiducia. I fornitori di solito sottolineano miglioramenti nella precisione, velocità di elaborazione o produttività degli analisti quando annunciano funzionalità AI.

Gli errori di sviluppo raramente ricevono la stessa attenzione. Questo squilibrio incoraggia gli acquirenti a valutare un flusso di lavoro in base al suo miglior benchmark anziché alle sue modalità di errore note.

L'allineamento del 98% riportato da Ivanti illustra il pericolo. Il numero sembra rassicurante, ma il suo significato pratico dipende da ciò che rientrava nella differenza restante.

Una discrepanza di formattazione irrilevante e una vulnerabilità sfruttata attivamente omessa non dovrebbero ricevere lo stesso peso. Una valutazione utile deve classificare gli errori in base alle conseguenze operative.

La completezza merita un’analisi distinta dalla correttezza. Un revisore può rilevare una gravità errata o una descrizione malformata in una riga visibile, ma non può facilmente accorgersi di una riga assente.

Questa è la sfida più netta alla narrazione della revisione umana. Leggere un output generato non equivale a riconciliarlo con un inventario autorevole delle fonti.

Kayne McGladrey, virtual chief information security officer indipendente e senior member IEEE, ha sostenuto che i clienti abbiano bisogno di una descrizione scritta della pipeline. Ha affermato che i fornitori dovrebbero spiegare dove opera il modello, come vengono analizzati i CVE, chi revisiona l’output e quale parte riceve una verifica rispetto alle fonti.

La sua critica andava oltre la richiesta di una firma umana. Un confronto con i mesi precedenti prodotti da esseri umani può misurare la somiglianza senza dimostrare la correttezza del mese corrente.

Un revisore umano può anche condividere il punto cieco del modello. Se entrambi si concentrano sulle voci visibili, nessuno dei due scoprirà un elemento scomparso prima dell’inizio della revisione.

Lo standard pertinente è quindi la tracciabilità. Ogni raccomandazione pubblicata dovrebbe essere collegata a un input autorevole, mentre per ogni input autorevole dovrebbe essere registrata una destinazione.

Questa seconda direzione è la più importante. Trasforma la revisione da “Questa bozza sembra ragionevole?” a “È possibile rendere conto di ogni elemento della fonte?”.

È qui che una disciplinata knowledge blending diventa rilevante oltre l’applicazione delle patch. Combinare le fonti è utile solo quando il flusso di lavoro preserva la provenienza e mette in evidenza i conflitti anziché appianarli.

La divulgazione di Ivanti offre un punto di partenza, non uno standard completo. Comunica agli acquirenti che l’AI ha partecipato e che le allucinazioni note hanno influenzato il processo di revisione.

Non stabilisce pubblicamente la genealogia a livello di riga, test indipendenti dei livelli di rischio, tassi di falsi negativi o la percentuale di materiale sorgente riconciliata automaticamente.

Tuttavia, l’ammissione esercita pressione sui concorrenti. Un fornitore che commercializza indicazioni di sicurezza assistite dall’AI senza descriverne la catena di validazione offre ora ai clienti meno informazioni di Ivanti.

Il ribaltamento è scomodo ma costruttivo. Riconoscere pubblicamente i fallimenti di un modello può diventare prova della maturità del processo, mentre il silenzio può nascondere controlli eccellenti oppure l’assenza totale di controlli.

La Revisione Umana Funziona Solo Quando Può Individuare le Prove Mancanti

Un revisore aggiunge valore solo quando il progetto della revisione prende di mira omissioni, affermazioni non supportate ed errori di classificazione ad alto impatto.

Il flusso di lavoro di Ivanti mantiene una persona tra la bozza di Claude e il briefing pubblicato. È più sicuro che consentire a un modello di pubblicare automaticamente la prioritizzazione.

Tuttavia, “human in the loop” è una descrizione progettuale, non una misurazione della qualità. La sua efficacia dipende da ciò che la persona vede, controlla e può bloccare.

Un revisore che esamina il testo può identificare formulazioni strane, un prodotto noto assegnato alla famiglia sbagliata o un modello di rilascio implausibile. L’esperienza di Goettl sembra aver individuato tali anomalie visibili durante l’addestramento.

Il fallimento più difficile è l’esclusione silenziosa. Se un parser o un modello non crea mai una riga per una vulnerabilità, un revisore che esamina soltanto il foglio di calcolo finale non riceve alcun avviso evidente.

Un sistema più solido necessita di controlli di riconciliazione esterni al modello linguistico. Verifiche deterministiche possono confrontare gli identificatori delle fonti, segnalare record non corrispondenti, rilevare CVE duplicati e contare gli elementi attesi per fornitore.

Il modello può quindi occuparsi delle attività che traggono beneficio dall’interpretazione. Potrebbe riassumere gli advisory, normalizzare descrizioni incoerenti o proporre categorie di rischio per l’approvazione di esperti.

Questa divisione assegna alle macchine responsabilità diverse. Il codice protegge completezza e ripetibilità, mentre il modello assiste con il linguaggio ambiguo e il contesto della prioritizzazione.

Crea inoltre segnali di fallimento più chiari. Una mancata corrispondenza nella riconciliazione può bloccare la pubblicazione anche quando la narrazione generata appare curata.

La validazione dei livelli di rischio richiede un rigore analogo. Il sistema dovrebbe registrare perché un elemento ha ricevuto quella classificazione, quali fatti della fonte hanno supportato la decisione e cosa è cambiato dopo la revisione umana.

Senza tale registrazione, un’approvazione finale stabilisce responsabilità ma offre prove limitate sulla qualità. Non può dimostrare se il revisore abbia esaminato ogni raccomandazione o si sia limitato a campionare le righe a rischio più elevato.

Ivanti afferma che i segnali relativi a exploit noti, divulgazione pubblica e volumi anomali attivano l’escalation. Si tratta di un insieme di regole sensato, ma le comunicazioni pubbliche non ne verificano indipendentemente l’applicazione.

I problemi relativi ad Adobe e Office mostrano anche perché sono importanti test specifici per fornitore. Un flusso di lavoro che funziona bene con i fogli di calcolo Microsoft può fallire quando un altro editore usa pagine web, convenzioni di denominazione diverse o calendari di rilascio irregolari.

La valutazione deve pertanto coprire ogni fonte di dati e ogni fase di trasformazione. Una media aggregata può nascondere un connettore debole per un fornitore sotto le buone prestazioni di Microsoft.

CrowdStrike ha descritto un diverso modello di revisione al Fal.Con 2026. Il suo approccio “human on the loop” vedrebbe un analista lavorare in parallelo sullo stesso rilevamento dell’agente, per poi confrontare i verdetti.

Il lavoro parallelo può mettere in luce disaccordi che una revisione sequenziale non coglie. Mantiene inoltre un maggiore impegno umano rispetto a un flusso di lavoro in cui una persona controlla una bozza già completata.

Palo Alto Networks ha introdotto Cortex XSIAM AgentiX nel febbraio 2026 con agenti preconfigurati e gate di approvazione per azioni ad alto impatto. Anche il suo agentic SOC design preserva il controllo umano quando le decisioni automatizzate comportano conseguenze maggiori.

Nessuno dei due modelli risolve automaticamente il problema degli input mancanti. Un umano e un agente possono entrambi ragionare partendo da un feed incompleto, mentre un gate di approvazione può autorizzare un’azione basata su prove difettose.

Il confronto rivela comunque un consenso emergente. I principali fornitori non considerano l’autonomia senza restrizioni un’impostazione predefinita accettabile per operazioni di sicurezza ad alto impatto.

Questo consenso conta perché il linguaggio del settore spesso confonde assistenza e autonomia. Un sistema che redige un briefing differisce sostanzialmente da uno che distribuisce una patch, isola un dispositivo o chiude un incidente.

Gli acquirenti dovrebbero associare ogni azione dell’AI alla sua reversibilità e al potenziale danno. I riepiloghi a basso impatto possono tollerare controlli più leggeri rispetto alle decisioni che modificano i sistemi di produzione.

Dovrebbero inoltre richiedere prove tratte da casi di fallimento reali. Un benchmark che riporta soltanto l’accordo nasconde se gli errori riguardavano formulazione, ambito, gravità o omissioni.

Le intercettazioni di allucinazioni note di Ivanti forniscono informazioni più utili di una semplice dichiarazione di accuratezza. Identificano condizioni concrete in cui il sistema è diventato inaffidabile.

La questione irrisolta è se i controlli di produzione rilevino nuove modalità di fallimento, non solo quelle scoperte durante l’addestramento. I siti dei fornitori cambiano, le tassonomie evolvono e rilasci insoliti possono invalidare le ipotesi di parsing di ieri.

La revisione umana resta necessaria, ma dovrebbe collocarsi all’interno di un sistema di controllo misurabile. Altrimenti, l’espressione può diventare una rassicurazione senza dimostrare che gli errori più pericolosi siano individuabili.

L’Ammissione di Ivanti Alza lo Standard per Ogni Fornitore di Sicurezza

I fornitori di sicurezza subiscono ora pressioni affinché rivelino non soltanto di utilizzare l’AI, ma esattamente in che modo essa influenzi le priorità rivolte ai clienti.

Ivanti non è sola nell’automatizzare l’analisi della sicurezza. CrowdStrike, Palo Alto Networks e altri fornitori stanno integrando modelli e agenti nei flussi di lavoro di rilevamento, indagine, triage e risposta.

La differenza competitiva emersa qui è la trasparenza. Ivanti ha nominato il proprio modello, descritto i suoi input, identificato modelli di allucinazione noti e spiegato che la pubblicazione richiede l’approvazione umana.

VentureBeat ha riportato di non aver trovato una divulgazione pubblica comparabile delle allucinazioni da parte di CrowdStrike o Palo Alto Networks. Tale assenza non dimostra che i loro sistemi abbiano fallito o che i loro controlli siano più deboli.

Significa che i clienti non dispongono di informazioni comparabili. Un fornitore ha esposto una parte della propria storia di fallimenti, mentre gli altri descrivono principalmente architettura e salvaguardie.

La divulgazione pubblica crea un difficile problema di incentivi. Un’azienda che segnala gli errori può sembrare meno affidabile di un concorrente che pubblica soltanto valutazioni di successo.

Gli acquisti nel settore della sicurezza possono invertire questo incentivo premiando le prove. Gli acquirenti possono porre a ogni fornitore le stesse domande e considerare le risposte mancanti come una lacuna di controllo irrisolta.

In primo luogo, i clienti dovrebbero chiedere quali artefatti siano generati dall’AI. La risposta dovrebbe distinguere raccolta, parsing, sintesi, valutazione, raccomandazione e azione automatizzata.

In secondo luogo, dovrebbero chiedere come viene verificata la completezza. Una risposta valida dovrebbe affrontare righe mancanti, record duplicati, modifiche alle fonti e acquisizione non riuscita.

In terzo luogo, dovrebbero chiedere chi revisiona il risultato e cosa copre quella revisione. Un ruolo di approvazione nominato è utile, ma una checklist documentata e una traccia di audit offrono una garanzia più solida.

In quarto luogo, dovrebbero richiedere categorie di errore anziché un’unica percentuale di accuratezza. Gli acquirenti devono sapere se i fallimenti incidono su grammatica, attribuzione del prodotto, stato dell’exploit, gravità o inclusione.

Queste richieste sono proporzionate alla decisione in gioco. I team responsabili delle patch usano la prioritizzazione perché non possono correggere ogni problema contemporaneamente.

Il rilascio di settembre dimostra il problema della scala. Tenable ha identificato 964 CVE, Ivanti ne ha identificati 973 e Senserva 1.169 con un diverso approccio di conteggio.

Un acquirente non ha necessariamente bisogno che ogni fornitore produca un numero identico. Ha però bisogno che ciascun fornitore spieghi il proprio ambito e riconcili le proprie raccomandazioni con tale ambito.

La stessa logica vale per i livelli di rischio. I fornitori possono ragionevolmente attribuire pesi diversi a sfruttabilità, esposizione e contesto aziendale, ma tali giudizi dovrebbero restare tracciabili.

La trasparenza protegge inoltre i fornitori da confronti ingiusti. Una metodologia documentata può mostrare che due totali differiscono per un ambito definito, non perché un sistema abbia perso silenziosamente dei dati.

La questione va oltre la cybersicurezza. Qualsiasi ricerca generata dall’AI, briefing di conformità, riepilogo finanziario o rapporto operativo può contenere omissioni plausibili che la revisione superficiale non rileverà.

La sicurezza rende il problema particolarmente visibile perché i CVE dispongono di identificatori e advisory autorevoli. Questa struttura offre ai fornitori un modo pratico per testare la completezza.

Le organizzazioni che lavorano con prove meno strutturate affrontano un compito più arduo. Hanno comunque bisogno di provenienza, rilevamento dei conflitti e trattamento esplicito del materiale mancante.

L’approccio di Ivanti è quindi degno di nota senza essere sufficiente. La sua divulgazione comunica ai clienti più di quanto farebbe il silenzio, mentre i controlli riportati lasciano ancora senza risposta importanti domande di verifica.

Il contesto storico di sicurezza dell’azienda rende il controllo particolarmente importante. I clienti che valutano le indicazioni sulle patch giudicheranno non soltanto l’efficienza del modello, ma anche la capacità di Ivanti di comunicare accuratamente il rischio.

Tale controllo dovrebbe rimanere basato sulle prove. La skill Claude discussa qui ha analizzato dati pubblici sulle patch e, secondo quanto riportato, non ha avuto accesso agli ambienti dei clienti.

Non era un agente di remediation autonomo. Produceva bozze per un briefing ricorrente, con una persona responsabile della pubblicazione.

Confondere queste categorie sovrastimerebbe l’evento. Minimizzare l’allucinazione perché “un umano l’ha controllata” sottostimerebbe la sfida di controllo.

La conclusione equilibrata si colloca tra questi estremi. Ivanti ha creato un processo sensibilmente più rapido, ha intercettato reali fallimenti del modello, ha divulgato il coinvolgimento dell’AI e ha mantenuto la revisione di esperti.

Non ha dimostrato pubblicamente che il proprio processo intercetti ogni vulnerabilità mancante o convalidi indipendentemente ogni decisione di priorità. È questo lo standard che i clienti dovrebbero ora chiedere a Ivanti e ai suoi concorrenti di soddisfare.

Tre Segnali Mostreranno se le Indicazioni AI sulle Patch Meriteranno Fiducia

Il prossimo test sarà verificare se i fornitori trasformano un’ampia supervisione umana in una validazione visibile, ripetibile e completa rispetto alle fonti.

Il primo segnale arriverà con il prossimo Patch Tuesday, il 13 ottobre 2026. Gli analisti dovrebbero confrontare i totali pubblicati, le definizioni dell’ambito, le etichette delle vulnerabilità già sfruttate e il trattamento dei dati insoliti dei fornitori.

Se l’output di Ivanti resterà rapido documentando al contempo con chiarezza le discrepanze tra le fonti, la sua tesi a favore dell’automazione supervisionata ne uscirà rafforzata. Un’omissione o un errore di mappatura non spiegato la indebolirebbe.

Il secondo segnale consiste in divulgazioni più dettagliate da parte di Ivanti o dei suoi concorrenti. Una documentazione utile indicherebbe dove operano i modelli, quali controlli deterministici proteggono la completezza e quali decisioni richiedono l’approvazione umana.

Queste informazioni rafforzerebbero l’argomentazione secondo cui la trasparenza può diventare uno standard competitivo. Il continuo ricorso a un linguaggio generico del tipo “human in the loop” lascerebbe irrisolta la lacuna centrale nella verifica.

Il terzo segnale è rappresentato dalle evidenze delle valutazioni in produzione. I fornitori dovrebbero riportare categorie di errore, copertura delle fonti, modifiche apportate dai revisori e falsi negativi ad alto impatto, senza esporre dettagli dei clienti sfruttabili da attaccanti.

Tali evidenze mostrerebbero se i sistemi migliorano dopo aver incontrato nuovi formati e casi limite. Il solo accordo aggregato non risponderebbe a questa domanda.

Il rapporto di CrowdStrike sullo sfruttamento rapido spiega perché questo lavoro non possa tornare interamente a un’elaborazione manuale. Le sue conclusioni sullo sfruttamento mostrano che i difensori operano spesso all’interno di una finestra di risposta sempre più ristretta.

L’esito corretto, quindi, non è meno automazione. È un’automazione le cui evidenze possano essere ispezionate prima che le sue raccomandazioni guidino persone o macchine.

Per i responsabili della sicurezza, la risposta pratica consiste nel censire ogni fonte esterna di indicazioni che utilizza l’AI. Occorre chiedersi se il modello conta, interpreta, classifica o agisce, perché ciascun ruolo crea un diverso percorso di errore.

Poi bisogna mettere alla prova l’affermazione del fornitore sulla revisione con una domanda difficile: come rileverebbe il processo una vulnerabilità che non è mai comparsa nella bozza generata?

Se la risposta dipende da una persona che nota qualcosa di assente, il controllo è incompleto. Se include la riconciliazione delle fonti, la gestione delle eccezioni e decisioni umane registrate, il flusso di lavoro è più credibile.

Le linee guida di sicurezza AI di Ivanti offrono ora un caso di studio pubblico per questa discussione. La sua skill Claude ha fatto risparmiare agli analisti molto tempo, ha inventato dettagli durante lo sviluppo e ha costretto l’azienda a progettare tenendo conto di questi fallimenti.

La divulgazione non dovrebbe meritare fiducia automatica, ma merita attenzione. Offre ai clienti debolezze concrete da esaminare e fornisce ai concorrenti un parametro di trasparenza che possono superare.

Prima di affidarsi al prossimo briefing di sicurezza assistito dall’AI, chiedete quale sia il ruolo del modello, come venga verificata la completezza delle fonti e quale sia il compito effettivo del revisore. Queste risposte riveleranno più di qualsiasi punteggio di accuratezza da titolo.