Model Hardware Standard, cos’è e cosa può aprire

Anthropic ha rilasciato il Model Hardware Standard, la specifica che permette agli agenti AI di gestire strumenti fisici. Cos’è, cosa apre e i limiti.

Il 27 agosto 2026 Anthropic ha annunciato il Model Hardware Standard, una specifica che stabilisce come vada scritto il software di collegamento fra un agente AI e uno strumento fisico. L’articolo spiega come funziona, chi scrive quei collegamenti, in cosa differisce dai server MCP e dove lo standard si sta muovendo fuori dai laboratori. Chiude sulla domanda che il documento lascia aperta, cioè se gestire strumenti fisici avvicini un modello a una conoscenza di quel mondo. La risposta è no, e la ragione non riguarda la maturità dello standard.

Nella prima settimana di settembre Anthropic e OpenAI hanno pubblicato a due giorni di distanza i rispettivi modelli più capaci. La discussione che ne è seguita ha preso la forma consueta, cioè il confronto sui punteggi delle prove di valutazione e la domanda su quale dei due convenga usare.

Il 27 agosto, pochi giorni prima, Anthropic aveva annunciato il Model Hardware Standard (MHS). È una specifica che permette a un agente AI di gestire strumenti fisici, in laboratorio e in fabbrica. Testate italiane e internazionali ne hanno scritto, quindi non è passato inosservato, ma non ha avuto la risonanza che merita.

Il motivo, un modello si prova la sera stessa in cui esce e il risultato si può mostrare a chi legge, uno standard di collegamento non produce niente da guardare e i suoi effetti si vedono solo dopo che qualcuno lo adotta e ci costruisce qualcosa sopra.

Le ragioni per cui questo annuncio è importante sono tre. Anthropic ha già portato a termine un’operazione dello stesso tipo con il Model Context Protocol, che in poco più di un anno è diventato uno standard adottato anche dai concorrenti. Il Model Hardware Standard tocca poi un punto in cui le AI generative sono deboli, cioè il rapporto con le cose fisiche. Infine il documento comporta implicitamente una domanda a cui non risponde, cioè se gestire strumenti fisici avvicini un modello a una conoscenza di quel mondo.

Cos’è il Model Hardware Standard

In un laboratorio ogni strumento con un’interfaccia digitale parla la propria lingua. Il microscopio ha il suo programma di controllo, la telecamera il suo, il braccio meccanico un altro ancora, e quasi sempre arrivano da produttori diversi.

Il caso raccontato nell’annuncio da una ricercatrice del HHMI Janelia Research Campus dà la misura del problema. Il suo banco di microscopia mette insieme laser, specchi mobili, rilevatori e due slitte di posizionamento, con i rilevatori che girano in MATLAB, le telecamere in Python e l’elettrofisiologia in C#. Per far comunicare due di quei programmi bisogna scrivere codice apposta, e per avviare un esperimento serve lanciare sette applicazioni nell’ordine giusto.

Il Model Hardware Standard interviene qui, definendo un layer di interfaccia unico per tutte le macchine.

Il collegamento fra un computer e un dispositivo passa da un driver, cioè il software che permette al computer di comandarlo, e chi ha installato una stampante ne ha già usato uno. I driver però sono ognuno un caso a sé, scritti dal produttore per il proprio dispositivo, e non c’è ragione perché due di essi si somiglino. MHS non è un altro driver, è la specifica che dice come vadano scritti, perché tutte le macchine rispondano nella stessa forma. Ogni strumento ha quindi il proprio driver MHS.

