Wie Sie die richtige Entscheidung treffen — strukturiert, nicht aus dem Bauch

 

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

KI-Entscheidungen werden in vielen Unternehmen falsch getroffen — nicht weil die Menschen dumm sind, sondern weil sie einem falschen Entscheidungsprozess folgen. Sie entscheiden zu früh, auf Basis unvollständiger Informationen, unter Druck von oben oder aus Angst, den Anschluss zu verlieren. Das Ergebnis: teure Piloten ohne Ergebnis, abgebrochene Rollouts, und IT-Leiter, die erklären müssen, warum die Investition nichts gebracht hat. Dieses Kapitel liefert den strukturierten Rahmen, den diese Entscheidungen brauchen. Nicht als akademisches Konstrukt — sondern als konkretes Werkzeug mit Checklisten, Entscheidungsbäumen und Go/No-Go-Kriterien. Die drei entscheidenden Fragen vor jeder KI-Entscheidung: Ist Ihre DSGVO-Basis geklärt? Haben Sie ein realistisches Budget für Jahr 1 inklusive Implementierung? Hat Ihr IT-Team die Kapazität für den Rollout? Wer alle drei mit Ja beantwortet, kann einen strukturierten Piloten starten. Wer eine mit Nein beantwortet, sollte das zuerst lösen. Die Entscheidung zwischen Copilot M365, Azure OpenAI-Eigenentwicklung und Copilot Studio ist keine Glaubensfrage, sondern eine Frage von Unternehmensgröße, vorhandener Kompetenz und spezifischen Anforderungen. Für 80 Prozent der Unternehmen ohne ML-Team und mit M365-Bestand ist Copilot M365 die richtige Wahl. Für den Rest gibt es eine Entscheidungsmatrix in Abschnitt 10.2. Der Stufenplan in 10.4 zeigt, wie ein Pilot aussehen soll, der tatsächlich Erkenntnisse liefert — und nicht nur ein teurer Proof-of-Concept ist, der in der Schublade endet.

 

10.1 Der Entscheidungsrahmen — wie man strategische KI-Entscheidungen strukturiert

KI-Entscheidungen sind anders als andere Technologieentscheidungen. Bei der Einführung eines neuen CRM-Systems oder eines Exchange-Upgrades haben Sie klare Anforderungen, einen definierten Lieferumfang und einen bewiesenen Track Record bei anderen Unternehmen. Bei Copilot und generativer KI haben Sie das alles nicht — zumindest nicht in der Form, die Sie gewohnt sind.

Was Sie stattdessen haben: Marketing-Versprechen mit ausgewählten Best-Case-Zahlen, eine schnell wechselnde Feature-Landschaft, unvollständige Compliance-Erfahrungen in der Branche und einen Vorstand, der "die KI-Strategie" will, aber noch nicht genau weiß, was das bedeuten soll. Das ist die Ausgangslage für die meisten Entscheider in Deutschland im Jahr 2026.

In dieser Ausgangslage treffen Unternehmen systematisch dieselben Fehler. Sie entscheiden zu früh, weil der Druck von oben so groß ist. Sie entscheiden auf Basis von Herstellerprasentätionen statt eigener Daten. Sie entscheiden, ohne die Compliance-Voraussetzungen geklärt zu haben. Oder sie entscheiden gar nicht — weil die Analyse nie endet und die Entscheidung im Abstimmungsprozess stirbt.

 

Die häufigsten Entscheidungsfehler

Der erste und häufigste Fehler ist die Entscheidung ohne vollständige Kosten. Unternehmen genehmigen die Lizenzkosten — 30 Euro pro Nutzer und Monat für 100 Nutzer sind 36.000 Euro im Jahr, das klingt überschaubar — und vergessen, dass Implementierung, Schulung, Governance-Dokumentation und IT-Betrieb im ersten Jahr leicht das 2,5-fache der reinen Lizenzkosten ausmachen. Der Anruf beim Controlling drei Monate nach dem Start, weil das Budget nicht reicht, ist ein bekanntes Muster.

Der zweite Fehler: Entscheidung ohne geklarte Voraussetzungen. Copilot wird aktiviert, bevor die DSFA abgeschlossen ist, bevor der Betriebsrat eingebunden wurde, bevor das Berechtigungskonzept geprüft wurde. Das ist nicht mutig — das ist fahrlässig. Die Konsequenzen reichen von Betriebsratsklage bis zu echten Datenschutzverletzungen.

Der dritte Fehler: das falsche Tool für die Anforderung. Copilot M365 ist ein Produktivitätswerkzeug für Wissensarbeiter mit hoher E-Mail- und Dokumentenlast. Wer einen spezifischen Geschäftsprozess automatisieren will, wer eigene Daten aus einer proprietären Datenbank einbinden muss oder wer hochsensible Daten hat, die nicht über die Graph-API laufen dürfen, braucht eine andere Lösung.

Und der vierte Fehler: die Entscheidung ohne klare Erfolgskriterien. Ein Pilot, bei dem vorab niemand definiert hat, was nach zwölf Wochen als Erfolg gilt, endet immer mit demselben Ergebnis: Die Enthusiasten sagen, es war gut. Die Skeptiker sagen, es hat nichts gebracht. Die Entscheidung über den Rollout wird vertagt.

 

