Microsoft 365 Copilot in den Office Apps deaktivieren: Registry, GPO & Intune

Die Integration von Microsoft 365 Copilot erfolgt nicht über einen einzelnen „Aus-Schalter“, sondern ist tief in der DNA der Office-Anwendungen verankert. Ein Administrator, der hier die Kontrolle behalten will, muss verstehen, dass wir es mit einem Hydra-Problem zu tun haben: Ein Kopf wird abgeschlagen (z.B. durch Lizenzentzug), doch der „Teaser“-Button im Word-Client wächst nach und generiert unnötige Support-Calls.

Das Ziel dieses Beitrags ist die radikale Reduktion der UI-Surface. Wir wollen verhindern, dass der User visuell mit Copilot konfrontiert wird, noch bevor die Data-Governance-Hausaufgaben erledigt sind. Es geht um Oberflächen-Hygiene und Ruhe im Betrieb.

⚠️ Wichtiger Hinweis zur Versionierung: Die hier beschriebenen granularen Steuerungen greifen effektiv erst ab Microsoft 365 Apps Version 2412. Ältere Builds ignorieren moderne Policies oft und benötigen härtere Methoden.

Microsoft 365 Apps | Registry oder GPO?

Die Verwaltung von Microsoft 365 Apps erfolgt klassisch über Administrative Vorlagen (ADMX). Doch die Realität in gewachsenen IT-Landschaften ist oft komplex: Veraltete Templates im Central Store, Verzögerungen bei der Replikation oder Konflikte mit dem Cloud Policy Service (OCPS) führen oft dazu, dass die Standard-Richtlinien („Administrative Vorlagen“) im Editor fehlen oder am Client nicht sauber greifen.

Wir benötigen daher eine Methode, die robuster ist als das Warten auf neue ADMX-Files.

– Registry-Eingriff

Anstatt uns auf instabile GUI-Einstellungen zu verlassen, erzwingen wir die Konfiguration direkt in der Registry. Das ist der chirurgische Weg, um Copilot auszublenden, ohne gleich die ganze Office-Suite lahmzulegen oder andere Cloud-Funktionen zu beeinträchtigen.

Wichtig: Es gibt zwei Pfade, je nachdem, wie dein Office verwaltet wird (On-Premises GPO vs. Cloud Policy). Im Zweifel setzt du beide.

So baust du das GPO-Objekt:

• Navigiere zu Benutzerkonfiguration > Einstellungen > Windows-Einstellungen > Registrierung.
• Rechtsklick > Neu > Registrierungselement.
• Wähle als Aktion zwingend Aktualisieren (Update). Das stellt sicher, dass der Key erstellt wird, falls er fehlt, oder korrigiert wird, falls er falsch ist.

Pfad A: Klassiker (On-Premises / Hybrid)

Das ist der Standard für Richtlinien, die direkt aus deinem lokalen Active Directory kommen.

• HKCU\Software\Policies\Microsoft\office\16.0\common\officeai
  
• Value: TurnOffCallout (DWORD) = 1

Effekt: Das weist den Client hart an, das Copilot-Popup und den Button im Ribbon nicht zu rendern.

Pfad B: Cloud-Pfad (OCPS / Modern Management)

Wenn du Richtlinien über config.office.com verteilst, landen diese oft in einem speziellen Cloud-Hive. Hier müssen wir zusätzlich das „Anheften“ der App verhindern.

• HKCU\Software\Policies\Microsoft\Cloud\Office\16.0\common\copilot
  
• Value 1: CopilotPinning (DWORD) = 0
• Value 2: PinningStateforCopilotApp (DWORD) = 0

Effekt: Damit verhinderst du, dass sich das bunte Copilot-Icon prominent in der Seitenleiste oder im App-Launcher festbeißt.

– GPO-Sicherheitsnetz

Registry-Einträge sind gut für den schnellen Effekt, aber echte Governance braucht Richtlinien. Wir bauen hier eine „Verteidigung in der Tiefe“ auf: Neben dem bloßen Deaktivieren von Copilot prüfen wir kritische Begleit-Einstellungen. So verhindern wir Workarounds durch findige User und stoppen nervige Marketing-Teaser, noch bevor sie erscheinen.

Die „Atombomben-Option“: Verbundene Erfahrungen

Wenn du absolut sichergehen willst (oder musst), kappst du die Leitung zur Microsoft Cloud komplett.

Pfad: Datenschutz > Trust Center

Einstellung: „Die Verwendung zusätzlicher optionaler verbundener Erfahrungen zulassen“ auf Deaktiviert.

Warnung: Sei dir bewusst, was du hier tust. Das tötet nicht nur Copilot, sondern auch nützliche Features wie 3D-Karten in Excel, die Online-Bildersuche oder Smart-Lookups. Kläre das vorher mit den Fachabteilungen, sonst steht das Telefon nicht mehr still.

