Wie Sie ein Governance-Framework aufbauen, das funktioniert

 

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

Governance ist kein Selbstzweck. Ohne strukturierten Rahmen endet jede KI-Einführung in einer Mischung aus Shadow AI, Haftungsrisiken und verärgertem Betriebsrat. Mit einem soliden Framework dagegen wissen alle Beteiligten, was erlaubt ist, wer entscheidet, wie Vorfälle gemeldet werden — und wer die Kosten trägt. Das Governance-Framework für KI besteht aus vier Bausteinen: Struktur (wer entscheidet), Richtlinie (was gilt), Prozess (wie läuft es ab) und Messung (was funktioniert). Alle vier müssen vorhanden sein. Drei von vier reichen nicht. Der kritische Erfolgsfaktor ist das Pilotprojekt. Ein Pilot mit 10–25 Personen, klaren Abbruchkriterien und sauberer Evaluation gibt Ihnen eine valide Entscheidungsgrundlage für den Rollout — und schlägt jedes Consultant-Deck mit geschwungenen Kurven und Hochglanzzahlen. Die Fallstudie Musterwerk GmbH in diesem Kapitel zeigt, was in der Praxis passiert: zwei Schritte vorwärts, einer rückwärts, und am Ende trotzdem ein funktionierendes Ergebnis — weil der Governance-Rahmen gehalten hat, als es darauf ankam. Zeitbedarf für einen ersten Governance-Aufbau: 4–6 Wochen bis zur einsatzfähigen Grundstruktur. Ein Pilot dauert weitere 8 Wochen. Tag 90 ist realistisch für eine fundierte Rollout-Entscheidung.

 

4.1 Was „Governance“ bedeutet — und was es nicht ist

Das Wort Governance löst in Unternehmens-Meetings zverlässig zwei Reaktionen aus. Die erste Reaktion kommt von Managern, die schon mehrere ISO-Zertifizierungsprojekte überlebt haben: ein leises Stöhnen, das professionell als Nachdenken verkleidet wird. Die zweite Reaktion kommt von Beratern: ein Aufleuchten der Augen, das wenig mit intellektuellem Interesse und viel mit Tagesatz zu tun hat.

Beide Reaktionen sind verständlich. Beide sind falsch.

Governance ist kein Projekt. Es ist kein Dokument. Es ist keine ISO-Norm. Governance ist der strukturierte Antwortrahmen auf die Frage: Wie stellen wir sicher, dass KI in unserem Unternehmen das tut, was wir wollen — und nicht das, was wir nicht wollen?

Diese Frage klingt banal. Sie ist es nicht. Denn „was wir wollen“ und „was wir nicht wollen“ müssen explizit definiert sein — und zwar so, dass ein Mitarbeiter in der Buchhaltung sie lesen und verstehen kann, ohne vorher einen Kurs in IT-Governance belegt zu haben.

Das Governance-Paradox: Zu wenig kostet mehr als zu viel

Es gibt eine Theorie, die in KI-Projekten regelmäßig bestätigt wird: Wer Governance als Bremse betrachtet und deshalb darauf verzichtet, zahlt später ein Vielfaches. Nicht in Projektbudget, sondern in Krisenmanagement, Rechtskosten und dem schwer bezifferbaren Schaden an der internen Glaubwürdigkeit der IT.

Das ist das Governance-Paradox. Die Unternehmen, die am wenigsten Zeit in Governance investieren, verbringen später die meiste Zeit damit, die Folgen mangelnder Governance zu reparieren. Datenpannen, Betriebsrat-Konflikte, abgebrochene Rollouts, Mitarbeiter die heimlich Tools nutzen und damit Daten nach außen tragen — all das hat eine gemeinsame Wurzel: niemand hat sich vorher die Mühe gemacht, klare Regeln aufzustellen.

Ein konkretes Zahlenbeispiel hilft, die Relation zu verstehen. Ein ordentlicher Governance-Aufbau für ein mittelständisches Unternehmen mit 500 Mitarbeitern kostet zwischen 40.000 und 70.000 Euro einmalig — inklusive externer Beratung, Schulung, IT-Anpassungen und Personalzeit. Das klingt viel. Ein einziger DSGVO-Bußgeldbescheid wegen unzureichender Datenschutz-Folgenabschätzung kann das Vielfache kosten. Ein Betriebsrat-Rechtsstreit der einen Rollout um drei Monate verzögert kostet im IT-Overhead — je nach Unternehmensgröße — zwischen 30.000 und 150.000 Euro in verschwendeter Ressource. Die Governance-Investition ist günstig im Vergleich zu dem, was sie verhindert.

Was Governance kosten darf, ist übrigens auch eine Governance-Frage. Das Budget muss realistisch sein. Ein Governance-Framework auf dem Papier, das aber nie mit Ressourcen unterlegt wird, ist schlechter als gar kein Framework — weil es die Illusion erzeugt, man hätte das Problem gelöst. Ein Lenkungsausschuss der sich nie trifft ist kein Lenkungsausschuss. Eine KI-Richtlinie die nie kommuniziert wird ist keine Richtlinie. Ein KI-Koordinator ohne Zeit ist kein KI-Koordinator.

Abb. 4.1 — Ohne Governance vs. Mit Governance: konkreter Vergleich der Konsequenzen

Was Governance konkret leistet — und was nicht

Eine gute KI-Governance leistet genau fünf Dinge:

Sie definiert, welche KI-Tools erlaubt sind und welche nicht — vollständig und nachvollziehbar.

Sie legt fest, wer für welche Entscheidungen verantwortlich ist — mit echten Namen, nicht mit Berufsbezeichnungen.

Sie regelt, wie mit Vorfällen umgegangen wird — bevor ein Vorfall passiert, nicht danach.

Sie definiert, was gemessen wird und wie der Fortschritt berichtet wird — für Vorstand, Betriebsrat und Mitarbeiter gleichermaßen.

Sie ermöglicht schnelle Anpassungen, wenn sich die Rechtslage oder die Technologie ändert — und das wird passieren.

 

Was Governance explizit nicht ist: eine Verbotssammlung, die Innovation verhindert. Wer eine KI-Richtlinie schreibt, die hauptsächlich aus Verboten besteht, hat das Konzept missverstanden. Verbote ohne Alternativen führen zu Shadow AI. Mitarbeiter nutzen dann einfach ihr privates ChatGPT-Konto — mit Unternehmensdaten, ohne Protokollierung, ohne Rückrufmöglichkeit, und die DSGVO wartet geduldig auf ihren Auftritt.

Der Unterschied zwischen IT-Governance und KI-Governance ist erheblicher als er auf den ersten Blick scheint. IT-Governance regelt Systeme und Prozesse — wer hat Zugriff auf welche Daten, welche Software darf installiert werden, wie werden Backups gemacht. KI-Governance regelt zusätzlich Verantwortung für Entscheidungen: Wer haftet, wenn Copilot eine fehlerhafte Zusammenfassung eines Vertrags erstellt, auf deren Basis ein Mitarbeiter eine falsche Entscheidung trifft? Eine IT-Policy gibt darauf keine Antwort. Eine KI-Richtlinie muss es.

ℹ️ TECHNISCHER HINTERGRUND — Was eine KI-Richtlinie rechtlich absichert

Eine KI-Richtlinie ist mehr als ein internes Dokument. Sie ist der Nachweis gegenüber Aufsichtsbehörden, dass das Unternehmen seiner Sorgfaltspflicht nachgekommen ist. Konkret: Gegenüber der Datenschutzbehörde: Nachweis, dass Art. 25 DSGVO (Datenschutz durch Technikgestaltung) umgesetzt wurde — die Richtlinie zeigt, dass personenbezogene Daten nicht unkontrolliert in KI-Systeme fließen dürfen. Gegenüber dem Betriebsrat: Grundlage für die Betriebsvereinbarung nach §87 Abs. 1 Nr. 6 BetrVG, die vor dem Einsatz technischer Überwachungseinrichtungen (und Copilot fällt darunter) erforderlich ist. Im Haftungsfall: Nachweis, dass das Unternehmen seine Aufsichtspflicht erfüllt hat — dass Mitarbeiter geschult wurden und klare Regeln hatten. Nach EU AI Act: Dokumentation, dass der KI-Einsatz kategorienkonforme Risikoeinstufung erhalten hat und Nutzerpflichten erfüllt wurden. Die Richtlinie muss vor dem ersten produktiven KI-Einsatz vorliegen — nicht als Alibi-Dokument, sondern als gelebtes Steuerungsinstrument. Der Unterschied ist spätestens dann sichtbar, wenn eine Behörde nachfragt.

 

Governance-Ebene	Fokus	Hauptakteure	Typische Artefakte	Review-Zyklus
Strategisch	Ziele, Ressourcen, Richtung	Vorstand, Lenkungsausschuss	KI-Strategie, Budget-Freigabe	Jährlich
Operational	Prozesse, Rollen, Compliance	CIO, CISO, DSB, KI-Koordinator	KI-Richtlinie, DSFA, RACI-Matrix	Halbjährlich
Operativ	Tagseinsatz, Vorfälle, Training	Key User, IT-Support, Abteilungen	Schulungen, Vorfallslog, FAQ	Monatlich

Tabelle 4.1 — Die drei Governance-Ebenen im KI-Kontext

Die Frage, ob man „Governance“ braucht oder nicht, stellt sich in der Praxis nicht mehr. Sie stellt sich höchstens so: Wie viel Schaden entsteht, bevor man sie einführt? Unternehmen, die KI ohne strukturierten Rahmen einführen, berichten regelmäßig von denselben Problemen: Mitarbeiter nutzen nicht genehmigte Tools, weil genehmigte nicht vorhanden oder zu langsam sind. Vertrauliche Daten landen in externen KI-Systemen, weil niemand definiert hat, was vertraulich ist. Betriebsräte werden zu spät informiert und leiten Mitbestimmungsverfahren ein, die den Rollout um Monate verzögern. Und am Ende fragt der Vorstand: Warum hat das niemand vorher gewusst?

Die ehrliche Antwort: Es hat jemand gewusst. Es hatte nur niemand die Aufgabe, das systematisch zu adressieren.

Das ist das strukturelle Problem, das Governance löst. Nicht durch Regeln um der Regeln willen, sondern durch explizite Zuweisung von Verantwortung, Werkzeug und Zeitkontingent. Ein KI-Koordinator der 10 Prozent seiner Arbeitszeit für Governance hat, löst das strukturelle Problem nicht. Er ist überlastet und produziert schlechte Ergebnisse. Ein KI-Koordinator mit 30 Prozent, einem klar definierten Mandat und Zugang zu DSB und CISO löst es.

Die häufigste Fehlannahme ist, dass Governance ein einmaliges Projekt ist. Man schreibt eine Richtlinie, führt den Pilot durch, und fertig. In der Realität ist Governance ein laufender Prozess. Microsoft veröffentlicht neue Copilot-Funktionen. Der EU AI Act konkretisiert sich durch Durchführungsbestimmungen. Mitarbeiter entdecken neue Use Cases, die nicht in der ursprünglichen Richtlinie vorgesehen waren. Datenschutzbedenken entstehen bei bestimmten Verwendungen, die niemand antizipiert hatte.

