Worauf Sie sich vorbereiten sollten — auch wenn Sie heute noch keinen Copilot haben

 

📋 MANAGEMENT SUMMARY — Was Sie in 5 Minuten wissen müssen

KI entwickelt sich schneller als Ihre Governance. Das ist keine Katastrophe — aber es ist ein strukturelles Risiko, das Sie kennen und aktiv managen müssen. Dieses letzte Kapitel des Buches ist der richtige Ort für eine ehrliche Prognose: Was kommt auf Sie zu, was bleibt stabil, und was müssen Sie konkret jetzt tun — unabhängig davon, ob Sie heute bereits Copilot im Einsatz haben oder nicht. Der wichtigste Begriff der nächsten zwei Jahre ist „Agentic AI“ — KI, die nicht mehr auf Anfragen wartet, sondern selbständig Ziele verfolgt, Werkzeuge einsetzt und Entscheidungen trifft. Microsoft hat das mit „Wave 3“ und dem Produkt „Agent 365“ auf seiner Roadmap. Das ist keine ferne Zukunft — es ist Produktplanung für 2026. Und es verändert die Risikokalkulation fundamental: Nicht mehr „was darf Copilot lesen“, sondern „was darf ein Agent TUN“. Die gute Nachricht: Das Fundament, das Sie heute für Copilot M365 aufbauen — saubere Berechtigungen, Purview-Labels, KI-Richtlinie, Betriebsvereinbarung — ist exakt dasselbe Fundament, das Sie 2027 für autonome Agents brauchen. Wer jetzt strukturiert aufbaut, hat einen echten Vorsprung. Wer wartet, startet 2027 mit dem gleichen ungeklärten Problem wie 2024 — nur mit mehr Risiko und weniger Zeit. Die drei Kernaussagen dieses Kapitels: Erstens, Agentic AI ist eine qualitativ andere Risikoklasse als reaktive KI — Agents handeln, Copilot antwortet. Zweitens, das Haftungsvakuum für KI-Agents ist real und wird frühestens 2026 durch die EU-Gesetzgebung gefüllt. Drittens, die fünf wichtigsten Sofortmaßnahmen sind unabhängig von Ihrem aktuellen KI-Reifegrad — und zahlen auf jede Entscheidung ein, die Sie in den nächsten zwei Jahren treffen werden.

 

11.1 Agentic AI — was sich grundlegend ändert

Stellen Sie sich vor, Sie delegieren eine Aufgabe an einen Kollegen. Nicht eine einzelne Frage — sondern ein Ziel. „Bereite den Quartalsbericht vor.“ Dieser Kollege weiß selbst, welche Schritte dafür nötig sind. Er sammelt Daten aus verschiedenen Systemen, schreibt Texte, formatiert Folien, schickt Entwurfsversionen an Reviewers, sammelt Rückmeldungen ein und liefert am Freitag das fertige Produkt. Sie müssen nicht jeden Schritt vorgeben. Sie müssen nicht nach jedem Teilschritt gefragt werden. Das Ergebnis erscheint, weil jemand — oder in diesem Fall etwas — das Ziel verfolgt und selbständig die Mittel wählt. Das ist agentic AI.

Copilot, wie er heute in M365 funktioniert, ist reaktiv. Sie stellen eine Frage, Copilot antwortet. Sie geben eine Aufgabe — „Fasse dieses Meeting zusammen“, „Drafte eine E-Mail“ — Copilot erfüllt sie. Einmalig, ohne Folgeschritte, ohne Gedächtnis über die nächste Session hinaus. Das Ergebnis liegt vor Ihnen, und Sie entscheiden, was damit passiert. Kein Schritt wird ausgeführt, ohne dass Sie ihn explizit freigeben. Das ist nützlich — aber es ist kein autonomes Handeln. Agents sind etwas anderes.

Ein KI-Agent hat vier Kernfähigkeiten, die ihn von einem einfachen Copilot-Assistenten unterscheiden. Erstens Planung: Er zerlegt ein Ziel in Teilschritte, erkennt Abhängigkeiten und priorisiert diese eigenständig. Zweitens Gedächtnis: Er erinnert sich, was er in früheren Schritten der gleichen Aufgabe getan hat, und nutzt diesen Kontext für Folgeentscheidungen. Im Unterschied zum heutigen Copilot kann dieser Kontext über Sitzungen hinaus bestehen bleiben. Drittens Werkzeuge: Er kann auf externe Systeme zugreifen. E-Mails senden. Kalendereinträge anlegen oder ändern. Dokumente verändern oder löschen. APIs externer Dienste aufrufen. Code ausführen. Und viertens Feedback-Loops: Er bewertet seine eigenen Zwischenergebnisse, erkennt wenn etwas nicht funktioniert, und korrigiert seinen Kurs — ohne auf eine neue Anfrage von Ihnen zu warten.

 

Abb. 11.1 — Agentic AI Architektur — Von der Benutzer-Anfrage bis zur autonomen Handlung: Jede Ebene erfordert eigene Governance-Maßnahmen, das rot markierte Approval-Gate ist die entscheidende Kontrollstelle

 

Das klingt eindrucksvoll. Es ist auch eindrucksvoll. Und es ist eine andere Qualität von Risiko — nicht nur eine höhere Menge des gleichen Risikos.

Ein Copilot, der falsch antwortet, ist ein Informationsproblem. Der Mensch liest die Antwort, bewertet sie, entscheidet, ob er ihr vertraut, und handelt danach. Die Handlung liegt beim Menschen. Ein Agent, der falsch handelt, ist ein Operationsproblem. Der Agent sendet die E-Mail, bevor Sie sie gelesen haben. Er bucht den Termin ohne Rückfrage. Er aktualisiert das Dokument. Er löscht die Datei. Er leitet die Zahlung ein. Alles unter Umständen, bevor Sie davon wissen — und einiges davon ist danach schwer oder gar nicht rückabwickelbar.

Das Kontroll-Paradox lautet: Je nützlicher ein Agent wird, desto mehr Autonomie braucht er — und desto weniger direkte Kontrolle haben Sie. Ein Agent, der bei jeder Aktion auf Ihre Bestätigung wartet, ist im Grunde nur ein besonders umständlicher Assistent, der Ihnen die Arbeit nicht abnimmt, sondern verdoppelt. Erst wenn er eigenständig handelt, entfaltet er den Wert, den man ihm zuschreibt. Und genau dann liegt die Frage offen: Wer ist verantwortlich? Wer haftet? Und vor allem: Wie wissen Sie, was der Agent getan hat?