Marketing unterdrücken: „Neuheiten“

Selbst wenn Copilot technisch deaktiviert ist, nervt Office oft mit „Coming Soon“-Popups. Das erzeugt bei Nutzern nur Verwirrung oder unnötiges Begehren („Warum haben wir das nicht?“).

Einstellung: „Neuheiten“ / „Keine Informationen zu neuen Funktionen anzeigen“ -> Aktivieren.

Effekt: Ruhe im Karton. Keine Teaser für Features, die du noch nicht freigegeben hast.

Shadow-IT verhindern: Beta-Kanäle blockieren

Microsoft rollt KI-Features oft zuerst im „Current Channel (Preview)“ aus. Ambitionierte User versuchen gerne, dorthin zu wechseln, um Sperren zu umgehen.

Einstellung: „Optionen für Microsoft 365 Insider anzeigen“ -> Deaktiviert.

Effekt: Du behältst die Hoheit über den Update-Kanal und verhinderst ungetesteten Code (und unkontrollierte KI) im Produktionsnetz.

Der schmale Grat: „Enable Writing Assistant“

Du wirst über die Policy „Enable Writing Assistant“ (unter Verschiedenes) stolpern. Hier ist Fingerspitzengefühl gefragt.

Einordnung: Das steuert primär den Microsoft Editor (Rechtschreib- und Stilprüfung), nicht den großen Generative-AI Copilot.

Empfehlung: Wenn du eine strikte „Zero Trust“-Strategie gegenüber jeglicher KI-Hilfe fährst, deaktiviere es. Aber sei fair zu deinen Usern: Du nimmst ihnen damit auch die besseren Grammatik-Vorschläge weg. Um nur den datenschutzritischen LLM-Chat zu treffen, ist die Registry-Methode (Stufe A) oder die Trust-Center-Policy (Punkt 1) der präzisere Weg.

Intune | Apps – Richtlinien für Microsoft 365 Apps

Wir nutzen hier den Cloud Policy Service via Intune, um Richtlinien direkt an die User-Identität zu binden. Das stellt sicher, dass Governance-Vorgaben auch auf nicht-verwalteten Geräten (BYOD) greifen, sobald sich der User anmeldet.

Da in dieser Ansicht der globale „Kill-Switch“ oft fehlt (lizenzabhängig), bauen wir einen digitalen Zaun („Containment“). Wir deaktivieren nicht das Feature selbst, sondern seine Fähigkeiten zur Interaktion und Datenverarbeitung.

Schritt 1: Die Policy erstellen

Navigiere im Intune Admin Center zu: Apps > Richtlinien für Office-Apps (unter „Richtlinien“) > Erstellen.

• Name: M365 Apps – Copilot Hardening
• Beschreibung: Einschränkung der KI-Oberfläche und Datennutzung (Containment).
• Bereich (Scope): Wähle hier „Diese Richtlinienkonfiguration gilt für Benutzer…“. Wähle die entsprechende Sicherheitsgruppe aus (z.B. „All Users / Alle Benutzer“ oder eine Pilot-Gruppe).

Schritt 2: Die Konfiguration

Suche im Konfigurations-Bereich nach „Copilot“. Basierend auf den verfügbaren Optionen setzen wir folgende Einstellungen, um die Angriffsfläche zu minimieren:

Microsoft Teams

In Teams greifen keine Client-Einstellungen. Die Kontrolle über KI-Funktionen liegt hier allein im Backend bei den Meeting Policies. Für Architekten stellt sich hier die entscheidende Compliance-Frage: Wie gehen wir mit dem gesprochenen Wort um?

Microsoft unterscheidet hier zwischen flüchtiger Verarbeitung (Daten liegen nur kurz im RAM, kein Audit-Trail) und persistenter Verarbeitung (Zwang zur Transkription). Da „flüchtig“ oft schwer zu auditieren ist und „persistent“ datenschutzrechtlich heikel sein kann, wählen viele Unternehmen den „Hard Kill“.

Teams Admin Center

• Pfad: Teams Admin Center > Besprechungen > Besprechungsrichtlinien.
• Einstellung: Suche nach dem Abschnitt „Aufzeichnung und Transkription“.
• Wert: Stelle das Dropdown bei „Copilot“ auf Aus (Off).

Hinweis zur Replikation: Änderungen an Teams Policies sind notorisch langsam. Es kann bis zu 24 Stunden dauern, bis der Copilot-Button bei allen Usern tatsächlich verschwindet. Plane dies in deine Kommunikation ein und eröffne keine verfrühten Support-Tickets bei Microsoft.

PowerShell (Der „Hard Kill“)

Die GUI im Teams Admin Center hinkt oft hinterher oder ist unübersichtlich. PowerShell ist hier präziser.

