Ecco perché ti serve un'infrastruttura solida per essere agent-ready nel 2025

Prologo

Con questa onnipresenza nascono molte idee e la voglia di agire o almeno sperimentare. In glueckkanja AG accompagniamo i nostri clienti lungo tutto questo percorso. Naturalmente sviluppiamo e costruiamo già agent, ma nell'80% dei nostri progetti il focus principale è la preparazione dei dati e del tenant per la creazione degli agent. Prima di implementare Copilot in modo produttivo nella tua organizzazione conviene dare uno sguardo critico all'infrastruttura. Quando si prendono decisioni in questo ambito ci sono diversi aspetti importanti da capire prima di distribuire agent AI su larga scala. Per questo, in questo blog post, ti guiderò attraverso i passi e le differenze essenziali. In un'epoca in cui gli assistenti AI come i Microsoft 365 Copilot Agents promettono di trasformare il mondo del lavoro, un principio vale sopra tutti: l'AI è buona solo quanto il sistema che le sta sotto.

Questa guida completa illustra come preparare i tuoi dati e la tua infrastruttura per i Copilot Agents, coprendo le pratiche chiave in SharePoint, Teams e Power Platform.

Perché la tua infrastruttura (dati) conta

Mentre utilizziamo agent AI è fondamentale capire che questi agent non possiedono di per sé alcuna conoscenza della nostra organizzazione, dei nostri dati o del nostro contesto operativo specifico. Di default un agent AI porta con sé solo il sapere integrato derivante dal training del Large Language Model (LLM). Per potenziare ed estendere efficacemente le capacità di questi agent AI è essenziale integrare in modo sistematico vari componenti. Questo potenziamento si ottiene tramite System Prompt, Knowledge Base, Connector, funzionalità di Web Search, accesso a Microsoft Graph, Semantic Search e strumenti aggiuntivi. Questi componenti permettono agli agent AI di fornire risposte e azioni più precise e contestualmente rilevanti, allineate strettamente alle esigenze e ai dati specifici dell'organizzazione. Dato che siamo appena all'inizio dell'era agentic, molti di noi partiranno con agent semplici che attingono informazioni da librerie SharePoint Online esistenti.

Per noi in IT questo significa che dobbiamo prenderci cura dei nostri dati in SharePoint Online più che mai.

SharePoint Online = Knowledge = Data e Data = Key

Il mio messaggio è chiaro: prima di aggiungere copilot AI alla tua organizzazione metti in ordine la tua casa dei dati. Gli stessi dati che alimentano i tuoi Copilot Agents alimentano anche Microsoft 365 Copilot stesso.

E non solo. Microsoft 365 Copilot valuta gli stessi dati. Se quei dati sono disordinati, condivisi troppo ampiamente o mal protetti, l'AI potrebbe far emergere informazioni errate o sensibili in modo inatteso. Ad esempio, immagina di chiedere a Copilot informazioni sulla struttura aziendale e ricevere dettagli di un piano di riorganizzazione riservato che non avresti dovuto vedere. Incidenti di questo tipo capitano quando i contenuti sono overshared (disponibili in modo troppo ampio) su piattaforme come SharePoint o Teams. Nota: Copilot rispetta tutti i permessi esistenti, quindi qualcosa del genere può accadere solo se i permessi sono configurati male. Al contrario, se i dati sono in silos o inaccessibili gli assistenti AI saranno meno utili.

Copilot mostra solo i dati organizzativi per cui l'utente ha almeno permessi di visualizzazione.

Fonte: https://learn.microsoft.com/en-gb/copilot/microsoft-365/microsoft-365-copilot-privacy?azure-portal=true

Key takeaway: l'AI aziendale ha successo solo con una solida foundation di dati. Un recente report Microsoft identifica oversharing dei dati, data leakage e uso non conforme come le sfide principali da affrontare prima di distribuire l'AI. Le organizzazioni che investono nella preparazione di SharePoint Online e delle altre sorgenti dati sbloccheranno i benefici di Copilot con fiducia, mentre chi non lo fa rischia brecce di sicurezza o output AI irrilevanti. Gli studi mostrano che circa un terzo dei decision maker non ha piena visibilità sui dati critici.

10 passi per migliorare subito la tua infrastruttura dati M365