Was das für Governance bedeutet, ist keine graduelle Verschiebung der gleichen Fragen. Es ist ein qualitativer Sprung. Bei Copilot M365 lautet die zentrale Governance-Frage: Was darf Copilot lesen? Welche Daten sind zugreifbar, welche sind durch Labels geschützt, welche sind durch Berechtigungen eingeschränkt? Das ist eine Frage der Datenlage und der Strukturierung von Zugriffsrechten. Bei Agents lautet die Frage: Was darf der Agent TUN? Welche Aktionen sind erlaubt, in welchem Kontext, mit welchen Schwellenwerten, ab wann braucht es eine menschliche Genehmigung, und wer ist verantwortlich wenn die Kette der Ereignisse, die ein Agent anstößt, zu einem Schaden führt? Das ist eine Frage der Policy-Definitionen, der Audit-Trails, der Haftungsregelung und der Eskalationspfade.

Ein praktisches Beispiel, das diese Verschiebung greifbar macht: Nehmen Sie den klassischen Copilot-Use-Case „Fasse meine E-Mails der letzten Woche zusammen“. Das ist reaktiv: Copilot liest, verarbeitet, gibt Ihnen Text aus. Sie entscheiden, was damit passiert. Nun der Agent-Use-Case der gleichen Funktion: „Verwalte meinen Posteingang. Beantworte Standard-Anfragen selbständig, eskaliere komplexe Fälle an mich, terminiere Folgetermine direkt, und erstelle bis Freitag einen Bericht über alle offenen Kundenanhänge.“ Der Agent liest nicht nur — er schreibt, er entscheidet, wer eine Antwort erhält, er verändert den Kalender und er erstellt selbständig ein Dokument. Jeder dieser Schritte kann einen Fehler produzieren, der Konsequenzen hat — rechtliche, geschäftliche, datenschutzrechtliche.

Sie müssen diese Governance-Fragen nicht heute abschließend beantworten. Vollständig autonome Agents in produktionsreifem Zustand für den allgemeinen Enterprise-Einsatz sind für die meisten Unternehmen noch sechs bis achtzehn Monate entfernt. Aber Sie müssen die Struktur kennen, bevor das Produkt da ist — denn die Struktur aufzubauen braucht Zeit, und Agents warten nicht darauf, dass Ihr Governance-Prozess aufgeholt hat. Wer 2026 mit Agent 365 konfrontiert wird und kein Framework hat, steht vor der gleichen Wahl wie jemand ohne Berechtigungskonzept bei der Copilot-Einführung: alles auf einmal lösen unter Zeitdruck.

 

Dimension	Copilot M365 (reaktiv)	KI-Agent (proaktiv / autonom)
Betriebsmodell	Antwortet auf Anfragen des Nutzers	Verfolgt Ziele selbständig über mehrere Schritte
Aktionstyp	Erzeugt Text, Zusammenfassungen, Vorschläge	Führt Aktionen aus: E-Mail, Kalender, Dokument, API
Menschliche Kontrolle	Mensch entscheidet vor jeder Folgehandlung	Agent entscheidet; Mensch genehmigt nur bei Risiko-Schwelle
Gedächtnis	Begrenzt auf aktuelle Sitzung	Dauerhaft über Aufgaben und Sitzungen hinweg
Fehlertyp	Falsche Information (korrigierbar vor Handlung)	Falsche Handlung (potenziell irreversibel)
Governance-Kernfrage	Was darf Copilot lesen?	Was darf der Agent TUN?
Haftungsklassifizierung	Klar: Mensch hat auf Basis der Antwort gehandelt	Unklar: Agent hat gehandelt, Mensch hat delegiert
Audit-Anforderung	Empfohlen für Compliance	Zwingend: lückenlose Protokollierung jeder Aktion

Tab. 11.1 — Copilot vs. Agent — Acht Dimensionen im Vergleich: Der Unterschied ist nicht graduell, sondern kategorial — Governance muss vor dem Rollout stehen, nicht danach

 

11.2 Wave 3 und Agent 365 — was Microsoft ankündigt und was davon realistisch ist

Microsoft strukturiert seine KI-Entwicklungsstrategie intern in sogenannten Waves — Entwicklungswellen, die jeweils neue Fähigkeiten auf eine breitere Nutzerbasis bringen. Wave 1 war der Copilot als Assistent: Er beantwortet Fragen, fasst Dokumente zusammen, hilft beim Schreiben von E-Mails und beim Erstellen von Präsentationen. Wave 2 brachte Copilot Studio und die ersten konfigurierbaren Agents: Unternehmen können eigene KI-Assistenten bauen, an Geschäftsprozesse ankoppeln und einfache Automatisierungen realisieren — auch ohne ML-Team, mit Low-Code-Werkzeugen. Wave 3 — das ist das, was Microsoft für 2026 und danach ankundet — soll autonome Agents mit dem Produkt „Agent 365“ und echten Multi-Agent-Orchestrierungsfähigkeiten bringen.

Was ist Agent 365 konkret? Nach dem Stand der Microsoft-Ankündigungen auf der Build 2024 und Ignite 2024 handelt es sich um eine neue Governance-Schicht für Agents im Enterprise-Umfeld. Drei Kernelemente wurden vorgestellt. Erstens eine Agent Registry: Ein zentrales Inventar aller im Tenant laufenden Agents, mit Informationen zu Berechtigungen, Verantwortlichen, Versions-Stand und Aktivitätsstatus. IT-Administratoren sollen damit überblicken können, welche Agents laufen, was sie tun und wer sie genehmigt hat. Zweitens delegierte Berechtigungen für Agents: Agents bekommen eigene Service-Prinzipal-Identitäten in Entra ID, mit spezifischen, eingeschränkten Zugriffsrechten — getrennt von den Benutzeridentitäten. Das bedeutet, dass ein Agent nicht einfach mit den Rechten des Nutzers operiert, der ihn ausführt, sondern nur mit den Rechten, die explizit für diesen Agent-Use-Case erteilt wurden. Drittens Genehmigungsworkflows: Definierte Schwellen, ab denen ein Agent eine menschliche Bestätigung braucht, bevor er eine Aktion ausführt. Das ist das Approval-Gate-Konzept, das die Kontrollfrage beim Einsatz autonomer Agents lösen soll.

 

Abb. 11.2 — Agent 365 Governance-Architektur — Rot markiert: Neue Governance-Aufgaben für IT-Leiter, die vor dem ersten produktiven Agent-Einsatz etabliert sein müssen

 

Was ist realistisch? Das ist die Frage, bei der Ehrlichkeit wichtiger ist als Begeisterung. Microsoft-Roadmap-Ankündigungen und tatsächliche GA-Termine haben eine gewisse historische Diskrepanz. Copilot M365 wurde mehrfach verschoben, bevor er im November 2023 tatsächlich allgemein verfügbar wurde. Copilot Studio ist heute verfügbar, aber produktionsreife Multi-Agent-Szenarien sind noch Preview-Features mit entsprechenden Einschränkungen in Stabilität und SLA. Agent 365 mit vollständiger Governance-Architektur ist für 2026 angekündigt — was bedeutet, dass es 2026 kommen oder auch 2027 kommen kann, mit Features, die den Ankündigungen entsprechen oder sie unterschreiten.

