Mese: Agosto 2026

Secondo ACN nel primo semestre del 2026 sono state pubblicate 37.032 nuove vulnerabilità informatiche, il 54% in più rispetto alle 24.098 dello stesso periodo del 2025. Il dato arriva dall’Operational Summary semestrale dell’Agenzia per la cybersicurezza nazionale (ACN), che questa volta associa l’impennata a una causa tecnologica precisa: l’impiego dei modelli di intelligenza artificiale di frontiera nell’analisi del codice e nella ricerca delle falle. Per chi guida i sistemi informativi o la sicurezza di un’azienda il numero pesa meno della dinamica che lo genera. La scoperta delle vulnerabilità sta accelerando; la loro correzione resta ferma ai ritmi di prima. È questa forbice il fatto che ridefinisce la gestione del rischio nei prossimi mesi, più della semplice crescita del conteggio.

ACN: eventi e incidenti in Italia, il +47% con la lente della NIS2

 

Nel semestre ACN ha individuato 2.171 eventi cyber, il 47% in più rispetto al primo semestre 2025, di cui 1.072 classificati come incidenti con impatto confermato, in crescita del 246%. La curva mensile mostra un picco degli eventi a febbraio, in concomitanza con i Giochi Olimpici invernali Milano Cortina e con le campagne DDoS filorusse, un massimo degli incidenti a marzo (285), un rientro ad aprile e una ripresa fra maggio e giugno. Il salto va letto per quello che è: l’Agenzia stessa avverte che l’aumento dipende in larga parte dall’entrata in vigore, da gennaio, degli obblighi di notifica della direttiva NIS2, con oltre mille segnalazioni gestite dal CSIRT Italia. Non è una crescita reale della minaccia, è una crescita della visibilità. Il dato che conta davvero, per un responsabile della sicurezza, è che oggi emergono con granularità fenomeni che prima restavano sotto la superficie.

Settori impattati: cosa dice e cosa non dice il grafico

 

Il settore manifatturiero guida la classifica delle vittime con 309 soggetti colpiti e una variazione del 175,89%, seguito dal comparto tecnologico (306, +106,76%) e dalle telecomunicazioni (297, +37,5%). In controtendenza, la pubblica amministrazione locale e centrale scende del 48,5% e del 47,56%. Sanità ed energia crescono in modo marcato (+35,16% e +46,09%), a conferma della pressione sulle infrastrutture critiche; l’università e la ricerca calano del 70,29%.
Anche qui la NIS2 è la chiave di lettura, e ignorarla porta a conclusioni sbagliate. La ridistribuzione non fotografa un dirottamento degli attacchi verso le fabbriche: riflette il fatto che manifatturiero, tecnologico e sanità sono ora dentro il perimetro degli obblighi di notifica, mentre la PA, che già segnalava, pesa meno in termini relativi. Resta un dato sostanziale per il tessuto produttivo italiano: il manifatturiero è la prima voce censita, e il comparto vive una fase di digitalizzazione spinta dei processi industriali, con una superficie di attacco che si allarga a ogni linea connessa.

Tipologia di minacce: il baricentro si sposta sull’identità

 

La minaccia più frequente è l’esposizione di dati (475 eventi, +125,12%), seguita dal DDoS (407, in calo del 31,94%) e dalla compromissione delle caselle di posta elettronica (392, +269,81%). Salgono il phishing (380, +119,65%), il brand abuse (299, +94,16%) e soprattutto l’intrusione tramite credenziali valide (291, +203,13%). La voce che cresce di più in percentuale è il supply chain attack, passato da 6 a 104 eventi, con un incremento del 1.633%; lo sfruttamento di vulnerabilità sale dell’89,83%.
Il quadro racconta uno spostamento del fronte. L’attaccante che entra con credenziali valide non abbatte il muro, attraversa la porta: nessun exploit spettacolare, una password riutilizzata o rubata e un accesso legittimo. È il motivo per cui ACN insiste sul fattore umano e sulla gestione delle identità come primo terreno di difesa, tema che avevamo affrontato analizzando cybersecurity per le PMI e difesa continua. In flessione, invece, tre categorie: DDoS, ransomware e misconfiguration, segnali di un livello di igiene di base che migliora mentre il perimetro dei rischi si sposta altrove.

