Hvis medarbejdernes pc’er begynder at gemme AI-snapshots, får I hurtigt en diskussion om privatliv, datalæk og revisionsspor. Problemet er sjældent brugeren – det er manglende central styring. Med de rigtige Windows 11 AI indstillinger kan I beslutte, hvad der må indsamles, og håndhæve det med Intune. Resultatet: færre overraskelser og en politik, I kan dokumentere.

Key takeaways

• Træf én beslutning for hele virksomheden: vælg om Recall/AI-snapshots må bruges, og lav en skriftlig begrundelse til ledelse og compliance.
• Håndhæv centralt via Intune: brug Settings Catalog (Intune service release 2502) til at slå AI-features fra/til pr. enhedsgruppe.
• Segmentér efter risiko: blokér på højrisiko-enheder (fx ledelse, HR, økonomi, kundedata) og test i en pilotgruppe først.
• Dokumentér drift og kontrol: gem politik-ændringer, scope og undtagelser, så I kan vise “hvem-hvad-hvorfor”.
• Undgå over-privilegering i jeres setup: skift til low-privilege konto til Intune Connector for Active Directory, hvis I bruger den (Intune 2502).

Hvorfor er Windows Recall en virksomhedsbegivenhed og ikke en brugerfeature?

Recall (AI-snapshots) ændrer dataplanen på endpoints: indhold kan blive “duplikeret” til et nyt lag på pc’en, som I skal tage stilling til. Det handler ikke kun om GDPR-ord, men om helt praktiske spørgsmål:

• Kan en pc gemme snapshots af mails, kundedata, løn, tilbud og interne chats?
• Hvad er jeres retention-krav for endpoint-data kontra SharePoint/Exchange?
• Hvordan håndterer I indsigt ved en sikkerhedshændelse (hvad blev gemt lokalt, og hvem havde adgang)?

Før → Efter (styring):
Før: Brugere opdager AI-funktioner tilfældigt, og IT får enkeltsager og undtagelser uden standard.
Efter: Én politik i Intune, scoped til grupper, med en pilot og en dokumenteret beslutning. IT kan svare “ja/nej” med samme begrundelse hver gang.

Sådan vælger I den rigtige politik for Windows 11 AI indstillinger

Brug denne beslutningsregel, før I rører ved teknikken:

• Hvis enheden håndterer følsomme data (HR, økonomi, kontrakter, sundhed, kunde-Persondata): vælg standard = deaktiveret, og kræv godkendt undtagelse.
• Hvis enheden er delt (frontline, shared devices): vælg deaktiveret. Delte enheder og snapshots er et dårligt match.
• Hvis I mangler endpoint-governance (ingen klare device groups, svag compliance reporting): vælg deaktiveret, indtil basis er på plads.
• Hvis I vil teste værdi uden at åbne hele flåden: vælg pilot = aktiveret på en lukket gruppe med klare “stop-kriterier”.

Tjekliste: sådan styrer I Recall og AI centralt i Intune (praktisk)

Nedenfor er en tjekliste, der passer til et typisk SMB-setup med Microsoft 365 og Intune. Den tager udgangspunkt i, at Intune (service release 2502) giver flere Windows AI-indstillinger i Settings Catalog.

1. Kortlæg scope (30 min):
   • Hvilke Windows 11-versioner har I (fx 24H2 udrulning)?
   • Hvilke enheder har følsomme roller (HR/Finance/Salg/ledelse)?
   • Hvilke enheder er shared devices?
2. Lav en “AI endpoint policy” (1 side):
   • Standard: tilladt/ikke tilladt.
   • Undtagelser: hvem godkender, og hvor længe gælder undtagelsen.
   • Kontrol: hvordan IT kan se, at politikken er anvendt (compliance/reporting).
3. Byg Intune-politik i Settings Catalog:
   • Opret en policy til Windows 11 AI indstillinger (Recall/AI-features efter jeres beslutning).
   • Scope: start med en pilotgruppe. Brug separate policies til “Blokeret” og “Tilladt”, så I kan forklare og rulle tilbage.
   • Konfliktstyring: undgå at flere policies rammer samme setting på samme enheder.
4. Definér stop-kriterier for pilot (før I starter):
   • Hvis der gemmes snapshots i følsomme apps/workflows, stopper I og ruller tilbage.
   • Hvis supporthenvendelser stiger markant pga. performance eller brugerforvirring, stopper I.
   • Hvis I ikke kan dokumentere status pr. enhed, stopper I og retter rapporteringen først.
5. Dokumentér og arkivér:
   • Gem policy-navne, scope, dato, ændringslog og beslutning fra ansvarlig (IT/ledelse/compliance).
   • Notér hvilke grupper der er undtaget, og hvornår I revurderer.

Fejl der koster tid (og giver flere undtagelser end nødvendigt)

1) I blokerer alt uden segmentering

Hvis alt rammes af samme politik, ender I med manuelle undtagelser. Segmentér i stedet efter risiko og arbejdsrolle.

