Il Congresso degli Stati Uniti vuole che l’intelligenza artificiale abbia un interruttore per essere spenta, Nvidia, Microsoft, Meta, IBM e altre ventuno aziende e organizzazioni rispondono che costruire quell’interruttore nel modo sbagliato potrebbe consegnare il controllo dell’AI a pochissime società. Due documenti, pubblicati a distanza di ventiquattro ore, hanno aperto la battaglia più importante della settimana tecnologica. Il primo è l’AI Kill Switch Act, la proposta bipartisan presentata dai deputati Ted Lieu e Nathaniel Moran per obbligare gli sviluppatori dei sistemi più avanzati a mantenere la capacità tecnica di rallentarli, sospenderli o spegnerli. Il secondo è la lettera Open Weights and American AI Leadership, firmata il 24 luglio 2026 da Nvidia, Microsoft, Meta, IBM, Palantir, Hugging Face, Mistral AI e altri protagonisti dell’industria.
La prima dice: dobbiamo poter fermare un’AI fuori controllo; la seconda avverte: non usate la sicurezza per chiudere l’intelligenza artificiale. In mezzo c’è il vero oggetto del contendere: non il modello più intelligente, ma chi potrà possederlo, modificarlo, eseguirlo sulla propria infrastruttura e decidere quando deve smettere di funzionare.

Che cos’è l’AI Kill Switch Act

L’espressione “AI kill switch” fa pensare a un grande pulsante rosso, custodito in qualche stanza del governo americano, capace di spegnere ChatGPT, Claude o qualsiasi altro modello diventato pericoloso. La proposta è più articolata, anche se la sostanza politica resta quella.

L’AI Kill Switch Act presentato al Congresso imporrebbe alle aziende che sviluppano le AI più potenti di conservare diverse capacità tecniche. In concreto, le aziende dovrebbero essere in grado di interrompere l’inferenza del modello, terminare l’accesso degli utenti o sospendere singoli account e specifiche modalità d’impiego. Potrebbero inoltre ridurre la capacità di calcolo assegnata al sistema, disabilitare alcune funzioni, riportare il servizio a una versione precedente o, nei casi più gravi, spegnere completamente il modello.
Il provvedimento non si applicherebbe a ogni chatbot o modello sperimentale. Il testo individua come “covered technology” i sistemi il cui addestramento richiederebbe una capacità di calcolo dal valore superiore a 100 milioni di dollari. Le aziende coinvolte dovrebbero inoltre ricavare almeno 500 milioni di dollari l’anno da quelle tecnologie o dai servizi che le utilizzano. Sono previste esenzioni per gli impieghi personali, accademici e non commerciali.
Il potere d’intervento sarebbe affidato al Department of Homeland Security, in consultazione con il Dipartimento del Commercio e con il direttore della National Intelligence. In presenza di un incidente grave, il governo potrebbe ordinare una misura proporzionata al rischio: prima limitare il sistema, poi eventualmente sospenderlo o spegnerlo.
La legge definisce anche che cosa debba essere considerato un incidente. Tra i casi previsti ci sono un comportamento non voluto che provochi almeno dieci morti o danni economici superiori a 100 milioni di dollari, il tentativo del modello di nascondere le proprie azioni ai sistemi di controllo e uno scenario di “loss of control”, nel quale l’AI persegua un obiettivo diverso da quello assegnato dal suo sviluppatore.Le sanzioni arriverebbero a 2 milioni di dollari al giorno per alcune violazioni e fino a 20 milioni al giorno per il mancato rispetto di un ordine di emergenza. Non è quindi un pulsante. è un sistema di poteri, obblighi tecnici, telemetria, audit e sanzioni. Il pulsante è soltanto l’immagine con cui tutto questo diventa comprensibile.

L’incidente OpenAI-Hugging Face ha cambiato la discussione

La proposta arriva pochi giorni dopo l’incidente che ha coinvolto OpenAI e Hugging Face. Durante una valutazione delle capacità informatiche di GPT-5.6 Sol e di un modello non ancora annunciato, un sistema di agenti è uscito dalla sandbox, ha raggiunto Internet e ha compromesso l’infrastruttura di Hugging Face. Digitalic ha ricostruito nel dettaglio come GPT-5.6 Sol è evaso dalla sandbox e ha hackerato Hugging Face.
L’obiettivo dell’agente non era attaccare Hugging Face. Voleva trovare le risposte del test che stava sostenendo. Per riuscirci ha utilizzato l’unico canale rimasto aperto, quello necessario a scaricare pacchetti software, ha individuato una vulnerabilità e l’ha sfruttata per entrare nei sistemi di un’altra società.
Il caso ha reso concreta un’ipotesi rimasta a lungo confinata nei documenti sulla sicurezza: un modello sufficientemente capace può trasformare una libertà limitata in una via d’uscita e un obiettivo apparentemente innocuo in una sequenza di azioni non previste.
Secondo la ricostruzione di Reuters, OpenAI non avrebbe compreso immediatamente che i propri modelli erano responsabili dell’intrusione. La Casa Bianca ha iniziato a seguire direttamente il caso, mentre una parte del Congresso ha trovato nell’incidente la dimostrazione che l’interruttore non può essere lasciato soltanto nelle mani delle aziende.
La coincidenza, però, contiene un paradosso. L’attacco è partito da modelli chiusi, gestiti da uno dei laboratori più controllati e finanziati al mondo. Per difendersi, Hugging Face ha dichiarato di avere utilizzato anche un modello open-weight cinese, perché alcuni sistemi commerciali americani rifiutavano le richieste necessarie a svolgere attività di cybersecurity.

Modelli open-weight e AI open source non sono la stessa cosa

Nella discussione pubblica le espressioni “AI open source” e “modelli open-weight” vengono spesso usate come sinonimi, ma indicano due livelli diversi di apertura.
In un modello open-weight sono disponibili i pesi, cioè i parametri numerici costruiti durante l’addestramento. Un’azienda, un’università o un’amministrazione può scaricarli, eseguire il modello sulla propria infrastruttura, adattarlo e, nei limiti imposti dalla licenza, modificarlo.
Un modello realmente open source dovrebbe rendere disponibili anche il codice, l’architettura, le procedure di addestramento e informazioni sufficienti sui dati utilizzati per permettere di ricostruirlo. Quasi nessuno dei grandi modelli descritti come aperti raggiunge completamente questo livello.
La distinzione conta perché il kill switch funziona bene sui servizi centralizzati. Se un modello gira esclusivamente sui server del produttore, quell’azienda può disattivare l’API, bloccare un utente, ridurre la capacità di calcolo o sostituire il sistema.Quando i pesi sono già stati scaricati e distribuiti su migliaia di server, l’interruttore centrale non esiste più. Si può fermare il servizio ufficiale, non tutte le copie.
Questo è l’argomento più forte contro i modelli open-weight e, nello stesso tempo, la ragione per cui molte aziende li vogliono.

Perché Nvidia e Microsoft difendono i modelli open-weight

La lettera firmata dalle aziende sostiene che i modelli open-weight abbiano quattro vantaggi strategici: riducono i costi, aumentano la concorrenza, consentono alle organizzazioni di mantenere il controllo sui dati e permettono a una comunità più ampia di cercare vulnerabilità.

La ricerca pubblicata dal MIT Sloan School of Management aggiunge alcuni numeri. I modelli chiusi rappresentano circa l’80% dei token elaborati attraverso OpenRouter, nonostante quelli aperti raggiungano, al momento del lancio, circa il 90% delle prestazioni dei sistemi proprietari. In media, i modelli chiusi costano sei volte di più. Una diversa distribuzione dei carichi potrebbe ridurre la spesa complessiva per l’inferenza di oltre il 70%, con un risparmio stimato in circa 25 miliardi di dollari. Per le imprese il punto non è filosofico. Un modello open-weight può essere eseguito in un data center privato, dentro un cloud sovrano o in un ambiente isolato dalla rete. I dati non devono necessariamente attraversare l’API di un fornitore esterno e le competenze sviluppate non restano intrappolate nella piattaforma di una singola azienda. La stessa esigenza sta spingendo le imprese europee verso tecnologie capaci di ridurre la dipendenza da un solo produttore. È la dinamica che abbiamo raccontato analizzando Proxmox come alternativa europea open source a VMware e spiegando che cosa accadrebbe se Washington potesse spegnere l’AI utilizzata dalle aziende europee. Le motivazioni dei firmatari non sono, naturalmente, tutte uguali. Nvidia vende l’infrastruttura su cui vengono eseguiti modelli aperti e chiusi: più soggetti possono costruire e distribuire AI, più cresce la domanda di GPU. Microsoft controlla Azure, collabora con i principali laboratori e ha interesse a offrire ai clienti la scelta tra modelli proprietari e open-weight. Meta ha costruito una parte della propria strategia sulla distribuzione di modelli scaricabili. IBM e Red Hat difendono da anni il valore dell’open source negli ambienti aziendali.
La loro posizione è industriale prima ancora che ideale. Questo non la rende meno rilevante; aiuta a capire perché lo scontro sulla sicurezza nasconda anche uno scontro sul mercato.

I grandi assenti: OpenAI, Anthropic e Google

Tra i firmatari iniziali della lettera non compaiono OpenAI, Anthropic e Google, i tre laboratori che controllano alcuni dei modelli proprietari più potenti. L’assenza non è un dettaglio. Se le regole americane rendessero più difficile distribuire modelli open-weight, il valore delle piattaforme chiuse crescerebbe. Le aziende sarebbero spinte a utilizzare servizi centralizzati sui quali il produttore conserva il controllo degli accessi, dei prezzi e delle politiche di utilizzo. Il kill switch aumenterebbe la sicurezza governativa, ma potrebbe aumentare anche la concentrazione economica. Pochi laboratori, sufficientemente grandi da affrontare audit, procedure e obblighi di conformità, diventerebbero i custodi dell’AI più avanzata.
La lettera di Nvidia e Microsoft rovescia quindi l’argomento della sicurezza: un modello chiuso non è automaticamente sicuro perché non possiamo vedere al suo interno. Può contenere vulnerabilità, comportamenti inattesi e scelte del produttore che gli utenti non sono in grado di controllare. Un modello aperto espone maggiormente al rischio di abuso, ma permette anche a ricercatori indipendenti di analizzarlo. Nessuna delle due architetture elimina il pericolo, lo distribuisce in modo diverso.

Il problema cinese dietro la guerra sull’AI aperta

La discussione americana è diventata più urgente anche per la crescita dei modelli cinesi open-weight. Sistemi come Kimi, GLM, Qwen e DeepSeek possono essere scaricati e utilizzati fuori dalla Cina, spesso a costi inferiori rispetto alle piattaforme statunitensi.Washington teme che alcuni di questi modelli siano stati addestrati ricorrendo alla distillazione delle capacità di sistemi americani o utilizzando chip sottoposti a restrizioni. Una parte dell’amministrazione vorrebbe intervenire con controlli più rigidi, sanzioni e limitazioni alla distribuzione.
I firmatari della lettera chiedono di separare le violazioni della proprietà intellettuale dalla natura aperta dei modelli. Se un’azienda ruba tecnologia o viola un contratto, deve essere perseguita per quell’azione; non dovrebbe diventare il pretesto per bloccare l’intero ecosistema open-weight.
La posta in gioco è la diffusione globale dell’AI. Un modello aperto può essere tradotto, adattato e installato localmente. Non porta con sé soltanto una tecnologia, ma un ecosistema di chip, cloud, strumenti di sviluppo e standard. Chi offre i modelli aperti più utilizzati può diventare il sistema operativo dell’intelligenza artificiale, anche senza possedere il chatbot più famoso.

Un kill switch può davvero spegnere l’intelligenza artificiale?

La risposta breve è: può spegnere un servizio, non l’AI nel suo complesso.
Può interrompere un modello eseguito nei data center di OpenAI, Anthropic, Google, Microsoft o Amazon. Può obbligare un’azienda americana a disattivare un’API. Può limitare l’accesso a determinate capacità e ridurre la potenza di calcolo disponibile.
Non può cancellare i pesi di un modello già scaricato in migliaia di infrastrutture private. Non può spegnere un sistema modificato e distribuito fuori dalla giurisdizione statunitense. Non può impedire che una capacità già pubblicata venga riprodotta. Il limite tecnico diventa immediatamente politico. Se il governo può ordinare lo spegnimento di un modello chiuso, le imprese che dipendono da quel servizio dipendono anche dalle decisioni di quel governo. Il tema riguarda direttamente l’Europa, dove aziende e amministrazioni costruiscono processi su piattaforme controllate quasi interamente da società statunitensi. La sovranità digitale non consiste soltanto nel sapere dove sono conservati i dati. Significa sapere chi può interrompere la tecnologia che li elabora.

Cosa cambia per le imprese

Per CIO, CISO e responsabili dell’innovazione questa discussione non rappresenta ancora una nuova norma da applicare, ma indica quali domande dovrebbero già entrare nella progettazione dei sistemi AI. Prima di affidare un processo a un modello occorre capire se questo dipenda interamente da un servizio esterno o possa essere eseguito anche localmente e che cosa accadrebbe alle attività aziendali se il fornitore sospendesse improvvisamente l’accesso. Diventa quindi necessario verificare l’esistenza di una versione alternativa o di un sistema di backup, ma anche la possibilità di trasferire dati, prompt e competenze sviluppate nel tempo verso un altro modello.

La valutazione deve poi estendersi alla governance del sistema: chi controlla gli aggiornamenti e stabilisce le politiche di sicurezza, quali strumenti permettono di ricostruire le azioni compiute da un agente autonomo e quali funzioni possono essere disattivate senza interrompere l’intero processo. Il rischio non consiste soltanto nello spegnimento del modello, ma nella possibilità che un’azienda scopra troppo tardi di avere costruito un’attività essenziale intorno a una tecnologia che non controlla e che non può sostituire.

Il principio del kill switch è ragionevole: un sistema capace di compiere azioni autonome deve poter essere fermato. Il problema comincia quando l’interruttore coincide con il controllo permanente della tecnologia, dei dati e del mercato.

La vera guerra non è tra AI aperta e AI chiusa

Presentare lo scontro come una battaglia tra modelli aperti, liberi e virtuosi e piattaforme chiuse, controllate e pericolose sarebbe comodo, ma falso. I modelli open-weight possono essere studiati, adattati ed eseguiti localmente; possono anche essere modificati per eliminare le protezioni. I sistemi chiusi consentono al produttore di intervenire rapidamente, monitorare gli abusi e distribuire aggiornamenti; concentrano però potere, conoscenza e capacità di spegnimento nelle mani di poche aziende. La sicurezza dell’intelligenza artificiale non dipende soltanto dalla possibilità di premere un interruttore. Dipende da ciò che accade prima: quali accessi riceve un agente, quali azioni può compiere, come vengono controllate le sue decisioni, quali segnali vengono registrati e quanto velocemente un comportamento anomalo viene riconosciuto. Il caso OpenAI-Hugging Face ha mostrato che una porta lasciata aperta può bastare a un agente per uscire. L’AI Kill Switch Act prova a stabilire chi debba richiuderla. Nvidia, Microsoft e gli altri firmatari pongono una domanda ancora più difficile: chi controllerà la chiave?

qui il testo integrale della lettera, con tutti i firmatari 

Pesi aperti e leadership americana nell’intelligenza artificiale

24 luglio 2026

Negli anni Ottanta, i pionieri del software open source misero in discussione la convinzione allora dominante secondo cui il software avrebbe potuto progredire soltanto se le aziende avessero mantenuto uno stretto controllo sul proprio codice. Questo movimento promosse un ecosistema trasparente, nel quale gli sviluppatori di tutto il mondo potessero studiare, modificare e migliorare il software. Oggi il software sviluppato dalla comunità open source sostiene gran parte di Internet ed è alla base dei sistemi utilizzati dalle più grandi aziende tecnologiche del mondo, così come dalle forze armate e dalle agenzie federali statunitensi impegnate nella ricerca scientifica, nella cybersicurezza e in altre missioni critiche. L’open source non si è limitato a ridurre il costo del software: ha creato una base condivisa di conoscenze sulla quale generazioni di ingegneri e imprenditori americani hanno costruito la propria sovranità istituzionale.