Report ACN – Distribuzione geografica: la mappa segue l’economia digitale

 

I 2.171 eventi hanno interessato 2.586 vittime, con una concentrazione netta su due province nella fascia più alta della scala, quella compresa fra 501 e 671 soggetti colpiti: Milano e Roma. Attorno, i poli industriali del Nord, dal Piemonte al Nord-Est, disegnano una seconda fascia di intensità; il Mezzogiorno e le aree interne restano più chiari.
La mappa non misura dove gli attacchi preferiscono colpire, misura dove si addensano l’attività economica digitalizzata e le sedi decisionali. Milano concentra imprese, finanza e manifattura avanzata; Roma la pubblica amministrazione centrale. La densità di bersagli segue la densità di valore. Per il tessuto produttivo lombardo, e per la Brianza che ne è motore manifatturiero, il messaggio è concreto: l’esposizione cresce dove cresce la digitalizzazione dei processi, e la prossimità geografica ai grandi hub non è una protezione.

ACN: 37.032 nuove CVE, il numero dipende dall’intelligenza artificiale

Delle 37.032 vulnerabilità registrate nel semestre, 5.722 dispongono di almeno un Proof of Concept, il codice dimostrativo che ne prova la sfruttabilità, in aumento di 3.646 unità; per 69 è stato rilevato uno sfruttamento attivo. ACN usa una formula prudente: l’incremento è “verosimilmente ascrivibile” al crescente utilizzo di modelli AI di frontiera, che riducono i tempi dell’analisi del codice, del vulnerability research e della generazione dei Proof of Concept, in particolare per alcuni vendor.

Il condizionale è la parte seria del passaggio: l’Agenzia indica una correlazione forte, non una prova diretta di causa. La stessa dinamica emerge fuori dall’Italia. La squadra di Firefox, lavorando con modelli di frontiera, ha rilasciato 61 patch a febbraio e 76 a marzo; le CVE pubblicate da Apache sono cresciute di oltre il 170%; le sottomissioni al NIST nel primo trimestre 2026 sono risultate quasi di un terzo superiori all’anno precedente, secondo l’analisi di Proofpoint. La distinzione che molte cronache saltano la mantiene la ricerca The AI Vulnerability Storm di Sonatype: tra i casi confermati, con l’attribuzione all’AI nell’advisory del vendor o nel record CVE, e quelli soltanto dichiarati, la contabilità precisa non c’è ancora; il segnale resta chiaro.

Vendor e prodotti colpiti: e il caso OpenClaw

 

La distribuzione per produttore è il punto in cui il report diventa più eloquente. Google passa da 159 a 1.766 vulnerabilità, Microsoft da 579 a 846, mentre alla voce prodotto il browser Chrome balza da 67 a 1.591 e Firefox da 84 a 255. Linux resta in cima con 2.543, ma il dato va contestualizzato con la nota del report: quel valore raccoglie solo le CVE registrate dalla CVE Numbering Authority del kernel. Browser e piattaforme di massa sono i bersagli ideali dell’analisi automatizzata: codice enorme, diffusione capillare, alto rendimento per chi cerca falle su scala industriale.

Poi c’è il dato che fotografa l’epoca. OpenClaw compare dal nulla, da zero a 474 come produttore e 476 come prodotto, in un solo semestre. È l’agente AI autonomo open source creato da Peter Steinberger, già noto come Clawdbot e MoltBot, che a inizio 2026 ha superato le 180.000 stelle su GitHub con deployment in 82 paesi. La sua crescita si è tradotta in una crisi di sicurezza documentata: la CVE-2026-25253, un’esecuzione di codice da remoto con un solo click ottenuta rubando il token di autenticazione, valutata 8.8 su scala CVSS e corretta il 30 gennaio, e la campagna di skill malevole sul marketplace ClawHub, dove i ricercatori hanno stimato che circa il 12% del catalogo fosse compromesso.

