Immaginate un sistema ERP che elabora le fatture in due ore invece di quaranta minuti. Non c’è nessun alert e nessun ticket aperto, il sistema funziona, eppure l’azienda sta bruciando risorse, rallentando decisioni, accumulando inefficienza, senza che, nella grande maggioranza dei casi, l’azienda ne abbia consapevolezza. Questo è il downtime invisibile: una forma di degrado che non compare nei report, non apre ticket, non viene mai attribuita a un incidente, ma che erode silenziosamente produttività, qualità delle decisioni e competitività.

L’adozione crescente di architetture ibride, di pipeline AI e di sistemi distribuiti su infrastrutture eterogenee sta amplificando questo fenomeno. Le organizzazioni che continuano a investire in strumenti di monitoraggio tradizionali, si trovano a governare la complessità attraverso una fotografia parziale e, in molti casi, fuorviante. Sanno se il sistema risponde, non sanno se sta lavorando al livello di cui il business ha bisogno.

Disponibilità non è performance

Il modello di monitoraggio ereditato dagli anni Novanta misura la disponibilità dei sistemi, ovvero: se il server risponde, il servizio è raggiungibile, il processo è in esecuzione. Questi indicatori rispondono però alla domanda sbagliata – “Il sistema è attivo?” – quando invece bisognerebbe chiedersi se il sistema sta funzionando con la massima efficienza.

Una piattaforma e-commerce che completa le transazioni con tempi di risposta superiori agli SLA concordati è tecnicamente disponibile; lo stesso vale per un’applicazione per la gestione degli ordini. Un modello AI che produce risposte con un tasso di allucinazione crescente è operativo. Un processo di sincronizzazione dati di produzione che accumula ritardi non critici ma progressivi non genera allarmi. In tutti questi casi, però, l’azienda sta utilizzando un servizio che non eroga il livello di performance adeguato e per cui è stato progettato.

Le forme del degrado silenzioso

Il downtime invisibile si manifesta in pattern ricorrenti che l’esperienza su ambienti complessi consente di classificare. Tra i principali quello che viene chiamato “latenza sub-critica persistente” che si manifesta quando i tempi di risposta non superano le soglie di allerta, ma si attestano costantemente al di sopra dei valori ottimali. Su processi ad alta frequenza come query analitiche e chiamate API, ciò si traduce in una perdita di produttività progressiva che però non viene mai imputata a un incidente specifico.

Il secondo riguarda la deriva qualitativa dei modelli AI in produzione. Un Large Language Model non si rompe, ma si degrada. La qualità delle risposte scende progressivamente per effetto del data drift, dell’obsolescenza dei dati di training o di prompt injection accumulate nei sistemi RAG. Il monitoraggio tradizionale non rileva questo tipo di decadimento perché non misura la qualità semantica dell’output, solo la presenza di una risposta.

La terza forma di degrado silenzioso risiede nella frammentazione dei dati nei sistemi ibridi. Quando l’infrastruttura si distribuisce tra on-premise e cloud o tra provider cloud diversi, le latenze di sincronizzazione creano finestre in cui gli stessi dati sono presenti in versioni diverse in punti differenti del sistema. Nessun componente è in errore, ma le decisioni vengono prese su dati parzialmente aggiornati, con conseguenze che emergono solo a valle e attraverso anomalie difficili da tracciare alla loro origine.

Il costo che non appare nel report

Tutto ciò, per quanto invisibile, ha dei costi che non appaiono in nessun report. Il primo è il costo dell’inefficienza accumulata legata a operatori che aspettano, processi che si dilatano, ri-elaborazioni causate da dati non aggiornati. Secondo Gartner, il costo medio del downtime IT per le grandi organizzazioni supera i 5.600 dollari al minuto, ma quella stima esclude i casi in cui il sistema “funziona”.

A confermare quanto questo “falso funzionamento” sia oneroso, uno studio globale di Dynatrace evidenzia che i team IT e di sviluppo trascorrono in media quasi un terzo del loro tempo (circa il 30%) a identificare e risolvere problemi di degrado delle performance che sfuggono alle metriche di monitoraggio classiche. Il secondo costo è quello delle decisioni non ottimali, perché in un’organizzazione data-driven che si basa su analytics, insight e modelli predittivi basati su input di qualità degradata, ciò produce effetti a cascata sulle scelte di business, invisibili nei log ma concreti nei risultati.

Inoltre, quando le prestazioni sono costantemente sotto le attese, si radica l’abitudine a lavorare “intorno ai sistemi” alimentando anche il fenomeno dello shadow IT. Questo non viene mai attribuito al downtime invisibile, ma ne è una conseguenza diretta.

Osservabilità, non solo monitoraggio

La risposta tecnica al downtime invisibile non è il monitoraggio, ma l’osservabilità. La distinzione è sostanziale in quanto il monitoraggio verifica che le metriche predefinite rientrino nelle soglie, mentre l’osservabilità consente di rispondere a domande che non erano state previste al momento della configurazione del sistema.

In pratica, questo significa correlare metriche di infrastruttura con indicatori di qualità applicativa, per esempio, introducendo una telemetria continua sui modelli AI o dotando i team di strumenti per esplorare il comportamento del sistema in modo retrospettivo. Non si tratta di aggiungere alert, piuttosto di comprendere lo stato reale del sistema andando oltre la domanda: “Il sistema è attivo?”.

Gli ambienti con architetture AI richiedono un livello aggiuntivo di attenzione. I modelli in produzione devono essere valutati anche sulla qualità delle risposte nel tempo, sulla coerenza rispetto ai dati aggiornati, sulla distribuzione degli errori per tipo di query, per esempio collegando la qualità dell’output a SLA operativi. Va aggiunto che gli SLA tradizionali misurano la disponibilità, non la qualità delle prestazioni nel tempo. Vanno anch’essi ridefiniti per includere indicatori di qualità applicativa, introdurre revisioni periodiche delle prestazioni operative al di là degli incident report, e costruire una cultura in cui il degrado silenzioso viene segnalato e analizzato con la stessa serietà di un’interruzione.

Ma, prima di tutto, va compreso che la tecnologia, e quindi anche il downtime invisibile, non è soltanto un costo operativo, ma uno dei principali fattori di redditività e competitività, dal momento che influisce sulla produttività dei dipendenti, sull’accuratezza e tempestività delle decisioni, sulla conformità normativa, sulla qualità dei servizi e della user experience.

L'articolo Il downtime è anche invisibile, come il suo costo proviene da Data Manager Online.

Allo stato attuale potremmo quasi dire: c’era una volta lo shadow IT. Applicazioni non autorizzate, account personali usati per documenti aziendali, Dropbox al posto dei server interni, sono fenomeni che i reparti IT conoscono bene e stanno ancora cercando di contenere. Oggi, però, il problema si è evoluto nella shadow AI, ovvero nell’utilizzo non governato di strumenti di intelligenza artificiale generativa da parte dei dipendenti per finalità lavorative.

Con la shadow AI la dinamica resta la stessa, ma il rischio cresce. Dipendenti e manager utilizzano strumenti AI non autorizzati per accelerare attività operative, dalla sintesi di documenti all’analisi dei dati fino alla generazione di codici. Sono azioni spesso compiute in buona fede, ma che sfuggono ai sistemi di governance e controllo aziendali.

