Valutazione, monitoraggio e testing non sono la stessa attività

Prima di raccomandare uno strumento, decidi quale delle tre attività risponde alla domanda che hai davanti, perché hanno momenti, artefatti e proprietari diversi.

Il testing precede il rilascio e lavora su casi definiti a tavolino. La documentazione di estensibilità di Microsoft 365 Copilot ne descrive il vocabolario: test case, test set, prompt, assertion, quality signal, grader e grounding data, con una guida di copertura che sale da 20-50 casi in prototipo a oltre 100 in produzione e un obiettivo di pass rate fra 80% e 90%, mentre i test di regressione dovrebbero avvicinarsi al 100%. La stessa pagina è esplicita nel dire che la valutazione non sostituisce le responsible AI review, la content moderation, i security test sul prompt injection, la user research e i performance test.

La evaluation misura la qualità con evaluator dedicati. Microsoft Foundry offre built-in evaluator di qualità generale (coherence, fluency), specifici per RAG (groundedness, relevance), di sicurezza (hate/unfairness, violence, protected materials) e specifici per agenti (tool call accuracy, task completion), più custom evaluator per il dominio.

Il monitoring osserva ciò che accade in esercizio: token, latenza, errori, alert. Accanto vive il tracing, che ricostruisce la singola esecuzione in span e attribute secondo le semantic convention OpenTelemetry per il generative AI; in Foundry il tracing è generally available per prompt agent e hosted agent, mentre workflow ed external agent sono in preview.

Dove si guarda una flotta eterogenea

Uno scenario tipico: un gruppo industriale ha agenti low-code in Microsoft Copilot Studio, declarative agent pubblicati in Microsoft 365 Copilot, agenti SharePoint creati dai team e agenti custom sul Microsoft Foundry Agents service. Il vincolo posto dal CIO è che nessun agente resti senza owner e che esista una vista di flotta. Non esiste un unico vetro che copra tutto: la raccomandazione corretta mappa ogni superficie sulla console che la governa.

Foundry Control Plane è la vista di flotta per gli agenti su Azure: scopre gli agenti a cui hai accesso, aggrega log e metriche dalle risorse Application Insights collegate e mostra in Operate il pannello Overview con health score, riepilogo degli alert e metriche di conformità, mentre Assets apre la scheda Agents e, per il singolo agente, i riquadri Active alerts e Activity. Copre agenti Foundry (prompt-based, workflow, hosted), Azure SRE Agent, agent loop di Azure Logic Apps e agenti custom registrati a mano. Due vincoli architetturali da ricordare: la capability esiste solo nel portale Foundry (new), e gli agenti che girano su risorse senza Application Insights restano privi di metriche di salute, tracking dei costi e drill-down. Servono inoltre il ruolo Log Analytics Reader sulla risorsa Application Insights e Cost Management Reader per vedere i costi.

Sul versante Power Platform, la Copilot Studio agent inventory dà a IT e sicurezza l’elenco degli agenti creati con Copilot Studio o Agent Builder nel tenant, bozze incluse, con campi come orchestration (Classic o Generative), channels, condivisioni e stato di quarantena; si consuma da Power Platform admin center, Power Platform API o Azure Resource Graph. Attenzione: riflette la versione pubblicata, si aggiorna di norma entro venti minuti e non include gli agenti V1 (classic bot). Per la qualità delle conversazioni, Copilot Studio scrive i log nella tabella ConversationTranscript di Microsoft Dataverse, e l’architettura di riferimento li fa elaborare da un cloud flow di Power Automate con AI Builder per sentiment, temi e riassunti, riportandoli in Dataverse e su un dashboard Power BI. A livello di tenant, Microsoft Purview registra in Audit gli eventi di authoring e l’evento CopilotInteraction: l’audit contiene solo l’ID del thread di trascrizione, il testo si recupera da DSPM for AI. Per gli agenti SharePoint valgono invece l’Agent Insights report di SharePoint Advanced Management e Microsoft Cost Management per la spesa.

Metriche e cadenza

L’Agent Monitoring Dashboard, nella scheda Monitor dell’agente, espone token usage, latency, run success rate, i punteggi degli evaluator sui campioni e gli esiti delle red team scan. La documentazione fornisce due soglie di lettura utili come ancoraggio: una latenza sopra i dieci secondi suggerisce throttling del modello, tool call complesse o problemi di rete, e un run success rate sotto il 95% merita indagine.

La cadenza è una scelta di design, non un dettaglio. Continuous evaluation campiona il traffico vivo al completamento delle risposte, con sampling Random o Intelligent e un limite orario di run (cento per impostazione predefinita); scheduled evaluation rilancia periodicamente un golden dataset ed è lo strumento giusto per intercettare la deriva dopo un aggiornamento delle knowledge source. Alert, recurring evaluation e red team scan sono in preview. Il Center of Excellence completa il quadro con le fasi Monitor e Improve del ciclo di vita e con l’idea che un agente senza owner e senza piano di monitoraggio accumula rischio. Dove serve supervisione umana, l’agent feed dei model-driven app (preview) raccoglie le attività in Needs Attention e Completed con un insights panel su 7, 14 o 30 giorni.

Che cosa verifica l’esame

L’esame propone sintomi e chiede lo strumento. Se un dashboard è vuoto, la risposta è quasi sempre architetturale: manca la connessione ad Application Insights o mancano i permessi su Log Analytics, non serve un nuovo alert. Se la qualità peggiora dopo un cambio di knowledge source, la risposta è una scheduled evaluation su dataset di riferimento, non più telemetria. E non confondere il monitoraggio con il content filter o con l’abuse monitoring: quelli intervengono sul contenuto, non misurano l’esercizio.