Come portare l'intelligenza artificiale nei processi produttivi reali con MCP e .NET

Tutti parlano di intelligenza artificiale in fabbrica. Nei convegni, nelle riviste di settore, nei comunicati stampa dei fornitori di automazione. L'AI trasformerà il manifatturiero, l'AI rivoluzionerà la produzione, l'AI cambierà tutto.

Ma c'è una differenza enorme tra "mettere un chatbot sul sito" e costruire agenti AI che parlano davvero con i tuoi sistemi produttivi.

Immagina il responsabile di stabilimento che alle 6 di mattina, prima ancora di entrare in fabbrica, chiede al suo telefono: "Com'è andata la notte?" E riceve una risposta dettagliata: "La linea 2 ha avuto un fermo di 23 minuti alle 2:14 per un allarme temperatura sul forno di trattamento. Il lotto 5821 è stato completato con il 97,3% di efficienza. Ci sono 3 ordini in ritardo che richiedono la tua attenzione."

Non è fantascienza. È ciò che MCP rende possibile oggi, connettendo i modelli linguistici ai sistemi reali dell'azienda. La tecnologia esiste. Le librerie .NET esistono. Lo standard è aperto e stabile.

Il problema è che la maggior parte delle aziende manifatturiere italiane non lo sa ancora. E la maggior parte dei developer .NET non ha ancora capito che questa è l'opportunità professionale più concreta degli ultimi anni nel settore industriale.

Fino a oggi, l'AI in fabbrica significava due cose: sistemi di visione artificiale per il controllo qualità (costosi, verticali, difficili da generalizzare) e chatbot aziendali che conoscono i manuali ma non sanno nulla della tua produzione di ieri.

MCP cambia le regole del gioco. Non è un'altra tecnologia AI da imparare da zero. È un protocollo standard, aperto, che definisce come qualsiasi modello linguistico può connettersi a qualsiasi sistema aziendale in modo uniforme. Un "USB-C per l'intelligenza artificiale", secondo la definizione di chi lo ha progettato.

Le aziende manifatturiere che implementeranno questa architettura nei prossimi 18 mesi avranno un vantaggio competitivo che non sarà facile colmare. Gli altri seguiranno. La domanda è solo quando.

In questo articolo ti mostro come funziona davvero l'architettura MCP più agenti AI in ambito industriale, cosa si può costruire già oggi con .NET, quali sono i rischi concreti da non sottovalutare e come avviare un progetto pilota che produce valore reale in 90 giorni.

Se sviluppi in .NET e hai anche solo una curiosità per il mondo industriale, questo è il momento di leggere con attenzione.

Perché l'AI generica non funziona in fabbrica: il problema dei dati chiusi

ChatGPT conosce il mondo. Sa cos'è l'OEE, conosce le best practice per la manutenzione predittiva, può spiegare la differenza tra un sistema MES e un sistema ERP con precisione enciclopedica.

Ma non sa nulla della tua fabbrica.

Non sa che la linea 3 ha avuto un problema di vibrazione sul riduttore per tre settimane a febbraio. Non sa che l'efficienza del turno mattutino è mediamente il 4% più alta del turno notturno. Non sa che il cliente principale ha modificato i requisiti di tolleranza sul componente B7 e questo sta impattando i tempi di ciclo.

Questi dati che contano, la produzione di ieri, lo stato dei macchinari, i fermi non pianificati, i lotti fuori specifica, sono tutti nei tuoi sistemi interni. Nello SCADA. Nel MES. Nell'ERP. In fogli Excel che il capo turno compila ogni mattina.

Senza accesso a questi dati, l'AI è cieca sulla tua realtà operativa. Può aiutarti con procedure generiche, documentazione, spiegazioni teoriche. Ma non può rispondere alla domanda che conta davvero: "Cosa sta succedendo sulla linea 2 adesso?"

Il problema non è la qualità dei modelli AI. I modelli sono ottimi. Il problema è l'accesso ai dati.

Fino a novembre 2024, connettere un LLM ai sistemi aziendali significava costruire integrazioni custom per ogni coppia sistema-modello. Volevi connettere Claude al tuo SCADA? Un'integrazione. Volevi connettere Copilot al tuo MES? Un'altra integrazione. Volevi passare da Claude a GPT-4? Riscrivevi tutto.

Questo approccio non scala. Non scala in termini di costi di sviluppo, non scala in termini di manutenzione, non scala quando cambia il modello AI o quando aggiungi un nuovo sistema aziendale.

MCP risolve esattamente questo problema.

Model Context Protocol è uno standard aperto che definisce un'interfaccia universale per connettere qualsiasi LLM a qualsiasi fonte di dati o strumento esterno. La logica è quella del protocollo USB: prima di USB, ogni periferica aveva il suo connettore proprietario. Dopo USB, basta un'interfaccia standard per collegare tutto a tutto.

