Benvenuti a tutti al podcast MC65FM. Oggi andremo oltre una delle conversazioni più comuni riguardo al prompt engineering di Microsoft 365 Copilot perché quando le organizzazioni iniziano a usare Copilot seriamente la domanda passa rapidamente da come scriviamo prompt migliore a come colleghiamo Copilot alle applicazioni, ai dati, alle app, ai processi aziendali e alla conoscenza che guidano la nostra azienda. Ed è qui che l'estensibilità di Copilot diventa interessante, stimolante. Il mio ospite di oggi è Evas Harvest, Microsoft MVP, consulente di business application AI World Group in Svizzera. Evas lavora tra Microsoft 365, Azure Dynamics 365 e la Power Platform con un focus particolare sull'estensione di Microsoft 365 Copilot tramite agenti e sviluppo personalizzato. Esploreremo l'estensibilità di Microsoft 365 Copilot, Copilot Studio, Microsoft Azure Foundry, non so, cambia nel nome, Microsoft Graph, sviluppo personalizzato, MCPS e così via.

Quindi sì, Evas, benvenuto al podcast MC65. Sì, ciao a tutti, grazie per avermi invitato. È davvero una buona opportunità per me essere qui, quindi grazie per mi ospitare. Sì, io ti ringrazio. Prima di diventare tecnici puoi raccontarci un po' del tuo percorso. Come sei entrato nell'ecosistema Microsoft?

Certamente, perché ho iniziato la mia carriera non nel mondo Microsoft, a dire il vero. Quindi ho iniziato la mia carriera nel mondo Apple. Ero un ingegnere del software sulla piattaforma Mac e dopo mi sono spostato su iOS, questo genere di cose. E, oh, è stato molto tempo fa, forse tipo, non so, 15 o 20 anni fa, sono passato al mondo Microsoft, a dire il vero. Ho iniziato la mia carriera su SharePoint, su SharePoint. E dopo sono passato al cloud, azzurro, M365.

Ero su SharePoint on-premise, ho iniziato così. E dopo sono passato a tutti i servizi cloud e alla fine la Power Platform è, più recentemente, a tutto ciò che riguarda l'IA. A dire il vero, perché è ormai una parte importante di M365, perché c'è una transizione verso gli agenti ora. E, in sostanza, questo è, in poche parole, il mio percorso. Ma ho iniziato la mia carriera nel mondo dell'ingegneria del software, che oggi è forse un termine che molti stanno dimenticando, perché abbiamo, sai, tutte queste cose legate all'IA ora. E, uh, fondamentalmente questo tipo di attività o lavori si sono spostati su l'IA. Quindi è molto diverso rispetto a 20 anni fa. Sì, lavori, dici di lavori con SharePoint e vedo anche che lavori con Graph, Speak, Dynamic, Power Platform. In che modo il tuo background ti ha preparato per l'attuale generazione di sviluppo IA?

Uh, fondamentalmente ho un profilo davvero trasversale, perché, uh, uh, nella mia carriera ho lavorato con moltissimi prodotti, potrebbero essere prodotti Microsoft e non Microsoft, quindi, in pratica, ho un ampio raggio di competenze su molte tecnologie e strumenti diversi. Quindi, uh, tutti i miei lavori mi danno una buona base, perché ora con l'IA è un argomento, è un argomento vasto, perché hai diversi tipi di approcci, diversi tipi di tecnologie per fare IA oggi. Potrebbe essere agentico, potrebbe essere più orientato al workflow, questo genere di cose. Quindi, fondamentalmente, tutti i miei lavori precedenti mi danno molte competenze per essere pronto per questa transizione verso l'IA ora a dire il vero. Quindi, sono passato dal low code al non a strumenti pro code. Quindi, sì, tutte queste, uh, sì, tutte queste, uh, opportunità e, uh, attività nei miei lavori mi danno, uh, delle buone, buone competenze per trarre vantaggio nel mondo dell'IA, a dire il vero.

E ora sei un AI test lead. Cosa fa un AI test lead?

Un'ottima domanda, perché molte persone me lo chiedono. Quindi, il mio lavoro è semplicemente far corrispondere, uh, le specifiche funzionali allo stack, uh, allo stack tecnico. Quindi, prendo il comando quando, uh, l'analisi aziendale è stata fatta. Uh, abbiamo definito i casi d'uso nell'IA, uh, per le cose legate all'IA. Uh, abbiamo definito scenari, casi d'uso, abbiamo definito, abbiamo fatto l'analisi aziendale completa e il mio lavoro è, ok, prendo queste esigenze e le abbino allo stack tecnico dietro le quinte. E poi, guido tutta l'implementazione degli strumenti e della, e della soluzione, uh, quando siamo pronti per iniziare lo sviluppo. Sì, interessante, um, in realtà molte aziende acquistano formazioni per i propri dipendenti, specialmente, uh, sì, um per il prompt engineering. Perché diresti che non è abbastanza?

Tendi solo il prompt engineering al giorno d'oggi?

Perché, perché, perché, perché loro, perché, sai, perché per le aziende, uh, non è abbastanza insegnare alle persone solo il prompt engineering. Ah, sì, ok, capisco, capisco. Ok, sì, sì, uh, praticamente, ad essere onesti, al giorno d'oggi hai, come ho detto prima, hai un sacco di strumenti e tecnologie diverse. Quindi, è praticamente, a un certo punto, l'IA può, può capire cosa fare e magari, uh, guidarti un po'. Ma per me, uh, uh, il ruolo, ad esempio, di architetto o progettista software, uh, deve avere un umano dietro le quinte perché devi capire il cliente.