OpenClaw non è un’eccezione, è la punta di un fenomeno. Scorrendo le vulnerabilità più gravi segnalate dal CSIRT Italia nel semestre, un cluster ricorre con insistenza: n8n, Flowise, Langflow, RAGFlow, LiteLLM, Ollama, piattaforme per costruire flussi, agenti e applicazioni basate su modelli linguistici. L’ecosistema degli strumenti AI è oggi il territorio più denso di falle nuove. La ricerca automatizzata delle vulnerabilità è un dispositivo a doppio uso, e la difesa si attrezza: Google ha presentato Gemini 3.5 Flash Cyber, un modello addestrato dall’inizio sui database di vulnerabilità e malware; il capitolo attaccanti lo avevamo raccontato con Sloply e il malware agentico.

Il paradosso: la patch esiste, il sistema resta esposto

Qui sta il cuore della questione sottoposta da ACN, e non riguarda “gli hacker che usano l’AI”, tesi ormai logora. Il fatto nuovo è un altro: l’intelligenza artificiale sta rendendo visibili vulnerabilità che le aziende non hanno il tempo materiale di correggere. Un dettaglio del report lo dimostra meglio di qualsiasi analisi. In moltissimi degli alert più gravi del CSIRT Italia ricorre la stessa formula: “già sanata dal vendor”. La correzione esiste, spesso da settimane, eppure l’esposizione persiste. In Italia il CSIRT ha individuato 24.303 tra asset e servizi potenzialmente vulnerabili, 5.781 in più rispetto al semestre precedente, inviando oltre 43.675 comunicazioni di allertamento, più del doppio dell’anno prima. Il collo di bottiglia non è la scoperta della falla e non è la disponibilità della patch: è la sua applicazione. Lo conferma Proofpoint, che ricorda come le scoperte arrivino oggi soprattutto da ricercatori e difensori, con l’intento di correggere; la remediation resta il vero punto di strozzatura.

C’è un contrappeso che va letto con attenzione. Gli asset effettivamente compromessi sono scesi da 4.408 a 1.560, il 64,6% in meno. L’allertamento tempestivo, insieme all’entrata a regime della NIS2, riduce i sistemi che passano dallo stato di esposti a quello di compromessi. Il meccanismo di difesa funziona, ma deve reggere un carico che si allarga a ogni semestre.

Report ACN: cosa cambia per CIO e CISO

 

La conseguenza operativa dei dati che emergono dal Report ACN è un cambio di priorità. Con decine di migliaia di CVE l’anno, correggere tutto nello stesso ordine è impraticabile; conta la capacità di stabilire quali vulnerabilità trattare per prime. I criteri che il 2026 impone sono espliciti: sistemi esposti su internet, presenza di un Proof of Concept pubblico, segnali di scansione o sfruttamento attivo. Sono queste le falle che meritano un intervento d’emergenza, non l’intero elenco in ordine di pubblicazione. La distribuzione delle debolezze aiuta a mettere a fuoco il grosso del lavoro: cross-site scripting, mancanza di autorizzazione e SQL injection dominano la classifica delle CWE del semestre, a ricordare che la superficie critica resta, prima di tutto, quella delle applicazioni web.
Il passaggio è lo stesso che separa la sicurezza reattiva dalla gestione del rischio: non attendere l’attacco, ma sapere in anticipo quali parti dell’organizzazione sono davvero esposte e quali interventi riducono la probabilità che un incidente diventi crisi. Chi governa PMI e catene di fornitori trova un quadro dei passi concreti nella guida completa alla cybersecurity.La domanda che l’Operational Summary lascia aperta non riguarda la tecnologia degli attaccanti, quella la conosciamo. Riguarda la capacità delle aziende di reggere un ritmo di scoperta che accelera mentre il tempo per correggere resta quello di sempre. Su questo divario si gioca la sicurezza dei prossimi semestri.

 

