Microsoft Copilot Cowork aktivieren: Kosten, Azure-Anforderungen und Best Practices

Microsoft erweitert sein Copilot-Portfolio kontinuierlich. Neben Microsoft 365 Copilot und Copilot Chat stehen Agents, Copilot Studio und inzwischen auch Cowork-Funktionen zur Verfügung. Microsoft Cowork ist quasi eine Erweiterung von M365 Copilot. Copilot Cowork ist ein KI-gestützter Arbeitsbereich innerhalb des Microsoft Copilot-Ökosystems, der darauf ausgelegt ist, komplexere Aufgaben, Projekte und Arbeitsabläufe zu koordinieren und auszuführen. Um es besser zu unterwscheiden: M365 Copilot ist der persönliche Assistent der E-Mails zusammenfasst oder Meetings auswertet. Copilot Cowork ist für die Informationssuche innerhalb eines Unternehmens gedacht, z.B. Erstellung eines Architekturvorschlags für eine M365 Umgebung auf Basis unserer Best Pracitces.

Technisch lässt sich Copilot Cowork über das Microsoft 365 Admin Center aktivieren. In der Praxis entstehen dabei jedoch einige Fragen:

• Welche Copilot-Variante ist für welchen Anwendungsfall gedacht?
• Benötigt jeder Benutzer eine Microsoft-365-Copilot-Lizenz?
• Welche Azure-Berechtigungen werden benötigt?
• Welche Rolle spielen Azure-Subscription, Resource Group und Billing Region?
• Was sind Copilot Credits?
• Wie lassen sich Credits in Euro umrechnen?
• Sollte ein organisationsweites und zusätzlich ein benutzerspezifisches Limit gesetzt werden?
• Wie lässt sich eine belastbare Kostenkontrolle aufbauen?

Dieser Artikel beschreibt die Aktivierung und zeigt, welche technischen, finanziellen und organisatorischen Aspekte vor einem produktiven Rollout berücksichtigt werden sollten.

Hinweis: Microsoft entwickelt Benennung, Lizenzierung und Abrechnung der Copilot-Dienste laufend weiter. Preise, Credit-Verbrauch und enthaltene Funktionen sollten deshalb vor einer Kundenfreigabe immer anhand der aktuell gültigen Microsoft-Produktdokumentation und der im jeweiligen Tenant angezeigten Commercial Terms geprüft werden.

1. Das Copilot-Portfolio einordnen

Die verschiedenen Microsoft-Angebote überschneiden sich teilweise. Für eine erste Einordnung hilft die Unterscheidung zwischen persönlicher Produktivität, allgemeinem KI-Chat, spezialisierten Agents und komplexeren Arbeitsaufträgen.

1.1 Microsoft 365 Copilot

Microsoft 365 Copilot ist primär der persönliche Arbeitsassistent innerhalb von Microsoft 365. Er ist unter anderem in folgenden Anwendungen integriert:

• Microsoft Teams
• Outlook
• Word
• Excel
• PowerPoint
• OneNote
• Microsoft 365 Copilot App

Typische Anwendungsfälle sind:

• E-Mails und Threads zusammenfassen
• Meetings vor- und/oder nachbereiten
• Dokumente entwerfen
• Präsentationen erstellen
• Tabellen analysieren
• Informationen aus Microsoft Graph und Microsoft 365 zusammenführen

Microsoft 365 Copilot arbeitet im Sicherheits- und Berechtigungskontext des jeweiligen Benutzers. Copilot sollte daher grundsätzlich nur Inhalte verwenden können, auf die der Benutzer bereits Zugriff besitzt.

Das schützt allerdings nicht automatisch vor Oversharing. Wenn SharePoint-, Teams- oder OneDrive-Berechtigungen zu großzügig gesetzt wurden, kann Copilot diese bestehenden Berechtigungsprobleme leichter sichtbar machen. Vor einem breiten Rollout sollten daher Datenklassifizierung, Berechtigungsstrukturen und Sharing-Konfiguration überprüft werden.

1.2 Microsoft 365 Copilot Chat

Copilot Chat bietet eine zentrale Chat-Oberfläche für KI-gestützte Aufgaben. Der konkrete Funktionsumfang hängt von Lizenzierung, Tenant-Konfiguration und den jeweils verfügbaren Microsoft-Angeboten ab.

Abhängig vom Szenario können Funktionen enthalten oder zusätzlich verbrauchsabhängig abgerechnet werden. Dazu können beispielsweise agentenbasierte Funktionen oder bestimmte Aktionen gehören.

