DM Web Solution — Oggi parliamo di…

Brotli e Node2Shell: la vulnerabilità nascosta nelle dipendenze aziendali

DM Web Solution — Thu, 05 Nov 2026 07:20:00 +0100

Una vulnerabilità nelle dipendenze

Un portale aziendale può funzionare perfettamente e contenere comunque un componente vulnerabile che nessuno ha inserito nell’inventario. È il problema delle dipendenze: librerie e moduli incorporati in applicazioni, piattaforme e servizi acquistati da terzi. Il caso Brotli offre un esempio concreto di quanto la sicurezza dipenda dalla conoscenza del software realmente in esecuzione.

Il fatto confermato è che il 27 ottobre 2026 CISA ha aggiunto CVE-2026-111497, relativa a Google Brotli, al catalogo Known Exploited Vulnerabilities, sulla base di evidenze di sfruttamento attivo. Questo conferma l’utilizzo della vulnerabilità in attacchi; non dimostra che una specifica azienda sia stata compromessa. [1]

Il progetto Node.js ha pubblicato il 21 ottobre aggiornamenti di sicurezza che includono la correzione del decoder Brotli. Secondo il bollettino del produttore, dati compressi appositamente costruiti possono provocare una scrittura oltre i limiti di un buffer quando vengono decompressi dall’applicazione. Le conseguenze possibili comprendono arresti del processo, divulgazione di memoria ed esecuzione di codice. L’esposizione dipende quindi anche dal percorso con cui il software riceve ed elabora quei dati. [2]

Dove utilizziamo questo componente?

Per un responsabile IT, la domanda iniziale dovrebbe essere molto concreta: dove utilizziamo questo componente? Limitarsi a cercare Node.js sui server censiti può lasciare fuori applicazioni distribuite in container, servizi gestiti da fornitori, strumenti interni e ambienti dimenticati. Anche un prodotto acquistato come soluzione completa può incorporare librerie che il cliente non amministra direttamente.

La nostra analisi operativa parte quindi dall’incrocio di tre inventari: servizi aziendali, software installato e dipendenze applicative. Per ogni applicazione occorre identificare un referente, l’ambiente di esecuzione e il soggetto che può modificarlo. Se queste informazioni mancano, la gestione della vulnerabilità rischia di fermarsi a uno scambio di email senza una decisione.

Una richiesta efficace al fornitore dovrebbe indicare la CVE e chiedere una risposta verificabile: il prodotto incorpora il componente interessato? Quali versioni sono coinvolte? La configurazione utilizzata permette di raggiungere la funzione vulnerabile? Quale aggiornamento o mitigazione viene raccomandato? Quando sarà completata la distribuzione? Una risposta generica come “il sistema è protetto dal firewall” non chiarisce questi aspetti.

Priorità e verifica della correzione

Consideriamo uno scenario ipotetico: un’impresa utilizza tre applicazioni con componenti potenzialmente coinvolti. La prima è un portale pubblico; la seconda opera soltanto nella rete interna; la terza è un ambiente di sviluppo spento. La presenza della stessa libreria non rende identica la priorità. Esposizione, raggiungibilità della funzione e impatto sul servizio devono guidare l’intervento, insieme alle evidenze disponibili.

La correzione richiede inoltre una verifica dell’ambiente effettivo. Aggiornare un pacchetto sul server non dimostra che ogni applicazione abbia smesso di usare la copia precedente. Conviene controllare il processo in esecuzione, la versione distribuita, le immagini applicative utilizzate e gli eventuali ambienti secondari. Il ticket dovrebbe raccogliere queste evidenze, oltre all’esito dei test funzionali.

Se l’aggiornamento immediato non è possibile, serve una misura temporanea specifica e verificata. Il Canadian Centre for Cyber Security raccomanda, tra le possibili azioni, di impedire alle applicazioni interessate di elaborare contenuti Brotli provenienti da fonti non attendibili fino all’applicazione della correzione. La misura deve essere valutata sulla propria architettura e sulle indicazioni del produttore. [3]

Dalla patch al risultato dimostrabile

Un intervento proporzionato dovrebbe prevedere anche la conservazione dei log utili e la valutazione di eventuali anomalie precedenti alla correzione. Arresti insoliti, comportamenti inattesi dei processi o connessioni anomale meritano un approfondimento, senza considerarli automaticamente una prova di attacco. La patch riduce l’esposizione futura; l’analisi degli eventi aiuta a comprendere ciò che potrebbe essere già accaduto.

Per chiudere il lavoro, la direzione dovrebbe ricevere un quadro leggibile: servizi verificati, sistemi coinvolti, correzioni completate, eccezioni ancora aperte e relative scadenze. La lezione aziendale del caso Brotli riguarda soprattutto questa capacità: passare rapidamente dal nome di una vulnerabilità all’elenco dei servizi interessati, assegnare responsabilità precise e dimostrare il risultato dell’intervento.

Fonti

ISO 42001: imparare a valutare l’impatto dell’AI sulle persone

DM Web Solution — Thu, 05 Nov 2026 07:20:00 +0100