Il 27 agosto 2026 Anthropic ha aperto a un primo gruppo di laboratori scientifici e produttori avanzati la sperimentazione del Model Hardware Standard, abbreviato in MHS: una specifica comune che consente agli agenti AI di riconoscere, coordinare e controllare strumenti fisici dotati di un’interfaccia programmabile. Microscopi, sistemi per il trasferimento di liquidi, laser e bracci robotici possono così essere collegati allo stesso agente, che legge i risultati di un’operazione, modifica i parametri e decide il passaggio successivo. La novità ha una portata più ampia del suo nome tecnico. Finora gli agenti AI hanno operato soprattutto dentro computer e servizi cloud, aprendo pagine web, scrivendo codice, interrogando database o modificando documenti; MHS porta quella capacità nella materia, dove un comando può spostare una piastra di laboratorio, cambiare la potenza di un laser oppure far muovere un robot industriale.
Quando l’agente sbaglia su un foglio elettronico, di solito lascia una cella errata e una cronologia da ripristinare. Quando sbaglia davanti a un microscopio, può rovinare un campione preparato per ore; accanto a una macchina, l’errore percorre centimetri e può incontrare oggetti, impianti o persone. L’intelligenza artificiale acquista conseguenze fisiche.

Model Hardware Standard: che cos’è e come funziona

Il Model Hardware Standard presentato da Anthropic nasce da un problema molto concreto. Nei laboratori e nelle fabbriche, strumenti costruiti da produttori diversi usano software, linguaggi e interfacce differenti; per farli lavorare insieme servono integrazioni su misura che possono richiedere settimane o mesi, anche quando ogni singolo apparato è già automatizzato.
MHS introduce un driver standardizzato, cioè uno strato software che traduce le funzioni della macchina in un gruppo di comandi comuni. Le operazioni di base sono volutamente semplici: leggere un valore, per esempio la temperatura, oppure scriverne uno, come la temperatura da impostare. Il driver descrive inoltre ciò che lo strumento può misurare, quali parametri consente di modificare e quali limiti di sicurezza devono essere rispettati.
Una parte di queste informazioni può essere inserita in linguaggio naturale. Il peso di un braccio robotico, la corsa massima di un componente, la potenza consentita a un laser o le condizioni nelle quali un’operazione deve fermarsi diventano elementi della scheda che l’agente consulta prima di agire. Il dispositivo viene poi reso individuabile in un formato comune, così l’agente può trovarlo sulla rete senza richiedere ogni volta un programma scritto appositamente.
Il controllo avviene attraverso tre canali: il Model Context Protocol, l’interfaccia a riga di comando e le API richiamate dal codice. MHS resta indipendente dal modello, quindi non è riservato a Claude; in linea teorica, qualsiasi agente compatibile può utilizzare i driver e orchestrare gli strumenti.

Su Digitalic avevamo descritto il Model Context Protocol come la tubatura comune che permette agli agenti di raggiungere dati e software, raccontando il caso del MCP applicato da Kolsquare all’influencer marketing. MHS estende quella logica: alla fine della tubatura, questa volta, c’è una macchina.

Model Hardware Standard: Anthropic non ha costruito un robot scienziato

La lettura più facile sarebbe quella dello scienziato autonomo, il laboratorio affidato interamente a Claude. La descrizione tecnica racconta qualcosa di meno spettacolare e, proprio per questo, più rilevante per le imprese.
MHS non fornisce a un modello la comprensione completa dello spazio e non sostituisce i sistemi di sicurezza incorporati nelle macchine; crea una lingua comune tra l’agente e dispositivi che possiedono già un controllo digitale. La capacità di muovere con precisione un braccio dipende ancora dal robot, dai sensori e dal suo controller. L’agente opera a un livello superiore: osserva lo stato degli strumenti, stabilisce la sequenza delle attività, modifica alcuni parametri e reagisce ai risultati.

La differenza rispetto all’automazione tradizionale sta nel punto in cui viene presa la decisione. Un impianto industriale esegue da tempo sequenze programmate, protette da controllori, barriere, arresti e procedure validate; un agente basato su un modello linguistico può invece scegliere il passaggio successivo in base a un obiettivo e a ciò che interpreta durante l’esecuzione. Anthropic racconta di avere osservato Claude regolare un laser, controllarne lo spostamento attraverso una telecamera e ripetere l’operazione fino a comprendere il comportamento del sistema; una volta trovata la procedura, il modello l’ha trasformata in uno script deterministico, eseguibile con un solo comando.
In quella trasformazione si legge la logica di fondo di MHS: l’agente esplora quando serve giudizio, poi consegna alla macchina una procedura stabile quando la velocità o la durata del compito rendono inadatto ragionare a ogni singolo passaggio.

