AI sikkerhed i virksomheden: ryd op før I køber Copilot

Hvis I tænder Microsoft 365 Copilot i et miljø med “alle kan se alt”, bliver jeres interne datarod til et sikkerhedsproblem på dag 1. Copilot respekterer adgangsrettigheder, men den gør det hurtigt at finde alt det, I har glemt lå i en delt mappe. Resultatet er ikke nødvendigvis et eksternt datalæk – men et internt læk, der er lige så dyrt. Her får I en praktisk tjekliste til at gøre jeres AI-brug dokumenterbar og sikker.

Key takeaways: det I skal gøre før Copilot

• Kortlæg oversharing: auditér SharePoint/Teams/OneDrive for brede grupper og “Alle undtagen eksterne” – og luk de værste huller først.
• Klassificér det vigtigste: brug Microsoft Purview labels og (hvor relevant) DLP på løn, HR, kontrakter og kundedata.
• Stram identitet: håndhæv MFA og Conditional Access i Entra ID, så AI-adgang ikke bliver et nyt angrebspunkt.
• Gør Shadow AI håndterbar: lav en enkel whitelist + regler for sikker brug af ChatGPT i virksomheder (hvad må ind, hvad må ikke).
• Log og dokumentér: sæt krav til logning, review og ejerskab, så I kan forklare jeres kontroller (NIS2-tankegang).

Hvorfor Copilot gør datarod synligt på en ny måde

Copilot er ikke “magisk adgang”. Den arbejder inden for de rettigheder, brugeren allerede har. Det er også Microsofts egen pointe: Copilot bruger kun data, brugeren har adgang til, og den træner ikke på jeres kundedata (Microsoft, 2026).

Problemet opstår, når adgangsmodellen er vokset tilfældigt: gamle projektteams, delte mapper, e-mail-vedhæftninger gemt “et sted” og eksterne gæster, der aldrig blev fjernet. Copilot bliver søgemotoren, der fjerner friktion. Det er godt for produktivitet. Det er dårligt for oversharing.

Micro “Før → Efter” #1 (oversharing)

Før: “Vi finder sjældent løn- og HR-filer, så risikoen er lav.”
Efter: I kører en adgangsaudit, flytter HR til et afgrænset site, og bruger labels + DLP. Copilot kan stadig hjælpe HR – men ikke give resten af organisationen genveje til følsomme filer.

Sådan vurderer I jeres AI data protection på 30 minutter

Brug denne hurtige vurdering som beslutningsregel for, om I er tæt på “Microsoft 365 Copilot readiness” – eller om I bør rydde op først.

Kontrolområde	Spørgsmål I skal kunne svare ja til	Hvad I kigger efter i praksis
Adgang	Har vi fjernet brede standard-adgange til følsomme sites/biblioteker?	“Everyone except external users”, “Alle medarbejdere” på HR/Finance; gamle M365-grupper; gæstekonti uden ejer.
Data-placering	Ved vi, hvor HR/kontrakter/kundedata ligger?	Spredning i OneDrive, Teams-chats, mailbokse; uklar ejerskab på SharePoint-sites.
Klassificering	Er minimum “Fortrolig” markeret og håndhævet på kritiske dokumenttyper?	Purview sensitivity labels på skabeloner og biblioteker; auto-label (hvor relevant); klare undtagelser.
DLP	Stopper vi de mest kritiske læk-scenarier?	DLP-regler for CPR/HR/løn/kontooplysninger; blok/override med begrundelse; test på pilotgruppe.
Identitet	Er MFA og Conditional Access håndhævet for alle (inkl. admin)?	Legacy auth slået fra; CA-policy for risiko/land/managed device; PIM for adminroller.
Logging	Kan vi dokumentere brug og hændelser?	Unified audit log aktiv; log-retention matcher jeres behov; faste reviews (måned/kvartal).

Tjekliste: 12 konkrete oprydningsopgaver der lukker 80% af risikoen

1. Lav en “top 20” liste over Teams/SharePoint-sites med mest følsomt indhold (HR, Finance, ledelse, kunder).
2. Find brede grupper (fx “Alle medarbejdere”) og erstat med rollebaserede grupper.
3. Gennemgå gæsteadgang: hvem er gæster, hvem ejer relationen, og hvornår udløber den?
4. Indfør navnestandard på teams/sites (ejer, formål, data-klasse) så governance kan drives i drift.
5. Fjern “for evigt”-links: slå anonyme delingslinks fra, og sæt udløb på delingslinks hvor muligt.
6. Flyt HR og ledelsesmateriale til dedikerede sites med stram medlemsstyring.
7. Udrul Purview labels (minimum: Offentlig / Intern / Fortrolig) og gør “Fortrolig” synlig i Office-apps.
8. Aktivér DLP for de kritiske mønstre (CPR, bank, kontraktdata) og test med en pilot før bred håndhævelse.
9. Indfør “owner review” på M365-grupper: hver 90. dag skal ejeren bekræfte medlemmer og formål.
10. Håndhæv Entra ID baseline: MFA + Conditional Access for alle, og PIM for admins.
11. Definér regler for Shadow AI: hvad må medarbejdere ikke indsætte i offentlige AI’er, og hvilke værktøjer er godkendt.
12. Planlæg log-review: hvem kigger, hvor ofte, og hvad gør I ved afvigelser (dokumentér i et simpelt årshjul).

