Proporre agenti Microsoft 365: si sceglie la superficie, non la funzionalità
Un gruppo manifatturiero vuole un assistente per il service desk interno: deve rispondere sulle procedure pubblicate in SharePoint, senza far uscire dati dal tenant e senza budget per hosting aggiuntivo. La proposta non parte dalle funzionalità: parte dalla scelta fra declarative agent e custom engine agent, che fissa costi, conformità e canali.
Un declarative agent riusa orchestrator, foundation model e infrastruttura di Microsoft 365 Copilot: tu fornisci instructions, knowledge e actions, e l’agente eredita sicurezza, compliance e responsible AI della piattaforma. Un custom engine agent porta orchestrator e modelli propri, richiede hosting fuori da Microsoft 365 e sposta su di te l’onere della conformità. Altri discriminanti: i declarative agent sono pensati per l’uso individuale e non supportano interazioni proattive; i custom engine agent reggono collaborazione di gruppo, trigger automatici, canali esterni e comunicazione agent-to-agent. Con quei vincoli la risposta è declarative.
Non confondere l’agente con lo strumento che lo costruisce: Agent Builder, SharePoint, Microsoft 365 Agents Toolkit e Microsoft Copilot Studio producono declarative agent, ma solo gli ultimi due anche custom engine agent. Gli agents in SharePoint non richiedono attivazione: compaiono per chi ha licenza Copilot o dove sia predisposto il billing pay-as-you-go tramite una risorsa Azure, e si monitorano con l’audit log di Microsoft Purview. Il piano di governo resta uno: nel Copilot Control System dentro il Microsoft 365 admin center decidi chi accede agli agenti (All users, No users oppure utenti e gruppi specifici), se ammettere agenti di Microsoft, di publisher esterni o interni, e approvi quelli che i maker pubblicano da Copilot Studio prima che entrino nel catalogo organizzativo.
Copilot for Sales e for Service: si orchestra una configurazione
Microsoft 365 Copilot for Sales non si costruisce, si affianca al CRM esistente. Supporta Dynamics 365 Sales e Salesforce, non è disponibile su Dynamics 365 Customer Engagement (on-premises) e non supporta più tenant. Prima trappola: la documentazione lo chiama ormai Sales agent pur restando sotto il percorso /microsoft-sales-copilot/. Nomi diversi, prodotto unico, come per Microsoft Foundry.
Orchestrarne la configurazione significa mettere in fila azioni in console diverse: installazione come integrated app dal Microsoft 365 admin center; setup policy nel Teams admin center; attivazione di Transcription nelle Meeting policies, altrimenti il riepilogo delle riunioni non esiste; server-side synchronization di email e appuntamenti, altrimenti le attività di Outlook non si salvano nel CRM; security role adeguati, che per Salesforce vanno sul profilo utente e non su un permission set. Le impostazioni si dividono in tenant-level (Copilot AI, Collaboration spaces) ed environment-level (Access settings, Forms, Custom AI instructions), più le Features Sales Chat, Meeting insights e Lead Research and Outreach (preview).
Qui cade la distinzione da tenere ferma per tutto l’esame. I synonyms che mappano il lessico aziendale sulle colonne del CRM si aggiungono in Copilot Studio, dentro l’agente Copilot in Dynamics 365 Sales, e valgono per entrambe le superfici. Copilot in Dynamics 365 Sales è una funzionalità dell’app; Copilot for Sales è un prodotto Microsoft 365 che vi si appoggia. Sul versante service la simmetria è identica: in un contact center che conserva CRM e CCaaS esistenti, Microsoft 365 Copilot for Service si incorpora nel CRM di terze parti e porta riassunti dei case, bozze di email e knowledge chat, mentre Copilot Studio gestisce dialogo self-service e IVR. Il Copilot in Dynamics 365 Customer Service si abilita invece dal Power Platform admin center con Enable AI-powered Copilot features e si configura nel Copilot Service admin center, dove vivono Copilot immersive, Copilot side pane e l’agente Admin Management (preview).
Power Platform: due cose diverse si chiamano AI hub
AI Builder è la componente AI di Power Platform e si raggiunge da Power Apps o Power Automate sotto More, poi AI hub e AI models. Il criterio di proposta è dichiarato: modelli prebuilt per scenari comuni a più aziende (receipt processing, invoice processing, ID reader), modelli custom quando i dati sono unici del business (document processing, prediction, object detection). Alcuni sono in preview, fra cui text generation e Image Description.
Le domande architetturali riguardano il ciclo di vita e il perimetro di controllo, non il modello: ogni environment deve avere un database Dataverse, i modelli si spostano fra sviluppo, test e produzione come componenti di una solution, e dopo un restore alcune categorie vanno ritrainate. Il consumo passa per gli AI Builder credits; ai fini delle policy di data loss prevention AI Builder ricade nel connettore Dataverse; gli interruttori Preview and experimental AI models e AI prompts esistono a livello di environment e come regola di environment group, e una regola pubblicata blocca l’impostazione al system administrator del singolo environment. È la risposta giusta quando il vincolo vieta modelli sperimentali nelle unità regolamentate.
Attenzione all’omonimia. Il Dynamics 365 AI Hub, raggiungibile dalla Sales Hub app in App Settings, è un’altra superficie: ospita Agent manager e AI optimization hub per governare agenti di vendita come Sales Qualification Agent e Sales Opportunity Agent. Rispondere “AI hub” senza dire quale significa perdere il punto.
Che cosa verifica l’esame
Le domande di questo gruppo sono di attribuzione: dato uno scenario e un vincolo, quale prodotto pronto lo copre senza costruire nulla e in quali console se ne orchestra la configurazione. I distrattori sono plausibili: un declarative agent dove serve un trigger autonomo, o Copilot in Dynamics 365 Sales dove il venditore lavora in Outlook su un CRM Salesforce.