Entscheidungsfehler	Symptom	Konsequenz	Wie vermeiden
Nur Lizenzkosten betrachtet	Budget reicht nach 3 Monaten nicht	Rollout gestoppt, IT-Leiter unter Druck	TCO-Kalkulation: Lizenz + 2,5× für Implementierung
DSGVO-Basis nicht geklärt	Datenschutzbeauftragter stoppt den Betrieb	Abschaltung mit juristischen Folgen	DSFA und Berechtigungsprüfung vor Pilot-Start
Falsches Tool ausgewählt	Copilot kann gewünschten Use Case nicht	Frustration, Lizenzen werden nicht genutzt	Use-Case-Analyse und Tool-Matching im Vorfeld
Kein Erfolgskriterium definiert	Pilot endet ohne Entscheidung	Geld ausgegeben, Status quo unverändert	Go/No-Go-Kriterien schriftlich vor Pilot-Start
Betriebsrat übergangen	Betriebsrat klagt auf Unterlassung	Produktionsstopp, Vertragskosten, Imageschaden	Betriebsrat frühzeitig und vollständig einbinden
Überhasteter Jahresvertrag	Pilot zeigt: Use Case nicht geeignet	Geld gebunden, keine Rücktrittsmöglichkeit	Monatliche Kündbarkeit für Pilot-Phase vereinbaren

Tab. 10.1 — Die sechs häufigsten KI-Entscheidungsfehler und wie man sie vermeidet

 

Der strukturierte Dreischritt

Eine gute KI-Entscheidung folgt einem einfachen Dreischritt: Analyse, Entscheidung, Umsetzungsplan. Klingt offensichtlich — wird aber überraschend selten eingehalten.

Die Analysephase klärt den Status quo: Wie sieht Ihre M365-Umgebung heute aus? Welche Lizenzen haben Sie bereits? Ist Ihr Berechtigungskonzept dokumentiert und geprüft? Haben Sie sensible Daten in SharePoint-Sites, auf die zu viele Personen zugreifen können? Wie ist der Reifegrad Ihrer Governance-Strukturen? Diese Fragen müssen beantwortet sein, bevor irgendeine Copilot-Entscheidung getroffen wird. Wer sie nicht beantworten kann, hat seine Hausaufgaben noch nicht gemacht.

Die Entscheidungsphase basiert auf einem vollständigen Bild: welches Tool für welche Anforderung, mit welchem Budget, für welche Nutzergruppe, mit welchen Erfolgskriterien, und mit welchem Go/No-Go-Mechanismus nach dem Pilot. Das ist keine PowerPoint-Entscheidung — das ist ein Dokument, das von IT-Leitung, DSB, Betriebsrat und Controlling gegengezeichnet wird.

Der Umsetzungsplan ist kein Wunschzettel, sondern ein Stufenplan mit konkreten Phasen, Meilensteinen und Entscheidungspunkten. Mehr dazu in Abschnitt 10.4.

 

Abb. 10.1 — Copilot-Entscheidungsbaum — strukturierter Entscheidungspfad von der ersten Frage bis zum Pilot-Start, mit konkreten Blocker-Kriterien und alternativen Pfaden

 

Abb. 10.2 — Was eine gute KI-Entscheidung auszeichnet — sechs Qualitätskriterien, die unterscheiden ob eine Entscheidung fundiert ist oder nur gut klingt

 

Was vor der Entscheidung feststehen muss

Für jede KI-Entscheidung, die über einen Piloten mit zwanzig Nutzern hinausgeht, müssen vier Dinge vor der finalen Entscheidung geklärt sein:

Status quo der Umgebung: Welche M365-Lizenzen sind vorhanden? Ist das Berechtigungskonzept dokumentiert und rezent geprüft? Gibt es bekannte Oversharing-Probleme? Wie viele Sensitivity Labels sind aktiv?

Budget für Jahr 1: Vollständige Kalkulation inklusive Lizenz, Implementierung, Schulung, externe Unterstützung und Governance-Dokumentation. Die Faustregel: Planen Sie mindestens das 2,5-Fache der reinen Lizenzkosten ein.

Governance-Bereitschaft: Ist eine KI-Richtlinie vorhanden oder in Arbeit? Ist der Betriebsrat informiert? Ist der Datenschutzbeauftragte eingebunden? Gibt es einen Verantwortlichen für die Governance?

IT-Kapazität: Hat Ihre IT-Abteilung mindestens 0,5 FTE für den Pilot und 1 FTE für den Rollout verfügbar? Wenn nicht: entweder verschieben oder externen Support beauftragen.

 

⚠️ RISIKO — Die Entscheidung unter Druck

Der gefährlichste Entscheidungspfad sieht so aus: Vorstand liest Artikel, fordert "KI-Strategie bis nächsten Monat", IT-Leiter genehmigt Piloten ohne vollständige Analyse, DSFA wird "parallel" nachgeholt, Betriebsrat wird "informiert" statt eingebunden. Sechs Monate später: Datenschutzverletzung oder Betriebsratsklage. Das ist kein hypothetisches Szenario. Es ist das Muster, das sich seit 2023 in deutschen Unternehmen wiederholt. Gegenmaßnahme: Setzen Sie einen festen Entscheidungsprozess auf — und kommunizieren Sie klar, welche Schritte vor dem Pilot-Start Pflicht sind. Nicht als Bürokratie, sondern als Schutz für alle Beteiligten — einschließlich des Vorstands.

 

10.2 Build vs. Buy — wann Azure OpenAI-Eigenentwicklung, wann Copilot