Con MCP, scrivi un "server MCP" che espone i dati del tuo SCADA come tool accessibili via protocollo standard. Qualsiasi agente AI compatibile con MCP, sia Claude, Copilot, Cursor o un agente personalizzato in .NET, può usare quei tool senza conoscere i dettagli del tuo sistema industriale.

La separazione delle responsabilità è netta: il server MCP conosce i dati industriali ma non sa nulla di AI. L'agente AI conosce il ragionamento ma non sa nulla del tuo SCADA specifico. MCP è l'interfaccia che li fa parlare.

Il vantaggio pratico per un'azienda manifatturiera è notevole. Costruisci il server MCP per il tuo SCADA una volta sola. Da quel momento, qualsiasi strumento AI che supporta MCP può accedere ai tuoi dati di produzione senza ulteriore lavoro di integrazione.

Quando Microsoft aggiornerà Copilot con nuove capacità, le userà con i tuoi dati. Quando Anthropic rilascerà una versione migliorata di Claude, funzionerà con la tua infrastruttura esistente. Quando la tua azienda deciderà di cambiare provider AI per ragioni di costo o di policy, cambierà solo il client, non l'intera integrazione.

Questa è la proposta di valore di MCP nel mondo industriale: disaccoppiare l'intelligenza (il modello) dai dati (i sistemi), con un'interfaccia standard che rende l'integrazione manutenibile nel lungo periodo.

E per un settore come il manifatturiero italiano, dove i sistemi legacy devono coesistere con le nuove tecnologie per anni o decenni, questo non è un dettaglio tecnico. È la differenza tra un investimento sostenibile e un vicolo cieco.

Cos'è un agente AI e come funziona in un contesto manifatturiero

La parola "agente" è usata in modo promiscuo nel mondo dell'AI. Vale la pena chiarire cosa significa nel contesto di questo articolo, perché la distinzione con un chatbot tradizionale è profonda e ha implicazioni concrete su cosa puoi fare e come lo costruisci.

Un chatbot risponde a domande. Prende il testo che gli dai, lo elabora, restituisce una risposta. È fondamentalmente un meccanismo di trasformazione testo in testo, anche quando è molto sofisticato.

Un agente AI esegue compiti. Riceve un obiettivo, lo scompone in passi, usa strumenti per raccogliere informazioni e agire, verifica se ha raggiunto l'obiettivo, corregge il percorso se necessario. È un sistema che ragiona e agisce in modo iterativo.

Il ciclo di un agente AI si articola in quattro fasi che si ripetono:

Percezione. L'agente riceve l'obiettivo dall'utente e raccoglie il contesto iniziale. Nel manifatturiero: l'utente chiede "Perché l'OEE della linea 3 è sceso sotto il 75% questa settimana?" L'agente inizia raccogliendo dati dal MES.

Ragionamento. L'LLM analizza i dati disponibili e decide il passo successivo. "Ho i dati di produzione ma mi mancano i dettagli sulle cause dei fermi. Devo interrogare il sistema di gestione allarmi dello SCADA."

Azione. L'agente chiama il tool MCP appropriato per recuperare i dati mancanti o eseguire l'operazione necessaria. Lo SCADA risponde con i dati degli allarmi delle ultime 7 giorni.

Verifica. L'agente valuta se ha abbastanza informazioni per rispondere all'obiettivo originale. Se no, torna alla fase di ragionamento e pianifica il passo successivo.

Questo ciclo continua finché l'agente non raggiunge l'obiettivo o decide che non ha abbastanza strumenti per proseguire.

La differenza pratica rispetto a un chatbot è enorme. Un chatbot può spiegarti cos'è l'OEE. Un agente AI può:

Interrogare il MES per recuperare i dati di produzione della settimana. Identificare che l'OEE è sceso del 6% rispetto alla settimana precedente. Interrogare lo SCADA per trovare i fermi non pianificati. Scoprire che ci sono stati 4 fermi sulla linea 3 per allarmi di temperatura. Correlare con i dati di manutenzione per verificare se il filtro aria del forno era in scadenza. Presentare al responsabile una diagnosi completa con la probabile causa radice e la proposta di azione correttiva.

Tutto questo in risposta a una singola domanda, senza che l'utente debba aprire 3 sistemi diversi, esportare dati su Excel e analizzarli manualmente.

Per il manifatturiero italiano, dove i responsabili di produzione passano ore ogni giorno a raccogliere dati da sistemi diversi per preparare report che diventano già obsoleti nel momento in cui vengono scritti, questo rappresenta un cambiamento operativo significativo.

Il potenziale non si ferma ai report. Un agente di monitoraggio può analizzare in modo continuo i dati SCADA e inviare alert proattivi quando rileva anomalie nei trend di temperatura, vibrazione o consumo energetico, ben prima che scatti un allarme formale. Un agente di schedulazione può ottimizzare la sequenza degli ordini di produzione considerando simultaneamente la disponibilità dei materiali, la capacità delle macchine, le priorità clienti e i vincoli di setup.

