Un assistente interno risponde a una domanda su un contratto. La risposta è corretta, pertinente, con la citazione del documento da cui viene. Il problema è che la persona che ha fatto la domanda, se aprisse SharePoint a mano, quel documento non lo troverebbe: non ha i permessi per vederlo.
Non è un’allucinazione del modello. Il modello ha fatto esattamente il suo lavoro su ciò che gli è stato passato. È il passaggio precedente ad essere sbagliato: il retrieval ha interrogato l’indice con i permessi di chi lo ha costruito, non con quelli di chi ha posto la domanda.
Perché le valutazioni non lo vedono
Questa è la parte che rende il difetto insidioso, e non è una disattenzione di chi ha fatto i test.
Un set di valutazione per un sistema RAG misura la pertinenza della risposta, la sua aderenza alle fonti, la completezza, a volte il tono. Nessuna di queste dimensioni contiene l’identità di chi ha fatto la domanda. Un set di valutazione che non ha una dimensione di identità non può far fallire un difetto di autorizzazione, per alto che sia il punteggio di aderenza alle fonti — è la formulazione che abbiamo dato a VentureBeat, e resta il modo più compatto di dirlo.
La conseguenza pratica è che il difetto sopravvive a tutta la fase di collaudo con il punteggio pieno. Non c’è nessun segnale rosso da leggere, perché la metrica che si sta guardando risponde a un’altra domanda.
Il nostro caso, e come è emerso
Abbiamo costruito un assistente email su Azure OpenAI che legge la nostra documentazione su SharePoint e prepara le risposte ai clienti. Auto-risolve circa il 60% delle email in ingresso.
La pipeline di retrieval era custom, e questa è la scelta che ha creato il problema: passando da un percorso costruito da noi, scavalcava il livello nativo di controllo degli accessi. L’indice veniva interrogato con l’identità del processo di indicizzazione — che per costruzione vede tutto ciò che deve indicizzare — invece che con quella dell’utente che stava chiedendo.
Ha passato tutte le valutazioni. L’abbiamo trovato nei nostri log, non in un incidente: nessun dato è uscito verso l’esterno, e non c’è stata alcuna esfiltrazione. È emerso da un controllo interno in cui abbiamo confrontato ciò che l’assistente restituiva a due account con privilegi diversi.
La vicenda è stata raccontata da Louis Columbus su VentureBeat il 1° settembre 2026, e una settimana prima nel pezzo sui confini di autorizzazione degli agenti AI.
Il test che lo scopre, e costa mezz’ora
È la parte più utile di questo articolo, perché non richiede strumenti, licenze o competenze specialistiche. Serve un secondo account.
1. Prendete le domande già fatte. Non inventatene di nuove: usate quelle che un account con privilegi ampi — un amministratore, un responsabile — ha già posto all’assistente. Ne bastano dieci, scelte fra quelle che hanno prodotto risposte ricche di dettagli.
2. Riponetele identiche da un account a privilegi ridotti. Un utente normale, meglio se di una funzione che non c’entra con l’argomento. Stesse domande, stesso testo.
3. Confrontate con ciò a cui quell’account arriva davvero. Non con la risposta dell’altro account: con quello che l’utente trova aprendo SharePoint a mano e cercando. È il confronto che conta, e l’unico che dimostra qualcosa.
4. Cercate le tracce indirette. Il caso ovvio è la citazione di un file che l’utente non può aprire. Ma il difetto si manifesta anche in forme più sottili: un riassunto che contiene un dato presente solo in un documento riservato, un elenco di clienti più lungo di quello che l’utente vedrebbe, una cifra corretta senza un documento accessibile che la contenga. Un dato senza una fonte che l’utente possa raggiungere è il sintomo, anche quando nessun nome di file compare nella risposta.
Se qualcosa non torna, il retrieval non sta usando l’identità di chi chiede.
Che cosa offre davvero Azure AI Search
Qui la documentazione va letta con attenzione, perché la risposta breve — «usa l’ACL trimming nativo» — è incompleta per la produzione.
Alla data della pagina Microsoft (8 agosto 2026, documentazione dell’API 2026-08-01-preview) esistono quattro approcci al controllo d’accesso a livello di documento, e uno solo è generalmente disponibile:
| Approccio | Stato | Come funziona |
|---|---|---|
| Security filter | Generalmente disponibile | Confronto di stringhe: l’applicazione passa l’identità del chiamante, che popola un filtro sulla query. Indipendente dalla versione di API |
| ACL e scope RBAC nativi | Preview | Token Entra confrontato con i metadati di permesso. Vale per Azure Data Lake Storage Gen2 e i blob |
| Etichette di riservatezza Purview | Preview | L’indexer estrae le etichette; valutate al momento della query contro le politiche Purview |
| ACL di SharePoint in Microsoft 365 | Preview | L’indexer estrae i metadati di permesso da SharePoint e li usa nei controlli a query-time |
Il meccanismo nativo funziona così: si allega il token dell’utente alla richiesta nell’header x-ms-query-source-authorization, il servizio estrae dalle sue rivendicazioni utente, gruppi e scope, li confronta con i metadati di permesso presenti nell’indice e restituisce solo i documenti autorizzati.
Due letture pratiche di questa tabella.
Se indicizzate SharePoint e volete la via nativa, state portando in produzione una preview. È una scelta legittima — molte aziende lo fanno con cognizione — ma va fatta sapendo cosa si sta firmando, non credendo di usare una funzione consolidata.
La via generalmente disponibile è un filtro. Ed è esattamente quello che abbiamo applicato: si recupera l’identità di chi sta chiedendo, si passa come stringa di filtro alla query, e i risultati escludono tutto ciò che non corrisponde. Non serve una nuova piattaforma di identità: l’identità era già in Entra ID, mancava il passaggio che la usava.
La trappola che non viene raccontata: la sincronizzazione
Supponiamo che abbiate risolto e che i permessi vengano applicati al momento della query. Resta un secondo problema, e in un’azienda vera si manifesta più spesso del primo.
L’applicazione dei permessi al momento della query valuta i metadati già presenti nell’indice. La documentazione Microsoft è esplicita: le modifiche ai permessi nel sistema di origine si riflettono nei risultati di ricerca solo dopo che quei metadati sono stati sincronizzati nell’indice.
Tradotto in un caso concreto: revocate a una persona l’accesso a una raccolta documenti. Da quel momento, in SharePoint, non ci entra più. Ma l’assistente continua a poter usare quei documenti per lei finché la sincronizzazione non è passata.
E per SharePoint c’è una distinzione che vale la pena scriversi da qualche parte:
- le modifiche ai permessi su elementi con permessi unici vengono raccolte in modo incrementale a ogni esecuzione riuscita dell’indexer;
- le modifiche ereditate da un livello superiore — sito, raccolta, elenco, cartella — richiedono un aggiornamento esplicito.
Il secondo caso è quello che capita più spesso nella pratica, perché nelle aziende i permessi si gestiscono sui contenitori, non sui singoli file. Il risultato è che la revoca fatta «bene», a livello di cartella, è proprio quella che l’indice recepisce più tardi.
La domanda operativa non è quindi «abbiamo il trimming attivo», ma: quanto dura la finestra fra una revoca e il momento in cui l’assistente la rispetta, e quella finestra è accettabile per i dati che stiamo indicizzando? La risposta la decide la pianificazione del vostro indexer, ed è un numero che dovreste conoscere.
Cosa non risolve, anche fatto bene
Il security trimming filtra i documenti in base ai permessi. Fa quello, e va detto anche cosa non fa.
Non risolve i permessi troppo larghi alla fonte. Se una cartella è condivisa con tutta l’azienda, il trimming la mostrerà correttamente a tutti, perché quello è il permesso reale. Un assistente che pesca da un tenant con condivisioni disordinate espone il disordine con la massima efficienza: è lo stesso problema che rende un rollout di Copilot un momento di verità sui permessi, e non un problema di AI.
Non risolve la cronologia. Le risposte generate prima della correzione sono già state lette, e magari inoltrate.
Non risolve il perimetro. Un assistente che indicizza tutto il tenant, dopo la correzione, resta un assistente che indicizza tutto il tenant — con i permessi giusti. Restringere ciò che l’assistente può vedere è una decisione separata, e nel nostro caso l’abbiamo presa insieme al filtro.
Il costo in qualità: zero, nel nostro caso
È la domanda che si fa chiunque debba decidere: se filtro i risultati per permessi, l’assistente diventa più stupido?
Nel nostro impianto l’auto-risoluzione è rimasta al 60% con il filtro attivo. Non è un dato generalizzabile — dipende da quanto i vostri documenti utili siano già accessibili a chi fa le domande — ma è un’indicazione utile: se le persone chiedono cose che rientrano nel loro lavoro, i documenti che servono a rispondere sono in genere documenti a cui hanno diritto. Il filtro toglie ciò che non avrebbero dovuto vedere, e quello serviva a rispondere molto meno spesso di quanto si teme.
Cosa faremmo, al vostro posto
Fate il test dei due account questa settimana. È mezz’ora e non richiede nulla. Se avete un assistente in produzione che pesca da SharePoint, è la cosa a più alto rendimento che potete fare oggi.
Guardate come è costruita la pipeline di retrieval, non solo il modello. La domanda da fare a chi l’ha costruita è una: con quale identità viene interrogato l’indice? Se la risposta è «con quella del servizio» o «con quella dell’indexer», il resto della conversazione è già scritto.
Misurate la finestra di sincronizzazione. Quanto passa fra una revoca su una cartella e il momento in cui l’indice la recepisce? Se non lo sapete, è un numero che va scoperto prima che lo scopra un cliente.
Decidete il perimetro invece di ereditarlo. Un assistente che vede meno è un assistente che sbaglia meno, e le risposte che perde sono quasi sempre quelle che non doveva dare.
Se volete che guardiamo il vostro impianto, il servizio si chiama RAG e Document Intelligence su Azure AI e in quei progetti il security trimming è incluso sempre — non come opzione, perché questo articolo racconta cosa succede senza. Se invece siete prima del rollout, il punto di partenza è l’AI Readiness Assessment.
Domande frequenti
Come faccio a sapere se il mio assistente ha questo problema?
Con un test che richiede mezz’ora e nessuno strumento. Prendete le domande che un account con privilegi ampi ha già posto all’assistente e riponetele identiche da un account con privilegi ridotti. Poi confrontate le risposte con ciò a cui quell’account arriva davvero aprendo SharePoint a mano. Se l’assistente cita, riassume o parafrasa un contenuto che l’utente non riesce ad aprire da solo, il retrieval non sta usando la sua identità. È un confronto fra due output, non un test di penetrazione.
Le valutazioni di qualità del modello non dovrebbero accorgersene?
Non possono, ed è un limite strutturale e non una disattenzione. Un set di valutazione misura se la risposta è pertinente, fondata sulle fonti, completa. Nessuna di queste dimensioni contiene l’identità di chi ha fatto la domanda: se la valutazione non ha una dimensione di identità, non può far fallire un difetto di autorizzazione, per alto che sia il punteggio di aderenza alle fonti. La risposta è corretta. È il destinatario a non avere diritto al dato.
Basta attivare l’ACL trimming nativo di Azure AI Search?
Dipende da dove stanno i documenti, e la risposta va letta con attenzione. Azure AI Search offre quattro approcci al controllo d’accesso a livello di documento, ma alla data della documentazione Microsoft (8 agosto 2026, API 2026-08-01-preview) solo i security filter sono generalmente disponibili: sono un confronto di stringhe, in cui l’applicazione passa l’identità del chiamante e quella popola un filtro sulla query. Gli ACL e gli scope RBAC nativi, le etichette di riservatezza di Purview e gli ACL di SharePoint in Microsoft 365 sono tutti in preview. Chi indicizza SharePoint e vuole la via nativa deve sapere che sta portando in produzione una preview.
Se revoco un permesso in SharePoint, l’assistente smette subito di mostrare quel documento?
No, e questa è la trappola meno raccontata. L’applicazione dei permessi al momento della query valuta i metadati già sincronizzati nell’indice: la documentazione Microsoft dice che le modifiche ai permessi nel sistema di origine si riflettono nei risultati solo dopo che quei metadati sono stati sincronizzati. Per SharePoint le modifiche agli elementi con permessi unici vengono raccolte in modo incrementale a ogni esecuzione dell’indexer, mentre le modifiche ereditate da sito, raccolta, elenco o cartella richiedono un aggiornamento esplicito. Tradotto: fra la revoca e il momento in cui l’assistente la rispetta c’è una finestra, e la sua durata la decide la vostra pianificazione dell’indexer.
Il security trimming risolve tutto?
No, e conviene sapere cosa lascia fuori. Filtra i documenti in base ai permessi, quindi risolve il caso «l’utente vede un file che non gli spetta». Non risolve i documenti con permessi troppo larghi alla fonte: se una cartella è condivisa con tutta l’azienda, il trimming la mostra correttamente a tutti, perché quello è il permesso reale. Non risolve la cronologia già prodotta: le risposte generate prima della correzione restano dove sono finite. E non risolve il perimetro: un assistente che indicizza tutto il tenant resta un assistente che indicizza tutto il tenant, con i permessi giusti.
Serve una nuova piattaforma di identità per correggerlo?
Nel nostro caso no, e vale la pena dirlo perché la reazione istintiva davanti a un problema di autorizzazione è comprare un prodotto di identità. È servito un filtro applicato al momento della query, che verifica i permessi di chi sta chiedendo prima che il modello veda il contenuto, più una riduzione del perimetro dell’assistente. L’identità era già in Entra ID: il problema era che la pipeline di retrieval non la stava usando.
Fonti. Microsoft Learn, Document-Level Access Control — Azure AI Search, pagina aggiornata l’8 agosto 2026 (documentazione dell’API 2026-08-01-preview): approcci disponibili, stato di anteprima, applicazione dei permessi al momento della query e sincronizzazione dei metadati. Per il nostro caso: Louis Columbus, VentureBeat, 1° settembre 2026 e 26 agosto 2026. Il dato del 60% di auto-risoluzione è nostro, misurato sul nostro impianto, e si riferisce alle email in ingresso della nostra assistenza. Le date e lo stato delle funzioni Azure sono quelli verificati il 2 settembre 2026: trattandosi in gran parte di anteprime, vanno riverificati sulla documentazione prima di una scelta architetturale.