Deshalb darf nicht pauschal angenommen werden: Eine vorhandene Microsoft-365-Copilot-Lizenz deckt automatisch jeden Agenten, jede Aktion und jeden Copilot-Dienst ohne zusätzliche Verbrauchskosten ab.

Vor dem Rollout sollte für jeden Anwendungsfall geklärt werden, ob er durch eine Benutzerlizenz, ein Capacity Pack oder Pay-as-you-go abgedeckt wird.

1.3 Copilot Agents

Agents sind spezialisierte KI-Assistenten, die auf bestimmte Wissensquellen, Regeln, Aktionen oder Geschäftsprozesse zugeschnitten werden können.

Mögliche Beispiele sind:

• Architektur-Assistent
• Angebots-Assistent
• interner Richtlinien-Assistent
• Onboarding-Agent
• Support- oder Service-Agent
• Azure Landing Zone Advisor

Ein Agent ist besonders sinnvoll, wenn Wissen oder Abläufe wiederverwendbar für mehrere Personen angeboten werden sollen.

1.4 Copilot Studio

Copilot Studio dient dem Erstellen und Verwalten umfangreicherer Agents. Je nach Ausbaustufe können unter anderem folgende Komponenten verwendet werden:

• Wissensquellen
• Topics und Instruktionen
• Connectoren
• Aktionen
• Agent Flows
• Authentifizierung
• Governance- und Analysefunktionen
• Veröffentlichung in unterschiedlichen Kanälen

Copilot Studio ist daher eher eine Plattform zum Entwickeln und Betreiben von Agents als lediglich eine einzelne Chat-Oberfläche.

1.5 Copilot Cowork

Cowork ist für Arbeitsaufträge gedacht, bei denen Copilot nicht nur eine einzelne Antwort liefern, sondern eine Aufgabe strukturierter und mit mehreren Arbeitsschritten bearbeiten soll.

Als praktische Orientierung gilt:

• Microsoft 365 Copilot Persönliche Produktivität im eigenen Arbeitskontext
• Copilot Chat: Allgemeine dialogbasierte KI-Unterstützung
• Agents: Wiederverwendbare Spezialisten für Wissen, Rollen oder Prozesse
• Copilot Studio: Entwicklung, Integration und Governance komplexerer Agents
• Cowork: Delegation umfangreicherer, gegebenenfalls mehrstufiger Arbeitsaufträge

Die Grenzen sind nicht immer scharf. Microsoft kann Funktionen zwischen den Produkten verschieben oder deren Bezeichnungen ändern.

2. Wann sollte Cowork verwendet werden?

Cowork eignet sich besonders für Aufgaben, bei denen ein Benutzer ein Ergebnis delegieren möchte, das mehr als eine einzelne Frage oder Textgenerierung umfasst.

Mögliche Szenarien sind:

• Informationen aus mehreren Quellen zusammentragen
• einen strukturierten Entwurf vorbereiten
• einen umfangreicheren Arbeitsauftrag in Teilschritte zerlegen
• Inhalte analysieren und daraus ein Arbeitsergebnis erstellen
• wiederkehrende Wissensarbeit standardisieren
• eine fachlich definierte Aufgabe über einen spezialisierten Agenten bearbeiten

Microsoft 365 Copilot eignet sich dagegen besser für unmittelbar interaktive Tätigkeiten wie:

• eine E-Mail formulieren
• ein Meeting zusammenfassen
• ein Dokument überarbeiten
• eine Präsentation erstellen
• eine Frage zu zugänglichen Microsoft-365-Inhalten stellen

Eine einfache Entscheidungsregel lautet:

Nutze Microsoft 365 Copilot für persönliche, interaktive Produktivität. Nutze Agents oder Cowork für wiederverwendbare, fachlich definierte oder mehrstufige Arbeitsaufträge.

3. Aktivierung im Microsoft 365 Admin Center