Le conseguenze possono essere rilevanti. Informazioni riservate rischiano di essere trasferite su piattaforme esterne senza piena consapevolezza di dove vengano archiviate, elaborate o riutilizzate, mentre dati strategici possono contribuire involontariamente all’addestramento di modelli terzi. Parallelamente, processi decisionali e attività operative iniziano a dipendere da strumenti non verificati, introducendo errori, bias o vulnerabilità di sicurezza difficili da individuare. Il rischio maggiore, però, è culturale, perché quando l’uso non autorizzato dell’AI diventa pratica quotidiana, innovazione e rischio crescono insieme e si radicano privi di adeguati meccanismi di supervisione.

In Italia, dove la cultura della compliance è storicamente più reattiva che proattiva, il fenomeno è diffuso, come emerge dagli ultimi dati dell’Osservatorio AI del Politecnico di Milano dello scorso febbraio che rilevano che l’84% delle grandi imprese ha licenze di Generative AI ma solo il 9% ha una governance AI strutturata. Nel frattempo, 8 lavoratori italiani su 10 dichiarano di utilizzare strumenti AI non aziendali.

Anche in questo caso, le organizzazioni stanno cercando di correre ai ripari. Ma mentre si discute di policy sull’uso dei modelli e di rischi legati al data leakage, un altro rischio si sta già manifestando, più profondo, più difficile da monitorare e, potenzialmente, molto più destabilizzante.

Il problema non è più quello che l’AI impara e dice, ma ciò che fa

Siamo entrati nell’era degli agenti autonomi, in cui gli LLM non vengono più usati soltanto per rispondere a domande o generare testi o codici ma anche per gestire e orchestrare flussi di lavoro anche complessi, integrati con API aziendali, dotati di credenziali con cui possono eseguire azioni concrete utilizzando i sistemi aziendali. Un agente può aprire ticket, modificare configurazioni cloud, avviare pipeline di dati, interagire con repository di codice. Lo fa in modo non deterministico e spesso senza che alcun presidio di sicurezza lo veda.

Questo è quel fenomeno denominato shadow operation, a indicare il deployment incontrollato di agenti AI che eseguono logica, chiamano API e modificano stati operativi senza supervisione formale.

Non è un rischio ipotetico: secondo il report 2’25 “The NHI & Secrets Risk” di Entro Labs, all’interno di un’azienda media le identità non umane come workload automatizzati e agenti AI, superano quelle umane con un rapporto di 144 a 1, registrando una crescita del 44% in un solo anno. Nelle organizzazioni che hanno già distribuito l’AI su più business unit, quando si chiede ai responsabili di elencare dove sono i loro agenti, quali permessi hanno e a quali sistemi accedono, la risposta è in molti casi incerta.

Gli strumenti ci sono, ma…

Sarebbe scorretto affermare che il mercato della cybersecurity sia impreparato.
Sono disponibili piattaforme di rilevamento per workload non umani e sistemi di gestione delle credenziali effimere (agenti AI ovviamente inclusi) con accesso just-in-time. Esistono inoltre soluzioni di identità per workload capaci di assegnare identità verificabili a processi automatizzati, con accesso condizionale e monitoraggio continuo, e anche strumenti per analizzare in tempo reale i flussi prompt-risposta degli stack agentici e per rilevare eventuali minacce.

Il problema non sono gli strumenti, è piuttosto legato a tre gap che le organizzazioni faticano ancora a colmare. Il primo è l’adozione: queste soluzioni non vengono ancora applicate sistematicamente agli agenti AI, troppo spesso soggetti agli stessi controlli inadeguati di un’applicazione tradizionale. Il secondo è la frammentazione: nessuna piattaforma copre in modo integrato l’intero stack agentico. Il terzo è la velocità: i framework agentici evolvono più rapidamente delle policy che dovrebbero governarli, aprendo superfici d’attacco prima che qualcuno le abbia mappate.

Inoltre, il problema non nasce quando il software è già in produzione o in esecuzione (“runtime”), ma molto prima, quando qualcuno propone una modifica al codice tramite una pull request. È lì che uno sviluppatore può assegnare all’agente privilegi eccessivi, credenziali statiche, scope troppo ampi. Se i team di sicurezza iniziano a monitorare solo quando il codice è già in produzione, arrivano tardi.

Infine, un singolo agente difficilmente opera in isolamento, è piuttosto un nodo in una rete di dipendenze che, nella maggior parte dei casi, nessuno ha ancora mappato, al contrario operazione nevralgica quanto urgente. A ciò si aggiunge la necessità di rivedere i test funzionali delle piattaforme, visto che la logica agentica introduce un’intrinseca “indeterminatezza” dei processi che rende difficile progettare casi di test sufficientemente flessibili e affidabili.

Una sfida prima organizzativa (e umana) che tecnologica

La risposta non è bloccare gli agenti AI né attendere strumenti più maturi, ma cambiare l’approccio alla loro adozione. Gli agenti vanno trattati come componenti critici dell’infrastruttura, quindi con identità verificabili, permessi rigorosi e un inventario strutturato di modelli, orchestratori e dipendenze, così da sapere quale agente opera su un processo, con quali credenziali e a quali repository accede.

Serve inoltre da un lato spostare i controlli a livello di codice, prima del deployment per non rincorrere i problemi a posteriori. Dall’altro costruire una governance coerente, con responsabilità chiare, audit trail leggibili e soglie di comportamento definite prima del go-live.

Su tutto, due messaggi emergono chiari: ciò che è invisibile, non si governa, ma soprattutto, più autonomia degli agenti non significa meno responsabilità umana, piuttosto il contrario. I sistemi agentici non sostituiscono il giudizio contestuale, la visione d’insieme e l’esperienza di dominio di un esperto umano. Supervisione, presidio dei punti critici e capacità di verificare decisioni e comportamenti degli agenti restano centrali: il vero rischio non è l’autonomia degli agenti AI, ma l’autonomia senza identità, inventario e controllo.

L'articolo Dopo lo shadow IT e la shadow AI, ora il rischio è la shadow operation proviene da Data Manager Online.

Le stime di Gartner indicano che entro il 2028 almeno il 50% dei progetti GenAI supererà il budget iniziale, soprattutto a causa dell’architettura sottostante, inclusa la scelta del cloud pubblico, dal momento che i dati sia globali che a livello nazionale del Politecnico di Milano evidenziano come dominante quest’ultima infrastruttura nell’adozione dell’intelligenza artificiale nelle imprese.

Questi scostamenti sono dovuti in particolare alle caratteristiche strutturali del modello di pricing del cloud pubblico, che per sua natura rende trasparenti alcune voci di costo e ne lascia altre fuori dalla visibilità dell’azienda.

Mappare queste voci prima dell’avvio non è un esercizio di mera prudenza contabile, piuttosto è la condizione per costruire un business case che regga all’impatto con la produzione. L’esperienza su progetti complessi insegna che le sorprese non arrivano dai listini, ma da ciò che i listini non mostrano.

Tra queste voci, sei in particolare raramente vengono contemplate nei budget forecast delle imprese:

1. Il costo dell’inferenza in produzione