Dai laboratori ai computer quantistici: i primi test di Model Hardware Standard (MHS)

Anthropic ha pubblicato diversi casi realizzati con i partner della sperimentazione. Genentech ha usato MHS in un proof of concept per coordinare un liquid handler, un braccio robotico e un lettore di micropiastre durante un test sulla concentrazione delle proteine. Alla Carnegie Mellon University un agente basato su Claude Opus 4.8 ha orchestrato quattro tipi di apparecchiature per costruire curve dose-risposta: il gruppo riferisce di avere sviluppato i driver e il livello di coordinamento in circa otto ore, rispetto alle settimane richieste da un’integrazione realizzata dal fornitore, eseguendo gli esperimenti a una velocità circa tre volte superiore.
I laboratori Baker e Pinglay dell’Università di Washington hanno collegato sei strumenti in meno di una settimana. In una dimostrazione, Claude Code ha coordinato un sistema per il trasferimento di liquidi e un braccio robotico che sostituiva le piastre; secondo il resoconto pubblicato da Anthropic, nei test ripetuti i due dispositivi non sono entrati in collisione, perché ogni movimento iniziava soltanto dopo il completamento di quello precedente.
QuEra, che costruisce computer quantistici basati su atomi neutri, ha affidato a un agente il recupero del lock del laser, la frequenza estremamente precisa necessaria per interagire con gli atomi. Il controller sviluppato attraverso MHS avrebbe ripristinato l’aggancio nel 99,3% dei casi senza intervento umano.
Sono risultati significativi, con un limite che deve restare visibile: arrivano dall’annuncio dell’azienda che propone lo standard e dai partner selezionati per la fase iniziale. Non costituiscono ancora una valutazione indipendente dell’affidabilità di MHS su impianti diversi, in condizioni impreviste o durante un utilizzo prolungato. Anthropic stessa definisce questi progetti proof of concept e riconosce che protocolli più complessi richiederanno ottimizzazione, supervisione ed esami di sicurezza ulteriori.
La sperimentazione serve esattamente a colmare questa distanza. Lo standard diventerà open source soltanto dopo la costruzione di valutazioni, pratiche operative e protezioni per il controllo di apparecchiature fisiche.

L’errore di un agente AI ora ha massa e velocità

Il rischio fisico non comincia con MHS. Robot industriali, macchine a controllo numerico e sistemi di laboratorio automatici eseguono comandi software da molti anni; la sicurezza funzionale è nata per impedire che un guasto elettronico o un’istruzione errata producano un movimento pericoloso.
L’agente introduce però un tipo diverso di incertezza. Il software tradizionale percorre una sequenza definita in anticipo e, se il codice non cambia, tende a ripetere lo stesso comportamento nelle stesse condizioni. Un modello linguistico interpreta istruzioni, seleziona strumenti e costruisce un piano durante l’esecuzione; può quindi trovare una soluzione che il progettista non aveva scritto, insieme a una scorciatoia che il progettista non aveva previsto.

La cronaca recente mostra quanto questa autonomia richieda prudenza. Durante test di cybersecurity, alcuni agenti sono riusciti a oltrepassare gli ambienti predisposti per valutarli e a raggiungere sistemi esterni; Digitalic ha ricostruito sia l’attacco degli agenti OpenAI contro Hugging Face, sia i test nei quali modelli Anthropic hanno violato sistemi aziendali reali. Quegli incidenti si sono svolti nel dominio digitale, ma hanno evidenziato un principio trasferibile: l’obiettivo assegnato all’agente non descrive tutte le strade che il sistema può scegliere per raggiungerlo.
Nel mondo fisico, anche una lettura sbagliata può diventare un’azione corretta dal punto di vista formale. Anthropic racconta che, durante un test con campioni proteici, Claude interpretò la schiuma come un problema software; furono i ricercatori di Genentech a spiegare che si trattava di un fenomeno materiale, risolvibile soltanto con un intervento fisico adeguato. Il modello aveva ricevuto i dati, ma non possedeva l’esperienza tacita di chi conosce il banco di laboratorio Il limite più difficile da codificare: una macchina può sapere quanto pesa un braccio perché il valore compare nella scheda MHS, mentre fatica a riconoscere ciò che nessuno ha pensato di scrivere.

