Il dato nasce per un agente e deve servirne dieci

Il primo agente va in produzione e ha bisogno delle procedure di reso: il maker le carica come knowledge source e funziona. Diciotto mesi dopo gli agenti sono nove, sei hanno una copia delle stesse procedure, tre le hanno disallineate e nessuno sa dire quale versione abbia risposto al cliente. Non è un errore di configurazione, è un errore di livello: la domanda dell’architetto non è «quale knowledge source collego a questo agente», ma «dove vive questo contenuto perché qualunque sistema AI autorizzato possa recuperarlo».

Ognuna delle tre superfici di costruzione ha un punto di condivisione diverso, e vanno tenuti distinti. In Microsoft 365 il punto è Microsoft Graph: i Microsoft 365 Copilot connectors (già Microsoft Graph connectors) ingeriscono contenuto esterno dentro Graph, dove viene indicizzato semanticamente e diventa disponibile a Microsoft 365 Copilot, a Microsoft Search, a Copilot in Excel e al Researcher agent, non a un singolo agente. In Microsoft Foundry il punto è Foundry IQ: una knowledge base che aggrega più knowledge source e che più agenti possono condividere, interrogata tramite agentic retrieval; parte delle sue funzionalità è generalmente disponibile, parte resta in preview. In Microsoft Copilot Studio una knowledge source configurata sull’agente resta di quell’agente: per condividere si punta a Dataverse, a SharePoint, ai Copilot connectors già indicizzati da Microsoft Search, oppure si collega una knowledge base di Foundry IQ attraverso un agente di Foundry (preview).

Sincronizzare, federare o chiamare

L’ingestione non è un dettaglio implementativo: decide che cosa il contenuto potrà fare. I Copilot connectors esistono in due modelli. Un synced connector copia il contenuto in Microsoft Graph come externalItem, secondo uno schema che va registrato prima di caricare, e in cambio ottiene l’indicizzazione semantica. Un federated connector lo recupera in tempo reale via Model Context Protocol (MCP) senza spostare nulla, e proprio per questo non ha indicizzazione semantica.

Il vincolo del cliente decide. Una casa farmaceutica che non può duplicare i verbali di deviazione fuori dal QMS validato sceglie la via federata e rinuncia alle ricerche per prossimità semantica; una società di servizi che vuole ogni report trovabile anche da chi non ne conosce il titolo sceglie il synced connector e accetta il consumo di item quota. Il Cloud Adoption Framework raccomanda di partire dalle capacità di retrieval integrate come standard predefinito — Foundry IQ, Fabric IQ, la connessione SharePoint, Azure AI Search, gli indexer su OneLake — e di riservare MCP ai casi in cui l’agente deve compiere azioni o leggere dati vivi, come la giacenza di uno SKU. Chiede anche un artefatto che gli architetti dimenticano: la tabella dei domini di dato con il metodo di retrieval scelto per ciascuno e il perché.

Sul lato indice valgono le raccomandazioni del Well-Architected Framework per i grounding data: esternalizzare in un search index invece di interrogare il sistema di origine, ripulire duplicati e rumore in ingestione, valutare se un indice unico o più indici servano meglio pubblici diversi, aggiornare con deployment side-by-side.

I permessi devono viaggiare con il dato

Rendere disponibile un contenuto significa replicarne anche l’autorizzazione, non solo il testo.

Con i Copilot connectors i permessi si esprimono come ACL sull’externalItem, con voci grant o deny riferite a utenti e gruppi Microsoft Entra. Quando la sorgente usa costrutti che in Entra non esistono — profili Salesforce, business unit di Dynamics 365, gruppi locali di ServiceNow o Confluence, gruppi di SharePoint — si creano externalGroup dentro la connessione e li si usa nelle ACL, con l’onere permanente di tenerne allineata la membership. Attenzione a un default che si paga caro: una connessione distribuita vale per l’intero tenant se non si restringe la sicurezza sugli external item.

In Azure AI Search, l’infrastruttura sotto Foundry IQ, il controllo a livello di documento ha quattro strade: i security filter basati su confronto di stringhe, generalmente disponibili e indipendenti dall’API; le ACL POSIX e gli RBAC scope nativi per ADLS Gen2 e Blob; le sensitivity label di Microsoft Purview; le ACL di SharePoint in Microsoft 365. Le ultime tre sono in preview. Il meccanismo è lo stesso: si abilita il permission filter sull’indice, si scrivono i metadati di permesso accanto al contenuto e a query time si passa il token dell’utente nell’header x-ms-query-source-authorization; il servizio verifica sia il ruolo dell’applicazione chiamante sia le identità dell’utente sui documenti. Tre conseguenze da saper enunciare: i permessi valgono quanto è fresca la sincronizzazione, perché una revoca in origine si vede solo dopo un nuovo giro di indexer, un push o un refresh; se la valutazione delle ACL fallisce il servizio risponde 5xx e non restituisce un risultato parzialmente filtrato, quindi chiude anziché perdere; e se lo skillset spezza i documenti in chunk, i campi di permesso e le label vanno proiettati su ogni riga di chunk, altrimenti i riferimenti a livello di chunk non vengono filtrati.

Che cosa verifica l’esame su questo punto

Il verbo del sotto-obiettivo è organize, non configure: se lo scenario dice «other AI systems» e la tua risposta è «lo aggiungo come knowledge source dell’agente», hai risolto per un agente solo. Tieni separati i tre piani che i distrattori mescolano di continuo: l’ingestione decide dove vive il contenuto, l’autorizzazione decide chi lo recupera, la governance con Microsoft Purview — DSPM for AI, classificazione, audit unificato, retention sulle interazioni — documenta e limita l’uso ma non sostituisce l’ACL che esclude il documento durante il retrieval. E qualifica sempre lo stato: proporre una capacità in preview a un carico regolamentato è una raccomandazione diversa dal proporne una generalmente disponibile.