Nella fase sperimentale, i workload sono limitati e i volumi contenuti. Il problema emerge con il passaggio al regime operativo continuativo. L’inferenza in produzione ha volumi e frequenze completamente diversi. E i costi non crescono in modo lineare, dal momento che le architetture di calcolo distribuito su cloud pubblico hanno meccanismi di pricing che amplificano i costi in modo non intuitivo all’aumentare dell’intensità d’uso. Chi ha costruito il business case sulla fase sperimentale si trova a ricalibrare le proiezioni quando il sistema va a pieno regime. A conferma di ciò, le analisi di settore condotte dai principali cloud provider stimano che l’inferenza rappresenti fino all’80-90% dei costi totali di un modello di intelligenza artificiale nel suo intero ciclo di vita operativo. Un impatto che spinge anche le aziende di grandi dimensioni, a rivalutare la sostenibilità di questo modello, nonostante le proprie capacità di spesa;

2. L’egress dei dati

Sul cloud pubblico, il traffico dati in uscita ha un costo che nelle architetture RAG intensive o nelle pipeline di elaborazione documentale diventa rilevante. Raramente compare nelle stime iniziali, perché i modelli di costo ragionano in termini di potenza computazionale, non di flussi. In un’architettura RAG, ogni interrogazione attiva il recupero di frammenti dalla knowledge base, il loro invio al modello e la restituzione di una risposta strutturata. Moltiplicate questo schema per decine di migliaia di chiamate quotidiane e la voce egress diventa tutt’altro che marginale. Anche l’annuale “State of the Cloud Report” di Flexera, conferma le spese di rete e di “data egress” come una delle voci di spesa imprevista più insidiose, arrivando a pesare per il 10-15% del totale della fattura cloud in architetture ad alta movimentazione di dati;

3. Il costo dell’integrazione con i sistemi legacy

Le soluzioni AI su cloud pubblico vengono presentate come plug-and-play, ma non è così. L’adattamento ai sistemi esistenti, gestionali, CRM, archivi documentali, sistemi di autenticazione, richiede una progettazione e uno sviluppo con costi iniziali e di manutenzione che arrivano a coprire circa il 35% del budget, secondo MuleSoft. Paradossalmente, un’architettura di Private AI risulta spesso più semplice da integrare, perché i punti di connessione con i sistemi aziendali possono essere progettati senza i vincoli delle API di un provider terzo;

4. Il costo del time-to-value mal calcolato

Sul cloud pubblico, il time-to-value ha una dimensione economica diretta che va oltre il costo opportunità: ogni settimana aggiuntiva tra l’avvio e la messa in produzione è una settimana in cui si paga l’infrastruttura senza generare ritorno. Il modello a consumo del cloud amplifica questo effetto, perché i costi di sviluppo e test si accumulano sulle stesse voci che poi alimenteranno il sistema in produzione. Chi non pianifica la traiettoria di scaling fin dall’inizio si trova a sostenere picchi di spesa non previsti esattamente quando il sistema comincia a funzionare davvero. Un’indagine di IDC ha evidenziato che le organizzazioni impiegano in media dai 5 ai 6 mesi per portare un modello dal proof-of-concept iniziale alla messa in produzione su larga scala;

5. Il costo della compliance che si scopre in corsa

Per banche, sanità e pubblica amministrazione la compliance è un vincolo architetturale e quindi certi dati non possono uscire dal perimetro aziendale. Tuttavia il problema emerge anche altrove. Le architetture AI vengono progettate e solo successivamente, spesso quando si è già in produzione, si scopre che la residenza dei dati, la gestione di quelli personali o le policy interne di sicurezza impongono modifiche significative. Retro-progettare la compliance ha un costo superiore (fino a 6 volte) rispetto a quello sostenuto integrandoli nativamente nella primissima fase di design architetturale;

6. Il costo della proprietà intellettuale esposta

Quando un’azienda effettua fine-tuning su dati interni verticali come la documentazione tecnica proprietaria, i dati storici di produzione o il know-how di processo, quel modello incorpora un patrimonio con valore strategico reale. Mantenerlo su infrastruttura condivisa, anche con adeguate garanzie contrattuali, introduce un profilo di rischio che cresce proporzionalmente alla qualità e alla specificità dei dati utilizzati. La protezione della proprietà intellettuale è un tema di governance che non può essere delegato alle clausole di un contratto SaaS, bensì richiede scelte architetturali esplicite a partire dalla valutazione di un’infrastruttura dedicata, che vanno prese prima, non a sistema già addestrato. Un tema di governance percepito da oltre il 57% dei leader IT e dei CISO come la preoccupazione numero uno legata all’uso dell’AI su piattaforme di cloud pubblico, come rilevato dall’Executive Survey di Gartner.

Governare correttamente queste variabili prima dell’avvio della produzione dimostra un approccio di Application Development maturo, indispensabile per rendere il progetto AI sostenibile in un mercato dove la distanza tra un proof of concept e un sistema operativo AI powered efficace ed efficiente si misura spesso anche in budget bruciati e aspettative disattese.

L'articolo AI sul cloud pubblico: i 6 costi sottovalutati che mettono a rischio i budget proviene da Data Manager Online.

Ogni giorno migliaia di aziende italiane affidano a un Large Language Model decisioni, processi e dati critici. Lo fanno convinte di adottare una tecnologia straordinariamente potente, spesso senza considerare che rappresenta anche una superficie di attacco in continua evoluzione. Secondo l’ultimo rapporto ISTAT “Imprese e ICT”, nel 2025 il 16,4% delle imprese con almeno 10 addetti ha adottato soluzioni di AI generativa, oltre al triplo rispetto al 2023. Una crescita guidata molto spesso più dall’urgenza di innovare che da una riflessione matura sui rischi.

Le vulnerabilità, una veloce review

Prima di affrontare il nodo della responsabilità, è utile tracciare rapidamente il perimetro tecnico del problema. Le vulnerabilità degli LLM si distribuiscono lungo l’intero ciclo di vita del sistema.

Nella fase di addestramento, il rischio principale è il Data Poisoning: inserire nel dataset fonti non verificate o contenuti manipolati significa alterare il comportamento del modello alla radice, prima ancora che entri in produzione. In sistemi con architetture RAG si aggiunge il problema della governance temporale: la knowledge base deve essere mantenuta aggiornata e presidiata continuamente. Non è un’attività automatica, e non è una responsabilità del modello.

Una volta in uso, la vulnerabilità più diffusa è la prompt injection: un input costruito per aggirare le istruzioni del sistema, inducendo il modello a produrre output non previsti o a rivelare informazioni riservate. La criticità di questa minaccia emergeva anche dalla Top 10 per la sicurezza delle applicazioni AI della fondazione OWASP (Open Worldwide Application Security Project) che anche nell’aggiornamento del 2025 confermava la Prompt Injection al primo posto assoluto. Inoltre, diversi studi di settore e attività di “red teaming” hanno evidenziato come tecniche avanzate di prompt injection, a partire dagli attacchi basati su roleplay, istruzioni indirette e manipolazioni logiche, possano compromettere con elevata probabilità sistemi LLM privi di adeguate difese multilivello.

Va aggiunto che con l’introduzione degli agenti AI, queste minacce cambiano natura, se un sistema conversazionale produce una risposta sbagliata, in un sistema agentivo connesso a strumenti operativi, ciò si traduce in un’azione sbagliata, ovvero il danno da informativo diventa operativo.

Nessuna di queste vulnerabilità dipende esclusivamente da un difetto implementativo, piuttosto sono il risultato di “negligenze”, come già evidenziato, lungo tutta la catena di adozione: progettazione, integrazione, aggiornamento nel tempo. Ed è proprio da questa distribuzione che nasce il problema più sottovalutato.