MHS lavora su tre fronti.

  • Comandi elementari uguali per tutti. Espone operazioni di base come leggere e scrivere, dove leggere è per esempio chiedere la temperatura e scrivere è impostarla. Perché quei comandi abbiano un bersaglio, ogni macchina viene descritta come un elenco di stati e di procedure. Gli stati sono le condizioni in cui può trovarsi, per esempio una piastra in posizione tre. Le procedure sono le operazioni che sa compiere, come aspirare o agitare. I comandi restano gli stessi per tutti, l’elenco cambia da macchina a macchina ma è scritto sempre nella stessa forma.
  • Strumenti che si fanno trovare. Ogni dispositivo si presenta in un formato standard, quindi strumenti e agente si riconoscono sulla rete senza un programma traduttore costruito su misura.
  • Etichette in linguaggio naturale. Chi installa lo strumento scrive in parole comuni quello che il codice non dice, per esempio quanto pesa un braccio meccanico, informazione che serve a manipolarlo senza fare danni.

Il terzo punto è importante, informazioni del genere finora stavano nei manuali di carta, sul computer di chi usa la macchina, oppure in testa a chi la usa da anni. Il driver le raccoglie e ne ricava un file di riferimento con quello che lo strumento misura, quello che si può regolare e i limiti di sicurezza che verranno fatti rispettare. Chi installa può scriverle da sé oppure farsi intervistare da un agente sul proprio impianto.

Quando l’agente sa cosa ha davanti restano da comandare le macchine, e le strade sono tre, il Model Context Protocol, la riga di comando e i file di codice. MHS non è legato a un modello particolare, e la documentazione dichiara che qualsiasi sistema di agenti può usarlo attraverso protocolli standard.

Resta la domanda su chi scriva quei driver, e la risposta spiega i tempi di integrazione più di qualsiasi altra cosa.

Il driver ha due facce. Quella rivolta alla macchina parla la lingua di quella macchina, quindi va scritta per lei e resta un caso a sé, perché un rilevatore governato da MATLAB e una telecamera governata da Python richiedono lavori diversi. Quella rivolta all’esterno è invece identica per tutti, ed è da lì che nasce il layer, perché tante facce uguali si presentano all’agente come un’interfaccia sola e non come tante. I comandi uguali per tutti arrivano a quella faccia, non alla macchina, ed è il driver a tradurli verso il basso.

Nell’annuncio vengono raccontate tre modalità diverse di scrivere la faccia verso le macchine.

La prima è il ricercatore che se la scrive da sé, come il dottorando di Washington, che ha collegato sei strumenti in meno di una settimana contando anche il tempo passato a scrivere i driver.

La seconda è l’agente. Alla Carnegie Mellon il dosatore di liquidi esponeva soltanto uno scripting Windows vecchio, senza kit di sviluppo, e i comandi utilizzabili sono stati ricavati dalla documentazione del fornitore oppure da un agente Claude che esplorava l’interfaccia e scriveva il driver funzionante. Leggere il manuale, provare i comandi, guardare cosa risponde la macchina e ricavarne il driver è lavoro che un modello sa fare, e le otto ore vengono da lì.

La terza è il produttore, che lo mette nel prodotto. MBF Bioscience sta costruendo il driver per il software che governa i microscopi a scansione laser in centinaia di laboratori di neuroscienze, Tecan lo sta aggiungendo alle proprie piattaforme di gestione dei liquidi, e Anthropic dichiara di lavorare con i costruttori dei dispositivi che un’interfaccia di programmazione non ce l’hanno.

C’è poi la parte che fa la differenza sul lungo periodo. La Carnegie Mellon scrive che i driver costruiti per i propri strumenti verranno resi pubblici, perché altri li riusino invece di rifare il lavoro da capo. Chi collega per primo un certo modello di lettore di piastre paga il costo, chi ha lo stesso lettore non lo paga più.

I numeri dichiarati dai partner riguardano quasi tutti il tempo di integrazione. Un dottorando dell’Università di Washington ha collegato sei strumenti in meno di una settimana, driver compresi. Nel test sviluppato da HHMI Janelia Research Campus l’aggiunta di una telecamera è passata da progetto di più giorni a pochi minuti. Alla Carnegie Mellon il percorso da apparecchiature non automatizzate a una curva completa ha richiesto otto ore, contro le settimane di un allestimento fatto fare al fornitore.