I limiti di sicurezza nel Model Hardware Standard

Anthropic ha progettato MHS affinché il driver esponga e faccia rispettare i limiti del dispositivo. Nel caso di un microscopio laser, per esempio, il ricercatore può impedire all’agente di superare una determinata potenza, evitando di scolorire le molecole fluorescenti e danneggiare il campione. Questo sposta una parte della sicurezza dal comportamento generale del modello al punto più vicino alla macchina, dove il vincolo può essere preciso e verificabile.
È una scelta corretta, purché il limite non venga confuso con un sistema completo di protezione. Una soglia sulla potenza non garantisce che il laser sia rivolto nel punto giusto; la corsa massima di un robot non impedisce una collisione all’interno dell’area consentita. Ogni strumento ha vincoli locali, ma l’incidente può nascere dall’interazione tra due dispositivi che, presi separatamente, stanno rispettando tutte le regole.
La sicurezza degli agenti fisici deve quindi essere costruita per strati. Il modello propone l’azione; il driver verifica i parametri; il controller della macchina applica i limiti funzionali; sensori e dispositivi indipendenti fermano il movimento quando la situazione supera il perimetro ammesso. La supervisione umana resta necessaria nei passaggi in cui un errore può compromettere persone, materiali costosi o risultati scientifici non ripetibili.
La stessa logica è già presente negli standard industriali. La ISO 10218-1:2025 definisce i requisiti per la progettazione sicura dei robot industriali, mentre la ISO 10218-2:2025 riguarda la loro integrazione nelle applicazioni e nelle celle robotiche. MHS aggiunge un’interfaccia, non cancella queste responsabilità.

L’AI fisica amplia anche la superficie di attacco

Un dispositivo raggiungibile da un agente attraverso la rete diventa parte di un sistema informatico più esteso. L’interoperabilità riduce le integrazioni artigianali, che sono spesso fragili e poco documentate; allo stesso tempo, un protocollo comune rende più semplice collegare strumenti diversi e amplia ciò che un’identità compromessa può tentare di raggiungere.

Il problema riguarda i permessi, e va risolto al livello del singolo comando. Un agente incaricato di leggere una temperatura non deve per questo poterla modificare; quello che riceve le immagini di una telecamera non deve necessariamente muovere il braccio che la telecamera osserva. Anche l’attribuzione delle credenziali pesa: il perimetro del rischio cambia a seconda che il diritto di agire appartenga al modello, alla sessione, all’operatore o al singolo esperimento. In un sistema fisico il principio del privilegio minimo deve arrivare fino al comando elementare, non fermarsi all’accesso generale al dispositivo.
Servono inoltre registri non modificabili delle decisioni e delle azioni, autenticazione tra agente e macchina, segmentazione delle reti operative, simulazioni prima dell’esecuzione e un arresto indipendente dal modello. Un prompt malevolo nascosto in un documento, un dato sensoriale alterato o una telecamera compromessa non devono poter diventare, senza ulteriori controlli, un’istruzione motoria.
La possibilità di spegnere o isolare un sistema avanzato, già discussa nel dibattito sugli AI kill switch, acquista qui un significato meno teorico. Il pulsante di arresto deve interrompere energia e movimento anche quando l’agente ritiene di avere una buona ragione per continuare.

Model Hardware Standard e regole europee