Dai risultati alle conseguenze sulle persone

Un progetto di intelligenza artificiale viene spesso presentato attraverso tre indicatori: tempo risparmiato, riduzione dei costi e qualità del risultato. Sono informazioni utili per decidere un investimento, ma lasciano aperta una domanda: quali conseguenze produce il sistema sulle persone che entrano nel processo? È una domanda che merita spazio nella formazione di chi propone, acquista e utilizza l’AI.

Il riferimento confermato è ISO/IEC 42001:2023, standard per i sistemi di gestione dell’intelligenza artificiale, applicabile alle organizzazioni che sviluppano, forniscono o utilizzano prodotti e servizi basati sull’AI. ISO ne presenta l’impostazione come un percorso strutturato di governo dei rischi e delle opportunità. [1]

A questo quadro si affianca ISO/IEC 42005:2025, pubblicata il 28 maggio 2025. Secondo le schede ufficiali ISO e IEC, la guida riguarda la valutazione degli impatti dei sistemi AI su persone e società, la documentazione delle valutazioni e il loro inserimento nel ciclo di vita e nella gestione aziendale. Non si tratta quindi di un nuovo standard pubblicato oggi. [2] [3]

Un laboratorio sul processo reale

La proposta formativa di DM Web Solution è dedicare un laboratorio a un caso d’uso reale, descritto senza informazioni personali superflue. Per esempio: un assistente suggerisce l’ordine con cui trattare le richieste dei clienti. Prima di discutere algoritmi e prestazioni, il gruppo ricostruisce il processo: chi invia le richieste, quali informazioni vengono utilizzate, chi legge il suggerimento e chi assume la decisione.

Il passaggio successivo consiste nel cambiare punto di osservazione. Per l’impresa, un errore può significare ritardo, costo o reclamo. Per il cliente, può significare attendere più a lungo per un’esigenza urgente. Per l’operatore, può significare dover spiegare una priorità che non comprende. Queste prospettive possono sovrapporsi, ma aiutano a individuare conseguenze che una valutazione soltanto economica potrebbe trascurare.

Durante l’esercitazione, i partecipanti descrivono scenari verificabili. Una richiesta scritta in modo poco chiaro viene sistematicamente penalizzata? La scarsità di informazioni viene interpretata come scarsa importanza? Il personale tende ad accettare il suggerimento per velocizzare il lavoro? L’obiettivo è formulare ipotesi da controllare, mantenendo distinta una possibilità ragionevole da un problema già osservato.

Dalle conseguenze alle misure

Il gruppo passa poi dalle conseguenze alle misure. Se il sistema può abbassare impropriamente una priorità, si può prevedere una revisione dei casi dubbi. Se il suggerimento è difficile da comprendere, l’interfaccia può mostrare gli elementi utilizzati. Se un dato essenziale manca, il processo può richiederne l’integrazione. Ogni misura deve indicare chi la attua e quale evidenza permette di valutarne l’efficacia.

Un punto delicato è la supervisione umana. Scrivere che “l’operatore controlla” lascia irrisolti molti aspetti: dispone del tempo necessario? Può modificare l’esito? Conosce i limiti del sistema? Sa come segnalare un comportamento ricorrente? Nel laboratorio conviene simulare una decisione contestata e verificare se il percorso di revisione funziona anche sotto pressione operativa.

La documentazione prodotta dovrebbe essere breve e riutilizzabile. Per ciascuno scenario possiamo registrare soggetti coinvolti, conseguenza possibile, evidenze disponibili, misura prevista, responsabile e condizione di riesame. Questa è una proposta di lavoro, non un modulo ufficiale ISO. Il vantaggio è poter aggiornare il ragionamento quando cambiano dati, popolazione interessata o utilizzo del sistema.

Valutare l’apprendimento e decidere

La verifica dell’apprendimento può consistere nella discussione di un caso nuovo. I partecipanti devono individuare chi potrebbe subire conseguenze, spiegare quali informazioni mancano e proporre una misura controllabile. Il docente valuta la qualità del ragionamento e la chiarezza delle responsabilità, evitando di premiare soltanto la familiarità con le sigle.

Per la direzione, il risultato utile è una decisione motivata sul caso d’uso: procedere con condizioni definite, modificare il processo oppure raccogliere ulteriori evidenze. La formazione diventa così parte del governo aziendale. Il suo valore si misura nella capacità delle persone di riconoscere un impatto, discuterlo con gli interlocutori corretti e trasformarlo in un’azione verificabile.

Fonti

L’assistente AI cita i documenti: ma la risposta è davvero corretta?

DM Web Solution — Thu, 05 Nov 2026 07:20:00 +0100

Una fonte da verificare

Un assistente AI risponde a una domanda sul regolamento aziendale e aggiunge il collegamento al documento. Per chi legge, la presenza della fonte è rassicurante. Il controllo successivo potrebbe però mostrare che il documento riguarda un’altra categoria di utenti, contiene una versione precedente della regola oppure non supporta una parte della risposta. La citazione permette una verifica; il suo semplice inserimento non la sostituisce.