Sullo stato della cosa conviene essere precisi. È una research preview, cioè una versione in prova aperta a un primo gruppo di laboratori e di produttori, l’accesso passa da una lista d’attesa e la specifica non è pubblica, senza licenza né numero di versione. Anthropic dichiara che la renderà open source e che insieme pubblicherà quello che ha imparato durante la prova, come guida per adottare lo standard in sicurezza, ma non dice quando.

Vale la pena notare che chi scrive per primo la specifica di un terreno nuovo decide anche cosa conti come limite di sicurezza e quali dispositivi vengano supportati prima degli altri.

In che cosa è diverso da un server MCP

Chi collega già Claude a strumenti esterni a questo punto si chiede cosa aggiunga MHS rispetto a un server MCP scritto per l’occasione. La domanda è pertinente, perché un server MCP che comanda un microscopio si può costruire, e Anthropic riconosce che molti sviluppatori già lavorano così con singole apparecchiature. Le differenze sono quattro.

  • La posizione. MHS non è un’alternativa a MCP, gli sta sotto. Il protocollo è una delle tre porte per raggiungere le macchine, insieme alla riga di comando e ai file di codice. Un server MCP è il livello che il modello vede, MHS è il livello che il dispositivo espone.
  • Chi parla con chi. Un server MCP esiste per portare un modello dentro uno strumento, quindi senza modello non serve a niente. In un laboratorio però il problema è anche un altro, perché gli strumenti devono parlare fra loro. Nel banco di Janelia ciascuna delle due slitte deve conoscere la posizione dell’altra perché il sistema sappia dove si trova il campione, e in quella richiesta non c’è nessuna AI. MHS raccoglie lo stato di tutti i dispositivi in un unico dizionario condiviso, che vive nella memoria del computer e che qualsiasi programma può leggere. È la trovata da cui lo standard è nato, sviluppata da un ricercatore di Janelia per far comunicare le macchine del proprio banco.
  • La velocità, che discende dal punto precedente. Un modello che ragiona a ogni passo è troppo lento per certi anelli di controllo, e allineare un raggio laser correggendo degli specchi è uno di quelli. La soluzione descritta nell’annuncio è che l’agente concatena i comandi in un file di codice e i dispositivi eseguono da soli, senza che il modello intervenga a ogni passaggio.
  • La sicurezza. In un server MCP i limiti li scrive chi ha costruito il server, oppure stanno nelle istruzioni date al modello. In MHS fanno parte della descrizione standard del dispositivo e vengono fatti rispettare lì, sotto l’agente. Alla Carnegie Mellon hanno provocato apposta sei situazioni di guasto, fra cui una piastra ruotata e un arresto di emergenza attivo, e il sistema le ha bloccate tutte prima che qualcosa si muovesse.

Messe insieme, le quattro differenze indicano obiettivi diversi. Un server MCP serve a far comandare un elemento, magari un’apparecchiatura, a un modello. MHS serve a tenere insieme l’impianto con il modello che interviene solo dove il suo ragionamento aggiunge qualcosa.

Cosa apre il Model Hardware Standard

Quello che si apre non è una capacità nuova dei modelli ma è il crollo del costo di collegare le macchine fra loro, il resto discende da lì. Un dottorando dell’Università di Washington scrive nell’annuncio di Anthropic che far comunicare strumenti di produttori diversi richiede da mesi ad anni di lavoro e costa da migliaia a milioni di dollari, il che tiene l’automazione fuori portata per la maggior parte dei laboratori.

