Le data policy governano capacità di prodotto, non solo dati

Un amministratore non approva i singoli agenti uno per uno: definisce in anticipo il perimetro di ciò che i maker possono costruire e pubblicare. Lo strumento è la data policy di Power Platform, che si configura nel Power Platform admin center sotto Security > Data and privacy > Data policy. Dentro una policy ogni connettore va classificato in uno di tre gruppi — Business, Non-business, Blocked — e i dati non possono essere condivisi fra connettori che stanno in gruppi diversi. L’ambito si sceglie nella pagina Define scope, con le opzioni Add all environments, Add multiple environments ed Exclude certain environments; la prima applica la policy anche agli environment creati in futuro.

Il punto che confonde di più è la parola “connettore”. Nell’elenco non ci sono soltanto i connettori Power Platform verso sorgenti dati: ci sono anche voci che rappresentano capacità di prodotto di Copilot Studio, e si spengono con lo stesso meccanismo. La documentazione avverte che i connettori introdotti dopo il 2019 — fra cui Chat without Microsoft Entra ID authentication in Copilot Studio e Direct Line channels in Copilot Studio — finiscono probabilmente nel gruppo di default “Non-business”, che in molte organizzazioni è bloccato per convenzione: un divieto può quindi essere già attivo senza che nessuno lo abbia deciso esplicitamente. Nota che i Copilot connectors di Microsoft 365 Copilot sono un oggetto diverso ancora, e i custom connector rientrano fra i connettori Power Platform.

Quale connettore chiude quale porta

  • Chat without Microsoft Entra ID authentication in Copilot Studio: impedisce ai maker di pubblicare agenti che non richiedono autenticazione. Dopo il blocco restano soltanto Authenticate with Microsoft e Authenticate manually, e nella pagina Authentication dell’agente l’opzione No authentication (assieme ad alcune opzioni manuali) non è più selezionabile. La policy non riscrive la configurazione dell’agente: gli sottrae una scelta.
  • Direct Line channels in Copilot Studio: blocca la pubblicazione sui canali basati su Direct Line, ovvero Demo website, siti custom, Mobile App e gli altri canali Direct Line. Gli altri canali hanno un connettore dedicato, per esempio Microsoft Teams + Microsoft 365 Channel in Copilot Studio, SharePoint channel, WhatsApp channel, Facebook channel e Omnichannel in Copilot Studio.
  • Skills with Copilot Studio: impedisce di estendere gli agenti con le skills. Il pannello Add a skill segnala un errore e suggerisce di contattare l’amministratore per l’inserimento nell’allow list.
  • Microsoft Copilot Studio: nome generico, effetto molto specifico. Blocca i trigger di evento e l’esecuzione di automated evaluations con un account autenticato. È la trappola nominale più probabile: chi legge di corsa pensa che blocchi “tutto Copilot Studio”.
  • Le tre voci Knowledge source with SharePoint and OneDrive, with public websites and data e with documents in Copilot Studio governano le knowledge source; il connettore HTTP governa il nodo HTTP request. Per queste, invece del blocco totale, esiste l’endpoint filtering che consente o nega singoli endpoint.
  • Bloccando i connettori Power Platform usati come tool si bloccano anche i tool dei server MCP collegati, perché per la connettività passano dagli stessi connettori.

Due effetti collaterali da mettere nel piano di rilascio

Il primo riguarda i tempi. La documentazione afferma che “Copilot Studio supports data policy enforcement in real time”: non c’è finestra di grazia, e in caso di violazione il pulsante Publish diventa non disponibile. Il maker vede un banner di errore con un pulsante Details; dalla pagina Channels può espandere il link e scegliere Download per ottenere un file in cui ogni riga descrive una violazione. Come amministratore puoi rendere quel messaggio utile aggiungendo un contatto e un link “Learn more”:

# New- per la prima configurazione, Set- per aggiornarla
Set-PowerAppDlpErrorSettings -TenantId "<tenant ID>" -ErrorSettings $ErrorSettingsObj

Il secondo riguarda i canali. I canali Direct Line sono consentiti per default, ma se i maker non configurano nessun canale non bloccato, oppure se gli amministratori non consentono alcun canale, gli agenti non si possono pubblicare affatto. Una policy scritta “per sicurezza” bloccando tutti i canali produce un tenant in cui nessuno riesce a rilasciare nulla.

Su questo punto l’esame verifica la scelta della leva corretta a partire da un requisito: se lo scenario chiede di impedire agenti anonimi, la risposta è bloccare il connettore Chat without Microsoft Entra ID authentication in Copilot Studio, non istruire i maker a selezionare Authenticate with Microsoft, e non usare le sharing rules, che regolano invece chi riceve i permessi Editor o Viewer e con quale numero massimo di viewer.

Responsible AI e residenza dei dati

Sul versante Responsible AI la guidance per Copilot Studio organizza le pratiche su quattro principi — Fairness, Accountability, Transparency, Ethics — e ne traduce due in requisiti verificabili: gli utenti devono sapere che stanno interagendo con un agente che usa capacità di AI generativa, e va previsto un human-in-the-loop con cicli di feedback, audit periodici e un organo di governance. Per ogni funzionalità generativa esistono poi Responsible AI FAQs dedicate (fra le altre, generative answers, generative orchestration, computer use, prompts) più una Platform Card per il prodotto nel suo insieme: sono gli artefatti da citare in una valutazione d’impatto, non un generico rimando ai principi Microsoft.

La residenza dei dati è la terza gamba della pianificazione. I dati risiedono nella geographic region dell’environment, e un tenant con indirizzo di fatturazione in UE o EFTA rientra nell’EU Data Boundary solo se tutti i suoi environment sono creati in regioni interne al confine. Le funzionalità di AI generativa possono però comportare movimento di dati fuori dalla regione per gli utenti al di fuori degli Stati Uniti: un amministratore Power Platform può abilitarlo o disabilitarlo, e un tenant admin può addirittura disattivare la pubblicazione degli agenti che usano AI generativa. Restano poi i controlli trasversali — CMK, Customer Lockbox (con esclusioni dichiarate per la telemetria di audit), log in Microsoft Purview e Microsoft Sentinel — e una responsabilità che ricade sul maker: per i connettori verso sistemi esterni non Microsoft, garantire le misure descritte spetta a chi costruisce l’agente, non a Microsoft.