L’ufficio acquisti di una PMI manifatturiera passa mezza giornata a rispondere alle stesse domande interne: “qual è la procedura per il reso fornitore?”, “dove trovo il template d’ordine aggiornato?”, “che soglia ho per approvare in autonomia?”. Le risposte sono già scritte, ferme in una libreria SharePoint che nessuno apre perché cercarle costa più che chiedere a un collega. È lo scenario che gli agenti in SharePoint risolvono: con pochi clic trasformi quella raccolta di documenti in un assistente AI che risponde in linguaggio naturale, citando i file da cui ha preso l’informazione.
La novità per le PMI è che questo non richiede più di passare da uno strumento di sviluppo. L’agente nasce direttamente dal sito o dalla libreria, no-code, in pochi minuti. Vediamo come si crea, come si delimita cosa può leggere, quale licenza serve e perché la parte più delicata non è tecnica ma di governance.
Cosa sono gli agenti in SharePoint
Un agente in SharePoint è un assistente conversazionale “grounded” su un insieme definito di contenuti SharePoint: uno o più siti, una o più librerie documentali, fino a singole cartelle o file. Quando un utente gli pone una domanda, l’agente cerca tra quei documenti, sintetizza una risposta e mostra i riferimenti alle fonti, così chi legge può verificare. È la stessa logica del Retrieval-Augmented Generation, ma pacchettizzata per chi non scrive una riga di codice.
A differenza di un’introduzione generale a cos’è SharePoint e a cosa serve, qui non parliamo di archiviazione o intranet: parliamo di mettere uno strato di AI sopra i documenti che già avete. Gli agenti vivono dentro l’esperienza SharePoint e possono poi essere usati anche dentro Microsoft Teams, dove la maggior parte delle PMI lavora ogni giorno.
Il punto chiave: l’agente non “sa” nulla dell’azienda di per sé. Sa solo ciò che gli date come ambito. Questo è un bene per la pertinenza (risponde sul vostro dominio, non inventa policy generiche) ed è la ragione per cui la scelta dell’ambito e dei permessi è la decisione più importante del processo.
Come si crea un agente, passo per passo
La creazione è deliberatamente semplice. Dal sito SharePoint o da una libreria documenti, si avvia la creazione dell’agente direttamente dalla barra dei comandi. Da lì il flusso tipico è questo:
1. Definire le fonti (l’ambito)
L’agente parte con il sito corrente come fonte. Potete ampliare o restringere: aggiungere altri siti, selezionare librerie specifiche, scendere fino a singole cartelle o file. Questa è la leva più importante. Un agente “ufficio HR” dovrebbe vedere solo la libreria delle policy del personale, non l’intero tenant.
2. Dare un nome, una descrizione e istruzioni
Assegnate un nome parlante (“Assistente Procedure Acquisti”), una descrizione e — consigliato — istruzioni che guidano il comportamento: tono, lingua di risposta (italiano), cosa fare quando non trova l’informazione (suggerire il referente invece di improvvisare).
3. Aggiungere domande di avvio
Le starter prompt sono le domande suggerite che l’utente vede al primo accesso. Riducono l’attrito: invece della pagina bianca, l’utente clicca “Come avvio un reso fornitore?” e capisce subito cosa l’agente sa fare.
4. Testare, poi condividere
Prima della pubblicazione, provatelo con domande reali e domande “trappola” (cose che NON dovrebbe sapere, per verificare che non sconfini). Quando siete soddisfatti, l’agente si condivide con i colleghi o si rende disponibile in Teams. La condivisione segue i meccanismi standard di Microsoft 365, ed è qui che entra in gioco la governance.
Per casi semplici — knowledge base interna, FAQ di reparto, runbook operativi — l’intero giro richiede minuti, non giorni: uno sforzo molto inferiore rispetto a costruire un bot in Copilot Studio, e per molte PMI è abbastanza.
Quale licenza serve
È la domanda che fa inciampare di più. Gli agenti SharePoint sono parte dell’ecosistema Microsoft 365 Copilot: per crearli e usarli appieno serve una licenza Copilot abbinata a Microsoft 365.
In pratica:
- Una base Microsoft 365 (Business Standard/Premium o E3/E5) fornisce SharePoint e il contesto di lavoro. La trovate nella scheda Microsoft 365.
- Per gli agenti grounded sui documenti serve il livello Microsoft 365 Copilot, che abilita l’AI generativa sopra i vostri contenuti.
Le condizioni di licenza e i meccanismi di consumo evolvono spesso: per gli scenari a consumo Microsoft spinge modelli pay-as-you-go basati su crediti, che fanno pagare l’utilizzo effettivo invece di una licenza fissa per ogni utente. Non riportiamo importi qui perché cambiano e dipendono dal piano: la regola operativa è verificare la propria configurazione con il partner prima di promettere agenti a tutta l’azienda. L’errore da evitare è assumere che “tanto SharePoint ce l’abbiamo già, quindi è gratis”: l’AI generativa sopra i documenti ha un suo modello di licenza.
La governance viene prima di tutto
È la parte che separa un progetto riuscito da un incidente di data leak. Un agente è potente proprio perché legge i documenti e li sintetizza in risposte chiare. Ma questa stessa caratteristica amplifica ogni errore di permessi già esistente nel tenant.
I permessi sono ereditati, non riscritti
Un agente rispetta i permessi esistenti di chi pone la domanda: in teoria, se un utente non può aprire un file, l’agente non gliene mostra il contenuto. Questo è il modello corretto. Il problema è che si appoggia ai permessi reali di SharePoint, che in molte PMI sono cresciuti per stratificazione: cartelle condivise “con tutta l’azienda” anni fa, link “chiunque nell’organizzazione” mai revocati, gruppi con accessi più ampi del dovuto.
L’agente non crea l’oversharing: lo rende visibile e facile da sfruttare. Prima, per trovare il file con gli stipendi finito per errore in una libreria aperta, dovevi sapere che esisteva e dove cercarlo. Con un agente basta chiederlo a parole: se l’informazione è raggiungibile, l’AI la troverà e la riassumerà.
Cosa fare prima di pubblicare
- Audit dei permessi del sito/libreria che fa da ambito. Chi può leggere cosa? Ci sono link di condivisione anonimi o “tutta l’organizzazione” non necessari?
- Ambito stretto, non largo. Puntate l’agente alla libreria più piccola che risponde al bisogno, non all’intero sito “per comodità”.
- Sensitivity label e Purview. Classificate e proteggete i contenuti sensibili con le etichette di riservatezza: un documento etichettato e cifrato resta protetto anche quando l’agente lo incontra. È il momento giusto per impostare le sensitivity label di Microsoft Purview, se non l’avete ancora fatto.
- Niente dati ad alto rischio nell’ambito iniziale. Per il primo agente scegliete contenuti a basso rischio (procedure, FAQ, manuali) e tenete fuori HR sensibile, contratti, dati finanziari finché la governance non è solida.
La sequenza giusta è: prima si mette in ordine chi vede cosa, poi si attiva l’agente. Invertire l’ordine significa scoprire i problemi di permessi nel modo peggiore — da una risposta dell’AI a chi non doveva riceverla.
Quando invece serve Copilot Studio
Gli agenti SharePoint sono perfetti finché il bisogno è “rispondi sui miei documenti”. Quando il caso d’uso diventa più articolato, lo strumento giusto è Copilot Studio, l’ambiente pro-code/low-code della Power Platform.
Passate a Copilot Studio quando vi serve:
- Più fonti dati oltre a SharePoint: database, gestionali, API esterne, siti web.
- Eseguire azioni, non solo rispondere: aprire un ticket, creare una riga in un gestionale, avviare un’approvazione.
- Logiche di conversazione complesse, topic strutturati, handover a un operatore umano.
- Canali multipli: sito web pubblico, WhatsApp, oltre a Teams.
- Governance avanzata con identità dedicate degli agenti e controlli IT granulari.
In sintesi: l’agente SharePoint è il “risponditore esperto” sui vostri documenti; Copilot Studio è la piattaforma per costruire un assistente che fa cose. Molte PMI iniziano dall’agente SharePoint per un caso semplice e migrano a Copilot Studio solo quando serve azione o integrazione — un percorso sano, che evita di sovra-ingegnerizzare al primo colpo.
Quando ha senso un servizio gestito
Creare un agente SharePoint è alla portata di chiunque sappia usare SharePoint. Metterlo in produzione in sicurezza è un’altra cosa: richiede un audit dei permessi, una strategia di etichettatura con Purview e un presidio su cosa l’AI può e non può raggiungere. È nello scarto tra “ho creato un agente” e “ho un agente che non espone dati sbagliati” che le PMI hanno bisogno di una mano.
Con il servizio di assistenza Microsoft 365 gestita accompagniamo la PMI dall’igiene dei permessi alla configurazione delle sensitivity label, fino alla pubblicazione dell’agente con un perimetro chiaro. Se la priorità è il lato sicurezza — oversharing, classificazione dei dati, controllo degli accessi — l’assistenza cybersecurity gestita interviene sulla postura prima ancora di attivare l’AI. Vuoi capire da dove partire sul tuo tenant? Parla con un nostro consulente.
Domande frequenti
Che differenza c’è tra un agente SharePoint e Copilot Studio?
L’agente SharePoint si crea no-code direttamente da un sito o una libreria e serve a rispondere sui documenti contenuti in un ambito definito. Copilot Studio è la piattaforma pro-code/low-code per agenti più complessi: più fonti dati, azioni concrete, canali multipli (sito web, WhatsApp), logiche di conversazione e governance avanzata. Si parte spesso dall’agente SharePoint e si migra a Copilot Studio quando servono integrazioni o azioni.
Quale licenza serve per creare un agente in SharePoint?
Serve una base Microsoft 365 (che fornisce SharePoint) abbinata al livello Microsoft 365 Copilot, che abilita l’AI generativa sopra i documenti. Per gli scenari a consumo Microsoft offre anche modelli pay-as-you-go basati su crediti. Importi e condizioni cambiano spesso: conviene verificare la propria configurazione con il partner prima di estendere gli agenti a tutta l’azienda.
Un agente può esporre documenti che un utente non dovrebbe vedere?
L’agente rispetta i permessi esistenti dell’utente che pone la domanda: se non può aprire un file, in teoria non ne riceve il contenuto. Il rischio reale è l’oversharing già presente nel tenant (cartelle condivise troppo ampiamente, link non revocati): l’agente non lo crea, ma lo rende facile da sfruttare. Per questo l’audit dei permessi e le sensitivity label di Purview vanno fatti prima di pubblicare.
Come si delimita cosa può leggere l’agente?
Si definisce l’ambito scegliendo le fonti: uno o più siti, librerie specifiche, fino a singole cartelle o file. La buona pratica è puntare alla libreria più piccola che risponde al bisogno, evitando di dare in pasto l’intero sito o tenant “per comodità”. Un ambito stretto migliora sia la pertinenza delle risposte sia la sicurezza.