Tre artefatti diversi sotto lo stesso nome

Quando un comitato chiede «facciamo una prompt library», sta chiedendo tre cose che hanno proprietario, ciclo di vita e superficie di rischio diversi, e il primo lavoro dell’architetto è separarle.

  • I prompt riusabili costruiti nel prompt builder di Microsoft Copilot Studio e di AI Builder: un’istruzione in linguaggio naturale con input variables e knowledge data, testabile, salvabile e riutilizzabile come tool di un agente, come nodo di un flow o dentro un’app. Sono componenti applicativi.
  • Le instructions di un agente: le declarative agent instructions di un declarative agent di Microsoft 365 Copilot e le istruzioni della pagina Overview di un agente Copilot Studio in generative orchestration. Sono configurazione di prodotto, e decidono quali tool vengono chiamati.
  • I prompt rivolti all’utente finale, come gli Starter Prompts che un amministratore configura per Sales agent chat: quelli forniti da Microsoft sono marcati Default, si possono disabilitare ma non modificare né eliminare. Sono contenuto di adozione, e invecchiano con il vocabolario commerciale.

Chi li mette nello stesso repository con la stessa procedura di approvazione ha già sbagliato l’architettura. La proprietà del tutto sta nell’AI Center of Excellence: fra le sue responsabilità il Cloud Adoption Framework elenca esplicitamente «Develop reusable assets» e, nella gestione dei servizi AI, «Build and maintain a library of templates, code repositories, and compliance tools». Il modello operativo però non è stabile: centralizzato all’inizio per consolidare le pratiche, poi advisory, quando le code di approvazione diventano il collo di bottiglia. È esattamente la transizione che l’esame chiede di proporre.

Versionare vuol dire entrare nell’ALM, non aprire una cartella

Un distributore farmaceutico con centocinquanta maker su nove paesi ha un vincolo di audit: deve poter dimostrare quale versione del prompt di estrazione dati ha prodotto un certo output sei mesi fa. Una cartella condivisa non lo soddisfa; l’ALM di Power Platform sì. I prompt e i componenti di agente viaggiano dentro le solution, e le regole d’oro valgono senza sconti: non personalizzare fuori dall’ambiente di sviluppo, lavorare sempre nel contesto di una solution, usare publisher e prefisso custom, spostare in environment variables ciò che cambia fra ambienti, esportare come managed, abilitare il source control con la Git integration. Almeno tre ambienti, development e test di tipo sandbox e production di tipo production. La promozione passa da Pipelines in Power Platform, da Azure DevOps o dalle GitHub Actions for Power Platform secondo chi deve premere il pulsante; le component collection permettono di condividere topic, knowledge e action fra agenti e ambienti con versioni proprie.

Due precisazioni che l’esame ama. La prima: alcuni elementi di Copilot Studio non sono solution-aware — impostazioni di Application Insights, autenticazione manuale, sicurezza dei canali Direct Line e Web, canali pubblicati, sharing — e richiedono passaggi post-deployment a valle. La seconda: questo è l’ALM di Power Platform, non il deployment lifecycle di un modello o di un agente in Microsoft Foundry, che ha artefatti propri.

C’è poi un anti-pattern dichiarato dalla documentazione (/microsoft-365/copilot/extensibility/declarative-agent-instructions): non spostare le instructions di un declarative agent dentro un documento SharePoint per aggirare il limite di 8.000 caratteri. Il contenuto di una knowledge source non è trattato come istruzione autorevole, passa dai classificatori sulle cross-prompt injection attack e può essere bloccato o troncato a runtime; inoltre chiunque abbia accesso in modifica al documento cambia il comportamento dell’agente scavalcando authoring, versioning e governance. Il grounding e la governance del prompt sono due meccanismi distinti.

Il criterio di ammissione è l’evaluation, non il gusto

Una libreria che accetta contributi «se sembrano buoni» non scala. Il gate va scritto in termini misurabili: un set di casi di test e gli evaluator di Microsoft Foundry — Groundedness e Relevance per il retrieval, Tool Call Accuracy e Intent Resolution (preview) e Task Adherence (preview) per gli agenti, i custom evaluator (preview) per criteri aziendali. Qui vanno tenute separate tre parole che i candidati confondono: testing avviene prima del rilascio, monitoring raccoglie telemetria in esercizio, evaluation verifica che l’agente faccia ancora ciò per cui è stato progettato. La guida al Center of Excellence lo dice così: «Continuous evaluation is the structured complement to ongoing monitoring». Resta obbligatoria la revisione umana prima di pubblicare, inviare a un cliente o decidere.

Attenzione al confine con la sicurezza: nessuna frase dentro il prompt è un controllo. La difesa contro il prompt injection sono i Prompt Shields, con i due tipi distinti — user prompt attacks e document attacks — configurati come guardrail sui punti di intervento user input e tool response, con lo Spotlighting (preview) come strato aggiuntivo. Altro discorso ancora sono i content filter e l’abuse monitoring.

Le tecniche che conviene standardizzare

Ciò che il CoE pubblica non è un elenco di frasi felici, ma uno schema: purpose, general guidelines, skills e, quando servono, step-by-step, gestione degli errori, esempi di interazione e glossario dei termini non standard. Si raccomandano sezioni per raggruppare, elenchi puntati per attività parallele e step numerati solo per sequenze reali; task atomici; tono, verbosità e formato di output sempre espliciti; Markdown pulito; few-shot solo negli scenari complessi. Due pattern meritano di stare nel template obbligatorio: l’output contract, che vincola forma e livello di dettaglio, e il self-evaluation gate finale. Per stabilizzare un agente che riordina i passaggi esiste l’header letterale, che inizia con «Always interpret instructions literally.».

In Copilot Studio vale la regola opposta all’accumulo: «Keep agent instructions as simple and as short as possible». Le istruzioni non modificano la logica di retrieval né il messaggio di fallback, che si cambia nella system topic Fallback; sono nome e descrizione di tool e knowledge a guidare la scelta. Infine il costo: la lunghezza dell’output è il fattore che pesa di più su latenza e spesa, l’esecuzione di un prompt è limitata a 100 secondi, e conviene partire dal modello Basic prima di salire a Standard e Premium. Vincolare con «Summarize in 50 words.» è una decisione di SLA, non di stile. E poiché i modelli sotto Microsoft 365 Copilot vengono aggiornati automaticamente — la documentazione avverte di «be prepared to adapt prompts and instructions where precision matters» — la libreria ha bisogno di una cadenza di ri-validazione, non di una data di pubblicazione.