# Verbindung herstellen
Connect-MicrosoftTeams

# Prüfen der aktuellen Global Policy
Get-CsTeamsMeetingPolicy -Identity Global | Select-Object Copilot

# Deaktivieren (Hard Kill)
Set-CsTeamsMeetingPolicy -Identity Global -Copilot Disabled

Die Parameter-Falle (Architect-Knowledge) | Es ist essenziell, die Nuancen des Parameters -Copilot zu verstehen, falls du ihn nicht auf Disabled stellst:

• Disabled: Copilot ist in Meetings für die zugewiesenen User nicht verfügbar. Der Button fehlt oder ist ausgegraut.
• Enabled: Das ist die „moderne“ Standard-Einstellung (oft „Copilot only“ genannt). Copilot kann aktiviert werden, ohne dass ein Transkript gespeichert wird. Die Daten werden flüchtig verarbeitet. Datenschutz-Sicht: Gut, da keine Logs bleiben. Compliance-Sicht: Schlecht, da kein Audit-Trail existiert (wer hat was gefragt?).
• EnabledWithTranscript: Copilot erzwingt, dass die Transkription gestartet wird. Ohne Transkript kein Copilot. Das erzeugt eine persistente .docx Datei im OneDrive/SharePoint.

Service Plan Stripping (Die Lizenz-Ebene)

Das ist die architektonisch sauberste Lösung. UI-Ausblendungen sind letztlich nur „Security through Obscurity“. Wenn du dem User das Recht auf Service-Ebene entziehst, weist das Microsoft-Backend jeden API-Call ab. Das verhindert auch „Shadow Access“ über direkte URL-Aufrufe oder Web-Versionen, die lokale Registry-Keys ignorieren.

Die Herausforderung: Copilot ist oft kein einzelner „On/Off“-Schalter, sondern versteckt sich in Unter-Plänen (Service Plans) innerhalb deiner E3/E5 oder Add-On SKUs. Wir müssen diese chirurgisch entfernen.

Relevante Service Plans (Stand 2026):

• COPILOT_FOR_M365_ENTERPRISE: Das eigentliche kostenpflichtige Add-on.
• BING_CHAT_ENTERPRISE: Der „Commercial Data Protection“ Schutz für die Bing-Suche (oft in E3/E5 enthalten).
• COPILOT_INDIVIDUAL: Taucht oft bei privaten MS-Konten oder Pro-Lizenzen auf.

Der Modern Architect Weg (Microsoft Graph)

Connect-MgGraph -Scopes User.ReadWrite.All, Directory.ReadWrite.All
$UserId = "user@domain.com"
$SkuId = "6fd2c87f-b296-42f0-b197-1e91e994b900" # Beispiel E5

# Pläne definieren, die deaktiviert werden sollen
$PlansToDisable = @("COPILOT_FOR_M365_ENTERPRISE", "BING_CHAT_ENTERPRISE")

# IDs ermitteln und Lizenz updaten
$SkuInfo = Get-MgSubscribedSku | Where-Object {$_.SkuId -eq $SkuId}
$DisabledIDs = $SkuInfo.ServicePlans | Where-Object {$_.ServicePlanName -in $PlansToDisable} | Select -ExpandProperty ServicePlanId
Set-MgUserLicense -UserId $UserId -AddLicenses @{SkuId = $SkuId; DisabledPlans = $DisabledIDs} -RemoveLicenses @()

Tipp: Prüfe vor dem Skripting IMMER die aktuellen Namen deiner Tenant-SKUs via Graph Explorer oder Get-MgSubscribedSku, da Microsoft die ServicePlan-IDs und Namen gelegentlich rotiert.

Fazit & Einschätzung

Die hier beschriebenen Maßnahmen sind weit mehr als nur technisches Troubleshooting. Man muss verstehen: Die Client-Konfiguration (Registry/GPO) ist primär UI Governance. Sie dient der Oberflächen-Hygiene, um „Fear of Missing Out“ (FOMO) bei den Anwendern zu dämpfen und die Support-Hotline zu entlasten.

Eine echte, wasserdichte „Deaktivierung“ erreichst du jedoch nie allein am Client, sondern nur durch die Kombination aus UI-Bereinigung und Lizenz-Entzug (Service Plan Stripping) im Backend.

Betrachte diese technische Blockade nicht als dauerhaften Zustand, sondern als strategisches Werkzeug. Nutze die gewonnene Ruhe („Strategic Pause“), um deine Hausaufgaben zu machen: Bereinige Berechtigungen, implementiere Sensitivity Labels und härte deinen Tenant. Denn nur wenn die Datenqualität stimmt, wird der Semantic Index später zum Vorteil statt zum Sicherheitsrisiko.

This post is also available in: Deutsch English