Una dispersione di responsabilità

Quando si verifica un incidente di sicurezza legato a un LLM, la prima domanda che emerge non è tecnica, ma chi risponde. E la risposta, oggi, non è chiara.

Le vulnerabilità descritte sono il risultato di decisioni prese in momenti e attori diversi, con livelli di consapevolezza anche molto differenti. Il vendor che ha pre-addestrato il modello, il system integrator che ha progettato l’architettura, il cliente che ha deciso quali dati far confluire nel sistema: ciascuno ha contribuito a costruire il perimetro di rischio. Ma quando quel perimetro viene violato, ogni attore tende a considerare la sicurezza come un tema delegato agli altri.

Questo schema non è nuovo nel settore tecnologico, ma negli LLM si manifesta con una forza particolare per due ragioni. La prima è l’opacità dei modelli: a differenza di un’applicazione tradizionale, un LLM produce output probabilistici che nessun attore della catena può prevedere o garantire completamente. La seconda è la velocità di adozione: le organizzazioni hanno integrato questi sistemi in processi critici prima che esistesse un framework condiviso per gestirne i rischi. Il risultato è che la responsabilità si è frammentata prima ancora di essere definita.

Tre livelli di responsabilità non delegabili

Per uscire dall’ambiguità occorre distinguere con precisione i livelli su cui questa responsabilità si articola. Ne identifico almeno tre, con obblighi che non possono essere scaricati sugli altri.

Il vendor del modello è responsabile di garantire che il sistema non sia inducibile, tramite prompt injection o jailbreak, a comportamenti che compromettono la sicurezza delle informazioni. I modelli pre-addestrati possono contenere funzionalità che, in determinate condizioni operative, diventano vettori di rischio. Si tratta di garanzie che la pressione competitiva relega spesso in secondo piano, anche per l’assenza di un’attenzione diffusa delle organizzazioni su questo tema. Ma la responsabilità esiste indipendentemente dal fatto che venga richiesta.

Il system integrator ha responsabilità tecniche sulla progettazione dell’intera pipeline: cifratura, configurazione dei modelli di sicurezza, architettura RAG, gestione degli ambienti e dei perimetri di accesso. Queste responsabilità esistono indipendentemente da come viene strutturato il contratto. Chi progetta l’architettura decide strutturalmente anche quanto il sistema può essere esposto.

Il cliente ha una responsabilità nel suo doppio ruolo. Come data controller è responsabile della classificazione dei propri dati e delle decisioni su quali informazioni entrano nel sistema. Come committente è responsabile della governance della pipeline nel tempo. Questa governance non può essere delegata all’AI stessa, perché un sistema linguistico non può essere il garante della propria affidabilità. E non può essere delegata interamente al fornitore, perché nessun fornitore conosce il contesto operativo dell’organizzazione meglio dell’organizzazione stessa.

Il modello che manca

Chi ha vissuto la transizione verso il cloud riconosce questo schema. Anche lì la responsabilità sulla sicurezza era rimasta a lungo ambigua, frammentata tra provider e clienti. La svolta è arrivata con il modello di Shared Responsibility che ha definito una mappa esplicita di chi è responsabile di cosa, a quale livello dello stack tecnologico. Una mappa che non ha eliminato i rischi, ma ha reso certamente possibile presidiarli con maggiore consapevolezza.

Per gli LLM, quel modello non esiste ancora. E la sua assenza non è un problema tecnico, è un problema di governance del settore. Costruirlo richiede che vendor, integratori e clienti smettano di considerare la sicurezza degli LLM un problema altrui, e che il management, non solo i team tecnici, comprenda concretamente cosa implica introdurre questi sistemi nei processi aziendali e le conseguenze dello Shadow AI per essere in grado di valutare i rischi che si stanno “accettando”.

La priorità emergente è adottare gli LLM con un modello di responsabilità chiaro, riconoscendo anche che la velocità d’innovazione non può giustificare compromessi sulla sicurezza da parte di nessun attore della catena. Non farlo significherà farlo al primo incidente, e a quel punto il costo non sarà solo tecnico.

L'articolo Gli LLM sotto attacco: vulnerabilità ormai note, ma responsabilità ancora da definire proviene da Data Manager Online.

L’IT Service Management (ITSM) ha lasciato un’eredità che va ben oltre gli strumenti che ha introdotto. Nel tempo, le organizzazioni che hanno adottato l’ITSM non hanno solo acquisito software di ticketing o portali di supporto: hanno adottato un modo diverso di pensare ai servizi, con processi tracciabili, SLA condivisi, misurazione sistematica delle performance e ricerca del miglioramento continuo. Un imprinting operativo che ha trasformato i servizi in elementi governabili, misurabili e confrontabili, oltre che focalizzati sui benefici per chi ne usufruisce.

Questi vantaggi dell’ITSM hanno aperto le porte al passo successivo: l’estensione della stessa logica a funzioni aziendali che con l’IT hanno poco a che fare, dall’HR al Legal, dal Finance al Facilities. La pressione crescente sulla produttività interna e la necessità delle imprese di portare ordine, controllo e miglioramento delle performance nei processi di business hanno accelerato nel tempo l’adozione dell’Enterprise Service Management (ESM) nelle imprese.

A conferma di questo trend, i dati di Gartner evidenziano come l’ESM sia ormai una priorità strategica, con oltre il 70% delle grandi organizzazioni che sta attivamente investendo nell’estensione delle pratiche di service management al di fuori dell’IT, proprio con l’obiettivo di abbattere i costi operativi e incrementare la produttività aziendale. Obiettivi, però, non sempre conseguiti con successo.

Un problema di governance, non di software

Quando un’organizzazione decide di adottare l’ESM, il primo step su cui ci si concentra è cercare una piattaforma. È comprensibile: il mercato offre suite ITSM consolidate che si presentano come pronte all’uso anche per le funzioni non-IT, con moduli preconfigurati per HR, Legal, Finance e Facilities da agganciare all’infrastruttura già in uso all’IT. L’idea, però, che basti estendere una licenza e attivare qualche modulo per adottare l’ESM è l’errore più frequente.

Infatti, trattare questa pratica come un progetto tecnologico e non organizzativo porta quasi inevitabilmente a risultati parziali e a funzioni che continuano a operare come prima, ovvero con telefonate ed email.

I passi che contano

Per evitare l’insuccesso, la prima buona pratica alla base di un progetto ESM efficace è la costruzione del catalogo servizi per le funzioni non-IT. Può apparire come un’attività tecnica, ma non lo è, perché definire quali attività l’HR copre, come e chi sono i destinatari obbliga l’organizzazione a ripensare e istituzionalizzare ambiti che spesso non sono mai stati formalizzati. Si tratta di un esercizio fortemente organizzativo e solo successivamente di design di processo.

Il passaggio successivo è anche il più complesso, ovvero la definizione degli SLA interni. Introdurre una logica di livelli di servizio tra funzioni aziendali significa rendere misurabili, quasi sempre per la prima volta, attività gestite fino a quel momento in modo informale. Questo può far emergere tensioni e resistenze, rendendo necessario un delicato lavoro di facilitazione.

La definizione del catalogo dei servizi e degli SLA vale, da sola, quanto l’adeguata selezione e implementazione della piattaforma ESM, al pari del nodo critico dell’ownership. La mancanza di uno schema di responsabilità chiaro e condiviso su chi, per esempio, gestisce il servizio e chi interviene nel caso di calo degli SLA è una delle cause più frequenti di insuccesso.