Questo problema riguarda anche i sistemi basati su Retrieval-Augmented Generation, o RAG: prima vengono recuperati contenuti da un archivio, poi il modello li utilizza per comporre la risposta. Una revisione scientifica pubblicata il 16 giugno 2026 propone di valutare separatamente dimensioni come pertinenza del contesto, fedeltà alle fonti, correttezza, rilevanza della risposta e qualità delle citazioni. È un quadro di valutazione, non una garanzia universale sulle prestazioni. [1]

Partire dal processo aziendale

La nostra proposta operativa è iniziare il collaudo dal processo che l’azienda vuole migliorare. Un assistente che aiuta a trovare procedure interne richiede prove diverse da uno che prepara risposte commerciali. Il gruppo di lavoro dovrebbe specificare utenti, domande ammesse, documenti utilizzabili e conseguenze degli errori. Questo permette di scegliere controlli proporzionati, senza affidarsi soltanto all’impressione prodotta da una dimostrazione.

Consideriamo uno scenario ipotetico: il personale usa l’assistente per consultare le regole sulle trasferte. Nell’archivio sono presenti un regolamento corrente, una versione precedente e una comunicazione dedicata a una sola sede. La domanda “posso ottenere questo rimborso?” sembra semplice, ma richiede di riconoscere data, destinatari ed eventuali condizioni. Una risposta scorrevole può nascondere proprio queste distinzioni.

Tre controlli distinti

Il primo controllo riguarda la ricerca. L’assistente ha recuperato il passaggio pertinente della versione corretta? Se la risposta è negativa, conviene esaminare l’archivio prima di modificare il modello: titoli ambigui, metadati incompleti, documenti duplicati o sezioni separate dal loro contesto possono rendere difficile trovare l’informazione. La soluzione potrebbe essere una migliore gestione documentale.

Il secondo controllo riguarda l’interpretazione. Anche avendo a disposizione il testo corretto, il sistema potrebbe omettere un’eccezione, combinare regole incompatibili o aggiungere una spiegazione non documentata. Per ogni risposta, il collaudatore dovrebbe identificare le affermazioni decisive e controllare quali passaggi le sostengono. Una risposta lunga non dovrebbe ricevere un giudizio favorevole soltanto perché contiene molte informazioni.

Il terzo controllo riguarda la citazione. Il collegamento deve portare al documento utilizzato e, quando possibile, al punto rilevante. Occorre poi verificare che quella fonte sostenga davvero l’affermazione associata. Una citazione può essere formalmente valida e sostanzialmente inadeguata: per esempio, rimandare al regolamento corretto senza supportare l’importo dichiarato nella risposta.

Domande, indicatori e rilascio

Per avviare il progetto proponiamo un insieme di domande preparato dagli esperti del processo, con risposte attese e fonti di riferimento. Dovrebbe comprendere casi ordinari, eccezioni, domande ambigue e informazioni assenti. Alcune prove devono verificare la capacità di chiedere un chiarimento o dichiarare che i documenti disponibili non consentono una risposta. Il numero iniziale va scelto in funzione del rischio e delle risorse disponibili.

Gli indicatori dovrebbero rimanere distinti. Possiamo misurare quante domande ricevono una risposta corretta, quante citazioni sostengono effettivamente il contenuto e quante domande senza soluzione ottengono un’appropriata astensione. Tempo di risposta e costo sono altre dimensioni utili. Ridurre tutto a una percentuale unica renderebbe difficile capire se il problema si trova nella ricerca, nella generazione o nell’archivio.

Anche gli strumenti automatici di valutazione richiedono controllo. Se un modello giudica le risposte di un altro, il risultato è un supporto al lavoro, da confrontare con esempi revisionati da persone competenti. Le decisioni sui casi più delicati dovrebbero basarsi su evidenze comprensibili al responsabile del processo.

Prima del rilascio, l’azienda dovrebbe approvare criteri di accettazione e gestione delle anomalie. Dopo modifiche a modello, documenti o configurazione, va ripetuto un insieme stabile di prove. Il risultato atteso è un servizio di cui siano conosciuti comportamento e limiti: abbastanza affidabile per l’uso definito, verificabile quando risponde e capace di fermarsi quando manca una base documentale adeguata.

Fonti

«Devi aggiornare la passkey»: quando il falso helpdesk apre la porta al cloud aziendale

DM Web Solution — Wed, 04 Nov 2026 09:20:00 +0100

Quando la sicurezza diventa un’esca

«Buongiorno, siamo dell’assistenza informatica. Devi aggiornare subito l’accesso, altrimenti il tuo account verrà bloccato». È una richiesta credibile, soprattutto mentre l’azienda introduce nuovi strumenti di sicurezza. Proprio questa familiarità può trasformare una telefonata apparentemente ordinaria nell’inizio di un incidente.

Il 9 settembre 2026 Microsoft Security Research ha descritto intrusioni cloud osservate da maggio, nelle quali gli attaccanti usavano riferimenti a passkey e accesso unico per convincere le persone a seguire procedure fraudolente. Secondo Microsoft, l’esca poteva indirizzare verso pagine di phishing con intermediazione dell’autenticazione oppure verso flussi di autorizzazione tramite codice dispositivo. Il riferimento alle passkey era un pretesto: il rapporto non dimostra una compromissione del protocollo crittografico delle passkey. [1]

