Copilot Studio: come creare un agente Copilot utile

Knowledge base, istruzioni, output, test e governance: cosa fare prima di condividere un agente Copilot con il team.

Creare un agente Copilot con Copilot Studio sembra facile.

Apri Copilot Studio o l’Agent Builder di turno. Gli dai un nome, gli scrivi cosa deve fare. Aggiungi qualche documento, lo colleghi a un repository, provi una domanda. La sua risposta ti convince.

A quel punto arriva la tentazione: condividerlo subito con il team. Ed ecco che cominciano i problemi.

Un agente Copilot non fallisce quasi mai nella versione “demo”. Fallisce dopo, quando lo usano persone diverse da te e gli fanno domande incomplete. Quando pesca da un documento vecchio o quando trova due fonti in conflitto e sceglie quella sbagliata con la sicurezza di un consulente junior in una call alle 18:45.

Il problema è che gli agenti si nutrono delle fonti che gli dai in pasto. Se il tuo SharePoint è una discarica, Copilot non lo trasforma in una biblioteca. Lo rende solo una discarica più eloquente.

E le fonti sono solo il primo dei tre punti dove si decide tutto. Fonti, perimetro, formato dell’output. Se sbagli uno di questi, l’agente non funzionerà come volevi.

IN BREVE

Un agente Copilot utile nasce da un perimetro chiaro, non dal prompt perfetto.
Più documenti non significano risposte migliori. Spesso significano risposte più confuse.
La knowledge base va curata prima: fonti autorevoli, niente duplicati, niente versioni vecchie.
Le istruzioni devono dire cosa fare, quando fermarsi e quando dichiarare “non lo so”.
L’output non è un dettaglio: se non controlli il formato della risposta, non controlli davvero l’agente.
Prima del rilascio serve un test serio, non una demo rassicurante.
Dopo il rilascio serve governance: owner, manutenzione, controllo permessi, incidenti, versioning.

Cosa troverai in questo articolo sulla creazione di un agente Copilot

Prima domanda: serve davvero un agente Copilot?

La tentazione è costruire subito ed è comprensibile. Strumenti come Copilot Studio e gli Agent Builder no-code abbassano la soglia d’ingresso, permettono di vedere subito il risultato.

Dopo aver descritto l’agente in linguaggio naturale, magari facendoti aiutare dallo stesso Copilot nella configurazione, e dopo aver definito istruzioni e fonti di conoscenza, puoi avere l’impressione di trovarti davanti a un collega digitale.

In realtà, quello che hai costruito è un agente dichiarativo: un assistente che lavora entro i confini che gli hai dato e che non ha piena autonomia. Risponde sulla base delle istruzioni impostate e delle fonti che hai scelto di collegare.

Una nota di metodo: qui uso “agente Copilot” in senso operativo, riferendomi soprattutto agli agenti dichiarativi costruiti nell’ecosistema Microsoft 365 Copilot (Agent Builder o Copilot Studio). Possibilità e limiti specifici cambiano in base a licenza, tenant e strumento di creazione.

La prima domanda da farsi è se serve davvero. “Come lo costruisco?” viene dopo, quando è chiaro il fine per cui lo si vuole usare. È lo stesso principio che Anthropic mette in cima alla sua guida sugli agenti: parti dalla soluzione più semplice e aggiungi complessità solo quando migliora davvero il risultato.

Tra l’altro, molte attività sono già coperte da Microsoft 365 Copilot base: riassumere una riunione, aiutare a scrivere una mail, sintetizzare un documento, preparare una bozza. Per queste cose non serve creare un agente custom. Sarebbe come aprire una fabbrica per farsi un panino.

Anzi, ci sono casi in cui un agente non va proprio creato:

se ti serve solo riassumere riunioni o mail;
se la knowledge base è disordinata e nessuno la sistemerà;
se nessuno potrà mantenerlo dopo il rilascio;
se il processo non è chiaro nemmeno agli esseri umani;
se lo vuoi per prendere decisioni che spettano a un responsabile.

Un agente ha senso quando deve lavorare su una conoscenza di dominio precisa: procedure interne, standard di team, documentazione di progetto, criteri operativi, glossari, template, regole condivise.

“Un assistente che aiuta il team” è troppo vago. È molto meglio: “un agente che risponde a domande sui nostri standard di lavoro e supporta la creazione di requisiti, criteri di accettazione e test case secondo i documenti approvati”. Meno affascinante, ma molto più utile.