Inoltre, adottare una logica di service management richiede di lavorare con cataloghi, richieste e SLA anche per team che non l’hanno mai fatto e che, quindi, con molta probabilità non utilizzeranno spontaneamente la piattaforma ESM. Vincere l’inerzia e l’abitudine richiede formazione, comunicazione interna e, soprattutto, che il nuovo modello ESM dimostri fin da subito di facilitare il lavoro delle persone.

Qual è la piattaforma giusta?

Solo dopo aver completato questi passaggi, la scelta della piattaforma acquista il peso che merita. Non è una decisione che si esaurisce nella valutazione delle funzionalità tecniche o nell’analisi comparativa dei vendor. Il nodo centrale da sciogliere è se quella data piattaforma sia in grado di adattarsi all’organizzazione e al modello di governance dei servizi di business che si vuole costruire, e non il contrario, ovvero che sia l’organizzazione a doversi adattare alla piattaforma.

In questo contesto, c’è un ulteriore rischio che le organizzazioni tendono a sottovalutare nella fase di selezione tecnologica: quello di replicare a livello di piattaforma la frammentazione che l’ESM dovrebbe eliminare. Accade quando ogni funzione aziendale adotta uno strumento diverso, o un modulo diverso della stessa suite, senza che esista un layer comune di orchestrazione.

Anche la capacità di integrare i sistemi esistenti, dall’ERP alle suite HR, dagli strumenti di collaboration ai sistemi di identity management, è tutto tranne un requisito tecnico accessorio: è piuttosto una delle condizioni fondamentali per un’adozione completa e diffusa.

A questo si aggiunge un’altra dimensione che definisce il vero salto qualitativo delle piattaforme più evolute: la transizione verso l’Intelligent Automation. Non si tratta di adottare una mera automatizzazione di flussi di lavoro lineari, ma di orchestrare processi complessi e cross-funzionali integrando Machine Learning e GenAI. L’AI permette infatti di passare da un approccio reattivo a un modello realmente predittivo e proattivo, grazie a vantaggi tangibili come il triage intelligente, che categorizza e indirizza automaticamente le richieste ai team corretti abbattendo i tempi di risoluzione, e gli agenti virtuali conversazionali (NLU), che offrono un supporto self-service avanzato e contestuale.

Inoltre, adottando logiche di AIOps estese all’intero perimetro aziendale, la piattaforma diventa in grado di anticipare i colli di bottiglia nei processi, assistere gli operatori umani con funzionalità di Copilot suggerendo soluzioni basate sullo storico e abilitare meccanismi di self-healing per risolvere le anomalie prima ancora che l’utente finale ne percepisca l’impatto. L’AI non si limita pertanto a rendere più efficiente l’ESM, ma ne amplifica esponenzialmente le capacità di supporto al business.

In questa prospettiva, l’adozione di una piattaforma di Enterprise Service Management trascende la dimensione dell’acquisizione tecnologica per configurarsi come elemento centrale della trasformazione dei processi operativi. Il valore intrinseco della soluzione non è determinato dal perimetro immediato, bensì dalla capacità del sistema di sostenere la scalabilità e l’evoluzione del modello operativo nel lungo periodo. L’assenza di una visione strategica nella selezione rischia di generare inefficienze strutturali; al contrario, una governance condivisa della soluzione permette di consolidare il percorso di digitalizzazione aziendale, garantendo l’allineamento tra strumenti tecnologici e obiettivi di business.

L'articolo Dall’ITSM all’Enterprise Service Management: quali sono gli elementi chiave per una implementazione efficace? proviene da Data Manager Online.

Innovaway, azienda italiana specializzata in servizi e soluzioni IT avanzate per imprese e Pubbliche Amministrazioni, ha recentemente adottato la piattaforma di AI-powered automation e no-code “HCL BigFix Service Management” per far evolvere il proprio modello di service delivery verso un approccio in cui l’automazione intelligente amplifica l’efficacia operativa dei team IT, potenziandone al contempo le capacità decisionali.

La scelta nasce dall’esigenza di rispondere alle crescenti pressioni operative che caratterizzano il mercato MSP – dai KPI alla marginalità – attraverso una soluzione tecnologica capace di semplificare la gestione della complessità e aumentare flessibilità ed efficienza. In questo contesto, Innovaway supera il tradizionale paradigma reattivo del “Break-Fix”, basato su flussi di lavoro frammentati e interventi post-incidente, adottando un approccio “Prevention and Act”. Governando l’intero processo end-to-end, l’azienda punta a valorizzare l’analisi dei dati in tempo reale per anticipare le criticità e prevenire i disservizi prima che abbiano impatto sull’utente finale.

Un salto qualitativo che ha reso necessario superare i limiti di un semplice tool di ticketing per adottare una piattaforma evoluta in grado di abbattere sforzi e costi, semplificare le configurazioni multi-tenant e sfruttare le potenzialità dell’automazione intelligente integrata in modo fluido e gestita attraverso un framework di governance unificato.

Per rispondere a queste esigenze, Innovaway ha adottato “BigFix Service Management” di HCLSoftware, che consente di gestire una parte rilevante dei propri clienti da un’unica istanza centralizzata, eliminando frammentazione e complessità tipiche delle soluzioni tradizionali. Inoltre la scelta è caduta su una piattaforma in grado di incorporare nativamente funzionalità AI avanzate, tra cui Cognitive Virtual Assistant e Predictive Insights, e di potenziare il proprio know-how operativo attraverso logiche evolute di automazione. Un supporto tecnologico centrale per ridurre le attività ripetitive in carico ai team IT e aumentare la disponibilità di insight azionabili al servizio dei processi decisionali, anche predittivi, e quindi potenziare la tempestività e qualità dei servizi erogati.

I risultati di questa evoluzione sono stati presentati da Innovaway, nel corso del webinar internazionale organizzato da HCLSoftware sull’AI-powered automation, a conferma della capacità di Innovaway di guidare l’innovazione nel proprio ambito. In soli sei mesi, Innovaway ha integrato sulla nuova piattaforma oltre 20 clienti, registrando miglioramenti significativi e misurabili su tutti i principali indicatori di performance, quali:

+35% nella velocità di attivazione dei nuovi contratti, con un onboarding clienti più rapido e standardizzato;

+30% nell’efficienza di delivery, accelerata dall’integrazione CTI e dall’automazione dei processi di supporto;

-25% del Total Cost of Ownership, grazie all’utilizzo di una piattaforma unica rispetto alle soluzioni precedenti;

+20% nella soddisfazione dei dipendenti legata alla maggiore usabilità degli strumenti e del supporto multilingue e ai flussi di lavoro più fluidi ed efficienti.

Antonio Burinato, Direttore Generale di Innovaway, ha commentato: “Con la piattaforma di Service Management di HCL abbiamo ridisegnato il nostro modello di delivery su basi più solide ed efficienti, grazie a processi standardizzati, gestione centralizzata multi-tenant e al supporto dell’AI che agisce come abilitatore per i nostri talenti. I risultati raccolti in soli sei mesi dimostrano che si può scalare il business senza compromettere la sostenibilità, la qualità dei servizi e il sentiment del personale” e ha concluso: “Oggi i clienti chiedono velocità, flessibilità e KPI sempre più stringenti: rispondere a queste aspettative richiede modelli di servizio ripensati dalle fondamenta sfruttando il supporto della tecnologia e l’expertise umana che la governa”.