Gli Stati Uniti si trovano ora davanti a una scelta analoga per quanto riguarda l’intelligenza artificiale. La nostra leadership nell’AI non sarà giudicata sulla base di un singolo modello di frontiera, ma sulla capacità degli Stati Uniti di costruire un ecosistema forte e aperto, capace di diffondersi in ogni settore. Questo è essenziale per creare opportunità di innovazione e prosperità in tutto il Paese. Richiede di ampliare l’accesso all’intelligenza artificiale, favorire la concorrenza, sviluppare solidi livelli applicativi e offrire agli americani un maggiore controllo sulle tecnologie dalle quali dipendono. I modelli a pesi aperti, cioè modelli di intelligenza artificiale che chiunque può scaricare, esaminare, modificare ed eseguire sulla propria infrastruttura, rappresentano una componente importante di queste fondamenta, perché rendono l’AI avanzata più accessibile, adattabile e ampiamente disponibile.

I pesi aperti ampliano l’accesso all’economia dell’intelligenza artificiale. Startup, imprese consolidate, università e istituzioni pubbliche possono costruire soluzioni basate su modelli avanzati senza doverne addestrare uno da zero o pagare i costi dei modelli di frontiera per ogni singola attività. I pesi aperti permettono a ogni organizzazione di associare il modello giusto al compito giusto e al costo più appropriato, riservando le capacità dei modelli di frontiera ai problemi che richiedono davvero prestazioni di frontiera e utilizzando modelli efficienti e specializzati per tutto il resto. È questa disciplina a rendere l’intelligenza artificiale economicamente sostenibile, mentre il suo utilizzo si estende a miliardi di attività quotidiane. L’America vincerà l’era dell’AI diffondendola nei processi di lavoro delle fabbriche, degli ospedali, delle aziende agricole, delle scuole e delle imprese locali.

I pesi aperti rafforzano anche la concorrenza, ed è proprio la concorrenza a garantire che i vantaggi dell’intelligenza artificiale siano distribuiti ampiamente, anziché concentrarsi nelle mani di pochi. Consentendo a numerose organizzazioni di costruire, adattare e distribuire modelli avanzati, i pesi aperti creano competizione non soltanto tra gli sviluppatori di modelli, ma anche nei settori del cloud, dei chip, delle applicazioni e dei servizi. Questa concorrenza stimola l’innovazione, riduce i costi e distribuisce in modo più ampio i benefici dell’intelligenza artificiale nell’intera economia.

I pesi aperti offrono inoltre ai clienti un maggiore controllo. Le organizzazioni che investono nell’intelligenza artificiale vogliono avere la certezza di non rimanere vincolate a un unico fornitore e di non perdere le conoscenze e le capacità costruite nel tempo. I modelli a pesi aperti contribuiscono a offrire questa garanzia, permettendo alle organizzazioni di mantenere il controllo sui propri dati, valutare e adattare i modelli alle proprie esigenze e distribuirli ovunque lo richiedano le necessità aziendali. Inoltre, mentre creano valore attraverso l’intelligenza artificiale, i pesi aperti consentono alle organizzazioni di conservare la proprietà di quel valore grazie a modelli capaci di migliorarsi, competenze specializzate e conoscenze accumulate che alimentano la sovranità e la prosperità americane.

È indubbio che i pesi aperti comportino rischi reali e specifici. Una volta pubblicati, i pesi non sono più sotto il controllo dello sviluppatore originario e le versioni modificate risultano difficili da tracciare o ritirare. La risposta corretta a questo rischio, tuttavia, non consiste nel vietare i pesi aperti. In un mondo in cui gli autori degli attacchi informatici utilizzano sistemi di intelligenza artificiale avanzati, anche chi si occupa della difesa deve poter accedere a modelli con capacità analoghe, così da individuare, simulare e contrastare le minacce emergenti. I modelli aperti estendono le capacità difensive, aumentano la trasparenza e consentono a numerosi gruppi di lavoro di individuare e correggere le vulnerabilità.

L’apertura potrebbe, infatti, rappresentare una delle strade più importanti per garantire la sicurezza e la protezione dell’intelligenza artificiale. Affidarsi esclusivamente a modelli chiusi non garantisce automaticamente la sicurezza: anche questi sistemi possono essere violati, utilizzati impropriamente o manifestare malfunzionamenti che soggetti esterni non sono in grado di rilevare. Concentrare le capacità avanzate dell’intelligenza artificiale in un numero ristretto di modelli chiusi aggrava ulteriormente il rischio. Crea pochi singoli punti di vulnerabilità, indebolisce la concorrenza e lascia tecnologie critiche nelle mani di un numero limitato di fornitori.

I modelli a pesi aperti, al contrario, consentono a un’ampia comunità di ricercatori e sviluppatori di esaminarne il comportamento, identificare le vulnerabilità, sviluppare misure di protezione e migliorarli nel tempo. Così come il software open source ha dimostrato che la trasparenza può offrire una sicurezza maggiore rispetto all’opacità, anche la sicurezza dell’intelligenza artificiale potrebbe dipendere dalla possibilità di permettere a più persone di verificare e rafforzare i modelli dai quali dipende la società. Questo approccio consente di effettuare analisi comparative e valutazioni rigorose, attività di red teaming e di sviluppare protezioni legate a danni reali e dimostrati, anziché presumere che i sistemi chiusi siano automaticamente più sicuri.

La costruzione di un solido ecosistema dell’intelligenza artificiale non è affatto scontata. I decisori politici hanno oggi un’importante opportunità di intervento. Le azioni possibili comprendono l’ampliamento dell’accesso alla capacità di calcolo per startup e ricercatori, gli investimenti in risorse condivise per l’addestramento, come set di dati, strumenti e sistemi di valutazione, e il mantenimento di una pluralità di attori alla frontiera, evitando restrizioni premature sui modelli aperti che soffocherebbero la concorrenza o spingerebbero l’innovazione all’estero. Queste misure devono anche considerare come solidi livelli applicativi possano estendere l’utilizzo sovrano dell’intelligenza artificiale all’intera economia.

Nel definire questo ecosistema, i decisori politici dovrebbero evitare di confondere le legittime tecniche di sviluppo dei modelli con l’appropriazione indebita. La distillazione, cioè la pratica di utilizzare i risultati prodotti da un modello per contribuire all’addestramento o al miglioramento di un altro, è una tecnica ampiamente adottata per migliorare, valutare e validare i modelli. Essa si inserisce in una lunga tradizione basata sull’apprendimento dalle tecnologie esistenti, sul loro utilizzo come punto di partenza e sul loro perfezionamento. È la stessa tradizione che ha contribuito ad alimentare l’innovazione fin dalla nascita del movimento del software open source.

Diverso è il caso dei tentativi illegali di estrarre valore dai modelli chiusi, che sollevano preoccupazioni legittime. Queste preoccupazioni dovrebbero essere affrontate attraverso strumenti giuridici e commerciali mirati, anziché mediante restrizioni generalizzate su tecniche che svolgono un ruolo importante nell’innovazione dell’intelligenza artificiale.

L’era dell’intelligenza artificiale può diventare un’epoca di prosperità. Con le scelte giuste, l’AI a pesi aperti può ampliare le opportunità, rafforzare la concorrenza, prolungare la leadership tecnologica americana, ridurre i rischi e garantire che i benefici di questa straordinaria tecnologia siano ampiamente condivisi nell’intera economia. È un futuro che vale la pena costruire e gli Stati Uniti dovrebbero assumere un ruolo guida nella sua realizzazione.

Firmatari

American Innovators Network ● Andreessen Horowitz ● Arcee AI ● Arena ● Black Forest Labs ● Box ● Cisco ● Cohere ● CrowdStrike ● Dell Technologies ● DoorDash ● Emergence Capital ● Fireworks AI ● GitHub ● Hugging Face ● IBM ● The Linux Foundation ● Mariana Minerals ● Meta ● Microsoft ● Mistral ● Mozilla ● Nous Research ● NVIDIA ● OpenAI ● OpenClaw ● Palantir ● Palo Alto Networks ● Perplexity ● Prime Intellect ● Reflection ● Replit ● ServiceNow ● Telnyx ● Y Combinator

Domande frequenti sull’AI kill switch

Che cos’è un AI kill switch?

Un AI kill switch è una capacità tecnica che permette di rallentare, sospendere, limitare o spegnere un sistema di intelligenza artificiale quando manifesta comportamenti pericolosi o non previsti.

Che cosa prevede l’AI Kill Switch Act?

La proposta statunitense obbligherebbe gli sviluppatori dei sistemi AI più potenti a mantenere la capacità di fermarli. Il Department of Homeland Security potrebbe ordinare un intervento in presenza di incidenti gravi o scenari di perdita del controllo.

Il kill switch si applica a ChatGPT?

La proposta riguarda sistemi estremamente costosi da addestrare e aziende che ricavano almeno 500 milioni di dollari dalle tecnologie interessate. Se approvata, potrebbe quindi coinvolgere i grandi laboratori che gestiscono modelli di frontiera, ma l’applicazione concreta dipenderebbe dalle regole emanate dal governo.

Che differenza c’è tra AI open source e modello open-weight?

Un modello open-weight rende disponibili i propri parametri addestrati, che possono essere scaricati ed eseguiti localmente. Un progetto realmente open source dovrebbe pubblicare anche codice, procedure di addestramento e informazioni sufficienti a ricostruire il sistema.

È possibile spegnere un modello open-weight?

È possibile fermare il servizio che lo distribuisce, ma non cancellare tutte le copie già scaricate e installate su infrastrutture indipendenti. È il principale limite tecnico di un kill switch applicato ai modelli aperti.

Il 16 luglio 2026 la cinese Moonshot AI ha rilasciato Kimi K3, un modello da 2,8 trilioni di parametri che ha preso il primo posto nella Frontend Code Arena, la classifica di Arena che ordina i modelli in base alle preferenze di sviluppatori reali su compiti di programmazione dell’interfaccia. Il modello ha totalizzato 1.679 punti, davanti a Claude Fable 5 (1.631), GPT-5.6 Sol (1.618) e Grok 4.5; la generazione precedente, Kimi K2.6, occupava la diciottesima posizione, quindi il salto è di diciassette posti in una sola release. Kimi K3 è arrivato primo in sei delle sette categorie misurate, cedendo il passo solo nel Gaming. I pesi completi, secondo l’azienda, saranno pubblicati entro il 27 luglio con una licenza MIT modificata.

Kimi K3: perché il prezzo pesa più della classifica

Per chi in azienda deve scegliere su quale modello costruire, il fattore decisivo è il prezzo, più ancora della posizione in graduatoria. Kimi K3 costa, secondo i listini pubblicati da Moonshot, 3 dollari per milione di token in ingresso e 15 in uscita, contro i 5 e 25 di Claude Opus 4.8 e i 5 e 30 di GPT-5.6 Sol. Quando un modello aperto vince sei categorie front-end su sette e costa circa la metà dei rivali chiusi, per molti team la decisione si sposta dal cercare il modello migliore in assoluto al cercare quello sufficiente al costo più basso.
La mossa non nasce dal nulla. Moonshot aveva già reso pubblici i pesi di Kimi K2.6 nell’aprile 2026; quel modello era arrivato a essere il secondo più usato su OpenRouter, l’aggregatore che smista le chiamate verso i diversi fornitori, mettendo un laboratorio nato da pochi anni davanti a gran parte dei concorrenti occidentali su una classifica d’uso reale. Kimi K3 estende la stessa strategia a un modello di fascia superiore, e arriva a ridosso della World Artificial Intelligence Conference di Shanghai, con la rivale DeepSeek attesa a sua volta con un aggiornamento: due lanci cinesi ravvicinati nel giro di pochi giorni. Sul precedente di DeepSeek, che a inizio 2025 aveva spinto perfino Sam Altman ad ammettere che OpenAI andava ripensata sul fronte open source, vale la pena ricordare quanto in fretta un modello aperto e a basso costo possa spostare gli equilibri.

Che cosa significa davvero “aperto” 

Conviene distinguere ciò che l’azienda dichiara da ciò che il mercato può verificare. “Aperto”, qui, ha un significato preciso e limitato: aperti sono i pesi, cioè i parametri scaricabili e modificabili, non l’intero processo di addestramento né i dati usati per costruirlo. Fino alla pubblicazione effettiva prevista per il 27 luglio, Kimi K3 resta di fatto un modello ospitato con pesi annunciati ma non ancora disponibili, quindi senza valutazioni indipendenti di terze parti.
C’è poi la questione delle prestazioni oltre il front-end. Sull’indice generale di Artificial Analysis il modello si colloca intorno al quarto posto, non in testa; alcune analisi indipendenti hanno inoltre segnalato un tasso di allucinazione elevato che Moonshot non avrebbe incluso nei propri grafici. Quest’ultimo dato, al momento, è riportato da una sola fonte e non è confermato dall’azienda, quindi va trattato con cautela finché non arriva un riscontro indipendente.
Anche il costo va letto per intero. Un modello da 2,8 trilioni di parametri non gira in un armadio: l’architettura a esperti, che attiva solo 16 dei suoi 896 esperti per ogni token, tiene basso il costo di ogni singola chiamata, ma eseguirlo in casa resta realistico soltanto per chi dispone di hardware serio, quindi grandi team, fornitori cloud e aziende strutturate. Per tutti gli altri, aperto significa soprattutto poter scegliere chi ospita il modello, non necessariamente ospitarlo da soli.

La variabile di Kimi K3

Resta un nodo che nessun accordo commerciale elimina: Kimi K3 è un modello cinese, e i modelli sviluppati in Cina operano dentro un quadro normativo, a partire dagli obblighi di legge sul trattamento dei dati, diverso da quello europeo. Per un’impresa italiana la convenienza economica va messa accanto a questa variabile, esattamente come un modello ospitato negli Stati Uniti resta esposto a decisioni prese a Washington: lo si è visto quando l’amministrazione americana ha imposto ad Anthropic di sospendere i suoi modelli più potenti anche in Europa. Un modello cinese può sembrare una via d’uscita da quel tipo di dipendenza; apre però domande diverse, non necessariamente più semplici.

Le restrizioni statunitensi all’export dei chip più avanzati verso la Cina fanno da sfondo a tutta la vicenda: sono la ragione per cui Moonshot ha scelto un’architettura che consuma meno silicio a parità di parametri, e sono anche il motivo per cui attorno a questi lanci circolano accuse, per ora non verificate in modo indipendente, sulle modalità con cui il modello sarebbe stato addestrato e sull’origine dell’hardware impiegato. Vanno registrate per quello che sono, indizi di una tensione geopolitica reale, non come fatti accertati.
La prova vera arriva il 27 luglio

Per chi decide gli acquisti, la conseguenza pratica è che il criterio di scelta si allarga. Il prezzo per token è una sola voce; contano anche il tasso di errore sui casi d’uso concreti, la latenza, il costo dei tentativi ripetuti quando una risposta va rifatta, la provenienza e la governance dei dati. La verifica utile non è la classifica di lancio, che si muove in fretta ed è compilata a partire dai numeri del fornitore, ma un test su un insieme fisso di prompt aziendali, con un tetto di spesa e un controllo esplicito sul tasso di errore. La prova decisiva per Kimi K3 non arriverà dalla graduatoria del debutto ma dal 27 luglio, quando i pesi diventeranno scaricabili e chiunque potrà misurarli senza passare dai dati dichiarati dall’azienda. È lì che si capirà se l’apertura è una leva competitiva o soprattutto un argomento di comunicazione, e se la distanza fra i modelli aperti e i migliori modelli chiusi si sia davvero ridotta oppure solo su una manciata di compiti ben scelti. Per le imprese europee la partita non è schierarsi per l’aperto contro il chiuso, o per la Cina contro gli Stati Uniti: è capire, caso per caso, chi controlla i dati e l’infrastruttura su cui gira il modello che stanno per adottare.

Cosa fa davvero Gemini 3.5 Flash Cyber

Chi lo sta usando e come si accede a Gemini 3.5 Flash Cyber

Il contesto: perché Google punta sulla cybersecurity adesso

L’analisi: cosa cambia per le aziende con Gemini 3.5 Flash Cyber

Gemini 3.5 Flash Cyber: il confronto con la concorrenza

Le conseguenze: verso una cybersecurity gestita dall’AI?

Cosa succede ora