Fondamentalmente, l'IA a volte non riesce a comprendere il contesto del cliente. Eh, uh, vedi lì, il quadro completo, ma dietro le quinte, uh, concentrarsi solo sul prompt engineering. Potrebbe essere utile a un certo punto, ma devi avere di più perché hai bisogno di, hai bisogno di avere dietro le quinte, uh, delle persone che siano, uh, architetti, ingegneri del software dietro le quinte e praticamente molte persone che abbiano competenze in tecnologie, uh, tecnologie dell'informazione come SharePoint, come OneDrive, come, non so, o Salesforce, questo genere di cose. Hai bisogno di avere specialist in, uh, quelle tecnologie perché l'IA può capire molte cose. Può, uh, uh, può guidarti, può generare ottimi documenti tecnici o funzionali, ma, uh, devi avere umani dietro le quinte che si occupino di, ok, va bene. Sta, uh, rispondendo all'esigenza del cliente, questo genere di cose, sai, per convalidare tutto e concentrarsi solo sul prompt engineering.

Per me ora è, sì, potrebbe essere, potrebbe essere un'opzione se non hai, uh, il tempo di, di, di formarti o di investire, uh, nel, uh, nell'acquisire alcune, alcune competenze. Ma per me tu, uh, tu devi avere, uh, buone competenze nelle tecnologie di base su cui vuoi costruire le tue soluzioni, ad essere onesti.

E tu sei un esperto in estensibilità di Copilot, dove, uh, si ferma il Copilot standard di Microsoft 365 e dove inizia l'estensibilità di Copilot? Ah sì, è una buona domanda perché, uh, ad essere onesti due anni fa, quando, quando Copilot, uh, è stato rilasciato e, uh, forse la prima versione, uh, praticamente la chat era ad essere onesti, davvero, davvero minimalista. Fondamentalmente, uh, ok, era come una chat GPT, uh, ma Microsoft ha fatto evolvere? Microsoft 365, Copilot di molto, in pratica ora hai, punto copri, hai diversi tipi di funzionalità, quindi ora l'estensibilità è meno di prima, perché in passato, sai, sviluppavo dei plugin, questo genere di cose, ma al giorno d'oggi, a essere onesti, in questo momento l'estensibilità si ha quando vuoi costruire qualcosa e vuoi personalizzare fondamentalmente l'orchestratore o vuoi personalizzare un po' di più, ad esempio l'interfaccia utente, se vuoi integrare il tuo agente non solo nella chat di Microsoft 365, ma, per esempio, nel tuo sito web, questo tipo di, quindi l'estensibilità inizia quando vuoi fondamentalmente personalizzare di più dietro le quinte, vuoi personalizzare un po' di più.

Potrebbe essere l'orchestratore, se vuoi personalizzare l'orchestratore, se vuoi personalizzare la tua interfaccia, se vuoi personalizzare diversi aspetti dove fondamentalmente Copilot Chat non può fare, non può rispondere. Penso che molte persone parlino di agenti. Perché pensiamo così tanto ora agli agenti Copilot? Perché non costruiamo, non so, un unico grande Copilot per tutto. Sì, è davvero interessante perché, uh, ora, a essere onesti, Microsoft, come ho detto prima, si è evoluta molto e forse, se fossimo a sei mesi fa, uh, ok, un agente era un argomento. Mmh. Ora, Microsoft ha introdotto Copilot Cowork e, a essere onesti, oggigiorno Copilot Cowork può sostituire molti agenti. E mentre pensiamo all'agente, è solo per separare le cose, perché ora siamo più in un modello multiagente dove ogni agente ha il suo ambito e le sue responsabilità. E non facciamo un grande Copilot, fondamentalmente, è semplice, per via delle prestazioni, primo, perché, uh, quando hai un set di istruzioni e strumenti, uh, in termini di prestazioni, diventerebbe un disastro.

E, uh, l'architettura ora è più multiagente, potrebbe essere in Copilot Studio, potrebbe essere un agente sviluppato su misura in termini di codice o sviluppo personalizzato. Ma, oggigiorno, è meglio avere un approccio multiagente, dove ogni agente ha il suo ambito e le sue responsabilità, anche solo in termini di prestazioni, e avere una chiara architettura degli agenti.

Schopenberg.

E quando guardiamo questa, ok, penso che l'architettura di base di un agente, IA, sia, direi, alcune parole chiave. Noi parole chiave, ma dobbiamo pensare al ragionamento, agli strumenti, alla conoscenza e alle istruzioni. Come si inserisce tutto questo nell'architettura di un agente IA?

La prima cosa a cui pensare, una delle prime domande a cui bisogna rispondere, è qual è l'obiettivo? Il primo obiettivo di questo agente? Fondamentalmente, dopo l'architettura della gente, dipende molto se ci si trova in un approccio low code o in un approccio di sviluppo personalizzato, perché l'approccio è totalmente diverso. In un approccio personalizzato gestisci tutto. Quindi gestisci la sicurezza, gestisci l'hosting, gestisci molte cose diverse. Nell'approccio low code è davvero diverso perché pensi, ok, dai le istruzioni, selezioni alcuni strumenti. Quindi, sostanzialmente, l'architettura in un approccio low code non è così semplice come ho detto ora, ma potrebbe essere molto veloce. Perché puoi definire, hai le istruzioni, puoi selezionare i tuoi strumenti, puoi selezionare un diverso agente se vuoi connetterlo. Ma è molto semplice. Quando hai a che fare con lo sviluppo personalizzato o quando sviluppi il tuo agente, potrebbe essere, per esempio, semantic kernel, legend framework, queste cose qui.

