IA agentica per la soluzione di riferimento

Dopo aver distribuito la soluzione di riferimento, i dati di telemetria OPC UA della factory sono connessi, normalizzati rispetto alla gerarchia di asset ISA-95 e resi querybili tramite Esplora dati di Azure (o una Microsoft Fabric Eventhouse) e l'API I3X. Si tratta esattamente del tipo di dati fondati, ben strutturati e in tempo reale di cui una soluzione di IA agentica ha bisogno. Questo articolo descrive come funziona un agente di intelligenza artificiale basato sulla soluzione di riferimento, partendo da un Plant Copilot distribuito automaticamente in sola lettura che risponde a domande in linguaggio naturale sull'impianto e delinea un percorso sicuro verso agenti in grado di agire.

Perché l'intelligenza artificiale agentic necessita di un modello informativo

I modelli linguistici di grandi dimensioni sono potenti strumenti di ragionamento, ma non conoscono il tuo impianto. Non sanno che la "cella di lavoro 3" è una stazione di assemblaggio sulla linea di assemblaggio di Seattle, quale sia il suo consumo energetico attuale, né quale sia stato l'andamento della sua produttività nell'ultimo turno. Se poni queste domande a un modello grezzo, tirerà a indovinare, e in produzione questo è inaccettabile.

La soluzione di riferimento risolve questo problema fornendo all'agente degli strumenti invece di chiedergli di ricordare dei fatti:

• La gerarchia degli asset ISA-95 (azienda → sito → area → linea → cella → asset) fornisce all'agente una mappa navigabile dell'impianto.
• Il modello di informazioni OPC UA (tipi di oggetto e variabili) indica all'agente quali tipi di asset esistono e quali misure.
• I valori live e le tendenze cronologiche forniscono all'agente i numeri effettivi, con timestamp e qualità, al momento necessario.

Poiché ogni risposta viene considerata come risultato di uno strumento, l'agente può citare l'asset esatto, il valore e il tempo usati, che è essenziale per l'attendibilità e la verificabilità.

Protocollo MCP (Model Context Protocol)

L'agente comunica con questi strumenti tramite il protocollo MCP (Model Context Protocol), uno standard aperto per esporre strumenti e dati agli agenti LLM. MCP è supportato da Microsoft 365 Copilot, Microsoft Copilot Studio, Microsoft Foundry, Claude e un elenco crescente di host, quindi un singolo server MCP può essere riutilizzato in molte esperienze degli agenti.

Questa soluzione di riferimento include un server MCP, Plant Copilot, in Tools/PlantCopilot. Si tratta di un wrapper di sola lettura leggero dell'API I3X che presenta i dati della fabbrica sotto forma di una manciata di strumenti ben descritti. È pacchettizzata come immagine Docker e distribuita come Azure Container App, usando il trasporto MCP HTTP streamable in modo che i runtime degli agenti remoti possano accedervi tramite HTTPS all'indirizzo /mcp.

Architecture

   ┌──────────────┐        natural language        ┌──────────────────────┐
   │    User      │  ───────────────────────────►  │   Agent runtime      │
   │ (chat / app) │  ◄───────────────────────────  │   (Microsoft 365     │
   └──────────────┘        grounded answer         │   Copilot, Foundry…) │
												   └──────────┬───────────┘
													   	      │ MCP
															  ▼
												   ┌──────────────────────┐
												   │     Plant Copilot    │
												   │      MCP server      │
												   └──────────┬───────────┘
													   	      │ I3X
															  ▼
												   ┌──────────────────────┐
												   │       I3X4Kusto      │
												   └──────────┬───────────┘
													  	      │ KQL
															  ▼
												   ┌──────────────────────┐
												   │ Azure Data Explorer  │
												   │ / Fabric Eventhouse  │
												   └──────────────────────┘

L'agente non tocca mai direttamente il database. Ha accesso solo agli strumenti selezionati e di sola lettura, e il livello I3X impone l'autenticazione e la struttura dei dati conforme a ISA-95.