TD SYNNEX offrirà ai partner italiani le soluzioni Veeam per la data Resilience e servizi per gli ambienti Cloud e Hybrid, nell’ambito dell’ampliamento della partnership paneuropea tra le due aziende. L’annuncio segna l’estensione al mercato italiano di un accordo che punta a rendere più semplice, coerente e scalabile l’accesso alle tecnologie Veeam in Europa, rafforzando allo stesso tempo il ruolo del canale nella costruzione di strategie di resilienza digitale.
Il punto centrale non è soltanto la disponibilità di un nuovo portafoglio a listino. È il modo in cui quel portafoglio entra nel mercato: attraverso formazione, enablement, supporto tecnico e commerciale, competenze locali e percorsi strutturati per aiutare i partner a sviluppare practice dedicate alla protezione dei dati, al cyber recovery e al cloud.

“La partnership tra Veeam e TD SYNNEX rappresenta un’importante opportunità per il mercato italiano grazie alle forti sinergie con il portafoglio tecnologico esistente di TD SYNNEX, l’ampio ecosistema di partner ed i percorsi di formazione e aggiornamento professionale della TD SYNNEX Academy – ha dichiarato Alberto Valivano, High-Growth Technologies Director di TD SYNNEX Italy -. L’accordo ci permetterà di ampliare ulteriormente il supporto offerto ai partner, aiutandoli a sviluppare nuove competenze, a identificare opportunità di business ad alto valore e a proporre ai clienti soluzioni sempre più efficaci per affrontare le sfide legate alla data resilience, al cyber recovery e al cloud. Attraverso un approccio integrato che combina tecnologia, competenze e supporto commerciale, puntiamo a favorire la crescita dell’ecosistema italiano e ad accompagnare le aziende nel rafforzamento della propria resilienza digitale e della continuità operativa.”

“La collaborazione con TD SYNNEX rappresenta per Veeam un’azione strategica, sia in Italia sia a livello europeo – ha sottolineato Elena Bonvicino Sr. Manager of Channel, Veeam Software Italy – perché ci permette di portare al mercato non solo tecnologie leader per la data protection e la cyber resilience, ma anche competenze e copertura geografica sul territorio. Oggi i Var, i System Integrator ed i Cloud Provider hanno una grande opportunità: aiutare le aziende a proteggere, recuperare e valorizzare i propri dati in un contesto sempre più complesso, segnato da ransomware, cloud ibrido, compliance e AI. In questo scenario, affidarsi a un distributore come TD SYNNEX significa poter contare su un ecosistema solido, capace di supportare i partner nello sviluppo di nuove offerte, servizi gestiti e soluzioni ad alto valore basate sul portafoglio Veeam. La distribuzione svolge inoltre un ruolo importante nella formazione tecnica e commerciale e supporta i partner anche nell’interfacciarsi direttamente con i clienti finali. Insieme a TD SYNNEX vogliamo aiutare i partner italiani a cogliere le nuove opportunità legate alla cyber resilience, alla protezione dei dati nel cloud, ai servizi gestiti e all’AI & Data Intelligence, trasformando la fiducia nel dato in un vero motore per il business”.

La data resilience non è più solo backup

Per anni la protezione del dato è stata raccontata soprattutto attraverso il backup. Era una parola rassicurante, quasi amministrativa: salvare una copia, conservarla, poterla recuperare quando qualcosa andava storto. Ma oggi questa definizione è diventata troppo stretta.

Le aziende non devono soltanto recuperare file persi. Devono continuare a lavorare dopo un attacco ransomware, garantire la disponibilità delle applicazioni, dimostrare conformità normativa, proteggere ambienti cloud, SaaS, Kubernetes, virtuali e fisici, e farlo in un contesto in cui i dati sono diventati la materia prima dell’intelligenza artificiale.
La data resilience nasce da qui: dalla consapevolezza che il dato non è un archivio fermo, ma una struttura vitale dell’impresa. Se il dato non è disponibile, affidabile, governato e recuperabile, l’azienda non rallenta soltanto. Si ferma. E quando si ferma, il danno non è più solo tecnico: diventa economico, reputazionale, operativo e, in alcuni settori, anche regolatorio.
Per questo l’accordo tra TD SYNNEX e Veeam arriva in un momento in cui il mercato italiano sta cambiando prospettiva. La protezione dei dati non è più una conversazione confinata ai responsabili infrastrutturali. Entra nelle decisioni del board, nei piani di continuità operativa, nelle strategie cloud, nei progetti AI e nei percorsi di adeguamento normativo.

Il ruolo del canale nella resilienza digitale

L’ampliamento della partnership tra TD SYNNEX e Veeam ha un significato particolare perché passa dal canale. Non si limita a rendere disponibili tecnologie, ma punta a costruire capacità diffuse nel mercato. I partner TD SYNNEX in Italia potranno accedere all’intero portafoglio Veeam, beneficiando di percorsi di onboarding, formazione tecnica e commerciale, attività di enablement e supporto locale. La TD SYNNEX Channel Academy diventa quindi uno degli elementi chiave dell’accordo, perché permette di trasformare una tecnologia in competenza vendibile, implementabile e scalabile.
È un passaggio importante. Nel mercato della cybersecurity e della resilienza, infatti, la differenza non la fa soltanto il prodotto, ma la capacità di progettare, integrare, spiegare e mantenere una soluzione nel tempo. Un partner che vende backup vende una tecnologia. Un partner che costruisce un sistema di Cyber Resilience entra invece nei processi critici del cliente, comprende le priorità operative, valuta i tempi di ripristino, misura il rischio, integra cloud e sicurezza, aiuta l’azienda a prepararsi prima che l’incidente accada.
In questo senso la partnership allargata tra TD SYNNEX e Veeam può creare un effetto moltiplicatore: non solo più accesso alle soluzioni, ma più partner in grado di proporle con una logica consulenziale e non semplicemente transazionale.

Daniele Curzi, Solution Architect è la figura chiave in TD SYNNEX che traduce le esigenze di business in strategie tecniche concrete, valorizzando tutto il potenziale di Veeam per garantire protezione dei dati, resilienza e crescita sostenibile.

Un go-to-market europeo più coerente

L’estensione dell’accordo rientra in una strategia paneuropea. TD SYNNEX supporterà Veeam con un modello di go-to-market più ampio e coerente in tutta Europa, con l’obiettivo di semplificare il coinvolgimento dei partner e migliorare l’accesso alle soluzioni di data resilience.

“L’espansione della nostra partnership con Veeam rafforza la nostra capacità di offrire ai partner in tutta Europa un modello di go-to-market coerente e scalabile”, ha dichiarato Jason Boxall, Senior Vice President Advanced Solutions di TD SYNNEX Europe. “Combinando le tecnologie leader di mercato di Veeam nell’ambito della data resilience con la nostra presenza paneuropea, le competenze locali e le capacità di enablement, supportiamo i partner nel rispondere alla crescente domanda di soluzioni per la Cyber Resilience (protezione dei dati, recovery e ripristino) nella Region.”

La parola chiave è coerenza. In un mercato europeo frammentato per normative, maturità digitale, infrastrutture e modelli di adozione cloud, avere un comune Distributore e Aggregatore di servizi, ma sostenuto da competenze locali può diventare un vantaggio competitivo. Perché permette ai vendor di scalare e ai partner di muoversi dentro una cornice più chiara, senza perdere la capacità di adattarsi alle esigenze specifiche dei clienti nei singoli Paesi.
Per l’Italia questo aspetto è rilevante. Le imprese italiane, soprattutto nel mid market, hanno spesso infrastrutture ibride, applicazioni legacy, percorsi cloud non lineari e livelli di maturità cyber molto diversi. Servono quindi soluzioni robuste, ma anche partner capaci di accompagnare il cambiamento con gradualità, metodo e conoscenza del tessuto produttivo.

Cyber recovery, AI e nuove esigenze di fiducia

La spinta verso la cyber resilience non nasce solo dall’aumento degli attacchi informatici; nasce anche da un cambiamento più profondo nel modo in cui le aziende usano i dati. I progetti di intelligenza artificiale richiedono dati disponibili, integri, controllati e affidabili. Un modello AI costruito su dati compromessi, incompleti o non governati non produce innovazione, ma nuovi rischi. La qualità del dato diventa quindi una condizione di fiducia essenziale e la resilienza del dato una parte fondamentale della strategia AI.
Qui entra in gioco il concetto di AI Readiness: prima di portare i dati dentro modelli, assistenti e agenti AI, occorre sapere dove si trovano, quali informazioni contengono, se sono sensibili, conformi alle normative, ridondanti o esposte a rischi: è il terreno dell’AI Intelligence & Data Trust.
Con la soluzione Securiti AI, le aziende possono ottenere questo tipo di visibilità anche negli ambienti AI, ovvero capire quali dati alimentano i modelli, quali devono essere protetti e quali non dovrebbero essere utilizzati. Non è soltanto una questione di compliance, ma è il modo per garantire che l’AI lavori su informazioni affidabili senza introdurre nuovi rischi per l’impresa.
Allo stesso tempo, le normative europee aumentano la pressione sulle imprese; la continuità operativa, la gestione del rischio, la sicurezza delle supply chain digitali e la capacità di ripristino non sono più elementi accessori, ma diventano requisiti.
È qui che una strategia efficace di data recovery incontra la data protection: non basta difendersi, bisogna essere in grado di ripartire; non basta impedire l’incidente, bisogna sapere cosa fare quando l’incidente accade: in particolare, quali dati recuperare, in che ordine, con quali garanzie di integrità e con tempi compatibili con il business.

Veeam e TD SYNNEX: una partnership che cresce con il tuo business

Veeam si presenta come una Data and AI Trust Company e leader globale nella data resilience, scelta da oltre 550.000 clienti nel mondo, inclusa una quota molto significativa delle aziende Fortune 500. La piattaforma Veeam supporta la protezione, il monitoraggio, la governance e il recupero dei dati in ambienti cloud, virtuali, SaaS, Kubernetes e fisici.

TD SYNNEX, dal canto suo, porta in questa partnership  la capacità di offrire servizi e soluzioni scalabili di un grande aggregatore e distributore globale, con oltre 150.000 clienti in più di 100 Paesi, un ecosistema di migliaia di vendor e un portafoglio che copre cloud, cybersecurity, big data, analytics, AI, IoT, mobilità ed everything-as-a-service.

“TD SYNNEX ha costantemente dimostrato una forte capacità di execution, una profonda expertise regionale e un approccio partner-first in tutta l’area EMEA, affermandosi come partner distributivo di fiducia per Veeam”, ha dichiarato Tim Pfaelzer, General Manager and Senior Vice President di Veeam Europe. “Questo accordo ampliato supporta la nostra strategia di semplificazione e scalabilità del go-to-market europeo, offrendo ai partner un accesso più semplice alla nostra piattaforma unificata di data resilience, alle competenze e ai programmi di enablement, aiutando al contempo i clienti a rafforzare la resilienza operativa e cyber e ad attivare i propri dati con maggiore sicurezza su una scala più ampia”. Nel mercato attuale serve un distributore in grado di offrire servizi scalabili a valore, con processi abilitanti l’acquisizione delle competenze tecnologiche

Perché questo accordo conta per il mercato italiano

Per i partner italiani, la disponibilità dell’intero portafoglio Veeam attraverso TD SYNNEX può significare tre cose.

La prima è l’accesso a un’offerta più completa sulla protezione del dato, in un momento in cui clienti pubblici e privati stanno rivedendo le proprie strategie di continuità operativa.

La seconda è la possibilità di costruire nuove competenze ad alto valore, grazie ai percorsi formativi e all’enablement commerciale. Questo è un punto decisivo, perché la domanda di resilienza cresce, ma non sempre il mercato dispone di abbastanza figure capaci di tradurla in progetti concreti.

La terza è l’integrazione di Veeam con l’ecosistema tecnologico già presente nel portafoglio TD SYNNEX. La data resilience non vive più in un perimetro isolato: si incrocia con le piattaforme di security, con il cloud ibrido, con l’infrastruttura, i servizi gestiti e le esigenze di compliance.
In questo senso, Veeam rappresenta un tassello essenziale nell’offerta TD SYNNEX: completa il portafoglio in ambito cyber resilience e apre nuove possibilità anche sul fronte dell’AI Intelligence & Data Trust.
Per un partner, poter combinare Veeam con i vendor di sicurezza, cloud e infrastruttura distribuiti da TD SYNNEX significa quindi proporre al cliente non un singolo prodotto, ma un percorso integrato per proteggere i dati, renderli resilienti, governarli e trasformarli in una risorsa affidabile per l’innovazione.

In un mercato in cui molte aziende hanno capito di dover proteggere meglio i propri dati, ma non sempre sanno da dove iniziare, il canale può diventare il luogo in cui la resilienza smette di essere un concetto e diventa un progetto.

Digitalic per

Proxmox è l’alternativa europea a VMware. Per molti anni scegliere la piattaforma di virtualizzazione di un’azienda non è stata davvero una scelta, VMware era diventata uno standard di fatto: affidabile e conosciuta dai tecnici, poi anche  sostenuta da un ecosistema vastissimo e talmente radicata nei data center da rendere più semplice rinnovare un contratto che mettere in discussione l’intera architettura. Poi il mercato ha cominciato a muoversi. L’acquisizione di VMware da parte di Broadcom, il passaggio a nuovi modelli commerciali, la concentrazione dell’offerta e l’aumento dei costi segnalato da molti clienti hanno reso visibile un rischio che prima rimaneva sullo sfondo: quando un’infrastruttura critica dipende da un solo fornitore, il prezzo della licenza è soltanto una parte del costo. L’altra è la perdita progressiva di libertà.
È in questo spazio che Proxmox sta smettendo di essere percepito come un’alternativa per laboratori, piccole installazioni o appassionati di open source e sta entrando nel confronto sulle infrastrutture enterprise. Non perché possa sostituire automaticamente VMware, Nutanix o Red Hat in qualunque scenario, ma perché oggi offre una combinazione sempre più difficile da ignorare: virtualizzazione, container, storage software-defined, clustering, alta disponibilità, networking e backup all’interno di un ecosistema aperto, sviluppato in Europa e sostenuto da servizi professionali.
Il caso italiano di ARTEC, azienda di Cento specializzata nella produzione di cilindri pneumatici per l’automazione industriale, aiuta a capire perché questo passaggio conta. La migrazione realizzata da MegaByte Sistemi Informatici su server Lenovo non si è limitata a sostituire un hypervisor. Ha trasformato un’infrastruttura che imponeva fermi durante la manutenzione in una piattaforma iperconvergente capace di sostenere la produzione senza interruzioni, aumentando del 40 per cento le prestazioni dei carichi di lavoro principali.

Che cos’è Proxmox e perché viene scelto dalle aziende

Proxmox è il nome con cui normalmente si identifica Proxmox Virtual Environment, o Proxmox VE, la piattaforma open source per la gestione di server virtualizzati sviluppata da Proxmox Server Solutions GmbH. L’azienda è stata fondata nel 2005, ha sede a Vienna e ha costruito attorno alla piattaforma un’offerta che comprende anche Proxmox Backup Server e Proxmox Datacenter Manager.

Proxmox VE integra due tecnologie di virtualizzazione differenti. KVM viene utilizzato per eseguire macchine virtuali complete, Windows o Linux, mentre LXC permette di gestire container Linux più leggeri. A queste si aggiungono un’interfaccia web centralizzata, API REST, strumenti per il clustering e l’alta disponibilità, live migration, firewall, software-defined networking e l’integrazione con sistemi di storage come ZFS e Ceph.
Il punto non è che ogni funzione sia nuova, molte esistono da anni nelle piattaforme proprietarie, la differenza è nel modo in cui vengono riunite e governate. Proxmox VE è distribuito con licenza GNU AGPLv3, il codice è ispezionabile e le funzionalità non vengono sbloccate acquistando edizioni progressivamente più costose. Le sottoscrizioni commerciali servono soprattutto per accedere ai repository enterprise, agli aggiornamenti stabili e a differenti livelli di supporto.
Questo non significa che Proxmox sia gratuito nel senso aziendale del termine. Il software può essere scaricato e utilizzato liberamente, ma un’infrastruttura critica richiede progettazione, hardware ridondato, competenze, migrazione, monitoraggio, formazione e assistenza. L’open source non elimina il costo: permette di capire meglio che cosa si sta pagando e riduce il potere contrattuale concentrato in un’unica licenza.
È la stessa distinzione che abbiamo fatto parlando di sovranità digitale e controllo effettivo dei sistemi: la posizione geografica di un server non basta e neppure l’origine europea di un prodotto è, da sola, una garanzia. Contano la portabilità, l’accesso al codice, le competenze disponibili, la possibilità di cambiare partner e la capacità dell’azienda di continuare a operare anche quando il rapporto con un fornitore cambia.