Proteggere l’intero ciclo di vita dell’account

Il punto tecnico confermato. Le linee guida NIST distinguono l’autenticazione resistente al phishing dai codici che l’utente può digitare su un sito contraffatto. Un codice temporaneo inserito manualmente non offre, da solo, quella resistenza. Occorre però distinguere la protezione del singolo accesso dalla sicurezza dell’intero ciclo di vita dell’account. [2]

La nostra analisi operativa parte da qui. Un’azienda dovrebbe verificare almeno quattro percorsi: accesso ordinario, registrazione di un nuovo autenticatore, recupero dell’account e assistenza agli utenti. Proteggere il primo lasciando ambigui gli altri significa conservare margini di manovra per l’ingegneria sociale.

Consideriamo uno scenario ipotetico. Un’impiegata riceve una chiamata durante la chiusura mensile. L’interlocutore conosce il nome del responsabile IT e cita una migrazione realmente in corso. Chiede di aprire un collegamento e completare una verifica. La pressione nasce dalla combinazione di urgenza, informazioni plausibili e timore di interrompere il lavoro. La risposta organizzativa deve rendere semplice interrompere quella sequenza.

Un’assistenza riconoscibile e verificabile

La prima misura proposta è un canale di assistenza riconoscibile. Ogni richiesta che modifica credenziali, metodi di autenticazione o autorizzazioni dovrebbe poter essere verificata aprendo autonomamente il portale aziendale o richiamando un numero già noto. Il recapito contenuto nel messaggio sospetto non dovrebbe diventare la fonte della verifica. Anche l’helpdesk deve conoscere questa regola e applicarla senza eccezioni informali.

La seconda misura riguarda la pianificazione delle migrazioni. Prima di introdurre passkey o nuovi sistemi di accesso, conviene comunicare tempi, schermate previste e azioni richieste. Un avviso utile spiega anche come riconoscere una richiesta anomala. «Stiamo migliorando la sicurezza» è troppo generico; «la registrazione avverrà dal portale interno e sarà associata a questa campagna» offre un riferimento controllabile.

La terza misura è una revisione tecnica dei percorsi alternativi. Per ogni applicazione critica, suggeriamo di registrare il metodo principale, le alternative consentite e chi può modificarle. Le eccezioni dovrebbero avere responsabile, motivazione e data di riesame. Un progetto pilota può coinvolgere prima amministratori, assistenza e un piccolo gruppo operativo, così da individuare problemi reali prima dell’estensione.

Monitoraggio, esercitazioni e indicatori

Occorre poi preparare il monitoraggio. La nostra proposta è collegare gli eventi di autenticazione con i cambiamenti dell’account e con gli accessi ai dati. Un’attività insolita acquista significato quando viene letta nella sua sequenza. Prima di acquistare nuovi strumenti, l’azienda dovrebbe sapere quali registri possiede, chi li consulta e quanto rapidamente può avviare un’indagine.

Anche la risposta va provata. In un’esercitazione interna si può simulare la segnalazione di una falsa telefonata, verificando chi prende in carico il caso, quali evidenze conserva e come coinvolge il responsabile della sicurezza. L’obiettivo proposto è misurare la capacità di riconoscere e contenere l’evento, senza trasformare la simulazione in una valutazione punitiva del dipendente.

Per la direzione, tre indicatori possono rendere concreto il progetto: copertura dei metodi resistenti al phishing sugli account prioritari, numero di eccezioni ancora aperte e tempo necessario a gestire una segnalazione. Sono indicatori suggeriti da DM Web Solution, da adattare all’organizzazione.

La decisione aziendale consiste quindi nel progettare insieme tecnologia e assistenza. Un accesso robusto, accompagnato da procedure comprensibili e verificabili, permette alle persone di lavorare con maggiore fiducia e offre al reparto IT una base migliore per riconoscere gli abusi.

Fonti

NIS2: dall’attestato alla prova pratica, come costruire competenze che servono davvero

DM Web Solution — Wed, 04 Nov 2026 09:20:00 +0100

Dalla partecipazione alla capacità operativa

Un’azienda può avere un registro presenze completo e scoprire, durante un incidente, che nessuno sa chi deve prendere la prima decisione. La distanza tra partecipazione e capacità operativa è il problema da affrontare quando si progetta la formazione sulla sicurezza informatica.

Il riferimento normativo va collocato correttamente. L’articolo 20 della direttiva NIS2 prevede formazione per i membri degli organi di gestione dei soggetti essenziali e importanti. In Italia, l’articolo 23 del decreto legislativo 138/2024 disciplina gli organi di amministrazione e direttivi, includendo la formazione e la promozione di un’offerta periodica coerente per i dipendenti. L’applicabilità va verificata rispetto alla singola organizzazione. [1] [2]

