Microsoft Purview DLP Copilot: stop web search-læk

Copilot kan forbedre svar ved at lave web search. Problemet opstår, når en medarbejder skriver noget fortroligt i prompten, som I aldrig ville sende ud af huset. Med Microsoft Purview DLP Copilot kan I blokere web search for netop den prompt og stadig få et svar baseret på jeres interne Microsoft 365-data.

• Reducer risikoen for IP-læk: Opsæt Purview DLP til at stoppe web grounding, når prompten indeholder følsomme data.
• Bevar produktiviteten: Lad Copilot fortsætte med at bruge interne kilder (SharePoint/OneDrive/Teams), selv når web search blokeres for en prompt.
• Få styr på “runtime” adfærd: Beskyt ikke kun filer og rettigheder – håndhæv regler i selve prompt-øjeblikket.
• Skær ned på Shadow AI: Kombinér med Purview Network Data Security for at forhindre deling til unmanaged AI i browseren.
• Gør compliance konkret: Dokumentér kontroller, dataflow og beslutningsregler, så I kan stå på mål for GDPR/NIS2-krav til dataminimering og kontrol.

Hvorfor er Copilot web search en reel risiko for SMB?

Copilot kan “grounde” et svar med webresultater. Det er nyttigt til generelle spørgsmål, men det er også et nyt dataflow, som I skal kunne styre. Microsoft beskriver nu, at Purview DLP kan forhindre, at følsomme data i Copilot-prompts bliver sendt til ekstern web search (Bing) (Microsoft Security Blog, 2026).

Det handler sjældent om, at Copilot “læser for meget”. Det handler oftere om, at medarbejdere copy-paster for meget: tilbud, kundelister, lønforhold, kodesnippets, kontraktudkast eller en hel mailtråd.

Hvad ændrer Purview DLP for Copilot web search?

Når Purview vurderer, at prompten indeholder følsomt indhold, kan web search for den enkelte prompt blokeres. Copilot kan stadig generere et svar baseret på interne M365-data, uden at sende prompten ud i web search (Microsoft Security Blog, 2026).

Mikro “Før → Efter” #1
Før: IT slår web search helt fra for alle, fordi de ikke kan vurdere prompt-risikoen.
Efter: Purview blokerer kun web search, når prompten matcher jeres DLP-regler. Brugere får stadig værdi af Copilot i interne dokumenter.

Sådan tænker I “statisk” vs. “runtime” sikkerhed

De fleste Copilot-projekter starter med oprydning: rettigheder, SharePoint-struktur og Teams-governance. Det er nødvendigt, men ikke tilstrækkeligt. Runtime-sikkerhed handler om det, brugeren selv skriver ind, og hvad Copilot derefter må gøre med det.

Hvis I kun arbejder statisk, kan I stadig få læk gennem prompten. Purview DLP lægger en kontrol ovenpå, som matcher anbefalinger om at styre dataflow til eksterne AI-komponenter (fx NIST AI RMF og CISA secure AI guidelines).

Mikro “Før → Efter” #2
Før: “Vi har ryddet op i SharePoint, så Copilot er sikkert.” (Kun filadgang er tænkt ind.)
Efter: I tester konkrete prompts og håndhæver DLP-regler på prompt-tekst, så web grounding ikke kan bruges som “udgang” for fortroligt indhold.

Hvis I mangler fundamentet, så start med jeres Microsoft 365-governance og informationsstruktur på /microsoft-365 før I ruller Copilot bredt ud.

Tjekliste: Sådan opsætter I Purview DLP for Copilot web search (styring, ikke klikguide)

Brug tjeklisten som styringsdokument til jeres IT, sikkerhedsansvarlige og ledelse. Den reducerer misforståelser og gør det muligt at auditere beslutninger senere.

Kontrolpunkt	Hvad I kigger efter	Beslutningsregel
1) Afgræns, hvornår web search er OK	Hvilke brugergrupper og use cases må bruge web grounding?	Tillad web search til “generelle” prompts; kræv blokering når prompten indeholder kundedata, IP eller økonomi.
2) Definér jeres “stop-ord” som Sensitive Information Types	De mest kritiske datatyper: kontrakter, priser/rabatter, kundelister, persondata, kildekode/design	Blokér web search hvis prompten matcher disse datatyper. Start stramt, udvid kontrolleret.
3) Vælg håndhævelse: block vs. warn-with-override	Hvad sker der ved falske positiver i jeres miljø?	Brug “warn” i pilotfasen for at lære; skift til “block” for de mest kritiske mønstre.
4) Test Copilot fallback	Kan Copilot stadig besvare opgaven med interne kilder, når web search blokeres?	Accepter kontrol hvis standard-scenarier stadig fungerer på SharePoint/OneDrive/Teams.
5) Log og auditér	Kan I dokumentere hændelser, undtagelser og ændringer i politikker?	Hvis I ikke kan finde hændelser og forklare dem, er kontrollen ikke driftbar.
6) Udvid til Shadow AI	Sendes data til unmanaged AI via browser (fx ChatGPT)?	Indfør Network Data Security for de samme datatyper, så brugerne ikke bare flytter risikoen (Microsoft Learn, 2026).