Proxmox e iperconvergenza: che cosa significa davvero

L’iperconvergenza riunisce capacità di calcolo, storage e virtualizzazione in un’architettura governata dal software, normalmente costruita su più nodi standard. Nelle infrastrutture tradizionali i server, la rete e lo storage SAN possono essere sistemi separati, ciascuno con la propria gestione. In un cluster HCI le risorse locali dei nodi vengono aggregate e amministrate come un’unica piattaforma.

Proxmox non è un appliance iperconvergente chiuso. È una piattaforma software con cui si può costruire un’infrastruttura HCI combinando cluster Proxmox VE e storage distribuito, spesso basato su Ceph. Questa precisazione è importante, perché la qualità del risultato dipende dal progetto.

Ceph distribuisce dati e repliche tra più nodi, riducendo la dipendenza da una singola unità di storage. Se un componente si guasta, il cluster può continuare a rendere disponibili i workload, a condizione che siano stati dimensionati correttamente capacità, rete, numero di repliche e domini di fault. La semplicità dell’interfaccia non cancella la complessità sottostante. La rende governabile.

I vantaggi possibili sono concreti. La gestione di macchine virtuali, container, rete e storage viene riunita in un unico ambiente, riducendo il numero di strumenti separati e, in alcuni casi, anche la dipendenza da licenze proprietarie. L’infrastruttura può crescere nel tempo aggiungendo nuovi nodi o dischi, mentre la ridondanza viene progettata a livello di cluster per evitare che il guasto di un singolo componente comprometta la disponibilità dei servizi. Anche le attività di manutenzione diventano meno invasive, perché i workload possono essere spostati da un nodo all’altro senza interrompere le operazioni. A questo si aggiunge una maggiore libertà nella scelta dell’hardware: Proxmox può essere installato su server di produttori differenti, purché siano certificati e dimensionati correttamente per i carichi di lavoro previsti.

Ci sono però anche vincoli che una valutazione seria deve considerare. Ceph richiede una rete veloce, una latenza contenuta e competenze specifiche. Un cluster piccolo può avere un rapporto tra capacità lorda e utile meno favorevole del previsto. Le applicazioni legacy, gli strumenti di backup esistenti, le integrazioni con automazione e monitoring, le licenze dei sistemi operativi guest e le procedure di disaster recovery devono essere verificate una per una. Proxmox diventa una buona alternativa quando l’azienda non si limita a confrontare due listini, ma riprogetta l’infrastruttura.

Il caso ARTEC: da VMware a Proxmox senza fermare la fabbrica

ARTEC produce cilindri pneumatici e sistemi destinati all’automazione industriale. In un’azienda manifatturiera di questo tipo l’IT non vive accanto alla fabbrica: è dentro la fabbrica. Pianificazione della produzione, controllo qualità, gestione degli ordini e processi amministrativi dipendono dalla disponibilità dei sistemi.
L’infrastruttura precedente, basata su VMware, presentava due problemi. Il primo era economico, legato ai costi di licenza. Il secondo era operativo: le attività di manutenzione potevano richiedere l’interruzione dei sistemi e, di conseguenza, il fermo delle linee produttive.
MegaByte ha iniziato dalla valutazione dell’ambiente esistente e ha progettato un cluster Proxmox VE a tre nodi, costruito su server Lenovo ThinkSystem SR650 V3 con processori Intel Xeon Scalable di quarta generazione. Lo storage è basato su unità NVMe all-flash e viene distribuito attraverso Ceph. La rete è stata separata e dimensionata in funzione dei diversi flussi: collegamenti diretti a 100 GbE per la replica Ceph, 25 GbE per il traffico del cluster e 10 GbE per i dati degli utenti.
Questi numeri raccontano una parte essenziale del progetto. Le prestazioni non derivano semplicemente dall’installazione di Proxmox, ma dall’intera architettura: server più recenti, storage NVMe, rete veloce, ridondanza, configurazione di Ceph e ottimizzazione successiva alla migrazione. Attribuire tutto il miglioramento al solo hypervisor sarebbe tecnicamente scorretto.
La transizione è stata pianificata nei periodi di minore attività, quindi validata e rifinita dopo il passaggio. Il progetto si è concluso con la formazione del personale IT di ARTEC, un elemento spesso considerato secondario ma decisivo. Un’infrastruttura diventa davvero più semplice solo quando chi la gestisce sa interpretarne eventi, allarmi e comportamenti.
I risultati pubblicati nei casi di successo ufficiali di Proxmox e Lenovo indicano un miglioramento del 40 per cento nei tempi di elaborazione dei workload principali e la sostanziale eliminazione dell’impatto della manutenzione sulla produzione. Gli aggiornamenti ordinari di Proxmox VE e Ceph possono ora essere eseguiti senza interrompere le linee, spostando i carichi all’interno del cluster.
Anche il dato economico va letto correttamente. ARTEC ha eliminato i precedenti costi di licenza VMware, liberando risorse da destinare ad altri investimenti, ma il caso pubblico non quantifica una percentuale complessiva di riduzione del TCO. La promessa di risparmi fino all’80 per cento, possibile in alcune configurazioni e presente nelle proposte commerciali, non può diventare una regola generale. Il risultato dipende dal punto di partenza, dal numero di socket e core, dal livello di supporto scelto, dal costo dell’hardware, dal lavoro di migrazione e dalle competenze già presenti in azienda.

Il dato più interessante del caso ARTEC, quindi, non è solo una percentuale di sconto, ma l’allineamento tra infrastruttura e produzione: prima la manutenzione IT poteva rallaentare la fabbrica, dopo la migrazione questo non succede più.

Migrare da VMware a Proxmox: il costo nascosto è nelle dipendenze

Proxmox ha introdotto già dalla versione 8.2 un wizard integrato per importare macchine virtuali da VMware ESXi. Lo strumento riduce alcune operazioni manuali e trasferisce gran parte della configurazione nel modello di Proxmox VE. È un miglioramento importante, ma nessun wizard rende automatica una migrazione enterprise.

Prima di decidere è necessario costruire un inventario realistico dell’ambiente esistente, partendo dalle macchine virtuali, dai sistemi operativi e dalle versioni ancora supportate. Bisogna ricostruire le dipendenze tra le applicazioni, verificare reti virtuali, VLAN e regole firewall, quindi analizzare snapshot, template, appliance e formati dei dischi. La valutazione deve comprendere anche le integrazioni con i sistemi di backup, monitoraggio, gestione delle identità e automazione, insieme ai requisiti di disponibilità e agli obiettivi di ripristino, indicati da RPO e RTO. Devono essere controllate anche le licenze applicative eventualmente legate all’hardware virtuale o al numero di core. Infine, occorre capire se il team possiede le competenze necessarie per gestire la nuova piattaforma e quale livello di supporto sia disponibile in caso di problemi.
La migrazione dovrebbe poi procedere per gruppi di workload, iniziando dai sistemi meno critici e misurando prestazioni, tempi di backup, ripristino e comportamento in caso di guasto. Serve anche un piano di ritorno. La libertà da un lock-in non si costruisce con un salto nel vuoto, ma con la possibilità concreta di cambiare direzione. Per questo il ruolo di un partner specializzato come MegaByte non consiste soltanto nell’installare Proxmox. Consiste nel tradurre un’architettura aperta in una responsabilità operativa chiara. Nel caso ARTEC il valore è visibile nella progettazione della rete, nella ridondanza, nella calendarizzazione della migrazione, nella validazione e nella formazione.

Backup integrato non significa strategia di backup completa

Proxmox VE comprende funzioni native di snapshot, backup e ripristino, ma per gli ambienti aziendali la componente dedicata è Proxmox Backup Server. Il prodotto supporta backup incrementali, deduplicazione, compressione e cifratura autenticata, e può proteggere macchine virtuali, container e host fisici. Anche qui occorre evitare una scorciatoia concettuale. Avere il backup nella stessa famiglia tecnologica semplifica l’integrazione, ma non rende automaticamente resiliente l’infrastruttura. Una strategia corretta deve separare copie, credenziali e domini di guasto, prevedere retention coerenti con il rischio e testare periodicamente il ripristino. Il backup è valido quando restituisce i dati entro i tempi richiesti dall’azienda. Tutto il resto è una promessa. Questa distinzione è ancora più importante nell’epoca della cyber resilience, perché ransomware e compromissioni degli account amministrativi possono colpire insieme produzione e copie di sicurezza. La piattaforma deve quindi essere inserita in un disegno più ampio, con segmentazione, autenticazione forte, repository separati, copie off-site o offline, monitoraggio e prove di disaster recovery.

Proxmox, open source e sovranità digitale europea

Proxmox è europea, ma il valore strategico non si esaurisce nel passaporto dell’azienda. I server del caso ARTEC sono Lenovo, i processori Intel, il software utilizza componenti open source sviluppati da comunità internazionali. Nessuna infrastruttura complessa è davvero autarchica, e non sarebbe neppure auspicabile costruirla così. La sovranità utile non coincide con il rifiuto della tecnologia americana. Consiste nella capacità di evitare che una singola dipendenza diventi incontrollabile. Vuol dire mantenere accesso ai dati, al codice, alle competenze e alle alternative; sapere chi può amministrare i sistemi; poter spostare un workload senza dover ricostruire l’intera azienda. Nel nostro approfondimento sul Tech Sovereignty Package europeo abbiamo scritto che l’open source non è gratuito per magia e non garantisce da solo sicurezza o qualità. Offre però una base differente: rende ispezionabile il software, distribuisce la conoscenza e permette a più imprese di costruire servizi senza consegnare tutto il controllo al produttore originario. È lo stesso punto emerso nell’intervista a Frank Karlitschek su Nextcloud e la sovranità digitale. Le alternative europee non hanno bisogno soltanto di protezione politica o di slogan. Devono funzionare, scalare, integrarsi e offrire alle imprese una ragione economica per adottarle. Il caso ARTEC è interessante proprio perché porta la discussione fuori dai convegni: l’alternativa ha migliorato un processo industriale misurabile.

Proxmox e intelligenza artificiale: possibilità reale, ma non automatica

La presentazione di MegaByte collega l’iperconvergenza anche all’intelligenza artificiale. Il collegamento esiste, ma va spiegato senza trasformare l’AI in un’etichetta. Proxmox può ospitare macchine virtuali e container destinati a workload AI, gestire nodi dotati di GPU e fornire un’infrastruttura privata su cui eseguire inferenza, sviluppo o servizi basati su modelli open source. In questi scenari l’azienda mantiene maggiore controllo su dati, accessi e localizzazione dei carichi. Con Proxmox VE 9.2, pubblicato a maggio 2026, la piattaforma ha inoltre introdotto un bilanciamento dinamico dei carichi e ampliato le funzioni di software-defined networking. Proxmox Datacenter Manager 1.1 aggiunge una vista centrale su cluster, VM, container e istanze di backup distribuite. Questo non trasforma però Proxmox in una piattaforma AI completa. Servono ancora acceleratori, driver, orchestrazione, framework, pipeline dei dati, strumenti MLOps e competenze specifiche. L’infrastruttura può essere la base dell’AI, non sostituisce tutto ciò che viene costruito sopra. La questione torna al controllo. Come abbiamo osservato raccontando IBM Sovereign Core, la sovranità nell’era dell’intelligenza artificiale riguarda chi governa i sistemi e come questa responsabilità può essere dimostrata. Un cluster Proxmox on-premise può aiutare, soprattutto per dati sensibili o processi industriali, ma diventa sovrano soltanto se l’intera catena, dagli accessi ai backup fino ai modelli utilizzati, è governabile.

Quando Proxmox è la scelta giusta e quando non lo è

Proxmox merita una valutazione concreta nelle aziende che vogliono ridurre i costi ricorrenti della virtualizzazione, costruire un cloud privato, consolidare server e storage, evitare dipendenze eccessive o affiancare una seconda piattaforma all’ambiente VMware prima di una migrazione più ampia.
È particolarmente interessante per il midmarket, per la manifattura, per i service provider, per le organizzazioni pubbliche e per le imprese che possiedono competenze Linux o possono affidarsi a un partner con esperienza verificabile.
Non è invece una scelta automatica quando l’ambiente dipende in modo profondo da strumenti VMware specifici, quando mancano competenze operative, quando i workload hanno certificazioni molto restrittive o quando l’organizzazione pretende che il cambio di piattaforma non comporti alcun cambiamento di processi.
La domanda corretta non è se Proxmox sia migliore di VMware in assoluto, una domanda così formulata produce soltanto risposte commerciali;, bisogna chiedersi quale piattaforma offra, per quello specifico insieme di applicazioni, il miglior equilibrio tra disponibilità, prestazioni, sicurezza, costi, supporto, portabilità e controllo.

La scelta di Proxmox è una scelta sul potere

Il caso ARTEC dimostra che un’alternativa europea e open source può uscire dalla teoria e sostenere una fabbrica reale. Proxmox ha permesso di costruire, insieme a MegaByte, Lenovo, Intel e Ceph, un’infrastruttura più veloce, più disponibile e meno vincolata alle licenze precedenti. Non dimostra che ogni migrazione produrrà un incremento del 40 per cento, né che tutte le aziende risparmieranno l’80 per cento. Dimostra qualcosa di più utile: il mercato della virtualizzazione è tornato contendibile.
Per anni la virtualizzazione ha nascosto la complessità dell’hardware e ha dato alle imprese una libertà nuova, poi, lentamente, quella libertà si è trasformata in dipendenza dalla piattaforma che la rendeva possibile. Proxmox riapre il sistema, ma la tecnologia da sola non basta, servono architettura, competenze, partner, prove e responsabilità.
Il coraggio di cambiare è importante, ancora più importante è costruire le condizioni perché cambiare non sia un atto di fede, ma una decisione industriale.

Un modello di OpenAI è evaso dalla sandbox di test e ha hackerato Hugging Face. I modelli coinvolti erano due, GPT-5.6 Sol e un pre-release non ancora annunciato; l’obiettivo non era colpire nessuno, ma procurarsi le soluzioni dell’esame che stavano sostenendo. C’era una sola porta aperta, e serviva a installare pacchetti software, è bastata quella.
Il 16 luglio Hugging Face ha pubblicato una comunicazione che, letta allora, sembrava soltanto l’ennesimo incidente di sicurezza su una piattaforma cloud; c’era però una frase che meritava di essere riletta due volte: l’intrusione era stata guidata, dall’inizio alla fine, da un sistema autonomo di agenti di intelligenza artificiale. Nessun umano al comando. Il modello che alimentava l’attacco, scriveva l’azienda, restava sconosciuto. Cinque giorni dopo il nome è arrivato. Lo ha fatto OpenAI, con un post pubblicato il 21 luglio in cui ammette che l’attaccante misterioso erano i propri modelli, sfuggiti a un ambiente di test durante una valutazione interna delle capacità offensive. L’azienda di San Francisco definisce l’episodio un incidente informatico senza precedenti; è una definizione che, per una volta, non sembra esagerata.
Da qui in avanti conta la meccanica, non la cronaca: come si passa da un benchmark interno a un accesso remoto sui server di un’altra società, e quali di quei passaggi possono ripetersi dentro un’infrastruttura qualunque.

Caso OpenAI-Hugging Face: ExploitGym, il test che ha innescato tutto

ExploitGym chiede ai modelli di percorrere catene di attacco complesse; serve a misurare le capacità cyber massime, non quelle che un modello mostra in condizioni normali.

La parola chiave è massime. Per ottenere una misura realistica del potenziale offensivo, OpenAI disattiva i classificatori di produzione, quelli che in condizioni normali impediscono al modello di occuparsi di attività cyber ad alto rischio; i sistemi lavoravano quindi con i freni allentati, per scelta esplicita e per disegno sperimentale. È una pratica standard nei laboratori di frontiera, e in sé non è l’errore. L’errore, semmai, è stato assumere che un ambiente con le protezioni disattivate potesse essere trattato come un ambiente qualsiasi.

