ALM dei dati usati da modelli e agenti

Il corpus è un artefatto rilasciabile, non un allegato

Quando si progetta l’ALM di una soluzione agentica, l’errore ricorrente è trattare l’agente come il software e i dati come contorno. Il grounding data è invece un artefatto con un proprio ciclo di rilascio, e va deciso esplicitamente che cosa entra sotto controllo di versione. Non è solo il documento sorgente: sono anche la pipeline di preparazione (pulizia, normalizzazione, arricchimento, chunking), la scelta degli embedding, lo schema dell’indice e i metadati di permesso che viaggiano insieme al contenuto. La guidance del Well-Architected Framework per i carichi AI (/azure/well-architected/ai/grounding-data-design) è netta su un punto: quando si modifica un indice, le variazioni di schema vanno coordinate con gli aggiornamenti di codice, esattamente come per un database relazionale, perché un campo rimosso rompe l’applicazione che lo richiede.

Il secondo pilastro è la strategia di aggiornamento. Il framework contrappone il side-by-side deployment — si costruisce il nuovo indice accanto a quello in esercizio, lo si collauda e poi si commuta il traffico — all’in-place update, che modifica l’indice esistente risparmiando la duplicazione ma esponendo a downtime e operazioni onerose. La raccomandazione, nella maggior parte dei casi, è side-by-side: ricostruire l’indice gestisce nativamente cancellazioni e aggiornamenti e permette di ispezionare i dati prima di renderli vivi, al prezzo di una duplicazione temporanea. Come architetto devi saper motivare la scelta con un criterio, non con una preferenza: dimensione dell’indice, costo e tempo di ricostruzione, frequenza di aggiornamento richiesta, obiettivo di servizio sulla continuità.

Scenario tipico d’esame: un produttore industriale fonda un agente di manutenzione sui manuali tecnici, con revisione editoriale trimestrale ma l’obbligo contrattuale di propagare entro ventiquattr’ore una nota di sicurezza. Un solo meccanismo non basta: servono aggiornamenti pianificati per il ciclo ordinario e una procedura di aggiornamento d’emergenza per rimuovere o sostituire singoli documenti, prevista fin dalla progettazione qualunque sia la strategia di deployment scelta.

Promuovere i dati insieme all’agente, non al posto suo

Qui le tre superfici di costruzione divergono, e confonderle è l’errore che l’esame cerca. In Microsoft Copilot Studio l’ALM eredita quello di Power Platform: si lavora sempre dentro solution, si usano almeno tre ambienti (development, test, production, i primi due di tipo sandbox), si esternalizzano le impostazioni che cambiano fra ambienti in environment variables e le credenziali in connection references. Le component collection sono il veicolo pensato per il riuso: raccolgono topic, knowledge, action ed entity e si spostano fra ambienti con versioni allineate. Attenzione però alla lista degli elementi non solution-aware — impostazioni di Application Insights, autenticazione manuale, sicurezza del canale Direct Line e Web, canali pubblicati, condivisione — che richiedono passi post-deployment a valle.

Nell’estensibilità di Microsoft 365 Copilot il pattern è diverso ma la logica è la stessa: per i declarative agent il Microsoft 365 Agents Toolkit modella ambienti e versioni con file di ambiente, e l’URL del sito SharePoint che fa da knowledge finisce proprio lì, come variabile risolta al momento del provisioning. È la traduzione operativa del principio: il puntatore ai dati è configurazione, non contenuto del manifest.

In Microsoft Foundry il knowledge vive come risorsa a sé. Con Foundry IQ una knowledge base aggrega più knowledge source e parametri di retrieval, e più agenti possono condividerla; l’indicizzazione automatizza chunking, generazione degli embedding ed estrazione di metadati, e si possono pianificare esecuzioni ricorrenti dell’indexer per il refresh incrementale. Alcune funzionalità sono in disponibilità generale, altre restano in preview a seconda della versione API usata, e il portale espone in preview tutte le capacità di agentic retrieval. Conseguenza architetturale: promuovere l’agente non promuove la sua knowledge base. Vanno definiti proprietario, cadenza e criterio di promozione anche per quest’ultima, e va deciso se test punta a una copia ridotta del corpus o alla sorgente di produzione — decisione che la classificazione del dato, non la comodità, deve governare.

Quando i dati cambiano sotto un modello già in esercizio

Il terzo pezzo è la deriva. Misura la finestra fra creazione o modifica del dato in origine e sua comparsa nell’indice, e trattala come indicatore rispetto a un obiettivo di servizio: la freschezza va dimensionata sul bisogno, non massimizzata. Poi considera i permessi, che sono dati anch’essi. Nel document-level access control di Azure AI Search — funzionalità in preview con l’API REST 2026-05-01-preview — l’applicazione avviene a query time confrontando il token Entra del chiamante con i metadati di permesso già presenti nell’indice: un cambio di ACL o di appartenenza a gruppo in origine si riflette solo dopo la sincronizzazione. Per SharePoint, i permessi unici vengono ripresi in modo incrementale a ogni esecuzione riuscita dell’indexer, mentre le modifiche ereditate da un ambito superiore richiedono un refresh esplicito. Un agente perfettamente versionato può quindi restare temporaneamente troppo permissivo.

Distingui infine i tre cicli che l’esame ama sovrapporre. Il testing verifica che una build si comporti come specificato; l’evaluation misura la qualità delle risposte contro un baseline; il monitoring osserva la produzione. Un aggiornamento del corpus invalida il baseline di evaluation esattamente come lo invalida un cambio di modello, e va gestito con la stessa disciplina di migrazione. E non confondere grounding data e dati di addestramento: il fine-tuning va ripetuto quando i dati vengono aggiornati o quando esce un modello base aggiornato, mentre il corpus di grounding si ricostruisce senza toccare i pesi. Chi versiona l’agente e lascia il knowledge alla deriva ha fatto metà del lavoro.