La prima conseguenza è il banco che lavora senza nessuno davanti. Una reazione a catena della polimerasi va interrotta al momento giusto, e finora quel momento lo si aspettava guardando lo schermo dello strumento per ore, mentre adesso la curva viene letta man mano che arriva e il sistema chiede se fermare o proseguire. Nello stesso laboratorio un braccio meccanico e un dosatore di liquidi si passano le piastre senza scontrarsi, mentre il ricercatore guarda dall’ufficio.

Il caso che dice di più non riguarda però la velocità. Nei computer quantistici di QuEra i laser vanno tenuti su una frequenza precisissima, e la qualità di quella tenuta dipende da dodici parametri legati fra loro. Un tecnico li regola guardando un indicatore di errore che approssima bene il risultato, perché misurare davvero il rumore residuo dopo ogni modifica sarebbe impraticabile a mano. L’agente quella misura l’ha fatta ogni volta, per trecentosessantatré tentativi in sedici ore senza nessuno presente.

Il confronto è stato fatto in cieco, perché lo specialista ha rifatto la regolazione a modo suo senza vedere il risultato dell’agente, e le due configurazioni sono finite su uno strumento di misura indipendente. Erano equivalenti su quasi tutta la banda, tranne a una risonanza dove la regolazione manuale lasciava un difetto che l’altra non aveva. In diciannove ore di prova la taratura dell’agente non ha mai perso l’aggancio, mentre quella dell’esperto lo perdeva circa una volta e mezza l’ora. Va aggiunto che la prova si è svolta su un banco dedicato e non sulla macchina in servizio ai clienti.

Un’altra conseguenza riguarda la riproducibilità degli esperimenti. Un protocollo può prescrivere una centrifugazione a una certa forza per un certo tempo senza nominare nessuna centrifuga, e il sistema cerca sulla rete una macchina compatibile, ne legge il driver e converte quella forza nei parametri che quella macchina accetta. Chi ha scritto il protocollo non sa e non deve sapere quale centrifuga sia stata usata, quindi un esperimento descritto così si può rieseguire altrove, con altre macchine, senza riscriverlo.

Fuori dal laboratorio cambia il tipo di azienda che si sta muovendo. Fra i partner della prova, accanto ai produttori di strumenti scientifici, compaiono aziende di robotica, Doosan Robotics e Universal Robots sono i due nomi principali dei robot collaborativi, cioè le macchine che lavorano accanto alle persone nelle officine. La prima sta provando lo standard per il controllo qualità automatico e per coordinare più robot fra loro, la seconda ha avuto accesso anticipato e prevede di supportarlo. Amazon Web Services lo integrerà nella libreria con cui collega gli agenti ai dispositivi fisici, mentre Hugging Face lo sta aggiungendo alla propria libreria di robotica LeRobot. All’estremo opposto per costo, Raspberry Pi ha dichiarato sul proprio canale di lavorare a un driver per le sue telecamere e di voler estendere la copertura ad altri prodotti.

La differenza rispetto ai laboratori non è di grado ma di destinazione. Un laboratorio adotta lo standard per il proprio banco, mentre un costruttore di robot lo mette in una macchina che venderà a qualcun altro, ed è quello che Universal Robots dichiara quando parla di aggiungere il supporto alla propria piattaforma. In officina lo standard arriverà come caratteristica del prodotto, e chi lo vende avrà interesse a metterla in evidenza, quindi la scelta si farà valutando la macchina invece che adottando lo standard.

Non è però la robotica dei robot che imparano a muoversi. Sono robot industriali con un’interfaccia programmabile, librerie per chi sviluppa e schede da poche decine di euro, cioè macchine che già oggi si comandano scrivendo codice. Quello che cambia è che il codice non va più riscritto per ogni marca, e fra il robot collaborativo e la scheda ci sono diversi ordini di grandezza di prezzo e lo stesso standard.

Oggi niente di tutto questo entra nello studio di un professionista o in un ufficio, il che è prevedibile per uno standard in prova presso pochi partecipanti e limitato a macchine con un’interfaccia programmabile. Guardando al precedente del Model Context Protocol viene facile pensare che la parte interessante arriverà quando lo standard verrà aperto e ognuno collegherà quello che ha, con gradi diversi a seconda di quanto ciascuno è attrezzato.