Per le imprese europee l’adozione di MHS non potrà essere trattata come l’installazione di un normale connettore software. A seconda dell’impiego, un sistema AI incorporato in una macchina o utilizzato come componente di sicurezza può rientrare nel regime dei sistemi ad alto rischio previsto dall’AI Act; il testo europeo richiede, tra le altre condizioni, strumenti che consentano una supervisione umana effettiva durante l’utilizzo. Il Regolamento europeo sulle macchine considera inoltre i rischi che possono emergere dall’evoluzione del comportamento di sistemi dotati di diversi livelli di autonomia.
La classificazione dipenderà dal prodotto, dalla funzione e dal modo in cui l’agente viene integrato: collegare un modello a una telecamera di prova non equivale ad affidargli una funzione che incide sulla sicurezza di una linea produttiva. Per questo la conformità non può essere attribuita allo standard in astratto. Va valutato l’intero sistema, comprendendo modello, driver, macchina, ambiente, operatore e procedure di emergenza.

Qui si apre anche il tema della responsabilità. Se un braccio danneggia un campione perché il modello ha interpretato male un’immagine, la causa può trovarsi nell’agente, nel sensore, nella descrizione MHS incompleta, nel limite configurato dal laboratorio oppure nella scelta di lasciare il processo senza supervisione. La standardizzazione facilita la connessione; per evitare che disperda le responsabilità, deve rendere leggibile l’origine di ogni comando.

Cosa cambia per laboratori e imprese manifatturiere

Il vantaggio immediato di MHS riguarda l’integrazione. Una fabbrica o un laboratorio non devono sostituire l’intero parco macchine per sperimentare gli agenti AI; possono descrivere attraverso driver comuni apparati programmabili già presenti e consentire al sistema di coordinarli. Per aziende con strumenti di produttori differenti, ridurre settimane di lavoro a giorni o ore può rendere sostenibili automazioni che prima costavano più del problema da risolvere.
Il secondo vantaggio riguarda il tempo di utilizzo. Un agente può sorvegliare un esperimento lungo, reagire a una deviazione, recuperare alcuni errori e avviare il passaggio successivo senza attendere l’arrivo di un tecnico. Questo non elimina il lavoro dello scienziato o dell’operatore; sposta il suo intervento dalla ripetizione delle sequenze alla progettazione dell’esperimento, alla definizione dei limiti e alla verifica dei risultati.

Prima di collegare un agente a una macchina, però, CIO, responsabili OT e responsabili della sicurezza dovrebbero pretendere almeno sei elementi concreti:

Un inventario delle azioni consentite, definito per singolo dispositivo e non per categorie generiche.
Limiti applicati dal controller, indipendenti dalla capacità del modello di ricordare o interpretare una regola.
Una simulazione o modalità shadow, nella quale l’agente propone i comandi senza eseguirli sull’hardware.
Autorizzazioni progressive, con approvazione umana per le azioni irreversibili e per ogni aumento del perimetro operativo.
Registri completi e protetti, capaci di collegare obiettivo, osservazione, decisione, comando e risposta della macchina.
Un arresto fisico e una procedura di recupero, verificati in condizioni reali e non affidati allo stesso agente che controlla il processo.

Gli agenti AI si distinguono dai chatbot per la possibilità di usare strumenti e compiere azioni. MHS rende visibile la conseguenza estrema di quella definizione: lo strumento può essere un braccio di metallo, il dato può arrivare da una telecamera, l’azione può continuare mentre nessuno guarda lo schermo.

L’AI esce dallo schermo, il controllo deve seguirla

Il Model Hardware Standard potrebbe diventare per le macchine ciò che MCP sta diventando per il software: un’interfaccia comune che riduce il costo di ogni nuova connessione e permette agli agenti di passare da uno strumento all’altro. Il valore economico è evidente nei laboratori che oggi perdono settimane a far comunicare apparecchi già automatizzati; lo è anche nelle fabbriche, dove una parte consistente della complessità si nasconde tra sistemi proprietari incapaci di scambiarsi informazioni.
Proprio questa facilità impone un criterio più severo. Nel software, collegare un nuovo strumento amplia ciò che l’agente può fare; nel mondo fisico amplia ciò che l’agente può muovere, riscaldare o rompere. La sicurezza non può risiedere nella promessa che il modello sceglierà sempre l’azione corretta. Deve essere incorporata nei limiti della macchina, nei permessi, nella rete, nelle procedure e nell’autorità umana di fermare il processo.