Non si tratta di sostituire l'operatore umano. Si tratta di amplificare la sua capacità di decisione, dandogli accesso immediato a informazioni rilevanti già elaborate, invece di costringerlo a raccoglierle e aggregarle manualmente.

MCP come infrastruttura per gli agenti AI in ambito industriale

Capire l'architettura MCP a livello tecnico è fondamentale per costruire sistemi che funzionano in produzione. Vediamo i componenti principali e come interagiscono.

MCP Server. È il componente che espone dati e funzionalità ai client. Nel contesto manifatturiero, scrivi un server MCP che si connette al tuo SCADA tramite OPC-UA, al tuo MES tramite le sue API, all'ERP tramite i suoi web service. Il server espone questi dati come "tool" che gli agenti possono chiamare. I tool hanno nome, descrizione e schema dei parametri. L'agente legge le descrizioni dei tool e decide autonomamente quale chiamare in base all'obiettivo.

MCP Client. È il componente integrato nell'agente AI che sa come parlare con i server MCP. Claude ha un client MCP nativo. Microsoft Copilot supporta MCP tramite connettori. Un agente custom in .NET usa l'SDK ModelContextProtocol per implementare il client.

Host. È l'applicazione che ospita l'agente e gestisce la comunicazione tra il client MCP e l'interfaccia utente. Può essere una web application in Blazor, un'API REST, un servizio di background che processa alert automatici, o uno strumento desktop per gli operatori di linea.

Il vantaggio architetturale di MCP nel manifatturiero diventa chiaro quando consideri la realtà di un'azienda con sistemi eterogenei. Uno stabilimento tipico ha uno SCADA per il controllo di produzione, un MES per la gestione degli ordini e la tracciabilità, un ERP per la pianificazione e la contabilità, forse un sistema di manutenzione (CMMS) separato, e dati storici in database o file.

Con l'approccio tradizionale (integrazioni custom), connettere un agente AI a tutti questi sistemi significa scrivere e mantenere N integrazioni separate, una per ogni sistema. Se cambi il modello AI, riscrivi tutto. Se cambi un sistema, aggiorni l'integrazione.

Con MCP, ogni sistema espone un server MCP standardizzato. L'agente AI parla con tutti i sistemi tramite lo stesso protocollo. Cambi modello AI? Il server MCP non cambia. Aggiungi un nuovo sistema? Scrivi un nuovo server MCP, l'agente lo rileva automaticamente.

Questa separazione delle responsabilità ha un impatto diretto sulla sostenibilità a lungo termine del progetto. Nel manifatturiero, i sistemi durano decenni. Un SCADA installato oggi sarà ancora in produzione tra 15 anni. Costruire integrazioni che siano manutenibili in quel lasso di tempo non è un lusso: è un requisito.

Un ulteriore vantaggio spesso sottovalutato: MCP supporta la scoperta dinamica dei tool. Un agente può chiedere al server MCP quali tool sono disponibili e usarli senza che siano stati configurati staticamente. Questo rende possibile costruire agenti generici che si adattano ai sistemi disponibili nel contesto specifico, senza richiedere una riscrittura per ogni variante di installazione.

Costruire un agente AI per il manifatturiero con .NET: l'architettura completa

Vediamo lo stack tecnologico concreto per costruire un agente AI che si connette ai sistemi industriali tramite MCP, usando .NET come piattaforma di sviluppo.

Microsoft.Extensions.AI è la libreria Microsoft per l'astrazione dei modelli LLM in .NET. Definisce interfacce standard come IChatClient che funzionano con Azure OpenAI, OpenAI diretto, Anthropic Claude e altri provider. Il vantaggio è la possibilità di cambiare provider LLM senza modificare il codice applicativo, esattamente come ILogger astrae il sistema di logging.

Semantic Kernel è il framework Microsoft per l'orchestrazione di agenti AI in .NET. Gestisce il ciclo di ragionamento dell'agente, la selezione e l'invocazione dei tool, la gestione della memoria conversazionale e l'integrazione con i modelli LLM tramite Microsoft.Extensions.AI. Per il manifatturiero è il componente che implementa la logica "pianifica, esegui, verifica" dell'agente.

ModelContextProtocol SDK è il pacchetto NuGet ufficiale per implementare client e server MCP in .NET. Lato server, permette di esporre tool annotando metodi C# con attributi. Lato client, permette all'agente di scoprire e invocare tool sui server MCP connessi.

La struttura del progetto si articola in tre livelli distinti:

Livello MCP Server (accesso dati). Uno o più progetti .NET che si connettono ai sistemi industriali. Il server MCP per lo SCADA usa OpcUaNetStandard per leggere tag e allarmi. Il server MCP per il MES chiama le API REST del sistema o accede direttamente al database. Ogni server espone tool con nomi descrittivi come GetLineEfficiency, GetUnplannedStoppages, GetOrderStatus.