2) I tester i produktion uden stop-kriterier

Pilot uden “hvad får os til at stoppe” bliver hurtigt en permanent halvløsning. Definér stop-kriterier før I aktiverer noget.

3) I glemmer servicekonti og connector-privilegier

Intune service release 2502 introducerer mulighed for en low-privilege konto til Intune Connector for Active Directory. Hvis I stadig bruger en bredt privilegeret konto, er det en unødvendig risiko, I kan reducere nu.

Før → Efter (privilegier):
Før: Connector kører med en konto, der har mere adgang end nødvendigt, fordi “det har altid virket”.
Efter: Connector kører med mindst mulige rettigheder, og I kan forklare det i en audit uden at krydse fingre.

Hvordan hænger det sammen med compliance og NIS2 i praksis?

Mange SMB’er bliver målt på, om de kan håndtere sårbarheder og begrænse unødvendig dataindsamling på endpoints. Uanset om I formelt er omfattet af NIS2 eller følger kravene som “best practice”, er den praktiske pointe den samme:

• En ny endpoint-funktion, der kan ændre hvor data ligger, skal have en beslutning og en kontrol.
• Kontrollen skal være central (Intune), ikke baseret på brugeradfærd.
• Dokumentation skal kunne findes igen: policy + scope + ansvarlig + dato.

Hvis I samtidig arbejder med grundlæggende sikkerhed i Microsoft 365, kan vores team typisk samle det i samme løft som jeres øvrige hardening og governance på /it-sikkerhed.

FAQ om Windows 11 AI indstillinger, Recall og Intune

Hvordan slår man Recall fra centralt i Intune?

Opret en Windows-policy i Intune via Settings Catalog, find de relevante Windows AI/Recall-indstillinger, og deploy til en enhedsgruppe. Start med pilot, og udrul derefter til “blokeret”-grupper (fx HR/Finance) før resten.

Skal vi deaktivere Recall på alle pc’er?

Hvis I har følsomme data på endpoints, delte pc’er, eller ingen klar governance, er tommelfingerreglen: deaktiver som standard og lav en kontrolleret pilot for udvalgte roller. Hvis I kan dokumentere scope, kontrol og undtagelser, kan I udvide gradvist.

Gælder Windows 11 AI indstillinger kun Windows 11 24H2?

I praksis ser vi dem især blive relevante i forbindelse med nyere Windows 11-udrulninger (fx 24H2). Kortlæg først versioner og hardware-parathed, og lav policies, der ikke rammer enheder, som ikke understøtter funktionen.

Hvad skal vi dokumentere for at kunne forklare beslutningen i en audit?

Gem: (1) beslutning (tillad/blokér), (2) begrundelse (risiko/rolle), (3) Intune policy-navn og settings, (4) scope (grupper), (5) undtagelser med udløbsdato, (6) ændringslog. Det er normalt nok til at gøre kontrollen efterprøvbar.

Kan vi styre det forskelligt for ledelse, HR og almindelige brugere?

Ja. Brug separate enhedsgrupper og to policies: én “Blokér AI-snapshots” og én “Tillad i pilot”. Undgå at “Tillad”-policyen kan lande på HR/Finance ved en fejl (fx via dynamiske grupper uden klare kriterier).

Vi bruger Intune Connector for Active Directory – hvad betyder low-privilege ændringen?

Intune 2502 gør det lettere at køre connectoren med en konto med færre rettigheder. Tommelfingerregel: giv kun de rettigheder, connectoren faktisk skal bruge, og fjern gamle “Domain Admin”-mønstre. Det reducerer konsekvensen, hvis kontoen kompromitteres.

Hvad er første skridt, hvis vi er i tvivl om vores nuværende setup?

Start med en 3-punkts audit: (1) hvilke enheder kan blive påvirket (versioner/grupper), (2) hvilke data ligger på endpoints (roller/flows), (3) hvilke Intune-policies rammer allerede privacy/telemetry. Først derefter vælger I “tillad vs. blokér”.

Sådan kommer I i mål de næste 10 arbejdsdage

1. Dag 1–2: Kortlæg enhedsgrupper (følsom rolle, shared devices, standardbrugere) og Windows 11-versioner.
2. Dag 3: Beslut standard (blokér/tillad) og skriv en 1-sides politik med undtagelsesproces.
3. Dag 4–5: Byg Intune Settings Catalog policies (pilot + blokér) og test på 5–15 enheder.
4. Dag 6: Mål resultater: supporttickets, brugerfeedback, og om compliance-status kan ses pr. enhed.
5. Dag 7–8: Udrul til højrisiko-grupper først (blokér), og udvid pilot kontrolleret.
6. Dag 9: Opdatér dokumentation (scope, undtagelser, ændringslog) og gem det ét sted.
7. Dag 10: Gennemgå connector/servicekonti og skift til low-privilege hvor muligt.