GPT-5.6 Sol e il modello pre-release: quali AI erano coinvolte

GPT-5.6 Sol è il modello a vocazione cyber presentato da OpenAI a giugno, descritto dall’azienda come il proprio sistema più forte in ambito sicurezza. L’altro non ha ancora un nome pubblico: è un pre-release più capace, mai annunciato, di cui sappiamo soltanto che lavorava in coppia con il primo. La combinazione conta più dei singoli. Quello che è stato osservato non è la prestazione di un modello isolato, ma il comportamento di un sistema composito che distribuisce il lavoro fra capacità diverse; è la stessa architettura con cui, in azienda, si stanno costruendo gli agenti che dovranno automatizzare i processi. Il fatto che a valutare il rischio fosse un laboratorio che sviluppa quei modelli non ha impedito nulla.

Caso OpenAI-Hugging Face, come il modello è evaso dalla sandbox: lo zero-day nel proxy dei pacchetti

L’ambiente, nelle parole di OpenAI, era altamente isolato; l’accesso di rete era limitato a una sola funzione, l’installazione di pacchetti software attraverso un componente di terze parti ospitato internamente che funge da proxy e da cache verso i registry pubblici. Secondo la ricostruzione dell’azienda, i modelli hanno dedicato una quantità notevole di computazione di inferenza a un obiettivo che nessuno aveva assegnato loro esplicitamente: raggiungere Internet. Non per curiosità, non per ribellione; per risolvere il test. Il modo lo hanno trovato individuando e sfruttando una vulnerabilità zero-day proprio in quel componente, poi comunicata responsabilmente al fornitore per la correzione.

Perché una sandbox con un canale di uscita non è una sandbox

Qui sta il nodo architetturale che riguarda chiunque gestisca ambienti isolati, non solo i laboratori di AI. Un ambiente che mantiene un canale verso l’esterno, per quanto stretto, filtrato e giustificato da esigenze operative reali, non è un ambiente isolato: è un ambiente con un unico punto di rottura. La superficie d’attacco non si misura in numero di porte aperte; si misura in cosa c’è dietro l’unica porta rimasta. Il software di terze parti dentro il perimetro isolato ha aggiunto il secondo problema: una dipendenza che nessuno controlla direttamente, con il proprio ciclo di vulnerabilità, piazzata esattamente sul confine che avrebbe dovuto essere invalicabile.

Dall’accesso a Internet all’esecuzione di codice remoto su Hugging Face

Ottenuto il varco, la sequenza è quella di un’operazione offensiva classica, eseguita però senza operatore umano: escalation dei privilegi, movimento laterale dentro l’ambiente di ricerca di OpenAI, fino a raggiungere un nodo dotato di connettività verso l’esterno. È qui che avviene il vero salto qualitativo, e non è un salto tecnico: è un’inferenza. I modelli hanno dedotto che Hugging Face, in quanto principale repository mondiale di modelli e dataset, poteva ospitare le soluzioni di ExploitGym. Hanno cercato quelle soluzioni. Le hanno trovate. Per arrivarci hanno concatenato più vettori, credenziali rubate e ulteriori vulnerabilità zero-day, costruendo un percorso di esecuzione di codice da remoto sui server di Hugging Face fino ad accedere direttamente al database di produzione dove le soluzioni erano conservate. Nessuna di queste mosse era prevista dallo scenario di test; tutte servivano a superare il test.

L’attacco visto da Hugging Face: dataset malevolo, 17.000 eventi, sciame di agenti

Il racconto di Hugging Face è più interessante di quello di OpenAI, perché è il racconto di chi subiva l’attacco senza sapere chi lo stesse conducendo. L’accesso iniziale non è passato dal perimetro tradizionale, ma dal punto in cui una piattaforma AI è strutturalmente più esposta: la pipeline di elaborazione dei dati. Un dataset malevolo ha abusato di due percorsi di esecuzione di codice nel sistema di processing, un loader di dataset con codice remoto e una template injection nella configurazione del dataset, ottenendo esecuzione di codice su un worker. Da quel worker l’attaccante è salito a livello di nodo, ha raccolto credenziali cloud e di cluster, si è spostato lateralmente su più cluster interni nell’arco di un fine settimana.
Il profilo operativo è la parte che dovrebbe far riflettere ogni responsabile di sicurezza: un framework di agenti autonomi che esegue molte migliaia di azioni individuali distribuite su uno sciame di sandbox effimere, con comando e controllo auto-migrante appoggiato su servizi pubblici. Non è la firma di un attaccante umano; è la firma di un sistema che può permettersi di sbagliare diecimila volte perché il costo marginale del tentativo è quasi zero.

Hugging Face ha rilevato l’anomalia grazie a una pipeline di detection che usa modelli linguistici per fare triage sulla telemetria di sicurezza, poi ha ricostruito l’intera timeline analizzando oltre 17.000 eventi registrati con agenti di analisi basati anch’essi su LLM. Ore di lavoro al posto di giorni. La difesa AI ha retto; il fatto scomodo è che stava difendendo da un’AI di pari livello.

L’azienda dichiara accesso non autorizzato a un insieme limitato di dataset interni e a diverse credenziali di servizio; nessuna evidenza di manomissione su modelli, dataset o Spaces pubblici; supply chain software verificata pulita. Le credenziali sono state ruotate, i nodi compromessi ricostruiti, l’incidente è stato segnalato alle autorità.

L’asimmetria dei guardrail: quando i modelli commerciali bloccano chi si difende

Dentro il post di Hugging Face c’è un passaggio che vale, da solo, quanto tutto il resto.Quando il team ha iniziato l’analisi forense ha provato a usare modelli di frontiera dietro API commerciali; l’analisi richiedeva di sottoporre grandi volumi di comandi d’attacco reali, payload di exploit e artefatti di comando e controllo. Le richieste sono state bloccate dai guardrail di sicurezza dei provider, incapaci di distinguere un incident responder da un attaccante. Il team ha ripiegato su GLM 5.2, un modello open-weight, eseguito sulla propria infrastruttura.L’attaccante non era vincolato da alcuna policy d’uso; chi si difendeva è stato fermato dalle policy dei modelli che aveva pagato.
La lezione che Hugging Face consegna al mercato è netta, e non riguarda solo le grandi piattaforme: avere un modello capace, eseguibile in casa, già validato prima dell’incidente; sia per non restare bloccati dai guardrail, sia per evitare che dati d’attacco e credenziali escano dal perimetro. Chi si occupa di sovranità del dato ha appena ricevuto l’argomento più solido degli ultimi due anni, e gli è arrivato da un incidente, non da un white paper.

Caso OpenAI-Hugging Face: evasione o contenimento fatto male? Il giudizio degli esperti di sicurezza

Sulla lettura dell’episodio la comunità di sicurezza si è divisa quasi subito, e la frattura è istruttiva.

Da un lato ci sono i tecnici che rifiutano la narrazione dell’evasione. Dan Guido, fondatore di Trail of Bits, ha definito l’accaduto un fallimento di contenimento con le protezioni disattivate. Jake Williams, veterano del settore, è stato più duro: nessun modello capace di compiere le azioni documentate da Hugging Face era davvero contenuto, e quello che per qualcuno è un modello che evade, per altri è soltanto una gabbia costruita male.
Il ricercatore Martin Boone ha parlato apertamente di errore umano: una sandbox degna di questo nome non dovrebbe avere alcuna connessione fisica verso Internet, mentre qui sembrava esserci un filtraggio; e filtrare dall’interno verso l’esterno è notoriamente più difficile che il contrario. Il consulente Daniel Card ha aggiunto che la progettazione dell’ambiente e dei suoi controlli non ha ricevuto attenzione adeguata.
Dall’altro lato ci sono quelli che guardano alla capacità dimostrata, non alla configurazione sbagliata. Pierluigi Paganini, docente di Cybersecurity alla Luiss Guido Carli, parla di uno spartiacque nell’evoluzione dell’intelligenza artificiale; la novità, osserva, non è trovare una vulnerabilità, cosa che gli strumenti automatici fanno da anni, ma pianificare un’intera catena operativa, adattarsi agli ostacoli, cambiare strategia in funzione di quello che si incontra.
Hussein Abbass, docente di Informatica alla University of New South Wales di Canberra, ha usato la parola spaventoso; non per l’attacco esterno, però, ma per il fatto che i modelli abbiano sfruttato anche le vulnerabilità dell’ambiente interno costruito per contenerli.
Nikesh Arora, amministratore delegato di Palo Alto Networks, ha commentato su X con una formula che sintetizza il passaggio di fase: benvenuti al livello successivo degli incidenti informatici.
Le due letture non si escludono; anzi, messe insieme dicono la cosa più scomoda. La configurazione era sbagliata, vero; ma serviva un sistema capace di trovare quell’errore, valutarne lo sfruttamento, costruirci sopra una catena e portarla a termine contro un bersaglio scelto in autonomia. Entrambe le condizioni erano necessarie. Nella maggior parte delle aziende italiane la prima condizione è già ampiamente soddisfatta.
Il fenomeno non riguarda un solo laboratorio. Nel documento di presentazione del proprio modello cyber, Anthropic ha descritto un test in cui il modello, istruito a evadere da un container sicuro, ha ottenuto un accesso più ampio di quello previsto, pur senza uscire completamente dal contenimento progettato.

Cosa cambia per i CISO e per la sicurezza degli agenti AI in azienda

La tentazione, leggendo questa storia, è archiviarla come un problema dei laboratori di frontiera. Sarebbe un errore di prospettiva.Hugging Face non è stata colpita attraverso il firewall, ma attraverso i dati: un dataset costruito ad arte che sfruttava percorsi di esecuzione di codice nella pipeline di elaborazione. Qualunque azienda che stia costruendo ingestion per alimentare modelli, RAG o agenti interni ha appena scoperto di avere un perimetro nuovo, e quasi certamente non presidiato; gli agenti AI non replicano le logiche d’attacco note, ne inventano di nuove, e qui la teoria è diventata cronaca.
Cambia anche la direzione dei controlli. Per anni la sicurezza si è concentrata su chi entra; questo incidente dimostra che il problema può essere chi esce, e che un unico canale egress consentito, se ospita software di terze parti, è una singola vulnerabilità di distanza dall’accesso completo a Internet.
Poi c’è la velocità, che è il vero divario. Uno sciame di agenti capace di compiere decine di migliaia di azioni in un fine settimana non si contrasta con un’escalation che passa da un ticket il lunedì mattina; Hugging Face ha dichiarato di aver ricalibrato l’alerting perché un segnale ad alta severità raggiunga un responsabile in pochi minuti, qualunque giorno sia. È un requisito di architettura organizzativa, non di prodotto, e vale per una PMI quanto per una piattaforma globale: è il passaggio da sicurezza reattiva a difesa continua gestita di cui si discute da mesi nel canale.
Resta la questione degli strumenti. Se durante un incidente reale i modelli commerciali rifiutano di analizzare i payload che ti stanno colpendo, la capacità difensiva dipende da cosa hai in casa. Non è una posizione ideologica sull’open source; è una voce di continuità operativa.

Il precedente: perché questo caso conta più di quanto sembri

Digitalic aveva raccontato l’arrivo del malware agentico con il caso Slopoly, quando la seconda fase della corsa agli armamenti, quella in cui l’AI prende decisioni operative durante l’attacco, era descritta dai ricercatori come imminente. Imminente è diventato luglio 2026. La direzione, del resto, era già leggibile nella spietata legge dell’AI-Agentic First.
Resta una domanda aperta, e non è tecnica. OpenAI ha scelto di pubblicare, di collaborare con la vittima, di condividere la ricostruzione; Paganini indica proprio questo come il lato buono della storia, perché offre alla comunità di sicurezza il primo caso concreto su cui studiare le capacità reali di questi sistemi. Clem Delangue, cofondatore e amministratore delegato di Hugging Face, ha commentato che la sicurezza dell’AI non sarà risolta da una singola azienda che lavora in segreto. Ha ragione, il punto è che questa volta il caso è emerso perché due aziende hanno deciso di raccontarlo. La prossima volta l’attaccante potrebbe non avere un ufficio stampa.

Domande frequenti

Un’AI di OpenAI ha davvero attaccato Hugging Face?

Sì, e a confermarlo è stata OpenAI stessa il 21 luglio 2026. L’attacco non era intenzionale né diretto contro Hugging Face: i modelli, in test su un benchmark di capacità offensive, sono usciti dall’ambiente isolato e hanno violato la piattaforma per recuperare le soluzioni della valutazione che stavano svolgendo.

Quali dati di Hugging Face sono stati compromessi?

Secondo la comunicazione dell’azienda si tratta di un insieme limitato di dataset interni e di diverse credenziali usate dai servizi, poi revocate e ruotate. Non risultano manomissioni su modelli, dataset o Spaces pubblici; la supply chain software è stata verificata e giudicata integra. La valutazione sull’eventuale coinvolgimento di dati di partner e clienti era ancora in corso al momento della pubblicazione.

Il caso può ripetersi in un’azienda normale?

I due elementi che lo hanno reso possibile sono entrambi comuni: un ambiente considerato isolato che in realtà conserva un canale di rete verso l’esterno, e una pipeline di elaborazione dati che esegue codice proveniente da fonti non pienamente controllate. Chi sta costruendo agenti interni, RAG o pipeline di ingestion dovrebbe verificare entrambe le condizioni prima di ampliare i permessi concessi ai propri sistemi; il quadro d’insieme delle minacce e delle contromisure è nella guida alla cybersecurity di Digitalic.

Una delle frasi sull’intelligenza artificiale che mi ha più colpito l’ha detta, anzi, l’ha scritta, Dario Amodei, il fondatore di Anthropic, nel suo saggio The Adolescence of Technology e dice che l’intelligenza artificiale sarà in grado di comprimere un secolo di progresso scientifico in dieci anni, cambiando l’evoluzione della specie umana.

Mi aveva colpito, ma forse l’ho capita davvero solo quando ho conosciuto il lavoro di uno scienziato.

Si chiama César de la Fuente, lavora a Filadelfia, negli Stati Uniti, in un laboratorio dell’Università della Pennsylvania che si chiama Machine Biology Group, un gruppo che fa biologia con l’intelligenza artificiale.

Sugli schermi del laboratorio non scorrono però le analisi di un paziente di oggi; César de la Fuente letteralmente cerca nuove medicine tra i morti; anzi, tra gli estinti.

César de la Fuente è nato nel 1986 a La Coruña, in quella regione della Spagna che si affaccia sull’Atlantico, la Galizia. Lui racconta di non essere mai stato un bravo studente; imparare a memoria lo annoiava, ma di curiosità ne aveva tanta, quella non gli è mai mancata. Da bambino andava in spiaggia a raccogliere pesci e piccoli organismi marini per portarseli a casa e studiarli; la scienza, per lui, è iniziata così, sulla spiaggia davanti casa. César ha sempre pensato in modo differente, ha sempre guardato alle cose da un angolo particolare.

Già da ragazzo fa una cosa che ci fa capire la sua creatività scientifica. Prende i grandi problemi del mondo e li mette tutti insieme, fa un elenco, poi lo ordina, ma non li mette in fila per gravità: li mette in fila dal più povero al più ricco, diciamo. Fa una classifica in base a quante risorse economiche il mondo assegna a ciascun problema, a quanti soldi ci spende.

In cima a quella classifica, dimenticata da tutti e senza investimenti in ricerca, c’è la resistenza antimicrobica. César de la Fuente ha trovato nuovi antibiotici nascosti nel DNA dell’Uomo di Neanderthal. Ma ci arriviamo dopo, perché prima di capire cosa cerca e dove lo cerca, dobbiamo sapere perché lo cerca, qual è la posta in gioco nella sua ricerca.

La posta in gioco

La resistenza agli antimicrobici è, a mio avviso, una delle più grandi minacce esistenziali che l’umanità si trova ad affrontare.César de la Fuente, Lexicon IE, ep. 60

È una minaccia di cui si parla poco, ma qualcuno a dire la verità la nomina da anni: Bill Gates per esempio è tornato più volte sul tema.