L’adozione di una piattaforma di automazione intelligente si inserisce in una strategia più ampia con cui Innovaway intende ridefinire qualità e scalabilità dei propri servizi IT. Nei prossimi mesi l’azienda consoliderà ulteriormente il proprio modello operativo, puntando su automazione predittiva e riduzione del tempo medio di risoluzione degli incidenti (MTTR) per migliorare efficienza e distintività nell’erogazione dei servizi.

L'articolo Innovaway rivoluziona l’erogazione dei servizi unendo AI-powered Automation e Human Collaboration proviene da Data Manager Online.

Solo qualche anno fa, ipotizzare che un software venisse scritto e poi verificato dall’AI sarebbe sembrato un’ipotesi fantascientifica. Oggi è una prassi sempre più diffusa e in molte aziende persino consolidata. A confermare la portata di questa trasformazione, Gartner stima che entro il 2028 il 75% degli ingegneri del software nelle grandi aziende utilizzerà regolarmente assistenti AI per la programmazione, rispetto a meno del 10% registrato all’inizio del 2023. L’intelligenza artificiale genera il codice, scrive i casi di test, produce la documentazione, analizza il codice prodotto e segnala anomalie suggerendo le relative correzioni. Il tutto in tempi brevissimi, con vantaggi concreti e misurabili, ma anche con un controllo e un’affidabilità fragili.

I limiti dell’AI testing

I sistemi AI riconoscono schemi nel codice, ma non ragionano sul contesto in cui quel software dovrà funzionare. Non sanno pertanto nulla del business che deve supportare, degli utenti che lo useranno, dei casi limite che potrebbero farlo fallire. Lo strumento che genera il codice e quello che lo verifica lavorano entrambi per correlazioni statistiche: identificano ciò che assomiglia a qualcosa di già visto, non ciò che è corretto rispetto a una realtà che non hanno mai osservato. Quando i due strumenti condividono gli stessi dati di addestramento, condividono anche gli stessi punti ciechi: l’errore che il primo potrebbe non vedere è lo stesso che non vedrà il secondo. I sistemi AI riconoscono bene gli errori già visti, di contro faticano con quelli nuovi, per esempio specifici di un contesto di business che nessun dataset ha contemplato o quelli che nascono dall’interazione tra componenti sviluppati in momenti diversi da team diversi.

Quando il testing è generato dallo stesso strumento che ha prodotto il codice, l’AI verifica che il codice faccia ciò che il modello si aspetta debba fare, non ciò che l’azienda o l’utente finale ha bisogno che faccia. Il risultato è che il codice funziona, i test vengono superati e l’applicazione viene rilasciata, ma in produzione emergono i problemi. Non errori tecnici come crash o blocchi del sistema, piuttosto comportamenti sbagliati: come un gestionale che registra le consegne senza aggiornare gli stock di magazzino, o un report che aggrega i dati nel modo indicato dal modello ma non in quello in cui gli utenti li leggono e usano. In altre parole, il software fa quello per cui è stato scritto, peccato che quello per cui è stato scritto non è corretto.

Questo non vuol dire che affidarsi a un sistema AI per valutare l’output di un altro sistema AI sia sbagliato, in certe condizioni è persino consigliabile, però diventa controproducente quando è l’unica modalità di verifica adottata, quando non c’è nessun punto nel processo in cui un essere umano con competenza di dominio verifica cosa è stato prodotto ed evita che gli errori arrivino in produzione.

Il ruolo del QA nel ciclo di sviluppo automatizzato

Questo scenario conferma la centralità del Quality Assurance come presidio della qualità lungo tutto il ciclo di sviluppo, dalla definizione dei requisiti fino al rilascio. Un ruolo che con l’introduzione dell’AI nel software development non si riduce, anzi si rafforza. Quando il codice viene generato e verificato in automatico, il QA è l’unica funzione che porta nel ciclo quella forma di giudizio che l’AI non può esercitare: la capacità di stabilire se un software è adeguato rispetto al contesto reale in cui opera, agli utenti che lo usano, alle situazioni che nessun dato di addestramento ha mai visto. Se l’AI verifica “solo” che il codice giri, i QA specialist hanno invece il compito, anzi la responsabilità, di rispondere alla domanda “Questo software fa ciò che deve fare e per chi deve farlo?”, e quindi di certificare che la soluzione sia veramente adeguata prima del rilascio.

Il Quality Assurance introduce inoltre nel ciclo un elemento che l’automazione tende a trascurare: la tracciabilità. Sapere quale strumento ha generato quale parte del codice, con quali istruzioni, in quale momento. Senza questa informazione, quando qualcosa va storto in produzione diventa molto difficile capire dove intervenire, e garantire che la correzione risolva davvero il problema e non solo i suoi effetti visibili.

La responsabilità che l’AI non può assumere

Quando un software in produzione si comporta in modo sbagliato, dire che “L’errore è stato generato dall’AI” non risponde alla domanda centrale: perché l’anomalia non è stata individuata prima del rilascio? Nei contesti in cui l’intero processo è delegato agli strumenti automatici, questa domanda spesso non ha risposta semplicemente perché nessuna funzione aziendale ha il compito formale di valutare se il software generato e testato dall’intelligenza artificiale è adeguato prima che vada in produzione.

È in questo scenario che il QA diventa decisivo, non come funzione di controllo aggiuntiva, ma come la funzione aziendale a cui spetta formalmente la responsabilità di certificare che il software sia idoneo prima del rilascio, quella che invece, negli scenari di automazione spinta, manca.

L’integrazione di un livello di supervisione umana (Human-in-the-Loop) non è una semplice cautela, ma un requisito imprescindibile di IT governance. L’Intelligenza Artificiale, per sua natura, tende a generare una pericolosa illusione di controllo, fornendo output che appaiono intrinsecamente verificati. Tuttavia, dal punto di vista dell’affidabilità sistemica, un modello basato sull’auto-convalida è intrinsecamente fragile perché potenzialmente in attesa di un’anomalia critica di cui l’algoritmo non possiede le metriche per identificarla e prevenirla.

Le ripercussioni di un’automazione priva di controllo sono già un problema tangibile. Un’analisi condotta da GitClear su oltre 150 milioni di righe di codice ha rivelato che la crescente dipendenza dagli assistenti AI sta generando un pericoloso “debito tecnico indotto dall’AI”. Il report ha evidenziato un aumento allarmante del “code churn”, ovvero la percentuale di codice che deve essere modificato, corretto o eliminato entro due settimane dalla stesura, dimostrando che l’iper-produttività iniziale della macchina spesso collassa senza una validazione umana adeguata.

E le conseguenze di un software inadeguato non si fermano al codice, si trasferiscono sull’esperienza degli utenti, sui processi aziendali, sulle decisioni che quella tecnologia avrebbe dovuto supportare e migliorare. Il Quality Assurance nell’era dell’AI software development è la condizione perché quelle conseguenze restino un rischio gestito, non un problema che emerge in produzione portando a problemi operativi e a importanti costi aggiuntivi.

L'articolo Quando l’AI sviluppa e testa il software, chi garantisce che funzioni davvero? proviene da Data Manager Online.