Sul versante delle competenze, ENISA ha pubblicato il 26 giugno 2025 una guida che collega gli obblighi NIS2 ai profili dell’European Cybersecurity Skills Framework. È un riferimento per ragionare su ruoli e capacità professionali; non è un nuovo obbligo formativo entrato in vigore oggi. [3]

Obiettivi diversi per responsabilità diverse

La proposta operativa di DM Web Solution è partire dalle decisioni che l’azienda deve saper prendere. La domanda iniziale diventa: “Che cosa deve riuscire a fare questa persona, nel proprio ruolo, dopo il percorso?”. Le ore di corso restano un dato utile, ma l’obiettivo deve descrivere un comportamento osservabile.

Per la direzione, proponiamo un modulo centrato su priorità, rischio e continuità. Un caso può richiedere di scegliere tra sospensione temporanea di un servizio e prosecuzione con misure compensative. Il risultato atteso è una decisione motivata, con responsabilità, informazioni mancanti e condizioni per il riesame. Lo scenario deve essere ipotetico e adattato ai servizi effettivamente erogati.

Per il personale tecnico, il percorso può concentrarsi sull’acquisizione delle prime evidenze, sull’escalation e sul coordinamento con i fornitori. Una prova utile consiste nel ricostruire la gestione di un accesso sospetto utilizzando registri predisposti per l’esercitazione. Il partecipante dovrebbe spiegare quali fatti conosce, quali verifiche propone e quali interventi richiedono autorizzazione.

Anche le funzioni amministrative hanno obiettivi specifici. Gli acquisti possono esercitarsi nel riconoscere un servizio informatico critico e nel coinvolgere chi valuta il rischio. Le risorse umane possono verificare il passaggio di informazioni necessario per attivare o revocare un accesso. I responsabili operativi possono provare a segnalare un disservizio descrivendone l’impatto sul lavoro.

Una matrice e criteri di valutazione chiari

Questa articolazione richiede una matrice essenziale. Suggeriamo cinque campi: ruolo, attività da svolgere, competenza richiesta, esercizio e prova del risultato. In una piccola struttura la stessa persona può coprire più ruoli; la matrice deve rendere visibili anche sovrapposizioni e dipendenze. Quando una competenza è esterna, occorre stabilire come viene attivata e chi ne valuta il contributo.

La valutazione dovrebbe combinare comprensione e applicazione. Un questionario può verificare termini e procedure; un caso guidato mostra come vengono usati. Per evitare giudizi arbitrari, suggeriamo criteri comunicati in anticipo: riconoscimento del problema, correttezza dell’escalation, qualità delle informazioni e rispetto delle autorizzazioni. Le carenze emerse devono generare un’attività di recupero proporzionata.

Un’esercitazione breve può coinvolgere più funzioni. Immaginiamo un fornitore che segnali un possibile incidente su un servizio utilizzato dall’azienda. L’IT raccoglie i dettagli tecnici, il responsabile operativo identifica le attività coinvolte, la direzione valuta le conseguenze e il referente competente verifica gli eventuali adempimenti. Non serve introdurre scadenze inventate: l’esercizio deve usare le procedure applicabili all’organizzazione.

Evidenze e miglioramento continuo

Le evidenze proposte sono semplici: programma, partecipanti, materiali utilizzati, risultati e azioni successive. Nei verbali conviene distinguere un errore individuale da un difetto della procedura. Se tutti cercano un recapito inesistente, la correzione riguarda prima di tutto l’organizzazione. Un corso successivo potrà verificare se il problema è stato effettivamente risolto.

Per misurare l’efficacia, suggeriamo di osservare la qualità delle segnalazioni, i tempi di attivazione dei referenti e la chiusura delle azioni correttive. Sono indicatori interni proposti, da interpretare insieme al contesto: una segnalazione più rapida è utile solo se contiene informazioni sufficienti.

Il piano formativo diventa così un ciclo: individuare una capacità necessaria, esercitarla, valutarla e correggere ciò che manca. Per l’impresa, il beneficio atteso è poter contare su persone che conoscono il proprio compito e sanno collaborare quando il normale funzionamento dei servizi viene messo alla prova.

Fonti

Un agente AI nel servizio clienti: quali permessi concedere prima di collegarlo al CRM

DM Web Solution — Wed, 04 Nov 2026 09:20:00 +0100

Il confine tra consultare e agire

Un agente AI può leggere una richiesta, cercare informazioni nel gestionale e preparare una risposta. Quando gli viene consentito anche di aggiornare dati o inviare comunicazioni, l’azienda deve decidere quali azioni affidargli e come verificarle. È una scelta di processo che accompagna quella tecnologica.

Nel 2026 il tema è stato affrontato da più fonti ufficiali. Il 5 febbraio NIST ha presentato un concept paper su identità e autorizzazione degli agenti software. Si tratta di un documento esplorativo per un possibile progetto, non di uno standard definitivo. NIST ha inoltre richiamato, nella richiesta di informazioni del 12 gennaio, rischi legati all’interazione tra modelli, dati e sistemi operativi. [1] [2]