Ein Governance-Framework das in sechs Monaten veraltet ist, war kein schlechtes Framework. Es war ein Framework ohne Review-Prozess. Der Review-Prozess ist genauso wichtig wie das initiale Dokument.

Shadow AI: Das kostspieligste Governance-Versagen

Shadow AI ist der Begriff für KI-Tools, die Mitarbeiter ohne IT-Wissen und ohne Genehmigung einsetzen. ChatGPT im Browser, Perplexity über das Mobiltelefon, externe KI-Dienste über kostenlose Konten — in vielen Unternehmen ist die Verbreitung dieser Tools bereits erheblich, bevor die erste offizielle KI-Richtlinie existiert.

Das Gefährliche an Shadow AI ist nicht das Tool selbst. Es ist die Datenkontrolle. Wenn ein Mitarbeiter einen Kundenvertrag in ChatGPT lädt, um ihn zusammenfassen zu lassen, verlassen diese Daten das Unternehmen. Ob sie später für das Training von Modellen verwendet werden, hängt von den AGB des Anbieters ab — die in den meisten Fällen niemand gelesen hat. Das ist ein DSGVO-Problem, ein Geschäftsgeheimnisproblem und ein Haftungsproblem gleichzeitig.

Die Lösung für Shadow AI ist nicht das Verbot aller KI-Tools. Das funktioniert nicht. Mitarbeiter haben Smartphones, persönliche Laptops und eine natürliche Neigung, effizientere Werkzeuge zu nutzen. Die Lösung ist das Bereitstellen genehmigter Alternativen. Wenn Microsoft 365 Copilot eine bessere und legitimere Alternative zu externem ChatGPT ist, sinkt die Shadow-AI-Nutzung organisch. Aber das erfordert, dass Copilot tatsächlich verfügbar und nutzbar ist — und das erfordert Governance.

Es gibt also einen direkten kausalen Zusammenhang: Governance → legale KI-Alternativen → weniger Shadow AI → weniger Datenschutzrisiken. Wer das als „Bremse“ betrachtet, hat den Kausalzusammenhang umgekehrt.

 

4.2 Wer entscheidet — Rollen und Verantwortlichkeiten

Die beliebteste Antwort auf die Frage „Wer ist verantwortlich für unsere KI-Governance?“ lautet: „Na, die IT.“ Diese Antwort ist falsch, aber sie ist verständlich. Die IT versteht die Technik, die IT hat die Lizenzen bestellt, die IT kümmert sich gewöhnlich um alles, was mit Computern zu tun hat. Warum also nicht auch KI?

Weil KI-Governance keine technische Aufgabe ist. Sie ist eine Organisations- und Compliance-Aufgabe, bei der Technik eine unterstützende Rolle spielt. Der CISO muss dabei sein, weil Sicherheitsrisiken zu bewerten sind. Der Datenschutzbeauftragte muss dabei sein, weil die DSGVO es verlangt und kein Consultant das für ihn abnehmen kann. HR muss dabei sein, weil Mitarbeiterthemen und Betriebsrat-Einbindung ohne HR-Kompetenz scheitern. Der Betriebsrat selbst muss informiert und eingebunden werden — und zwar von Anfang an, nicht als letzter Schritt kurz vor dem Rollout.

Abb. 4.2 — KI-Governance-Architektur: drei Ebenen mit Rollen, Aufgaben und Kommunikationspfaden

Der KI-Lenkungsausschuss

Der Lenkungsausschuss ist das strategische Steuerungsgremium für KI im Unternehmen. Er entscheidet über Budget, Richtung und grundlegende Weichenstellungen. Er trifft sich nicht täglich — monatlich reicht, solange es einen dedizierten Kanal für dringende Entscheidungen gibt.

Zusammensetzung des Lenkungsausschusses: CISO, Datenschutzbeauftragter, CIO, HR-Leitung, und ein Vertreter des Vorstands oder der Geschäftsführung. Optional: ein Vertreter des Betriebsrats — was in der Praxis die Akzeptanz erheblich erhöht. Was der Lenkungsausschuss nicht braucht: zu viele Mitglieder. Ab sieben Personen wird aus einem Entscheidungsgremium ein Diskussionsforum.

Der KI-Koordinator: Dreh- und Angelpunkt im Alltag

Der KI-Koordinator ist die Rolle, ohne die das gesamte Governance-Konstrukt im Alltag kollabiert. Er ist der zentrale Ansprechpartner für alle KI-Fragen — für Mitarbeiter, die nicht wissen ob sie eine bestimmte Anfrage stellen dürfen, für IT, die technische Konfigurationsfragen hat, und für den Lenkungsausschuss, der regelmäßige Status-Reports erwartet.

Der häufige Fehler: Diese Rolle wird jemanden übertragen, der sie nicht wollte und dem kein Zeitkontingent dafür freigeschaufelt wird. Ein KI-Koordinator der nebenbei noch drei andere Vollzeitaufgaben hat, ist in der Praxis kein KI-Koordinator. Er ist jemand der überfördert ist und deshalb Mails spät beantwortet.

Realistischer Zeitaufwand: 20 bis 50 Prozent einer Vollzeitstelle, je nach Unternehmensgröße und Rollout-Phase. In der Pilot-Phase eher 50 Prozent. Im Regelbetrieb nach einem Jahr eher 20 bis 30 Prozent.

Abb. 4.3 — RACI-Matrix: Wer trägt welche Verantwortung in den zentralen KI-Governance-Prozessen

Was passiert, wenn niemand verantwortlich ist

Ein illustratives Beispiel aus der Praxis, anonymisiert und rekonstruiert: Ein mittelständisches Unternehmen im Bereich professionelle Dienstleistungen führt Copilot für 200 Mitarbeiter ein. Der IT-Leiter ist technisch verantwortlich. Die Rechtsabteilung sagt: „Wir haben einen Auftragsverarbeitungsvertrag mit Microsoft, das reicht.“ Der Datenschutzbeauftragte wird informiert, aber nicht in den Rollout-Prozess eingebunden. Den Betriebsrat informiert niemand.

Sechs Wochen nach Rollout-Start klagt der Betriebsrat. Nicht weil Copilot schlechte Ergebnisse produziert, sondern weil er sein Mitbestimmungsrecht nach § 87 Abs. 1 Nr. 6 BetrVG nicht ausüben konnte. Das Gericht erhält die einstweilige Verfügung aufrecht: Copilot muss abgeschaltet werden, bis eine Betriebsvereinbarung vorliegt. Zwei Monate Rollout-Pause. 40 Stunden Anwaltskosten. Und ein zerstörtes Vertrauensverhältnis zum Betriebsrat, das das nächste Projekt noch schwieriger macht.

Wer war verantwortlich? Alle. Und damit: niemand. Der IT-Leiter hat die Technik geliefert. Die Rechtsabteilung hat einen Vertrag geprüft. Der DSB wurde informiert. Aber niemand hatte die übergreifende Governance-Verantwortung. Niemand hat die Checkliste abgehakt: DSFA — Betriebsrat — Richtlinie — Schulung — Rollout. Ohne KI-Koordinator mit klarem Mandat passiert das.

Der Unterschied zwischen „wir haben einen KI-Beauftragten“ und einem echten Governance-Modell ist genau das: Ein Governance-Modell definiert nicht nur, wer eine Aufgabe hat, sondern auch ob diese Person die Kapazität, die Befugnis und die Unterstützung hat, sie auszuführen. Ein Beauftragter ohne Mandat ist ein Feigenblatt.

Thomas Berger bekommt eine neue Aufgabe

Bei Musterwerk GmbH läuft es etwas besser. Thomas Berger, IT-Leiter mit neun Jahren Betriebszugehörigkeit, wird zum KI-Koordinator ernannt. Das Gespräch dauert sieben Minuten. Der Geschäftsführer sagt: „Thomas, Sie machen das jetzt noch zusätzlich.“ Thomas Berger denkt an seinen bereits ausgebuchten Kalender und an die drei offenen Server-Migrations-Tickets.

Dann passiert das, was selten passiert: Sandra Koch, HR-Leiterin, sagt in die Stille hinein: „Thomas braucht ein ordentliches Zeitkontingent dafür. Wir machen das nicht halbherzig oder gar nicht.“ Diese zwei Sätze retten das Projekt. Thomas Berger bekommt 30 Prozent Entlastung von laufenden IT-Aufgaben. Das ist nicht perfekt. Aber es ist genug.

CISO und DSB: Keine Erweiterungen, sondern Kernrollen

Ein verbreitetes Missverständnis: CISO und Datenschutzbeauftragter sind „bei Bedarf“ einzubinden — also dann, wenn technische oder rechtliche Fragen entstehen. Das ist falsch. Beide sind von Anfang an Kernmitglieder der Governance-Struktur, nicht Berater die auf Anfrage kommen.

Der CISO bringt die Sicherheitsperspektive ein: Welche Angriffsvektoren entstehen durch den KI-Einsatz? Was sind die Prompt-Injection-Risiken? Wie wird der Copilot-Zugriff auf sensible Daten kontrolliert? Welche Audit-Logs werden geführt? Diese Fragen müssen beantwortet sein, bevor der erste Nutzer mit Copilot arbeitet.

Der DSB ist aus rechtlicher Sicht obligatorisch einzubinden — Art. 38 DSGVO verpflichtet dazu, ihn in alle Fragen des Datenschutzes einzubeziehen. Wer den DSB erst nach dem Piloten informiert, hat nicht nur eine schwierige Erklärung vor sich, sondern riskiert, dass der Pilot rueckwirkend als unzulässig eingestuft wird.

⚠️ RISIKO — Governance ohne Betriebsrat-Einbindung: das kostet Zeit und Geld

Der Betriebsrat hat nach § 87 Abs. 1 Nr. 6 BetrVG ein echtes Mitbestimmungsrecht bei der Einführung technischer Einrichtungen zur Überwachung von Verhalten und Leistung der Arbeitnehmer. Copilot fällt unter diese Kategorie. Was das bedeutet: Kein Pilot, keine Einführung, kein Rollout ohne vorherige Einigung mit dem Betriebsrat. Und „vorherige Einigung“ heißt: eine unterzeichnete Betriebsvereinbarung, bevor das System in Betrieb geht — nicht danach, nicht „gleichzeitig“. Unternehmen, die das ignorieren, bekommen gelegentlich eine einstweilige Verfügung. Die unterbricht den Rollout sofort — oft in einer Phase, in der bereits erhebliche Investitionen getätigt wurden. Die Kosten für einen nachträglichen Einigungsstellenstreit übersteigen die Kosten einer ordentlichen Vorab-Einbindung um ein Vielfaches. Die Lösung ist einfach: Betriebsrat von Tag 0 an informieren. Nicht „informieren“ im Sinne von „ins CC nehmen“, sondern echte Einbindung in die Konzeptentwicklung. Das dauert länger, erzeugt aber eine Betriebsvereinbarung, die tatsächlich funktioniert.

 