Allo stato attuale della tecnologia, uno scopo stretto batte sempre un agente tuttofare. Quello che risponde su processi, progetti, budget, rischi, normative, persone, ferie, architetture, test, incidenti, audit e magari consiglia anche dove andare a pranzo è una pessima idea. Un agente troppo ampio non sa quando fermarsi e quali fonti privilegiare. Sembra potente, ma è fragile: più allarghi il perimetro, più aumenti le possibilità che risponda bene alla domanda sbagliata.

Prima di aprire Copilot Studio, bisogna chiarire quattro aspetti:

Chi è l’agente.
Quale lavoro accelera.
Quali ruoli serve.
Cosa è fuori perimetro.

Esempio: “Sei l’assistente di area per il supporto ai team. Aiuti a trovare standard, procedure e template approvati. Produci bozze operative, ma non prendi decisioni tecniche, regolamentari o organizzative. Quando l’informazione non è presente nelle fonti, lo dichiari e non inventi.”

Dare un ruolo esatto all’agente e, contestualmente, dei limiti, ne aumenta l’utilità.

Il punto debole di un agente Copilot è la knowledge base. Le istruzioni vengono dopo

Qui arriva la parte meno sexy e più importante. La qualità dell’agente si decide prima di costruirlo, nella knowledge base che gli dai da leggere.

L’istinto dice: carichiamo tutto. Tutte le procedure, le minute, i documenti funzionali, incluse le versioni vecchie, perché “non si sa mai”. È l’errore classico: più documenti significano soltanto più rumore.

In qualunque archivio aziendale reale convivono file superati, duplicati, PDF scansionati male, procedure scritte tre riorganizzazioni fa e mai eliminate perché nessuno ha il coraggio di farlo. L’agente non sa che quel documento è morto. Se lo trova, lo usa. E lo userà con una sicurezza irritante.

La regola è brutale: una knowledge piccola e curata batte sempre una knowledge grande e disordinata. Per ogni argomento serve una fonte autorevole. Una sola, non cinque. Se due documenti dicono cose diverse, non stai creando un agente: stai creando un conflitto automatico.

E qui un vincolo gioca a tuo favore: Microsoft pone limiti alle fonti collegabili, che variano per tipo (siti e file SharePoint, file OneDrive, pagine web, connettori). Non è un tetto da saturare, è un invito a scegliere. Se per coprire un dominio ti servono decine di fonti, il problema è che la knowledge base non è ancora curata.

Prima di aggiungere una fonte, bisogna fare queste verifiche:

È ancora valida e ha un owner?
Ha una data di aggiornamento?
È la fonte autorevole su quel tema, e sostituisce le precedenti?
Contiene dati che non dovrebbero essere accessibili?
È leggibile da una macchina?

Sembra burocrazia e invece è igiene. Un agente Copilot non sfoglia i documenti come una persona paziente: recupera passaggi, cerca pattern, produce risposte. Se il documento è confuso, scansionato male, pieno di eccezioni implicite, il risultato peggiora.

Garbage in, garbage out. Lo dicevamo già prima dell’AI. Solo che adesso la spazzatura parla.

Le istruzioni: non cercare il prompt magico

Dopo la knowledge base arrivano le istruzioni. Qui l’errore è opposto: credere che una buona istruzione possa salvare una base documentale pessima. Non può. Le istruzioni delimitano il comportamento dell’agente, non guariscono i documenti.

Suggerisco una struttura semplice:

Purpose: chi sei e a cosa servi.
Guidelines: tono, limiti, fonti, cosa fare quando non sai.
Domain terms: acronimi e parole di dominio.
Skills: compiti specifici che l’agente può svolgere.

Oppure, se preferisci ragionare per blocchi: ruolo, obiettivi, contesto, esecuzione. Il nome conta poco, la disciplina sì.

La regola più importante è questa: se l’informazione non è nella knowledge, dichiaralo. Non inventare, non compensare, non abbellire.

In azienda è fondamentale. Una risposta incompleta ma onesta è gestibile. Un’allucinazione scritta con una sintassi perfetta è pericolosa.

La lezione di N.I.M.O.: se non controlli l’output, non controlli l’agente Copilot

Ho imparato questa cosa costruendo N.I.M.O., uno strumento con cui metto alla prova idee, progetti e storie, e che ho costruito facendo lavorare insieme più modelli: ChatGPT, Claude, Gemini.

All’inizio pensi che il problema sia far rispondere bene l’AI. Poi scopri che il problema vero è impedirle di essere genericamente utile: fluida, educata, plausibile e spesso impossibile da verificare.

Per questo, nel motore di N.I.M.O., non ho chiesto “valuta questa idea”. Ho imposto un output strutturato: verdetto, diagnosi, punteggio di maturità, contesto, punti di rottura, bias, cliché, illusione principale, motivazione. Ho usato un JSON come formato di risposta per tenere il modello nei binari.