Una guida australiana del settembre 2026 concentra l’attenzione sull’harness, l’insieme di componenti che collega modello, strumenti e ambiente di esecuzione. Il documento evidenzia il ruolo di permessi, approvazioni e controlli applicati intorno al modello. Sono indicazioni tecniche da valutare nel proprio contesto aziendale. [3]

Tre livelli di implementazione

La proposta applicativa che segue è della redazione. Consideriamo un servizio clienti che riceve richieste di aggiornamento delle anagrafiche. L’obiettivo iniziale potrebbe essere ridurre il tempo di preparazione della pratica mantenendo affidabile il controllo dei dati. Per valutarlo serve una misura di partenza: quanto tempo impiegano oggi gli operatori e quali errori devono correggere?

Il primo livello può limitarsi alla lettura. L’agente consulta una selezione di informazioni e presenta all’operatore i dati pertinenti, indicando da dove provengono. Il test deve verificare sia la qualità delle risposte sia il rispetto delle restrizioni: un utente non dovrebbe ottenere tramite l’agente informazioni alle quali il processo aziendale non gli consente di accedere.

Il secondo livello può produrre una proposta di aggiornamento. L’agente prepara i campi da modificare, evidenzia quelli incerti e allega il riferimento alla richiesta ricevuta. L’operatore vede il valore precedente e quello proposto. In questa fase suggeriamo di mantenere separati la preparazione della modifica e il comando che la rende effettiva.

Un terzo livello può consentire scritture limitate, dopo una valutazione dei risultati. La nostra proposta è partire da campi a impatto contenuto e con controlli espliciti. Dati di pagamento, variazioni contrattuali, esportazioni estese e comunicazioni esterne richiedono una decisione specifica sul processo. La semplice disponibilità tecnica di un connettore non costituisce una ragione sufficiente per abilitarne tutte le funzioni.

Identità, registri e contenuti ostili

Anche l’identità dell’agente deve essere progettata. Suggeriamo un’identità applicativa riconoscibile, con permessi documentati e un responsabile. Per ogni operazione dovrebbe essere possibile ricostruire quale richiesta l’ha originata, quale versione del sistema è stata usata e quale approvazione è intervenuta. I registri vanno progettati evitando di raccogliere dati sensibili superflui.

Un caso di prova riguarda i contenuti ricevuti dall’esterno. Immaginiamo una richiesta cliente che includa istruzioni per esportare l’elenco completo delle anagrafiche. È un esempio ipotetico di contenuto ostile. Il test deve verificare che quella frase resti materiale da trattare e non diventi un’autorizzazione a usare strumenti estranei al compito.

Per questo suggeriamo controlli anche nell’applicazione che esegue le operazioni. Il comando di aggiornamento può accettare soltanto campi consentiti, richiedere un identificativo valido e respingere richieste prive delle condizioni previste. Una spiegazione convincente generata dal modello non dovrebbe sostituire questi controlli. Il confine operativo deve restare verificabile anche quando la risposta linguistica appare corretta.

Misurare il beneficio e prevedere l’arresto

La valutazione economica dovrebbe includere l’intera pratica. Tempo di revisione, correzioni, gestione delle eccezioni e manutenzione possono modificare il beneficio apparente. Proponiamo di misurare il tempo totale per pratica corretta, la quota di proposte accettate senza modifiche e gli errori che raggiungono il sistema operativo. Le soglie di accettazione vanno fissate prima del pilota.

Serve infine una procedura di arresto. Il responsabile deve sapere come disabilitare le scritture, sospendere il collegamento e continuare il lavoro manualmente. Ogni modifica a modello, strumenti o permessi può richiedere una nuova verifica proporzionata all’impatto.

L’implementazione può così crescere attraverso passaggi osservabili: consultazione, proposta e azione circoscritta. Il risultato atteso è un servizio clienti che recupera tempo mantenendo chiari responsabilità e controlli. Il valore dell’agente emerge quando migliora una pratica misurabile e resta entro i limiti stabiliti dall’azienda.

Fonti

Attacchi ai congelatori: quando la cybersecurity entra nella catena del freddo

DM Web Solution — Tue, 03 Nov 2026 21:00:00 +0100

Che cosa sta succedendo

I congelatori di un supermercato sono anche un sistema digitale: sensori, controllori e piattaforme di telegestione permettono di sorvegliare temperature e intervenire a distanza. Gli attacchi segnalati in Europa in questi giorni mostrano che la compromissione di queste funzioni può interrompere un processo essenziale. Reuters ha riferito il 2 novembre episodi che hanno interessato punti vendita di diversi operatori, fra cui Ahold Delhaize, Colruyt, ICA e Coop. Non risulta stabilita un’attribuzione comune né che tutti gli incidenti siano collegati. [1]

In Italia, ANSA ha riportato il 3 novembre il caso di un esercizio a Silvi Marina: secondo il titolare, il valore impostato era arrivato a 150 °C, mentre la temperatura effettiva aveva raggiunto circa 40 °C. Sono due grandezze diverse: un comando anomalo non significa che l’apparecchio abbia fisicamente raggiunto il valore richiesto. [2]

Un rischio OT, con effetti sul lavoro quotidiano