(https://gregorreimling.blob.core.windows.net/images/2026/08/2026-08-22-Copilot-Cowork-setuppage-in-m365-admin-center.jpg)

Die Aktivierung befindet sich im Microsoft 365 Admin Center im Bereich der Copilot-Abrechnung beziehungsweise der Spending Policies. Bitte beachtet, die genaue Navigation kann sich mit Portal-Updates ändern.

Sinngemäß zeigt das Portal folgende Funktion:

Activate the default spending policy for your organization (https://gregorreimling.blob.core.windows.net/images/2026/08/2026-08-22-Copilot-Cowork-setuppage.jpg)

Die Erläuterung im Portal macht deutlich, dass Benutzer Copilot Credits innerhalb der konfigurierten Agents und Dienste verbrauchen können. Als Abrechnungsmethode kann eine Azure-Pay-as-you-go-Subscription verbunden werden.

Der Dialog enthält typischerweise folgende Elemente:

1. Auswahl der Abrechnungsmethode
2. Auswahl einer organisationsbezogenen Azure-Subscription
3. Festlegung eines organisationsweiten Credit-Limits
4. optionales monatliches Limit pro Benutzer
5. Aktivierung der Default Spending Policy

Persönliche Azure-Subscriptions können angezeigt werden, sind für eine organisationsweite Spending Policy jedoch möglicherweise nicht verwendbar. Es sollte eine Subscription verwendet werden, die dem richtigen Entra-Tenant und dem vorgesehenen Billing-Kontext zugeordnet ist.

4. Erforderliche Azure-Berechtigungen

(https://gregorreimling.blob.core.windows.net/images/2026/08/2026-08-22-Copilot-Cowork-setup-azuresettings.jpg)

Eine auswählbare Azure-Subscription bedeutet nicht automatisch, dass der angemeldete Administrator die Spending Policy mit dieser Subscription verbinden darf.

Folgende Berechtigungsbereiche müssen unterschieden werden:

• Microsoft-365-Administratorrolle
• Entra-Verzeichnisrolle
• Azure-RBAC-Rolle auf Subscription- oder Resource-Group-Ebene
• Berechtigung im Azure-Billing-Kontext
• gegebenenfalls Rechte zur Registrierung eines Resource Providers oder zum Erstellen einer Abrechnungsressource

Welche konkrete Rolle erforderlich ist, hängt vom verwendeten Abrechnungsworkflow und Vertragstyp ab.

Das Prinzip der geringsten Privilegien sollte eingehalten werden. Ein permanenter Owner auf Subscription-Ebene sollte nicht allein aus Bequemlichkeit vergeben werden.

Empfehlungen:

1. Die von Microsoft für den konkreten Aktivierungsdialog dokumentierten Mindestrollen prüfen.
2. Azure-RBAC möglichst über eine dedizierte Administratorgruppe vergeben.
3. Privilegierte Rollen über Microsoft Entra Privileged Identity Management aktivieren.
4. Die Rollenzuweisung zeitlich begrenzen.
5. Nach erfolgreicher Konfiguration nicht mehr erforderliche Rechte entfernen.
6. Azure Activity Log und Microsoft-365-Audit-Protokolle für Änderungen überwachen.

UX-Falle bei fehlenden Berechtigungen

In der Praxis kann es vorkommen, dass:

• die Subscription in der Auswahl erscheint,
• alle Felder konfigurierbar sind,
• der Aktivierungsbutton aber deaktiviert bleibt oder
• keine ausreichend konkrete Fehlermeldung angezeigt wird

Fehlende Berechtigungen auf der Azure-Subscription sollten deshalb frühzeitig vor der Verwendung geprüft werden.

5. Was bedeutet „Monthly budget (credits)“?

Das Feld Monthly budget (credits) bezeichnet kein Euro-Budget und keine direkte Anzahl von Azure-OpenAI-Tokens. Es handelt sich um ein monatliches Limit in Copilot Credits.

Copilot Credits bilden eine abstrakte Verbrauchseinheit für die von Microsoft unterstützten Copilot-Dienste und Funktionen. Der Credit-Verbrauch kann abhängig sein von:

• dem verwendeten Dienst,
• dem Agententyp,
• der ausgeführten Aktion,
• den verwendeten Wissensquellen,
• der Anzahl und Art von Agenteninteraktionen,
• dem aktuell gültigen Microsoft-Abrechnungsmodell.

Ein Copilot Credit kann daher nicht automatisch mit einem Token eines Sprachmodells gleichgesetzt werden.

6. Lassen sich Copilot Credits in Euro umrechnen?

Eine pauschale Aussage wie text = 1 Copilot Credit = 0,01 EUR ist derzeit leider nicht möglich. Dies kann höhstens verwendet werden, wenn sie durch eine für das konkrete Produkt, die Region, den Vertrag und den Abrechnungszeitraum gültige Microsoft-Preistabelle belegt ist.

Eine allgemeingültige Umrechnung ist problematisch, wenn unterschiedliche Dienste eine unterschiedliche Anzahl von Credits verbrauchen oder Credit-Packs und Pay-as-you-go unterschiedlich bepreist werden.

Für eine belastbare Kostenprognose werden mindestens folgende Informationen benötigt:

1. Preis der Copilot Credits im konkreten Vertrag und in der gewählten Abrechnungsregion
2. Credit-Verbrauch pro unterstütztem Dienst oder Vorgang
3. erwartete Anzahl der Benutzer
4. erwartete Anzahl und Art der Vorgänge
5. vorhandene Capacity Packs
6. Verhalten nach Verbrauch vorhandener Capacity Credits
7. Steuern, Währung und gegebenenfalls Enterprise Agreement Discounts

Eine belastbare Formel sieht konzeptionell so aus:

text Monatliche Kosten = Anzahl der Vorgänge × Credits pro Vorgang × Preis pro Credit

Wenn der Verbrauch pro Vorgang variiert, sollte mit Szenarien gerechnet werden:

text Best Case Expected Case Worst Case

Ohne dokumentierte Werte für Credits pro Vorgang und Preis pro Credit ist ein Credit-Limit primär eine technische Verbrauchsgrenze, aber keine transparente Euro-Budgetgrenze. (https://gregorreimling.blob.core.windows.net/images/2026/08/2026-08-22-Copilot-Cowork-setup-succeeded.jpg)

7. Capacity Packs und Pay-as-you-go

Der Aktivierungsdialog weist sinngemäß darauf hin:

Wenn Credits aus Capacity Packs aufgebraucht sind, wechselt die Abrechnung zu Pay-as-you-go.

Das bedeutet:

1. Vorhandene Capacity Credits können zuerst verbraucht werden.
2. Nach deren Verbrauch kann die Nutzung über die verbundene Azure-Subscription weiterlaufen.
3. Das Umschalten auf Pay-as-you-go verhindert eine Dienstunterbrechung.
4. Ohne geeignete Limits kann dadurch zusätzlicher Azure-Verbrauch entstehen.

Dieser Fallback sollte bewusst als Governance-Entscheidung behandelt werden. Für einen Pilotbetrieb ist Kontinuität nicht immer wichtiger als Kostenbegrenzung.

8. Organisationsweites Spending Limit

Für eine neue Einführung sollte die Option text Limit the number of credits that the default policy can spend each month in der Regel gegenüber einer unbeschränkten Policy bevorzugt werden.

Wenn das Limit erreicht wird, können die der Policy zugeordneten Benutzer den Zugriff auf betroffene Agents und Dienste verlieren, bis das Credit-Kontingent entsprechend der Policy zurückgesetzt oder angepasst wird.

Das Limit ist damit auch eine Verfügbarkeitsentscheidung.

Ein zu niedriges Limit kann Geschäftsprozesse unterbrechen. Ein zu hohes oder unbegrenztes Limit erhöht hingegen das finanzielle Risiko.

Statt einen universellen Startwert zu behaupten, sollte das Pilotlimit anhand folgender Faktoren gewählt werden:

• Anzahl der Pilotbenutzer
• freigegebene Dienste
• vorgesehene Testszenarien
• dokumentierter Credit-Verbrauch
• akzeptiertes maximales Pilotbudget
• kritische oder unkritische Nutzung

9. Monatliches Limit pro Benutzer

Zusätzlich zur organisationsweiten Policy kann ein monatliches Spending Limit pro Benutzer sinnvoll sein.

Vorteile:

• Ein einzelner Benutzer kann nicht das gesamte organisationsweite Kontingent verbrauchen.
• Ausreißer werden begrenzt.
• Pilotgruppen lassen sich kontrollierter testen.
• Verbrauchsmuster pro Benutzer werden besser vergleichbar.
• Fehlkonfigurationen oder ungewöhnlich intensive Nutzung haben geringere Auswirkungen.

Das Benutzerlimit sollte kleiner als das organisationsweite Gesamtlimit sein und zur Anzahl der freigeschalteten Benutzer passen.

Beispiel für ein rein rechnerisches Pilotmodell:

text Organisationsweites Limit: 1.000 Credits Anzahl Pilotbenutzer: 10 Benutzerlimit: 100 Credits pro Benutzer

Dieses Beispiel ist keine Euro-Kostenschätzung. Es zeigt lediglich eine mögliche Aufteilung des Credit-Kontingents.

Für unterschiedliche Rollen können separate Policies oder Gruppen sinnvoll sein, sofern das Produkt dies unterstützt:

• normale Pilotbenutzer
• Agent-Entwickler
• Administratoren
• Power User
• produktive Fachbereiche

10. Benötigt Cowork eine Microsoft-365-Copilot-Lizenz?

Hier ist eine pauschale Ja-oder-Nein-Antwort riskant.

Microsoft unterscheidet unter anderem zwischen:

• Benutzerlizenzen für Microsoft 365 Copilot
• Funktionen von Copilot Chat
• nutzungsbasierter Abrechnung über Copilot Credits
• Copilot Studio beziehungsweise Agents
• Capacity Packs
• tenantseitig aktivierten Pay-as-you-go-Diensten
• gegebenenfalls Vorschau- oder Einführungsbedingungen für Cowork

Ob ein Benutzer Cowork verwenden kann und welche Funktionen enthalten sind, hängt vom aktuellen Angebot, der Lizenz, der Rollout-Welle, dem Tenant und der konfigurierten Abrechnung ab.

Vor der Kundenfreigabe sollten deshalb folgende Punkte geprüft werden:

1. Wird für Cowork eine Microsoft-365-Copilot-Benutzerlizenz verlangt?
2. Welche Funktionen sind in der Benutzerlizenz enthalten?
3. Welche Funktionen verbrauchen zusätzliche Copilot Credits?
4. Können Benutzer ohne Microsoft-365-Copilot-Lizenz über Pay-as-you-go zugreifen?
5. Welche Voraussetzungen gelten für Agents, Actions und Connectoren?
6. Gibt es Einschränkungen nach Region, Release Ring oder Preview-Status?

Die im jeweiligen Microsoft 365 Admin Center angezeigten Lizenz- und Abrechnungshinweise sollten dokumentiert werden.

11. Azure Resource Group

Wenn der Aktivierungsworkflow eine Resource Group verlangt oder eine Abrechnungsressource in Azure erstellt, empfiehlt sich eine dedizierte Resource Group.

Beispiel:

text rg-m365-copilot-payg-prod

Mögliche Vorteile:

• klare organisatorische Zuordnung
• einfachere RBAC-Verwaltung
• gezieltes Azure Policy Scoping
• bessere Sichtbarkeit in Cost Management
• saubere Tags
• nachvollziehbare Activity Logs
• Trennung von Azure OpenAI und Microsoft-365-Copilot-Verbrauch

Empfohlene Tags können sein:

Service       = M365-Copilot
Capability    = Cowork
Environment   = Production
CostCenter    = <Kostenstelle>
Owner         = <Verantwortliches Team>
DataClass     = Internal
ManagedBy     = CloudPlatform

Allerdings muss geprüft werden, ob die Kosten tatsächlich auf Ebene dieser Resource Group ausgewiesen werden. Einige SaaS- oder Marketplace-basierte Meter erscheinen in Azure Cost Management möglicherweise anders als klassische Azure-Ressourcen.

Eine eigene Resource Group verbessert die Governance, garantiert aber nicht automatisch eine vollständige Kostenisolierung.

12. Auswahl der Billing Region

Wenn der Assistent eine Billing Region verlangt, sollte diese Auswahl nicht automatisch mit der tatsächlichen Verarbeitungs- oder Datenresidenzregion gleichgesetzt werden.

Je nach Dienst kann die Region festlegen:

• wo eine Azure-Abrechnungsressource bereitgestellt wird,
• welches regionale Abrechnungsangebot verwendet wird,
• welche Ressourcenregion für die Verknüpfung gilt,
• welche Preise oder Steuern relevant sind,
• unter welchen Bedingungen der Dienst verfügbar ist.

Sie muss nicht zwangsläufig bestimmen:

• wo sämtliche Prompts verarbeitet werden,
• wo Microsoft-365-Daten gespeichert werden,
• über welche Region jeder Datenstrom läuft.

Vor der Auswahl sollten folgende Punkte geprüft werden:

1. Unterstützte Regionen des Dienstes
2. Datenresidenzbedingungen
3. EU Data Boundary
4. Preisunterschiede
5. verfügbare Azure-Regionen der Subscription
6. Anforderungen aus Datenschutz und Compliance
7. mögliche Netzwerkkosten
8. Auswirkungen auf Support und Betriebsmodell

13. Entstehen bei einer Region wie Schweden Traffic-Kosten?

Grundsätzlich kann Azure für ausgehenden Datenverkehr und regionsübergreifenden Datentransfer Gebühren berechnen.

Ob dies bei der Copilot-Spending-Policy tatsächlich relevant ist, hängt jedoch vom technischen Datenpfad ab.

Wenn die Region lediglich eine Billing- oder Metering-Ressource verankert, entsteht nicht automatisch ein kostenpflichtiger Datenstrom zwischen Deutschland und Schweden.

Wenn hingegen eigene Azure-Komponenten in unterschiedlichen Regionen kommunizieren, können Kosten entstehen, beispielsweise für:

• Inter-Region Data Transfer
• Internet Egress
• Datenverkehr zwischen Azure-Diensten
• angebundene APIs
• eigene Such-, Storage- oder Integrationskomponenten
• Azure Functions oder Logic Apps
• Azure OpenAI oder AI-Search-Ressourcen

Für eine belastbare Bewertung sollte nach Aktivierung in Azure Cost Management nach folgenden Meter-Kategorien gesucht werden:

Bandwidth
Data Transfer
Inter-Region Transfer

Auch die Azure-Preisübersicht für Bandbreite sollte für die eingesetzten Services geprüft werden.

14. Azure Cost Management richtig einsetzen

Zusätzlich zum Credit-Limit sollte ein monetäres Budget in Azure Cost Management eingerichtet werden.

Navigationspfad:

Azure Portal
→ Cost Management + Billing
→ Gewünschter Scope
→ Budgets
→ Add

Mögliche Benachrichtigungsschwellen:

• 50 Prozent
• 80 Prozent
• 100 Prozent
• zusätzlicher Forecast Alert

Wichtig: Ein Azure Budget ist normalerweise keine harte Ausgabensperre

Azure Cost Management Budgets senden Benachrichtigungen. Sie stoppen Ressourcen oder Pay-as-you-go-Verbrauch in der Regel nicht automatisch.

Deshalb gilt:

Ein Azure Budget ist ein Monitoring- und Alerting-Instrument, keine garantierte Kostensperre.

Eine tatsächliche Begrenzung muss über die Spending Policy, Benutzerlimits, Dienstkonfiguration, Automation oder andere produktspezifische Kontrollmechanismen erfolgen.

Mögliche ergänzende Maßnahmen sind:

• Action Groups für Budget Alerts
• Benachrichtigung an FinOps und Cloud Operations
• Azure Monitor Workbooks
• regelmäßige Kostenexports
• organisatorische Eskalationsprozesse
• automatisierte Reaktionen, sofern der Dienst und das Betriebsmodell dies sicher unterstützen

Automatisches Abschalten sollte nur mit großer Vorsicht eingesetzt werden. Es kann produktive Prozesse unterbrechen und möglicherweise nicht alle Kosten sofort stoppen.

15. Pilotmodell für eine kontrollierte Einführung

Eine sinnvolle Einführung kann in mehreren Phasen erfolgen.

Phase 1: Technische Validierung

Ziele:

• Abrechnung funktioniert
• Rollen und Berechtigungen sind korrekt
• Credit-Verbrauch wird sichtbar
• Kosten erscheinen im erwarteten Azure-Scope
• Audit- und Monitoringdaten stehen zur Verfügung

Maßnahmen:

• sehr kleine Administratorgruppe
• begrenzte Spending Policy
• begrenzte Benutzerlimits
• keine kritischen Geschäftsprozesse
• dokumentierte Testszenarien

Phase 2: Fachlicher Pilot

Ziele:

• reale Anwendungsfälle bewerten
• Nutzen und Qualität messen
• Kosten pro Szenario ermitteln
• Risiken und Datenzugriffe überprüfen

Mögliche Kennzahlen:

• Credits pro Benutzer
• Credits pro Auftrag
• Eurokosten pro Auftrag
• Zeitersparnis
• Erfolgsquote
• Anzahl notwendiger Korrekturen
• Benutzerzufriedenheit
• Anzahl sicherheitsrelevanter Auffälligkeiten

Phase 3: Produktive Einführung

Voraussetzungen:

• dokumentiertes Kostenmodell
• definierte Service Owner
• freigegebene Datenquellen
• Betriebs- und Supportmodell
• Incident-Prozess
• regelmäßige Access Reviews
• klarer Prozess zur Limitanpassung
• FinOps-Reporting
• Lifecycle-Prozess für Agents

16. Sicherheits- und Governance-Best-Practices

16.1 Least Privilege

Administratoren, Entwickler und Benutzer sollten nur die Berechtigungen erhalten, die für ihre Aufgaben erforderlich sind.

Empfehlungen:

• Azure-RBAC über Gruppen
• Entra PIM für privilegierte Rollen
• zeitlich befristete Rollenzuweisungen
• Approval für besonders kritische Rollen
• regelmäßige Access Reviews
• keine unnötigen permanenten Owner-Zuweisungen

16.2 Datenquellen kontrollieren

Agents und Cowork können nur so sicher sein wie die angebundenen Datenquellen und deren Berechtigungsmodell.

Vor einer Freigabe sollten geprüft werden:

• SharePoint-Berechtigungen
• Teams-Mitgliedschaften
• OneDrive-Sharing
• Sensitivity Labels
• DLP-Richtlinien
• externe Freigaben
• Connector-Berechtigungen
• Service Accounts
• Application Permissions
• Information Barriers

16.3 Oversharing reduzieren

Bestehendes Oversharing sollte vor einem breiten Copilot-Rollout reduziert werden.

Mögliche Maßnahmen:

• Site Ownership überprüfen
• „Everyone except external users“ kritisch bewerten
• anonyme Links einschränken
• veraltete Teams und Sites archivieren
• Access Reviews durchführen
• Sensitivity Labels einführen
• Restricted Content Discovery oder vergleichbare Steuerungsmöglichkeiten prüfen

16.4 Agent Lifecycle Management

Für Agents sollte ein geregelter Lebenszyklus definiert werden:

1. Anforderung
2. fachliche Bewertung
3. Security Review
4. Datenschutzprüfung
5. Entwicklung
6. Test
7. Freigabe
8. Veröffentlichung
9. Monitoring
10. regelmäßige Rezertifizierung
11. Außerbetriebnahme

Jeder Agent sollte mindestens folgende Metadaten besitzen:

• Owner
• fachlich verantwortliche Person
• technische Kontaktperson
• Zweck
• Zielgruppe
• Datenquellen
• Aktionen und Connectoren
• Datenklassifizierung
• Kostenstelle
• maximale Spending Policy
• Review-Datum

16.5 Logging und Audit

Je nach verfügbarem Funktionsumfang sollten überwacht werden:

• Änderungen an Spending Policies
• Azure-Rollenzuweisungen
• Agent-Veröffentlichungen
• Connector-Änderungen
• neue Datenquellen
• ungewöhnlicher Credit-Verbrauch
• fehlgeschlagene Aktionen
• Änderungen an Benutzerlimits

Die Verfügbarkeit und Aufbewahrungsdauer der Logs hängt von Lizenzierung und Dienst ab.

17. FinOps-Best-Practices

17.1 Credits und Euroverbrauch korrelieren

Nach Aktivierung sollten Credit-Verbrauch und Azure-Kosten regelmäßig gemeinsam ausgewertet werden.

Für jeden repräsentativen Anwendungsfall sollten erfasst werden:

Datum
Benutzer oder Testgruppe
Agent oder Dienst
Art des Auftrags
Anzahl der Vorgänge
verbrauchte Credits
Azure-Kosten
Ergebnisqualität

Daraus können tenant- und kundenspezifische Erfahrungswerte entstehen.

Beispiel:

Kosten pro erfolgreichem Vorgang =
Azure-Kosten des Szenarios
÷ Anzahl erfolgreicher Vorgänge

17.2 Forecast statt Bauchgefühl

Für die Planung sollten mindestens drei Szenarien erstellt werden:

Best Case:
Niedrige Nutzung und einfache Vorgänge

Expected Case:
Erwartete Nutzung und typische Vorgänge

Worst Case:
Hohe Nutzung, komplexe Agents und viele Aktionen

Ein Worst-Case-Szenario sollte durch technische Limits begrenzt werden, nicht nur durch E-Mail-Benachrichtigungen.

17.3 Showback oder Chargeback

Für größere Organisationen kann Verbrauch nach folgenden Dimensionen ausgewiesen werden:

• Fachbereich
• Kostenstelle
• Agent
• Benutzergruppe
• Umgebung
• Projekt
• Kunde

Ob dies nativ möglich ist, hängt davon ab, wie Microsoft die Copilot-Meter in Azure Cost Management darstellt. Fehlt eine ausreichende Granularität, kann ein ergänzendes internes Reporting erforderlich sein.

18. Häufige Stolperfallen

Aktivierungsbutton ist deaktiviert

Mögliche Ursachen:

• fehlende Azure-RBAC-Rechte
• fehlende Billing-Berechtigung
• falscher Entra-Tenant
• persönliche statt organisationsbezogene Subscription
• ungültiger oder nicht vollständig ausgefüllter Budgetwert
• Subscription nicht aktiv
• Backend- oder Portalproblem

Subscription ist sichtbar, aber nicht verwendbar

Die reine Sichtbarkeit beweist nicht, dass die Subscription für die Spending Policy zulässig ist. Tenant-Zuordnung, Vertragstyp und Rechte müssen separat geprüft werden.

Azure Budget wird als harte Sperre verstanden

Azure Cost Management Budgets stoppen den Dienst normalerweise nicht. Sie lösen Warnungen aus.

Credits werden mit Tokens gleichgesetzt

Copilot Credits sind nicht automatisch Azure-OpenAI-Tokens. Die Verbrauchslogik muss produktbezogen geprüft werden.

Benutzerlizenz wird mit vollständiger Kostenabdeckung gleichgesetzt

Eine Microsoft-365-Copilot-Lizenz bedeutet nicht zwingend, dass jede Agenten-, Cowork- oder Pay-as-you-go-Funktion ohne Zusatzkosten enthalten ist.

Billing Region wird mit Datenresidenz gleichgesetzt

Billing-, Ressourcen-, Verarbeitungs- und Datenresidenzregion können unterschiedliche Konzepte sein.

19. Empfohlene Checkliste

Vor der Aktivierung

• Business Owner benannt
• Service Owner benannt
• gewünschte Copilot-Funktionen dokumentiert
• Lizenzvoraussetzungen geprüft
• aktuelle Microsoft-Preise geprüft
• Credit-Verbrauch pro relevantem Dienst geprüft
• Azure-Subscription festgelegt
• Billing Owner eingebunden
• Mindestberechtigungen dokumentiert
• PIM für privilegierte Rollen eingerichtet
• Resource Group und Tags definiert
• Billing Region bewertet
• Datenschutz und Datenresidenz geprüft
• Pilotgruppe definiert

Bei der Aktivierung

• organisationsweite Spending Policy begrenzt
• Benutzerlimit konfiguriert
• Capacity-Pack-Fallback geprüft
• Pay-as-you-go bewusst aktiviert
• Azure Budget erstellt
• Budget Alerts konfiguriert
• Empfänger der Alerts getestet
• Aktivierung im Audit dokumentiert

Nach der Aktivierung

• Credit-Verbrauch sichtbar
• Azure-Kosten sichtbar
• Kosten-Scope validiert
• Resource Group beziehungsweise Billing-Ressource geprüft
• Bandwidth- und Data-Transfer-Meter geprüft
• erste Referenzszenarien getestet
• Kosten pro Szenario dokumentiert
• Benutzerfeedback erfasst
• Security Review durchgeführt
• Limits nach Messdaten angepasst

20. Fazit

Copilot Cowork kann einen Mehrwert bieten, wenn umfangreichere Wissensarbeit oder wiederverwendbare Arbeitsaufträge an Copilot delegiert werden sollen. Die Aktivierung ist technisch überschaubar, berührt aber mehrere Governance-Bereiche gleichzeitig:

• Microsoft-365-Lizenzierung
• Copilot Credits
• Azure Pay-as-you-go
• Azure RBAC
• Billing-Berechtigungen
• Kostenkontrolle
• Datenzugriff
• Agent Governance
• Datenschutz und Compliance

Die wichtigste Erkenntnis lautet:

Ein Credit-Limit ist nicht automatisch ein transparentes Euro-Budget, und ein Azure Cost Management Budget ist normalerweise keine harte Kostensperre.

Eine kontrollierte Einführung sollte deshalb mehrere Schutzebenen kombinieren:

1. begrenzte Pilotgruppe
2. organisationsweites Credit-Limit
3. benutzerspezifische Limits
4. Azure Cost Management Alerts
5. Least Privilege und PIM
6. kontrollierte Datenquellen
7. Messung von Credits und realen Azure-Kosten
8. Freigabe erst nach einem dokumentierten Kosten- und Governance-Modell

Erst wenn der reale Verbrauch der vorgesehenen Szenarien gemessen wurde, lässt sich gegenüber Kunden eine belastbare Kostenprognose vertreten.

Weiterführende offizielle Quellen

Da sich Produktnamen, Preise und Lizenzbedingungen ändern können, sollten im veröffentlichten Artikel aktuelle Links auf folgende Microsoft-Bereiche ergänzt werden:

• Microsoft Learn Dokumentation zu Copilot Credits
• Microsoft Learn Dokumentation zu Microsoft 365 Copilot
• Microsoft Learn Dokumentation zu Copilot Studio und Agents
• Microsoft Copilot Licensing Guide
• Microsoft Product Terms
• Azure Cost Management Dokumentation
• Azure Bandwidth Pricing
• Microsoft 365 Message Center Ankündigungen zu Cowork
• Microsoft Trust Center und EU Data Boundary Dokumentation

Die offiziellen Quellen sollten unmittelbar vor Veröffentlichung auf Aktualität, Region, Währung und Gültigkeit für den jeweiligen Vertrag geprüft werden.