Was Sie heute trotzdem vorbereiten können, ist vollständig produktunabhängig. Die Governance-Struktur für Agents ist unabhängig vom konkreten Produkt. Wenn Sie heute definieren, welche Kriterien ein Agent erfüllen muss, bevor er in Ihrer Umgebung laufen darf — Sicherheitscheck durch IT, Datenschutzprüfung durch den DSB, Berechtigungsrevision, Genehmigung durch IT-Leiter, dokumentierter Use Case, definiertes Approval-Gate für risikoreiche Aktionen — dann haben Sie einen Prozess, den Sie auf jedes Agent-Produkt anwenden können. Ob es von Microsoft kommt, von einem Drittanbieter, oder aus Ihrer eigenen Copilot-Studio-Entwicklung.

Copilot Studio ist dabei der relevante Einstiegspunkt für viele Unternehmen heute. Mit Copilot Studio können Sie bereits jetzt eigene KI-Agenten für spezifische Anwendungsfälle bauen — ohne ML-Kenntnisse, mit Low-Code-Interfaces. Die Integration mit MCP (Model Context Protocol) ermöglicht es, Agents an externe Datenquellen und APIs anzuschließen. Das bedeutet: Wer heute einen Copilot-Studio-Agenten für eine spezifische Aufgabe deployt und dabei keine Agent-Policy, kein Audit-Trail und kein Genehmigungsverfahren hat, läuft bereits jetzt ohne Governance — nicht erst 2026.

 

Abb. 11.3 — Microsoft Copilot Evolution Wave 1 bis Wave 3 — Was wann verfügbar ist, was produktionsreif ist, und welche Governance-Anforderungen je Wave gelten

 

Merkmal	Wave 1 (2023)	Wave 2 (2024–25)	Wave 3 (2026+)
Grundprinzip	Reaktiver Assistent	Proaktive, konfigurierbare Agents	Autonome Multi-Agent-Orchestrierung
Verfügbarkeit	GA seit Nov 2023	Teils GA, teils Preview	Roadmap — noch nicht GA
Governance-Aufwand	Mittel: Richtlinien, DSGVO, BV	Hoch: Agent-Policies, Audit-Trails	Sehr hoch: Multi-Agent-Kontrolle, Haftungsregelung
Haftungsrisiko	Gering — Mensch entscheidet	Mittel bis hoch — Agent handelt für Nutzer	Sehr hoch und rechtlich ungeklärt
Wichtigste Voraussetzung	Berechtigungen, DSGVO, BV	+ Agent-Policies, Genehmigungsworkflows	+ Haftungsregelung, Notfall-Stopp, Rechtsberatung
Heute nutzbar?	✅ Ja, mit Governance-Basis	⚠️ Teils — mit zusätzlichem Aufwand	❌ Noch nicht GA — Governance jetzt planen

Tab. 11.2 — Wave-Vergleich — Governance-Anforderungen steigen mit jeder Generation: Das Fundament von heute trägt alle künftigen Wellen und erspart teure Nacharbeiten

 

⚠️ RISIKO — Roadmap-Gläubigkeit als Planungsrisiko

Microsoft ankündigt. Microsoft liefert — meist. Manchmal später als angekündigt, manchmal mit weniger Features als versprochen, manchmal mit anderen Preisen als kalkuliert. Wenn Ihre KI-Strategie auf einem bestimmten Feature aufbaut, das sich noch im Preview befindet, dann ist das ein Planungsrisiko — und kein kleines. Bauen Sie Ihre Strategie auf dem, was heute verfügbar und produktionsreif ist. Planen Sie den Rest als Option — nicht als Voraussetzung. Das bedeutet nicht, dass Sie Roadmap-Features ignorieren sollen. Es bedeutet: Treffen Sie keine unwiderruflichen Investitionsentscheidungen auf Basis von Features, die noch nicht GA sind. Wer heute einen teuren Prozess in Abhängigkeit von einem Preview-Feature aufbaut, und dieses Feature wird in sechs Monaten geändert, eingestellt oder hinter eine höhere Lizenzstufe verschoben, zahlt die Rechnung zweimal.

 

11.3 Haftung — wer haftet, wenn ein Agent einen Fehler macht

Das ist die Frage, bei der momentan niemand eine vollständig befriedigende Antwort hat. Nicht Microsoft, nicht die Rechtsabteilungen der Großkanzleien, nicht der EU-Gesetzgeber. Der EU AI Act regelt Haftungsfragen im Kontext von Hochrisiko-KI-Systemen, aber er klärt nicht abschließend, wer haftet, wenn ein Unternehmens-Agent im Low-Risk-Kontext eine fehlerhafte Entscheidung trifft, die zu einem Geschäftsschaden führt. Das allgemeine Produkthaftungsrecht und das allgemeine Haftungsrecht gelten, sind aber nicht auf diese Szenarien zugeschnitten. Die KI-Haftungsrichtlinie der EU ist noch nicht verabschiedet und wird voraussichtlich 2025 oder 2026 kommen. Kurz: Es gibt ein Haftungsvakuum.

Dieses Vakuum ist kein Freifahrtschein — es ist ein Unsicherheitsraum, der im Streitfall von Gerichten gefüllt wird. Im Zweifel wird das Gericht schauen, wer den Agent eingesetzt hat, wer ihn konfiguriert hat, wer ihn freigegeben hat und ob dabei die Sorgfaltspflichten eingehalten wurden, die man einem ordentlichen Unternehmer abverlangen kann. Wenn Sie diesen drei Fragen nicht mit Dokumentation begegnen können, liegt das Risiko bei Ihnen.

Die Antwort auf die Haftungsfrage ist daher nicht, auf Agents zu verzichten — sondern, die Grundlagen zu schaffen, die das Haftungsrisiko eingrenzen. Drei Werkzeuge stehen dafür heute bereit: Erstens Agent-Policies, die schriftlich fixieren, was ein Agent tun darf und was nicht. Zweitens Audit-Logs, die lückenlos protokollieren, welche Aktion ein Agent wann und auf wessen Veranlassung ausgeführt hat. Drittens Genehmigungsschwellen, die definieren, ab welchem Risikoniveau eine menschliche Bestätigung nötig ist — bevor der Agent handelt.

 

Abb. 11.4 — Haftungs-Entscheidungsbaum — Vier Fragen bestimmen, wer bei einem Agent-Fehler haftet: Die häufigste Antwort beim aktuellen Stand ist „unklar“ — was bedeutet, dass das Gericht entscheidet

 