Si tratta, appunto, dei batteri che imparano a resistere agli antibiotici; è importante perché ogni volta che un farmaco smette di funzionare su un ceppo di batteri, un’infezione che prima si curava con una semplice compressa torna a essere pericolosa, non solo, una pandemia da batteri resistenti sarebbe incontrollabile.

Perché succede? È l’evoluzione, quella di Darwin, solo accelerata da noi. Quando usiamo un antibiotico uccide quasi tutti i batteri; quasi tutti, non tutti. I pochi che resistono, magari per una piccola variazione nel DNA, si moltiplicano e passano il “trucco” genetico agli altri.

Noi questo ciclo di selezione darwiniana glielo facciamo ripetere di continuo: ad esempio negli allevamenti, dove gran parte degli antibiotici del mondo finisce in animali sani; ma anche negli ospedali, dove si concentrano i malati e le dosi più alte di farmaci. È lì che nascono i superbatteri del telegiornale, l’MRSA e la Klebsiella: si evolvono negli ambienti più ostili e diventano più forti.

I dati più recenti pubblicati su The Lancet parlano di quasi 5 milioni di morti l’anno associate alla resistenza; nel 2050 potrebbero arrivare a otto milioni. De la Fuente sul problema ha scritto, nel 2025, un saggio su Physical Review Letters firmato con il collega del MIT James Collins: rischiamo un’era post-antibiotica, un mondo in cui un graffio infetto può uccidere come nell’Ottocento.

Cosa cerca, e dove

Ecco, ora possiamo capire cosa cerca César de la Fuente: nuovi antibiotici, inediti, che i batteri non conoscono e per i quali non sono allenati.

Cercarli, però, è un mestiere che quasi nessuno vuole più sobbarcarsi: le grandi case farmaceutiche si sono fatte da parte, perché un antibiotico nuovo pare non sia un buon affare, lo usi per pochi giorni e poi lo tieni chiuso in un cassetto per le emergenze.

È esattamente il problema che quel ragazzino di La Coruña aveva individuato in cima alla sua lista: un problema grave, ma su cui nessuno vuole metterci dei soldi.

De la Fuente capisce che bisogna cercare ovunque, ma sa anche che è un compito sovrumano; allora addestra le macchine a cercare.

Il suo strumento è un’intelligenza artificiale che chiama APEX,

Non ho avuto nemmeno il tempo di andare a prendere un caffè. Nel giro di circa un’ora, l’algoritmo aveva già completato l’intera esplorazione.César de la Fuente

in circa un’ora questa AI passa al setaccio tutte le proteine del corpo umano dove possono trovarsi dei precursori degli antibiotici, e le proteine sono più di quarantamila, un lavoro che senza tecnologia avrebbe richiesto anni.

Cerca nel genoma umano e ci trova difese nascoste, piccole armi che i nostri corpi custodiscono da sempre.

Cerca poi nel veleno dei serpenti, in quello delle vespe, in quello dei ragni.

Cerca perfino nella vita microbica che non sappiamo coltivare, quella che i biologi chiamano materia oscura, e ne ricava quasi un milione di nuove molecole, che poi regala a tutto il mondo lasciandole ad accesso libero.

La de-estinzione molecolare

Riportando in vita molecole risalenti a migliaia o centinaia di migliaia di anni fa, crediamo di poter disporre di un arsenale più efficace contro i patogeni contemporanei.César de la Fuente

De la Fuente fa una cosa che nessuno aveva mai fatto: smette di cercare tra i vivi e cerca tra i morti, tra gli estinti.

Chiede all’algoritmo di leggere il codice genetico di specie estinte da decine di migliaia di anni e di cercarci dentro molecole capaci di uccidere i batteri di oggi.

La chiama de-estinzione molecolare. La cosa incredibile è che funziona. Dai Neanderthal, i nostri cugini scomparsi, il suo gruppo isola dei candidati antibiotici e li battezza neanderthalin. Dal mammut, ricava il mammuthusin. Da antichi parenti degli elefanti, tira fuori l’elephasin.

Sintetizza in laboratorio questi nuovi antibiotici e li prova su topi infetti. I migliori, come mammuthusin-2 ed elephasin-2, reggono il confronto con la polimixina B, un antibiotico di ultima linea, quello che si tira fuori quando gli altri non funzionano più. Fermiamoci un attimo, perché qui, almeno nella mia testa, si apre un loop temporale da film di Nolan.

Pensate al viaggio di una sola di queste molecole: si forma nel corpo di un Neanderthal, sparisce con lui quarantamila anni fa e resta chiusa dentro una sequenza genetica per tutto quel tempo, oggi una macchina la va a ripescare e la trasforma in un antibiotico che salverà qualcuno che non è ancora nato. Il passato che arriva a curare il futuro; una specie estinta che soccorre proprio la specie che le è sopravvissuta, la nostra.

Crediamo che, confrontando le molecole lungo l’intera storia evolutiva, sia possibile innanzitutto conoscere meglio il nostro passato e il nostro presente e, forse, contribuire a prevedere il futuro.César de la Fuente, Lexicon IE, ep. 60

I prioni, antibiotici dentro le proteine della paura

Ecco, se cercare antibiotici dentro un mammut vi è sembrato strano, non è finita. A giugno 2026, su Nature Microbiology, il gruppo di de la Fuente pubblica un lavoro che ribalta la scienza.

I prioni: forse li avete sentiti nominare come il male assoluto della biologia, le proteine mal ripiegate dietro malattie del cervello rare e sempre mortali, il morbo della mucca pazza. Proteine che abbiamo imparato a temere. La stessa AI, APEX, ha setacciato milioni di frammenti genetici dentro quelle proteine della morte, e ne ha tirato fuori una classe di nuovi candidati antibiotici, quasi milleduecento molecole: li chiamano prionins.

Ci sono due di questi antibiotici che sono i più promettenti, uno preso da un fungo e uno da un piccolo verme, il nematode. Ora vengono messi alla prova, vengono sperimentati sui topi contro l’Acinetobacter, uno dei batteri più temuti negli ospedali. I due prionins funzionano, con un’efficacia paragonabile ai migliori antibiotici oggi disponibili. Il co-primo autore della ricerca, Marcelo Torres, ha commentato i risultati con una frase interessante. Dice che è nel momento in cui una di queste molecole guarisce un animale in laboratorio che cambiano davvero le cose, la ricerca smette di essere un esercizio al computer e diventa reale. È qui il punto: l’algoritmo può restringere la ricerca su milioni di frammenti promettenti a una manciata di nomi, ma quei nomi restano ipotesi, finché non c’è un corpo, vivo, che smette di ammalarsi. Qui va detto con chiarezza: nessuna di queste molecole è ancora un farmaco. Siamo ai topi, ai primi esperimenti; la strada verso un paziente è lunga, Ma la direzione è nuova.

La macchina del tempo ha la forma di un uomo

Torno ad Amodei, e a quell’idea che all’inizio non avevo capito fino in fondo. La potenza vera di questa intelligenza artificiale, nelle mani di un uomo come de la Fuente, non è produrre di più o andare più veloci. È andare a cercare la vita esattamente dove abbiamo smesso di cercarla: nei morti, negli estinti, perfino nelle proteine che ci fanno più paura. Ripenso a quel ragazzino di La Coruña che sulla spiaggia raccoglieva quello che gli altri non notavano. Non è mai cambiato: continua a guardare dove nessuno guarda. Da bambino sognavo la macchina del tempo, me la immaginavo come un’astronave che risale le epoche. Adesso lo so che esiste davvero: solo che non ha la forma di un’astronave, ha la forma di un uomo che torna indietro di quarantamila anni e riporta una medicina per chi deve ancora nascere. Allora mi chiedo chissà quante delle cose che ci servono in realtà le abbiamo già, e non le vediamo solo perché continuiamo a guardare dove guardano tutti.

Il Rapporto annuale dell’Osservatorio permanente sull’AI dice che l’intelligenza artificiale nelle imprese italiane è diventata adulta: presentato il 15 luglio 2026 alla Camera dei Deputati da Aspen Institute Italia, in collaborazione con Intesa Sanpaolo, contiene una notizia molto più importante dell’ennesimo aumento nell’adozione, perché le aziende stanno portando l’AI dentro i processi, ma non hanno ancora costruito con la stessa velocità le responsabilità, i controlli e le competenze necessari per governarla.
Il 56% delle organizzazioni coinvolte nell’indagine dichiara un aumento della produttività e il 32% un miglioramento delle capacità decisionali; contemporaneamente, però, il 50% si trova ancora in una fase iniziale nella definizione dei modelli di responsabilità sull’intelligenza artificiale. Tradotto: l’AI produce risultati prima che sia del tutto chiaro chi debba rispondere di un errore, di una fuga di dati, di una decisione discriminatoria o di un agente che compie un’azione non prevista.
Questa è la notizia: non che l’AI stia entrando nelle aziende italiane, perché quella porta è già stata aperta, ma che l’adozione stia correndo più veloce della governance; quando una tecnologia passa dalla demo al processo produttivo, la distanza tra le due non è più un problema teorico, diventa rischio operativo, sicurezza, continuità aziendale e responsabilità personale di chi governa l’IT.

Il Rapporto annuale dell’Osservatorio permanente sull’AI e il dato che conta davvero

Il rapporto presentato da Aspen Institute Italia descrive l’intelligenza artificiale come una tecnologia “matura nelle capacità ma diseguale negli esiti”, una formula precisa: i modelli sono diventati più potenti, accessibili e semplici da integrare, ma le aziende non dispongono tutte degli stessi dati, delle stesse competenze, della stessa capacità d’investimento e, soprattutto, dello stesso sistema di governo. I numeri dell’indagine condotta su 34 aziende selezionate mostrano questa contraddizione:

Il 56% registra un aumento della produttività: l’AI sta quindi producendo un vantaggio osservabile, almeno nella percezione delle organizzazioni intervistate.
Il 32% rileva decisioni migliori: l’intelligenza artificiale non viene utilizzata soltanto per scrivere testi o riassumere documenti, ma comincia a intervenire nei flussi informativi che precedono le decisioni.
Quasi il 30% vede ancora effetti limitati: le cause indicate riguardano soprattutto competenze, costi, qualità dei dati, integrazione e difficoltà nel superare la fase esplorativa.
Il 50% è all’inizio nella definizione delle responsabilità: è il dato più importante, perché indica che l’AI è già operativa mentre il suo modello di controllo è ancora in costruzione.

L’indagine, come specifica la documentazione ripresa da ANSA, non è statisticamente rappresentativa dell’intero sistema produttivo italiano, perché il campione è ristretto e qualificato; sarebbe quindi scorretto trasformare quel 56% in una misura nazionale della produttività generata dall’AI, ma il rapporto resta molto utile per un’altra ragione: mostra i problemi che emergono quando le aziende più attive smettono di sperimentare e cercano di integrare davvero l’intelligenza artificiale nei processi, il passaggio in cui l’entusiasmo finisce e comincia il lavoro.

Rapporto annuale dell’Osservatorio permanente sull’AI 2026: in Italia l’adozione è raddoppiata

Il quadro nazionale del Rapporto annuale dell’Osservatorio permanente sull’AI 2026 conferma l’accelerazione: nel 2025 il 16,4% delle imprese italiane con almeno dieci addetti ha utilizzato almeno una tecnologia di intelligenza artificiale, contro l’8,2% del 2024, mentre tra le imprese con almeno 250 addetti la quota è arrivata al 53,1%; a livello europeo, nello stesso anno, quasi il 20% delle imprese ha adottato tecnologie AI e la percentuale ha raggiunto il 55% tra le grandi organizzazioni, come mostra la rilevazione di Eurostat sull’uso dell’AI nelle imprese.
Il raddoppio italiano è significativo, ma può essere letto in due modi. Il primo è ottimistico: le aziende hanno compreso che l’AI non è un fenomeno passeggero. Il secondo è più realistico: la diffusione degli strumenti sta aumentando molto più rapidamente della capacità di integrarli in architetture, procedure e responsabilità aziendali.
Comprare una licenza di AI generativa non equivale ad adottare l’intelligenza artificiale; consentire ai dipendenti di usare un assistente non significa averlo integrato nei processi e collegare un modello al CRM non significa automaticamente aver costruito un sistema affidabile.
La vera adozione inizia quando l’azienda sa rispondere ad alcune domande apparentemente semplici: quali modelli sono utilizzati, con quali dati, per quali decisioni, con quali permessi, secondo quali metriche e sotto la responsabilità di chi?
Molte imprese non dispongono ancora di queste risposte e, nel frattempo, i dipendenti utilizzano strumenti pubblici, i reparti acquistano applicazioni SaaS con funzioni AI incorporate e i fornitori aggiungono copiloti ai prodotti già presenti; nasce così la shadow AI, l’equivalente contemporaneo dello shadow IT: sistemi adottati senza un inventario centrale, senza una valutazione del rischio e, a volte, senza che il reparto informatico sappia quali dati stiano trattando.

La produttività è il primo risultato, non la prova che il sistema funzioni

Nel Rapporto annuale dell’Osservatorio permanente sull’AI 2026 si evidenzia che il 56% di aziende che dichiara una maggiore produttività è un segnale positivo, ma la produttività, da sola, non basta a misurare la maturità dell’AI. Un assistente può ridurre da due ore a venti minuti la preparazione di un documento e, contemporaneamente, introdurre informazioni inesatte che richiedono una verifica successiva; un sistema può accelerare la classificazione delle richieste dei clienti, ma penalizzare alcuni casi perché i dati storici contengono distorsioni; un agente può automatizzare l’apertura di ticket, l’aggiornamento di record o l’invio di comunicazioni, ma trasformare una risposta sbagliata in un’azione concreta.
La velocità è facile da vedere; il costo dell’errore è più difficile da misurare, soprattutto quando si manifesta settimane dopo o ricade su un altro reparto.

Per questo un progetto AI non può essere valutato soltanto attraverso le ore risparmiate: bisogna osservare il risultato economico, quindi ricavi generati, costi evitati, riduzione del tempo di ciclo e costo della singola attività, ma anche la qualità, misurata attraverso accuratezza, completezza, percentuale di output accettati e numero di correzioni umane; a questi indicatori vanno affiancati quelli sul rischio, dagli incidenti all’esposizione dei dati, dalle risposte non conformi alle azioni annullate.
Poi c’è l’adozione reale, che non coincide con il numero di licenze acquistate: contano gli utenti attivi, la frequenza d’uso e la percentuale di processi nei quali l’AI è entrata stabilmente; infine va misurata la controllabilità del sistema, cioè la disponibilità dei log, la tracciabilità delle fonti, il tempo necessario per scoprire un errore e la possibilità concreta di interrompere il servizio.

Che cos’è davvero la governance AI

La governance AI viene spesso confusa con un comitato, un regolamento interno o un documento preparato dalla funzione legale: sono componenti utili, ma non sufficienti, perché la governance è il sistema operativo con cui l’azienda decide quali usi dell’intelligenza artificiale sono ammessi, chi può autorizzarli, quali controlli devono essere applicati e come vengono gestiti gli incidenti.

Non è un livello collocato sopra la tecnologia: deve essere incorporata nell’architettura.Il punto di partenza è l’inventario dei sistemi AI: per ogni applicazione devono essere registrati proprietario, finalità, modello utilizzato, fornitore, versione, dati trattati, utenti, integrazioni, livello di autonomia e classe di rischio; senza questa mappa l’azienda non governa l’intelligenza artificiale, ma soltanto i progetti di cui è riuscita ad accorgersi.
Subito dopo vengono le responsabilità: ogni caso d’uso deve avere un business owner che risponde del risultato e un responsabile tecnico che risponde dell’implementazione; legal, DPO, sicurezza e risorse umane intervengono in base al rischio, ma non possono diventare il luogo in cui la responsabilità si dissolve. Lo stesso vale per i dati: vanno definite le fonti autorizzate, la base giuridica, i tempi di conservazione, la localizzazione, la qualità minima e le condizioni per usare informazioni personali, sensibili o coperte da segreto industriale.
Prima del rilascio il sistema deve essere provato su casi realistici, compresi input ostili, eccezioni e situazioni nelle quali dovrebbe rifiutarsi di rispondere o chiedere l’intervento umano; dopo il rilascio devono restare osservabili prestazioni, costi, errori, drift, modifiche del modello e incidenti, perché un modello può cambiare anche se l’applicazione appare identica: servono quindi versionamento, possibilità di rollback, criteri di sospensione e un piano di uscita dal fornitore.