"Sollen wir das nicht lieber selbst bauen?" — diese Frage kommt immer. Meist aus der Entwicklungsabteilung, manchmal vom CTO, gelegentlich von jemandem, der gerade einen interessanten Blogbeitrag gelesen hat. Die Antwort ist nicht trivial, aber sie ist auch nicht so kompliziert, wie sie manchmal dargestellt wird.

Für die meisten deutschen Unternehmen ist Copilot M365 die richtige Wahl. Nicht weil es das beste aller denkbaren Systeme ist, sondern weil es das System ist, das mit dem vorhandenen M365-Ökosystem zusammenarbeitet, keine ML-Kompetenz intern voraussetzt und in einem überschaubaren Zeitrahmen produktiv eingesetzt werden kann. Wer eine gute Antwort braucht auf die Frage "Was macht unser KI-Produktivitätswerkzeug?", ist mit Copilot M365 gut bedient.

Azure OpenAI als Eigenentwicklung ist eine andere Entscheidung. Sie bedeutet: eigenes Team, eigene Infrastruktur, eigene Sicherheitsverantwortung, eigenes Testing, eigene Governance. Das ist kein Plug-and-Play — das ist ein Softwareentwicklungsprojekt. Wer das nicht einkalkuliert hat, wird von der Realität eingeholt.

Copilot Studio ist der Mittelweg: eigene Agenten und Workflows auf der Microsoft-Plattform, mit Low-Code-Werkzeugen und M365-Integration. Für Unternehmen, die spezifische Prozesse automatisieren wollen ohne ein ML-Team aufzubauen, ist das oft die pragmatischste Lösung.

 

Abb. 10.3 — Copilot M365 vs. Azure OpenAI vs. Drittanbieter-KI — Vergleich nach sieben Kriterien mit Ampelbewertung und konkreten Empfehlungen

 

Wann Copilot M365 die richtige Wahl ist

Copilot M365 ist das richtige Werkzeug, wenn Sie Wissensarbeiter mit hoher Kommunikations- und Dokumentenlast haben, die in Teams, Outlook, Word, Excel und PowerPoint arbeiten. Es ist das richtige Werkzeug, wenn Sie kein ML-Team haben und keines aufbauen wollen. Es ist das richtige Werkzeug, wenn Sie in drei bis sechs Monaten produktiv sein wollen und nicht in zwanzig.

Konkret profitieren folgende Nutzergruppen: Management und Führungskräfte mit hoher Meeting- und E-Mail-Last, Projektmanager, Analysten, Juristen, HR-Mitarbeiter, Vertriebsmitarbeiter. Was diese Gruppen gemeinsam haben: viel Kommunikation, viele Dokumente, viel Routine-Zusammenfassung — genau das, was Copilot gut kann.

Copilot M365 ist das falsche Werkzeug, wenn Sie spezifische Kerngeschäftsprozesse automatisieren wollen, die auf Daten basieren, die nicht in M365 sind. Wenn Ihre Anwendung ERP-Daten, CRM-Daten oder proprietäre Datenbanken braucht, muß Copilot Studio oder Azure OpenAI her.

 

Wann Azure OpenAI sinnvoll ist

Azure OpenAI Eigenentwicklung ist sinnvoll, wenn Sie sehr spezifische Anforderungen haben, die Copilot nicht erfüllen kann. Dazu gehören: hochspezialisierte Fachdomänen mit eigenen Wissensdatenbanken, Prozessautomatisierung auf Basis interner Datenquellen außerhalb von M365, hohe Anforderungen an Kontrolle und Nachvollziehbarkeit, oder regulatorische Vorgaben, die eine vollständige Datenhaltung in Ihrer eigenen Infrastruktur erfordern.

Die ehrliche Frage, die vor dieser Entscheidung gestellt werden muss: "Haben wir die ML-Kompetenz für Eigenentwicklung?" Gemeint sind mindestens zwei Machine-Learning-Engineers, ein Data Scientist und jemand, der die Infrastruktur betreiben kann. Wenn diese Rollen nicht vorhanden sind und auch nicht besetzt werden können, ist Azure OpenAI Eigenentwicklung keine realistische Option — es ist eine teure Lehrstunde.

 

Abb. 10.4 — Build vs. Buy Entscheidungsmatrix — wann welche Option für welche Unternehmensmerkmale geeignet ist

 

Kriterium	Copilot M365	Azure OpenAI	Copilot Studio
Minimale IT-Vorkenntnisse	M365-Administration	ML-Engineering, DevOps, Data Science	Power Platform, M365
Minimales Budget Jahr 1 (50 Nutzer)	Ca. 135.000€ inkl. Implementierung	200.000€+ Entwicklungsaufwand	Ca. 80.000€ inkl. Aufbau
Zeit bis Produktivbetrieb	2–4 Monate (Pilot)	6–18 Monate	3–6 Monate
Eigene Datenquellen einbindbar	Nur M365/Graph-API-Quellen	Beliebig (RAG, Vektordatenbanken)	Connector-Ökosystem (Power Platform)
Compliance-Aufwand	Gering (Microsoft verwaltet)	Hoch (eigene Verantwortung)	Mittel (Azure-Infrastruktur)
Langfristige Skalierbarkeit	Mit M365-Lizenzen	Vollständig anpassbar	Im Power-Platform-Ökosystem

Tab. 10.2 — Build vs. Buy — konkrete Anforderungen und Schwellenwerte im Vergleich

 

10.3 Selbst bauen — was das wirklich bedeutet