L'architettura potrebbe essere molto più complessa perché devi gestire concetti molto avanzati come, appunto, la sicurezza.

Termini di autenticazione, se hai, per esempio, strumenti multipli e vuoi integrare alcuni endpoint, se vuoi connetterti a strumenti interni protetti da reverse proxy, queste cose qui. Quindi, fondamentalmente, devi riflettere di più in termini di architettura quando tratti con agenti personalizzati. Ad esempio, in Copilot Studio, in termini di architettura, è molto veloce definire l'architettura in un approccio di sviluppo personalizzato. Devi gestire concetti avanzati e, per molte persone, potrebbe essere difficile perché si tratta di aspetti davvero fondamentali. Nel mio lavoro, a essere onesto, ho a che fare con molte esigenze diverse. Può trattarsi di sviluppo personalizzato, di Copilot Studio o di un semplice agente in Agent Builder per esigenze basilari. Quindi, in sostanza, definire un'architettura dipende dall'approccio che si vuole adottare. In pratica esiste un'architettura generale, ma poi tutto dipende dall'approccio scelto, low code o full code, capisci?

Ma potresti descrivere l'anatomia di un tipico agente AI aziendale? Ah sì, certamente. In breve, per dirla nel modo più semplice possibile, quando sorge un'esigenza, ad esempio, un agente di supporto IT, si parte da una base. Tuttavia, oggi, come dicevo, esiste l'approccio multiagente e io di solito imposto un primo agente come front-end. Quindi, questo è l'agente front-end, che è in strada tutte le richieste verso diversi altri agenti. Per esempio, se l'utente pone una domanda su Salesforce, lui, in strada, la richiesta all'agente di supporto IT dedicato a Salesforce. Quindi, per alcuni clienti abbiamo creato questo tipo di architettura, perché ogni agente si occupa del proprio ambito specifico. In specifico, può trattarsi di prodotti come Salesforce o di M365 e cose simili. E dietro le quinte, ogni agente ha un set di istruzioni, ha una serie di strumenti.

Oggi è meglio usare i server MCP, perché sono un connettore universale per integrare molteplici servizi con l'IA. Quindi, ho un insieme di server MCP e anche alcune fonti di conoscenza interne, può essere Gira, oppure la knowledge base di ServiceNow, cose di questo genere. Hai quindi un set di istruzioni per ogni agente. Queste istruzioni definiscono l'ambito, il ruolo di ogni agente. E poi hai i server MCP e magari fonti di conoscenza, come file PDF. Quindi può trattarsi di diverse tipologie di fonti dati.

E dopo, scusate, quando un utente fa una richiesta, ad esempio l'agente principale, dopo stabilirà. Stabilirà, ok, devo delegare questo compito al rispettivo agente.

Uh, diamo un'occhiata alle possibilità.

Ah, Copilot Studio, dove si colloca nell'architettura complessiva?

Copilot Studio, a dire il vero, è uno strumento low-code di Microsoft. Quindi, prima di tutto, in termini di architettura, Copilot Studio è pensato per i maker, in sostanza per le persone che non sono. Siamo principalmente sviluppatori.

E in termini di architettura, fondamentalmente, se prendiamo l'esempio fatto prima, quello del supporto IT, ad esempio Copilot Studio si adatta bene, perché dal punto di vista architetturale fa il suo lavoro. Puoi definire un server, puoi integrare facilmente delle fonti di conoscenza esterne o interne, se vuoi. Uh, dopo, come ho detto prima, se ad esempio hai un caso d'uso in cui vuoi personalizzare un po' l'orchestratore, dato che dietro le quinte di Copilot Studio non puoi personalizzare l'orchestratore, attivi l'orchestratore AI, e basta. E non puoi ad esempio personalizzare la priorità, uh, ad esempio del compito che vuoi svolgere, perché dietro le quinte Copilot Studio definirà, ok, il tuo piano e dopo lo eseguirà. Ma se vuoi avere un po' più di personalizzazione, in questo caso, devi usare uno sviluppo custom con, ad esempio, Semantic Kernel Land Chain, un framework molto recente, perché Microsoft ha rilasciato questo framework, e in questo ambito puoi personalizzare facilmente l'orchestrazione, puoi definire dei flussi di lavoro, puoi personalizzare ciò che vuoi.

Questo è Copilot Studio come architettura davvero pensata per builder e maker, perché è molto semplice far funzionare un agente.

L'unico problema con Copilot Studio, e di questo bisogna tener conto, perché quando definisci, quando scegli il tuo percorso, e magari definisci la tua architettura, devi fare attenzione alle licenze, perché ormai sono una parte importante di ogni soluzione. E oggigiorno Copilot Studio si è evoluto un po' verso un modello pay-as-you-go, e bisogna fare attenzione alla stima dei costi, perché in base a ciò che si vuole ottenere, a volte è meglio fare uno sviluppo personalizzato, così puoi ospitarlo dove vuoi, gestire tutti i costi e fare una stima più facilmente rispetto ad ora. Perché con l'approccio a crediti di Copilot, a volte è difficile prevedere quanto costerà per uno o due mesi e cose di questo genere.