Il JSON è il blocco di cemento con le parentesi graffe che impedisce all’AI di fare quello che vuole. Costringe il modello a separare le parti del giudizio. E quando separi le parti, puoi controllarle.

Un conto è ricevere: “L’idea sembra interessante, ma andrebbe approfondita.” Grazie, anche l’oroscopo dà consigli del genere.

Un altro conto è ricevere una struttura che distingue il verdetto, la sua causa, i rischi strutturali, i bias rilevati, le assunzioni non verificate, le parti da preservare, i casi in cui l’input è insufficiente.

Questa è governance dell’output. La lezione che porto da N.I.M.O. non è “usate tutti un JSON”: è che un agente Copilot utile deve produrre risposte confrontabili, verificabili e ripetibili.

JSON sempre? No, sarebbe una tortura

Non significa far rispondere in JSON tutti gli agenti. Se un collega chiede “dove trovo lo standard per i criteri di accettazione?”, una risposta in linguaggio naturale è più utile. Il formato deve servire al compito.

Ma se chiedi all’agente di valutare un requisito, controllare un documento, classificare un rischio o analizzare una richiesta di business, allora serve un output ricorrente, non per forza JSON, basta una struttura markdown:

Verdetto: completo, incompleto, ambiguo, non valutabile.
Sintesi: massimo tre frasi.
Campi mancanti / ambiguità.
Criteri non verificabili.
Fonti usate.
Domande da fare al business.

Il punto è questo: l’agente non deve solo rispondere, deve rispondere in modo confrontabile. Se oggi valuta una cosa in un modo e domani in un altro, non hai un assistente: hai un collega lunatico che però non puoi neanche invitare a prendere un caffè.

Le tassonomie sono più importanti del tono

Uno degli errori più comuni è lavorare troppo sul tono. “Rispondi in modo professionale, chiaro, sintetico.” Va bene, serve, ma non basta. Spesso la cosa più importante non è il tono: sono le categorie.

In N.I.M.O. ho dovuto definire tassonomie controllate: tipi di verdetto, bias ammissibili, criteri di maturità, casi in cui non valutare. Perché se non dai categorie al modello, se le inventa. Ed è bravissimo a inventare categorie che sembrano sensate. Il problema è che poi qualcuno le prende sul serio.

In un agente aziendale succede lo stesso. Se vuoi che aiuti davvero un team, devi dargli categorie di dominio: tipi di requisito, tipi di rischio, stati RAG, classificazione delle issue, definizione di blocco/dipendenza/escalation, stati documento, livelli di confidenza.

Senza tassonomie, l’agente produce ordine apparente. Con le tassonomie, comincia a produrre ordine verificabile. La differenza è enorme.

La regola “non valutabile” è una protezione

La lezione più importante di N.I.M.O., però, è un’altra: devi insegnare all’AI a fermarsi.

Nel motore ho inserito una regola esplicita: se l’input è troppo vago, generico o breve, il sistema non finge una valutazione. Restituisce “non valutabile” e dice cosa manca.

Per un agente Copilot vale ancora di più. Se la richiesta è ambigua, l’agente non deve completare i vuoti con fantasia statistica. Deve fermarsi, chiedere contesto, dichiarare che non può rispondere.

Sembra una piccola cosa, ma non lo è. L’AI ama chiudere i cerchi: è progettata per produrre una risposta e se manca un pezzo tende a compensare. Nel lavoro reale, però, i pezzi mancanti sono spesso quelli decisivi. Quale procedura? Quale versione? Quale perimetro? Quale fonte approvata? Se l’agente li riempie da solo, ti sta aiutando a sbagliare più velocemente. Che è una delle grandi promesse non dichiarate dell’AI.

Compito o decisione?

Ogni volta che usi un agente Copilot dovresti chiederti: sto delegando un compito o una decisione?

I compiti si delegano: riassumere un documento, estrarre criteri, preparare una bozza, raccogliere dipendenze, suggerire una struttura di test case.

Le decisioni no: chiudere un finding, scegliere una soluzione tecnica, validare un rischio regolamentare, interpretare una policy in un caso ambiguo, prendere posizione quando le fonti sono in conflitto. Queste restano umane.

Il problema è che l’AI è bravissima a darti una risposta quando dovrebbe dirti “non posso saperlo”. Per questo il confine va scritto prima. Non quando il danno è già nell’e-mail.

Testare prima di fidarsi

La demo serve a rassicurare chi ha già voglia di credere. Un test serve a trovare dove il sistema si rompe.