Livello Agent Host (orchestrazione). Il progetto che ospita Semantic Kernel e gestisce il ciclo dell'agente. Riceve la richiesta dell'utente, la passa all'agente, monitora l'esecuzione, raccoglie il risultato. Può essere un servizio ASP.NET Core con endpoint REST o un servizio di background per monitoring automatico.

Livello UI. L'interfaccia verso gli utenti finali. Per un assistente conversazionale per il responsabile di stabilimento: una web application Blazor con chat interface. Per alert automatici: integrazione con Teams o email. Per dashboard operative: API REST consumata dalla visualizzazione esistente.

// Registrazione del client MCP e dell'agente Semantic Kernel
builder.Services.AddMcpClient(options =>
{
    options.AddServer("scada", new McpServerOptions
    {
        Command = "ScadaMcpServer",
        TransportType = McpTransportType.StdIo
    });
    options.AddServer("mes", new McpServerOptions
    {
        Url = "http://mes-mcp-server:5000/mcp",
        TransportType = McpTransportType.Http
    });
});

builder.Services.AddKernel()
    .AddAzureOpenAIChatCompletion(
        deploymentName: config["AzureOpenAI:DeploymentName"],
        endpoint: config["AzureOpenAI:Endpoint"],
        apiKey: config["AzureOpenAI:ApiKey"])
    .AddMcpToolsFromServices();

Il codice sopra mostra la registrazione del sistema. I server MCP vengono registrati con il loro tipo di trasporto (StdIo per processi locali, HTTP per server remoti). Semantic Kernel viene configurato con il modello LLM e i tool MCP vengono aggiunti automaticamente tramite AddMcpToolsFromServices().

Lato server MCP, la definizione dei tool è altrettanto semplice grazie agli attributi:

// Esempio di tool MCP per lo SCADA
[McpServerTool, Description("Restituisce l'efficienza OEE di una linea di produzione per un intervallo temporale")]
public async Task<LineEfficiencyResult> GetLineEfficiency(
    [Description("Identificatore della linea (es: LINEA_2)")] string lineId,
    [Description("Inizio periodo in formato ISO8601")] DateTime from,
    [Description("Fine periodo in formato ISO8601")] DateTime to)
{
    var tags = await _opcUaClient.ReadTagsAsync(lineId, from, to);
    return CalculateOee(tags);
}

L'agente legge la descrizione del tool, capisce cosa fa, e decide autonomamente se e quando chiamarlo in base all'obiettivo che deve raggiungere. Le descrizioni sono fondamentali: più sono precise e contestualizzate al dominio manifatturiero, più l'agente farà scelte corrette.

Un aspetto critico per la produzione industriale: la gestione degli errori e dei timeout. I sistemi SCADA possono avere latenze variabili, i server OPC-UA possono essere temporaneamente irraggiungibili, il MES può avere finestre di manutenzione. Il server MCP deve gestire questi casi in modo elegante, restituendo errori strutturati che l'agente può interpretare e segnalare all'utente invece di propagare eccezioni.

Esempi concreti di agenti AI in produzione: cosa funziona oggi

Abbandoniamo la teoria. Vediamo tre scenari concreti di agenti AI che risolvono problemi reali nelle fabbriche, con le considerazioni pratiche per ciascuno.

Caso 1: l'assistente virtuale per il responsabile di stabilimento.

Il responsabile inizia il turno chiedendo all'agente: "Dammi un briefing sulla situazione attuale." L'agente interroga il MES per gli ordini aperti e i ritardi, lo SCADA per lo stato delle linee e gli allarmi attivi, e il sistema di manutenzione per gli interventi programmati del giorno. Restituisce un riassunto strutturato in linguaggio naturale con i punti critici che richiedono attenzione.

Durante il turno, il responsabile può fare domande specifiche: "Perché la linea 4 è al 68% di efficienza?" L'agente analizza i dati degli ultimi 2 turni, identifica i fermi principali, correla con i dati degli allarmi e risponde con una diagnosi con probabilità stimate per ogni causa.

Il valore di questo agente non è nella risposta alle domande ovvie. È nell'eliminare il tempo che il responsabile passa ogni mattina ad aprire sistemi diversi, esportare dati, confrontarli manualmente. Un'ora al giorno di tempo risparmiato per il responsabile, su base annua, vale decine di migliaia di euro in produttività.

Caso 2: il monitor proattivo di anomalie.

Questo agente non aspetta le domande: funziona in background, analizzando periodicamente i dati SCADA per rilevare pattern anomali.

Non si limita a rilanciare gli allarmi che già esistono nel sistema. Fa qualcosa di più sofisticato: analizza trend. Una temperatura che sale di 0,3 gradi ogni ora non genera un allarme oggi, ma tra 8 ore supererà la soglia critica. Un agente di monitoring che analizza questo trend può notificare il tecnico di manutenzione con anticipo, permettendo un intervento preventivo durante la prossima finestra di manutenzione programmata invece di gestire un fermo non pianificato nel momento peggiore.