Il bollettino ACN, ripubblicato dal CSIRT Toscana e aggiornato il 3 novembre, richiama installazioni obsolete, amministrazione esposta su Internet e autenticazione carente. Descrive la possibilità di alterare parametri e cicli di sbrinamento. È un problema di tecnologia operativa, o OT: i sistemi digitali controllano un processo fisico. [3]

La nostra lettura tecnica è che l’analisi debba partire dalle funzioni autorizzate. Se un account può modificare più impianti, il rischio dipende anche dall’ampiezza dei suoi privilegi. La domanda utile per l’azienda diventa: quale percorso consente di passare da un accesso remoto a una modifica della refrigerazione?

Le verifiche da organizzare con i manutentori

Le indicazioni istituzionali comprendono censimento dei sistemi, rimozione dell’esposizione pubblica delle console, separazione IT/OT, accessi controllati con autenticazione a più fattori e controllo degli account. Vanno verificate anche le temperature effettive e le notifiche, preservando gli elementi utili all’analisi. Gli interventi devono essere coordinati con chi gestisce gli impianti, evitando interruzioni incontrollate. [3]

Come primo esercizio operativo proponiamo una riunione fra IT, manutenzione e responsabile del punto vendita. Portate una mappa degli accessi e una configurazione autorizzata: chi entra, su quali apparecchiature, per quanto tempo? Scegliete poi un allarme e seguitene il percorso fino alla persona reperibile. Annotate il risultato e assegnate un responsabile alle anomalie. È una verifica organizzativa da adattare all’impianto, non una prova da improvvisare sui controllori in esercizio.

Che cosa sappiamo e che cosa resta da chiarire

Federdistribuzione ha dichiarato il 3 novembre di non registrare criticità nelle reti delle proprie imprese associate. Questa dichiarazione riguarda quel perimetro e non smentisce automaticamente i singoli casi riportati altrove. [4] Evitiamo quindi di trasformare notizie eterogenee in un elenco di aziende sicuramente compromesse con la stessa tecnica.

Il ripristino tecnico non chiude da solo l’incidente: la valutazione delle merci dopo un’anomalia termica compete ai responsabili della sicurezza alimentare. [3] Per la direzione aziendale, la priorità è mettere in relazione sicurezza digitale, continuità del servizio e responsabilità sul processo fisico. Un inventario aggiornato diventa utile quando permette di decidere rapidamente chi deve intervenire.

Fonti

AI Act e Cyber Resilience Act: le scadenze aggiornate e le competenze da costruire

DM Web Solution — Tue, 03 Nov 2026 21:00:00 +0100

Prima il perimetro, poi la scadenza

AI Act e Cyber Resilience Act, abbreviato CRA, vengono spesso riuniti sotto l’etichetta della conformità digitale. Per impostare la formazione serve però distinguerli: l’AI Act disciplina sistemi e modelli di intelligenza artificiale secondo il relativo ruolo e rischio; il CRA riguarda la cybersicurezza dei prodotti con elementi digitali che rientrano nel suo campo di applicazione. Non ogni utilizzatore aziendale è automaticamente un fabbricante soggetto agli stessi obblighi. [1] [4]

La nostra proposta didattica è partire da un caso concreto: quale soluzione realizziamo, acquistiamo o utilizziamo? Chi ne stabilisce finalità e modalità d’impiego? Chi la immette sul mercato? Senza questa mappa, una presentazione sulle date rischia di produrre un calendario senza responsabili.

AI Act: il calendario è stato aggiornato

La Commissione europea comunica che l’AI Omnibus è entrato in vigore il 27 luglio 2026. Le regole per i sistemi ad alto rischio dell’allegato III sono previste dal 2 dicembre 2027; per quelli incorporati nei prodotti regolamentati dell’allegato I, dal 2 agosto 2028. La Commissione segnala anche semplificazioni amministrative e modifiche alle misure sull’alfabetizzazione in materia di IA. [1]

Questo aggiornamento non equivale a rinviare indistintamente tutto l’AI Act. Il Service Desk europeo indica l’applicazione delle disposizioni sulla trasparenza dal 2 agosto 2026 e una transizione fino al 2 dicembre 2026 per determinati sistemi già sul mercato, riferita all’articolo 50, paragrafo 2. La verifica deve quindi riguardare la disposizione e il caso specifico, non soltanto l’etichetta “IA”. [2]

CRA: le notifiche sono già una responsabilità operativa

Dall’11 settembre 2026 i fabbricanti interessati devono segnalare vulnerabilità attivamente sfruttate e incidenti gravi che incidono sulla sicurezza dei prodotti. La Commissione indica un preallarme entro 24 ore dalla conoscenza e una notifica entro 72 ore. Per la relazione finale distingue le vulnerabilità — entro 14 giorni dalla disponibilità della misura correttiva — dagli incidenti gravi, entro un mese dalla notifica delle 72 ore. [3]