Rolle	Aufgabe im KI-Governance	Zeitaufwand/Woche	Mindestqualifikation
KI-Koordinator	Zentraler Ansprechpartner, Reporting, Pilotsteuerung	8–20 Std.	M365-Admin-Kenntnisse + Datenschutz-Grundlagen
IT-Architektur	Tenant-Konfiguration, MFA, Sensitivity Labels	2–5 Std.	M365 Admin, Azure AD, Sicherheitskonzepte
Datenschutz-Koordinator	DSFA-Dokumentation, Abstimmung mit DSB	2–4 Std.	DSGVO-Kenntnisse, Dokumentationsfähigkeiten
CISO	Sicherheitsreview, Incident Response, Audit	2–3 Std.	IT-Security, Risk Management
Datenschutzbeauftragter	DSFA-Freigabe, Behördenabstimmung, Aufsicht	1–2 Std.	Datenschutzrecht (Pflicht: benannter DSB)
HR-Leitung	Betriebsrat-Einbindung, Schulungskonzept, Change	2–4 Std.	Arbeitsrecht, Betriebsverfassungsrecht
Change Manager	Kommunikation, Akzeptanzförderung, Schulung	3–5 Std.	Kommunikation, Erwachsenenbildung
Betriebsrat	Mitbestimmung, Betriebsvereinbarung, Kontrolle	1–3 Std.	BetrVG-Kenntnisse (insb. §87)

Tabelle 4.2 — KI-Governance-Rollen: Aufgaben, Zeitbedarf und Qualifikationsanforderungen

 

4.3 Die KI-Richtlinie: Was rein muss — und was nicht

Wer das erste Mal eine KI-Richtlinie schreibt, macht üblicherweise einen von zwei Fehlern. Fehler Nummer eins: Die Richtlinie ist zu kurz. Drei Absätze mit allgemeinen Grundsätzen, die sich lesen wie ein Unternehmensleitbild aus dem Jahr 2008. Kein Nutzer weiß danach, was er tun darf und was nicht. Fehler Nummer zwei: Die Richtlinie ist zu lang. 40 Seiten mit Paragraphenverweisen, technischen Details und einem Impressum. Kein Nutzer liest sie.

Das Ziel einer KI-Richtlinie ist Lesbarkeit und Verbindlichkeit. Beides gleichzeitig. Das ist tatsächlich möglich, aber es erfordert einen Prozess: schreiben, kürzen, testen ob ein normaler Mitarbeiter versteht was gemeint ist, dann nochmal kürzen.

Abb. 4.4 — KI-Richtlinien-Hierarchie: Unternehmensrichtlinie, Durchführungsanweisungen und Arbeitsanweisungen

Die Struktur einer professionellen KI-Richtlinie ist hierarchisch. An der Spitze steht die Unternehmensrichtlinie — das Grundlagendokument das vom Vorstand oder Lenkungsausschuss verabschiedet wird und für alle Mitarbeiter gilt. Sie definiert die Grundsätze, die zulässigen Tools und die grundlegenden Verhaltensregeln. Zwei bis drei Seiten, nicht mehr.

Darunter liegen Durchführungsanweisungen für spezifische Bereiche: eine DA für den konkreten Copilot-M365-Einsatz, eine DA für Datenschutz und DSFA-Anforderungen, eine DA für Security-Anforderungen und Monitoring. Diese Dokumente richten sich an die jeweils Betroffenen — Fachabteilungen, IT, Datenschutz — und sind entsprechend fachlicher. Fünf bis acht Seiten je Dokument.

Auf der untersten Ebene stehen Arbeitsanweisungen: Abteilungs-Leitfäden mit konkreten Use Cases, Checklisten für Nutzer, Vorfalls-Meldeformulare. Diese Dokumente schreibt der KI-Koordinator oder der jeweilige Key User. Eine Seite reicht.

Warum diese Hierarchie? Weil unterschiedliche Zielgruppen unterschiedliche Dokumente brauchen. Ein Einkaufssachbearbeiter braucht keinen DSFA-Leitfaden. Ein DSB braucht keine abteilungsspezifische Use-Case-Bibliothek. Wer alles in ein Dokument stopft, erzeugt ein Dokument das niemand liest — und das dann auch für niemanden handlungsleitend ist.

10 Pflichtinhalte jeder KI-Richtlinie

Zulässige KI-Tools: Eine vollständige Liste der genehmigten Produkte — mit Versionsnummer oder Datum, weil Microsoft das Produktportfolio regelmäßig erweitert. Nicht genehmigte Tools sind verboten.

Verbotene Anwendungen: Was darf Copilot auf keinen Fall tun? Personalbewertungen, autonome Außenkommunikation, Entscheidungen über Kreditvergabe oder ähnliches — explizit ausschließen, nicht nur implizit.

Datenkategorien-Regelung: Welche Daten dürfen als Prompt eingegeben werden? Welche nicht? Besondere Kategorien nach Art. 9 DSGVO sind klar verboten. Was ist mit Geschäftsgeheimnissen? Was mit Kundendaten? Jede Kategorie braucht eine explizite Regelung.

Nutzungszwecke: Für welche Aufgaben darf KI eingesetzt werden — und in welchen Rollen? Ein Sachbearbeiter in der Buchhaltung hat andere Freigaben als ein Analyst in der Strategieabteilung.

Aufsichtspflichten: Kein Ergebnis von Copilot darf ungepüft nach außen gegeben werden. Wer ist verantwortlich für die Prüfung? Wie wird sie dokumentiert?

Schulungsanforderungen: Welche Schulung muss vor der ersten Nutzung absolviert sein? Mit welchem Nachweis?

Dokumentationspflichten: Was muss protokolliert werden? Bei welchen KI-Anwendungen ist ein Vorfallslog zu führen?

Meldepflichten: Ab wann ist ein KI-Vorfall meldepflichtig — intern und an den Datenschutzbeauftragten? Was löst eine DSGVO-Meldepflicht nach Art. 33 aus?

Sanktionen: Was passiert bei Verstößen? Ohne klare Konsequenzen ist eine Richtlinie ein Wunschzettel. Die Sanktionen müssen verhältnismäßig, im Einklang mit dem Arbeitsrecht und mit dem Betriebsrat abgestimmt sein.

Review-Zyklus: Die KI-Richtlinie muss mindestens halbjährlich überprüft werden. Nicht weil das Unternehmen sich nicht sicher ist, sondern weil Microsoft das Produktportfolio halbjährlich ändert und der EU AI Act weitere Anforderungen hinzufügt.

 

Abb. 4.5 — KI-Richtlinie: Pflichtinhalt, empfohlene Inhalte und was Richtlinien schlechter macht

💡 TIPP — Der Governance-Quick-Start für Unternehmen unter Zeitdruck

Wenn Sie keine sechs Monate haben, aber trotzdem handlungsfähig sein müssen: Der Governance-Quick-Start in vier Wochen. Woche 1: Lenkungsausschuss konstituieren (60 min), Betriebsrat informieren (formell), KI-Koordinator benennen (mit Zeitkontingent). Woche 2: KI-Richtlinie Entwurf v1 schreiben (2-Seiten-Version). Vorlage gibt es von Verbänden (Bitkom, TeleTrusT). Anpassen, nicht von null starten. Woche 3: DSFA-Kurzbewertung mit DSB. Betriebsrat-Abstimmung Richtlinie v1. CISO-Security-Check Tenant-Konfiguration. Woche 4: Richtlinie v2 mit Betriebsrat-Feedback. Unterzeichnung. Schulung Pilotgruppe (2 Stunden reichen für die Grundversion). Ergebnis: Eine einsatzfähige Grundstruktur nach vier Wochen. Nicht perfekt, aber rechtskonform und ausreichend für einen kontrollierten Pilot. Perfekt wird sie beim ersten Review in sechs Monaten. Wichtig: Vier-Wochen-Governance ist nur dann vertretbar, wenn der Pilot klein und die Datenökologie des Tenants bereits halbwegs geordnet ist. Wer mit einem chaotischen SharePoint startet, braucht länger.

 

Kapitel	Inhalt	Pflicht / Optional	Typischer Umfang
1. Zweck und Geltungsbereich	Für wen gilt die Richtlinie, welche Systeme umfasst sie	Pflicht	0,5 Seiten
2. Grundsätze	Verantwortungsvoller KI-Einsatz, Aufsichtspflicht	Pflicht	0,5 Seiten
3. Zulässige Tools	Genehmigte Produkte, Versionsstatus	Pflicht	0,5 Seiten
4. Verbotene Anwendungen	Explizite Verbotsliste mit Begründung	Pflicht	0,5 Seiten
5. Datenkategorien-Regelung	Was darf / darf nicht eingegeben werden	Pflicht	1 Seite
6. Nutzungszwecke	Erlaubte Einsatzbereiche je Rolle	Pflicht	1 Seite
7. Schulung und Onboarding	Mindestanforderungen vor erster Nutzung	Pflicht	0,5 Seiten
8. Melde- und Dokumentationspflichten	Vorfallsmelder, Log-Anforderungen	Pflicht	0,5 Seiten
9. Sanktionen	Konsequenzen bei Verstößen	Pflicht	0,5 Seiten
10. Review-Zyklus und Änderungshistorie	Wann, von wem, wie häufig überprüft	Pflicht	0,5 Seiten
11. Use-Case-Bibliothek	Konkrete Anwendungsbeispiele je Abteilung	Empfohlen	1–2 Seiten
12. FAQ und Eskalationspfad	Häufige Fragen mit Antworten	Empfohlen	1 Seite

Tabelle 4.3 — Gliederung einer vollständigen KI-Richtlinie: Kapitel, Inhalt und Umfang

 

4.4 Abteilungen einbinden — ohne dass alle gleichzeitig klagen

Jede KI-Einführung scheitert oder gelingt im Wesentlichen an der Frage: Wie gut gelingt die interne Einbindung? Technologie lässt sich kaufen. Prozesse lassen sich dokumentieren. Aber wenn fünf Schlusssenabteilungen gleichzeitig Bedenken haben und diese laut geäußeÖert werden, blockiert das jeden Fortschritt.

Die schwierigen Abteilungen sind in den meisten Unternehmen dieselben. HR, Recht/Compliance, Betriebsrat, die Fachbereiche mit der höchsten Fachkompetenz und die IT. Jede dieser Gruppen hat legitime Bedenken — und jede dieser Bedenken hat eine Antwort, wenn man sie ernst nimmt.

Die fünf schwierigen Abteilungen und wie man sie einbindet