Ora sappiamo che i tuoi agent avranno bisogno di dati. Quando noi di glueckkanja entriamo in questi progetti, questa è la nostra tipica lista in 10 punti che percorriamo dall'alto verso il basso insieme ai clienti.

Passo 1: verifica le impostazioni di condivisione principali

Verifica le impostazioni a livello di tenant che potrebbero portare a oversharing. Ad esempio, esamina le policy di link sharing di default (se ad esempio è consentito di default "Anyone with the link" o "People in your organization" per SharePoint/OneDrive), se gli utenti possono creare Teams pubblici di default e se il tuo ambiente Power Platform è aperto senza governance. Configurazioni di default sbagliate sono una causa comune di accesso ampio non intenzionale.

Passo 2: audit dei Teams pubblici

Rivedi tutti i Microsoft Teams contrassegnati come "Public". Un Team pubblico significa che chiunque nella tua organizzazione può scoprirne e accedere ai contenuti. Assicurati che qualsiasi Team impostato come pubblico contenga davvero solo contenuti non sensibili, adatti a un pubblico ampio. Altrimenti, passalo a privato o rivedi la membership. È facile che un Team venga creato come pubblico e poi dimenticato, esponendo file a tutti i dipendenti.

Passo 3: rivedi i Graph Connector

Controlla se nel tuo tenant sono configurati Microsoft Graph Connector che portano dati di terze parti (ad esempio da file system esterni, wiki, ecc.). Rimuovi o metti in sicurezza qualsiasi connector che indicizzi dati che non dovrebbero essere visibili a tutti. Perché? I contenuti indicizzati tramite Graph Connector diventano parte del tuo Microsoft Graph search index, e ciò significa che Copilot può potenzialmente usarli per rispondere ai prompt. Vuoi collegare solo sorgenti dati rilevanti e volute.

Passo 4: genera un SharePoint Online Baseline Report

SPO presenta diversi possibili rischi di dati indesiderati in Agents e Copilot. Devi guardare a diverse metriche chiave:

• Broken Permission Inheritance a livello di cartella
• Public SharePoint Sites
• Uso di "Everyone Except External Users" o di altri gruppi dinamici che contengono tutti gli utenti
• Anyone Sharing Links
• Everyone-in-my-org Sharing Links
• Persone indesiderate nei gruppi Site Admins / Owners / Members / Visitors

Passo 5: categorizza e assegna priorità ai rischi

Prendi le rilevazioni dei passi 1 e 4 e classificale per gravità. Quali site o file contengono i dati più business-critical o sensibili e hanno anche rischi di esposizione? Dai priorità a sistemare quelli. Stratificando il contesto business (ad esempio un site con dati finanziari rispetto a uno con template generici) puoi concentrarti prima sui problemi con maggiore impatto.

Passo 6: coinvolgi i site owner nelle access review

Per ogni SharePoint site (o Team) evidenziato come rischioso, chiedi al site owner di ricontrollare chi ha accesso e se è appropriato. Gli owner sono in genere i più vicini ai contenuti e possono cogliere velocemente un "Aspetta, perché Everyone ha accesso in lettura a questo? Non dovrebbe essere così". Metti in piedi un processo in cui i site admin certificano i permessi con regolarità.

Passo 7: stabilisci una supervisione continua

Metti in atto un processo di monitoraggio continuo per nuovi problemi di oversharing. Il controllo dell'oversharing non è un fix una tantum: mentre vengono creati nuovi site, Teams e file, devi intercettare le misconfigurazioni in modo proattivo. Considera l'uso dei report o degli alert di Microsoft Purview per intercettare cose come file condivisi esternamente o con gruppi enormi, nuovi Team pubblici creati e via dicendo. Gli strumenti Microsoft possono automatizzare gli alert per queste condizioni, quindi usali per mantenere una postura solida.

Passo 8: applica Sensitivity Label e policy DLP

Usa le Sensitivity Label di Microsoft Purview per classificare i dati (Confidential, Highly Confidential, ecc.) e collega quelle label a impostazioni di protezione. Ad esempio, una label "Confidential" può cifrare i file o impedire la condivisione esterna. Configura anche policy di Data Loss Prevention (DLP) per prevenire o monitorare l'oversharing di informazioni sensibili (come impedire a qualcuno di inviare via email un elenco di SSN dei clienti). Questi strumenti non solo prevengono leak accidentali nell'uso quotidiano, ma funzionano anche con Copilot: se Copilot prova ad accedere o restituire contenuti etichettati in modi che non dovrebbe, DLP può intervenire. Inoltre, Copilot stesso porterà avanti la label del documento nelle sue risposte, come vedremo più avanti.