Innovaway, azienda specializzata in soluzioni e servizi IT avanzati per imprese e Pubbliche Amministrazioni, annuncia il conseguimento della certificazione Platinum Partner di ISTQB (International Software Testing Qualifications Board), il più alto livello di riconoscimento assegnato in ambito nazionale dall’organizzazione internazionale di riferimento nella validazione delle competenze nel software testing.

Un traguardo, conseguito interamente grazie ad un piano interno di formazione avviato nel 2023, che attesta ulteriormente la qualità dei servizi di Testing & Quality Assurance erogati da Innovaway ai propri clienti.

In particolare, il riconoscimento di Platinum Partner testimonia la solidità e l’eccellenza delle certificazioni conseguite dal team Innovaway, il suo allineamento alle best practice internazionali e la focalizzazione costante sulla crescita professionale dei propri specialisti.

Questa certificazione assume ancora più valore alla luce del contesto sempre più complesso e dinamico in cui operano le organizzazioni, dove un’applicazione che si blocca, rallenta o espone dati sensibili non è solo un problema tecnico, ma soprattutto un danno diretto al business e alla fiducia dei clienti.

Per questo motivo, l’approccio di Innovaway al Software Testing punta alla massima prevenzione al fine di assicurare l’affidabilità, la sicurezza e le alte performance delle soluzioni e salvaguardare la continuità operativa e la reputazione aziendale, eliminando i costi imprevisti legati alla correzione dei difetti in produzione.

Attraverso un approccio strutturato e completo che tocca i seguenti ambiti:

• Test Management
• Functional & Automated Testing
• Performance Testing
• Security Testing
• Usability & Accessibility Testing

Innovaway offre una copertura dell’intero ciclo di vita della qualità del software.

A gestire ogni fase un team con le principali certificazioni ISTQB, segno concreto di come Innovaway faccia della formazione continua e della qualità, un metodo di lavoro e un pilastro della sua profonda cultura di servizio.

“Ottenere la qualifica di Platinum Partner ISTQB è un traguardo di cui siamo orgogliosi, perché riflette un impegno concreto verso l’eccellenza nel testing per garantire ai nostri clienti la massima affidabilità delle soluzioni digitali” ha dichiarato Antonio Burinato, Direttore Generale di Innovaway: “Non va sottovalutato che la crescente complessità dei sistemi software, la diffusione dei modelli agile e DevOps, l’intensificarsi delle minacce cyber e la crescente adozione dell’intelligenza artificiale nello sviluppo applicativo, rendono il testing e la Quality Assurance ancora più critici e centrali”.

Questo traguardo rafforza il ruolo di Innovaway quale partner solido per la Digital Transformation di imprese e Pubblica Amministrazione. Un risultato supportato da un’offerta end-to-end di servizi IT gestiti, da una elevata maturità professionale dei team e da una comprovata capacità di soddisfare i rigorosi standard dei settori più critici.

L'articolo Innovaway ottiene il massimo riconoscimento ISTQB per il software testing proviene da Data Manager Online.

L’ecosistema normativo europeo ha subito una trasformazione radicale negli ultimi anni. GDPR, DORA, NIS2 e AI Act non rappresentano semplicemente un incremento dei requisiti di compliance, ma configurano un nuovo scenario in cui la protezione crittografica dei dati non è più una best practice opzionale, bensì un prerequisito legale vincolante.

Questa evoluzione sta rendendo però sempre più evidente che i modelli crittografici tradizionali, per quanto sofisticati, presentano limiti strutturali che non possono essere risolti attraverso ottimizzazioni incrementali, ma richiedono una revisione più profonda, anche in relazione all’evoluzione computazionale alle porte.

Il paradosso operativo della validazione

Le metodologie classiche come controlli di accesso basati su ruoli, crittografia a riposo e in transito, pseudonimizzazione, segregazione dei database e audit trail, si scontrano con un problema: per validare i dati personali è necessario esporli in chiaro. Ogni verifica KYC, ogni controllo di conformità, ogni processo di onboarding implica l’esposizione di dati che, se compromessi, generano responsabilità che vanno oltre il danno economico diretto.

Questo paradosso ha un duplice impatto. Dal punto di vista economico, la gestione della compliance assorbe risorse per implementazione tecnica, audit continui, consulenze legali e formazione del personale. Il rischio di sanzioni può raggiungere il 4% del fatturato globale, accompagnato da un danno reputazionale spesso più pesante dell’ammenda stessa. Il report “Cost of a Data Breach 2024” di IBM evidenzia che il costo medio globale di una violazione dei dati ha raggiunto il record storico di 4,88 milioni di dollari, con un’impennata nei settori sanitario e finanziario, dove l’esposizione di dati in chiaro rappresenta uno dei vettori di costo più onerosi.

Il limite più critico è tuttavia un altro: queste metodologie aprono la porta a un rischio concreto di intrusione nei sistemi. Essere conformi, infatti, non significa essere al sicuro, il personale autorizzato rimane un potenziale vettore di attacco e ogni accesso costituisce un possibile punto di compromissione. La compliance procedurale, in altre parole, non garantisce la sicurezza.

Zero Knowledge Proofs: verificare senza leggere

I protocolli crittografati Zero Knowledge Proofs (ZKP) promettono di eliminare questa debolezza permettendo di dimostrare di possedere un requisito senza rivelare dati. Prendiamo l’esempio di una finanziaria che deve verificare che il reddito di un cliente superi i 30.000 euro per concedere un prestito. Tradizionalmente, il cliente fornisce buste paga e CUD – documenti che rivelano stipendio esatto, datore di lavoro, dettagli patrimoniali – esposti a chiunque li gestisca. Con le ZKP, il datore di lavoro firma digitalmente il reddito del cliente e, tramite un’applicazione, il cliente genera una prova crittografica che il reddito supera i 30.000 euro da fornire alla banca. In questo modo, nessun dato sensibile transita, nessun database lo acquisisce, nessun operatore vi accede. La verifica avviene, ma il pericolo di compromissione scompare alla radice.

I progetti pilota nel settore bancario mostrano riduzioni significative dei tempi di onboarding e contenimento dei costi di compliance, grazie alla riduzione del personale necessario per gestire dati sensibili, dei costi di storage sicuro e di quelli assicurativi. Ma il valore più rilevante è la riduzione del rischio: meno dati sensibili in chiaro significano minore superficie di attacco e minore responsabilità in caso di incidente.

I progressi nello sviluppo delle ZKP sono reali e rapidi: Microsoft, Google e istituzioni accademiche investono attivamente in questi protocolli e l’obiettivo è chiaro: trasformarli da strumento accademico a tecnologia di uso comune per settori come banking, PA e sanità.

La vulnerabilità agli attacchi quantistici

Mentre l’attenzione si concentra sulle vulnerabilità immediate, un’ulteriore minaccia sta prendendo forma. Gli attori ostili applicano già la tattica “Harvest now, decrypt later”, ovvero raccolgono oggi dati crittografati con l’intenzione di decifrarli quando i computer quantistici raggiungeranno la capacità necessaria. Per infrastrutture con cicli di vita di 15-20 anni, come le reti 5G, o per dati che mantengono valore nel tempo (sanitari, finanziari, governativi), questa non è una minaccia teorica e di poco conto.