HR hat typischerweise zwei Arten von Bedenken. Die erste: Angst um Arbeitsplätze. Diese Angst ist in einem Maße berechtigt, das je nach Abteilung und Funktion stark variiert. Die ehrliche Antwort ist weder „KI ersetzt niemanden“ noch „Alle Stellen werden wegfallen.“ Die ehrliche Antwort ist: Routineaufgaben werden kürzer. Was Menschen dann mit der gewonnenen Zeit machen, entscheidet das Unternehmen — und das ist eine Führungsaufgabe, keine KI-Frage. Die zweite HR-Sorge betrifft Leistungsmonitoring: Werden Mitarbeiter durch Copilot-Nutzungsdaten überwacht? Die Antwort muss in der Betriebsvereinbarung stehen.

Recht und Compliance fragt drei Fragen, die alle berechtigt sind: Wer haftet für KI-Fehler? Welche Daten dürfen verarbeitet werden? Was verlangt der EU AI Act? Die Antwort auf Frage eins steht in der KI-Richtlinie (Aufsichtspflicht). Die Antwort auf Frage zwei kommt aus der DSFA. Die Antwort auf Frage drei aus Kapitel 7 dieses Buchs.

Der Betriebsrat braucht keine Überzeugung — er braucht ein Mitbestimmungsrecht und eine Betriebsvereinbarung. Wer versucht, den Betriebsrat durch Argumente zu überzeugen statt durch ein strukturiertes Mitbestimmungsverfahren einzubinden, verliert Zeit und Vertrauen. Informieren Sie früh, erklären Sie transparent, und geben Sie dem Betriebsrat echten Einfluss auf die Ausgestaltung. Das erzeugt Akzeptanz. Späte Informationen erzeugen Widerstand.

Fachbereiche sind oft die lautesten Skeptiker und gleichzeitig die wichtigsten Unterstützer. Ein Vertriebsleiter der sagt „Das kenne ich selbst besser als Copilot“ hat häufig recht. Aber der gleiche Vertriebsleiter ist oft bereit, Copilot für Angebotserstellung oder Meeting-Vorbereitung auszuprobieren — wenn er selbst entscheiden darf, für welche Aufgaben er es einsetzt. Key-User aus den Fachbereichen zu gewinnen ist die effektivste Strategie.

Die IT-Abteilung ist die schwierigste Verbundüberraschung. Sie sollte Unterstützer sein, ist aber häufig Skeptiker. Der Grund: IT-Mitarbeiter sehen die Komplexität der Integration, während der Rest des Unternehmens nur die bunte Copilot-Oberfläche sieht. „Das haben wir doch schon“ und ‚Das wird nie funktionieren“ kommen aus der IT. Die Antwort: IT ist nicht Bedenkenträger, sondern Enabler. Das muss in der Rollenverteilung explizit so stehen.

Abb. 4.6 — Betriebsrat-Einbindung: wann welche rechtliche Pflicht entsteht und was vor dem Pilot unterzeichnet sein muss

Das Schulungskonzept: Wer braucht was wann

Schulung ist kein Luxus. Sie ist eine rechtliche Anforderung (Nachweis der Aufsichtspflicht), eine praktische Notwendigkeit (Nutzer die nicht wissen wie Copilot funktioniert, produzieren schlechte Ergebnisse und geben die Schuld dem Tool) und ein Sicherheitsfaktor (Mitarbeiter die Datenschutzregeln nicht kennen, halten sie nicht ein).

Das Schulungskonzept unterscheidet drei Zielgruppen. Erstens alle Nutzer: eine zweistündige Pflichtschulung vor der ersten Aktivierung des Accounts. Inhalte: Was ist Copilot, was darf ich eingeben, was nicht, wie prüfe ich Ausgaben, wie melde ich Vorfälle. Zweitens Key User: eine zusätzliche vierstündige Schulung mit Use-Case-Training und Eskalationspfad. Drittens Administratoren und Governance-Rollen: technische Vertiefung, DSFA-Dokumentation, Audit-Log-Auswertung.

Ein oft unterschätztes Element der Schulung ist der Umgang mit Fehlern. Copilot halluziniert. Das ist keine Fehlfunktion — es ist ein inhärentes Merkmal großer Sprachmodelle. Mitarbeiter müssen wissen, dass Copilot-Ausgaben immer als Entwurf zu betrachten sind, nicht als Ergebnis. Wer das in der Schulung nicht klar kommuniziert, bekommt später Probleme: Mitarbeiter die Copilot-Zusammenfassungen ungepüft weiterschicken, Berechnungen die Copilot geliefert hat ohne Verifikation in Berichte übernehmen, oder externe Kommunikation die auf Basis von KI-Texten geht ohne redaktionelle Prüfung.

Das Schulungsformat macht einen Unterschied. E-Learning ist kostengünstig und skalierbar, aber schlecht geeignet für den Aufbau von Fragekompetenz und kritischem Denken. Ein Live-Workshop mit echter Interaktion — wo Teilnehmer ausprobieren, Fehler machen und Fragen stellen können — erzeugt höhere Kompetenz. Die Empfehlung: Pflicht-E-Learning für alle, optionale Live-Session für Interessierte. Das Optimum sind hybride Formate: 60 Minuten asynchrones E-Learning gefolgt von 60 Minuten Live-Q&A.

Eine kritische Frage für den Schulungsplan: Wer schult die Trainer? Der KI-Koordinator muss selbst gut genug ausgebildet sein, um Fragen zu beantworten die über die FAQ hinausgehen. Das erfordert eine eigene Vertiefungsschulung — und die kostet Zeit und Geld, die im Schulungsbudget häufig vergessen werden. Ein KI-Koordinator der selbst keine Ahnung hat wie Sensitivity Labels technisch funktionieren, kann keine sinnvolle Schulung zu deren Bedeutung liefern.

Zielgruppe	Schulungsinhalte	Format	Dauer	Zeitpunkt
Alle Nutzer	Grundlagen, erlaubte Nutzung, Datenschutz, Vorfallsmelder	E-Learning + optionale Live-Session	2 Stunden	Vor Aktivierung Pflicht
Key User	Use-Case-Training, Eskalationspfad, Feedback-Methodik	Live-Workshop (Präsenz oder Online)	4 Stunden	Woche -2 vor Pilot-Start
KI-Koordinator	Governance-Prozesse, Reporting, Betriebsvereinbarung	Externer Workshop oder Zertifizierung	1–2 Tage	Vor Governance-Aufbau
IT-Administratoren	Tenant-Konfiguration, Sensitivity Labels, Audit-Logs	Technisches Training (Microsoft Learn)	8–16 Stunden	Vor Pilot-Start
Führungskräfte	Strategischer Überblick, Haftung, Aufsichtspflichten	Executive Briefing	1,5 Stunden	Parallel zum Governance-Aufbau

Tabelle 4.4 — Schulungsmatrix: Zielgruppen, Inhalte, Format und Zeitpunkt

Change Management: Was funktioniert und was nicht

Change Management ist eines jener Felder, bei denen viel versprochen und wenig gehalten wird. Die meisten KI-Rollouts haben kein Budget für Change Management. Sie haben ein Budget für Lizenzen, für technische Implementierung, und manchmal für Schulung. Change Management gilt als weich und deshalb als entbehrlich.

Was Change Management in einem KI-Rollout konkret bedeutet: Erstens, frühzeitige und ehrliche Kommunikation. Mitarbeiter die aus der Zeitung erfahren, dass ihr Unternehmen KI einführt, haben keine gute Einstellung zum Thema. Zweitens, Einbeziehung von Skeptikern. Die lautesten Kritiker der KI-Einführung haben häufig die hilfreichsten Bedenken. Wer sie ignoriert, lässt die wertvollsten Feedbackgeber ungenutzt. Drittens, sichtbare Führung. Wenn der Geschäftsführer Copilot nicht selbst nutzt, hat die Belegschaft einen guten Grund zu zweifeln.

Was nicht funktioniert: Kommunikation die Begeisterung vorspielt, die nicht vorhanden ist. Mitarbeiter merken den Unterschied zwischen echter Überzeugung und Unternehmensmarketing — meistens bereits am zweiten Satz der Präsentation. Wer in der KI-Einführungsveranstaltung den Satz sagt „KI wird keine Arbeitsplätze vernichten“, verliert augenblicklich die Glaubwürdigkeit bei allen, die kürzlich über KI-bedingte Entlassungen bei anderen Unternehmen gelesen haben.

Die ehrliche Kommunikation sieht so aus: Copilot wird bestimmte Routineaufgaben schneller machen. Das bedeutet entweder, dass Mitarbeiter mehr Zeit für komplexere Aufgaben haben, oder dass der gleiche Output mit weniger Zeit erbracht werden kann. Was das für die Personalplanung bedeutet, liegt in der Entscheidung des Managements — und das Management sollte diese Entscheidung nicht dem Zufall überlassen.

Die Pilot-Begleitung: Monitoring ohne Überwachung

Während des Pilots braucht der KI-Koordinator regelmäßige Informationen darüber, was passiert. Das Problem: Zu viel Monitoring wirkt wie Überwachung und reduziert die Bereitschaft der Pilotteilnehmer, offen über Probleme zu sprechen. Zu wenig Monitoring bedeutet, dass Probleme unentdeckt bleiben bis sie groß werden.

Der richtige Ansatz: Eine anonyme Wochenbefragung mit drei bis fünf Fragen (Nutzungshäufigkeit, ein positives Beispiel, ein Problem). Ergänzt durch wochentliche optionale Drop-in-Sessions von 30 Minuten, in denen Pilotteilnehmer Fragen stellen und Erfahrungen teilen können. Und einen direkten Meldekanal für Probleme — idealerweise eine Teams-Gruppe oder ein dediziertes Postfach, das der KI-Koordinator mindestens einmal täglich liest.

Die Kunst ist, eine Kultur zu erzeugen, in der schlechte Nachrichten willkommen sind. Wenn Pilotteilnehmer merken, dass Problemmeldungen zu schnellen Lösungen führen und nicht zu unangenehmen Nachfragen, berichten sie mehr. Das ist der Informationsfluss, der einen validen Pilot von einem Schaufenster-Pilot unterscheidet.

Ein praktisches Instrument für die Pilot-Begleitung ist das wochentliche Kurzformat: Eine anonyme Umfrage mit drei Fragen, die in zwei Minuten ausgefüllt werden kann. Frage eins: Wie oft haben Sie Copilot diese Woche genutzt? Frage zwei: Was war das Beste an Copilot diese Woche? Frage drei: Was hat nicht funktioniert oder Sie gestört? Die Auswertung dieser drei Fragen über acht Wochen gibt ein klares Bild der Akzeptanzentwicklung.

Besondere Aufmerksamkeit verdient die Gruppe der Nicht-Nutzer. In jedem Pilot gibt es Pilotteilnehmer, die Copilot kaum oder gar nicht nutzen. Die Gründe sind vielfältig: Überlastung, fehlendes Vertrauen, unklar was man damit machen soll, oder der schlichte Eindruck, dass es keine Zeit dafür gibt. Diese Gruppe ist wertvoller als die enthusiastischen Nutzer, weil sie repräsentiert, was beim Rollout auf Sie zukommt. Ein KI-Koordinator der nur mit den Fans spricht, bekommt ein verzerrtes Bild.