Passo 9: implementa la governance della Power Platform

Estendi la tua supervisione alla Power Platform (Power Apps, Power Automate, ecc.). Definisci policy DLP per la Power Platform per controllare i connector (in modo che qualcuno non possa, ad esempio, creare un flow che estrae dati da una lista SharePoint sensibile e li pubblica su un servizio esterno). Considera anche di avere più ambienti (Dev/Test/Prod) con security adeguata, così che i "Citizen Developer" che costruiscono agent o app non espongano inavvertitamente dati. In sostanza, impedisci che la Power Platform diventi una backdoor non governata verso i tuoi dati.

Passo 10: forma e abilita i tuoi Agent Builder

Infine, crea linee guida e best practice per chi costruirà o distribuirà agent AI (che siano pro developer o utenti business). Metti in piedi una formazione sulla gestione sicura dei dati: ad esempio come scegliere le knowledge source appropriate per un agent, perché non includere file sensibili in un agent condiviso ampiamente, come testare l'output di un agent per informazioni inaspettate. Coltivando una cultura consapevole dei dati tra gli "agent maker", riduci le probabilità che qualcuno esponga involontariamente informazioni progettando una soluzione AI.

Fonti:

• https://techcommunity.microsoft.com/blog/microsoft365copilotblog/from-oversharing-to-optimization-deploying-microsoft-365-copilot-with-confidence/4357963
• https://techcommunity.microsoft.com/blog/microsoft365copilotblog/microsoft-graph-connectors-update-expand-copilot%E2%80%99s-knowledge-with-50-million-ite/4243648

Dopo aver completato questi passi puoi proseguire in sicurezza e iniziare a costruire agent produttivi. Per costruire agent abbiamo diverse piattaforme e feature Microsoft su cui poggiare. Trovi gli esempi più importanti nel prossimo capitolo. Se ti serve aiuto con questa lista, contattaci pure per supportarti in questo esercizio di preparazione fondamentale.

Nulla ti vieta nel frattempo di creare PoC o Test Agent con dati di esempio, file caricati manualmente o dati specifici collegati via RAG. Consigliamo però questi passi prima di una implementazione o rollout più ampio degli agent.

Comprendere le differenze tra le Agent Platform

Passo 1: comprendi i tuoi Agent Creator

Dopo il lavoro di fondamenta per preparare i dati, dobbiamo capire quali piattaforme sono disponibili per creare quegli agent. Cerchiamo di differenziare questi tool per feature e possibilità, ma è importante notare che creare agent e scegliere il tooling giusto è uno spettro. Ci sono diversi modi per costruire agent AI nell'ecosistema Microsoft. È importante scegliere quello giusto per le tue esigenze e per il livello di skill del tuo team. Chiarisce anche quando ricorrere ad Azure AI Foundry rispetto ai tool integrati di Copilot Studio.

Microsoft offre oggi un set di tool diversi per costruire agent. Sebbene sembrino simili tra loro, sono pensati per target e livelli di expertise differenti. Dai uno sguardo alla panoramica qui sotto. Capire chi deve creare e mantenere questi agent ci mostra anche quali knowledge source (= dati) dobbiamo preparare per i nostri agent. Oltre ai tool della lista qui sotto ci sono anche altre soluzioni pro-code per costruire agent, come M365 Agents Toolkit, Visual Studio Code, Agent SDK e altre. Tutti i nostri passi di preparazione dei dati valgono anche per loro, dato che accedono agli stessi dati degli altri agent.

Fonte: https://www.egroup-us.com/news/microsoft-copilot-ai-integration/

Passo 2: identifica use case e requisiti per la tua piattaforma

Come immagini, non ogni piattaforma supporta ogni use case. Gli agent possono essere usati per task semplici, come rispondere a domande basandosi su conoscenza esistente, o complessi, come generare risposte automaticamente o eseguire processi. Anche la UX finale, dove e come vogliamo accedere a questi agent, è importante per decidere la piattaforma.

Con queste considerazioni in mente cerchiamo di solito di usare la soluzione più semplice possibile per costruire il nostro agent. Al tempo stesso dobbiamo trovare la soluzione scalabile per uno sviluppo ulteriore. Ma non ogni agent va costruito su Azure AI Foundry sin dall'inizio.