Prima di condividere l’agente, consiglio di preparare un golden test set: domande reali, divise per ruolo e difficoltà. Domande frequenti, ambigue, fuori perimetro, con fonti contraddittorie, su documenti obsoleti, e qualche tentativo di prompt injection: input costruiti apposta per far dire all’agente quello che non dovrebbe, o per estrarre dati non consentiti.

Conviene pensare alla sicurezza come a una difesa a livelli, non a un controllo solo: filtri sull’input, classificatori che segnalano le domande fuori tema, rilevamento dei tentativi di manipolazione, e l’ultima rete che resta umana.

E il maker non dovrebbe essere l’unico tester. Serve un piccolo gruppo cross-ruolo: chi raccoglie i requisiti, chi sviluppa, chi testa. Magari qualcuno che non ha partecipato alla costruzione. Perché chi costruisce l’agente sa cosa chiedere. Chi lo userà davvero no. E proprio lì scopri se funziona. E lo adatti.

È una delle grandi differenze tra i progetti AI e non-AI. Nei progetti tradizionali, ti puoi basare su “SE A allora B”. Con l’AI non puoi. Devi affinare, aumentare la probabilità di risposta corretta, che non sarà mai il 100% per tutte le domande possibili. Non a caso Anthropic distingue i workflow, dove i passaggi seguono percorsi predefiniti, dagli agenti, dove è il modello a dirigere il processo. Un agente dichiarativo sta nel mezzo: più lo lasci decidere, più devi affinare invece di programmare.

Quando non rilasciare un agente Copilot

Servono criteri di uscita. Non “mi sembra buono”, non “in demo ha fatto bella figura”. Una soglia possibile:

almeno il 90% delle risposte fattuali cita la fonte corretta;
zero esposizioni di dati sensibili nei test negativi;
rifiuto corretto delle domande fuori perimetro;
nessuna invenzione quando la risposta non è nella knowledge;
output coerente nei task strutturati.

Sottosoglia non si rilascia: si correggono knowledge o istruzioni e si riprova. È la logica dei progetti seri: prima definisci cosa significa “funziona”, poi verifichi. Se fai il contrario, non stai governando. Stai sperando.

Dopo il rilascio: chi governa l’agente?

Qui molte iniziative AI diventano pericolose. Si crea l’agente, lo si condivide, tutti contenti, fine. No.

Una volta pubblicato comincia il lavoro vero. Un agente Copilot è un piccolo sistema vivo: cambiano i documenti, i processi, i modelli sottostanti, i permessi, gli utenti. Senza governance, degrada.

Servono almeno quattro ruoli: un owner dell’agente, un maker che mantiene configurazione e istruzioni, un owner della knowledge, uno o più tester per le regressioni. E serve un canale incidenti: se l’agente dà una risposta materialmente errata, chi lo spegne? Entro quanto? Chi corregge la fonte?

Non sono dettagli amministrativi: sono il confine tra sperimentazione responsabile e giocattolo lasciato acceso in produzione. Perché una volta pubblicato, l’agente inizia a consumare fiducia: se funziona bene la aumenta, se sbaglia in modo elegante la brucia.

Checklist minima prima di pubblicare un agente Copilot

Scopo dell’agente scritto in quattro righe.
Ruoli serviti chiariti.
Cose fuori perimetro dichiarate.
Knowledge base pulita, fonti obsolete rimosse.
Owner delle fonti definito.
Istruzioni con la regola “non lo so”.
Output standard per i task valutativi.
Test set con domande reali, ambigue e fuori perimetro.
Verifica dei permessi.
Owner dell’agente nominato.
Processo di gestione incidenti definito.

Se anche una sola di queste righe resta vuota, non sei pronto a condividerlo.

La domanda che resta

Un agente Copilot utile non è quello più intelligente. È quello meglio delimitato. Quello che sa dove cercare, che cita le fonti, che non si vergogna di dire “non lo so”, che restituisce output controllabili quando serve, che aiuta a lavorare più velocemente senza prendersi responsabilità che non gli appartengono.

Nei progetti veri servono strumenti affidabili. Gli oracoli affascinano, ma servono a poco. E l’affidabilità nasce da ciò che fai prima di implementare l’agente Copilot. Scegliere cosa includere, cosa escludere, cosa testare, quale formato pretendere, chi decide, chi controlla, chi spegne tutto se qualcosa va storto.

È la stessa idea della co-intelligence di Ethan Mollick: l’AI come collega capace, con un umano che resta il decisore. Come spesso accade, non è davvero una questione di tecnologia. È una questione di giudizio. L’AI può accelerare il lavoro. Ma qualcuno deve ancora sapere dove si sta andando.

Vuoi sapere quando pubblico qualcosa di nuovo? Niente spam. Ti scrivo solo quando ne vale la pena. Lascia la tua email.