La notifica include non solo l'anomalia ma il contesto: "La temperatura del motore M-14 sulla linea 3 sta crescendo con un trend di 0.28°C/ora. Al tasso attuale, raggiungerà la soglia di allarme (85°C) in circa 7 ore. Storico: questa macchina ha avuto un guasto al cuscinetto 14 mesi fa con un pattern simile. Raccomandazione: verifica lubrificazione e stato cuscinetti alla prossima fermata programmata (ore 14:00)."

Caso 3: l'ottimizzatore di schedulazione ordini.

La schedulazione della produzione è un problema di ottimizzazione complesso. Il planner deve bilanciare priorità clienti, disponibilità materiali, capacità macchine, tempi di setup, scadenze di consegna. Tipicamente questo si fa con fogli Excel e molta esperienza.

Un agente connesso al MES e all'ERP può analizzare la situazione degli ordini aperti, la disponibilità reale delle linee (includendo i fermi pianificati per manutenzione), le scorte di materiali, e proporre una sequenza ottimizzata con la spiegazione del ragionamento.

Non si tratta di rimpiazzare il planner. L'agente propone, il planner rivede e approva. Ma invece di partire da zero ogni mattina, il planner parte da una proposta già coerente con tutti i vincoli noti, e usa la sua esperienza per aggiustare i casi particolari che richiedono giudizio umano.

Questi tre casi hanno qualcosa in comune: non sostituiscono i sistemi esistenti, ci si appoggiano sopra. Lo SCADA continua a fare il controllo di processo. Il MES continua a gestire la tracciabilità. L'agente AI è un'interfaccia intelligente che rende questi sistemi più accessibili e il loro valore più immediatamente fruibile.

Sicurezza degli agenti AI in ambiente industriale OT: i rischi da non sottovalutare

La sicurezza in ambito OT (Operational Technology) è un argomento che non può essere trattato come una nota a piè di pagina. Un sistema di controllo industriale che si ferma o si comporta in modo inatteso può causare danni fisici, perdite economiche significative e, nei casi più gravi, rischi per la sicurezza delle persone.

Quando si introduce un agente AI connesso ai sistemi industriali, i rischi cambiano natura rispetto a un'applicazione software tradizionale. Non si tratta solo di bug o vulnerabilità di sicurezza informatica. Si tratta di un sistema che prende decisioni e potenzialmente esegue azioni in modo autonomo, sulla base di un ragionamento che non è sempre prevedibile.

Il principio fondamentale è il seguente: nessun agente AI deve poter inviare comandi di controllo diretti a PLC o sistemi SCADA senza supervisione esplicita di un operatore umano.

Questo significa che l'architettura deve essere progettata con questa separazione come vincolo non negoziabile. I tool MCP esposti al sistema di lettura devono essere separati architetturalmente dai tool di scrittura/comando. I tool di lettura vengono usati liberamente dall'agente per raccogliere dati. I tool di scrittura richiedono un pattern di approvazione esplicita: l'agente propone l'azione, l'operatore approva tramite un'interfaccia dedicata, solo dopo l'approvazione l'azione viene eseguita.

Vediamo i rischi concreti da indirizzare:

Privilege escalation nei tool. Se un tool MCP di lettura espone anche funzionalità di scrittura "per comodità", un agente potrebbe usarle in modo inatteso. Ogni tool deve avere scope preciso e minimo. Un tool che legge lo stato delle valvole non deve poter modificarne lo stato, nemmeno "di servizio".

Prompt injection. Un attaccante potrebbe modificare i dati in un sistema industriale (un campo note in un record MES, il nome di un lotto) in modo da includere istruzioni per l'agente AI. Questo è un rischio reale nei sistemi dove i dati provengono da fonti non completamente controllate. La soluzione è la validazione del contesto: i tool MCP non devono mai restituire dati grezzi non sanitizzati.

Latenza delle decisioni. In ambienti dove le condizioni cambiano rapidamente (un processo chimico, una linea ad alta velocità), un agente che impiega 30 secondi per ragionare e rispondere potrebbe proporre azioni già obsolete. L'architettura deve chiarire quali decisioni possono essere delegate all'agente (analisi diagnostica, report) e quali richiedono sistemi di controllo real-time (loop di controllo PID, sicurezze).

Audit log e tracciabilità. Ogni azione proposta dall'agente, ogni approvazione dell'operatore, ogni chiamata a un tool MCP deve essere registrata con timestamp, utente e payload completo. Nei settori regolamentati (farmaceutico, alimentare) questo è un requisito normativo. Negli altri è una best practice irrinunciabile per diagnosticare problemi e dimostrare compliance.

Sandboxing delle capability. L'agente deve avere accesso solo ai sistemi e ai dati necessari per il suo scopo specifico. Un agente di reporting sulla produzione non ha bisogno di accesso al sistema di gestione degli accessi fisici. Applicare il principio del minimo privilegio anche agli agenti AI.