Tip:

Se non sei sicuro da dove iniziare per costruire il tuo agent, puoi sempre usare Copilot Studio e integrare altri dati da Azure AI, per poi pubblicarlo in Microsoft 365 Copilot. Così ottieni sia la "up-compatibility" che la "down-compatibility".

RAG (Retrieval-Augumented Generation) vs. SharePoint vs. Upload

A prima vista sembra tutto RAG, ma ci sono differenze. Quando esplori per la prima volta i Copilot Agents e le loro capacità agent è facile assumere che tutta l'integrazione della conoscenza segua lo stesso pattern RAG (Retrieval-Augmented Generation). Anche se dall'esterno sembrano tutti RAG, cioè recuperano documenti e generano risposte, il modo in cui funzionano sotto il cofano differisce in modo significativo. Capire queste differenze è essenziale per scegliere l'approccio giusto in base ai tuoi obiettivi, alla scala e alla maturità tecnica. Ecco una breve spiegazione e panoramica.

Manual File Upload

Il caricamento manuale è il modo più semplice per aggiungere conoscenza a un Copilot Agent. Trascini e rilasci i documenti direttamente nell'interfaccia di Copilot Studio. Microsoft indicizza automaticamente questi file e recupera i contenuti rilevanti durante una query utente. È ideale per piccoli pilot e test iniziali. Tieni presente che il contenuto dei file deve essere accessibile a chiunque abbia accesso all'agent. Qui non c'è un Permission Management di cui prendersi cura. D'altra parte, dovrai aggiornare manualmente questi file nel lungo periodo se le cose cambiano. Attualmente per i Copilot Agents puoi aggiungere fino a 20 file manualmente.

Fonte: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

SharePoint Online

Questo metodo usa la Retrieval API di Microsoft per accedere ai contenuti direttamente da SharePoint Online, collegato via Graph Connector. L'agent recupera i contenuti più rilevanti live al momento della query, rispettando i permessi Microsoft 365 esistenti. I contenuti possono essere SharePoint site, document library, cartelle o file. È dinamico, sicuro e adatto a scalare tra reparti o business unit senza dover gestire la propria infrastruttura. Poggiando sull'infrastruttura esistente, usiamo il security model integrato di SharePoint, il che è un enorme vantaggio rispetto alle altre knowledge option. I reparti possono aggiornare facilmente i file e questo si rifletterà nell'agent. Ciò significa che se due utenti con livelli di accesso diversi interrogano l'agent, uno potrebbe ottenere una risposta da un certo file mentre un altro utente (senza accesso) no, che è esattamente il comportamento che vogliamo.

Nota: le SharePoint List al momento non sono un knowledge type supportato, quindi non puoi indicizzarle out of the box (Q3 2025).

Custom RAG (Self-Managed)

In un setup RAG classico costruisci e gestisci l'intera retrieval pipeline in autonomia. Include preprocessing dei documenti, chunking, embedding, storage in un vector database e recupero dei top match al momento della query. Questo ti dà pieno controllo su come i contenuti vengono processati e recuperati, ma porta con sé anche complessità e overhead di manutenzione. È indicato per use case avanzati che richiedono personalizzazione oltre ciò che offrono i managed service di Microsoft. Non è una feature integrata in Copilot o Copilot Studio, la faremmo in Microsoft Azure.

Un esempio di quando usare RAG potrebbe essere, per esempio, se dovessi integrare un agent AI con un database proprietario o con migliaia di PDF archiviati fuori da Microsoft 365 e applicare filtri custom, un RAG self-managed potrebbe essere necessario, ma richiede uno sforzo significativo.

fonte: https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs

Cosa scegliere e quando

Mentre tutti e tre gli approcci prevedono di recuperare contenuti per supportare la generazione linguistica, solo la soluzione custom self-managed è "vero RAG" in senso tecnico. Per la maggior parte delle organizzazioni che partono, gli upload manuali o le connessioni SharePoint sono significativamente più facili e veloci da implementare. Danno risultati solidi con setup minimo, e lasciano ai team la libertà di concentrarsi sul design del use case e sull'adozione, invece che sull'infrastruttura.

Un consiglio generale da parte mia su questo punto:

Prova a costruire gli agent il più vicino possibile ai tuoi dati.

