MCP e fabbrica: come collegare agenti LLM all'impianto, e cosa manca

Il 29 settembre 2026 IIoT World ha pubblicato la seconda di tre puntate nate dalle domande rimaste senza risposta durante la sessione "From Data Streaming to Autonomous Action" dell'Industrial AI Summit 2026. Le risposte sono di Peter Sorowka, CEO di Cybus. L'articolo è etichettato "Sponsored by Cybus | Editorially Independent": va quindi letto come il punto di vista del CEO di un fornitore, non come una valutazione neutrale del mercato.

Che cosa fa MCP in fabbrica

Il Model Context Protocol (MCP) è un modo standard con cui un agente scopre e richiama degli strumenti. Secondo Sorowka, in uno stabilimento lo "strumento" è il modello di fabbrica stesso: namespace, asset e valori live, esposti con le stesse regole di accesso valide per le persone. Ne deriva un unico punto d'ingresso verso l'impianto per qualsiasi LLM, conversazionale o agentico, che può comprendere dati e contesto, leggerli e agire su di essi.

Sempre secondo Sorowka, i clienti usano piattaforme diverse:

• assistenti in hosting come Copilot Studio, che accedono tramite chiave API;
• front end GPT interni basati su modelli OpenAI, Anthropic e Google;
• modelli self-hosted quando i dati devono restare in stabilimento.

Cybus afferma che Connectware si comporta allo stesso modo qualunque sia il modello dall'altra parte.

Standard: la connettività c'è, il resto no

Per Sorowka la connettività è "largely solved" grazie a OPC UA e MQTT. Non lo è la contestualizzazione: AAS, i3X e le convenzioni UNS competono, e la maggior parte degli impianti modella i dati in modo diverso da sito a sito. Manca del tutto uno standard industriale per la governance tra esseri umani e IA: MCP definisce la chiamata, non il permesso. Per scalare serve un modo portabile per dichiarare chi può leggere e chi può agire.

Il suo consiglio pratico è dichiarare il proprio modello in una forma che possa essere in seguito proiettata su AAS o i3X, invece di attendere che uno standard prevalga.

Il ruolo dell'LLM

Oggi l'LLM è interfaccia e orchestratore. Il valore industriale continua a venire da modelli costruiti per uno scopo: rilevamento di anomalie, previsione di serie temporali, ottimizzazione. L'LLM recupera il contesto, richiama questi modelli e ne spiega il risultato. Per le decisioni con conseguenze fisiche, le regole dichiarate e gli interlock devono restare vincolanti.

"The model proposes and the policy layer decides."

Agent-to-agent e identità

Oggi un assistente raggiunge Connectware tramite il server MCP con una chiave che agisce per conto di una persona identificata. Le catene agent-to-agent richiedono invece un'identità distinta per l'agente, con un responsabile chiaro: Cybus la indica come voce di roadmap. La posizione dell'azienda è che la governance appartenga al confine della fabbrica.

Il processo conta più dello strumento

Sorowka descrive la maggior parte dei progetti come uno "steam-to-electricity swap": un agente sostituisce una dashboard dentro un processo invariato. Il guadagno reale, sostiene, sta nell'accorciare il ciclo decisionale, cioè nel ridurre i passaggi di mano. Si aspetta "organigrammi ibridi" e avverte di non sottovalutare la governance della manifattura agentica ad anello chiuso.

Indicazioni pratiche

Per chi vuole esporre dati di PLC, SCADA e UNS ad agenti LLM, gli spunti sono:

• applicare l'accesso a privilegi minimi, con gli stessi criteri usati per le persone;
• mantenere deterministici interlock e regole di sicurezza, fuori dalla portata dell'LLM;
• modellare i dati in modo dichiarativo, così da restare portabili verso AAS o i3X;
• trattare permessi e identità degli agenti come questioni ancora aperte e presidiarle esplicitamente.

Trattandosi di una fonte di parte, conviene verificare queste affermazioni sul proprio caso d'uso. L'impostazione di fondo, però, è sensata: l'LLM propone e spiega, mentre l'autorità sulle azioni fisiche resta a livello di regole e controlli deterministici.