La rete deve essere segmentata: il server MCP che accede allo SCADA deve risiedere nella DMZ della rete OT, con accesso controllato sia dalla rete IT che dalla rete OT. Non deve esistere un percorso diretto tra l'agente AI (che potrebbe essere esposto su internet per l'accesso mobile) e i PLC.

Questi requisiti di sicurezza non sono ostacoli all'adozione. Sono il framework che rende l'adozione sostenibile e affidabile. Un'azienda che implementa MCP e agenti AI rispettando questi principi costruisce un sistema su cui può appoggiarsi. Una che li ignora crea vulnerabilità.

L'integrazione con Copilot Studio e Azure AI Foundry: per chi non vuole partire da zero

Non ogni azienda manifatturiera ha un team di sviluppo .NET interno capace di costruire un sistema agente AI from scratch. Per molte PMI italiane, questo è il caso più comune. E la risposta di Microsoft a questo scenario è concreta.

Microsoft Copilot Studio è la piattaforma no-code/low-code per creare agenti AI personalizzati nell'ecosistema Microsoft 365. A partire dal 2025, Copilot Studio supporta i connettori MCP nativamente. Questo significa che puoi prendere un server MCP scritto in .NET che espone i dati del tuo SCADA, registrarlo come connettore in Copilot Studio, e creare un agente che usa quei dati senza scrivere codice per l'orchestrazione.

Il vantaggio è la velocità di setup e l'integrazione con Teams, SharePoint e Outlook. Il responsabile di stabilimento può interrogare i dati di produzione direttamente da Teams, usando l'interfaccia che già conosce. Non serve una nuova applicazione, non serve formazione su nuovi strumenti.

Il limite è la personalizzazione. Copilot Studio gestisce bene i flussi di conversazione strutturati, ma ha vincoli su logiche di orchestrazione complesse, ragionamento multi-step profondo e integrazione con sistemi non Microsoft.