Esempio: se i tuoi dati sono in grandi database SQL o in sistemi CRM esterni, un SharePoint Agent non farà il lavoro. Se abbiamo tutta la conoscenza in SharePoint, gli SharePoint Agent o i Copilot Agent possono essere un buon inizio.

Il custom RAG andrebbe considerato solo quando le tue esigenze vanno oltre ciò che le opzioni managed possono offrire, non come punto di partenza di default. Un upload manuale va benissimo per il primo pilot o per piccoli pilot con conoscenza limitata e specifica non aggiornata di frequente. In molti scenari useremmo semplicemente una libreria o un site SharePoint con l'agent. Per questo motivo ci concentriamo su uno scenario simile a quello:

Microsoft 365 Copilot & Copilot Agents: Security & Compliance out of the box

L'infrastruttura cloud sicura è la base per l'AI aziendale. Microsoft fornisce il framework più sicuro possibile per i nostri agent, mettendoli nel contesto di Microsoft 365 Copilot. Ogni organizzazione può fidarsi del proprio Security Framework esistente basato su Conditional Access e Multi-Factor Authentication per l'accesso, e del proprio Governance Framework esistente basato su Microsoft Purview.

Gli agent usati in M365 Copilot o pubblicati da Copilot Studio come Teams Chatbot sono accessibili solo entro i confini del nostro tenant. Ciò significa che otteniamo lo stesso livello di security che già abbiamo per queste applicazioni.

Oltre a questo, Microsoft offre diversi impegni tecnici e organizzativi raccolti in quello che chiamiamo "Enterprise Grade Data Protection".

Fonte: https://learn.microsoft.com/en-gb/copilot/microsoft-365/microsoft-365-copilot-privacy?azure-portal=true

Microsoft 365 Copilot: Enterprise Data Protection (EDP) per Prompt e Response

• Protezione contrattuale: i prompt (input utente) e le response (output di Copilot) sono protetti dal Data Protection Addendum (DPA) e dai Product Terms. Queste protezioni sono le stesse applicate alle email in Exchange e ai file in SharePoint.
• Data Security: cifratura at rest e in transit, controlli di sicurezza fisica, isolamento dei dati a livello di tenant
• Impegni sulla privacy: Microsoft agisce come data processor e usa i dati solo secondo le istruzioni del cliente. Supporta GDPR, EU Data Boundary, ISO/IEC 27018 e altro.
• Access Control & Policy Inheritance: Copilot rispetta identity model e permessi, sensitivity label, retention policy, impostazioni di audit, configurazioni admin, mitigazione dei rischi AI e copyright e protezione contro prompt injection, contenuti dannosi, questioni di copyright (tramite protected material detection e Customer Copyright Commitment).
• No Model Training: prompt, response e dati di Microsoft Graph NON vengono usati per allenare i foundation model.

Copilot Agent con SharePoint Online Knowledge:

• Modello di permessi e sharing: gli agent con accesso a SharePoint Online rispettano sempre i permessi dello SharePoint site associato. Ciò significa che, da un lato, devi assicurarti che chiunque debba avere accesso abbia almeno permessi di lettura sul site; dall'altro, devi vigilare per non concedere permessi non necessari che potrebbero esporre informazioni sensibili a utenti non autorizzati. Configurare correttamente i permessi è essenziale, poiché i Copilot Agent potranno accedere e mostrare solo contenuti che l'utente che effettua la query è autorizzato a vedere. Inoltre, sfruttare la information protection di Microsoft Purview garantisce che sensitivity label e policy di data loss prevention (DLP) rimangano legate al contenuto.
• Label persistenti e DLP: abilita la information protection di Microsoft Purview in modo che le sensitivity label rimangano legate ai contenuti. I Copilot Agent ereditano le label dai documenti sorgente. Ciò significa che se un file è classificato "Confidential", ogni contenuto o documento generato dall'AI d'ora in poi porterà con sé quella label. Questa ereditarietà persistente lavora insieme alle policy di Data Loss Prevention per impedire all'AI di esporre inavvertitamente dati protetti. In pratica, questo significa che anche se Copilot riassume un file sensibile, il riassunto sarà trattato come sensibile a sua volta. Questo è un aspetto straordinario che non troviamo fuori da Microsoft 365, e non vedremo agent AI in grado di integrarsi in modo così profondo nell'ecosistema Microsoft 365.