E quali sono i limiti di Copilot Studio? Studio quando devo scegliere, penso a Microsoft Foundry, Azure Foundry, non so quale sia il nome esatto, e quando devo dire, ok, devo fare uno sviluppo completamente personalizzato. La prima domanda a cui rispondere è, ok, ho bisogno di personalizzare l'orchestrazione. Questa è la mia prima domanda, perché ti dirà, ok, se non vuoi personalizzare l'orchestrazione, se non vuoi approfondire come viene fatta l'orchestrazione o come viene generato il piano, puoi usare un approccio low-code con Copilot Studio, ad esempio un builder. Inoltre, a volte, quando hai casi d'uso semplici, puoi usare questo tipo di strumenti.

Ma se vuoi personalizzare l'orchestrazione, devi passare a uno sviluppo specifico. In questo caso, devi usare Foundry per il modello o la tua piattaforma, perché il vantaggio dello sviluppo personalizzato è che puoi integrare modelli non ospitati in Microsoft Foundry. Se vuoi, puoi usare i modelli di Foundry, ma se hai una piattaforma AWS o Google, scusa, e hai ad esempio Gemini o hai distribuito modelli esternamente, hai la possibilità di integrare quei modelli direttamente nel tuo agente quando usi un approccio personalizzato. Questo è un altro vantaggio. Poi puoi personalizzare l'orchestrazione, come viene generato il piano, tutte le cose che confluiranno nella gente. Foundry? Sì. Il problema di Foundry oggi è che all'inizio era solo una piattaforma di hosting per modelli. Se guardi a qualche anno fa, era così solo un semplice catalogo. I modelli da distribuire. Oggi Microsoft ha fatto evolvere questo prodotto per permettere, ad esempio, di creare agenti con un'interfaccia utente simile a Copilot Studio, praticamente senza scrivere codice, puoi gestire la governance, puoi gestire tantissime cose.

È diventata una piattaforma veramente agentica, come Copilot Studio per i low-code e cose del genere. E oggi Foundry è davvero difficile da collocare nell'ecosistema, perché si sta evolvendo velocemente, fondamentalmente. Microsoft ha introdotto alcune funzionalità che non sono, non saprei, diverse, ma ci sono similitudini con Copilot Studio, in termini di integrazione MCP e cose simili, ma il limite principale di Copilot Studio riguarda i modelli. Quindi hai la possibilità di integrare codice o visualizzare questo genere di cose. Ma se vuoi integrare, ad esempio, il tuo modello, perché hai una versione specifica, non puoi farlo, devi praticamente usare uno sviluppo personalizzato per integrare la tua piattaforma LLM. Se ne hai una, o clienti che hanno la loro piattaforma AWS, in questo caso, puoi integrare questo modello con un pricing gestito esternamente.

E penso che quando costruiamo un agente, un argomento importante, sia anche tutto il resto.

Schopenhauer. La maggior parte delle persone parla di MCP, il Model Context Protocol. Perché? È diventato uno degli argomenti principali nello sviluppo agentico e per chi non ci ha ancora lavorato, cos'è il Model Context Protocol? Sì, è un parolone. Molte persone ne parlano perché risolve un problema importante. Si tratta di come unificare l'integrazione di strumenti, competenze o magari strumenti esterni. Nell'IA ha risolto questo problema perché in passato, senza MCP, era un caos, dato che molti servizi comunicavano in modi diversi. Hai protocolli tecnologici differenti, approcci architetturali diversi. E sostanzialmente MCP unifica il modo in cui integri i servizi al tuo agente IE o, per essere più generici, alla tua soluzione IE. MCP è davvero il modo per integrare strumenti esterni o interni o entrambi. Ma MCP ora è una parte importante dell'architettura IEA perché garantisce questa unità in termini tecnologici e oggi è un punto fondamentale perché in passato si parlava di integrazione API, ora si parla di MCP.

Questa non è l'evoluzione, ma in passato integravi il tuo agente con le API. Dovevi gestire, ok? Come autenticarti o gestire la cosa o chiamare lo strumento. Ora l'IA può dire, ok, questo strumento a disposizione, posso selezionare ciò che mi serve per raggiungere l'obiettivo.

E cosa è cambiato davvero dall'MCP alla connessione API? In pratica, in passato, in termini di integrazione, le API non sono intelligenti, se posso dirlo. Le API sono solo, ok? Tu chiami, tu chiami, chiami uno strumento e questo ti dà dei dati. La differenza con MCP è, MCP è più intelligente in termini di architettura perché dietro le quinte non hai solo strumenti che ti danno dati o informazioni, ma hai anche competenze e istruzioni e diversi tipi di cose che rendono MCP davvero intelligente e in pratica MCP può dire all'IA, ok, vuoi ottenere questo? Posso darti gli strumenti esatti che corrispondono alla tua richiesta e non puoi chiamare solo uno strumento, ma devi chiamare questi strumenti per ottenere ciò che vuoi. Questo è il ruolo di MCP. Dici all'IA, ok, ho questi strumenti e poi puoi chiamare questo o quello o più strumenti per raggiungere i tuoi obiettivi. Ti dà l'IA il contesto, il vero contesto di tutto, mentre l'API è solo, ok, hai strumenti, hai descrizioni e questo è praticamente tutto.

Quindi è il model context protocol, penso sia simile ai metadati o come funziona? No, MCP dietro le quinte è solo, è un protocollo. In pratica è un protocollo tecnologico e dietro le quinte hai, sì, hai metadati, hai descrizioni, hai competenze IA che descrivono di più, è davvero focalizzato sugli IA e in pratica hai competenze, hai istruzioni, IA può capire meglio, ok, questi strumenti fanno questo, questo strumento fa quello, ok, posso chiamare queste competenze, posso richiedere queste informazioni al server MCP per completare il mio compito.