"Wir bauen das selbst mit Azure OpenAI" klingt nach Kontrolle und Unabhängigkeit. In der Praxis bedeutet es: Sie sind jetzt verantwortlich für alles. Das Modell. Die Infrastruktur. Die Sicherheit. Das Testing. Die Updates. Die Governance. Und die Erklärung gegenüber dem Datenschutzbeauftragten, warum das System eine bestimmte Antwort gegeben hat.

Das ist kein Argument dagegen — es ist die ehrliche Darstellung dessen, worauf Sie sich einlassen. Für Unternehmen mit den richtigen Ressourcen und den richtigen Anforderungen ist Azure OpenAI Eigenentwicklung die beste Lösung. Für Unternehmen, die das unterschätzt haben, ist es das teuerste Lehrprojekt ihrer IT-Geschichte.

 

Minimum-Ressourcen für Eigenentwicklung

Ein realistisches Eigenentwicklungsprojekt mit Azure OpenAI braucht mindestens folgende Ressourcen, bevor es in den Produktivbetrieb gehen kann:

ML-Engineering: Mindestens zwei Engineers mit nachweisbarer Erfahrung in Large Language Models, Prompt Engineering, Vektordatenbanken und RAG-Architekturen. Wenn Sie diese Rollen nicht haben: rechnen Sie sechs bis neun Monate für Recruiting oder 400€+ pro Tag für externe Experten.

Data Engineering: Ein Data Scientist oder Data Engineer, der die Datenpipeline aufbaut — vom Rohdatenimport über die Bereinigung bis zur Einbindung in die Vektordatenbank. Schätzen Sie drei bis sechs Monate allein für diesen Schritt.

Security Engineering: Jemand, der die Azure-Sicherheitsarchitektur verantwortet, Zugriffsrechte definiert und regelmäßig überprüft. Kein Nice-to-have — Pflicht.

Projektleitung: Jemand, der das Projekt steuert und zwischen den technischen Teams, dem Fachbereich, dem DSB und dem Betriebsrat koordiniert.

Initialer Zeitaufwand: Planen Sie mindestens zwölf Monate bis zum ersten produktionsreifen System. Sechs Monate ist machbar — aber nur wenn alle oben genannten Rollen von Tag eins besetzt sind.

 

Warum Eigenentwicklungen scheitern

Die Mehrzahl der Azure OpenAI Eigenentwicklungsprojekte in mittelständischen Unternehmen scheitert. Nicht weil Azure OpenAI schlecht ist — sondern weil die Voraussetzungen nicht erfüllt waren. Die drei häufigsten Scheitergründe:

Erstens: unterschätzter Aufwand. "Das ist doch nur eine API" — ja, aber die API ist nicht das Problem. Das Problem ist die Datenpipeline, das Prompt Engineering, das Testing, die Governance-Dokumentation und der laufende Betrieb. Alle diese Schritte sind aufwendiger als geschätzt.

Zweitens: fehlende Data-Governance. Eine KI ist nur so gut wie ihre Daten. Wer keine Datenqualität, kein Datenmanagement und keine klaren Regeln darüber hat, welche Daten in das System dürfen, wird ein System bauen, das unzuverlässige oder datenschutzwidrige Ergebnisse produziert.

Drittens: kompetenz-loses Scaling. Der erste Prototyp funktioniert. Der erste Produktionseinsatz scheitert an Skalierungsproblemen, Sicherheitslücken oder Modell-Drift. Die ML-Experten, die den Prototyp gebaut haben, sind mittlerweile in anderen Projekten. Das Wissen ist weg.

 

RAG: Wie eigene Unternehmensdaten sicher eingebunden werden

Retrieval Augmented Generation — RAG — ist das Schlagwort für die Technik, die eigene Unternehmensdaten sicher in einen LLM-basierten Dienst einbindet. Das Grundprinzip: das Sprachmodell bekommt keine rohen Datenbankzugriffe, sondern bekommt relevante Textpassagen aus einer vorher aufbereiteten Wissensdatenbank zugespielt — nur die Passagen, die für die konkrete Anfrage relevant sind.

Das klingt einfacher als es ist. Die praktischen Herausforderungen: Dokumente müssen aufbereitet und in Chunks segmentiert werden. Metadaten müssen gepflegt werden. Die Retrieval-Qualität muss regelmäßig gemessen werden. Und die Zugriffskontrolle muss gewährleisten, dass Nutzer über die KI nicht auf Dokumente zugreifen können, auf die sie direkt keinen Zugriff hätten.

Copilot Studio bietet eine Low-Code-Variante dieser Architektur: eigene Agenten können auf SharePoint-Dokumente, externe APIs und andere Datenquellen zugreifen — innerhalb der M365-Sicherheitsinfrastruktur. Das ist kein vollständiges RAG-System, aber für viele Anwendungsfälle ausreichend und mit erheblich weniger Aufwand verbunden.

 

💡 TIPP — Copilot Studio als pragmatischer Einstieg in eigene Agenten

Wenn Sie eigene Geschäftsprozesse mit KI unterstützen wollen, ohne ein ML-Team aufzubauen, ist Copilot Studio oft der richtigere erste Schritt als Azure OpenAI Eigenentwicklung. Sie bleiben in der Microsoft-Infrastruktur, nutzen bestehende M365-Compliance-Mechanismen, und können eigene Agenten mit Power Platform-Kenntnissen aufbauen. Was Copilot Studio kann: eigene Chatbots auf SharePoint-Wissen, Prozessautomatisierung mit Power Automate-Integration, Anbindung externer APIs, eigene Agenten-Workflows. Was es nicht kann: vollständig maßgeschneiderte KI-Modelle, Einbindung beliebiger externer Datenbanken ohne Connector, hochspezialisierte Domänenanpassungen. Die Entscheidungsregel: Wenn Ihr Anwendungsfall in Copilot Studio machbar ist — starten Sie dort. Azure OpenAI-Eigenentwicklung ist für Anforderungen, die Copilot Studio nicht erfüllen kann.

 