Strumenti di Plant Copilot

Con questi strumenti un agente può rispondere a domande come:

• "Qual è il consumo energetico corrente della cella di lavoro 3?"
• Qual è stato l'andamento della produttività della linea di produzione di Monaco durante l'ultimo turno?
• Quali asset sono stazioni di test e quali hanno una pressione elevata in questo momento?
• "Elencare i siti e le linee nell'impianto."

Esecuzione dell'impianto Copilot

Plant Copilot è distribuito per te come parte della soluzione di riferimento. Non c'è niente di più da configurare. L'immagine del contenitore viene creata e pubblicata automaticamente in ghcr.io/digitaltwinconsortium/manufacturingontologies/plantcopilot:main e il modello di distribuzione ne effettua il provisioning come Azure Container App collegata all'app I3X nel cluster. La distribuzione espone il proprio endpoint MCP remoto come output plantCopilotMcpUrl, ad esempio https://<resourcesName>-plantcopilot.<region>.azurecontainerapps.io/mcp.

Per rendere disponibile Plant Copilot all'interno dell'esperienza Microsoft 365 Copilot, è necessario registrarlo come strumento del Model Context Protocol, aggiungerlo a un agente personalizzato e pubblicare tale agente in Microsoft 365 Copilot.

Prerequisiti relativi alle autorizzazioni e alla governance. La registrazione di un connettore MCP personalizzato e la pubblicazione di un agente sono regolate dai criteri a livello di tenant che possono essere configurati solo dagli amministratori. Prima di iniziare, assicurarsi che un amministratore di Power Platform (e, dove indicato, un amministratore di Microsoft 365 e un amministratore di Entra ID) abbia organizzato quanto segue; in caso contrario, la connessione non riesce alla creazione o all'accesso:

• Accesso per creatori a Copilot Studio — un ambiente Power Platform in cui è possibile creare agenti (ruolo Creatore dell'ambiente), idealmente un ambiente dedicato di sviluppo/sandbox.
• Criterio DLP per i dati — il connettore personalizzato Plant Copilot deve essere classificato in un gruppo autorizzato (Business o Non-Business, corrispondente agli altri connettori dell'agente), non Bloccato. Configurato in Criteri di sicurezza → dati nell'interfaccia di amministrazione di Power Platform.
• Isolamento del tenant / filtro dell'endpoint del connettore — il traffico OAuth in uscita verso l'host di Plant Copilot (https://<resourcesName>-plantcopilot.<region>.azurecontainerapps.io) deve essere consentito. Si tratta di impostazioni con ambito tenant che solo un amministratore globale o Power Platform può visualizzare o modificare.
• Entra ID (solo modalità di autenticazione di produzione) — se il server è eseguito con AUTH_AUTHORITY impostato su Entra ID, un amministratore registra l'app del connettore e deve assicurarsi che nessun criterio di accesso condizionale impedisca l'accesso. L'esatto criterio di blocco è visualizzato in Entra ID → Log di accesso.
• Approvazione dell'amministratore di Microsoft 365 — la pubblicazione dell'agente nel canale Microsoft 365 Copilot potrebbe richiedere l'approvazione nell'interfaccia di amministrazione di Microsoft 365 in Impostazioni → App integrate.

Se non si è un amministratore, condividere questo elenco (più il nome del connettore e l'URL host) con l'amministratore del tenant. Nulla nel codice di Copilot plant o nella distribuzione può ignorare questi controlli di governance del tenant.

Registrare il server MCP come strumento

In Microsoft Copilot Studio selezionare Strumenti → Nuovo strumento → Model Context Protocol e specificare:

• Nome server: Plant Copilot
• Descrizione del server:A read-only MCP server that exposes the plant's ISA-95 asset hierarchy, OPC UA information model, and live/historical telemetry.
• URL del server:https://<resourcesName>-plantcopilot.<region>.azurecontainerapps.io/mcp
• Autenticazione: OAuth 2.0 con l'individuazione dinamica (plant Copilot annuncia il server di autorizzazione e supporta la registrazione dinamica del client, quindi non è necessario immettere id client/segreto)

Creare lo strumento. Alla prima connessione, Copilot Studio esegue il flusso OAuth sul Plant Copilot; approvalo per stabilire la connessione.

Creare l'agente

1. In Copilot Studio selezionare Crea → Nuovo agente (o Agenti → Nuovo agente).
2. Assegnare all'agente un nome (ad esempio , Plant Copilot) e una descrizione e impostare le istruzioni che lo guidano per rispondere solo dai risultati dello strumento. Ad esempio: "Sei un assistente di impianto. Usa gli strumenti Plant Copilot per rispondere a domande su asset, valori in tempo reale e cronologia. Basa sempre le risposte sui risultati degli strumenti e cita l'ID dell'asset, il valore e il timestamp utilizzato. Non inventare mai dati."
3. In Strumenti dell'agente selezionare Aggiungi strumento e scegliere lo Plant Copilot strumento MCP registrato nel passaggio 1.
4. Usa il riquadro Test per confermare che l'agente richiami gli strumenti e restituisca risposte fondate (ad esempio, chiedi "Elenca i siti e le linee nell'impianto").

Pubblica in Microsoft 365 Copilot

1. Selezionare Pubblica per pubblicare l'agente.
2. Aprire la scheda Canali e abilitare Microsoft 365 Copilot (Teams e Microsoft 365 Copilot).
3. Inviare l'agente per l'approvazione dell'amministratore se il tenant lo richiede; un amministratore Microsoft 365 lo approva nella interfaccia di amministrazione di Microsoft 365 in Impostazioni → App integrate.

Dopo la pubblicazione e l'approvazione, gli utenti possono selezionare l'agente in Microsoft 365 Copilot (in Teams, Outlook o il app Microsoft 365 Copilot) e porre direttamente le domande sull'impianto. Copilot basa le sue risposte sui risultati degli strumenti restituiti da Plant Copilot.

Alternativa: un agente dati Fabric su Eventhouse

Se si utilizza l'opzione Microsoft Fabric della soluzione di riferimento, è possibile creare la stessa esperienza di copilota per l'impianto basata sui dati interamente all'interno di Fabric, senza il server MCP, Copilot Studio o la governance associata dei connettori. Un agente dati di Fabric risponde a domande in linguaggio naturale sulle origini dati di Fabric generando query (KQL) direttamente su di esse. Poiché la soluzione di riferimento rispecchia già le stesse tabelle, funzioni e visualizzazioni OPC UA nella Fabric Eventhouse, i dati dell'impianto sono direttamente disponibili per l'agente per eseguire query.

Quando usare quale. Il server MCP di Plant Copilot è l'opzione cross-host: un'unica interfaccia di strumenti in sola lettura riutilizzabile in molti runtime di agenti (Microsoft 365 Copilot, Claude e altri). Un agente dati di Fabric è il percorso interno a Fabric più rapido: richiede solo l'accesso a Fabric, ma è limitato all'esperienza Fabric e interroga KQL direttamente anziché usare gli strumenti I3X di sola lettura selezionati. Si noti che un agente dati di Fabric non è un host MCP; non chiama il server MCP di Plant Copilot. Al contrario, Fabric può esporre un agente dati come server MCP per l'utilizzo da parte di altri host. Si noti che l'agente dati Fabric richiede una capacità F2+ a pagamento, richiede impostazioni di elaborazione/archiviazione di intelligenza artificiale tra aree geografiche e può inviare risposte al di fuori del limite di conformità o dell'area geografica di Fabric.

Per crearne uno:

1. Aprire l'area di lavoro Fabric che contiene la eventhouse di cui è stato effettuato il provisioning dalla soluzione di riferimento.
2. Creare un agente dati e aggiungere il database Eventhouse/KQL come origine dati.
3. Imposta istruzioni che mantengano le risposte basate sui dati, ad esempio: "Sei un assistente dell'impianto. Rispondi alle domande sugli asset, sui valori in tempo reale e sulla cronologia usando Eventhouse. Basa sempre le risposte sui risultati della query e cita l'ID dell'asset, il valore e il timestamp. Non inventare mai dati."
4. Facoltativamente, aggiungere alcune domande di esempio e le relative query KQL per indirizzare l'agente verso le tabelle, le funzioni e le viste ISA-95 (vedere Connettere Microsoft Fabric alla soluzione di riferimento).
5. Esegui il test con le stesse domande ("Qual è il consumo energetico attuale della stazione di assemblaggio di Seattle?", "Come si è evoluta la velocità effettiva della linea di produzione di Monaco durante l'ultimo turno?"); l'agente genera query KQL sull'Eventhouse e basa le proprie risposte sui risultati.

Poiché la soluzione di riferimento normalizza i dati di telemetria rispetto alla gerarchia degli asset ISA-95 e al modello informativo OPC UA, Eventhouse fornisce già la struttura semantica di cui un agente dati ha bisogno per ragionare sull'impianto.

Oltre alla sola lettura: agenti che eseggono un'azione

Rispondere alle domande è solo il primo scenario. Poiché la soluzione di riferimento contiene già dati normalizzati basati su modello, sono possibili diversi scenari agenti con valori più elevati:

• Triage delle anomalie — quando il rilevamento delle anomalie o la pipeline di previsione segnala un asset, un agente raccoglie il contesto correlato (cronologia recente, asset correlati, tipo di asset) e redige una spiegazione e una raccomandazione sul passo successivo da sottoporre alla revisione di un operatore.
• Ordini di lavoro di manutenzione predittiva: un agente trasforma una stima in un ordine di lavoro proposto in Connettere Microsoft Dynamics 365 Customer Voice alla soluzione di riferimento, che un planner approva.
• Ottimizzazione del ciclo umano - un agente propone una modifica del punto di set o una regolazione della pianificazione; la modifica viene applicata solo dopo che un essere umano lo approva e viene azionato tramite un percorso di comando autenticato separato( ad esempio un comando OPC UA tramite un servizio dedicato con controllo dell'approvazione).
• Asset autodocumentati: un agente usa i modelli di informazioni OPC UA standardizzati importati da Import OPC UA Information Models from the UA Cloud Library in Azure services per descrivere gli asset non familiari in linguaggio normale.

Sicurezza e corrimano

L'attuazione in uno stabilimento comporta un rischio fisico reale, quindi la soluzione di riferimento mantiene una netta separazione tra lettura e attuazione:

• Sola lettura per impostazione predefinita. Il server Plant Copilot MCP espone solo gli strumenti di esplorazione ed esecuzione di query. Non ha alcun strumento che modifica un set-point, riconosce un allarme o altrimenti attua l'impianto.
• Operazioni di scrittura soggette ad approvazione. Qualsiasi azione che cambia l'impianto deve passare attraverso un percorso separato, autenticato, approvato dall'uomo. L'agente può proporre un'azione, ma una persona lo autorizza.
• Messa a terra. Gli strumenti restituiscono dati con valori espliciti, qualità e timestamp e le descrizioni degli strumenti indicano all'agente di rispondere solo a tali dati anziché inventare ID asset, valori o ore.
• Accesso limitato. L'API I3X è protetta con l'autenticazione.
• Controllabilità. Ogni chiamata di strumento e ogni azione proposta o approvata deve essere registrata nel siem. Ciò supporta direttamente le mitigazioni del ripudio nella revisione della sicurezza della soluzione di riferimento.

Partire da un copilot basato su dati affidabili e di sola lettura consente di dimostrarne rapidamente il valore in modo sicuro, per poi aggiungere azioni soggette ad approvazione, uno scenario alla volta, man mano che si consolida la fiducia.