Sådan håndterer I falske positiver uden at skabe “Copilot-modstand”

Falske positiver er ikke et argument for at droppe DLP. Det er et argument for at køre en kontrolleret pilot, hvor I lærer, hvilke mønstre der rammer for bredt.

3 regler der virker i praksis

1. Start med de få, dyre datatyper. Priser, kontrakttekst, kundelister og persondata giver typisk mest risiko pr. hændelse.
2. Brug “warn” i pilot – men log alt. Hvis brugerne kan override, skal det være synligt og forklareligt i audit.
3. Giv brugeren et alternativ. Når web search blokeres, skal forventningen være: “Formulér spørgsmålet uden fortroligt indhold” eller “peg på et internt dokument i SharePoint”.

Hvordan vælger I mellem at slå web grounding fra og at bruge dynamisk DLP?

Der findes to strategier, og de passer til forskellige risikoprofiler:

• Slå web grounding fra hvis I har meget lav risikotolerance, få use cases der kræver web, eller hvis I er i en tidlig fase uden labels/DLP-disciplin. Ulempen er lavere nytteværdi for mange brugere.
• Brug dynamisk DLP hvis I vil have web value, men kunne dokumentere kontrol med hvilke prompts der må gå ud. Det matcher idéen om styring af dataflow frem for total forbud.

Microsoft har tidligere givet admins mere kontrol og transparens over web search queries i Copilot, og Purview bygger nu ovenpå med DLP-håndhævelse (Microsoft Tech Community, 2024/2025).

FAQ: Microsoft Purview DLP og Copilot web search

Sender Copilot mine data til internettet?

Copilot kan lave web search for at forbedre svar. Med Purview DLP kan I forhindre, at følsomme prompt-data sendes til ekstern web search, mens Copilot stadig kan svare på interne M365-kilder (Microsoft, 2026).

Kan man slå web search fra i Microsoft 365 Copilot?

Ja, admins kan styre web search/web grounding. Tommelfingerregel: Slå det helt fra, hvis I ikke har klassificering og DLP på plads. Ellers brug dynamisk DLP, så I ikke fjerner nytteværdien for alle.

Hvad er Microsoft Purview DLP Copilot helt konkret?

Det er DLP-kontroller, der kan håndhæve regler på Copilot-interaktioner, så bestemte typer følsomt indhold ikke må bruges i bestemte handlinger – fx at blive sendt ud i web search. Fokus er runtime: det der sker i prompten.

Påvirker blokering af web search Copilots evne til at svare?

Ja, Copilot mister web-kilder til den specifikke prompt. Men Microsoft beskriver, at Copilot stadig kan generere svar ud fra interne M365-data, når web search blokeres (Microsoft, 2026). Beslutningsregel: Hvis opgaven kræver internetkilder, så omformulér prompten uden følsomme data.

Hvordan beskytter vi IP i AI-prompts uden at bremse alle?

Start med 5–10 konkrete mønstre (priser/rabatter, kontraktfraser, kundelister, kildekode) og blokér web search ved match. Kør 2–4 uger med “warn” i pilot for resten og finjustér efter hændelser.

Hvordan hænger det sammen med GDPR og NIS2?

Fællesnævneren er kontrol med data og dataflow. ENISA peger på behovet for kontrol med eksterne data-kald i AI-systemer (ENISA), og NIST/CISA lægger vægt på styring og “secure by design” (NIST AI RMF, CISA). Purview DLP er jeres konkrete kontrol, der kan dokumenteres.

Sådan kommer I i gang (uden at starte for stort)

1. Kortlæg 10 typiske Copilot-prompts fra salg, økonomi, HR og drift – og markér hvilke der må bruge web search.
2. Definér jeres “røde” datatyper (SITs/klassificering): priser, kontrakter, kundedata, persondata, kildekode/design.
3. Kør en pilot med Purview DLP hvor web search blokeres ved match, og resten kører med advarsel + logging.
4. Review hændelser ugentligt og justér regler: skærp de dyre datatyper, løs de mønstre der giver støj.
5. Udvid til Shadow AI med Network Data Security, så brugerne ikke flytter samme data til en unmanaged chatbot (Microsoft Learn, 2026).
6. Dokumentér beslutningsreglerne (hvem må hvad, hvornår, og hvorfor) og læg dem ind i jeres compliance- og driftsrunbooks – gerne sammen med jeres leverandør på /compliance og /drift.

Kilder: Microsoft Security Blog (2026), Microsoft Learn (2026), Microsoft Tech Community (2024/2025), NIST AI RMF, CISA, ENISA, Quadbridge (2025), Microsoft Security Blog (2025), A1T Security (2025).