Die „Das-haben-wir-doch-schon“-Falle

In fast jedem KI-Governance-Projekt gibt es mindestens eine Person die sagt: „Dafür brauchen wir keine neue Richtlinie — das ist doch bereits durch unsere allgemeine IT-Nutzungsrichtlinie abgedeckt.“ Diese Person ist häufig aus der IT, manchmal aus der Rechtsabteilung, und sie hat auf einer sehr abstrakten Ebene recht: IT-Nutzungsrichtlinien enthalten häufig Formulierungen zu „verantwortungsvollem IT-Einsatz“ die theoretisch auch KI umfassen.

In der Praxis deckt eine allgemeine IT-Nutzungsrichtlinie von 2019 KI nicht ab. Nicht weil die Formulierungen falsch sind, sondern weil sie keine der konkreten Fragen beantworten, die für KI relevant sind: Welche KI-Tools sind genehmigt? Welche Datenkategorien dürfen als Prompts eingegeben werden? Wer haftet für fehlerhafte KI-Ausgaben? Was ist die Aufsichtspflicht? Was ist die DSFA-Anforderung? Was verlangt der EU AI Act?

Eine IT-Nutzungsrichtlinie die diese Fragen nicht beantwortet, ist für den KI-Kontext nicht ausreichend. Der Überlappungsbereich zwischen allgemeiner IT-Governance und KI-Governance ist vorhanden — aber er deckt höchstens 20 bis 30 Prozent der KI-spezifischen Anforderungen ab.

Welche Abteilungen zuerst?

Die Pilotreihenfolge ist keine Frage des Zufalls, sondern der strategischen Auswahl. Drei Kriterien entscheiden darüber, welche Abteilung als erste in den Pilot geht — und die Reihenfolge dieser Kriterien ist nicht beliebig.

Erstens: KI-Affinität. Gibt es bereits Mitarbeiter, die KI-Tools privat nutzen und damit produktive Erfahrungen gemacht haben? Diese werden Copilot schneller adoptieren, liefern realistischere Nutzungsdaten und fungieren als natürliche Multiplikatoren im Kollegenkreis. Eine Abteilung mit hoher KI-Affinität als erstes zu pilotieren beschleunigt den Start, ohne den Piloten auf eine Schaufenster-Evaluation zu reduzieren.

Zweitens: Datensensibilität. Abteilungen mit niedrig-sensiblen Daten — etwa Marketing, interne Kommunikation oder Projektmanagement — eignen sich besser für erste Piloten als Abteilungen mit hochsensiblen Daten wie Personalabteilung oder Buchhaltung. Der Grund ist nicht, dass man in sensiblen Bereichen später keine Copilot-Einführung plant — sondern dass die Sicherheitsanforderungen dort deutlich höher sind und im Erst-Pilot die Variablen kontrollierbar bleiben sollen.

Drittens: Führungskräfte-Commitment. Die Abteilung, deren Leitung den Pilot aktiv unterstützt und sichtbar mitträgt, ist die bessere Wahl als eine Abteilung, die zufällig ausgewählt wurde. Ein Abteilungsleiter, der selbst Copilot nutzt und in Teammeetings darüber spricht, verdreifacht die Adoption-Rate gegenüber einer Abteilung, in der die Führungskraft dem Thema neutral gegenübersteht.

Die typische Pilotreihenfolge in mittelständischen Unternehmen folgt diesem Muster: Marketing und interne Kommunikation als Einstieg, dann Vertrieb (Innendienst), dann IT, dann die Fachbereiche, und die Personalabteilung zuletzt — wenn die Berechtigungsstruktur auf HR-Daten vollständig geklärt und abgesichert ist.

Abteilungsspezifische Herausforderungen

Jede Abteilung bringt eigene strukturelle Probleme mit, die beim Copilot-Einsatz relevant werden. Diese Probleme sind vorhersehbar — und können deshalb vor dem Rollout adressiert werden, wenn man weiß, wo man hinschauen muss.

Abteilung	Typische Herausforderung	Häufigster Fehler	Empfehlung
Personalabteilung	Hochsensible Daten: Gehälter, Beurteilungen, Bewerberunterlagen	Copilot erhält Zugriff bevor Sensitivity Labeling auf HR-Daten abgeschlossen ist	Erst aktivieren, wenn alle HR-Daten korrekt gelabelt und Berechtigungen geprüft sind
Recht und Compliance	Mandatsgeheimnisse, externe Beratungsunterlagen, vertrauliche Verträge	Externe Dokumente landen im falschen SharePoint-Bereich ohne Zugangsbeschränkung	Separates SharePoint-Team für externe Unterlagen mit strikter Berechtigungsstruktur
Vertrieb	Kundendaten, Konditionen, Angebote, Wettbewerbsanalysen	„Everyone“-Berechtigung auf Verkaufsunterlagen seit dem SharePoint-Setup 2018	Berechtigungsaudit vor Pilotstart zwingend — kein Vertriebspilot ohne bereinigte Struktur
Geschäftsführung	Strategische Dokumente, M&A-Unterlagen, Personalpläne, Vorstandsprotokolle	Sekretariat hat historisch gewachsenen Vollzugriff auf GF-Ablage — und damit Copilot auch	Eigene SharePoint-Site mit stark eingeschränktem Zugriff, Sensitivity Label Highly Confidential
IT-Abteilung	Zugangsdaten, Netzwerkkonfigurationen, Infrastrukturpläne	IT-Personal hat admin-ähnliche Berechtigungen die im Normalbetrieb nicht notwendig sind	Privileged Identity Management (PIM) aktivieren, Copilot für IT-Admins mit erhöhter Vorsicht

Tab. 4.8 — Abteilungsspezifische Copilot-Herausforderungen: Problemfelder, Fehler und Empfehlungen

Die drei häufigsten Abteilungs-Rollout-Fehler

Unabhängig davon, welche Abteilung als erste in den Pilot geht — drei Fehler tauchen in fast allen Rollouts auf, die nicht nach Plan verlaufen.

Alle Abteilungen gleichzeitig: Wenn zehn Abteilungen parallel Pilot starten, hat der KI-Koordinator keine Kapazität mehr, Support zu leisten, Probleme zeitnah zu lösen und Erkenntnisse strukturiert zu sammeln. Das Ergebnis ist eine chaotische Einführung mit unklaren Learnings und frustrierten Pilotteilnehmern, die das nächste Mal weniger kooperativ sein werden.

Nur die Enthusiasten: Wenn ausschließlich Mitarbeiter am Pilot teilnehmen, die Copilot ohnehin wollten, liefert der Pilot verzerrte Ergebnisse. Eine Adoption-Rate von 90 Prozent klingt beeindruckend — sagt aber nichts darüber aus, was mit den übrigen 80 Prozent der Belegschaft passiert, die nicht zum Pilot zugelassen wurden. Der Pilot muss repräsentativ sein, nicht enthusiasmiert.

Die falsche Abteilung als Aushängeschild: Wenn der Pilot in einer Abteilung läuft, die strukturell nicht repräsentativ für das Unternehmen ist — etwa eine junge, technikaffine Marketingabteilung in einem klassischen Industrieunternehmen mit 60 Prozent gewerblichen Mitarbeitern — sind die Ergebnisse nicht übertragbar. Gut gemeinte Schaufenster-Piloten erzeugen falsche Erwartungen an den Breitenrollout.

 

 

4.5 Das Pilotprojekt: Wie man es richtig macht

Der Pilot ist das wichtigste Kapitel der gesamten KI-Einführung. Nicht die Strategie. Nicht das Framework. Der Pilot. Weil der Pilot die einzige Quelle valider Erkenntnisse über das ist, was Copilot in Ihrer spezifischen Umgebung, mit Ihren spezifischen Daten und Ihren spezifischen Mitarbeitern tut.

Alle Erkenntnisse aus Webinaren, Fallstudien anderer Unternehmen und Beraterprojekten können als Orientierung dienen, aber nicht als Entscheidungsgrundlage. Ihre Berechtigungsstruktur ist anders. Ihre Unternehmenskultur ist anders. Ihre Daten sind anders. Der einzige Weg, das zu wissen, ist es auszuprobieren — kontrolliert, mit klaren Abbruchkriterien und einer sauberen Evaluation.

Das klingt nach einer Selbstverständlichkeit. Ist es aber nicht. In der Praxis wird der Pilot häufig entweder übersprungen („Wir haben doch schon genug Informationen“) oder so gestaltet, dass er kein echter Test ist („Wir nehmen die zehn enthusiastischsten Mitarbeiter“). Beides ist ein Fehler. Der Pilot ist die einzige valide Entscheidungsgrundlage. Alles andere ist Spekulation mit Unternehmensbudget.

Abb. 4.7 — Copilot-Pilotprojekt: vollständiger Prozessablauf mit Entscheidungspunkten und Abbruchkriterien

Pilotgröße und Gruppenauswahl

Warum 10 bis 25 Personen? Die Untergrenze ergibt sich aus der statistischen Mindestbasis: Mit weniger als 10 Personen sind Aussagen über Nutzungsverhalten und Akzeptanz nicht repräsentativ. Die Obergrenze ergibt sich aus dem Betreuungsaufwand: Über 25 Personen ist eine intensive Einzelbegleitung kaum noch möglich, und der KI-Koordinator wird zum Vollzeit-Support-Kanal.

Die Pilotgruppe soll repräsentativ sein — nicht ein Abteilungsaushang. Die ideale Zusammensetzung: Personen aus drei bis fünf verschiedenen Abteilungen, darunter mindestens eine Abteilung mit eher geringer KI-Affinität. Wer nur technikaffine Mitarbeiter in den Pilot nimmt, erhält Ergebnisse, die nicht auf den Rest des Unternehmens übertragbar sind.

Abb. 4.8 — Pilotgruppen-Auswahlmatrix: KI-Affinität vs. Datensensitivität — für wen ist ein Erstpilot geeignet?

Technische Vorbereitung vor dem Pilot

Bevor der erste Pilotteilnehmer eine Copilot-Lizenz aktiviert, müssen fünf technische Voraussetzungen erfüllt sein. Erstens: Multi-Faktor-Authentifizierung für alle Pilotteilnehmer — ohne Ausnahme. Zweitens: Berechtigungs-Audit der SharePoint-Strukturen, auf die Pilotteilnehmer Zugriff haben. Dritte: Sensitivity Labels auf den Dokumenten, die als höchst vertraulich klassifiziert sind. Viertens: Data Loss Prevention Policy für die bekannten Hochrisiko-Daten. Fünftens: Audit-Logging aktiviert, sodass Copilot-Aktivitäten protokolliert werden.