Ma hai, sì, hai una parte di metadati, perché? Devi definire, ok, il nome dello strumento, cosa sta facendo dietro le quinte.

Senti, possiamo dire che il filo è il futuro MCP, quindi dobbiamo iniziare a pensare, non so, le aziende hanno 100 API rest all'interno dell'organizzazione, dovrebbero iniziare a costruire server MCP attorno ad esse.

Sì, sì, praticamente, il server MCP lavora con le IAP dietro le quinte, non è un sostituto praticamente. Se tu, se riassumo questo, perché il server MCP è solo ok. fornisce il contesto e dietro le quinte l'MCP può chiamare le IAPI dietro le quinte, ma il server MCP è un frontend, lo strumento frontale che devi chiamare, perché dietro le quinte invierai la tua richiesta basata su ok dietro le quinte. Potrebbe essere un API, un database, potrebbero essere molteplici strumenti, ma devi, se vuoi, avere il tuo server MCP. Per esempio, se internamente nella tua azienda hai UAPI e hai diversi tipi di servizi, potrebbe essere, non so, servizio finanziario, potrebbe essere servizio risorse umane, se vuoi costruire il tuo MCP devi gestire dietro le quinte U con tutte queste API e il server MCP dovrà esporre tutte queste API. Quali sono i servizi, quali sono gli strumenti disponibili, di quali sono le competenze e questo genere di cose.

Dopo devi gestire l'autenticazione dietro le quinte, perché le API non funzionano allo stesso modo, perché puoi avere un'autenticazione tramite chiave, tramite questo genere di cose. Quindi devi gestire questo. Ma l'MCP esporrà gli strumenti disponibili e dietro le quinte tutti questi strumenti possono interrogare molteplici API, un API potrebbe essere, che hai diversi tipi di architettura dietro le quinte.

E come fa l'MCP?

Scegliere lo strumento giusto quando ho, non so, 100-500 agenti. E hai U, si baserà su U, prime cose. Fondamentalmente quando hai una richiesta in un agente U, scoprirai tutti gli strumenti disponibili. Il server MCP U verificherà, ok, ho tutti questi strumenti disponibili. E in sostanza l'orchestratore dell'agente capirà, ok, ho questo, ho un LM a disposizione. Dopodiché creerai il piano. Se riassumo un po', creerai un piano con alcune azioni da compiere e dopo, in questa azione, nell'azione che vuoi eseguire, puoi richiamare uno, due, tre o più strumenti per portare a termine il compito richiesto dall'utente. Quindi in sostanza l'orchestratore dell'agente comprenderà gli strumenti MCP e selezionerà i migliori per la richiesta. Vedi? Ed è proprio questo il ruolo dell'orchestratore selezionare gli strumenti e cose del genere con l'aiuto dell'LLM, ovviamente, perché l'LLM è parte del cervello e l'orchestratore comunicherà con l'LLM e anche con gli strumenti per fare la scelta migliore e creare il piano migliore per completare il compito.

Sì, penso che per un po' molte aziende abbiano iniziato con PowerShell e ora usano le Microsoft Graph API. Graph e MCP sono collegati? O come funziona?

Sì, penso che è in realtà a dire il vero le Graph API. No, non esiste un MCP per Graph e vogliamo chiamarlo così. Sai, nel mondo Microsoft 305 Microsoft ha introdotto molti server MCP e questi server MCP si basano dietro le quinte su Microsoft Graph. Quindi, per esempio, se vuoi usare, non so, il server MCP di Teams, dietro le quinte vengono richiamate le Graph API quando usi il server MCP. Quindi le Graph API nel mondo Microsoft 365 sono fondamentali perché dietro le quinte l'MCP comunica con Graph per far sì che la richiesta funzioni correttamente. Ma sì, al giorno d'oggi Graph è centrale anche in Copilot in generale perché l'indice semantico di Copilot si basa sui dati grezzi ma in realtà, sai, consumi Graph attraverso i server MCP. Al giorno d'oggi funziona così.

Microsoft 305 contiene un valore incredibile con testi organizzativi, documenti, riunioni, email, persone, team, conversazioni e, direi, contenuti condivisi.

Come esponiamo quel contesto senza, sì, a creare un incubo per la sicurezza?

In termini di governance e cose del genere?