Azure AI Foundry (l'evoluzione di Azure AI Studio) è la piattaforma Microsoft per agenti AI custom su modelli Azure OpenAI. Permette di definire agenti con capacità di ragionamento avanzate, di configurare tool e connessioni MCP, e di deployare gli agenti come servizi Azure. È la scelta per chi vuole la flessibilità del codice con il vantaggio dell'infrastruttura gestita da Microsoft.

Come scegliere tra Copilot Studio, Azure AI Foundry e lo sviluppo custom in .NET?

Copilot Studio conviene se la tua azienda è già nell'ecosistema Microsoft 365, vuoi un proof-of-concept in 2-3 settimane, il tuo caso d'uso è principalmente conversazionale e non hai requisiti di personalizzazione profonda. I limiti emergono quando hai logiche di business complesse, hai bisogno di integrazioni con sistemi legacy non standard o hai requisiti di sicurezza OT stringenti.

Azure AI Foundry conviene se vuoi usare i modelli Azure OpenAI con supporto enterprise (SLA, data residency europea, compliance), hai bisogno di un livello intermedio tra no-code e sviluppo full custom, e il tuo team ha competenze cloud Azure.

Sviluppo custom in .NET con Semantic Kernel e SDK MCP conviene se hai requisiti di personalizzazione profondi, devi integrare sistemi legacy con API non standard, hai requisiti di sicurezza OT che richiedono controllo totale sull'architettura, o stai costruendo un prodotto che vuoi mantenere per anni. È la scelta con il costo iniziale più alto ma con la maggiore flessibilità a lungo termine.

In molti progetti reali la risposta è ibrida: un server MCP custom in .NET per l'accesso ai sistemi industriali legacy, Azure AI Foundry o Copilot Studio per l'orchestrazione dell'agente, e un'interfaccia Teams per gli utenti. Scrivi il codice custom solo dove è strettamente necessario, e usi piattaforme gestite per il resto.

Per una PMI manifatturiera italiana con un budget limitato, questo approccio ibrido permette di arrivare a un primo agente funzionante in 4-6 settimane con un investimento ragionevole, per poi valutare se investire nello sviluppo custom basandosi sui risultati reali del pilota.

Il ROI degli agenti AI in fabbrica: come misurare il valore e convincere il management

Qualsiasi progetto tecnologico in un'azienda manifatturiera deve rispondere a una domanda semplice: quanto vale? I decision maker del manifatturiero italiano sono pragmatici. Non investono su visioni del futuro: investono su ritorni dimostrabili.

Il problema con gli agenti AI è che il valore è spesso difficile da quantificare a priori, perché dipende da quanto tempo le persone passano oggi a fare cose che l'agente potrebbe fare meglio e più velocemente. Bisogna partire dalla misurazione del problema attuale.

Tempo di raccolta dati per i report operativi. Quanto tempo impiega il responsabile di produzione ogni mattina per raccogliere i dati della notte e preparare il briefing per la direzione? In molte aziende manifatturiere italiane di media dimensione, questa attività occupa 45-90 minuti al giorno. Un agente AI che fa questa raccolta automaticamente e la presenta in modo strutturato recupera quell'ora ogni giorno. Per un responsabile con un costo aziendale di 60.000 euro l'anno, l'ora quotidiana vale circa 15.000 euro annui di produttività recuperata. Solo da questo caso d'uso.

MTTR (Mean Time To Repair) e fermi non pianificati. Quanto dura mediamente un fermo non pianificato sulla tua linea principale? Qual è il costo orario di quel fermo? Per una linea da 10 milioni di euro di fatturato annuo che lavora su 2 turni, il costo orario di un fermo si aggira intorno ai 4.000-6.000 euro per il solo mancato valore aggiunto, escluso lo straordinario per il recupero.

Un agente di monitoring che rileva anomalie in anticipo e riduce il MTTR del 20% su una linea con 50 ore di fermo non pianificato all'anno (un valore comune) vale 40.000-60.000 euro di mancato fermo. Questo è un dato misurabile, confrontabile prima e dopo l'implementazione.

OEE e ottimizzazione della schedulazione. Su una linea con un fatturato di 10 milioni di euro l'anno, ogni punto percentuale di OEE vale circa 100.000 euro. Un agente che ottimizza la schedulazione degli ordini, riducendo i tempi di setup non necessari e minimizzando le attese per materiali, può ragionevolmente contribuire a 0,5-1,5 punti di OEE aggiuntivi in 12 mesi. Vale 50.000-150.000 euro.

Come presentare questi numeri al management? Il framework in tre passi:

Primo: quantifica il costo del problema attuale. Fai fare al responsabile di produzione una stima onesta di quanto tempo passa a raccogliere dati invece di analizzarli. Misura la frequenza e la durata media dei fermi non pianificati. Calcola l'OEE attuale e confrontalo con il best-in-class del settore.

Secondo: proponi un pilota con obiettivi misurabili. Non "implementare l'AI in fabbrica". Ma "ridurre il tempo di preparazione del briefing mattutino da 60 a 10 minuti" o "ridurre il MTTR medio del 15% in 6 mesi". Obiettivi specifici, misurabili, con una baseline definita prima dell'inizio.

Terzo: dimensiona il pilota in modo che il ROI sia dimostrabile anche con risultati parziali. Un pilota da 50.000 euro che riduce i fermi del 10% su una linea che fermò costa 5.000 euro l'ora ha un payback in meno di 2 mesi se la riduzione vale solo 20 ore di fermo l'anno. I numeri devono reggere anche nello scenario conservativo.

Come avviare un progetto pilota di agenti AI con MCP in 90 giorni

Novanta giorni per dimostrare valore reale. Questo è il framework che consiglio per qualsiasi azienda manifatturiera italiana che voglia iniziare con MCP e agenti AI senza rischiare investimenti significativi su tecnologie non ancora validate nel proprio contesto.

Il principio guida è semplice: valore reale in 90 giorni, o si ferma tutto. Non pilot eterni che producono PowerPoint. Non sperimentazioni laboratorio sconnesse dalla realtà operativa. Un agente in produzione, con utenti reali, che risponde a domande reali sui dati reali.

Settimane 1-4: fondamenta e inventario.

Il primo mese è dedicato a capire cosa c'è e a costruire le fondamenta tecniche. L'attività principale è l'inventario dei sistemi: quali sistemi esistono (SCADA, MES, ERP, altri), quali dati espongono, come si accede (API REST, OPC-UA, database diretto, file export), chi è il responsabile tecnico di ciascuno.

Contemporaneamente si identificano i 3-5 utenti pilota: il responsabile di produzione, il capo turno più tech-savvy, il responsabile manutenzione. Si fanno interviste per capire le 3 domande che fanno più spesso ai sistemi e per cui impiegano più tempo a trovare risposta. Queste diventano i casi d'uso del pilota.

Sul piano tecnico: setup dell'ambiente di sviluppo, scelta del modello LLM (Azure OpenAI è la scelta più sicura per le PMI italiane per ragioni di data residency e supporto enterprise), implementazione del primo server MCP in sola lettura collegato al sistema con i dati più rilevanti. Solo lettura: nessun tool di scrittura nelle prime 4 settimane.

Settimane 5-8: primo agente in produzione.

Con le fondamenta pronte, si costruisce il primo agente. Non il più sofisticato: il più utile. Tipicamente un assistente di Q&A che risponde alle 3 domande identificate nelle settimane precedenti, usando i dati dal server MCP.

L'interfaccia deve essere la più semplice possibile: una chat web accessibile da browser, preferibilmente integrata in Teams se l'azienda lo usa già. L'obiettivo non è fare bella figura con la tecnologia, è far usare lo strumento alle persone.

Nelle settimane 5-8 si raccoglie feedback continuo dagli utenti pilota. Cosa funziona? Cosa non funziona? Quali domande l'agente risponde male? Il prompt di sistema dell'agente viene iterato ogni settimana basandosi sul feedback reale.

Un elemento critico: non nascondere gli errori. Se l'agente risponde in modo errato a una domanda, vuoi saperlo subito. Metti un meccanismo di feedback esplicito (pollice su/giù) e discuti gli errori con gli utenti pilota nella review settimanale.

Settimane 9-12: misurazione e decisione.

L'ultimo mese è dedicato alla misurazione dei risultati rispetto agli obiettivi definiti all'inizio e alla decisione su come proseguire.

Misura quanto tempo gli utenti pilota risparmiano usando l'agente invece dei sistemi tradizionali. Registra la qualità delle risposte (percentuale di risposte corrette vs. incorrect, basata sul feedback raccolto). Calcola il ROI preliminare basandosi sul tempo risparmiato e sulle basi economiche identificate prima del pilota.

La decisione finale ha tre opzioni possibili: estendere il pilota a più utenti e più casi d'uso (il pilota ha dimostrato valore, si investe di più), ristrutturare il pilota su basi diverse (il valore c'è ma il caso d'uso non era quello giusto), fermare (il valore non è dimostrabile nel contesto specifico dell'azienda, meglio usare le risorse altrove).