ENISA ha attivato la Single Reporting Platform; i principali requisiti di cybersicurezza del CRA si applicheranno dall’11 dicembre 2027. Gli obblighi degli open-source software stewards hanno una decorrenza distinta, anch’essa indicata nell’11 dicembre 2027. [4] Attendere la scadenza generale del prodotto può quindi far trascurare un adempimento già applicabile al fabbricante.

Come trasformare le regole in una lezione utile

Proponiamo tre moduli: riconoscere il proprio ruolo, gestire una segnalazione e documentare una decisione. Nel primo, i partecipanti classificano un prodotto o un impiego dell’IA con il supporto di chi presidia la conformità. Nel secondo, simulano l’arrivo di una vulnerabilità sfruttata e ricostruiscono chi riceve la notizia, chi valuta il perimetro e chi prepara le informazioni. Nel terzo, compilano una scheda con fonte, data di verifica, motivazione e responsabile.

Per sviluppo e prodotto l’esercizio può riguardare dipendenze e gestione delle correzioni; per acquisti, le informazioni da ottenere dal fornitore; per direzione e responsabili di processo, risorse ed escalation. L’obiettivo formativo proposto è verificabile: al termine, ogni partecipante deve sapere riconoscere il limite della propria competenza e attivare il referente corretto.

Le certificazioni ISO 27001 e ISO 42001 possono offrire un contesto di gestione per organizzare responsabilità ed evidenze; non vanno presentate come una sostituzione automatica degli adempimenti di legge. Un percorso serio collega apprendimento, pratica e riesame delle informazioni, tenendo separati requisiti normativi e scelte organizzative.

Fonti

Programmazione agentica: dal suggerimento di codice al lavoro verificabile

DM Web Solution — Tue, 03 Nov 2026 21:00:00 +0100

Che cosa cambia rispetto al completamento del codice

La programmazione agentica porta l’IA dentro un ciclo di lavoro: ricevere un obiettivo, leggere il progetto, proporre modifiche, eseguire strumenti e usare il risultato per decidere il passo successivo. Un completamento suggerisce una porzione di codice; un agente può lavorare su un’attività che attraversa più file. Il risultato deve comunque essere confrontato con la richiesta iniziale.

Anthropic distingue i workflow, con percorsi definiti dal codice, dagli agenti, nei quali il modello orienta dinamicamente processo e strumenti. La sua guida raccomanda semplicità e complessità aggiunta solo quando serve: l’autonomia può aumentare costi e latenza. Sono principi architetturali, non una garanzia che qualsiasi compito debba essere affidato a un agente. [1]

Un esempio: correggere un errore di salvataggio

Immaginiamo un’applicazione che perda un campo quando l’utente salva una bozza. È un esempio didattico, non il resoconto di un progetto reale. Una consegna utile descrive il comportamento atteso, i passaggi per riprodurre il difetto e i vincoli: formato dei dati invariato, compatibilità con le bozze esistenti e nessuna pubblicazione automatica.

L’agente può ricostruire il percorso del dato dall’interfaccia alla persistenza e proporre una correzione. Il revisore deve poi poter vedere che cosa è cambiato e con quali evidenze: riproduzione del difetto, verifica del caso corretto e controllo di un salvataggio già funzionante. Un test che passa è un elemento di valutazione; serve anche verificare che il test rappresenti davvero il problema.

L’ambiente conta quanto il modello

GitHub descrive per i propri Agentic Workflows un’architettura fondata su isolamento, uscite vincolate, registrazione delle attività e verifica delle scritture. Il modello di minaccia considera anche gli input non affidabili: una pagina o un’issue può contenere istruzioni che tentano di deviare l’agente. Il progetto separa l’esecuzione dell’agente dai segreti e governa accessi e comunicazioni. [2]

Per una sperimentazione aziendale proponiamo un repository circoscritto e dati di prova. Definite quali comandi sono ammessi, quali servizi sono raggiungibili e chi approva merge e rilascio. Le credenziali di produzione non servono per dimostrare che un agente sappia correggere un difetto in un ambiente di test. Registrate anche i blocchi incontrati: sono informazioni utili per migliorare il processo.

Come valutare il beneficio senza inseguire le promesse

Il rapporto Anthropic sulle tendenze del 2026 descrive il passaggio verso il coordinamento degli agenti e insiste sul giudizio umano. Trattandosi di un rapporto del produttore, i casi e le valutazioni vanno letti nel loro contesto e non trasferiti automaticamente alle prestazioni di ogni azienda. [3]

La nostra proposta è misurare un piccolo insieme di attività confrontabili: tempo fino a una modifica accettata, lavoro di revisione necessario, difetti riaperti e consumo del servizio. Un’attività veloce da generare ma lenta da capire può spostare il costo sul revisore. Date quindi una definizione esplicita di “completato” prima dell’esperimento e annotate le eccezioni.

Il coordinamento di più agenti può essere utile quando le responsabilità sono separabili, ma aggiunge comunicazione e integrazione. Partite da un problema limitato e ampliate il perimetro dopo una verifica. Il passaggio decisivo è organizzativo: chi decide che il risultato soddisfa la richiesta? Nella programmazione agentica, una specifica chiara e una revisione competente diventano strumenti di lavoro quotidiano.