Sì, è sempre un problema perché molte persone costruiscono agenti senza una corretta governance dietro le quinte. Quindi voglio costruire un agente. Ok, procediamo. Costruiamo, distribuiamo. E poi, ah, ma ok, questa gente gestirà un sacco di dati. Come lo gestiamo? La prima domanda è, ok, come implemento la governance dell'agente? Prima potrebbe essere, come hai detto tu, un disastro perché molte persone vogliono costruire agente, agente, agente o voglio costruire qualcosa, voglio costruire una soluzione ma dietro le quinte se sei in un contesto Microsoft 365 per esempio una delle prime cose da fare è capire i propri dati perché senza capire i tuoi dati sei perduto. Devi capire i tuoi dati perché è importante comprendere se sto trattando dati riservati o meno sto trattando dati altamente riservati ehi, devi capire i tuoi dati poi se sei in un ambiente Microsoft devi implementare per esempio funzionalità di LP, etichette di sensibilità e cose del genere perché senza queste potrebbe essere un problema e poi devi anche ripulire un po' i tuoi dati perché un'IA con dati scadenti non farà funzionare l'agente come vorresti dato che se hai del disordine in SharePoint nei team o nei canali sarà difficile che l'approccio agentico funzioni correttamente ma si devi capire i tuoi dati devi implementare alcune basi di sicurezza come l'autenticazione come ho detto le funzionalità di Purview e Purview è diventata una soluzione centrale per mettere in atto tutta questa sicurezza e governance e dopo quando hai ripulito i tuoi dati quando hai messo in atto alcune basi di sicurezza devi anche comprendere le licenze perché prima di iniziare a costruire un agente devi capire ok quali sono gli sviluppatori sono formati per questo abbiamo le licenze corrette per iniziare a lavorare ci servono abbonamenti di questo tipo dopo anche uno dei grandi problemi sono gli strumenti come integro correttamente tutti gli strumenti nel mio sviluppo nel mio agente devo limitare qualcosa essere onesti è una grande questione hai diverse attività da prendere in considerazione ma per me la cosa più importante è comprendere i tuoi dati e se un'azienda non comprende i propri dati sarà un problema fin dall'inizio onestamente e quando come l'abbiamo l'argomento sicurezza lì penso ci siano due due sì due tipi di persone alcuni dicono ok servono permessi utente e altri dicono che servono permessi applicativi come dovrebbe operare generalmente un agente in generale la mia migliore raccomandazione è che fondamentalmente quando devi gestire una soluzione agentica fallo sempre con permessi utente permessi delegati perché in termini di sicurezza a essere onesti è meglio dato che l'utente gestirà solo i dati e gli strumenti a cui accesso questo è il principio principale poi se ti servono permessi applicativi per uno specifico non so una specifica ip o un contesto specifico puoi farlo ma non usare direttamente i permessi applicativi fallo nel contesto di un rapper quindi crei non so potrebbe essere un server mcp per esempio e integri questo mcp con permessi applicativi dietro le quinte quindi l'mcp chiamerà per esempio non so la tua api dietro le quinte con permessi applicativi e poi ti darà le informazioni che ti servono ma l'utente non ha a che fare direttamente con i permessi applicativi chiamiamo il server mcp per esempio con permessi utente e il server mcp chiamerà dietro le quinte le applicazioni o i servizi con permessi applicativi dedicati vedi la differenza?

ok uh interessante penso che quando pensiamo all'architettura dobbiamo anche guardare un po' più a fondo penso che ci siano tre grandi argomenti nell'architettura abbiamo la retrieval augmented generation abbiamo l'argomento conoscenza e abbiamo quella che definirei la ricerca aziendale di base da dove iniziamo con la rag dove si inserisce la rag nell'architettura alla rag a dire il vero la rag è in realtà la più onestamente in termini di performance perché l'IA deve comprendere diversi tipi di dati e fondamentalmente la rag serve a rispondere a una domanda perché in passato quando non avevi la rag dovevi sostanzialmente gestire approcci diversi non vecchia scuola ma era complicato ma la rag è centrale perché comprende diversi tipi di dati e ti permette di recuperare le informazioni di cui l'IA ha bisogno che si tratti di documenti o di molteplici tipi di dati quindi si la rag è centrale oggi nell'architettura dell'IA ma è vero che per molti utenti quando si parla di rag dietro le quinte non sanno cosa sia perché microsoft o molte aziende di software non ne parlano dietro le quinte hai la rag ma ad esempio in copilot studio l'utente non capisce che dietro c'è la rag vedi e oggi quando vuoi approfondire ok hai questo concetto ma per molti utenti la rag è totalmente sconosciuta perché usano solo lo strumento e dietro le quinte ci sono questi concetti e poi abbiamo il prossimo argomento la conoscenza come otteniamo tutto questo da dove prendono la loro conoscenza i sistemi di IA è un collettore di bacheche o come funziona in realtà bisogna essere onesti la conoscenza potrebbe essere ospitata in molti sistemi diversi potrebbe essere un file di testo semplice un file markdown una knowledge base potrebbe essere qualsiasi cosa ma in realtà se hai un server mcp puoi accedere a quelle conoscenze oppure se hai per esempio non saprai un connettore per sharepoint hai connettori per molti servizi al giorno d'oggi quindi accedere alla conoscenza è più facile di prima dobbiamo essere onesti perché in passato dovevi costruire i tuoi plugin e gestire tutto quanto oggi hai a disposizione connettori diretti per qualsiasi sistema puoi integrare le tue conoscenze senza dover gestire grandi team di sviluppo io penso spesso penso che abbiamo non lo so mi confronto con i miei dico ai miei non saprei collaboratori e come fa l'IA a capire quali documenti non sono pronti o sono obsoleti o non so duplicati come come può come fa a capire questo un sistema di IA cosa dovremmo usare cosa no praticamente stai usando la RAG perché dietro le quinte devi capire ok quali sono i tuoi dati ma a dire il vero se riassumo un po' tu parti dal prompt ok l'utente vuole ok vuoi per esempio cercare attraverso non so una knowledge base per esempio OneDrive dietro le quinte quando l'orchestratore con l'aiuto dell'LM comprende il prompt e l'intento dell'utente dietro le quinte hai l'indice sostanzialmente perché per esempio in Copilot hai l'indice semantico e questo indice semantico ti fornisce praticamente ok ho tutta questa conoscenza e poi con una query sull'indice semantico l'I può interrogare direttamente l'indice semantico per eseguire la RAG per esempio e poi direttamente ok selezionare i documenti giusti in base alle esigenze ma in Copilot hai questo indice semantico e l'IA può interrogare direttamente questo indice U con linguaggio naturale dietro le quinte quindi chiederò ok voglio capire U non so come U come configurare la VPN della mia azienda e dietro le quinte eseguirai la RAG sull'indice semantico e praticamente recupererai il documento che contiene per esempio tutta la configurazione della VPN aziendale per esempio nella chat di Microsoft R665 Copilot U dietro le quinte c'è Graph API perché come ho detto prima hai l'indice semantico costruito su Graph API è una funzionalità di Graph dietro le quinte ma U quando hai uno sviluppo personalizzato hai per esempio Azure AI Search dietro le quinte era era un servizio Azure con un nome diverso ma ora puoi avere il tuo sistema RAG se vuoi e in sostanza quando hai un agente personalizzato puoi chiederlo direttamente a quest'istanza di Foundry AQ voglio usare voglio ottenere la configurazione della mia VPN aziendale e l'IA può recuperare ciò di cui hai bisogno in termini di documenti potrebbe essere PDF Word Excel quel genere di cose e è così che funziona la ricerca giusto?