Was nicht vollständig sein muss: eine lückenlose Sensitivity-Label-Abdeckung aller Dokumente. Das ist das Ideal, aber kein realistisches Vor-Pilot-Ziel für ein Unternehmen, das SharePoint seit Jahren betreibt. Die bekannten Hochrisiko-Daten müssen geschützt sein. Der Rest ist ein laufendes Verbesserungsprojekt.

Abb. 4.9 — KPIs für den Copilot-Pilot: Nutzung, Produktivität und Zufriedenheit mit konkreten Zielwerten

Abbruchkriterien: Wann man aufhören muss

Ein Pilot ohne Abbruchkriterien ist kein Pilot — es ist ein Rolling Deployment ohne Sicherheitsnetz. Abbruchkriterien müssen vor dem Pilot definiert sein, schriftlich, und vom Lenkungsausschuss genehmigt. Was ein Abbruchkriterium ist und was nicht, muss klar sein.

Abbruchkriterium	Messgröße	Schwellenwert	Konsequenz
Bestätigte Datenschutzverletzung	Unberechtigter Zugriff auf Daten durch Copilot	Jeder einzelne Fall	Sofortiger Pilot-Stopp, DSGVO-Prüfung
Kritische Sicherheitsanomalie	Audit-Log zeigt unerklartes Datenzugriffsverhalten	Jeder nicht erklärte Vorfall	Sofortiger Pilot-Stopp, CISO-Untersuchung
Zu geringe Akzeptanz	Anteil aktiver Nutzer nach Woche 4	Unter 30% der Pilotteilnehmer	Intensivbegleitung oder Stopp
Budgetüberschreitung	Tatsächliche vs. geplante Pilot-Kosten	Mehr als 150% des geplanten Budgets	Lenkungsausschuss-Entscheidung
Betriebsrat-Widerruf	Zurückziehen der Betriebsvereinbarung	Formaler Widerruf	Sofortiger Pilot-Stopp
Systemstabilität	Copilot-bedingte IT-Ausfälle in 72h	Mehr als 2 schwerwiegende Ausfälle	IT-Review, ggf. Pause

Tabelle 4.5 — Abbruchkriterien für den Copilot-Pilot: Messgrößen, Schwellenwerte und Konsequenzen

Abb. 4.10 — 90-Tage-Rolloutplan: von der Vorbereitung über den Pilot bis zur Rollout-Entscheidung mit konkreten Meilensteinen

Der 90-Tage-Plan ist ein Orientierungsrahmen, kein starres Pflichtprogramm. In der Realität gibt es immer Verschiebungen: Die Betriebsvereinbarung braucht eine Woche länger als geplant. Der Tenant-Check offenbart Berechtigungsprobleme, die zusätzliche Arbeit verursachen. Einzelne Pilotteilnehmer fallen wegen Urlaub oder Krankheit aus dem Pilot. Das sind keine Katastrophen — das ist normales Projektmanagement.

Was den Plan robust macht, ist nicht Starre, sondern klare Prioritäten. Es gibt drei Dinge, die unter keinen Umständen übersprungen werden dürfen: die DSFA muss vor dem Pilot abgeschlossen sein, die Betriebsvereinbarung muss vor dem Pilot unterzeichnet sein, und die Schulung muss vor der ersten Aktivierung absolviert sein. Alles andere kann angepasst werden.

Eine häufige Versuchung: Den Pilot zu früh zu starten, weil der Druck vom Vorstand größer wird. Das ist fast immer ein Fehler. Ein Pilot der mit unvollständiger Vorbereitung startet, produziert Vorfälle die bei ordentlicher Vorbereitung nicht passiert wären. Diese Vorfälle werden dann als Argument gegen den Rollout verwendet — was das Gegenteil des ursprünglichen Ziels ist. Nehmen Sie sich die Zeit, die Sie brauchen. Vier Wochen Verzögerung am Anfang sind besser als vier Monate Krisenmanagement in der Mitte.

Die Abschlussevaluation: Was eine valide Entscheidungsgrundlage ist

Die Abschlussevaluation in Woche acht bis zehn ist der Moment, in dem aus Pilotdaten eine Rollout-Entscheidung wird. Was dabei zählt, ist nicht das subjektive Gefühl des KI-Koordinators, sondern messbare Ergebnisse.

Eine valide Entscheidungsgrundlage enthält: Nutzungsstatistiken aus dem Microsoft 365 Admin Center (wer hat wie oft welche Copilot-Funktionen genutzt), Produktivitätsdaten aus der Selbstauskunft der Pilotteilnehmer (wie viel Zeit gespart, bei welchen Aufgaben), Qualitätsbeispiele (zwei bis drei konkrete Anwendungsfälle wo Copilot einen messbaren Unterschied gemacht hat), eine Vorfallsliste (was ist schiefgegangen und wie wurde es behandelt), und NPS-Daten aus der abschließenden anonymen Umfrage.

Was keine valide Entscheidungsgrundlage ist: eine Präsentation voller positiver Zitate aus den enthusiastischsten Pilotteilnehmern. Das ist Marketing, keine Evaluation. Die Entscheidung muss auf der Gesamtheit der Daten basieren — einschließlich der Teilnehmer, die Copilot nie wirklich genutzt haben, und der Vorfälle, die behandelt werden mussten.

Die drei möglichen Entscheidungen sind Rollout (alle Voraussetzungen erfüllt, klarer Mehrwert, Akzeptanz hoch), Verlängern (gemischte Ergebnisse, aber kein Abbruchkriterium ausgelöst — weitere vier Wochen mit angepasster Konfiguration), oder Stopp (Abbruchkriterium ausgelöst oder Kosten-Nutzen-Rechnung negativ). Alle drei Entscheidungen sind legitim. Ein Pilot der zum Stopp führt, ist kein gescheiterter Pilot — er ist ein Pilot der seinen Job gemacht hat.

Der Stopp-Fall verdient eine besondere Erwähnung, weil er in der Praxis selten offen kommuniziert wird. Unternehmen die einen Pilot abbrechen, sprechen oft von „Pause“ oder „Restrukturierung des Ansatzes“. Das ist schade, weil ein sauber begründeter Stopp wertvolle Erkenntnisse liefert: Welche Voraussetzungen fehlen? Was muss zuerst gelöst werden — Berechtigungsstruktur, Datenqualität, Schulungsansatz? Ein „Stopp mit Plan“ ist kein Scheitern. Es ist eine fundierte Entscheidung.

KPI	Messmethode	Zielwert Pilot-Ende	Quelle
Aktive Nutzungsrate	M365 Admin Center Usage Report	≥70% der Pilotteilnehmer	Microsoft Tenant Analytics
Zeitersparnis/Tag	Nutzer-Umfrage (anonymisiert)	≥20 Minuten im Schnitt	Wochentliche Pulsumfrage
Net Promoter Score	Anonyme Einzelbefragung Woche 8	NPS ≥ +20	Interne Umfrage
Weiterempfehlungsrate	Direkte Befragung Abschlussevaluation	≥70% würden empfehlen	Pilotteilnehmer-Interview
Datenschutzbedenken ungeklärt	Offene Fragen aus Umfragen	≤20% offene Bedenken	Feedback-Auswertung
Kritische Vorfälle	Vorfallslog KI-Koordinator	0 unreparierte Vorfälle	Vorfallsprotokoll

Tabelle 4.6 — Abschlussevaluation: KPIs, Messmethoden und Zielwerte für die Rollout-Entscheidung

Abbruchkriterien — wann Sie den Pilot stoppen

Ein Pilot ohne vorab definierte Abbruchkriterien ist kein Pilot — er ist ein unkontrolliertes Experiment mit unklarem Ausgang. Abbruchkriterien schaffen die nötige Struktur, damit das Projekt-Team im Ernstfall nicht über „ob gestoppt werden soll“ diskutiert, sondern wissen, dass sie müssen. Definieren Sie vor dem Start schriftlich, bei welchen Ereignissen der Pilot sofort beendet wird — und lassen Sie diese Liste vom Lenkungsausschuss genehmigen.

Mindestens fünf Abbruchszenarien gehören in jedes Pilotprojekt: Eine Datenpanne, bei der ein Nutzer über Copilot Zugriff auf Daten erhält, die er nicht sehen darf — egal ob intern oder mit personenbezogenem Charakter. Ein formaler Betriebsrat-Widerruf, falls der Betriebsrat seine Zustimmung zur Betriebsvereinbarung zurückzieht. Eine DSGVO-Verletzung, wenn festgestellt wird, dass die Datenschutz-Folgenabschätzung wesentliche Risiken nicht erfasst hatte. Ein technischer Totalausfall, bei dem Copilot-Funktionen die produktive M365-Nutzung der Teilnehmer messbar beeinträchtigen. Und ein nachgewiesener Sicherheitsvorfall, etwa ein Prompt-Injection-Angriff über einen Copilot-Kanal.

Diese Kriterien müssen schriftlich festgelegt, vom Management genehmigt und dem Betriebsrat kommuniziert sein. Ein Pilot, der ohne formale Entscheidung „einfach weiterläuft“, ist kein gesteuertes Projekt mehr — er ist ein laufender Produktionsbetrieb, der sich noch „Pilot“ nennt, aber keine Rückzugsmöglichkeit mehr hat.

Erfolgsmessung — was Sie tatsächlich messen

Die häufigste Schwäche von Copilot-Piloten ist fehlende Baseline. Wenn Sie nicht wissen, wie lange ein Mitarbeiter vor dem Pilot für eine bestimmte Aufgabe benötigt hat, können Sie nach dem Pilot keine valide Aussage über Zeitersparnis machen. Eine gefühlte Zeitersparnis ist kein Messergebnis.

Objektive Metriken sind solche, die Sie ohne Befragung aus Systemdaten ablesen können: Die Copilot-Nutzungsfrequenz aus dem Microsoft 365 Admin Center, die Anzahl der Copilot-Abfragen pro Nutzer und Woche, und welche Funktionen tatsächlich genutzt werden — Chat, Meeting-Zusammenfassungen, E-Mail-Entwurfe oder Dokument-Zusammenfassungen. Diese Daten zeigen Ihnen, ob Copilot im Alltag ankommt, oder ob er nach der Schulung in der Schublade bleibt.

Subjektive Metriken erfordern Befragung. Sie erfassen die wahrgenommene Zeitersparnis, die Qualitätswahrnehmung der Copilot-Ausgaben und die Frustrationspunkte. Wichtig: Wahrgenommene Zeitersparnis und gemessene Zeitersparnis sind zwei verschiedene Dinge. Beide sind nützlich — aber man sollte sie nicht verwechseln. Ein Nutzer, der sagt „Copilot spart mir jeden Tag 30 Minuten“, hat diese Zeit möglicherweise nur anders verbracht, nicht eingespart. Das ist kein Versagen des Tools — es ist eine Erklärung dafür, warum ROI-Berechnungen auf Basis von Pilotbefragungen mit Vorsicht zu genießen sind.

