Agenti LLM in fabbrica: l'architettura MCP e i vuoti di governance

Il 29 settembre 2026 IIoT World ha pubblicato la seconda di tre puntate nate dalle domande del pubblico rimaste senza risposta nella sessione "From Data Streaming to Autonomous Action" all'Industrial AI Summit 2026. A rispondere a sei domande di architettura è Peter Sorowka, CEO di Cybus. Va detto subito: l'articolo è contrassegnato come sponsorizzato da Cybus ("Editorially Independent") e la sessione era sponsorizzata da Cybus, Barbara e HiveMQ. È dunque il punto di vista di un fornitore, non una ricerca indipendente, e va letto così.

Il server MCP come porta d'accesso alla fabbrica

MCP (Model Context Protocol) è un modo standard con cui un agente scopre e richiama strumenti. Nel contesto industriale lo "strumento" è il modello stesso della fabbrica: namespace, asset e valori in tempo reale. Questi elementi vengono esposti con le stesse regole di accesso valide per le persone. Di conseguenza qualsiasi LLM, conversazionale o agentico, può comprendere dati e contesto, leggerli e agire su di essi.

Cybus osserva tre schemi ricorrenti presso i clienti:

• assistenti ospitati, come Copilot Studio, collegati tramite chiave API;
• interfacce GPT interne basate su modelli di OpenAI, Anthropic e Google;
• modelli self-hosted, quando i dati devono restare nello stabilimento.

Secondo l'azienda, la propria piattaforma Connectware si comporta allo stesso modo indipendentemente dal modello utilizzato.

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

Per Sorowka la connettività è "in gran parte risolta" grazie a OPC UA e MQTT. La contestualizzazione invece no: AAS, i3X e le convenzioni UNS competono tra loro e la maggior parte degli impianti modella i dati in modo diverso da sito a sito. Manca inoltre uno standard industriale per la governance nel rapporto uomo-AI. MCP disciplina la chiamata, non il permesso: per scalare serve un modo portabile di esprimere chi può leggere e chi può agire.

MCP copre la chiamata, non il permesso.

Il ruolo dell'LLM e il livello di policy

Oggi l'LLM è soprattutto interfaccia e orchestratore. Il valore industriale continua a venire da modelli costruiti ad hoc per rilevamento di anomalie, previsione e ottimizzazione. L'LLM raccoglie il contesto, chiama questi modelli e spiega i risultati in un unico ciclo. Per le decisioni con conseguenze fisiche, la raccomandazione è vincolarle a regole e interblocchi dichiarati: il modello propone, un livello di policy decide che cosa è consentito.

Agent-to-agent: il problema dell'identità

Oggi un assistente raggiunge Connectware via MCP con una chiave che agisce per conto di una persona identificata. Nelle catene agent-to-agent "per conto di una persona" non basta più. Un'identità separata per l'agente, con un responsabile chiaramente attribuito, è indicata come voce di roadmap. La posizione di Cybus è che la governance appartenga al confine della fabbrica.

Cambiare il processo, non solo lo strumento

Sorowka definisce la maggior parte dei progetti uno "scambio vapore-elettricità": un agente al posto di una dashboard, in un processo rimasto identico. Il beneficio reale arriva riducendo il ciclo decisionale, cioè i passaggi di mano. Avverte inoltre di non sottovalutare sicurezza e flussi di approvazione nella produzione agentica a ciclo chiuso.

Che cosa portarsi a casa

Per chi guida progetti di AI in stabilimento, l'indicazione pratica è:

• collocare MCP al confine dell'impianto, con accesso limitato all'identità di chi chiama;
• inserire un livello di policy e interblocchi tra AI e attuazione;
• dichiarare il modello dati in una forma proiettabile in seguito su AAS o i3X, invece di attendere che uno standard prevalga;
• valutare le affermazioni con cautela, trattandosi di una prospettiva di fornitore.

Il valore dell'articolo sta nell'onestà sui limiti: contestualizzazione e identità degli agenti restano aperte. Modellare i dati in modo portabile è un passo a basso rimpianto, da compiere già ora.