Aspekt	Was Copilot Studio kann	Was Azure OpenAI bietet	Unterschied
Datenquellen	SharePoint, M365, Power Platform-Connectoren	Beliebige Quellen über RAG und APIs	OpenAI flexibler, aber mehr Aufwand
Anpassung	Prompts, Workflows, Geschäftslogik per Low-Code	Vollständige Kontrolle bis zum Modell	OpenAI tiefergehend anpassbar
Compliance	M365-Infrastruktur, fertige DPA	Azure-Infrastruktur, eigene Verantwortung	Studio einfacher konform
Betrieb	Microsoft verwaltet Plattform	Eigenes Team notwendig	Studio wartungsärmer
Zeitaufwand initial	3–6 Monate bis Produktivbetrieb	6–18+ Monate	Studio deutlich schneller
Kosten Jahr 1 (Pilotumfang)	Geringer (Power Platform inkludiert)	Höher durch Entwicklungsaufwand	Studio kostengünstiger initial

Tab. 10.3 — Copilot Studio vs. Azure OpenAI Eigenentwicklung — was wo sinnvoll ist

 

10.4 Der Stufenplan — Pilot, Rollout, Vollbetrieb

Ein Stufenplan ist kein Selbstzweck. Er ist das Werkzeug, das sicherstellt, dass Sie am Ende des Piloten eine fundierte Entscheidung treffen können — und nicht eine emotionale. Wer keine klare Struktur hat, fährt nach dem Pilot entweder mit Begeisterung weiter, obwohl die Zahlen das nicht rechtfertigen, oder er beendet einen Piloten, der tatsächlich funktioniert, weil die internen Skeptiker lauter waren als die Daten.

 

Abb. 10.5 — Stufenplan: Vorbereitung, Pilot, Rollout Welle 1, Rollout Welle 2, Vollbetrieb — mit Aktivitäten und Go/No-Go-Kriterien pro Phase

 

Phase 0: Vorbereitung (4–6 Wochen)

Phase 0 ist keine administrative Pflichtübung — sie ist die Phase, in der alles schiefgeht, wenn sie übersprungen wird. Die vier Pflichtaufgaben:

Erstens: die DSFA abschließen. Nicht "beginnen", nicht "weitgehend abschließen" — abschließen. Mit Freigabe durch den Datenschutzbeauftragten. Wenn das vier Wochen dauert: gut. Wenn es acht Wochen dauert: auch gut. Copilot ohne abgeschlossene DSFA zu aktivieren ist ein behebbares Problem, das aber häufig zu einem unbehebbaren Vertrauensverlust führt.

Zweitens: den Betriebsrat einbinden. Das bedeutet nicht, eine E-Mail zu schicken. Es bedeutet, ein Meeting zu führen, die technischen Details zu erklären, Fragen zu beantworten und eine Betriebsvereinbarung zu erarbeiten oder zumindest einen verbindlichen Zeitplan dafür zu vereinbaren. Vier Wochen bis zwölf Wochen sind typische Zeitrahmen für diesen Prozess.

Drittens: die Pilotgruppe definieren. 20 bis 50 Nutzer, Wissensarbeiter mit hoher E-Mail- und Meeting-Last, aus unterschiedlichen Abteilungen. Keine reinen Enthusiasten — sonst messen Sie nur, wie sehr Enthusiasten KI lieben. Keine reinen Skeptiker — sonst messen Sie nur, wie wenig Skeptiker KI nutzen. Ein repräsentatives Sample des Unternehmens.

Viertens: die Governance-Dokumentation und die Lizenzen. KI-Richtlinie in Erstfassung, Sensitivity Labels konfiguriert, Berechtigungsaudit abgeschlossen. Ohne das: No-Go für Phase 1.

 

Phase 1: Pilot (8–12 Wochen)

Der Pilot ist kein "Mal ausprobieren". Er ist ein strukturiertes Experiment mit einem klar definierten Ziel: zu entscheiden, ob ein Rollout gerechtfertigt ist. Das erfordert:

Klare Erfolgskriterien vor dem Start. Schriftlich. Unterschrieben. Mindestens: Aktivierungsrate nach vier Wochen, Nutzerzufriedenheit nach acht Wochen, dokumentierte konkrete Anwendungsfälle, keine kritischen Sicherheitsvorfälle. Mehr dazu im nächsten Abschnitt.

Wöchentliche Messung und dokumentierte Erkenntnisse. Kein "gefühlt gut", keine anekdotischen Erfolgsgeschichten. Zahlen aus dem M365-Admin-Center, Feedback aus Kurzumfragen, dokumentierte Anwendungsfälle.

Ein Go/No-Go-Meeting nach acht bis zwölf Wochen, in dem die Erfolgskriterien bewertet werden. Dieses Meeting wird von der IT-Leitung geleitet, der DSB ist anwesend, das Controlling ist informiert. Das Ergebnis ist eine schriftliche Empfehlung: Rollout empfohlen, Rollout nicht empfohlen, oder Pilot verlängern mit konkreten Nacharbeitspunkten.

 