Drei konkrete Szenarien illustrieren das Haftungsproblem. Erstens: Ein Agent sendet im Auftrag eines Mitarbeiters eine E-Mail an einen Kunden, die falsche Preise enthält. Der Mitarbeiter hat den Agenten mit dem Ziel konfiguriert, Kunden-E-Mails zu beantworten, aber die Preisliste, aus der der Agent die Daten gezogen hat, war veraltet. Der Kunde vertraut der E-Mail und bestätigt die Bestellung zum falschen Preis. Wer haftet? Der Nutzer für mangelhafte Konfiguration? Die IT-Abteilung für fehlende Datenqualitätsprüfung? Die Geschäftsführung für eine fehlende Agent-Policy, die externe Kommunikation mit Preisinformationen unter Genehmigungspflicht stellt?

Zweitens: Ein Agent löscht im Rahmen eines automatisierten Aufräum-Prozesses ein Dokument, das für eine laufende steuerrechtliche Prüfung aufbewahrt werden muss. Der Agent hat die konfigurierte Retention-Policy korrekt angewendet — das Dokument war älter als die Policy vorschreibt. Aber die Prüfungsanforderung war nicht in den Agent-Constraints abgebildet. Drittens, und das ist das gefährlichste Szenario: Ein Finanz-Agent führt eine Überweisung aus, die falsch parametriert war, weil die Stammdatenquelle, aus der er die Bankverbindung gezogen hat, einen Fehler enthielt. Der Agent hat getan was ihm gesagt wurde — nur die Eingangsdaten waren falsch.

Szenario	Wahrscheinliche Haftungsquelle	Risikominimierung durch Agent-Policy
Agent sendet Preise falsch an Kunden	Nutzer (Fehlkonfiguration) und IT (Datenqualität)	Externe Kommunikation: nur mit Approval-Gate
Agent löscht aufbewahrungspflichtiges Dokument	IT-Abteilung (fehlende Constraints) und Nutzer	Retention-Lock vor Löschung prüfen — Pflichtfeld
Agent führt fehlerhafte Transaktion aus	Alle Beteiligten anteilig — Haftungsklage absehbar	Finanztransaktionen: immer Mensch-Bestätigung, kein Agent
Agent greift auf nicht erlaubte Daten zu	Microsoft (Sandbox-Verletzung) und IT	Agent-Berechtigungen minimal — Least Privilege Prinzip
Multi-Agent-Fehler (Kaskade)	Unklar — Rechtsklima noch nicht gereift	Multi-Agent-Orchestrierung erst nach Rechtsberatung

Tab. 11.3 — Agent-Haftungsszenarien — Fünf typische Fehlersituationen und ihre Haftungseinschätzung: Die Dokumentation der Agent-Policy ist der wichtigste Schutzmechanismus

 

11.4 Das Tempo-Problem — warum schnelle Features zu langsamer Entscheidungskultur passen müssen

Microsoft veröffentlicht neue Features in einem Rhythmus, der mit den Governance-Prozessen der meisten Unternehmen strukturell nicht mithalten kann. Das ist keine Kritik an Microsoft — es ist die betriebswirtschaftliche Realität von Cloud-Software in einem Markt, in dem Google, Amazon und OpenAI den gleichen Rhythmus fahren. Wer langsamer ist, verliert Marktanteile. Das Ergebnis aus Nutzersicht: Im November 2024 wurden Copilot Actions ankündigt. Im Januar 2025 kamen neue Agent-Fähigkeiten in Copilot Studio. Im März 2025 wurden MCP-Integration und neue Tool-APIs vorgestellt. Und das ist nur ein Quartal.

Das Feature-Governance-Gap beschreibt das strukturelle Problem: Ein Feature ist live und für Nutzer sichtbar, bevor eine Policy existiert, die seinen Einsatz regelt. Ihre Mitarbeiter probieren es aus, weil es im Produktivitäts-Blogpost von Microsoft erwähnt wurde, weil der Kollege in der Nachbarabteilung schwärmt, weil es in der nächsten Teams-Session sichtbar ist. Ihre IT-Abteilung erfährt davon, wenn das erste Problem auftaucht. Ihr DSB hört davon, wenn es eine DSGVO-relevante Situation gibt. Das ist nicht böser Wille — es ist die natürliche Konsequenz einer fehlenden Governance-Struktur, die neue Features systematisch bewertet.

 

Abb. 11.5 — Autonomie-Spektrum — Von der Texthilfe zum Multi-Agent-System: Governance-Anforderungen steigen mit jeder Stufe — es gibt kein Überspringen von Stufen

 

Die Lösung ist nicht, langsamer zu werden. Es ist, eine Governance-Struktur aufzubauen, die neue Features systematisch bewertet, bevor sie breiter ausgerollt werden. Das bedeutet konkret: Feature-Gating. Neue M365-Features werden zunächst nur für eine definierte Pilot-Gruppe aktiviert. Die Pilot-Gruppe — idealerweise zehn bis zwanzig Personen aus verschiedenen Abteilungen, koordiniert durch einen IT-Ansprechpartner — erprobt das Feature im Alltagsbetrieb. IT und DSB bewerten die Erkenntnisse nach zwei bis vier Wochen. Dann kommt die Entscheidung: Breite Aktivierung, eingeschränkte Aktivierung oder Blockierung.

Microsoft selbst bietet dafür die Infrastruktur: Das Microsoft 365 Admin Center erlaubt über Release-Einstellungen, Features für ausgewählte Nutzer zu aktivieren, während sie für den Rest der Organisation noch nicht sichtbar sind. Das Copilot Admin Center hat eigene Steuerungsmöglichkeiten für Copilot-spezifische Features. Dieser Mechanismus ist in zehn Minuten konfiguriert. Was fehlt, ist der dahinterliegende Prozess: Wer entscheidet, welche Features in den Pilot kommen? Wer bewertet danach? Und nach welchen Kriterien?

Das richtige Tempo zu finden, ist eine Managemententscheidung, keine technische. Zu langsam bedeutet Wettbewerbsnachteil: Ihre Mitarbeiter nutzen nicht die Werkzeuge, die sie produktiver machen könnten, während Ihre Mitbewerber weiter sind. Zu schnell bedeutet Kontrollverlust: Neue Fähigkeiten werden produktiv, bevor ihre Risiken bekannt und ihre Governance-Anforderungen erfüllt sind. Das goldene Mittel liegt bei einem Feature-Gating-Prozess, der neue Agent-Fähigkeiten automatisch in eine Prüfphase bringt — und nur nach bestandener Prüfung weiter aktiviert.

ℹ️ TECHNISCHER HINTERGRUND — Feature-Gating in Microsoft 365 einrichten