Best practice per preparare ulteriormente SharePoint Online all'uso con gli agent

Per preparare SharePoint Online a un uso efficace con i Copilot Agent, segui queste best practice:

SharePoint site dedicato

Per prima cosa, crea uno SharePoint site dedicato o una cartella specifica pensata esclusivamente per la knowledge base del tuo Copilot Agent. Questo approccio aiuta a minimizzare i problemi legati all'oversharing e riduce il rischio che gli utenti carichino accidentalmente file sensibili o non pertinenti nel repository accessibile all'agent. Se decidi di usare uno SharePoint site esistente, controlla con attenzione i suoi contenuti per assicurarti che non vi siano informazioni riservate o sensibili che non dovrebbero essere scopribili dall'agent.

Concedere l'accesso

È importante anche assicurarsi che tutti gli utenti previsti abbiano i necessari permessi di lettura per accedere al site o alla cartella. Se devi concedere l'accesso manualmente, assicurati che tutti gli utenti previsti abbiano accesso in lettura al site (ad esempio aggiungendoli al gruppo Visitors dello SharePoint site o a un opportuno gruppo di security di Azure AD) per semplificare il processo ed evitare misconfigurazioni accidentali dei permessi.

Preparare i file

Quando prepari i documenti per l'uso con i Copilot Agent, ricorda che l'AI al momento non può interpretare le immagini incorporate nei file. Per questo aggiungi didascalie descrittive o testo alternativo per assicurarti che le informazioni visive importanti non vadano perse. Per documenti text-heavy, assicurati che quando riassumi o fai riferimento a contenuti, il totale resti entro un massimo di 1,5 milioni di parole o 300 pagine per far lavorare Copilot in modo efficace.

Per i file Excel, organizza i dati in modo che ogni file si concentri o su numeri o su testo, dato che le tabelle a contenuto misto tendono a dare risultati meno accurati. Gli agent inoltre rispondono in modo più affidabile alle query quando i dati rilevanti sono contenuti in un singolo sheet del workbook.

Gli agent rispondono al meglio ai dati Excel quando sono contenuti in un solo sheet.

Esempio: se hai un grande survey di customer feedback archiviato in un singolo file Excel, separa i dati quantitativi (come rating e risposte numeriche) da quelli qualitativi (come feedback in testo libero) in due sheet differenti. Questo metodo ti permette di usare strumenti come Python e formule Excel per analizzare in modo efficiente i dati numerici (ad esempio calcolare medie, ordinare i risultati, determinare i confidence level), sfruttando al contempo le feature di sentiment analysis di M365 Copilot per trarre insight dal feedback testuale.

File Limitations

Infine, sii consapevole dei tipi di file e dei limiti di dimensione supportati dai Copilot Agent e da Copilot Studio. La tabella seguente riassume il supporto attuale: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

Tieni conto anche delle best practice che Microsoft ha condiviso sulla lunghezza dei documenti: https://support.microsoft.com/en-gb/topic/keep-it-short-and-sweet-a-guide-on-the-length-of-documents-that-you-provide-to-copilot-66de2ffd-deb2-4f0c-8984-098316104389

File type attualmente non supportati in SharePoint Online: ufficialmente, tutto ciò che non è elencato lì non è ufficialmente supportato.

Alcuni file type, come i CSV, possono funzionare in modo adeguato anche se non ufficialmente supportati perché somigliano molto ai formati di testo semplice. Tuttavia, la maggior parte degli altri file type, in particolare i container file come CAB, EXE, ZIP e i formati immagine, video e audio come PNG, IMG, MP3 e MP4, non sono supportati al momento.

Considerazioni finali

Seguendo queste raccomandazioni puoi assicurarti che i tuoi Copilot Agent abbiano accesso a dati ben strutturati, sicuri e di alta qualità, massimizzando la loro utilità e minimizzando il rischio di esposizione accidentale dei dati. Investire tempo nella preparazione del tuo ambiente SharePoint pone una foundation solida per una distribuzione e un'adozione di successo degli agent AI nella tua organizzazione.

Anzi, molti dei nostri progetti "Build-an-Agent" partono esattamente da lì. Non costruendo l'agent, ma preparando l'infrastruttura e la knowledge, in modo da avere dati di buona qualità da usare per l'AI, perché l'agent è buono solo quanto il sistema che gli sta sotto.