Dietro le quinte intendi? Ah dietro le quinte hai la ricerca praticamente oggi dietro le quinte di Copilot Chat hai tre funzionalità la ricerca standard che è fondamentalmente una ricerca in cui inserisci semplicemente delle parole chiave e cerchi tra i tuoi documenti e cose del genere questa è una ricerca semplice tutti conosciamo la ricerca per parole chiave come Google poi hai due diverse funzionalità hai innanzitutto il RAG dietro le quinte hai la funzionalità di RAG nel graph e hai anche la ricerca nell'indice semantico di Copilot che è un po' diversa perché il RAG è davvero più avanzato rispetto all'indice semantico di Copilot ma hai tutte queste tre capacità dietro le quinte così che non sei tu ma l'IA può richiamare queste tre diverse funzioni per recuperare i dati su OneDrive Teams e M3S 65 in generale inoltre l'indice semantico di Copilot include anche i connettori di Copilot quindi ad esempio se hai collegato Salesforce con il connettore Copilot puoi anche cercare tra tutti i tuoi dati in Salesforce in ServiceNow e in molti altri strumenti poiché grazie al connettore Copilot hai integrato tutti i dati nel graph e nell'indice semantico puoi interrogare direttamente i tuoi sistemi esterni e penso che quando costruiamo agenti abbiamo la parte di governance e una delle parti per quanto mi riguarda è la gestione del ciclo di vita dell'agente come appare effettivamente come è strutturato?

ad essere onesti nell'ecosistema Microsoft è piuttosto semplice se posso dirlo perché quando hai a che fare con il low code ad esempio con Copilot Studio hai a che fare con la Power Platform il concetto è lo stesso e non è cambiato nulla quindi hai la soluzione hai le pipeline dunque quando si ha a che fare con Copilot Studio onestamente è come prima perché se ha tutto ciò in cui si è investito in termini di governance di Power Platform ciclo di vita e ALM è esattamente la stessa cosa questa è una buona cosa perché molte persone mi chiedono oh Copilot Studio come si gestisce è diverso no è davvero semplice come per le applicazioni Power Apps o Power Automate per la gestione del ciclo di vita delle applicazioni quindi in questo caso si tratta di gestione del ciclo di vita della gente ma dietro le quinte il concetto è lo stesso di Power Platform e quando si ha a che fare con ad esempio lo sviluppo personalizzato in pratica è come quando si costruiscono applicazioni punto net cose del genere perché si gestisce tutto come codice quindi iFramework e aspetti di sicurezza questo tipo di cose quindi tutto onestamente in termini di gestione del ciclo di vita dell'applicazione degli agenti è davvero lo stesso concetto di prima e questo è un buon punto per me perché non devi investire molto in termini di processi di ciclo di vita questo tipo di cose ma l'unica cosa ci sono alcuni cambiamenti uno dei grandi cambiamenti è ok devi occuparti dell'LM questo tipo di cose della distribuzione questo genere di cose ma dietro le quinte sembra il vecchio approccio DevOps con Pipeline questo tipo di cose quindi a mio parere non è cambiato nulla perché gestiamo gli agenti che si tratti di sviluppo personalizzato di Copilot si usa lo stesso approccio di prima onestamente al giorno d'oggi questo significa quando un'azienda loro non usano prima l'IA ma hanno la configurazione perfetta per Purview per Defender e tutti gli strumenti successivi c'è qualche cambiamento da fare o questo significa prontezza per l'IA ah è una grande domanda perché la prontezza per l'IA per Microsoft è ok sono autorizzazioni condivise gestire questo tipo di cose ma ok per me la prontezza per l'IA non è solo un approccio tecnico perché ok tecnicamente sappiamo cosa fare ok dobbiamo gestire i permessi in molti servizi sai per me la prontezza per l'IA deve includere anche i dati capisci perché quando non comprendi i tuoi dati come dicevo prima non puoi gestire la parte tecnica perché quando non sai cosa è riservato o meno ad esempio è difficile implementare delle misure di sicurezza ma se se seguiamo Microsoft la preparazione all'IA va bene devi gestire i permessi vuoi applicare etichette di sensibilità devi conformarti al GDPR questo genere di cose ma c'è anche un aspetto di livello più alto un aspetto di livello più alto e per me la preparazione all'IA non è solo tecnica oggi onestamente devi considerare anche un aspetto funzionale o di livello superiore un sì davvero interessante penso che molte aziende abbiano iniziato con l'IA ma ora con gli agenti molte dicono ha cancellato tutte le mie email o sta facendo qualcosa di malvagio cosa ne pensi cosa diranno le aziende temono l'IA è una buona domanda perché vivo in Svizzera e fondamentalmente abbiamo molte banche private e onestamente abbiamo molti clienti molto sensibili e sostanzialmente la parte più critica è ok dove vengono elaborati i dati fondamentalmente e sì anche ok l'IA sta cercando tra le mie email questo generico quindi dietro le quinte loro chiedono sempre questo ma sai la parte più critica per loro è ok devo capire ok dove vengono elaborati i dati e e anche ok io sono il proprietario dell'IA quindi io do le istruzioni all'IA e l'IA dietro le quinte farà il lavoro e hanno paura ad esempio dell'aspetto autonomo perché oggi giorno ok puoi fare questo e dietro le quinte l'IA cercherà qualcosa interrogerà qualcosa e hanno paura di ok quando chiedo all'IA di fare qualcosa cosa viene eseguito dietro le quinte e sì ci sono molte domande di questo tipo come come faccio a prendere il controllo dell'intero processo dietro potrebbe essere un agente IA o un servizio IA sì ci sono alcune domande come questa ma è davvero una questione di adozione anche di formazione per mettere in atto un po' di formazione su ok come capire l'IA come capire dietro le quinte cosa viene eseguito esattamente U e anche la trasparenza è un punto importante U perché la trasparenza deve essere messa in atto in ogni soluzione IA perché la trasparenza per me è un grande argomento perché devi mettere in atto tutto U ogni cosa perché la tua soluzione IA deve essere trasparente devi capire cosa viene eseguito dietro le quinte U quali dati vengono interrogati U devi tracciare devi registrare tutto quindi quindi tutto deve essere trasparente quando hai una soluzione al giorno d'oggi perché devi capire esattamente U cosa viene eseguito dietro e U quali dati vengono elaborati e U qual è il ragionamento dietro le quinte come ha generato questo piano basato su quali fatti e questo tipo di cose fantastico vedo che stiamo finendo un po' il tempo è stato davvero fantastico ma in ogni podcast ho una sessione di domande rapide quindi io faccio una frase breve e tu dai una risposta breve quindi sei pronto?