Abb. 10.6 — Pilot-Erfolgsmessung: fünf Metriken mit Messmethode, Go-Schwellenwert und Signalwert für die Rollout-Entscheidung

 

Erfolgskriterien für den Pilot

Kriterium	Messmethode	Go-Schwellenwert	No-Go-Signal
Aktivierungsrate	M365-Admin-Center, wöchentlich	≥60% nach Woche 4, ≥75% nach Woche 8	Unter 40% nach Woche 6
Nutzerzufriedenheit	Wöchentliche Kurzumfrage (3 Fragen)	≥3,5 / 5,0 oder NPS ≥20	Unter 3,0 / 5,0 konstant
Dokumentierte Anwendungsfälle	Qualitative Interviews, 5–10 Nutzer	≥3 konkrete Einsparungsbeispiele	Keine belegbaren Beispiele
Sicherheitsvorfälle	SIEM, Purview-Reports, Stichproben	0 kritische Vorfälle	Jeder kritische Vorfall = No-Go
IT-Supportlast	Helpdesk-Ticketsystem	<2 Tickets/Nutzer/Monat nach Woche 4	Dauerhaft >4 Tickets = Schulungsproblem

Tab. 10.4 — Pilot-Erfolgskriterien mit konkreten Go/No-Go-Schwellenwerten

 

💡 TIPP — Die Pilot-Gruppe richtig zusammenstellen

Der typische Fehler bei der Pilotgruppen-Auswahl: Man nimmt die Begeisterten. Die, die schon in der ersten Woche fragen, wann es losgeht. Das Problem: Enthusiasten messen nicht, ob Copilot für Ihr Unternehmen funktioniert. Sie messen, ob Copilot für Enthusiasten funktioniert. Das ist eine andere Frage. Eine repräsentative Pilotgruppe enthält: 30% Early Adopters (die Enthusiasten), 50% repräsentative Nutzer aus verschiedenen Abteilungen mit realer Arbeitslast, 20% Skeptiker. Wenn die Skeptiker nach acht Wochen sagen, es hat ihnen geholfen, haben Sie ein starkes Argument für den Rollout. Wenn nur die Enthusiasten begeistert sind: Vorsicht.

 

Phasen 2–4: Rollout und Vollbetrieb

Phase 2 — Rollout Welle 1 (6–8 Wochen) — beginnt erst nach einem positiven Go aus Phase 1. Sie weitet die Einführung auf erste Abteilungen aus, typischerweise die mit der höchsten Affinität zum Pilot. Kritisch in dieser Phase: das Schulungsprogramm muss stehen, bevor die ersten Nutzer aktiviert werden. Copilot ohne Schulung führt zu Frustration, Fehlnutzung und supportintensivem Betrieb.

Phase 3 — Rollout Welle 2 (4–6 Wochen) — weitet auf die restlichen Abteilungen aus. Bis hier sollten Governance-Dokumentation, Supportstruktur und Schulungskonzept vollständig etabliert sein. Compliance-Check und Lizenzoptimierung sind Pflichtaufgaben dieser Phase: Welche Lizenzen werden wirklich genutzt? Welche können reduziert werden?

Phase 4 — Vollbetrieb — ist kein Endzustand, sondern ein kontinuierlicher Prozess. Quartalsreviews, Nutzungsmessungen, Governance-Updates wenn neue Features von Microsoft eingeführt werden, Schulungen für neue Mitarbeiter. Copilot ist keine einmalige Investition — es ist ein laufendes Betriebsthema.

 

Phase	Dauer	Voraussetzung für Start	Hauptaufgaben	Go-Kriterien für nächste Phase
Phase 0: Vorbereitung	4–6 Wochen	Budget genehmigt, IT-Kapazität verfügbar	DSFA, Betriebsrat, Pilotgruppe, Lizenzen, Governance-Dok.	DSFA freigegeben, BR zugestimmt, Pilotgruppe definiert
Phase 1: Pilot	8–12 Wochen	Phase-0-Checkliste abgehakt	20–50 Nutzer live, wöchentliche Messung, Go/No-Go-Meeting	≥60% Aktivierung, ≥3,5/5 Zufriedenheit, 0 kritische Vorfälle, 3+ Anwendungsfälle
Phase 2: Rollout Welle 1	6–8 Wochen	Positives Go aus Phase 1	Erste Abteilungen, Schulungsprogramm, Support-Struktur	>70% Adoption Welle 1, Schulung abgeschlossen
Phase 3: Rollout Welle 2	4–6 Wochen	Welle-1-Adoption >70%	Restliche Abteilungen, Lizenzoptimierung, Compliance-Check	Vollständiges Rollout abgeschlossen
Phase 4: Vollbetrieb	Dauerhaft	Welle-2-Abschluss	Quartalsreviews, ROI-Messung, neue Features, neue MA schulen	Quartals-Review-Prozess etabliert

Tab. 10.5 — Stufenplan im Überblick: Phasen, Voraussetzungen und Go-Kriterien

 

ℹ️ ENTSCHEIDUNGS-CHECKLISTE — Vor dem Pilot-Start