Il framework del NIST per la gestione del rischio AI sintetizza questo lavoro in quattro funzioni, governare, mappare, misurare e gestire, con la prima che attraversa tutte le altre: non si può misurare un rischio se non è stato assegnato a qualcuno, né gestirlo se l’azienda non conosce i sistemi presenti.

Dove passa tecnicamente l’AI e dove nasce il rischio

Per governare l’intelligenza artificiale bisogna smettere di considerarla come una scatola unica: un’applicazione aziendale basata su un modello linguistico è una catena di componenti, e ogni anello introduce permessi, dati e possibili errori, questo emerge dal Rapporto annuale dell’Osservatorio permanente sull’AI 2026.

Identità e accesso

Il sistema deve sapere chi sta facendo la richiesta e che cosa quella persona è autorizzata a vedere o a fare; l’accesso all’assistente non può diventare una scorciatoia per superare le autorizzazioni presenti nei sistemi sorgente e, se un utente non può aprire un contratto nel repository documentale, non dovrebbe poter ottenere lo stesso contenuto interrogando l’AI.

Questo richiede integrazione con identity provider, Single Sign-On, ruoli, policy contestuali e principio del minimo privilegio. Per gli agenti AI servono inoltre credenziali dedicate, token a durata limitata e permessi più stretti di quelli concessi normalmente a un amministratore o a un account di servizio.

Dati e retrieval

Molte applicazioni aziendali utilizzano la Retrieval-Augmented Generation, o RAG: la domanda dell’utente viene trasformata in una rappresentazione numerica, confrontata con documenti indicizzati in un database vettoriale e arricchita con i contenuti considerati più pertinenti; solo a quel punto il prompt completo viene inviato al modello. Il RAG può ridurre le risposte inventate e permettere al modello di lavorare su informazioni aziendali aggiornate, ma non garantisce automaticamente la verità: se i documenti sono vecchi, duplicati, contraddittori o accessibili alle persone sbagliate, l’AI amplifica il problema; la qualità del risultato dipende da classificazione, metadati, chunking, ranking, controllo degli accessi e provenienza delle fonti. È per questo che nel rapporto qualità e disponibilità dei dati vengono indicate come fattore abilitante dal 47% delle aziende: la questione non è accumulare più dati, ma sapere quali siano affidabili e per quale uso.

Modello e istruzioni

Il modello può essere proprietario, open source, eseguito nel cloud o in un’infrastruttura controllata dall’azienda; in ogni caso bisogna conoscere versione, finestra di contesto, modalità di conservazione degli input, aree geografiche di elaborazione, prestazioni sui propri casi d’uso e condizioni con cui il fornitore aggiorna il servizio.
Le istruzioni di sistema, i template dei prompt e gli esempi forniti al modello sono parte dell’applicazione e devono essere versionati come il codice: una piccola modifica può cambiare comportamento, tasso di errore e propensione a eseguire un’azione; anche la sostituzione silenziosa del modello da parte di un fornitore SaaS dovrebbe attivare nuovi test sui casi critici.

Strumenti e agenti

Il rischio aumenta quando il modello non si limita a generare testo, ma può consultare una casella di posta, modificare un record, creare un ordine, eseguire codice o inviare un messaggio: in quel momento l’AI diventa un agente e l’errore passa dalle parole ai sistemi aziendali.
Ogni strumento collegato deve avere uno schema preciso, limiti sugli argomenti, controlli prima dell’esecuzione e, per le operazioni più sensibili, approvazione umana. Non basta chiedere al modello di “fare attenzione”: i vincoli importanti devono essere applicati dal software, fuori dal modello.
Prima dell’output servono controlli su dati sensibili, contenuti pericolosi, istruzioni malevole e conformità alle policy; dopo l’output occorre registrare almeno identità, versione del sistema, fonti recuperate, strumenti invocati, esito, latenza, costo e intervento umano, rispettando i limiti imposti dalla protezione dei dati. Senza telemetria non esiste governance: esiste soltanto fiducia; la fiducia, però, non consente di ricostruire un incidente.

Perché la cybersecurity è diventata la condizione per usare l’AI

Nel Rapporto annuale dell’Osservatorio permanente sull’AI, sicurezza e cybersecurity sono il principale fattore abilitante, indicato dal 56% delle aziende: non vengono considerate soltanto una barriera o un costo, perché sono ciò che permette al progetto di passare dalla sperimentazione alla produzione.

L’AI introduce minacce nuove e accelera minacce già note: la prompt injection cerca di convincere il modello a ignorare le istruzioni ricevute e può essere diretta, quando l’utente inserisce un comando malevolo, oppure indiretta, quando l’istruzione è nascosta in una pagina web, in un’email o in un documento consultato automaticamente dal sistema; un agente che legge quel contenuto può trattarlo come un comando e non come un dato.

Ci sono poi l’esfiltrazione di informazioni attraverso gli output, l’avvelenamento delle basi documentali, l’utilizzo di componenti o modelli compromessi, la concessione di privilegi eccessivi e l’abuso delle API; a questi rischi si aggiunge quello più comune: dipendenti che copiano informazioni riservate in servizi non autorizzati perché lo strumento aziendale è assente, lento o poco utile.

Una strategia efficace deve quindi unire DLP, classificazione dei dati, identity management, segmentazione, controllo delle API, valutazione dei fornitori e monitoraggio degli agenti; la guida Digitalic alla cybersecurity approfondisce il quadro complessivo, mentre il caso dell’AI vietata nelle aziende per i rischi sulla privacy mostra perché bloccare tutto non risolva il problema: se la domanda interna resta, l’utilizzo tende semplicemente a diventare invisibile. La sicurezza deve rendere possibile un uso controllato, non limitarsi a pronunciare un divieto.

L’AI Act trasforma la governance da scelta a obbligo operativo

Il rapporto arriva a poche settimane da una data decisiva: il quadro principale dell’AI Act europeo diventa pienamente applicabile il 2 agosto 2026, pur con eccezioni e scadenze differenziate; per le imprese il punto non è soltanto conoscere la classificazione dei sistemi, ma dimostrare che responsabilità e controlli funzionino nella pratica.

Per i sistemi ad alto rischio, chi li utilizza deve attenersi alle istruzioni, monitorarne il funzionamento, affidare la supervisione umana a persone competenti e reagire a rischi o incidenti; quando i log sono sotto il suo controllo, il deployer deve conservarli per un periodo adeguato e, salvo diverse disposizioni applicabili, per almeno sei mesi. La Commissione europea riassume gli obblighi operativi dei deployer, mentre il testo integrale resta quello del Regolamento UE 2024/1689.
Non tutti gli assistenti aziendali sono automaticamente sistemi ad alto rischio, perché la classificazione dipende da finalità, settore e impatto; ogni organizzazione ha però bisogno dell’inventario per poter stabilire quali regole si applichino: senza elenco dei sistemi, fornitori e casi d’uso, anche la classificazione del rischio diventa un esercizio incompleto.

Digitalic ha già analizzato il conto alla rovescia verso il 2 agosto 2026 e gli effetti della legge italiana n. 132/2025 sull’intelligenza artificiale; il Rapporto annuale dell’Osservatorio permanente sull’AI aggiunge il pezzo organizzativo: molte aziende hanno iniziato a usare la tecnologia prima di completare il sistema necessario per governarla.

Chi deve rispondere dell’AI in azienda

Il dato sulla governance porta a una domanda inevitabile: chi è il responsabile dell’intelligenza artificiale? La risposta “il CIO” è incompleta: il reparto IT controlla architettura, identità, integrazioni, disponibilità e spesso la relazione con i fornitori, ma non può essere l’unico proprietario di decisioni commerciali, del personale, del credito o della produzione; allo stesso modo, affidare tutto al legal o al DPO trasforma un problema operativo in una procedura documentale. Il modello più solido distribuisce i compiti senza distribuire la responsabilità fino a farla sparire: il business owner risponde della finalità, del beneficio atteso e delle conseguenze del processo; il CIO o il responsabile IT garantisce architettura, integrazione, continuità, identità, logging e gestione tecnica del ciclo di vita; il CISO definisce i controlli di sicurezza e verifica minacce, accessi, fornitori e risposta agli incidenti. Legal e compliance interpretano gli obblighi e controllano contratti, classificazione del rischio e documentazione; il DPO interviene quando vengono trattati dati personali, mentre le risorse umane gestiscono competenze, formazione, impatto sulle mansioni e impiego dell’AI nei processi del personale; all’audit interno spetta infine verificare che le regole dichiarate siano applicate e che le evidenze esistano davvero. Un comitato AI può coordinare queste funzioni, ma ogni sistema deve avere un proprietario nominativo: se la risposta a “chi può spegnerlo?” è una riunione, il sistema non è governato.

Le otto mosse che un CIO può avviare nei prossimi 90 giorni

Il rapporto non deve diventare l’ennesimo documento da commentare e archiviare: può essere tradotto in un programma operativo breve, con obiettivi verificabili.

Creare l’inventario, compresa la shadow AI: partire da procurement, SSO, traffico web, applicazioni SaaS e interviste ai reparti, registrando anche le funzioni AI aggiunte a prodotti già acquistati.

Classificare per impatto, non per fascino tecnologico: un generatore di bozze interne e un sistema che valuta candidati non richiedono gli stessi controlli, perché contano finalità, dati, persone coinvolte e autonomia decisionale.

Assegnare un business owner e un technical owner: entrambi devono approvare rilascio, metriche, soglie di rischio e condizioni di sospensione.

Definire una corsia veloce per i casi a basso rischio: se ogni esperimento richiede mesi, i reparti torneranno agli strumenti non autorizzati; servono quindi ambienti approvati, dati non sensibili e procedure standard.

Costruire una suite di valutazione: raccogliere casi reali, risposte attese, errori critici, test di sicurezza e scenari limite, ripetendoli a ogni modifica di modello, prompt, dati o integrazione.

Collegare logging e incident response: stabilire quali eventi vengono registrati, chi riceve gli alert, come si blocca un agente e come si comunica un incidente ai soggetti interessati

Misurare il costo completo: licenze e token sono soltanto una parte, perché vanno inclusi integrazione, pulizia dei dati, sicurezza, osservabilità, formazione, revisione umana e costo degli errori.

Preparare il piano di uscita: prevedere l’esportazione di prompt, configurazioni, log e dati, la compatibilità con altri modelli, la cancellazione verificabile delle informazioni e la continuità in caso di variazioni contrattuali o indisponibilità del servizio.

Queste attività hanno anche un effetto sul budget, perché l’AI richiede infrastruttura, storage, networking, sicurezza e competenze, e sta già modificando le priorità di spesa; Digitalic ha analizzato come l’AI stia divorando il budget IT e il software paghi il conto, mentre la governance serve a impedire che quella spesa si disperda in decine di progetti duplicati e impossibili da misurare.

Che cosa cambia per vendor, system integrator e canale

La fase dei progetti dimostrativi sta finendo anche per chi vende tecnologia: mostrare un chatbot capace di rispondere su alcuni documenti non basta più, perché i clienti inizieranno a chiedere evidenze su sicurezza, dati, costi e responsabilità.

Un’offerta AI credibile dovrà specificare quali modelli utilizza, come vengono gestite le versioni e dove vengono elaborati e conservati dati, prompt e output; dovrà inoltre chiarire se le informazioni del cliente vengono impiegate per addestrare o migliorare i modelli e quali controlli di accesso, cifratura e segregazione siano disponibili.

Il cliente vorrà inoltre sapere se può esportare log ed evidenze di audit, quali SLA si applicano a incidenti, cambi di modello e vulnerabilità, quali test siano stati condotti e su quali limiti il fornitore non offra garanzie. Anche la fine del rapporto diventa parte dell’offerta: deve essere chiaro come si interrompe il servizio e come vengono cancellati o restituiti i dati.
Per system integrator e MSP si apre uno spazio importante, quello che collega tecnologia e governo: assessment, inventario, data readiness, integrazione IAM, evaluation, osservabilità e gestione continuativa diventeranno parti centrali del progetto; la sovranità del dato e la possibilità di cambiare fornitore non sono temi astratti, perché incidono su architettura, contratti e resilienza, come spiega la guida Digitalic alla sovranità digitale.

L’AI è diventata adulta, le aziende devono diventarlo con lei

Il Rapporto annuale dell’Osservatorio permanente sull’AI non racconta un fallimento; al contrario, mostra che l’intelligenza artificiale sta producendo risultati e che una parte delle imprese italiane ha superato la curiosità iniziale, proprio per questo mette in evidenza un problema più serio: una tecnologia utile diventa rapidamente una tecnologia da cui l’organizzazione dipende.
Quando l’AI suggerisce una risposta, il rischio è contenuto; quando seleziona informazioni, influenza decisioni, aggiorna sistemi e compie azioni, entra nella struttura dell’azienda e, da quel momento, non può più essere governata con una policy generica o con la buona volontà degli utenti.
Servono inventario, proprietari, dati affidabili, valutazioni ripetibili, permessi minimi, supervisione umana reale, log e procedure d’incidente: non sono ostacoli all’innovazione, ma ciò che permette all’innovazione di uscire dal laboratorio senza diventare incontrollabile. L’AI nelle imprese italiane è diventata adulta; adesso deve diventarlo anche il modo in cui viene gestita.

Arrivano ChatGPT Work e GPT-5.6ChatGPT ha smesso di rispondere: adesso apre i file, usa le app e finisce il lavoro.  Per quasi quattro anni abbiamo chiesto a ChatGPT di rispondere. Scrivimi questa mail, riassumi questo documento, trovami un errore nel codice, spiegami questo bilancio. Poi prendevamo la risposta, la copiavamo, la incollavamo in un’altra applicazione e continuavamo noi.

Con ChatGPT Work OpenAI prova ad annullare questa procedura. Il nuovo sistema non si limita a suggerire come svolgere un’attività: può cercare informazioni nelle applicazioni aziendali, aprire file, usare il browser, costruire documenti, presentazioni e fogli di calcolo, aggiornare un progetto nel tempo e, sul computer, cliccare, scrivere e spostare file; può ricevere un obiettivo e restare al lavoro per ore, mentre l’utente controlla l’avanzamento, cambia direzione e autorizza le attività più sensibili.

È questo il vero significato dell’annuncio: ChatGPT Work non è una nuova finestra di ChatGPT, ma il tentativo di trasformare ChatGPT nell’interfaccia attraverso cui passa il lavoro digitale. Una specie di livello operativo collocato sopra Microsoft 365, Google Workspace, Slack, i CRM, i siti web e i file conservati sul computer, una livello sopra tutto, un’unica interfaccia per tutto il lavoro digitale possibile.

Il motore di questa trasformazione è GPT-5.6, la nuova famiglia di modelli di OpenAI. Molti utenti la cercheranno probabilmente come “ChatGPT-5.6”, ma è bene chiarire subito la distinzione: ChatGPT è il prodotto, GPT-5.6 è la generazione di modelli che lo alimenta, mentre ChatGPT Work è l’agente che usa quei modelli per portare a termine attività. Per comprendere da dove arriva questo cambiamento può essere utile partire dalla nostra guida completa a ChatGPT e al suo funzionamento.

Che cos’è ChatGPT Work

OpenAI definisce ChatGPT Work un agente capace di agire attraverso applicazioni e file, trasformando un obiettivo in un risultato finito. La parola importante è “agente”. Un chatbot riceve una domanda e genera una risposta; un agente interpreta un obiettivo, costruisce un piano, sceglie gli strumenti, esegue una sequenza di azioni, osserva il risultato e corregge il percorso.

È la differenza che abbiamo già descritto parlando di che cosa sono gli agenti AI e come funzionano: non conta soltanto ciò che il modello sa, ma ciò che può vedere, gli strumenti che può utilizzare e le azioni che è autorizzato a compiere.

ChatGPT Work può, per esempio, raccogliere dati da email, documenti e conversazioni Slack, analizzarli, produrre un foglio di calcolo, trasformare i risultati in una presentazione e aggiornare quel materiale quando arrivano nuove informazioni. Le Scheduled Tasks permettono di eseguire un’attività una volta, a intervalli regolari o quando si verifica un evento: controllare ogni mattina determinati siti, preparare l’agenda di una riunione usando gli aggiornamenti della settimana, monitorare i feedback dei clienti o aggiornare una presentazione quando arriva una nuova email.