Coppailo Studio codice personalizzati Coppailo Studio Microsoft Foundry o Coppailo Studio Coppailo Studio TypeScript o C-Shar GitHub o Azure DevOps GitHub o Reg o Fine Tuning va bene qual è l'API Microsoft 3.5 o più sottovalutata API Reg una tecnologia che ogni sviluppatore Microsoft dovrebbe imparare nel 2026 GitHub Coppailo quando Satya Nadella viene da te e dice ti diamo tutti i soldi e le risorse che vuoi per migliorare la nostra piattaforma IA o puoi sviluppare una funzionalità quale sarebbe tutta la parte di governance di cui abbiamo bisogno e chi dovrai invitare prossimamente al podcast quale domanda dovrai porre o buona domanda ho molti amici ma sì forse puoi chiedere la mia ho una correlatrice in molte conferenze puoi chiedere ad esempio a Chloe Moro l'era una consulente funzionale prima di passare al lato tecnico ora e ha una storia davvero bella riguardo a cose funzionali meno tecniche nel mondo dynamics quindi magari potresti invitarle a chiederle ok dimmi oggigiorno come gestire il lavoro tra l'aspetto funzionale e quello tecnico perché ci sono delle grandi sfide in questo ambito e la mia domanda conclusiva è cosa dovrebbero quando possono trarre un insegnamento da questa sessione cosa dovrebbero portare a casa da questa sessione intendo praticamente l'IA si sta evolvendo velocemente e se vuoi essere aggiornato oggigiorno devi seguire tutto perché oggigiorno l'IA è davvero presente in tutto lo stack Microsoft a dire il vero e oggigiorno una delle cose che devi capire è che l'UCCI l'evoluzione è rapida e devi essere aggiornato davvero in ogni momento perché tu tu perderai qualcosa a un certo punto se se non se non impari se non capisci l'evoluzione di questo tipo te quindi sì grazie per esserti unito a me penso che l'importante lezione da questa conversazione sia che la sensibilità di Microsoft 365 e Copilot non riguarda semplicemente la scrittura di prompt sempre più sofisticati penso che ci stiamo muovendo verso un'architettura in cui Copilot e gli agenti possono collegare la conoscenza organizzativa Microsoft Graph le applicazioni aziendali le API e così via sì penso che Copilot Studio Microsoft Foundry lo sviluppo personalizzato e tecnologie come MCP offrano agli sviluppatori sì un set di strumenti incredibile e potente e sì ma più sì capaci diventano gli agenti più diventano importanti anche i fondamentali identità autorizzazioni sicurezza governance test osservabilità gestione del ciclo di vita delle applicazioni e così via quindi sì penso che tu abbia dato davvero un'ottima panoramica di tutti tutti questi argomenti quindi grazie per esserti unito a me e per gli ascoltatori tutte le informazioni le trovate nelle note dell'episodio sulla pagina del podcast M365 FM e sì dove potete connettervi e vedere il lavoro di S e sì grazie per essere qui e sì grazie per essere qui grazie per avermi invitato è stato davvero un ottimo momento con te grazie per avermi invitato