Gli algoritmi di crittografia a chiave pubblica attualmente in uso – RSA, ECC e varianti – sono vulnerabili agli algoritmi quantistici. La domanda non è più se questi sistemi diventeranno obsoleti, ma quando: la comunità scientifica colloca l’orizzonte più probabile tra i 10 e i 15 anni. Secondo il World Economic Forum (WEF), oltre 20 trilioni di dollari di valore economico globale all’interno delle infrastrutture digitali sono attualmente esposti al rischio di decrittazione quantistica. Per le organizzazioni che gestiscono dati con sensibilità pluridecennale, aspettare la maturità del quantum computing significa essere già un bersaglio vulnerabile oggi.

Per un istituto finanziario di medie dimensioni, la compromissione di dati crittografati si traduce in esposizioni stimate tra 50 e 250 milioni di euro. Per settori nevralgici come gli energy provider o le telco, significa mettere a rischio infrastrutture core del valore di decine di miliardi. Per aziende il cui capitale è prevalentemente costituito da progetti riservati, dati di ricerca, design industriale mission critical (es: settore pharma, aerospace, defence, …) questa esposizione diventa non solo economica ma può compromettere la sicurezza di interi comparti industriali o paesi.

La crittografia post-quantistica

Il National Institute of Standards and Technology americano ha pubblicato nel 2024 i primi standard di crittografia post-quantistici: non più prototipi di laboratorio, ma algoritmi pronti per l’implementazione. Le organizzazioni non hanno più l’alibi della tecnologia: questa migrazione è già tecnicamente possibile e la finestra temporale per gestirla in modo ordinato si accorcia mese dopo mese.

Questa migrazione richiede un inventario completo di dove viene utilizzata la crittografia, quali algoritmi, quali dipendenze, e una valutazione del rischio specifica per ciascun asset: quali dati hanno valore a lungo termine, quali sistemi hanno cicli di vita estesi, quali compromissioni avrebbero impatto critico. Passi indispensabili anche perché le organizzazioni molto raramente hanno visibilità di quest’ambito. Le indagini di mercato sulla “Crypto-Agility” confermano questa lacuna: meno del 25% delle Big Company ha una lista e quindi visione dei propri asset crittografici.

In questo contesto una migrazione last minute o d’emergenza, ovvero pianificata solo quando diventerà inevitabile, è un’opzione rischiosa, oltre che con costi e margini di errore elevati.

L'articolo Cybersecurity: limiti e futuro dell’attuale crittografia proviene da Data Manager Online.

Negli ultimi anni il Digital Workplace è stato considerato la “naturale” evoluzione dei modelli organizzativi, prospettando — grazie alla crescente disponibilità di strumenti digitali — livelli superiori di collaborazione, flessibilità e produttività. Oggi, però, il quadro che si delinea è meno positivo. Le aziende hanno destinato investimenti importanti alla trasformazione digitale degli ambienti di lavoro, ma l’accelerazione nell’adozione di nuove piattaforme e applicazioni ha prodotto ecosistemi digitali avanzati, ma complessi da gestire e utilizzare, ricchi di possibilità, ma spesso carenti in termini di gestibilità, integrazione, coerenza e, quindi, di efficacia.

In altre parole, se da un lato la proliferazione di tool ha abilitato numerosi vantaggi, incluso il lavoro da remoto, dall’altro ha generato una frammentazione tecnologica che oggi rappresenta uno dei principali freni all’efficienza del mondo enterprise. È sufficiente pensare che secondo uno studio dell’Enterprise Strategy Group, il 44% delle organizzazioni negli Stati Uniti ha implementato da sei a dieci soluzioni di comunicazione e collaborazione e il 37% ne ha a disposizione oltre dieci.

Questa stratificazione incontrollata si traduce in criticità che incidono direttamente sulle performance di business, generando per prima cosa inefficienza operativa: il continuo “Context Switching” tra dashboard eterogenee rallenta i processi decisionali e compromette la visibilità end-to-end, rendendo più complessa la governance complessiva dell’ecosistema digitale.

Sul fronte della sicurezza, la mancanza di integrazione tra strumenti e domini tecnologici crea vere e proprie aree d’ombra in cui le minacce possono muoversi lateralmente senza essere intercettate tempestivamente. In assenza di una correlazione strutturata degli eventi, la postura di cybersecurity rimane inevitabilmente reattiva e frammentata, con un impatto diretto sul livello di rischio aziendale.

Inoltre, questa frammentazione si riflette in modo diretto sulla collaborazione cross-funzionale all’interno dell’organizzazione non mitigando, anzi amplificando i silos esistenti. In assenza di un layer tecnologico unificato, informazioni, processi e responsabilità rimangono confinati all’interno di domini funzionali distinti, ostacolando il coordinamento tra IT, security e il resto dell’organizzazione.

Non va inoltre trascurato l’impatto sulla Digital Employee Experience (DEX), che rischia di deteriorarsi in modo significativo. Secondo la ricerca “Gray Work Index 2024/2025” realizzata da Quickbase su migliaia di lavoratori, il 90% degli intervistati ha dichiarato di essere sopraffatto dal numero di applicazioni utilizzate quotidianamente.

In questo scenario, il Digital Workplace perde progressivamente il proprio ruolo strategico di abilitatore di integrazione, agilità organizzativa e superamento dei silos. Una dinamica che sta orientando un numero crescente di organizzazioni verso piattaforme integrate, capaci di garantire una gestione unificata ed efficace dell’intero ecosistema digitale aziendale.

Una scelta che non si traduce semplicemente in una riduzione del numero di fornitori, ma in una revisione radicale del modo in cui gli ambienti di lavoro digitali vengono gestiti, protetti e ottimizzati. L’obiettivo centrale di queste piattaforme è quella di mettere le aziende nella condizione di disporre di una visione unificata nella gestione degli endpoint integrando anche sicurezza e user experience.

Alcune soluzioni oggi disponibili sul mercato, come HCL BigFix Workspace+, recentemente riconosciuta da Gartner come Leader nel Magic Quadrant 2026 for Endpoint Management Tools, dimostrano concretamente l’efficacia di questo approccio grazie all’integrazione nativa di endpoint management, cybersecurity e Digital Employee Experience. Un unico framework tecnologico, progettato per garantire controllo, protezione e performance operative su larga scala.

Grazie alla piena visibilità sullo stato dei dispositivi, accesso a un monitoraggio proattivo delle performance e automatizzazione delle attività operative, questo tipo di soluzioni non si limita a risolvere problemi tecnici, ma trasforma il modo stesso in cui l’IT opera – da reattivo a proattivo – e può supportare l’operatività e il business.

Tutto ciò si traduce in minori costi operativi, migliore postura di sicurezza, maggiore soddisfazione dei dipendenti e integrazione interfunzionale. Ma, spingendo la prospettiva più avanti, un approccio unificato alla gestione del workspace digitale non rappresenta solo una risposta alle complessità attuali della frammentazione tecnologica, piuttosto un presupposto per affrontare le nuove sfide all’orizzonte.

Una piattaforma integrata degli endpoint consente infatti alle aziende di adattarsi rapidamente ai cambiamenti tecnologici e organizzativi, garantendo la scalabilità e la flessibilità necessarie per incorporare innovazioni come l’AI, senza dover ridisegnare l’intera infrastruttura. Inoltre, la visibilità centralizzata e la gestione coerente delle risorse tecnologiche permettono di governare con maggiore controllo e minore complessità, ambienti e modelli di lavoro sempre più distribuiti e dinamici.

L'articolo Oltre la frammentazione tecnologica: il valore di un approccio unificato alla gestione del Digital Workspace proviene da Data Manager Online.