La domanda sulla consapevolezza del mondo fisico

Alle AI generative si rimprovera spesso di non avere consapevolezza del mondo fisico, e uno standard che le mette a gestire strumenti sembra un primo passo per rimediare. Il ragionamento è lineare, perché maneggiare strumenti significa misurare, misurare significa raccogliere dati, e con i dati questi sistemi lavorano bene. L’annuncio contiene abbastanza materiale per rispondere, purché si separino tre cose che di solito si tengono insieme, cioè descrivere un impianto, ricavare per esperimento come si comporta e trattenere quello che si è ricavato.

La descrizione è il mestiere di MHS. Il file di riferimento dice cosa lo strumento misura e quali limiti valgono, mentre il dizionario di stato tiene la fotografia viva del banco durante l’esperimento. Sono due rappresentazioni complete dentro il loro perimetro e mute su tutto il resto.

Il secondo punto dà ragione all’ipotesi. Nell’annuncio c’è un passaggio in cui il modello regola un laser, guarda con una telecamera come si è spostato il raggio e ripete, per capire la sequenza degli eventi. In QuEra la cosa va più lontano, perché provocando lo stesso guasto centinaia di volte durante la notte il sistema ha ricavato uno schema del comportamento del laser sotto disturbo, e ha riscritto la procedura come albero di decisione invece che come sequenza fissa. Quello è un modello di come si comporta un pezzo di mondo fisico, ottenuto per esperimento e non per lettura.

Il terzo punto è dove il ragionamento si rompe. Quello che il sistema ha ricavato non diventa conoscenza del modello, perché il risultato del lavoro notturno è uno script deterministico che poi gira in produzione senza nessun agente sopra, e da Genentech le conclusioni sulle bolle sono state depositate in skill riutilizzabili. È memoria esterna e non comprensione acquisita, quindi la sessione successiva riparte dal file.

C’è poi la parte che nessuna interfaccia può trasmettere. La critica sulla mancanza di consapevolezza fisica non riguarda la misura, perché gli strumenti digitalizzano misure da decenni. Riguarda il ritorno di forza, il contatto, la resistenza, cioè quello che di una cosa si sa solo toccandola. MHS trasporta quello che è già digitalizzabile, e quella parte non lo è.

La stessa Anthropic dice che Claude impara il mondo fisico da testo e immagini e che il suo ragionamento spaziale richiede ancora supervisione esperta.

Un elemento in direzione opposta però esiste. Genentech scrive che, confrontando le decisioni del modello con la competenza dei propri esperti, sta generando i dati che servono a migliorare le prestazioni dei modelli su questo compito. È l’unico punto in cui il cerchio si chiude verso il modello, ed è un’intenzione dichiarata da un partner, non un risultato misurato.

La risposta alla domanda iniziale quindi è no, e la ragione non è la maturità dello standard. Un’interfaccia trasmette quello che le macchine sanno già digitalizzare, e la parte mancante non passa di lì, quindi resterebbe fuori anche da una versione completa. Quello che MHS riduce è il costo di far parlare le macchine fra loro e con un agente, che è una cosa diversa dal dare a un modello la conoscenza del mondo fisico.

Paolo Dalprato, formatore sulle AI generative

Chi ha scritto questo articolo

Sono Paolo Dalprato, formatore sulle AI generative. Lavoro con professionisti, studi e PMI da una parte, con scuole, biblioteche e istituzioni culturali dall'altra, sull'ecosistema Claude e NotebookLM. Quello che insegno è lo stesso che uso ogni giorno, e finisce qui sul blog prima ancora che in aula.

Autore di «Creatività ibrida: autore e opera nell'era delle macchine intelligenti».

Potrebbe interessarti