Im Microsoft 365 Admin Center unter Einstellungen → Organisationsprofil → Release-Einstellungen stehen drei Modi zur Wahl: Standard-Release (alle Nutzer erhalten neue Features wenn sie GA sind), Targeted Release für ausgewählte Nutzer (definierte Gruppe erhält neue Features zuerst — empfohlen für Governance), und Targeted Release für alle (gesamte Organisation bekommt Features früher als Standard). Für sinnvolles Feature-Gating: Targeted Release auf eine IT-Pilotgruppe von zehn bis fünfzehn Personen, die neue Features zwei Wochen testen. Danach Entscheidung für breiten Rollout oder gezielte Blockierung. Copilot-spezifische Features können im Copilot Admin Center (admin.microsoft.com/AdminPortal/Home#/copilot) separat gesteuert werden. Agent-Features in Copilot Studio haben eigene Governance-Einstellungen unter Umgebungskontrollen. Purview-DLP-Policies können direkt auf Agent-Aktionen angewendet werden, um zu verhindern, dass Agents auf Daten zugreifen, die ihre Berechtigungen überschreiten.

 

11.5 Was stabil bleibt — worauf Sie jetzt investieren können

In einer Umgebung, in der sich Features monatlich ändern, Preise jährlich steigen und Regulierung noch im Entstehen ist, stellt sich die legitime Frage: Worauf kann ich mich verlassen? Worauf baue ich, ohne Angst, dass ich in zwei Jahren von vorne anfangen muss?

Die Antwort ist klar, auch wenn sie unspektakulär klingt: Auf die Plattform-Infrastruktur. Microsoft Entra ID — bis 2023 Azure Active Directory — existiert in verschiedenen Formen seit der Einführung von Azure im Jahr 2010 und in seinen Grundprinzipien seit Windows NT. Es ist so tief in alle Microsoft-Dienste integriert, dass eine fundamentale Änderung des Identitätskonzepts einer Neugestaltung der gesamten Produktlinie entsprechen würde. Was Sie in Entra ID aufbauen — Benutzergruppen, Zugriffsrichtlinien, Conditional Access, PIM-Rollenzuweisungen, Gastbenutzer-Reviews — wird auch 2028 noch funktionieren. Und: 2026 und 2027 werden Agent-Identitäten über Entra ID gesteuert. Wer Entra heute sauber hat, hat das Fundament für Agent-Governance.

Microsoft Purview und Sensitivity Labels sind ebenfalls stabil. Die Konzepte der Datenklassifizierung werden nicht verschwinden — sie werden wichtiger. Jeder Agent, der künftig auf Ihre Daten zugreift, wird auf Basis dieser Labels wissen — oder wissen sollen — welche Daten er wie verarbeiten darf. Wer Labels heute sauber aufsetzt, nach einem definierten Schema mit klarer Taxonomie, hat 2027 eine durchsetzbare Agent-Berechtigungssteuerung. Wer damit wartet, klassifiziert 2027 unter Zeitdruck und mit dem Druck des laufenden Agent-Betriebs im Hintergrund.

 

Abb. 11.6 — Technologie-Stabilitäts-Matrix — Grün: jetzt investieren, die Investition trägt langfristig; Gelb: bedingt stabil; Rot: schnell veränderlich, Entscheidungen verschieben

 

Microsoft Graph API ist der stabile Integrations-Layer, über den alle Microsoft-365-Dienste miteinander kommunizieren. Die v1.0-API-Endpunkte sind stabil — Microsoft verpflichtet sich vertraglich zu Abwärtskompatibilität dieser Endpunkte. Beta-Endpunkte dagegen können sich jederzeit ändern. Was Sie auf Graph v1.0 aufbauen — Integrationen, Monitoring-Lösungen, Custom Connectors, Automatisierungen — funktioniert langfristig. Das ist relevant wenn Sie eigene Geschäftsprozesse an M365-Daten anbinden wollen.

Ihre SharePoint-Berechtigungsstruktur ist ein besonderer Fall. Die Plattform selbst ist stabil — SharePoint gibt es seit 2001 und es wird solange es Microsoft gibt nicht verschwinden. Aber der Zustand, in dem Ihre Berechtigungen sich befinden, ist in den meisten Unternehmen alles andere als stabil: Gewachsen über Jahre, undokumentiert, mit Altlasten aus mehreren Migrationsrunden, Abteilungsumstrukturierungen und dem guten alten Prinzip „ich gebe dir kurz Zugriff und wir ändern das dann“. Was Sie heute in diesem Bereich bereinigen, bleibt — für Copilot, für Agents und für alle späteren KI-Vorhaben. Es gibt keine KI-Technologie, die das für Sie erledigt. Das ist Handarbeit. Manchmal mehrere Monate Handarbeit.

Was sich dagegen ändert und auf das Sie nicht allzu fest planen sollten: Die konkreten Feature-Oberflächen von Copilot. Was heute „Copilot Chat“ heißt, kann morgen einen anderen Namen tragen. Die Preismodelle und Lizenzstrukturen ändern sich regelmäßig — wie die Erhöhung von Juli 2026 zeigt, die Kapitel 9 beschreibt. Die spezifischen Agent-Fähigkeiten sind noch im schnellen Wandel, was Preview heute ist, kann GA morgen sein und deprecated übermorgen. Und die Details der Regulierung — konkrete Schwellenwerte im EU AI Act, spezifische Anforderungen aus der KI-Haftungsrichtlinie — werden sich in den nächsten zwei Jahren noch erheblich konkretisieren.

 

Abb. 11.7 — Zukunftsszenario 2027 — Das KI-gouvernierte Unternehmen: Drei Ebenen — Mitarbeiter-Agents, Governance-Schicht, stabiles Fundament. Nur Unternehmen mit dem Fundament können die oberen Ebenen sicher betreiben

 

💡 TIPP — Die Investitionshierarchie für IT-Leiter mit beschränktem Budget

Sofort und kostenarm: Berechtigungsaudit beauftragen — intern durch IT-Team oder extern durch Spezialisten. Identifiziert Oversharing-Risiken, verbessert Sicherheit und ist die Basis für jede KI-Entscheidung. Kurzfristig (ROI in 12 Monaten): Purview Sensitivity Labels einführen. Einmalige Investition in Taxonomie-Defintion und Rollout, die jede zukünftige KI-Entscheidung einfacher und sicherer macht. Mittelfristig (ROI in 24 Monaten): Entra ID aufräumen: PIM für privilegierte Rollen, Conditional Access für risikobasierte Authentifizierung, Guest Access Review automatisieren. Das Fundament für Agent-Identitäten. Bewusst abwarten: Spezifische Agent-Produkt-Entscheidungen, Lizenzmodell-Festlegungen, AI-Act-Detail-Compliance. Beobachten, Optionen offenhalten, aber keine unwiderruflichen Entscheidungen treffen.

 

Investition	Stabilität	KI-Relevanz heute	KI-Relevanz 2027	Empfehlung
Entra ID Aufräumen und Härten	Sehr hoch	Copilot-Berechtigungen steuern	Agent-Identitäten verwalten	✅ Sofort starten
Purview Sensitivity Labels	Hoch	Copilot-Datenzugriff einschränken	Agent-Policy-Enforcement	✅ Sofort starten
SharePoint-Berechtigungen bereinigen	Hoch	Oversharing verhindern	Agent-Datenzugriff kontrollieren	✅ Sofort starten
KI-Richtlinie schreiben	Mittel (Inhalt ändert sich)	Shadow AI und Nutzung regeln	Agent-Governance-Basis	✅ Sofort — aktualisierbar
Copilot M365 Pilotieren	Mittel	Direkte Produktivitätsgewinne	Erfahrungsbasis für Agents	✅ Nach Governance-Basis
Agent-Policies definieren	Mittel	Noch nicht dringend	Zwingend vor erstem Agent	⚠️ Bald planen
Spezifische Agent-Lizenzen kaufen	Gering	Noch nicht relevant	Abhängig von Wave-3-GA	❌ Abwarten

Tab. 11.4 — Investitionsempfehlungen nach Stabilität und KI-Relevanz — Die ersten vier Zeilen sind unabhängig von KI wertvoll und werden durch KI zusätzlich relevant

 

11.6 Jetzt handeln — konkrete Maßnahmen unabhängig vom KI-Reifegrad

Sie haben elf Kapitel gelesen. Sie wissen, wie Copilot auf Ihre Daten zugreift, warum Ihre Berechtigungsstruktur das entscheidende Fundament ist, was die DSGVO von Ihnen verlangt, welche Rolle der EU AI Act spielt, was CISOs nachts wachhalt und was Sie wirklich bezahlen werden. Das ist viel Wissen. Es gewährt Ihnen die Möglichkeit, eine gut informierte Entscheidung zu treffen. Aber es ersetzt die Entscheidung nicht.

Das Paradox des letzten Kapitels: Je mehr Sie wissen, desto überwältigender kann die Aufgabe wirken. Berechtigungsaudit, DSFA, Betriebsvereinbarung, KI-Richtlinie, Schulungen, Governance-Framework, Agent-Policies — das klingt nach einem Projekt, das sechs Monate dauert, bevor überhaupt etwas passiert. Das ist falsch. Das meiste davon können und müssen Sie in Wellen angehen. Und die erste Welle ist klein.

 

Abb. 11.8 — Risiko-Landkarte — Was passiert wenn Sie zwei Jahre nichts tun: Acht konkrete Risiken, ihre Wahrscheinlichkeit und Auswirkung — die rot markierten tragen Brußgeldrelevanz

 

Die fünf wichtigsten Maßnahmen, unabhängig davon ob Sie heute Copilot haben oder nicht:

Maßnahme 1: Berechtigungsaudit

Beauftragen Sie — intern oder extern — eine Übersicht, welche Nutzer auf welche SharePoint-Sites, OneDrive-Ordner und Teams-Kanäle Zugriff haben. Insbesondere: Wer hat Zugriff auf Verzeichnisse mit sensiblen Informationen — HR-Daten, Gehaltsstrukturen, Geschäftsführungskorrespondenz, Kundendaten? Wie viele Nutzer haben Vollzugriff auf Bereiche, die sie täglich nicht brauchen? Gibt es Freigaben an externe Nutzer, die nie aufgeräumt wurden? Gibt es Websites oder Teams, die niemand mehr aktiv nutzt, aber auf die noch hundert Personen Lesezugriff haben?

Dieses Audit nützt Ihnen mit oder ohne KI. Es ist gute IT-Hygiene und gute Sicherheitspraxis. Mit Copilot oder Agents wird es zum absoluten Sicherheits-Pflichtprogramm. Microsoft bietet dafür das Copilot Readiness Assessment Tool im Microsoft 365 Admin Center an, das speziell darauf ausgelegt ist, Oversharing-Risiken vor der Copilot-Einführung zu identifizieren. SharePoint Advanced Management ergänzt das mit granularen Berichten über Zugriffsstrukturen. Beides kostet nicht viel — aber beides zeigt Ihnen, was Sie wirklich haben.

Maßnahme 2: DSB einbinden

Nicht irgendwann. Jetzt. Ihr Datenschutzbeauftragter muss wissen, dass KI auf der Agenda steht — ob als laufendes Produkt, als geplante Einführung oder als erkanntes Shadow-AI-Problem. Die Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO greift frühzeitig, und ihre Vorbereitung dauert Wochen bis Monate. Wer den DSB erst nach der Lizenzbestellung einbindet, startet mit sechs Wochen Rückstand und einer gereizten Rechtsabteilung. Wer ihn nach dem ersten Incident einbindet, erklärt, warum er nicht vorher eingebunden war.

Was der DSB konkret braucht für den ersten Termin: Eine Beschreibung der geplanten oder laufenden Verarbeitung, einen Überblick über den Microsoft DPA (Data Processing Agreement), die Information über EU Data Boundary Status und eine ehrliche Einschätzung, welche personenbezogenen Daten in den Copilot-Kontext gelangen können. Das reicht für den ersten Termin und für eine erste gemeinsame Priorisierung der offenen Fragen.

Maßnahme 3: Betriebsrat informieren

Informieren — nicht fragen ob er einverstanden ist. Der Betriebsrat hat ein Mitbestimmungsrecht nach Paragraph 87 Abs. 1 Nr. 6 BetrVG, sobald KI zur Verhaltens- und Leistungsüberwachung eingesetzt werden kann. Das ist bei Copilot M365 der Fall, sobald Nutzungsdaten analysiert werden. Das ist bei Agents der Fall, sobald Agents im Namen von Mitarbeitern handeln. Frühzeitige Information und kooperative Einbindung — was sind die Bedenken des Betriebsrats, was muss in einer Betriebsvereinbarung stehen, welche Informationspflichten bestehen — sind der Unterschied zwischen einem Rollout der klappt und einem der drei Monate auf Eis liegt.

Die Betriebsvereinbarung muss nicht sofort fertig sein. Aber der Prozess zu ihrer Erstellung muss starten. Drei Monate Vorlaufzeit sind realistisch für eine gute Betriebsvereinbarung. Sechs Monate für eine sehr detaillierte. Für beides gilt: Wer nicht rechtzeitig startet, hat das Zeitproblem auf dem Tisch wenn der Roll-out-Termin drängt.

Maßnahme 4: KI-Richtlinie skizzieren

Sie brauchen keine fertige, juristisch geprüfte KI-Richtlinie als nächsten Schritt. Sie brauchen einen Entwurf, der drei Fragen beantwortet: Was sind erlaubte Verwendungen von KI-Tools im Unternehmen? Was ist verboten — insbesondere: welche Datentypen dürfen nicht in externe oder interne KI-Dienste eingegeben werden, die über Ihre Kontrolle hinausgehen? Und wer ist verantwortlich, wenn jemand gegen diese Regeln verstößt?

Dieser Entwurf kann eine Seite lang sein. Er muss nicht DSGVO-vollständig sein — das kommt in der nächsten Version. Er muss zunächst kommuniziert werden, damit Mitarbeiter wissen, dass es Regeln gibt und dass jemand zuständig ist. Die wichtigste Funktion dieses Entwurfs: Er signalisiert der Organisation, dass KI-Governance keine Einzelmeinung des IT-Leiters ist, sondern Unternehmenspolitik. Dieser Entwurf ist in vier bis sechs Wochen fertig, wenn jemand damit beauftragt ist und die Abstimmung mit DSB und Rechtsabteilung zeitnah erfolgt.

Maßnahme 5: IT-Team schulen

AI Literacy ist nicht nur ein Endnutzer-Thema. Ihr IT-Team braucht ein tiefes Verständnis dafür, wie Copilot intern funktioniert, wie Agents konfiguriert und genehmigt werden, welche Sicherheitseinstellungen welche Auswirkungen haben, wie Purview, Entra und Copilot zusammenspielen und welche Risiken bei welcher Konfiguration entstehen. Diese Kompetenz ist die Voraussetzung dafür, dass IT-Entscheidungen fundiert getroffen werden — und nicht auf Basis von Marketing-Folien oder dem Rat des Microsoft-Account-Teams, das naturgemäß Interessen hat.

Microsoft bietet Lernressourcen über Microsoft Learn, spezifische Trainings im Microsoft AI Cloud Partner Program und die Microsoft Copilot Academy. Die Investition in zwei bis drei Tage strukturiertes Training für das IT-Kernteam zahlt sich schneller zurück als die erste Copilot-Lizenz. Wer seine eigenen Werkzeuge nicht versteht, wird von deren Konsequenzen überrascht.

Ein oft unterschätzter Aspekt der IT-Schulung ist der Unterschied zwischen „ich weiß wie das Produkt heißt“ und „ich verstehe wie es funktioniert“. Copilot M365 ist für Endnutzer einfach zu bedienen — aber sein Verhalten wird durch Konfigurationen gesteuert, die nur IT-Administratoren sehen und ändern können. Berechtigungssteuerung, DLP-Policy-Enforcement, Entra ID-Integration, Audit-Log-Konfiguration, EU Data Boundary-Einstellungen — das alles liegt im IT-Bereich, nicht beim Nutzer. Ein IT-Team, das diese Stellschrauben nicht kennt, kann Risiken nicht einschätzen und Entscheidungen nicht begründen. Das ist das Schulungsdefizit, das behoben werden muss.

Eine konkrete Empfehlung für die Priorisierung: Beginnen Sie nicht mit einem Schulungspaket für alle Mitarbeiter. Beginnen Sie mit einem intensiven zweitägigen Workshop für das IT-Kernteam und den DSB gemeinsam. Das schafft eine gemeinsame Sprache, gemeinsame Risikobewertungen und — was oft wichtiger ist — gemeinsames Vertrauen. IT und DSB, die die gleiche technische Basis haben, arbeiten erheblich besser zusammen als zwei Parteien, die aneinander vorbeireden, weil die eine Seite technische Begriffe verwendet, die die andere nicht versteht.

 

Abb. 11.9 — Was jetzt zu tun ist — Vier Zeitrahmen, konkrete Aufgaben, klare Verantwortlichkeiten und die Begründung: Warum jetzt und nicht später

 

Maßnahme	Zeitaufwand	Wer ist verantwortlich	Warum jetzt und nicht später
1. Berechtigungsaudit beauftragen	2–4 Wochen für Befund	IT-Leiter	Copilot und Agents lesen was Ihre Struktur erlaubt — ohne Audit wissen Sie nicht was das ist
2. DSB einbinden	1 Termin, dann laufende Abstimmung	IT-Leiter gemeinsam mit DSB	DSFA-Pflicht und AVV brauchen Vorlauf — wer nach dem Incident anruft, hat das Problem
3. Betriebsrat informieren	1 Informationssitzung, dann BV-Prozess	IT-Leiter, GF und Betriebsrat	Mitbestimmungsrecht gilt ab erstem produktiven Einsatz — Betriebsrat kann stoppen
4. KI-Richtlinie skizzieren	4–6 Wochen für Entwurf	IT-Leiter koordiniert mit DSB und Recht	Shadow AI passiert ohne Regeln — und mit Konsequenzen die niemand will
5. IT-Team schulen	2–3 Tage Kernteam	IT-Leiter	Fundierte Entscheidungen erfordern Grundkompetenz — Marketing-Folien reichen nicht

Tab. 11.5 — Fünf Sofortmaßnahmen — Alle fünf sind unabhängig von KI sinnvoll. Alle fünf zahlen auf jede KI-Entscheidung der nächsten zwei Jahre ein. Keine setzt KI voraus — alle ermöglichen sie.

 

ℹ️ HINWEIS FÜR DSBs — Was jetzt in der Datenschutz-Dokumentation fehlt

Viele Datenschutzbeauftragte haben KI-Tools wie Copilot noch nicht im Verarbeitungsverzeichnis nach Artikel 30 DSGVO erfasst — weil die Frage „ist das überhaupt eine Verarbeitung?“ ungeklärt schien. Die Antwort ist: Ja. Copilot verarbeitet personenbezogene Daten, sobald Inhalte aus E-Mails, Teams-Chats oder Dokumenten mit Personenbezug in die Verarbeitung eingehen. Das ist der Regelfall im Unternehmenseinsatz. Was jetzt in der Dokumentation fehlt und nachgeholt werden sollte: Erstens ein Eintrag im Verarbeitungsverzeichnis für „Microsoft 365 Copilot / Azure OpenAI Service“ als Auftragsverarbeitung. Zweitens eine Prüfung, ob die bestehende DSFA für Microsoft 365 die Copilot-Nutzung abdeckt oder ob eine neue DSFA erforderlich ist. Drittens eine Überprüfung des bestehenden AVV mit Microsoft auf Vollständigkeit im Kontext von Copilot und künftigen Agent-Einsätzen. Viertens eine Einschätzung, welche Betroffenenrechte (Auskunft, Löschung) durch die Copilot-Nutzung tangiert werden und wie Auskunftsanfragen zu Copilot-verarbeiteten Daten beantwortet werden können. Agents vergrößern den Dokumentationsaufwand: Jeder Agent, der eigenständig Daten verarbeitet, ist eine eigenständige Verarbeitungstätigkeit. Wer fünf Agents betreibt, hat fünf zusätzliche Einträge im Verarbeitungsverzeichnis zu planen. Das ist kein bürokratischer Exzess — das ist die Konsequenz aus dem Grundprinzip der Rechenschaftspflicht nach Artikel 5 Abs. 2 DSGVO.

 

⚠️ RISIKO — Die Illusion des „wir beobachten das erst mal“

Es gibt eine Kategorie von Entscheidungen, die sich als Nichtentscheidung tarnt: Das Abwarten. „Wir beobachten das erst mal.“ „Wir schauen, was die anderen machen.“ „Wenn die Technologie ausgereift ist, springen wir auf.“ Das klingt vorsichtig und strategisch. Es ist beides nicht. Während Sie beobachten, nutzen Ihre Mitarbeiter ChatGPT, Perplexity, Claude und andere externe KI-Dienste — mit Ihren Unternehmensdaten, ohne Governance, ohne Audit-Trail. Während Sie abwarten, läuft die DSGVO. Während Sie schauen was andere machen, werden die anderen um sechs bis zwölf Monate Erfahrung schneller. Das Beobachten ist eine Entscheidung — mit konkreten Konsequenzen. Es ist nur keine bewusste. Und unbewusste Entscheidungen haben die unangenehme Eigenschaft, dass man sie später nicht erklären kann. Die Frage ist nicht ob Sie in den nächsten zwei Jahren mit KI in Berührung kommen werden. Sie kommen bereits in Berührung. Die Frage ist, ob das strukturiert passiert oder ungeplant.

 

Schlusswort — Die Entscheidung ist bereits gefallen

Es gibt Entscheidungen, bei denen das Treffen einer Entscheidung tatsächlich optional ist. Die KI-Entscheidung ist keine davon.

KI ist bereits in Ihren Unternehmen. In Form von Mitarbeitern, die ChatGPT für ihre Arbeit nutzen — mit oder ohne Ihr Wissen. In Form von Microsoft 365 Copilot, das — ob als Einzellizenz durch einen begeisterten Abteilungsleiter oder als breites Rollout durch die IT — irgendwann auf Ihrem Schreibtisch landet. In Form von Kundenanforderungen, die Lieferanten mit KI-unterstützten Prozessen stellen. In Form von Wettbewerbsdruck aus einer Branche, in der die Produktivitätsunterschiede zwischen KI-nutzenden und nicht-KI-nutzenden Unternehmen in den nächsten zwei Jahren sichtbar werden. Die Entscheidung „ob“ ist längst getroffen — von der Realität, nicht von Ihnen.

Die einzige verbleibende Entscheidung, die Sie noch selbst treffen können, ist: Strukturiert oder ungeplant? Mit Governance oder ohne? Mit einem Berechtigungskonzept, das auch ein Agent respektiert — oder mit einem Datenwust, der jedem System zur Verfügung steht, das groß genug ist um hineinzusehen? Mit einer KI-Richtlinie, die Ihre Mitarbeiter führt — oder mit dem ständigen Nachlaufen hinter Compliance-Problemen, die jemand anderes für Sie entdeckt?

Sie haben mit diesem Buch das Handwerkszeug für die strukturierte Variante. Die Fragen, die Sie beantworten müssen, sind nicht mehr abstrakt. Sie wissen, was die DSGVO von Ihnen verlangt und welche konkreten Schritte für eine DSFA nötig sind. Sie wissen, was der EU AI Act von Ihnen erwartet und bis wann. Sie wissen, wo die Haftungsrisiken bei KI-Agents liegen und wie Sie sie eingrenzen. Sie wissen, was Sie wirklich bezahlen werden — inklusive der Positionen, die in keinem Microsoft-Angebot stehen.

Was fehlt, ist der erste Schritt. Der erste Termin mit dem DSB. Das erste Gespräch mit dem Betriebsrat. Das erste Scope-Statement für den Berechtigungsaudit. Die erste E-Mail, in der Sie jemanden beauftragen, die KI-Richtlinie zu skizzieren. Diese Dinge machen sich nicht von selbst. Aber sie machen sich. Und wenn sie gemacht sind, haben Sie etwas, das die meisten Ihrer Mitbewerber nicht haben: Ein Fundament, das trägt. Für Copilot heute. Für Agents übermorgen. Für alles, was Microsoft und der Rest des Marktes nach Wave 3 noch ankündigen werden.

Der Rest ist Arbeit. Aber es ist Arbeit, die Sie jetzt kennen — und für die Sie jetzt das Werkzeug haben.

 

➡️ WAS JETZT ZU TUN IST — Der erste Tag nach diesem Buch

Dieses Buch endet. Ihr Arbeitsalltag geht morgen früh weiter. Hier ist, was auf dem Plan stehen sollte:   Diese Woche: Terminieren Sie drei Gespräche: eines mit Ihrem DSB, eines mit dem Betriebsratsvorsitzenden oder einem Mitglied, eines mit Ihrem IT-Kernteam. Agenda jeweils: „Wir reden über KI. Nicht ob — sondern wie.“ Zwei Stunden Ihres Kalenders und der Beginn von allem. Dieser Monat: Beauftragen Sie ein Berechtigungsaudit. Nicht irgendwann — beauftragen Sie es in den nächsten vier Wochen, mit einem konkreten Abgabedatum für den Befund. Intern durch das IT-Team oder extern durch einen Spezialisten. Das Ergebnis wird Sie überraschen — meistens unangenehm, aber besser jetzt als wenn Copilot läuft. Dieses Quartal: Schreiben Sie die erste Version Ihrer KI-Richtlinie. Eine Seite reicht für den Anfang. Sie wird sich ändern. Das ist in Ordnung. Das Entscheidende ist, dass sie existiert, kommuniziert wird und dass klar ist, wer bei Fragen und Verstomsständen verantwortlich ist. Dieses Jahr: Führen Sie einen strukturierten Copilot-Piloten durch — oder entscheiden Sie bewusst dagegen und dokumentieren Sie die Begründung. Beides ist akzeptabel. Nur das Nicht-Entscheiden ist es nicht.   Der Unterschied zwischen Unternehmen, die KI gut handhaben, und denen, die es nicht tun, ist kein technischer Unterschied. Es ist ein Governance-Unterschied. Und Governance entsteht nicht durch Abwarten — sie entsteht durch Entscheidungen, die jemand trifft, weil er oder sie die Verantwortung dafür übernimmt. Treffen Sie die Entscheidung.