Checkliste für die IT-Leitung — alle Punkte müssen erfüllt sein: □ DSFA abgeschlossen und vom DSB freigegeben □ Betriebsvereinbarung oder verbindlicher Zeitplan dafür vorhanden □ Budget für Jahr 1 vollständig genehmigt (inkl. Implementierung und Schulung) □ Pilotgruppe (20–50 Nutzer) definiert und informiert □ Erfolgskriterien schriftlich definiert und von IT-Leitung unterschrieben □ Berechtigungskonzept geprüft, bekannte Oversharing-Probleme behoben □ IT-Kapazität (min. 0,5 FTE) für Pilot-Begleitung verfügbar □ Go/No-Go-Meeting-Termin nach Woche 8–12 eingetragen □ Kommunikationsplan für Pilotgruppe erstellt □ Schulungsunterlagen für Pilotgruppe vorbereitet   Punkte, die noch nicht erfüllt sind, werden — mit Datum und Verantwortlichem — dokumentiert. Erst wenn alle Punkte abgehakt sind, wird Phase 1 gestartet. Kein Punkt ist optional.

 

💡 TIPP — Wie Sie den Rollout intern kommunizieren

Technisch perfekte Rollouts scheitern an schlechter interner Kommunikation. Die häufigsten Fehler: Ankündigung per E-Mail ohne Erklärung des Nutzens, keine Antwort auf die Frage "Was ändert sich für mich?", und fehlende Unterstützung für die, die Schwierigkeiten haben. Bewährtes Kommunikationsformat pro Phase: Eine Seite Erklärung was Copilot ist und was es nicht ist. Drei konkrete Anwendungsbeispiele aus dem eigenen Unternehmen. Eine klare Aussage über Datenschutz und was mit den Daten passiert. Und eine Kontaktperson für Fragen. Mehr braucht es nicht. Den Satz „KI überwacht Sie nicht“ müssen Sie in jedem Rollout mindestens dreimal sagen. Er ist immer der erste Gedanke. Sagen Sie ihn proaktiv, nicht reaktiv.

 

Was einen misslungenen Pilot von einem erfolgreichen unterscheidet

Die Unterschiede zwischen Piloten, die zu einem erfolgreichen Rollout führen, und solchen, die im Nichts enden, sind überraschend konsistent. Erfolgreiche Piloten haben einige Merkmale gemeinsam, die mit der Technologie selbst wenig zu tun haben.

Erstens: konkrete Use Cases vor dem Start. Nicht „Wir probieren mal, was Copilot so kann“ — sondern: „Wir testen, ob Copilot uns hilft, Meeting-Protokolle in unter fünf Minuten zu erstellen, Kundenmails zu kategorisieren und Angebote zu erstellen.“ Konkrete Use Cases ermöglichen konkrete Messung. Vage Use Cases ermöglichen nur vage Ergebnisse.

Zweitens: einen Pilot-Champion in der Nutzergruppe. Jemand — kein IT-Mitarbeiter, sondern ein Fachbereichsnutzer — der die Gruppe von innen begleitet, Fragen beantwortet, Tipps teilt und Feedback zur IT trägt. Diese Person ist wertvoller als jedes Schulungsvideo.

Drittens: schnelle Reaktion auf Feedback. Wenn die Pilotgruppe meldet, dass ein bestimmtes Feature nicht funktioniert oder verwirrend ist, braucht es eine Reaktion innerhalb von 48 Stunden. Nicht notwendigerweise eine Lösung — aber eine Antwort. Piloten, in denen Feedback ins Leere läuft, verlieren die Nutzer nach vier Wochen.

Viertens: transparente Go/No-Go-Kommunikation. Die Pilotgruppe sollte wissen, nach welchen Kriterien über den Rollout entschieden wird. Das schafft Commitment: Die Nutzer wissen, dass ihr Feedback tatsächlich die Entscheidung beeinflusst.

 

Die Kostenfrage im Vollbetrieb

Was viele Unternehmen unterschätzen: die Kosten im Vollbetrieb sind höher als im Pilot. Nicht durch versteckte Gebühren, sondern durch drei Faktoren, die im Pilot noch nicht sichtbar waren.

Erstens: Lizenzoptimierung ist keine Einmalinvestition. Wer Copilot für 200 Nutzer einführt und nach sechs Monaten feststellt, dass 40 davon kaum aktiv sind, muss entscheiden: weiterbezahlen oder Lizenzen reduzieren? Microsoft-Lizenzen haben typischerweise Jahreslaufzeiten mit festen Kontingenten. Die Optimierung erfordert regelmäßige Überprüfung und Planung.

Zweitens: der Schulungsaufwand hört nicht auf. Neue Mitarbeiter müssen eingearbeitet werden. Neue Features — Microsoft aktualisiert Copilot regelmäßig — erfordern erneute Kommunikation. Und Nutzer, die anfänglich Schwierigkeiten hatten, brauchen manchmal einen zweiten Anlauf.

Drittens: Governance-Updates sind Pflicht, keine Option. Wenn Microsoft neue Copilot-Features einführt, müssen Sie prüfen, ob diese Features Ihre bestehende DSFA und KI-Richtlinie berühren. Das ist kein großer Aufwand — aber es ist ein Aufwand, der eingeplant sein muss.

 

Kostenfaktor	Erstjahr (Pilot + Rollout)	Folgejahre (Vollbetrieb)	Risiko bei Vernachlässigung
Lizenzkosten (100 Nutzer)	Ca. 36.000 €/Jahr (30 €/Nutzer/Monat)	Gleich oder steigend (Preisanpassungen)	Budgetierungslücke bei Preiserhöhungen
Implementierung & Konfiguration	10.000–30.000 € einmalig	Gering (laufende Anpassungen)	Technische Schulden bei fehlender Pflege
Schulung & Change Management	5.000–15.000 €	2.000–5.000 €/Jahr (neue MA, neue Features)	Sinkende Adoption, Support-Eskalationen
Governance & Compliance	3.000–8.000 €	1.000–3.000 €/Jahr	DSGVO-Risiko bei nicht aktualisierten DSFAs
IT-Betrieb & Support	0,5 FTE im Rollout	0,2 FTE im Vollbetrieb	Support-Stau, unzufriedene Nutzer
Berechtigungsaudit (einmalig)	3.000–8.000 €	Keine laufenden Kosten	Oversharing-Risiko, wenn nicht durchgeführt