La terza opzione è legittima. Non ogni azienda è pronta per gli agenti AI in questo momento. Le ragioni possono essere la qualità dei dati nei sistemi esistenti, la maturità del team IT, la resistenza culturale al cambiamento. Meglio scoprirlo dopo 90 giorni con un investimento contenuto che dopo 2 anni e 500.000 euro di progetto.

Il 90-day framework funziona perché forza le decisioni difficili a emergere presto. Se i dati dello SCADA sono troppo sporchi per essere usati da un agente AI, lo scopri alla settimana 3, non alla settimana 40. Se gli utenti non usano lo strumento nonostante i briefing entusiasti, lo scopri alla settimana 6. Queste sono informazioni preziose che guidano l'investimento futuro.

Il mercato italiano e le competenze che mancano: perché è il momento giusto per un developer .NET

Chiudiamo con una prospettiva sul mercato, perché questo articolo è scritto anche per i developer .NET che stanno valutando dove investire il loro tempo di apprendimento nei prossimi 12-18 mesi.

Il manifatturiero è il settore con il PIL più alto d'Italia dopo i servizi. Le PMI manifatturiere italiane sono il cuore del sistema economico del paese: meccanica di precisione, componentistica automotive, farmaceutico, packaging, alimentare. Tutte queste aziende hanno sistemi SCADA, MES, ERP. Tutte stanno sentendo la pressione competitiva dell'Industry 4.0. Quasi nessuna ha un team interno capace di costruire agenti AI.

La figura professionale che serve è una figura ibrida: qualcuno che conosce .NET, capisce almeno i principi dei sistemi industriali (OPC-UA, MES, SCADA), e sa costruire applicazioni AI con MCP e Semantic Kernel. Questa figura praticamente non esiste sul mercato italiano nel 2026.

Chi la costruisce nei prossimi 12 mesi si posiziona in un mercato con domanda alta e offerta quasi nulla.

Le competenze da acquisire, nell'ordine di priorità:

Microsoft.Extensions.AI e Semantic Kernel. Il framework di Microsoft per agenti AI in .NET è maturo, ben documentato e supportato nel lungo periodo. È la base su cui costruire.

SDK ModelContextProtocol. La libreria ufficiale per MCP in .NET. Impararla richiede un paio di settimane, ma è la competenza più differenziante nel breve periodo.

OPC-UA e sistemi SCADA. Non serve diventare ingegneri di automazione. Serve capire come funzionano a sufficienza per costruire server MCP che leggono dati da questi sistemi. L'articolo su come costruire sistemi SCADA con C# e .NET è il punto di partenza.

Azure OpenAI e Azure AI Foundry. Per le PMI manifatturiere italiane, Azure è la piattaforma cloud più realistica: presenza locale, supporto enterprise, compliance europea sui dati. Saper deployare agenti su Azure AI Foundry è una competenza commercialmente rilevante.

Il momento giusto per iniziare è adesso. MCP è abbastanza maturo da essere affidabile in produzione, ma abbastanza nuovo da non avere ancora una massa critica di developer specializzati. Questa finestra non rimarrà aperta per sempre.

Le aziende manifatturiere italiane stanno iniziando a fare le prime domande su questi temi. Chi arriva a queste conversazioni già preparato, con un prototipo funzionante e la competenza per guidare un pilota, troverà un terreno molto fertile.

L'AI non è una moda. I LLM non sono la soluzione a tutto. Ma connettere l'intelligenza artificiale ai dati reali delle fabbriche italiane tramite MCP è una delle opportunità tecniche più concrete e a più alto impatto dei prossimi anni. E richiede esattamente le competenze che i developer .NET già hanno, più un investimento mirato su MCP e Semantic Kernel.

Vale la pena farlo.