Fejl der koster mest ved AI governance i SMB

1) I køber licenser før I har en adgangsmodel

Copilot gør det lettere at arbejde. Den gør det også lettere at arbejde med de forkerte dokumenter. Start med adgang og ejerskab, ikke med udrulning til alle.

2) I prøver at “blokere AI” i stedet for at styre AI

Forrester peger på, at Shadow AI er en af de største governance-risici, fordi medarbejdere bruger BYO-AI uden godkendelse (Forrester, 2025). Hvis I kun forbyder, flytter brugen sig. Hvis I giver et sikkert alternativ + klare regler, får I kontrol.

3) I glemmer logging og dokumentation

ENISA anbefaler streng adgangskontrol og logning af AI-interaktioner som del af compliance-indsatsen (ENISA, 2025). Det samme tankesæt går igen i NIS2: dokumentér, at I gør noget – og at I følger op.

Sådan håndterer I Shadow AI uden at kvæle arbejdet

Lav en enkel “AI-politik skabelon” på én side og håndhæv den med tekniske kontroller, hvor det giver mening.

• Godkendte værktøjer: Microsoft 365 Copilot og evt. godkendte enterprise-løsninger. Alt andet kræver vurdering.
• Forbudt input: CPR, løn, kundekontrakter, interne priser, adgangskoder, sikkerhedslogfiler, kode med nøgler.
• OK input: anonymiserede tekster, offentlige dokumenter, interne skabeloner uden kundedata.
• Kontrolpunkt: hvis en opgave kræver at indsætte kundedata i en offentlig AI, skal den flyttes til et godkendt miljø.

Micro “Før → Efter” #2 (styring af AI-værktøjer)

Før: Medarbejdere bruger tilfældige chatbots, og I opdager det først, når nogen nævner det i frokostpausen.
Efter: I indfører en whitelist, kommunikerer 5 klare regler for sikker brug af ChatGPT i virksomheder, og giver et godkendt alternativ i Microsoft 365. I kan både støtte produktivitet og reducere risikoen for datalæk.

FAQ om AI sikkerhed virksomhed

Er Microsoft 365 Copilot sikkert, eller træner den på vores data?

Som udgangspunkt træner Microsoft 365 Copilot ikke på jeres kundedata, og den bruger kun det indhold, den enkelte bruger allerede har adgang til (Microsoft, 2026). Jeres reelle risiko er derfor typisk oversharing i Microsoft 365.

Hvad er den største Copilot-sikkerhedsrisiko i en SMB?

For brede adgangsrettigheder i Teams/SharePoint kombineret med utydeligt ejerskab. Tommelfingerregel: Hvis I ikke kan pege på en ejer for et site, så er adgang som regel også forkert.

Hvilke tre kontroller skal være på plads før udrulning?

1) MFA + Conditional Access i Entra ID, 2) oprydning i deling og grupper, 3) minimum én følsomhedsklasse (Purview label) for fortrolige dokumenter. Hvis én af dem mangler, så kør pilot i lille skala, ikke “til alle”.

Hvordan kobler vi AI governance til NIS2 og compliance?

Behandl AI som en ændring i jeres risikobillede: dokumentér kontroller (adgang, DLP, logning), læg faste reviews i et årshjul, og sørg for at ledelsen har et beslutningspunkt (accept/afvis/rest-risiko). Det gør jeres “risikovurdering af AI” revisor- og tilsynsvenlig.

Kan vi bare slå DLP til og være færdige?

Nej. DLP hjælper, men hvis adgang er forkert, vil brugere stadig kunne se og bruge indhold internt. Start med adgangsmodellen, og brug DLP til at stoppe de mest kritiske delings- og kopieringsscenarier.

Vi bygger en egen chatbot – hvad er den typiske LLM-risiko?

Prompt injection er en kendt top-risiko for LLM-applikationer (OWASP, 2025). Beslutningsregel: Hvis chatbotten kan kalde interne systemer eller hente data, skal I have input-validering, output-håndtering og logging fra start. Overvej at bygge i et kontrolleret miljø på Azure.

Hvordan starter vi i morgen uden at bruge en måned på workshops?

Vælg 5 forretningskritiske områder (HR, Finance, ledelse, salg, drift), lav en adgangsaudit på deres sites, og luk de 10 værste oversharing-huller. Kør Copilot-pilot på de opryddede områder først.

Afslutning: 7 implementeringsskridt I kan eksekvere nu

1. Udpeg ejerskab: én ansvarlig fra ledelsen + én teknisk ansvarlig (IT) for AI governance.
2. Vælg pilot-områder: start med teams/sites med høj værdi og lav kompleksitet (ikke hele virksomheden).
3. Kør adgangsaudit: fjern brede grupper og anonyme delingslinks på pilot-områderne.
4. Udrul labels: sæt minimum “Fortrolig” på HR/Finance/ledelse og gør det nemt for brugerne at vælge rigtigt.
5. Aktivér DLP i “audit mode”: mål påvirkning og justér, før I håndhæver blokering.
6. Håndhæv identitet: MFA + Conditional Access for alle, PIM for admins, og gennemgå gæster.
7. Dokumentér og drift: lav et kvartalsvist review af adgang, labels, DLP-hændelser og Shadow AI-regler.