Kriterium	Wie messen	Zielwert	Datenquelle
Aktive Nutzung	Copilot-Aktivierungsrate nach 4 Wochen: Anteil Nutzer mit mind. 3 Abfragen/Woche	>60% der Pilot-Nutzer aktiv	M365 Admin Center
Nutzungsfrequenz	Abfragen pro Nutzer und Woche im Durchschnitt über alle Pilotwochen	>5 Abfragen/Woche	Copilot Analytics
Wahrgenommene Nützlichkeit	Wöchentliche Kurzumfrage: „Wie nützlich war Copilot diese Woche?“ (Skala 1–5)	Ø >3,5 nach 6 Wochen	Survey-Tool (Forms)
Datenschutz-Vorfälle	Gemeldete unerwartete Datenzugriffe oder Berechtigungsanomalien	0 Vorfälle	Manuell / SIEM
Support-Aufwand	IT-Tickets pro Pilot-Nutzer und Woche — zeigt Reife der Vorbereitung	<0,5 Tickets/Nutzer/Woche	Ticketsystem

Tab. 4.9 — Pilot-Erfolgskriterien: Was Sie messen und wie

Was nach dem Pilot passiert

Nach 8 bis 12 Wochen Pilot stehen Sie vor einer Entscheidung — nicht vor einer Selbstverständlichkeit. Der Rollout ist kein automatisches Ergebnis eines abgeschlossenen Pilots. Er ist eine Entscheidung, die auf Basis der Pilotdaten getroffen und dokumentiert werden muss.

Drei mögliche Ergebnisse stehen zur Auswahl. Das erste ist ein Go: Die definierten Erfolgskriterien sind erfüllt, kein Abbruchkriterium wurde ausgelöst, der Betriebsrat hat keine offenen Einwände, und die Kosten-Nutzen-Betrachtung ist positiv. Die Rollout-Planung beginnt. Das zweite Ergebnis ist ein No-Go: Mindestens ein Abbruchkriterium wurde ausgelöst, oder die Erfolgskriterien wurden so deutlich verfehlt, dass eine positive Prognose für den Breitenrollout nicht vertretbar ist. Die Ursachenanalyse beginnt, und ein Neustart mit verändertem Scope oder veränderter Vorbereitung wird geprüft. Das dritte Ergebnis ist ein Conditional Go: Der Pilot war in Teilen erfolgreich, hat aber in bestimmten Bereichen Bedenken offenbart. Der Rollout startet mit eingeschränktem Scope oder nach definierten Nachbesserungen.

Wichtig: Die Entscheidung muss dokumentiert werden. Ein Vermerk mit Datum, Entscheidungsgrundlage und Name des Entscheidungsträgers. „Wir haben den Pilot gemacht und dann weitergemacht“ ist keine Entscheidung — es ist ein Auslaufen des Projekts ohne Governance. Das Dokument zeigt: Erfolgskriterien geprüft, Ergebnis bewertet, Entscheidung getroffen. Es ist die Verbindung zwischen dem Pilot und dem Rollout — und im Zweifelsfall der Nachweis, dass das Unternehmen seine Sorgfaltspflicht erfüllt hat.

 

4.6 Fallstudie Musterwerk GmbH: Vom Chaos zur Governance

🏢 FALLSTUDIE — Musterwerk GmbH: Sechs Monate Governance-Aufbau — ein Schritt vor, zwei zurück, am Ende trotzdem funktioniert

Musterwerk GmbH, 800 Mitarbeiter, Maschinenbau, Dortmund. Thomas Berger, IT-Leiter seit neun Jahren, war eigentlich zufrieden mit dem Status quo. Das änderte sich an einem Montag im Januar. Der Geschäftsführer hatte am Wochenende — natürlich — einen Artikel gelesen. Titel: „KI im Mittelstand: Wer jetzt nicht handelt, verliert den Anschluss.“ Am Montag, 8:47 Uhr, Inbox Thomas Berger: „Wir müssen über Copilot reden. Können wir das bis Ende des Quartals einführen?“ Thomas Berger seufzte. Leise, professionell. Monat 1: Die Entscheidung und ihre Nebenwirkungen Thomas Berger tat, was erfahrene IT-Leiter in solchen Situationen tun: Er bat zunächst um ein Treffen mit dem Geschäftsführer, dem CISO Marc Weber und der DSB Julia Weiß. Das Treffen fand statt. Es dauerte 90 Minuten länger als geplant. Julia Weiß sagte während des Meetings einen Satz, der später oft zitiert wurde: „Ich wäre gerne früher gefragt worden — aber gut, dass ich jetzt hier bin.“ Denn Julia Weiß hatte bereits von zwei anderen mittelständischen Unternehmen gehört, bei denen Copilot ohne DSFA eingeführt worden war. Beide hatten kurze, schöne Eskalations-Momente mit der Datenschutzbehörde. Ergebnis des Meetings: Copilot wird eingeführt — aber nicht bis Ende des Quartals, sondern mit einem seriösen Zeitplan. Thomas Berger wird KI-Koordinator (zusätzlich zu allen anderen Aufgaben, weshalb ihm sofort 30 Prozent seiner bisherigen Aufgaben an einen Kollegen übergeben werden). Ein externer Berater wird für die Governance-Strukturierung beauftragt. Monat 2: Der Governance-Aufbau Der externe Berater brachte eine Vorlage mit. Thomas Berger änderte etwa 60 Prozent davon, weil die Vorlage für ein Unternehmen mit 5.000 Mitarbeitern und eigenem Rechtsteam geschrieben worden war. Die RACI-Matrix wurde definiert. Der Lenkungsausschuss wurde konstituiert: Geschäftsführer, Thomas Berger, Julia Weiß, Marc Weber und die HR-Leiterin Sandra Koch. Sandra Koch wollte von Anfang an den Betriebsrat einbinden — und setzte sich damit durch, obwohl der Geschäftsführer zunächst „schieben wir das noch etwas“ sagte. Das war die beste Entscheidung des gesamten Projekts, wie sich später zeigen sollte. Monat 3: Die KI-Richtlinie und der Betriebsrat Drei Entwurfsversionen. Entwurf eins war zu lang (28 Seiten), zu technisch und hatte keinen Sanktionenteil. Entwurf zwei war besser, aber der Betriebsrat hatte Einwände gegen die Formulierung zur Leistungskontrolle: „Alle Copilot-Aktivitäten werden protokolliert“ klingt nach Überwachung. Entwurf drei enthielt eine Formulierung, die mit dem Betriebsrat gemeinsam entwickelt wurde: Protokolldaten werden ausschließlich für Sicherheits- und Compliance-Zwecke verwendet und können nicht für individuelle Leistungsbeurteilungen verwendet werden. Diese Formulierung stand auch in der Betriebsvereinbarung. Alle unterschrieben. Monat 4: Der Pilot beginnt Pilotgruppe: 18 Personen aus vier Abteilungen (IT, Marketing, Einkauf, Projektmanagement). Auswahl nach der Matrix aus Abschnitt 4.5: mittlere bis hohe KI-Affinität, geringe bis mittlere Datensensitivität. Keine HR, keine Finanzabteilung, keine Geschäftsführung. Die technische Vorbereitung dauerte zwei Wochen länger als geplant — weil Thomas Berger beim Berechtigungs-Audit entdeckte, dass fünf SharePoint-Bibliotheken mit „Jeder außer externe Benutzer“ geteilt waren, darunter eine mit dem Namen „Projektmanagement-Vorlagen“ die tatsächlich auch aktuelle Kundenprojektdaten enthielt. Pilot-Kick-off war trotzdem fast problemlos. Die Schulung dauerte zwei Stunden, Thomas Berger hatte ein FAQ-Dokument vorbereitet. Erste Reaktion der Teilnehmer: gemischt. IT-Mitarbeiter sofort begeistert. Einkauf: „Ganz nett, aber ich warte mal ab.“ Marketing: „Das wird für Textentwurfe richtig gut.“ Monat 5: Der Überraschungsmoment Woche 6 des Pilots, Dienstagmorgen. Thomas Berger bekommt eine Nachricht von Anna Müller aus dem Projektmanagement: „Copilot hat mir gerade auf eine allgemeine Projektfrage geantwortet und dabei auch Zahlen aus dem letzten Jahr erwähnt, die ich eigentlich nicht sehen sollte. Ich glaube das war die Gehaltskalkulation aus dem HR-Bereich.“ Thomas Berger überprüfte den Fall sofort. Was war passiert: Ein HR-Mitarbeiter hatte vor sechs Monaten eine Excel-Datei mit Kalkulationen in eine SharePoint-Bibliothek hochgeladen, die eigentlich nur für die HR-Abteilung gedacht war — aber nie als solche konfiguriert worden war. Die Bibliothek hatte die „Jeder“-Berechtigung. Copilot hatte darauf zugegriffen. Thomas Berger aktivierte den Eskalationspfad. Julia Weiß und Marc Weber wurden informiert. Bewertung: Datenpanne — aber begrenzt auf eine Person, die die Information nicht weitergegeben hatte und sofort Meldung gemacht hatte. DSGVO-Meldepflicht nach Art. 33: nach Prüfung kein meldepflichtiger Vorfall, aber Dokumentation im Vorfallsprotokoll. Die SharePoint-Bibliothek wurde innerhalb von zwei Stunden korrekt konfiguriert. Der Pilotteilnehmer wurde gebrieft. Das Ergebnis der Zwischenevaluation: 13 von 18 Teilnehmern aktiv, NPS +18, aber ein offener Vorfall der Aufmerksamkeit brauchte. Thomas Berger war im ersten Moment geärgert. Im zweiten Moment dachte er: „Genau dafür haben wir den Pilot gemacht.“ Er hatte recht. Monat 6: Abschlussevaluation und Entscheidung Abschlussevaluation Woche 9. Zahlen: 15 von 18 Teilnehmern aktiv in der letzten Woche (83%). Durchschnittliche Zeitersparnis laut Selbstauskunft: 28 Minuten pro Tag. NPS: +32. Weiterempfehlung: 78% der Teilnehmer würden Copilot einem Kollegen empfehlen. Vorfälle: einer, behandelt, dokumentiert, keine Folgeschaden. Was Musterwerk richtig gemacht hat: DSB und Betriebsrat früh eingebunden. Klare Abbruchkriterien definiert. Den Vorfall als Lernmoment behandelt, statt zu vertuschen. Berechtigungsstruktur vor dem Pilot gründlich geprüft. Was Musterwerk falsch gemacht hat: Thomas Berger hatte zunächst kein ausreichendes Zeitkontingent bekommen — das kostete in den ersten vier Wochen spürbar Qualität. Die DSFA wurde parallelisiert statt sequenziell gemacht, was zu einem zweimal überarbeiteten Entwurf führte. Und die Schulung für das mittlere Management wurde vergessen — mehrere Abteilungsleiter wussten nicht genau, was der Pilot bezwecken sollte. Lenkungsausschuss-Beschluss: Rollout Welle 1, 200 Nutzer aus den Abteilungen Marketing, Einkauf, Projektmanagement und IT. Start in sechs Wochen. Die anderen Abteilungen folgen nach Welle-1-Evaluation. Thomas Berger schloss den Bericht mit einem Satz, der später in das interne Governance-Wiki aufgenommen wurde: „Der Pilot hat nicht bewiesen, dass Copilot funktioniert. Er hat bewiesen, dass wir bereit sind, Copilot zu betreiben. Das ist mehr wert.“ Der Rollout Welle 1 startete planmäßig sechs Wochen später. Thomas Berger hatte inzwischen eine dreiseitige Lessons-Learned-Dokumentation erstellt, die er neuen KI-Koordinatoren in anderen Unternehmen auf Anfrage schickt. Er hat aufgehört, Governance als zusätzliche Last zu betrachten. Er betrachtet sie jetzt als das, was sie ist: die Voraussetzung dafür, dass die Technik tut, was sie soll — statt das zu tun, was niemand wollte. Was andere Unternehmen aus Musterwerk lernen können Die Musterwerk-Geschichte ist repräsentativ für mittelständische Unternehmen, die mit KI-Governance beginnen. Sie ist nicht repräsentativ für Konzerne mit dedizierten KI-Ethics-Teams und fünfstelligen Governance-Budgets. Das ist kein Fehler — es ist eine bewusste Entscheidung. Die meisten Leser dieses Buchs arbeiten in Unternehmen, die näher an Musterwerk sind als an einem DAX-Konzern. Die wichtigste Lektion: Governance scheitert nicht an mangelndem Wissen. Sie scheitert an mangelnden Ressourcen und mangelnder Konsequenz. Thomas Berger wusste von Anfang an, was zu tun war. Was er nicht hatte, war Zeit. Als er Zeit bekam, funktionierte es. Das ist keine Überraschung — aber es ist bemerkenswert häufig der einzige Unterschied zwischen Projekten die gelingen und solchen die scheitern. Die zweite Lektion: Der Vorfall in Monat 5 war kein Versagen des Governance-Systems. Er war ein Beweis dafür, dass das System funktioniert. Ein Mitarbeiter hat ein Problem erkannt, es sofort gemeldet, der Eskalationspfad hat gegriffen, das Problem wurde in Stunden gelöst. In einem Unternehmen ohne Governance hätte derselbe Mitarbeiter möglicherweise nichts gemeldet — weil es keine klare Anweisung gab, was zu melden ist, und weil er nicht wusste, an wen er sich hätte wenden sollen. Die dritte Lektion: Der Betriebsrat ist kein Feind. Er ist ein Partner. Die Betriebsvereinbarung bei Musterwerk enthält Formulierungen, die die Qualität der Richtlinie verbessert haben — insbesondere die Klarstellung zur Nicht-Verwendung von Protokolldaten für Leistungsbeurteilungen. Das wäre ohne Betriebsrat-Einbindung nicht entstanden. Und es ist eine Formulierung, die das Vertrauen der Belegschaft in das System erhöht hat. Für Unternehmen die kleiner sind als Musterwerk — unter 250 Mitarbeitern, ohne dedizierten CISO, ohne eigene DSB-Stelle — gilt: Die Prinzipien bleiben dieselben, aber der Aufwand skaliert. Ein Unternehmen mit 80 Mitarbeitern braucht keine RACI-Matrix für fünf Rollen. Es braucht einen IT-Verantwortlichen der auch für KI zuständig ist, einen DSB (intern oder extern bestellt), und eine einseitige KI-Richtlinie die der Geschäftsführer und der Betriebsvertreter unterzeichnen. Das ist der Governance-Quick-Start für kleine Unternehmen. Es ist nicht perfekt. Es ist ausreichend.

 

