Microsoft Purview DLP pentru Copilot web search oprește trimiterea prompturilor sensibile către furnizori externi de căutare web, dar permite în continuare ca Copilot să răspundă din datele interne Microsoft 365. Asta este util și, sincer, trebuia să existe mai devreme, pentru că prea multe rollout-uri AI tratează grounding-ul pe web ca pe un default inofensiv.
Elementul din roadmap spune că rollout-ul global începe la sfârșitul lui iunie 2026. Documentația Microsoft este mai clară despre ce face efectiv: când un prompt conține tipurile configurate de informații sensibile, Copilot blochează web search extern ca sursă de grounding și revine la sursele interne Microsoft 365 permise. Asta se aplică pentru Microsoft 365 Copilot, Copilot Chat și agenților construiți în Copilot Studio care sunt publicați în Microsoft 365 Copilot.
Ce face de fapt acest control?
Acesta nu este un switch general de tipul "face Copilot sigur". Este un control DLP țintit pentru o singură cale de exfiltrare: web search extern.
În Purview, administratorii pot crea o politică DLP pentru locația Microsoft 365 Copilot and Copilot Chat, pot detecta sensitive information types și pot aplica acțiunea Prevent Copilot from processing content și apoi Performing Web Searches.
Policy location: Microsoft 365 Copilot and Copilot Chat
Condition: Content contains > Sensitive information types
Action: Prevent Copilot from processing content > Performing Web Searches
Când regula se potrivește, Copilot nu trimite către servicii web externe interogarea derivată din prompt. Totuși, răspunde folosind sursele interne de date permise.
Asta contează pentru că Microsoft documentează și faptul că interogările web derivate din prompturi pot fi afișate utilizatorilor în citations și pot fi logate pentru investigații administrative. Dacă utilizatorii pot lipi accidental date reglementate într-un prompt, blocarea hop-ului extern este un minim rezonabil.
De ce este bun, și de ce nu este suficient
Părerea mea: este un control bun, dar este ușor de vândut exagerat.
Partea bună este evidentă. Reduci un tip de scurgere fără să interzici complet Copilot. Pentru echipele care construiesc Microsoft Copilot și AI agents, acesta este tipul de control bazat pe least privilege pe care îl vrei: nu da agentului o cale de ieșire a datelor mai largă decât are nevoie.
Dar acesta este doar un strat.
Documentația Purview de la Microsoft descrie controale separate pentru:
- blocarea completă a prompturilor sensibile, în preview
- restricționarea procesării fișierelor și emailurilor sensibile
- blocarea emailurilor externe ca sursă de grounding, în preview
Deci dacă o organizație citește acest item din roadmap și concluzionează „Copilot este acum acoperit”, concluzia este greșită. Acoperă o singură rută, nu întregul peisaj. Dacă ați construit agenți personalizați, i-ați conectat la conținut SharePoint distribuit prea larg sau ați lăsat default-urile tenant-wide prea permisive, acest control nu vă salvează. Acolo, un audit de AI și automatizare este de obicei mai valoros decât încă un workshop optimist de enablement.
Ce merită urmărit la licențiere și guvernanță
Un detaliu care merită subliniat: descrierea serviciului Microsoft spune că Purview DLP for prompts is available to all users of M365 Copilot and Copilot Chat. Este o veste bună, pentru că scade bariera de intrare pentru această protecție specifică.
Totuși, guvernanța nu se termină la licențiere. Munca reală înseamnă calitatea clasificării, custom sensitive information types unde este nevoie, simulare, tratarea excepțiilor și monitorizare. Dacă acoperirea SIT este slabă, controlul este slab, punct. Iar Microsoft notează explicit că nu poți combina „sensitive information types” și „sensitivity labels” în aceeași regulă. Le poți pune în aceeași politică, dar nu în aceeași regulă. Pare un detaliu minor până când cineva presupune că există o regulă unică pentru tot și se întreabă de ce enforcement-ul este inconsistent.
Ce aș face eu în practică
Dacă deja implementați Copilot sau publicați agenți în Microsoft 365 Copilot, eu aș trata asta ca pe un default sigur și l-aș activa devreme. Apoi aș verifica restul stack-ului:
- clasificați mai întâi datele reglementate evidente
- adăugați custom SITs pentru identificatorii interni care contează
- revizuiți web grounding împreună cu prompt blocking și restricțiile pentru fișiere și email
- testați explicit agenții din Copilot Studio, nu doar chat-ul principal Copilot
- nu mai pretindeți că DLP singur este modelul vostru de guvernanță AI
Dacă aveți nevoie de ajutor pentru a pune cap la cap control plane-ul mai larg din Purview, Power Platform și AI workflow automation, această funcție se potrivește cel mai bine ca un singur guardrail într-un design mai amplu.
Util? Da. Suficient? Nu. Acesta este nivelul corect de entuziasm aici.
