Il «no» è una decisione di architettura

La prima domanda di un progetto agentico non è quale modello scegliere né su quale superficie costruire, ma se un agente serva davvero. Il Cloud Adoption Framework mette questa verifica prima di tutte, con una sezione intitolata When not to use AI agents: se i passi sono chiari, ripetibili e governati da regole rigide, la raccomandazione è usare «regular code or nongenerative AI models», perché su un flusso fisso sono più veloci, più economici e più affidabili. Stesso verdetto per il recupero di conoscenza statica: se l’obiettivo è rispondere su un corpus documentale fermo, senza strumenti né ragionamento multi-passo, basta un pattern RAG classico e l’agente è complessità gratuita.

L’agente si giustifica su tre condizioni documentate: quando il compito richiede decisioni multi-passo (leggere, valutare, scegliere il passo successivo, controllare il proprio lavoro), quando usa molti strumenti o sistemi chiamandoli in ordine flessibile, e quando serve comportamento adattivo su input incompleti o ambigui. Fuori da lì il costo cresce e la determinatezza cala.

Un caso concreto: una manifattura chiede un agente che calcoli lo scaglione di sconto contrattuale. Input strutturati, regola pubblicata, e il vincolo esplicito è che a parità di input l’esito deve essere identico, perché finisce in un ordine di vendita. La risposta corretta è codice o una regola in un agent flow di Microsoft Copilot Studio, non un modello generativo: introdurre non-determinismo dove il business pretende determinismo è un difetto di progetto.

Valutare le tre famiglie di impiego separatamente

Automazione di task. Molti processi «da automatizzare con l’AI» non chiedono ragionamento ma estrazione o classificazione. Per fatture, ricevute, documenti d’identità e contratti esistono modelli prebuilt in AI Builder; per documenti propri dell’azienda si addestra un modello custom. La regola dichiarata è che i modelli custom servono per dati unici del proprio business e i prebuilt per scenari comuni a più aziende. Un agente resta utile solo se, dopo l’estrazione, occorre decidere fra percorsi diversi.

Analisi dei dati. Qui l’errore ricorrente è chiedere all’agente ciò che deve dare un modello semantico governato. Il piano dati del CAF colloca i dati certificati in Microsoft Fabric OneLake e li fa consumare tramite Fabric IQ, i Fabric data agents e Foundry IQ in Microsoft Foundry, proprio per preservare governance e confini di sicurezza. Se il vincolo del CFO è che la stessa domanda produca lo stesso numero in due sessioni, la cifra deve nascere da una misura, non da una sintesi libera; l’agente può interpretarne la richiesta e commentarla.

Supporto alle decisioni. Un agente propone, una persona decide, quando l’azione è ad alto impatto. La guida sugli autonomous agents di Copilot Studio è esplicita nel richiedere approvazione umana per le azioni sensibili, ambito ristretto e privilegio minimo. Attenzione a dichiarare sempre di che cosa si parla: un agente che agisce solo quando qualcuno scrive è cosa diversa da uno che parte da un trigger su evento senza attendere un prompt utente.

Rivedere i dati di grounding lungo cinque assi

Poiché gli agenti sintetizzano informazioni invece di crearle, la loro accuratezza dipende interamente dalla qualità e dall’accessibilità delle fonti. Vale il principio che la doc cita testualmente, “garbage in, garbage out.”

  • Accuratezza: la fonte è autorevole e riconosciuta come tale, o è una copia divergente? Un agente sopra due verità contraddittorie non le concilia, ne pesca una.
  • Rilevanza: il Well-Architected Framework chiede di anticipare le domande attese e progettare l’indice per la massima rilevanza, scegliendo campi ricercabili, filtrabili e ordinabili in funzione di quelle domande.
  • Tempestività: si misura la finestra fra creazione o modifica del dato all’origine e sua comparsa nell’indice, e la si confronta con un obiettivo di servizio; l’indice va aggiornato per evitare inferenza su dati stantii, ma deve essere fresco solo quanto serve.
  • Pulizia: la strategia di ingestione rimuove rumore e duplicati, sana le incongruenze e standardizza su uno schema comune, rispettando le etichette di classificazione applicate all’origine.
  • Disponibilità: non basta che il dato esista. Va valutato se sia raggiungibile al momento dell’inferenza e sotto quale identità: il security trimming garantisce che l’utente veda solo ciò cui è autorizzato anche su un indice condiviso, ed esternalizzare su un indice di ricerca evita di caricare il sistema sorgente.

Che cosa verifica l’esame

AB-100 formula queste domande come scelte fra alternative tutte plausibili, con un vincolo che decide. Aspettati di dover rifiutare l’agente in almeno uno scenario. Le confusioni più costose: RAG deterministico contro agente, che decide a ogni passo quali conoscenze e strumenti usare e per questo introduce comportamento non deterministico da testare e governare; le etichette delle categorie di agente, che cambiano da pagina a pagina (il CAF parla di agenti di produttività, azione e automazione; Microsoft Foundry distingue il prompt agent dichiarativo dallo hosted agent full-code) mentre il criterio resta il grado di autonomia; e la scelta fra singolo agente e sistema multi-agente, dove si parte dal singolo salvo confini di sicurezza e conformità, più team coinvolti o crescita già pianificata.

Una nota pratica: AB-100 si sostiene con un solo esame, con soglia 700, ma la credenziale richiede anche una certificazione Associate attiva fra quelle qualificanti. Infine, il lessico: il blueprint usa i nomi nuovi (Microsoft Foundry, Foundry Tools, Microsoft Foundry Agents service), mentre parte della documentazione vive ancora sotto percorsi con i nomi precedenti. È lo stesso prodotto, non due.