Abb. 4.11 — Musterwerk GmbH: Governance-Einführung Monat 1–6 — Erfolge, Rückschläge und Wendepunkte auf dem Zeitstrahl

Abb. 4.12 — KI-Governance-Reifegrad: fünf Stufen von Initial bis Optimiert — Musterwerk befand sich zu Beginn auf Stufe 1

Abb. 4.13 — Kostenstruktur KI-Governance: einmalige Investitionen und laufende Betriebskosten im Vergleich

Abb. 4.14 — Eskalationspfad bei KI-Vorfällen: vier Stufen, Beispielszenarien und gesetzliche Meldefristen

 

⚠️ RISIKO — Wenn der Pilot als Grundlage für eine vorgeässte Entscheidung genutzt wird

Es gibt eine Version des Pilotprojekts, die kein Pilotprojekt ist: die Schaufenster-Evaluation. 25 IT-affine Mitarbeiter werden ausgewählt (alle freiwillig, alle technikbegeistert), erhalten intensive Unterstützung, und am Ende kommt ein Bericht mit NPS +45 und 95% Empfehlungsquote heraus. Auf dessen Basis wird Rollout beschlossen. Für 800 Mitarbeiter. Mit komplett anderer Technikaffinität, anderen Aufgaben, anderen Datenstrukturen. Das Ergebnis ist vorhersehbar: Akzeptanzprobleme, Überarbeitung des Schulungskonzepts, Nachverhandlung mit dem Betriebsrat, weil die Realität nicht zum Pilotbericht passt. Die vermiedenen Kosten eines ordentlichen Pilots werden dreifach in nachgelagertem Krisenmanagement reinvestiert. Ein valider Pilot hat eine repräsentative Teilnehmergruppe — inklusive Skeptiker. Er hat klare Abbruchkriterien. Er misst auch, was nicht funktioniert. Und er führt zu einer Entscheidung, die alle drei Optionen (Rollout, Verlängern, Stopp) gleichberechtigt in Betracht zieht.

 

Governance-Kosten-Kategorie	Einmalig (€)	Laufend/Jahr (€)	Anmerkung
Richtlinienentwicklung	4.000–8.000	1.500–3.000	Hälfte einsparen durch Verbandsvorlagen
Schulung Ersteinführung	8.000–18.000	3.000–6.000	Je nach Unternehmensgröße und Format
IT-Tenant-Anpassung	8.000–15.000	2.000–5.000	Einmalig: Berechtigungsaudit + Baseline
Monitoring und Reporting	2.000–5.000	4.000–8.000	Laufend höher wegen KPI-Auswertung
Key-User-Support	0	3.000–8.000	Interner Zeitaufwand Key User + Koordinator
Externe Beratung	12.000–25.000	0–5.000	Nur Ersteinführung; danach interne Kompetenz
Gesamt (Richtwert)	34.000–71.000	13.500–35.000	Abhängig von Größe und Inhouse-Anteil

Tabelle 4.7 — KI-Governance-Kosten: Investitionen nach Kategorie für mittelständische Unternehmen (200–1.000 Mitarbeiter)

 

Das Rückkehr-Investment: Wann lohnt sich Governance?

Eine berechtigte Frage die selten gestellt wird: Ab wann zahlt sich das Governance-Framework durch eingesparte Kosten oder erzielte Erträge zurück? Die Antwort ist unbefriedigend, aber ehrlich: Das hängt davon ab, was ohne Governance passiert wäre.

Der direkte ROI von Governance lässt sich nicht berechnen wie der ROI einer Copilot-Lizenz. Man kann nicht messen, welche Datenpanne nicht passiert ist, welche Betriebsrat-Klage nicht eingereicht wurde, oder welcher Rollout nicht abgebrochen werden musste. Was man messen kann: die Implementierungsgeschwindigkeit mit Governance verglichen mit typischen Projekten ohne Governance, die Schulungs-Abschlussrate, die Pilot-Erfolgsquote, und die Zeit bis zur Rollout-Entscheidung.

Empirische Daten aus ähnlichen KI-Einführungsprojekten deuten darauf hin, dass Unternehmen mit Governance-Framework ihren Rollout im Schnitt sechs bis acht Wochen früher abschließen als Unternehmen ohne. Das liegt nicht an schnellerer Technik, sondern an weniger Rückschlägen, weniger Nachverhandlungen und weniger Nachkorrekturen. Sechs Wochen IT-Overhead bei 200 Nutzern sind — konservativ gerechnet — ein Wert der die Governance-Investitionskosten übersteigt.

Dazu kommt: Governance schafft Vertrauen. Mitarbeiter die wissen, dass ihr Unternehmen KI strukturiert einführt und ihre Datenschutzinteressen ernst nimmt, nutzen KI-Tools häufiger und kompetenter als Mitarbeiter in einer Umgebung wo niemand die Regeln kennt. Vertrauen erhöht die Adoption-Rate. Eine höhere Adoption-Rate erhöht den ROI der Copilot-Lizenz. Der Wirkmechanismus ist indirekt, aber er ist real.

Ein letzter Gedanke zur Governance-Investition, der häufig übersehen wird: Governance ist teilweise amortisierbar. Die KI-Richtlinie die Sie für Copilot schreiben, bildet die Grundlage für die Governance jedes weiteren KI-Tools das Sie einführen werden. Der Lenkungsausschuss den Sie etablieren, ist die Struktur für alle zukünftigen KI-Entscheidungen. Der KI-Koordinator dessen Kompetenz Sie aufbauen, ist eine interne Ressource für Jahre. Die Initialinvestition wird über viele Projekte amortisiert.

➡️ WAS JETZT ZU TUN IST — Governance-Aufbau Schritt für Schritt

Diese Woche: Lenkungsausschuss-Zusammensetzung festlegen. Fünf Personen: Geschäftsführer oder CIO, CISO, DSB, HR-Leitung, und einen KI-Koordinator-Kandidaten. Betriebsrat informieren. Nicht per E-Mail — im persönlichen Gespräch. Agenda: „Copilot-Einführung ist geplant. Betriebsrat wird von Anfang an eingebunden.“ KI-Koordinator benennen und Zeitkontingent freischaufeln. Minimum 20% — ohne das bleibt alles an einem Überlasteten Hängen. Nächste zwei Wochen: KI-Richtlinie Entwurf v1: Nutzen Sie eine Vorlage (Bitkom, TeleTrusT), passen Sie sie an Ihr Unternehmen an. Zwei Seiten, nicht 20. DSFA einleiten: DSB für die Copilot-Datenschutz-Folgenabschtzung beauftragen. Nicht warten bis der Pilot startet. Tenant-Check: CISO oder IT-Architektur prüft MFA-Status, SharePoint-Berechtigungen, Sensitivity-Label-Abdeckung. In vier Wochen: Governance-Struktur steht. Richtlinie v2 liegt vor. Betriebsvereinbarung in Abstimmung. Pilotgruppe auswahl: 10–25 Personen, repräsentativ, nicht nur Enthusiasten. Schulungsplan finalisieren: Wer schult wen, wann, in welchem Format? In 90 Tagen: valide Rollout-Entscheidung auf Basis echter Pilotdaten. Ohne Schaufenster-Evaluation, ohne Wunschdenken.

 

 

KAPITEL 5