Tab. 10.6 — Vollständige Kostenkalkulation Copilot M365 — Erst- und Folgejahre für 100 Nutzer

 

Wann ist die Entscheidung für Copilot die falsche?

Diese Frage wird selten gestellt. Aber sie gehört in jeden Entscheidungsprozess, der sich ernst nimmt.

Copilot ist die falsche Entscheidung, wenn Ihr Unternehmen primär in Google Workspace arbeitet und keine Migration zu M365 plant. In diesem Fall zahlen Sie für eine tiefe Integration in eine Umgebung, die Ihre Mitarbeiter kaum nutzen. Die Produktivitätsgewinne bleiben aus.

Copilot ist die falsche Entscheidung, wenn Ihre Kernprozesse auf Datenquellen basieren, die nicht in M365 sind und auch nicht in M365 gebracht werden können. Ein Maschinenbauer, dessen relevante Daten in einem SAP-System stecken, dem niemand Zugriff geben will, wird mit Copilot M365 keine relevanten Produktivitätsgewinne erzielen.

Copilot ist die falsche Entscheidung, wenn die DSGVO-Basis nicht klärbar ist — etwa weil das Unternehmen in einer hochregulierten Branche mit spezifischen Datenlokalisierungsanforderungen tätig ist, die Microsoft nicht erfüllen kann oder will.

Und Copilot ist die falsche Entscheidung, wenn niemand in der Organisation die Governance dauerhaft betreiben will. Eine KI-Richtlinie, die einmal erstellt und nie aktualisiert wird, ist kein Schutz — sie ist eine Häftung. Wenn Sie nicht bereit sind, Governance als Dauerthema zu behandeln, sollten Sie Copilot nicht einführen.

 

⚠️ RISIKO — Das Abwarten-Risiko: wann Nichtstun die schlechtere Entscheidung wird

Es gibt ein Gegenrisiko zum überhasteten Entscheiden: das Abwarten. Unternehmen, die den KI-Entscheid immer wieder vertagen, laufen in ein Problem, das erst in zwei bis drei Jahren sichtbar wird, aber sich jetzt aufbaut. Das Problem heißt Kompetenzlücke. Während Ihr Unternehmen wartet, sammeln Ihre Wettbewerber, Ihre Kunden und Ihre Mitarbeiter KI-Erfahrung. Die Lernkurve für die effektive Nutzung generativer KI beträgt sechs bis zwölf Monate. Je später Sie anfangen, desto länger dauert es, bis Sie diese Kurve hinter sich haben. Das zweite Abwarten-Risiko ist die Mitarbeiterbindung. Qualifizierte Wissensarbeiter — besonders jüngere Mitarbeiter — suchen zunehmend nach Arbeitgebern, die moderne Werkzeuge anbieten. „Wir evaluieren das noch“ ist keine attraktive Antwort auf die Frage, warum das Unternehmen kein KI-Werkzeug hat. Das bedeutet nicht, dass Sie überstürzt entscheiden sollen. Es bedeutet, dass auch Abwarten eine Entscheidung ist — mit Konsequenzen, die kalkuliert werden müssen.

 

➡️ WAS JETZT ZU TUN IST — Die nächsten Schritte

Unabhängig davon, wo Sie gerade stehen, gibt es drei konkrete nächste Schritte: 1. Entscheidungsrahmen einrichten: Setzen Sie eine Arbeitsgruppe aus IT-Leitung, DSB und Controlling auf. Auftrag: Standortbestimmung nach der Checkliste in diesem Kapitel — was ist erfüllt, was fehlt, was dauert wie lange. Zeitrahmen: zwei Wochen. 2. Build-or-Buy klären: Beantworten Sie die Fragen aus Abschnitt 10.2 für Ihr Unternehmen: Welche Use Cases haben Sie konkret? Haben Sie ML-Kompetenz intern? Was ist Ihr Budget für Jahr 1? Die Antworten auf diese drei Fragen entscheiden zwischen Copilot M365, Copilot Studio und Azure OpenAI. 3. Phase-0-Plan erstellen: Wenn Copilot M365 die richtige Wahl ist, erstellen Sie sofort einen Phase-0-Plan: DSFA-Zeitplan, Betriebsrats-Kontakttermin, Pilotgruppen-Vorschlag. Das dauert maximal eine Woche und gibt Ihnen Klarheit darüber, wie lange es bis zum Pilot wirklich dauert.   Was Sie nicht tun sollten: warten, bis alle Fragen beantwortet sind. Manche Fragen beantworten sich nur im Pilot. Was Sie aber auch nicht tun sollten: loslegen, bevor die Pflichtvoraussetzungen erfüllt sind. Der Mittelweg heißt: Phase 0 jetzt starten — und Phase 1 erst starten, wenn Phase 0 komplett ist. Die Unternehmen, die Copilot 2026 erfolgreich einsetzen, haben nicht schneller entschieden als die anderen. Sie haben strukturierter entschieden.

 

 

KAPITEL 11