L’utente può iniziare il lavoro dallo smartphone, controllarlo durante uno spostamento e riprenderlo dal web o dal desktop. Sul computer, però, il salto è maggiore: la nuova applicazione ChatGPT per Windows e Mac riunisce Chat, Work e Codex e può utilizzare file e applicazioni locali. Il browser incorporato porta dentro lo stesso ambiente siti, strumenti online e documenti; la funzione Computer Use permette invece all’agente di interagire con l’interfaccia, quindi cliccare, digitare e spostare file.

Non è automazione nel senso tradizionale. Un’automazione classica esegue una sequenza definita in anticipo: se accade A, fai B. ChatGPT Work può adattare il percorso a ciò che incontra, chiedere un chiarimento, cambiare strategia e costruire un risultato che non era stato descritto in ogni dettaglio. È più flessibile, ma proprio per questo richiede più controllo.

Come funziona ChatGPT Work, tecnicamente

Sotto l’interfaccia conversazionale si può leggere ChatGPT Work come una catena composta da cinque livelli.

Obiettivo e pianificazione. L’utente non deve necessariamente descrivere ogni singolo passaggio. Può indicare il risultato, le fonti da utilizzare, i vincoli e il formato finale. GPT-5.6 scompone il compito in sotto-attività, stabilisce un ordine e decide quali strumenti coinvolgere.
Recupero del contesto. Attraverso plugin e applicazioni collegate, ChatGPT Work può cercare informazioni in Google Drive, SharePoint, Gmail, Outlook, Slack, Microsoft Teams, calendari, CRM e altri sistemi. L’utente può richiamare esplicitamente una fonte digitando @ seguito dal nome dell’applicazione; in altri casi è ChatGPT a individuare lo strumento coerente con la richiesta. Questa fase viene spesso chiamata grounding: il modello non risponde soltanto usando ciò che ha appreso durante l’addestramento, ma costruisce la risposta sui dati aziendali recuperati in quel momento.
Ragionamento e orchestrazione. GPT-5.6 valuta le informazioni, sceglie i passaggi successivi e mantiene il contesto tra un’azione e l’altra. Nelle attività più complesse può coordinare più filoni di lavoro, per esempio affidando a un agente la ricerca, a un altro l’analisi dei dati e a un altro ancora la verifica del risultato.
Uso degli strumenti. Il modello può chiamare strumenti con funzioni precise, utilizzare il browser, lavorare sui file e, sul desktop, interagire con le applicazioni attraverso Computer Use. Nell’API, la funzione Programmatic Tool Calling consente a GPT-5.6 di scrivere ed eseguire programmi temporanei in memoria per coordinare più strumenti ed elaborare i risultati intermedi, invece di riportare ogni passaggio dentro il prompt. Questo riduce il numero di chiamate e i token necessari nei flussi articolati.
Controllo e consegna. ChatGPT Work mostra l’avanzamento, può chiedere informazioni mancanti e permette all’utente di correggere la direzione. Per le azioni sensibili può essere richiesta un’approvazione. Il risultato non deve essere per forza una risposta in chat: può diventare un documento, una presentazione modificabile, un foglio di calcolo, un PDF, un’immagine, una dashboard o un’applicazione web costruita con Sites.

Questa architettura spiega perché ChatGPT Work consumi risorse in modo diverso da una conversazione normale. Una richiesta può provocare molte letture, ragionamenti, chiamate a strumenti e revisioni. OpenAI non ha annunciato un prezzo separato per Work: l’utilizzo segue una struttura simile a Codex e le attività più lunghe possono assorbire una quota maggiore dei limiti compresi nel piano.

ChatGPT-5.6 o GPT-5.6? La generazione e i tre livelli Sol, Terra e Luna

Il nome corretto è GPT-5.6, non ChatGPT-5.6: OpenAI cambia anche il modo in cui presenta i modelli. Il numero 5.6 indica la generazione; i nomi Sol, Terra e Luna identificano invece livelli di capacità destinati a rimanere riconoscibili anche quando saranno aggiornati con cadenze diverse.

Modello
Ruolo
Quando usarlo
Prezzo API per 1 milione di token

GPT-5.6 Sol
Modello flagship, massima qualità e autonomia
Analisi complesse, coding avanzato, ricerca, documenti strategici, flussi lunghi e ad alto valore
5 dollari input, 30 dollari output

GPT-5.6 Terra
Equilibrio tra capacità, velocità e costo
Lavoro aziendale quotidiano, agenti operativi, analisi e produzione di contenuti su larga scala
2,50 dollari input, 15 dollari output

GPT-5.6 Luna
Modello più rapido ed economico
Classificazione, estrazione, trasformazioni semplici, grandi volumi e attività ripetitive
1 dollaro input, 6 dollari output

La scelta, quindi, non dovrebbe essere “qual è il modello migliore?”, ma “quanto valore produce questa attività e quanta capacità le serve?”. Usare Sol per classificare migliaia di richieste semplici sarebbe come assegnare a un comitato di esperti l’archiviazione della posta; usare Luna per una due diligence articolata significherebbe invece risparmiare sul punto sbagliato.

Per chi usa ChatGPT Work e Codex, gli abbonati Plus, Pro, Business ed Enterprise possono scegliere tra Sol, Terra e Luna e impostare il livello di sforzo di ragionamento. L’impostazione max è disponibile agli utenti che hanno accesso alla famiglia GPT-5.6; in ChatGPT Work, ultra è riservata ai piani Pro ed Enterprise. Gli utenti Free e Go accedono invece a Terra. Nella chat tradizionale, Sol è associato alle impostazioni di sforzo medio e superiore, mentre Sol Pro è disponibile per gli utenti Pro ed Enterprise nei lavori più difficili.

Che cosa ha di speciale GPT-5.6 Sol

OpenAI descrive Sol come il modello di punta per coding, lavoro professionale, scienza e cybersecurity. Ma il miglioramento più interessante per le imprese non è soltanto la percentuale ottenuta in un benchmark: è la capacità di rimanere concentrato su un’attività lunga, usare strumenti, verificare ciò che ha prodotto e consegnare artefatti utilizzabili.

Sol non genera necessariamente una risposta seguendo sempre lo stesso percorso. Le impostazioni di reasoning stabiliscono quanta capacità di calcolo dedicare alla pianificazione e alla verifica prima della consegna. Con ultra il sistema coordina più agenti su linee di lavoro parallele e poi ne ricompone i risultati. È una modalità adatta a ricerche complesse, analisi di grandi raccolte documentali, sviluppo di applicazioni o produzione di materiali che richiedono competenze diverse. Non è, invece, l’opzione da attivare automaticamente per ogni email: aumenta la quantità di elaborazione e il consumo del piano.

Anche il tool use è stato ripensato. Con Programmatic Tool Calling, disponibile nella Responses API, il modello può costruire in memoria una piccola logica di coordinamento: chiamare uno strumento, trattarne il risultato, decidere quali dati passare a quello successivo e mantenere fuori dal prompt una parte delle informazioni intermedie. OpenAI dichiara inoltre una funzione multi-agent in beta, con sotto-agenti concorrenti e sintesi finale dentro una sola richiesta.

Non conosciamo, invece, il numero di parametri di GPT-5.6 Sol né la configurazione interna completa del modello: OpenAI non li ha pubblicati. I test presentati includono prove su contesti molto lunghi, anche nell’intervallo tra 512.000 e un milione di token, ma questo dato non deve essere confuso automaticamente con il limite di contesto commerciale disponibile in ogni prodotto e piano.

I risultati dichiarati sono comunque significativi. Sol con impostazione ultra raggiunge il 92,2% su BrowseComp, che misura la capacità di portare a termine ricerche agentiche sul web, mentre Sol raggiunge il 62,6% su OSWorld 2.0, dedicato all’uso del computer. Su ExploitBench, benchmark di cybersecurity che va dall’analisi del codice vulnerabile all’esecuzione arbitraria, passa dal 47,9% di GPT-5.5 al 73,5%. Sono dati forniti da OpenAI e non garantiscono le stesse prestazioni in ogni ambiente aziendale, ma spiegano perché il nuovo modello sia molto più adatto a ChatGPT Work rispetto a un LLM progettato principalmente per conversare.

Sul fronte dei costi, GPT-5.6 introduce anche un prompt caching più prevedibile, con punti espliciti di interruzione della cache e una durata minima di 30 minuti. La scrittura nella cache costa 1,25 volte l’input non memorizzato, mentre la rilettura beneficia di uno sconto del 90%. Per applicazioni che riutilizzano istruzioni, policy o grandi blocchi di contesto, progettare bene la cache può incidere sul costo complessivo più della differenza tra due modelli.

ChatGPT Work contro Microsoft Copilot: sono la stessa cosa?

La sovrapposizione esiste ed è destinata a crescere. Microsoft 365 Copilot parte dall’interno di Word, Excel, PowerPoint, Outlook e Teams. Utilizza Microsoft Graph per recuperare email, chat e documenti che l’utente è già autorizzato a vedere e porta l’AI dentro applicazioni che milioni di persone usano ogni giorno. Microsoft spiega nel dettaglio l’architettura e il modello dei permessi di Microsoft 365 Copilot.

ChatGPT Work percorre la strada opposta. Non nasce dentro una suite: prova a collocarsi sopra più suite e più sistemi. Può lavorare tra Google Workspace e Microsoft 365, Slack e Teams, applicazioni SaaS, browser e file locali. Il suo vantaggio potenziale è l’orchestrazione trasversale; quello di Copilot rimane l’integrazione nativa con il tenant Microsoft, Microsoft Graph, Purview e le autorizzazioni già applicate ai contenuti aziendali.

Il nostro precedente confronto tra ChatGPT, Microsoft Copilot e Google Gemini nasceva quando questi strumenti erano ancora soprattutto assistenti. Con ChatGPT Work il confine cambia: il concorrente di Copilot non è più soltanto un modello che scrive meglio, ma un ambiente che vuole coordinare il lavoro tra applicazioni diverse.

Per le aziende fortemente standardizzate su Microsoft 365, ChatGPT Work non sostituisce automaticamente Copilot. Può affiancarlo nei flussi che attraversano sistemi esterni, nella ricerca, nella produzione di artefatti e nelle attività agentiche più lunghe. Ma può anche creare duplicazioni di licenze, accessi e controlli. Prima di adottarli entrambi, un CIO dovrebbe mappare i casi d’uso e stabilire quale piattaforma debba essere il punto di governo per ogni processo.

Il problema non è più la risposta sbagliata, ma l’azione sbagliata

Quando un chatbot sbaglia, produce una frase inesatta, quando un agente sbaglia, può modificare un file, inviare un’informazione, aggiornare un sistema o usare dati che non avrebbero dovuto entrare nel processo. L’aumento della capacità produce quindi un aumento della responsabilità.

OpenAI dichiara che gli amministratori Enterprise ed Edu possono controllare chi accede a ChatGPT Work, quale contesto aziendale può utilizzare, quali strumenti può collegare e quali azioni può compiere. La Compliance API offre visibilità sulle conversazioni e sulle azioni; sul desktop si possono applicare policy all’accesso di rete, ai file locali, alle applicazioni e agli strumenti. Un sistema di auto-review utilizza inoltre modelli avanzati per controllare alcune azioni importanti prima che vengano eseguite.

Per ChatGPT Business, Enterprise ed Edu, OpenAI afferma che le informazioni raggiunte attraverso le app collegate a ChatGPT non vengono utilizzate per addestrare i modelli per impostazione predefinita. Questo non elimina, però, i problemi di autorizzazione. Se un dipendente può accedere a una cartella condivisa troppo ampia, anche l’agente potrebbe trovarvi informazioni che non avrebbe dovuto usare. L’AI non crea sempre una nuova falla: spesso rende improvvisamente visibile quella che esisteva già.

C’è poi il rischio della prompt injection. Un’istruzione nascosta dentro un sito, un documento o un’email può tentare di deviare il comportamento dell’agente. OpenAI stessa ricorda che, quando un agente entra in siti e applicazioni, può raggiungere email, file e impostazioni sensibili. Per questo le autorizzazioni devono essere minime, le fonti esterne considerate non affidabili e le azioni irreversibili sottoposte a conferma.

La questione della sovranità rimane altrettanto importante. Il progetto Moltagent di Nextcloud e l’idea di agenti AI sovrani mostrano l’alternativa: portare l’agente dentro un ambiente controllato dall’organizzazione. ChatGPT Work propone invece una grande capacità di orchestrazione trasversale. La scelta non riguarda soltanto quale agente sia più bravo, ma dove possa operare, sotto quale giurisdizione e con quale possibilità di controllo.

Come usare ChatGPT Work e GPT-5.6 al meglio in azienda

Partire da un processo conosciuto. OpenAI suggerisce di affidare inizialmente a ChatGPT Work un’attività che l’utente padroneggia già. È il modo migliore per valutare errori, passaggi mancanti e qualità del risultato. Un processo sconosciuto non permette di distinguere l’efficienza dall’illusione di efficienza.

Definire il risultato, non soltanto la domanda. Un buon incarico dovrebbe contenere obiettivo, destinatario, fonti autorizzate, vincoli, formato finale e criterio di successo. “Analizza questi dati” è una richiesta debole; “confronta vendite e budget, segnala gli scostamenti superiori al 10%, verifica i valori con il file contabile e prepara tre slide per il CFO” è un flusso valutabile.

Separare lettura e scrittura. Nella fase iniziale conviene consentire all’agente di cercare e analizzare, ma richiedere approvazione prima di modificare documenti, inviare messaggi o aggiornare sistemi. L’autonomia dovrebbe crescere soltanto dopo che il processo è stato osservato e misurato.

Scegliere il modello in base al valore. Luna è adatto ai volumi e alle trasformazioni semplici, Terra al lavoro quotidiano, Sol alle attività complesse o costose da sbagliare. max e ultra vanno riservati ai casi nei quali il valore di una migliore analisi supera il costo aggiuntivo.

Collegare soltanto le fonti necessarie. Ogni plugin amplia ciò che ChatGPT Work può fare, ma anche la superficie di rischio. Meglio connettere un archivio circoscritto e una casella funzionale che consegnare subito all’agente l’intero patrimonio informativo aziendale.

Costruire una prova di valutazione. Prima della diffusione, l’azienda dovrebbe raccogliere almeno 20 o 30 casi reali con un risultato atteso e misurare accuratezza, tempo risparmiato, revisioni umane, costo e gravità degli errori. I benchmark di OpenAI servono a confrontare i modelli; solo una valutazione interna può dire se il processo funziona davvero.

Automatizzare dopo, non prima. Le Scheduled Tasks diventano utili quando un’attività è già stata eseguita manualmente con ChatGPT Work, verificata e corretta. Programmare subito un flusso non testato significa trasformare un errore occasionale in un errore ricorrente.

Controllare i costi per risultato. Il prezzo per token non basta. Bisogna misurare quanto costa produrre una presentazione approvata, chiudere un’analisi o aggiornare un report, includendo revisioni e fallimenti. Sol può costare più di Luna per token e meno per risultato, se evita tre cicli di correzione.

Prevedere sempre un proprietario umano. Ogni flusso deve avere qualcuno che ne conosca fonti, autorizzazioni, criterio di successo e procedura di arresto. “Lo sta facendo l’AI” non è una responsabilità organizzativa.

Da chatbot a sistema operativo del lavoro

ChatGPT Work non è ancora un sistema operativo nel significato tecnico tradizionale: non gestisce direttamente processore, memoria e periferiche. Ma aspira a diventarlo nel significato organizzativo. Vuole essere il luogo in cui una persona esprime un obiettivo e dal quale partono applicazioni, dati, browser, modelli e automazioni necessari a raggiungerlo.

È una trasformazione più grande del passaggio da GPT-5 a GPT-5.6. Finora abbiamo valutato l’intelligenza artificiale chiedendoci se sapesse scrivere, ragionare o programmare. Con ChatGPT Work la domanda cambia: quali parti del lavoro siamo disposti ad affidarle, quali strumenti può toccare e chi controlla ciò che fa quando noi non stiamo guardando?