Microsoft Copilot-Governance – Grundlagen, Umsetzung, Praxis

Management Summary

• Klare Governance für KI-Assistenten: Copilot-Governance definiert klare Verantwortlichkeiten und Regeln, um Microsoft 365 Copilot sicher, datenschutzkonform und produktivitätssteigernd einzusetzen. Ohne solche Leitplanken drohen Datenmissbrauch, Compliance-Verstöße und Qualitätsprobleme.
• Nutzen ausschöpfen, Risiken minimieren: Eine robuste Governance sichert erhebliche Produktivitäts- und Qualitätsgewinne durch Copilot, indem sie Risiken wie Datenabfluss, Fehlinformationen („Halluzinationen“) und Urheberrechtsverletzungen proaktiv adressiert.
• Organisatorische Voraussetzungen: Vor dem Rollout müssen Organisation und Prozesse vorbereitet sein. Es braucht ein interdisziplinäres Team (IT-Leitung, CISO, Datenschutzbeauftragter, Fachbereiche, Betriebsrat), definierte Rollen (z. B. Copilot-Produktverantwortlicher) und die Einbindung des Betriebsrats, um Akzeptanz und Rechtssicherheit zu gewährleisten.
• Technische Leitplanken im Tenant: Bestehende Sicherheitsmaßnahmen von Microsoft 365 (MFA, Conditional Access, Berechtigungsmodelle) werden konsequent genutzt. Sensitivitätslabels, Data Loss Prevention (DLP) und Audit-Protokolle werden eingerichtet, um zu verhindern, dass Copilot vertrauliche Informationen unbefugt preisgibt.
• Quick Wins vor dem großen Rollout: Bereits vorab können Unternehmen kritische Daten identifizieren und absichern (Berechtigungen straffen, vertrauliche Bereiche mit Labels versehen). Eine kleine Pilotgruppe mit eingeschränktem Funktionsumfang („Guardrails“) liefert frühe Erkenntnisse und schafft Vertrauen – so lassen sich grobe Fehler beheben, bevor Copilot breit ausgerollt wird.
• Kontinuierliche Überwachung und Metriken: Zentrale Kennzahlen (KPIs) wie Nutzungsgrad, durchschnittlich eingesparte Bearbeitungszeit pro Nutzer und Anzahl der gemeldeten Vorfälle machen den Erfolg und die Sicherheit des Copilot-Einsatzes messbar. Ergänzende Risiko-Kennzahlen (KRIs) – etwa DLP-Alarmierungen oder Fehlerquoten – dienen der frühzeitigen Warnung vor Fehlentwicklungen.
• Kosten und Lizenzierung im Griff: Ein Governance-Ansatz umfasst auch die wirtschaftliche Steuerung. Durch bedarfsgerechte Lizenzplanung, Nutzungsanalysen und das Re-Allozieren ungenutzter Lizenzen werden Kosten optimiert und der ROI von Copilot laufend überprüft.
• Empfohlener Fahrplan: Governance beginnt vor der technischen Einführung. Ein mehrstufiger Fahrplan – von Vorbereitung und Risikoanalyse über einen begrenzten Pilotbetrieb hin zum gestaffelten Rollout und dauerhaftem Betrieb – stellt sicher, dass Copilot schrittweise, mit bewährten Kontrollen und ausreichender Schulung aller Beteiligten eingeführt wird. Go-Live erfolgt erst, wenn definierte Kriterien erfüllt sind (z. B. geschulte Nutzer, getestete Sicherheitsmechanismen, Betriebsrat-Zustimmung).

1. Einordnung und Begriffe

1.1 Was ist Copilot-Governance?

Copilot-Governance bezeichnet den Ordnungsrahmen für den verantwortungsvollen Einsatz von Microsoft 365 Copilot im Unternehmen. Ähnlich wie IT-Governance die Leitplanken für IT-Einsatz setzt, definiert Copilot-Governance spezifisch, wie der KI-gestützte Assistent genutzt, überwacht und kontrolliert wird. Sie umfasst Richtlinien, Prozesse und Zuständigkeiten, um sicherzustellen, dass Copilot die Produktivität steigert, ohne dabei Sicherheit, Datenschutz oder Compliance zu gefährden. Konkret regelt Copilot-Governance z. B., welche Daten Copilot verarbeiten darf, wie Ergebnisse geprüft werden sollen und wer im Falle eines Problems eingreift. Im Kern geht es darum, die Balance zwischen Innovation und Kontrolle zu finden: Copilot soll Mehrwert liefern, aber unter klaren Spielregeln, die Missbrauch verhindern und Vertrauen schaffen.

Dabei ist Copilot-Governance kein isoliertes Thema, sondern integriert sich in bestehende Unternehmensrichtlinien. Sie lehnt sich an bewährte Frameworks an, berücksichtigt aber die neuartigen Herausforderungen generativer KI. Wichtig ist, dass Copilot-Governance praktikabel und verständlich ausgestaltet wird – von der Vorstandsebene bis zum Endanwender. Nur dann werden die Vorgaben akzeptiert und im Alltag gelebt. Insgesamt bildet Copilot-Governance den roten Faden, an dem sich alle Beteiligten orientieren können, wenn es um den Umgang mit dem KI-Assistenten geht.

Praxistipps am Ende von 1.1:
– Begriffsverständnis schaffen: Stellen Sie sicher, dass alle Stakeholder (IT, Fachbereiche, Compliance) ein gemeinsames Verständnis davon haben, was unter Copilot-Governance fällt – z. B. durch eine offizielle Definition oder Leitlinie im Intranet.
– Scope klar abgrenzen: Legen Sie fest, ob sich Copilot-Governance ausschließlich auf Microsoft 365 Copilot bezieht oder ob ähnliche KI-Tools (etwa in anderen Anwendungen) einbezogen werden. Diese Abgrenzung verhindert Überschneidungen mit anderen Richtlinien.

1.2 Abgrenzung zu IT-Governance, Data Governance, Informationssicherheit und Compliance

Copilot-Governance steht nicht losgelöst im Raum, sondern überschneidet sich mit mehreren Governance-Bereichen. Wichtig ist daher eine klare Abgrenzung und Zuordnung:

• IT-Governance: Diese bildet den allgemeinen Rahmen für alle IT-Aktivitäten und sorgt für strategische Ausrichtung, Wertbeitrag und Risiko-Management der IT insgesamt. Copilot-Governance ist eine Spezialisierung darunter: Sie fokussiert auf das Teilgebiet „Einsatz von KI-Assistenten in M365“. Während IT-Governance beispielsweise die generelle Rollenverteilung in der IT, Investitionsentscheidungen oder Change-Management regelt, kümmert sich Copilot-Governance gezielt um Fragen wie „Wer darf Copilot verwenden und wofür?“ oder „Welche Leitlinien gelten für KI-generierte Inhalte?“. Man kann Copilot-Governance also als Erweiterung der IT-Governance betrachten, die den speziellen Anforderungen generativer KI gerecht wird.
• Data Governance: Data Governance steuert den Umgang mit Unternehmensdaten allgemein – von Datenqualität über Lebenszyklus bis Zugriffskontrolle. Copilot-Governance baut hierauf auf, da Copilot auf nahezu alle verfügbaren Daten zugreifen kann. Der Unterschied: Data Governance betrifft das Was der Daten (Klassifizierung, Qualität, Wahrheit), Copilot-Governance betrifft das Wie der Datennutzung durch die KI. Beispielsweise stellt Data Governance sicher, dass wichtige Dokumente als „vertraulich“ gekennzeichnet sind und nur berechtigte Personen Zugriff haben. Copilot-Governance stellt ergänzend sicher, dass Copilot diese Kennzeichnungen respektiert und keine vertraulichen Inhalte an Unbefugte in einer Antwort herausgibt. Copilot-Governance benötigt also eine solide Data Governance als Grundlage (ohne klare Datenklassifizierung und Berechtigungen wird es schwierig, KI-Nutzung sauber zu steuern).
• Informationssicherheit (Security Governance): Die Security-Governance kümmert sich um Vertraulichkeit, Integrität und Verfügbarkeit der Informationen im Unternehmen. Copilot-Governance adressiert diese Schutzziele speziell im Kontext des KI-Einsatzes. So werden z. B. innerhalb der Copilot-Governance spezifische Sicherheitsmaßnahmen definiert (etwa DLP-Regeln für KI-Ausgaben oder Einschränkungen für externe Plugins), die aber natürlich in die Gesamt-Sicherheitsstrategie passen müssen. Ein Beispiel: Die allgemeine Sicherheitsrichtlinie fordert „Least Privilege“ und „Need-to-Know-Prinzip“ für Datenzugriff – Copilot-Governance konkretisiert dies dahin gehend, dass Copilot nur Daten ausgeben darf, auf die der jeweilige Benutzer ohnehin Zugriff hat, und dass Rechte regelmäßig überprüft werden, da Copilot ansonsten „vergessene“ Zugriffsrechte gnadenlos aufdecken könnte. Insgesamt kann man sagen, Copilot-Governance verankert KI-spezifische Sicherheitskontrollen innerhalb des bestehenden ISMS (Information Security Management Systems).
• Compliance-Governance: Compliance stellt sicher, dass Gesetze, Vorschriften und interne Vorgaben eingehalten werden. Copilot-Governance unterstützt die Compliance insbesondere in den Bereichen Datenschutz (z. B. DSGVO), regulierte Aufbewahrung und Audits. Hier liegt der Fokus darauf, neue Pflichten oder Fragestellungen durch KI-Nutzung zu antizipieren und entsprechende Prozesse einzurichten. So ergänzt Copilot-Governance bspw. die bestehende DSGVO-Compliance dadurch, dass ein Data-Protection-Impact-Assessment (DPIA) für den Copilot-Einsatz durchgeführt wird oder dass dokumentiert wird, wie Copilot-Ausgaben archiviert werden (falls als Geschäftsunterlagen relevant). Auch Ethik und verantwortungsvolle KI-Nutzung fließen ein: Während Compliance-Richtlinien allgemeiner Natur sind („Wir halten alle relevanten Gesetze ein“), formuliert Copilot-Governance konkrete Handlungsanweisungen („KI-Ausgaben dürfen nicht ungeprüft an Kunden gehen, um falsche Auskünfte zu vermeiden“).

Zusammengefasst: Copilot-Governance operiert als Querschnittsdisziplin, die Elemente der IT-Governance, Data Governance, Informationssicherheit und Compliance zusammenführt und auf den speziellen Anwendungsfall Microsoft 365 Copilot zuschneidet. Wichtig ist, dass keine Widersprüche entstehen – Copilot-Governance sollte in Einklang mit den bestehenden Governance-Regeln gebracht werden und diese ergänzen, nicht ersetzen. Daher empfiehlt es sich, von Anfang an Vertreter aus all diesen Bereichen in die Ausgestaltung der Copilot-Governance einzubeziehen.

Praxistipps am Ende von 1.2:
– Mapping erstellen: Fertigen Sie eine Übersicht an, welche bestehenden Policies (z. B. Informationssicherheitsrichtlinie, Datenschutzrichtlinie, IT-Nutzungsbedingungen) vom Copilot-Einsatz tangiert werden. So erkennen Sie, wo Copilot-Governance anknüpfen oder spezifische Ergänzungen liefern muss.
– Keine Insel-Lösung: Verankern Sie Copilot-Governance formal im Unternehmensregelwerk – z. B. als Anhang zur IT-Sicherheitsrichtlinie oder als Teil der Daten-Governance-Dokumentation. Das vermeidet Doppelgleisigkeiten und signalisiert, dass Copilot kein rechtsfreier Raum ist, sondern denselben Prinzipien unterliegt wie andere Tools.

1.3 Architekturüberblick: Microsoft 365, Graph-Grounding, Datenquellen, Plugins/Connectors, Mandantenkontrollen

Microsoft 365 Copilot ist tief in die M365-Produktivitätsumgebung integriert. Ein Grundverständnis der Architektur hilft, Governance-Maßnahmen gezielt anzusetzen. Die vereinfachte Funktionsweise und Komponenten sind:

• Microsoft 365 Tenant & Apps: Copilot agiert als Dienst innerhalb Ihres Mandanten (Tenant) und erscheint in verschiedenen Microsoft 365 Anwendungen (z. B. als Assistenzfeld in Word, Excel, PowerPoint, Outlook, Teams). Sobald ein Benutzer in einer Office-App eine Anfrage (Prompt) eingibt, tritt Copilot in Aktion. Wichtig: Copilot befindet sich innerhalb der Microsoft 365 Service-Grenze Ihres Unternehmens – das heißt, die Datenverarbeitung findet im geschützten Cloud-Tenant statt, analog zu anderen M365-Diensten.
• Graph-Grounding (Datenabfrage über Microsoft Graph): Copilot nutzt den Microsoft Graph, um kontextrelevante Informationen aus den Datenquellen Ihres Unternehmens abzurufen. Dieser Schritt wird als Grounding bezeichnet: Der vom Benutzer eingegebene Prompt wird zunächst vom Copilot-System analysiert und durchsuchbar gemacht. Dann ruft Copilot – basierend auf dem Inhalt der Anfrage – passende interne Informationen ab: etwa E-Mails, Teams-Chats, Kalendertermine, OneDrive-/SharePoint-Dokumente oder andere Elemente, auf die der Benutzer Zugriff hat. Diese gefundenen Inhalte (Texte, Fakten etc.) werden in den Prompt “eingebettet”, bevor er an das Sprachmodell geht. Grounding erhöht die Relevanz und Aktualität der Antworten: Copilot kombiniert die allgemeine Sprachintelligenz des KI-Modells mit Ihrem Unternehmenswissen aus dem Graph. Governance-seitig bedeutet dies: Alles, was Microsoft Graph finden kann und worauf der Nutzer Berechtigung hat, kann potenziell auch in einer Copilot-Antwort auftauchen. Daher sind Zugriffssteuerung und Datenbereinigung im Graph-Index zentrale Stellhebel (siehe Abschnitt 5).
• LLM (Large Language Model) in Azure OpenAI Service: Nachdem der Prompt mit Ihren Daten angereichert wurde, wird er an das KI-Sprachmodell gesendet. Microsoft 365 Copilot nutzt dafür die Azure OpenAI Infrastruktur – Ihre Prompt-Daten bleiben also in Microsofts Cloud (und werden nicht an das öffentliche ChatGPT weitergegeben). Das LLM (z. B. GPT-4) generiert anhand des Prompts eine Antwort in natürlicher Sprache. Dieser Antwortentwurf ist kontextbezogen auf Ihr Unternehmen (weil das Grounding entsprechende Inhalte geliefert hat). Wichtig: Weder Prompt noch Antwort fließen zurück ins Training des Basis-Modells; Microsoft hat vertraglich zugesichert, dass Ihre Daten nicht zur Verbesserung des generischen KI-Modells verwendet werden. Die KI antwortet also nur session-spezifisch und „vergisst“ den Inhalt nach Abschluss der generierten Antwort (abgesehen von Zwischenspeicherung in Ihrem Tenant, siehe nächster Punkt).
• Rückgabe und Anzeige im Client: Copilot gibt die erstellte Antwort im jeweiligen Client (z. B. als Chatblasen in Teams oder als eingefügter Text in Word) an den Benutzer zurück. Dabei werden oft Verweise auf Quellen angezeigt (z. B. „Laut Dokument X vom Datum Y…“), sofern Informationen aus bestimmten Dateien genutzt wurden – das erhöht die Nachvollziehbarkeit. Die gesamte Interaktion – also Prompt und Antwort – wird zudem im Copilot-Verlauf gespeichert. Dieser Verlauf ist pro Benutzer einsehbar (z. B. in Business Chat in Teams kann man frühere Fragen/Antworten erneut anschauen) und auch für Administratoren über Audit/Content-Search auswertbar. Für Governance heißt das: Es existiert ein Protokoll der KI-Nutzung, das für Audits oder Analysen herangezogen werden kann. Zudem können Benutzer ihren persönlichen Verlauf bei Bedarf löschen (über das Microsoft-Konto-Portal), was ggf. aus Datenschutzsicht relevant ist.
• Integrierte Sicherheits- und Compliance-Services: Copilot respektiert Mandantenrichtlinien. Es ist kein eigenständiges System, das Berechtigungen umgeht, sondern baut auf dem M365-Berechtigungsmodell auf. Beispielsweise: Hat ein Nutzer keinen Zugriff auf eine bestimmte SharePoint-Seite, kann auch Copilot daraus keine Inhalte liefern (solche Daten bleiben für den Prompt „grau ausgeblendet“). Auch Mechanismen wie Conditional Access (z. B. Gerät muss compliant sein, sonst kein Copilot-Zugriff) und Multi-Faktor-Authentifizierung greifen für Copilot genau wie für andere Dienste. Der Dienst arbeitet zudem konform mit Datenresidenz-Vorgaben (für EU-Tenants gelten EU Data Boundary Zusagen). Aus Governance-Sicht heißt das, viele bestehende Sicherheitsvorkehrungen wirken auch für Copilot – diese sollten also richtig konfiguriert und durch Copilot-Governance ggf. verschärft werden (z. B. MFA-Pflicht unterstreichen, Gerätekonformität einfordern, etc., siehe Abschnitt 5.1).
• Plugins und Connectors: Copilot kann seine Fähigkeiten erweitern, indem er externe Datenquellen oder Dienste einbindet. Es gibt zwei Hauptmechanismen:
• Microsoft Graph Connectors: Das sind Schnittstellen, um Drittsysteme in den Microsoft Graph Index zu integrieren. Beispielsweise kann ein Graph Connector Inhalte aus einer externen Datenbank oder einem Intranet-CMS indexieren, sodass Copilot (und auch die Microsoft-Suche) darauf zugreifen kann. Für die Governance bedeutet das: Falls Graph Connectors genutzt werden, muss man die extern eingebundenen Datenquellen kontrollieren – inhaltlich (dürfen diese Daten via Copilot bereitgestellt werden?) und technisch (Indexierung aktuell, Berechtigungen gemappt?). Graph Connectors werden im Tenant konfiguriert und verwaltet, was zentral steuerbar ist.
• Copilot Plugins (Agents): Microsoft 365 Copilot unterstützt zusätzlich sogenannte Agents – vergleichbar mit ChatGPT-Plugins – die es Copilot erlauben, Aktionen in anderen Anwendungen oder Webdiensten durchzuführen. Ein Beispiel: Ein genehmigtes Plugin könnte es Copilot ermöglichen, auf ein Drittanbieter-CRM zuzugreifen, um Kundendaten abzurufen, oder Webinhalte zu lesen. Aktivierte Plugins werden im Kontext der Benutzeranfrage vom Copilot ausgewählt, falls sie relevant sind. Wichtig: Admins können im M365 Admin Center steuern, welche Plugins/Agents im Unternehmen zugelassen sind. Alle verfügbaren Agents sind mit Beschreibung, benötigten Berechtigungen und Datenschutz-Hinweisen gelistet. Standardmäßig ist die Nutzung vieler Plugins unternehmensweit deaktivierbar oder erlaubnispflichtig. Governance-seitig muss hier ein Freigabeprozess etabliert werden (siehe Abschnitt 5.5 und 10.3), damit nicht unkontrolliert Dienste angebunden werden, die Daten abziehen könnten. Außerdem sollten Benutzer nur diejenigen Plugins nutzen können, die vom Admin erlaubt wurden und die sie selbst aktiviert haben.
• Mandantenkontrollen: Über das Gesagte hinaus stellt Microsoft einige Tenant-weite Konfigurationsmöglichkeiten bereit, die das Verhalten von Copilot beeinflussen. Dazu zählen:
• Das Zuweisen von Lizenzen: Nur lizensierte Benutzer sehen Copilot überhaupt in ihren Apps. Dies ist die erste Kontrollinstanz – über die Lizenzvergabe kann gesteuert werden, wer Copilot nutzen darf (z. B. zunächst nur eine Pilotgruppe).
• Disable-Funktionen: Microsoft hat angekündigt, gewisse Copilot-Funktionen via Admin-Einstellungen abschaltbar zu machen. Ein Beispiel ist die Option, Websuche in Copilot Chat zu deaktivieren, falls man nicht möchte, dass die KI eigenmächtig Internet-Suchen durchführt (könnte relevant sein in stark regulierten Umgebungen, um zu verhindern, dass Unternehmensfragen ungefiltert nach außen gehen). Ebenso lassen sich evtl. bestimmte Anwendungsintegrationen einschränken.
• Einschränkung von Datenquellen: Über Security-Features wie Restricted SharePoint Sites und Search Restrictions (Teil von SharePoint Advanced Management) kann man definieren, dass bestimmte vertrauliche Bereiche gar nicht durchsuchbar sind – das schränkt dann auch Copilots Zugriff dort ein.
• Audit und Monitoring aktivieren: Der Admin kann über Microsoft Purview Audit festlegen, welche Aktivitäten geloggt werden. Für Copilot sind spezielle Audit-Events verfügbar (z. B. „Benutzer X hat Copilot in Teams Chat genutzt“ inkl. Zeitstempel und evtl. Kategorien). Diese Logging-Optionen sollten in der Tenant-Konfiguration eingeschaltet und an die gewohnten SIEM/Monitoring-Systeme angebunden werden.

Der Architekturüberblick zeigt: Copilot sitzt als Layer auf Ihren vorhandenen Systemen und Daten. Governance muss daher sowohl horizontal (fachübergreifend Policies und Prozesse definieren) als auch vertikal (in der technischen Plattform Einstellungen vornehmen) wirken. Ein Verständnis, welche Daten und Funktionen Copilot nutzt, ist essentiell, um die richtigen Stellschrauben zu finden.

Trotz aller Technik sollte Governance den Menschen nicht vergessen: Copilot mag KI sein, aber Nutzer steuern ihn mit Prompts. Schulungen zu effektivem und verantwortungsvollem Prompting (siehe Abschnitt 10.4) sind Teil der Governance-Architektur – quasi die „User Experience“-Schicht oben drauf.

Praxistipps am Ende von 1.3:
– Eigenen Architektur-Leitfaden erstellen: Dokumentieren Sie für Ihr Unternehmen die Copilot-Architektur in verständlicher Form (gern grafisch): Welche internen Systeme werden angebunden, welche Sicherheitsfeatures sind relevant? Dies hilft allen Beteiligten – insbesondere Nicht-Technikern wie Datenschutz oder Betriebsrat – die Funktionsweise zu verstehen und passende Vorgaben abzuleiten.
– Technische Defaults überprüfen: Gehen Sie die verfügbaren Mandanten-Einstellungen für Copilot durch (z. B. in Preview-Dokumentationen von Microsoft). Setzen Sie möglichst früh die gewünschten Defaults (etwa Websuche aus, wenn unerwünscht) und kommunizieren Sie diese Entscheidungen. So vermeiden Sie, dass im Eifer des Einführungsprojekts unsichere Standardeinstellungen übersehen werden.

1.4 Reifegrade und Zielbild (Governance-Maturität in 4–5 Stufen)

Die Einführung von Copilot-Governance kann – analog zu anderen Governance-Themen – über Reifegradstufen betrachtet werden. Nicht jedes Unternehmen wird sofort eine voll ausgereifte KI-Governance haben; vielmehr entwickelt sich diese iterativ. Ein Reifegradmodell mit 5 Stufen hilft, den aktuellen Stand einzuordnen und ein Zielbild zu formulieren:

• Stufe 1 – Ad-hoc / Unstrukturiert: Es gibt keine spezifische Copilot-Governance. Vielleicht befindet man sich noch vor der Einführung oder Copilot wurde testweise aktiviert, ohne dass Policies definiert sind. Entscheidungen erfolgen fallweise, Risiken sind nicht bewertet. Diese Stufe ist hoch riskant – ein Unternehmen sollte hier so kurz wie möglich verweilen. Beispiel: Copilot wird für ein paar neugierige Power-User freigeschaltet, es gibt aber keine Regeln, was sie damit tun dürfen.
• Stufe 2 – Reaktiv / Initiale Kontrollen: Es gibt erste provisorische Regelungen. Möglicherweise haben IT-Sicherheit oder Datenschutz ein paar Grundsätze ausgesprochen (z. B. „Bitte keine vertraulichen Daten in Copilot-Eingaben nutzen“), aber noch kein formales Rahmenwerk. Governance greift reaktiv: Wenn ein Problem auftritt, wird es adressiert, aber es gibt kein systematisches Vorgehen. Immerhin werden auf dieser Stufe schon wichtige Risiken erkannt und isolierte Kontrollen eingeführt (z. B. adminseitig DLP-Regeln aktiviert, wenn ein Vorfall passiert). Das Unternehmen lernt aus ersten Erfahrungen, aber es besteht Uneinheitlichkeit und Lücken.
• Stufe 3 – Definiert / Formalisiert: Nun existiert ein ausgearbeitetes Copilot-Governance-Framework. Es wurden Policies geschrieben, Rollen benannt (z. B. hat der CISO eine explizite Verantwortung für KI-Sicherheit übernommen, der Datenschutzbeauftragte hat Copilot in sein Programm integriert). Schulungen wurden durchgeführt, und der Copilot-Einsatz erfolgt nicht mehr wild, sondern nach definierten Prozessen – z. B. müssen neue Anwendungsfälle vorab freigegeben werden, es gibt einen offiziellen Pilotbetrieb. Die meisten Mitarbeiter wissen, dass es Regeln gibt, und halten sich im Großen und Ganzen daran. Diese Stufe ist ein solides Ziel für den initialen Rollout: Governance ist etabliert, wenn auch noch nicht perfekt optimiert.
• Stufe 4 – Gesteuert / Messbar: Auf dieser Stufe ist Copilot-Governance voll in die Unternehmenssteuerung integriert. Es werden kontinuierlich Metriken erhoben: z. B. regelmäßige Berichte an das Management über Nutzung, Nutzen und Risiken. Ein Gremium (z. B. AI Governance Board) trifft sich periodisch, um Kennzahlen zu prüfen, Entscheidungen zu justieren und Vorfälle auszuwerten. Alle relevanten Prozesse (Incident-Response, Änderungsmanagement bei neuen Copilot-Versionen, Plugin-Freigaben etc.) laufen routiniert ab. Die Organisation proaktiviert: Man wartet nicht nur auf Probleme, sondern verbessert das System laufend (z. B. durch jährliche Auditierungen des Copilot-Einsatzes, Red-Teaming-Workshops etc.). Diese Stufe zeichnet sich auch dadurch aus, dass sämtliche Stakeholder eingebunden sind: Fachbereiche melden zurück, wo Copilot gut funktioniert oder wo Regeln hinderlich sind, und Governance passt sich entsprechend an.
• Stufe 5 – Optimiert / Transformativ: Copilot-Governance ist hier nicht nur ein Kontrollmechanismus, sondern wird zum Enabler für Innovation. Das Unternehmen nutzt Copilot und ähnliche KI-Technologien voll aus, ohne die Kontrolle zu verlieren. Governance ist so verankert, dass sie beinahe unsichtbar wirkt: Mitarbeiter kennen die Spielregeln im Schlaf, Verstöße sind extrem selten, und die Organisation hat Vertrauen, auch neue KI-Features schnell einzuführen, weil ein belastbares Fundament da ist. Außerdem wird die Governance regelmäßig extern benchmark-basiert optimiert – man schaut also, was machen Branchenführer, was fordert ggf. der Gesetzgeber demnächst (Stichwort EU AI Act), und passt die eigenen Richtlinien vorausschauend an. Auf Stufe 5 trägt Copilot-Governance aktiv zur Wettbewerbsfähigkeit bei: Sie ermöglicht risikobewusste Experimente mit KI, sodass das Unternehmen Agilität und Compliance gleichzeitig erreicht.

Realistisch werden viele Unternehmen anstreben, mittelfristig in Stufe 4 anzukommen: Ein kontrolliertes, messbares System. Stufe 5 ist ein idealisiertes Zielbild, das fortgeschrittene KI-affine Organisationen erreichen können. Wichtig ist, dass man den nächsten sinnvollen Schritt geht: Ein Unternehmen auf Stufe 1 sollte schleunigst Policies entwickeln (Stufe 3 anpeilen). Wer bei Stufe 3 ist, sollte beginnen, KPIs und regelmäßige Reviews einzuführen (Stufe 4). Das Reifegradmodell dient somit auch zur Kommunikation gegenüber dem Management: Man kann aufzeigen, wo man steht und welche Investitionen nötig sind, um das nächste Level zu erreichen.

Praxistipps am Ende von 1.4:
– Selbstbewertung durchführen: Ordnen Sie Ihr aktuelles Governance-Niveau einer der Reifegradstufen zu. Seien Sie dabei ehrlich: Haben Sie wirklich schon Monitoring (Stufe 4) oder bisher nur Policy-Dokumente (Stufe 3)? Diese Standortbestimmung hilft bei der Roadmap-Planung.
– Reifegrad-Ziel als Vision kommunizieren: Definieren Sie ein Ziel („Wir wollen innerhalb eines Jahres von ad-hoc zu formalisiert gelangen“) und teilen Sie diese Vision den Beteiligten mit. So verstehen alle, dass Governance ein Entwicklungsprozess ist – das nimmt den Druck, sofort perfekt zu sein, und motiviert, schrittweise Verbesserungen umzusetzen.

2. Warum Copilot-Governance unverzichtbar ist

2.1 Geschäftsnutzen: Produktivität, Qualität, Nachvollziehbarkeit, Wissensmanagement

Die Einführung von Microsoft 365 Copilot verspricht beträchtliche geschäftliche Vorteile. Doch diese stellen sich nur ein, wenn der Einsatz in geordneten Bahnen verläuft – hier kommt Governance ins Spiel. Ein strukturierter, gut geplanter Copilot-Einsatz kann folgende Nutzenpotentiale heben:

• Steigerung der Produktivität: Copilot kann Routineaufgaben automatisieren, Inhalte zusammenfassen und auf Knopfdruck Entwürfe erstellen. Mitarbeiter sparen Zeit bei der Informationssuche („Finde alle relevanten Mails zu Projekt X und ziehe die Kernaussagen heraus“), bei der Erstellung von Dokumenten („Erstelle eine erste Präsentation aus diesen Berichten“) oder bei der Beantwortung von Fragen. Governance sorgt dafür, dass diese Produktivitätsvorteile im Vordergrund stehen und nicht durch Zwischenfälle oder Unsicherheit konterkariert werden. Zum Beispiel kann durch Policies klargestellt werden, wofür Copilot genutzt werden sollte (z. B. Entwürfe erstellen, Recherche unterstützen) und wofür nicht (z. B. finale Freigaben ersetzen). Mit solchen Leitplanken wird Copilot zielgerichtet eingesetzt, was die Effizienzgewinne maximiert. Unternehmen mit klaren Nutzungsregeln berichten, dass Mitarbeitende Copilot bewusst als Tool in ihren Arbeitsabläufen einplanen und dadurch beispielsweise wöchentliche Reporting-Aufgaben in einem Bruchteil der Zeit erledigen.
• Verbesserung der inhaltlichen Qualität: Richtig eingesetzt kann Copilot die Qualität von Ergebnissen erhöhen. Er kann etwa Vorschläge für konsistente Formulierungen liefern, Inhalte nach vorgegebenen Kriterien überprüfen oder Wissenslücken füllen. Wenn Governance sicherstellt, dass Fachrichtlinien in Copilot einfließen (z. B. durch hinterlegte Prompt-Vorlagen mit Qualitätskriterien, siehe Szenario S9 und Anhang 10.4), dann wird der KI-Assistent zum Qualitätssicherer. Zudem erzwingt Nachvollziehbarkeit (dazu gleich mehr) indirekt bessere Qualität: Mitarbeiter wissen, dass KI-Ausgaben mit Quellen belegt sein sollten, also fordern sie diese ein – dadurch steigen Relevanz und Richtigkeit der Antworten. Insgesamt kann Copilot helfen, Fehler zu reduzieren (z. B. weniger Zahlendreher in Berichten, weil Copilot direkt aus verlässlichen Datenquellen zitiert) und Standards einzuhalten (z. B. Vorgaben zur Kundenansprache, die als Textbausteine über Copilot verfügbar gemacht werden). Governance ist unverzichtbar, um diesen Nutzen zu realisieren, indem sie vorschreibt, wie Copilot in bestehende Qualitätsprozesse eingebunden wird (etwa 4-Augen-Prinzip trotz KI oder definierte Review-Schritte).
• Nachvollziehbarkeit und Auditierbarkeit: In vielen Arbeitsbereichen ist wichtig, im Nachhinein nachvollziehen zu können, wie ein bestimmtes Ergebnis zustande kam. Copilot kann hierbei Fluch und Segen zugleich sein: Ohne Governance besteht das Risiko, dass jemand KI-generierten Inhalt übernimmt, aber nicht mehr weiß, wo die Infos herkamen. Mit geeigneten Vorgaben hingegen wird Copilot zu einem Transparenz-Werkzeug. Beispielsweise kann eine Policy vorgeben, dass bei entscheidungsrelevanten Ausgaben immer die Quelle angegeben oder ein Verweis auf das zugrundeliegende Dokument beigefügt werden muss (Copilot liefert diese Quellen oft automatisch mit, sofern Daten aus dem Graph gezogen wurden). Außerdem sorgt das Logging der Prompts/Antworten dafür, dass man später auditieren kann, welche KI-Information wann geflossen ist. Dies ist besonders nützlich für Branchen mit Dokumentationspflichten (z. B. könnte eine Prüfung ergeben „auf Basis welcher Analyse wurde dieser Börsenentscheid getroffen?“ – mit Copilot-Logs ließe es sich rekonstruieren). Allerdings nur, wenn die Governance von Anfang an die Nachvollziehbarkeit betont und z. B. entsprechende Tools (Audit-Export, Archivierung) implementiert. Deshalb unverzichtbar: Copilot-Governance stellt sicher, dass kein Black-Box-Effekt entsteht, sondern alle KI-Interaktionen im Zweifel erklärbar bleiben.
• Wissensmanagement und Kollaboration: Copilot agiert als universeller Wissensträger, der das über die Organisation verstreute Wissen abrufen und zugänglich machen kann. Für Unternehmen ist dies eine Riesenchance: Silos können aufgebrochen werden, Expertenwissen wird schneller gefunden, neue Mitarbeiter kommen besser an vorhandene Informationen. Allerdings passiert das nicht automatisch. Governance muss lenken, welche Wissensquellen Copilot erschließt und wie aktuell diese sind. Ohne Vorgaben könnte Copilot z. B. veraltete oder redundante Dokumente ausgeben, was die Nutzer eher verwirrt. Deshalb gehört zum Governance-Auftrag auch, das Informationsökosystem aufzuräumen – etwa ROT-Daten (Redundant, Obsolete, Trivial) zu bereinigen und sicherzustellen, dass wichtige Inhalte klassifiziert und gepflegt sind. Im Idealfall gibt es eine Rückkopplung: Copilot wird genutzt, um Wissenslücken zu identifizieren (wenn Nutzer ständig nach etwas fragen, das Copilot nicht beantworten kann, fehlt evtl. ein zentrales Dokument) und diese Lücken dann durch Datenpflege zu schließen. So hebt Copilot-Governance auch das allgemeine Wissensmanagement auf ein höheres Niveau. Die Kollaboration profitiert, weil Copilot z. B. Zusammenfassungen für alle Teammitglieder erstellen kann, gemeinsame Projektstände aus verschiedenen Quellen verdichtet und damit alle auf demselben Wissensstand hält. Wieder gilt: Governance sorgt dafür, dass das erlaubt und gewünscht ist und keine sensiblen Infos unkontrolliert in solche Team-Zusammenfassungen rutschen.

Zusammenfassend bringt Copilot, richtig gesteuert, mehr Tempo und bessere Ergebnisse in die Organisation. Governance ist unverzichtbar, um diese positiven Effekte gefahrlos zu realisieren. Sie schafft die Voraussetzung, dass Mitarbeiter Copilot vertrauensvoll einsetzen und das Management den Mehrwert quantifizieren kann. Ohne Governance würden viele Mitarbeiter aus Unsicherheit (Was darf ich? Darf ich dem trauen?) Copilot womöglich wenig nutzen – oder umgekehrt sorglos zu viel und falsch nutzen. Beides würde die Vorteile schmälern. Eine klare Copilot-Governance schafft Vertrauen und Orientierung, was letztlich die Akzeptanz erhöht und den Nutzen voll zum Tragen bringt.

Praxistipps am Ende von 2.1:
– Use Cases definieren: Identifizieren Sie konkrete Anwendungsfälle, in denen Copilot einen hohen Produktivitäts- oder Qualitätsnutzen hat (z. B. Meeting-Zusammenfassungen, Angebotstexte erstellen). Priorisieren Sie diese in Pilot und Rollout – Erfolgserlebnisse dort überzeugen das Management von Copilots Wert.
– „KI-Protokoll“ einführen: Ermuntern Sie Nutzer, bei wichtigen Ergebnissen kurz zu notieren oder zu kommunizieren, ob/wie Copilot beteiligt war („Entwurf mit Copilot erstellt, dann manuell geprüft“). Diese Kultur der Transparenz fördert Nachvollziehbarkeit und hilft, Vertrauen in die KI-Ergebnisse aufzubauen.

2.2 Risikoanalyse: Vertraulichkeit, Integrität, Verfügbarkeit, Datenabfluss, Halluzination, Urheberrecht, Haftung

Wo Chancen sind, gibt es auch Risiken – und bei einer so mächtigen Technologie wie Copilot sind diese erheblich, wenn keine Leitplanken existieren. Copilot-Governance ist deshalb unverzichtbar, um die folgenden Risiken systematisch zu beherrschen:

• Risiko für die Vertraulichkeit (Confidentiality): Copilot kann sensible interne Informationen einem breiten Nutzerkreis leicht zugänglich machen. Was früher in entlegenen Ordnern „versteckt“ war, kann die KI unter Umständen zutage fördern. Ohne Governance könnten Mitarbeiter versehentlich Einblicke in vertrauliche Daten erhalten, obwohl sie technisch Zugriff hatten, aber es nie wussten. Beispiel: Eine Marketing-Mitarbeiterin bittet Copilot um „eine Liste aller anstehenden Firmenakquisitionen“ – Copilot findet ein SharePoint-Dokument der Geschäftsführung (falsch berechtigt) und fasst es zusammen. Plötzlich kennt die ganze Marketing-Abteilung streng vertrauliche Pläne. Das Need-to-know-Prinzip wäre ausgehebelt. Zusätzlich besteht die Gefahr, dass vertrauliche Inhalte das Unternehmen unkontrolliert verlassen: z. B. indem jemand eine interne Copilot-Antwort mit sensiblen Details kopiert und extern teilt, oder durch Plugins, die Daten an Drittanbieter senden. Governance muss daher strikte Vertraulichkeitsregeln vorgeben: Etwa indem es Berechtigungen eng führt, DLP-Regeln konfiguriert (siehe 5.4) und durch Nutzerschulungen klargemacht wird, welche Arten von Informationen tabu für Prompts sind. Ohne Governance ist ein Datenleck fast vorprogrammiert, weil Benutzer die Tragweite der KI oft unterschätzen.
• Risiko für die Integrität (Integrity): Integrität bedeutet hier korrekte, unveränderte Information. Copilot ist ein probabilistisches Modell – es kann sogenannte Halluzinationen erzeugen, also plausibel klingende, aber faktisch falsche Inhalte. Ohne Vorgaben könnten Mitarbeiter solche falschen Ausgaben ungefiltert übernehmen. Das gefährdet die fachliche Richtigkeit und Verlässlichkeit Ihrer Dokumente, Berichte oder Entscheidungen. Beispielsweise: Copilot beantwortet eine juristische Frage im Intranet mit einem erfundenen Paragraphen – wenn das niemand prüft, handelt das Unternehmen evtl. falsch und macht sich haftbar. Auch besteht ein Integritätsrisiko, wenn Copilot Inhalte misinterpretiert oder aus dem Zusammenhang reißt. Governance zielt darauf ab, die Integrität zu schützen, indem sie Qualitätssicherungsmaßnahmen vorschreibt (z. B. „kritische Copilot-Antworten müssen durch einen Fachexperten verifiziert werden“), und Nutzer dazu anhält, Quellen einzusehen. Außerdem kann Governance steuern, dass Copilot bevorzugt auf validierte Daten zugreift (z. B. offizielle Wissensdatenbank vs. irgendein altes Dokument), um die Wahrscheinlichkeit korrekter Ausgaben zu erhöhen. Kurz: Ohne Governance drohen Fehlinformationen, die zu Fehlentscheidungen oder peinlichen Fehlern führen könnten.
• Risiko für die Verfügbarkeit (Availability): Copilot wird schnell zu einem geschätzten Helfer – was, wenn er ausfällt oder entfernt werden muss? Ohne Plan B könnten Arbeitsabläufe ins Stocken geraten. Dieses Risiko ist zweischneidig: Einerseits könnte ein technischer Ausfall von Copilot (z. B. Cloud-Dienst Störung) temporär die Produktivität beeinträchtigen, wenn Mitarbeiter sich daran gewöhnt haben. Governance sollte daher die IT-Bereitschaft planen: z. B. Copilot-Ausfälle im Incident-Management berücksichtigen und Nutzer wissen lassen, dass sie in kritischen Phasen nicht 100% auf KI verlassen sollten (Resilienz). Andererseits gibt es das Szenario, dass Copilot aus Compliance-Gründen abgeschaltet werden müsste (etwa nach einem schweren Vorfall oder bei neuen regulatorischen Auflagen). Unternehmen ohne Governance-Strategie stünden dann abrupt ohne KI-Unterstützung da. Mit Governance hingegen identifiziert man Geschäftsprozesse, die stark auf Copilot setzen, und hält ggf. konventionelle Alternativen oder manuelle Verfahren in der Hinterhand. Insgesamt ist das Verfügbarkeitsrisiko durch Copilot beherrschbar, aber nur, wenn es bewusst adressiert wird (z. B. Notfallplan „KI-Offliner“ definieren, falls z. B. externe Aufsichtsbehörde es verlangen würde, Copilot temporär zu deaktivieren).
• Risiko Datenabfluss (Exfiltration): Eng verwandt mit Vertraulichkeit, aber noch spezifischer: Copilot könnte Daten dort hinbringen, wo sie nicht hingehören. Ein Beispiel: Ein Mitarbeiter kopiert einen Chatverlauf mit Copilot und sendet ihn an einen externen Partner (vielleicht ohne maliziöse Absicht, sondern um zu zeigen, „schau mal was unser Copilot kann“). Wenn in dem Verlauf interne Daten stehen, sind diese nun extern. Oder: Ein Plugin, das von Copilot verwendet wird, leitet Anfragen an einen fremden Service weiter (z. B. ein Übersetzungsservice) und dabei gehen intern eingegebene Texte außer Haus. Ohne klare Regeln und technische Sperren können solche Abflüsse unentdeckt passieren. Copilot-Governance muss dem vorbeugen, z. B. indem Plugins streng geprüft werden und standardmäßig keine Websuche/offene Kommunikation nach außen erfolgt, es sei denn, es ist genehmigt. Auch Insider-Risiken müssen betrachtet werden: Ein böswilliger Mitarbeiter könnte Copilot nutzen, um systematisch vertrauliche Daten zusammenzutragen, die er dann exfiltriert. Hier können Logging und Anomalieerkennung (siehe 5.3, 5.4) helfen. Letztlich ist Governance unverzichtbar, um sicherzustellen, dass Daten dort bleiben, wo sie hingehören – innerhalb der vertrauenswürdigen Umgebung.
• Risiko Halluzination / Falschinformation: Schon angesprochen unter Integrität, aber so wichtig, dass es separat genannt sei: Halluzinationen sind spezifisch das Phänomen, dass die KI Informationen erfindet. Für Governance bedeutet das, Richtlinien zu etablieren, die den Umgang mit KI-Fehlern regeln. Zum Beispiel könnte eine Policy festhalten: „Copilot-Antworten dürfen nicht ungeprüft an Kunden weitergeleitet werden“ oder „Bei Unklarheiten in einer KI-Antwort ist diese zu verwerfen oder zu verifizieren“. Ohne solche Regeln verlassen sich manche Nutzer vielleicht blind auf die KI, was zu gravierenden Fehlern führen kann (z. B. falsche Finanzzahlen in einem Bericht). Auch muss Schulung stattfinden, damit Anwender Halluzinationen erkennen (etwa ungewöhnlich präzise Auskünfte ohne Quelle sind verdächtig). Ohne Governance kann sich Fehlinformation unbemerkt verbreiten und die Glaubwürdigkeit des Unternehmens untergraben.
• Risiko Urheberrecht (Copyright): Copilot generiert Inhalte auf Basis von trainierten Daten und den bereitgestellten Unternehmensinformationen. Hier gibt es zwei Arten von Urheberrechtsrisiken:
• Interne Informationen mit Schutzrechten: Falls Copilot Informationen aus urheberrechtlich geschützten Dokumenten des Unternehmens zieht (oder die das Unternehmen von Dritten lizenziert hat), stellt sich die Frage, ob die KI-Ausgabe gegen Nutzungsbeschränkungen verstößt. Beispiel: Eine externe Studie darf intern gelesen, aber nicht einfach kopiert werden. Fragt nun jemand Copilot nach einer Zusammenfassung, könnte diese – je nach Umfang – gegen die Lizenz verstoßen (wenn z. B. weite Passagen fast wortgleich ausgegeben werden). Governance muss definieren, inwiefern solcher Content genutzt werden darf. Evtl. muss man Copilot-Zugriff auf bestimmte Sammlungen beschränken, um Lizenzauflagen einzuhalten.
• Vom KI-Modell generierte Inhalte: Es gilt als wahrscheinlich, dass rein KI-generierte Texte und Bilder keinen klassischen Urheberrechtsschutz genießen (weil kein menschlicher Schöpfer). Das heißt, Output von Copilot ist vermutlich frei verwendbar – allerdings gibt es Unsicherheit in Rechtsauslegung. Zudem könnten im Training des Modells urheberrechtlich geschützte Werke eingeflossen sein, was im worst case dazu führt, dass Copilot bekannte Texte nahezu zitiert (eher selten, aber möglich, z. B. bei bestimmten Code-Snippets war das bei anderen KI-Modellen ein Thema). Ohne Governance besteht das Risiko, dass das Unternehmen unwissentlich gegen Urheberrechte verstößt oder später nicht klären kann, wem erstellte Inhalte gehören. Mit Governance kann man Regeln setzen, wie KI-Ergebnisse weiterverwendet werden dürfen: z. B. Hinweis, dass Mitarbeiter bei Veröffentlichung von KI-erstellten Texten prüfen müssen, dass keine geschützten Texte 1:1 enthalten sind, oder dass sie KI-Inhalte als solche kennzeichnen, falls dies rechtlich gefordert wird. Zudem sollte klar sein, dass alle mittels Copilot erzeugten Inhalte für Unternehmenszwecke genutzt werden dürfen und keine individuellen Ansprüche geltend gemacht werden (Mitarbeiter könnten sonst fragen, ob sie „Autor“ eines Copilot-Textes sind – hier sollte klargestellt sein, dass es zum Arbeitsprodukt gehört).
• Haftungsrisiken: Wer haftet, wenn Copilot einen Fehler macht? Juristisch ist das Feld neu. Doch aus Sicht der Unternehmensleitung ist klar: Das Unternehmen trägt letztlich die Verantwortung für seine Handlungen, auch wenn ein KI-Tool beteiligt war. Ohne Governance laufen Mitarbeiter Gefahr, dem Copilot eine Entscheidung zu überlassen, für die sie selbst gar nicht autorisiert wären. Beispiel: Copilot formuliert eine Antwort an einen Kunden, die eine Zusicherung enthält – der Sachbearbeiter klickt nur noch auf Senden. Wenn diese Zusicherung falsch ist, haftet das Unternehmen. Governance muss vorbeugen, indem sie festlegt, dass Copilot nicht für Entscheidungen, sondern zur Assistenz da ist. Außerdem sollte abgesteckt sein, welche Inhalte NICHT mit KI erzeugt werden dürfen (z. B. rechtliche Bewertungen sollten immer von Legal geprüft werden, KI kann höchstens zuarbeiten). Ein weiterer Aspekt: Datenschutz-Haftung. Sollte Copilot personenbezogene Daten unzulässig verarbeiten (z. B. sensible Daten im Prompt ohne Rechtsgrundlage), haftet das Unternehmen für DSGVO-Verstöße. Daher ist ein DPIA etc. Pflicht (siehe 2.3). Nicht zuletzt: Ethik und Reputation – gibt Copilot etwas potenziell Diskriminierendes oder Unangemessenes aus, könnte das Unternehmen zur Verantwortung gezogen werden (Stichwort „verantwortungsvolle KI“ – hier hat Microsoft zwar Filter, aber 100% ausschließen kann man peinliche Ausgaben nicht). Governance sollte definieren, wie auf solche Vorfälle reagiert wird und dass Mitarbeiter verpflichtet sind, problematische Outputs sofort zu melden und nicht zu verbreiten.

Diese umfangreiche Risikoanalyse zeigt, dass fast alle klassischen Schutzziele der IT (CIA: Confidentiality, Integrity, Availability) plus zusätzliche KI-spezifische Risiken betroffen sind. Copilot-Governance adressiert diese durch gezielte Kontrollen und Regeln in organisatorischer, technischer und prozessualer Hinsicht (siehe weitere Kapitel). Die Erfahrung zeigt: Unternehmen, die ohne KI-Governance starten, erleben früher oder später einen Zwischenfall – sei es ein Datenleck, ein falscher Inhalt mit Folgen oder interne Verunsicherung. Solche Vorfälle können das Vertrauen in die neue Technologie erschüttern und den Rollout verzögern oder stoppen. Daher ist es unverzichtbar, von Anfang an eine fundierte Risikoanalyse zu betreiben und entsprechende Maßnahmen abzuleiten – genau das leistet Copilot-Governance.

Praxistipps am Ende von 2.2:
– Risiko-Workshop durchführen: Bevor Copilot ausgerollt wird, setzen Sie Vertreter von IT-Security, Datenschutz, Fachbereichen und Recht an einen Tisch und sammeln Sie gemeinsam mögliche Risiken/”Was, wenn…”-Szenarien. Dieses Brainstorming schärft das Bewusstsein und fließt idealerweise in ein formales Risikoregister (vgl. Kapitel 9) ein.
– Keine Panikmache – aber realistisch bleiben: Kommunizieren Sie intern offen über die Risiken und die getroffenen Gegenmaßnahmen. Wenn Mitarbeitende wissen, dass z. B. „Halluzinationen vorkommen können, aber wir haben dafür Regel X“ oder „Daten sind geschützt durch Maßnahme Y“, nehmen sie Copilot ernst, aber verlieren nicht das Vertrauen.

2.3 Regulatorische Treiber: DSGVO, Aufbewahrung/Records, Prüf- und Dokumentationspflichten

Neben den internen Risiken zwingen auch externe Vorgaben praktisch jedes mittlere und große Unternehmen dazu, Copilot-Governance einzuführen. Die wichtigsten regulatorischen Treiber sind:

• Datenschutz (DSGVO): Copilot verarbeitet personenbeziehbare Daten – z. B. Inhalte von Mails (Absender, Empfänger), Chat-Nachrichten, Dokumente mit Mitarbeiter- oder Kundendaten, etc. Damit findet eine automatisierte Verarbeitung statt, die der DSGVO unterliegt. Unternehmen müssen Rechenschaft darüber ablegen können, welche personenbezogenen Daten wie verarbeitet werden. Ein Copilot-Modell kann zwar als „Auftragsverarbeitung durch Microsoft“ betrachtet werden (Microsoft betont die Einhaltung von GDPR in seinem Copilot-Dienst), dennoch bleiben gewisse Pflichten beim Unternehmen:
• DPIA (Datenschutz-Folgenabschätzung): Für den Einsatz einer derart neuartigen Technologie, die umfangreiche Daten verarbeitet, wird in vielen Fällen eine Datenschutz-Folgenabschätzung angeraten oder sogar gefordert sein. Hier werden Risiken für Rechte und Freiheiten der Betroffenen analysiert (z. B. könnte Copilot intern sensible Gesundheitsdaten eines Mitarbeiters in einer Antwort offenlegen – wie wird das verhindert?) und entsprechende Schutzmaßnahmen dokumentiert. Copilot-Governance liefert genau diese Schutzmaßnahmen (Policies, Zugriffskontrollen, Logging) und muss im DPIA beschrieben werden. Ohne Governance würde eine DPIA vermutlich zum Schluss kommen, dass das Risiko nicht vertretbar ist.
• Transparenz & Zweckbindung: Nutzer (Mitarbeiter) müssen darüber informiert werden, dass ihre in M365 erzeugten Daten durch Copilot verarbeitet werden. Datenschutzrechtlich sollte klar definiert sein, zu welchem Zweck die KI genutzt wird (z. B. „zur Steigerung der Effizienz interner Arbeitsprozesse“). Governance muss sicherstellen, dass Copilot nicht plötzlich zu anderen Zwecken missbraucht wird (z. B. man lässt Copilot Mitarbeiterdaten auswerten, um Leistungsprofile zu erstellen – das wäre ein anderer Zweck und datenschutzrechtlich problematisch). Daher empfiehlt es sich, eine interne Richtlinie oder Nutzungsinformation zu erstellen, in der der Umgang mit personenbezogenen Daten bei Copilot geklärt ist.
• Betroffenenrechte & Löschung: Die DSGVO fordert, dass personenbezogene Daten auf Verlangen offengelegt, berichtigt oder gelöscht werden können. Hier muss man Copilot-spezifisch überlegen: Falls ein Mitarbeiter seine via Copilot gespeicherten Interaktionen gelöscht haben will (z. B. in seinem Activity Log), bietet Microsoft dafür Funktionen (Nutzer können Verlauf selbst löschen; Admins können nach gewisser Zeit automatisiert löschen via Retention). Governance sollte definieren, wie lange solche Daten vorgehalten werden (dazu im nächsten Punkt mehr) und wie auf Auskunftsersuchen reagiert wird – etwa könnte ein Betroffener fragen: „Welche meiner personenbezogenen Daten wurden durch Copilot genutzt?“ Das ist schwer exakt zu beantworten, aber man kann zumindest darlegen, aus welchen Datenquellen Copilot geschöpft haben könnte.
• Fazit DSGVO: Copilot-Governance ist nötig, um datenschutzkonform zu sein. Ohne eine strukturierte Herangehensweise und dokumentierte Maßnahmen läuft man Gefahr, gegen Grundprinzipien (Datenminimierung, Zweckbindung, Transparenz) zu verstoßen, was empfindliche Strafen oder zumindest Reputationsschäden nach sich ziehen kann.
• Aufbewahrungspflichten / Records Management: Viele Unternehmen unterliegen gesetzlichen oder internen Aufbewahrungsfristen für bestimmte Unterlagen (z. B. Handelsbriefe 6 Jahre, steuerrelevante Dokumente 10 Jahre, Protokolle, Verträge etc.). Eine Herausforderung mit Copilot ist, dass es neue Formen von „Kommunikation“ und „Inhalten“ schafft, die zuvor nicht da waren. Zum Beispiel: Business Chat in Copilot (über Teams) kann unternehmensweit nach Informationen suchen und liefert Antworten, die ähnlich wie E-Mails oder Chat-Nachrichten sind – gelten diese als aufzubewahrende Kommunikation? Finanzdienstleister z. B. müssen Kundenberatungsprotokolle aufbewahren; wenn ein Berater Copilot nutzt, um eine Anlageempfehlung zu formulieren, muss diese Interaktion dann archiviert werden? Wahrscheinlich ja, aus Sicht der Regulatorik muss der Einsatz von KI so dokumentiert werden, dass ein Prüfer später alles nachvollziehen kann. Microsoft hat angekündigt, dass alle Copilot-Interaktionen im Audit-Log erfasst werden und via eDiscovery/Content Search auffindbar sind. Das ermöglicht die Integration in Records-Management-Prozesse: Man könnte z. B. festlegen, dass bestimmte Arten von Copilot-Chats als „Geschäftskommunikation“ klassifiziert und entsprechend archiviert werden. Copilot-Governance muss hier Leitlinien setzen: was wird aufbewahrt, wie lange und in welcher Form? Möglicherweise führt man neue Kategorien ein, z. B. einen Label „KI-generierte Inhalte – relevant“ den der Nutzer vergeben muss, wenn z. B. eine Copilot-Ausgabe eine Entscheidung beeinflusst hat. Auch ist es wichtig, Copilot in bestehende Archivierungswerkzeuge einzubinden (ggf. Third-Party-Lösungen, siehe Smarsh in 1.3). Ohne Governance könnten wichtige KI-Ausgaben verloren gehen, was im Nachhinein zu Audit-Problemen führt („zeigen Sie uns die Unterlagen dazu“ – „hatte die KI erstellt, haben wir aber nicht mehr“). Zudem gibt es rechtliche Grauzonen: Muss man KI-Content mit aufbewahren oder reicht es, die Primärdokumente zu halten? Bis der Gesetzgeber hier Klarheit schafft, ist es besser, mehr Nachweise zu haben als zu wenig. Copilot-Governance stellt sicher, dass das Unternehmen hier auf der sicheren Seite ist und im Zweifel nachweisen kann, was die KI geliefert hat.
• Prüf- und Dokumentationspflichten: Neben konkreten Aufbewahrungsvorschriften gibt es branchenabhängig vielfältige Anforderungen an interne Kontrollen und Dokumentationen. Beispielsweise:
• Ein Internes Kontrollsystem (IKS) nach SOX oder ähnlichen Standards muss relevante IT-Systeme und deren Kontrollen dokumentieren. Copilot als neues System muss hier abgebildet sein, inkl. wer Zugriff hat, welche Changes es gibt etc. Copilot-Governance liefert diese Dokumentation (z. B. Rollen & Zugriffssteuerung).
• Interne/Externe Audits (ISO 27001, TISAX etc.) werden fragen: „Wie stellen Sie die Sicherheit und Compliance beim Einsatz von KI-Tools sicher?“ Ohne Governance hätte man darauf keine gute Antwort. Mit Governance kann man dem Auditor ein klar umrissenes Konzept vorlegen: Policies, Schulungen, technische Maßnahmen, Monitoring – alles schriftlich fixiert. Das zeigt Prüfern, dass das Unternehmen die Kontrolle behält.
• In stark regulierten Feldern (Finanz, Gesundheitswesen) geben Aufsichtsbehörden teils sehr konkrete Leitlinien: Z. B. erwarten einige Finanzaufsichten, dass beim Einsatz von KI eine Art Algorithmus-Governance implementiert ist, inklusive laufender Risikobewertung und Berichtspflichten ans Management. Copilot-Governance kann diese Anforderungen erfüllen, indem sie ein regelmäßiges Reporting (siehe Abschnitt 8.2) und ein KVP (kontinuierlicher Verbesserungsprozess, Abschnitt 8.3) etabliert – das sind Elemente, die Prüfer in Governance, Risk & Compliance (GRC) Abteilungen sehen wollen.
• Darüber hinaus kann es branchenspezifische Vorgaben geben, z. B. die EU-Kommission arbeitet am AI Act, der je nach Risikoklassifizierung des KI-Einsatzes Transparenz und Risikomanagement verlangt. Schon jetzt gilt: Jeder, der KI einsetzt, sollte sich auf strengere Prüfungen in Zukunft einstellen. Copilot-Governance ist die Vorbereitung darauf. Insgesamt erzwingt der regulatorische Druck ein systematisches Vorgehen. Die Vorstellung, Copilot „mal nebenbei“ einzuführen, ohne mit Compliance/Datenschutz zu sprechen, ist unrealistisch – spätestens bei der nächsten Auditierung käme das als Feststellung. Es ist viel effizienter, proaktiv Governance aufzusetzen, als später Vorfälle zu korrigieren oder Strafen zu riskieren.

Somit ist klar: Copilot-Governance ist nicht nur Kür, sondern Pflicht, um Gesetze und Auflagen einzuhalten. Sie hilft, die notwendigen Nachweise bereitzuhalten und in Audits bestehen zu können. Ein Governance-Framework fungiert dabei auch als Schutzschild gegenüber dem Vorwurf der Fahrlässigkeit: Wenn etwas schiefgeht, kann das Unternehmen wenigstens zeigen, dass es angemessene Vorkehrungen getroffen hatte (was bei der Bewertung durch Behörden mildernd wirkt). Ohne Governance stünde man im Ernstfall blank da.

Praxistipps am Ende von 2.3:
– Frühzeitige Abstimmung mit Datenschutz und Compliance: Beziehen Sie den Datenschutzbeauftragten und Compliance Officer von Anfang an ein. Lassen Sie sich beraten, welche internen Genehmigungsschritte (z. B. Datenschutz-Folgenabschätzung absegnen, Betriebsrat informieren) nötig sind. So vermeiden Sie spätere Einführungstopps durch ungeplante Bedenken.
– Dokumentation mitführen: Erstellen Sie ein „Copilot-Compliance-Dossier“, in dem alle relevanten Unterlagen gesammelt sind: DPIA-Bericht, Schulungskonzepte, Policy-Dokumente, technische Konfigurationen, Kommunikation an Mitarbeiter. Diese Bündelung erleichtert es, bei Audits oder Rückfragen schnell nachzuweisen, dass alle Pflichten beachtet wurden.

2.4 Wirtschaftlichkeit: Business Case, Kostenarten, Nutzenhebel, ROI-Messung

Neben Sicherheits- und Compliance-Aspekten gibt es einen ganz pragmatischen Grund für Copilot-Governance: die ökonomische Steuerung des Copilot-Einsatzes. Microsoft 365 Copilot ist ein teures Zusatzprodukt (Lizenzkosten pro Nutzer kommen on top zu bestehenden M365-Kosten). Das Management wird zurecht fragen: „Lohnt sich das? Wie stellen wir sicher, dass wir einen Return on Investment erzielen?“ Copilot-Governance liefert auch hier Antworten:

• Business Case untermauern: In einem Business Case werden die erwarteten Nutzen in Euro den Kosten gegenübergestellt. Copilot-Governance hilft erstens, die Nutzenpotentiale (siehe 2.1) tatsächlich zu heben, und zweitens, sie messbar zu machen. Beispielsweise kann Governance vorschreiben, dass Mitarbeiter bei der Pilotierung Zeiten erfassen oder Feedback geben zu „Zeit gespart durch Copilot“. Oder sie richtet KPIs ein wie „Anzahl erstellter Dokumente per Copilot pro Monat“. Solche Datenpunkte fließen ins Controlling ein und quantifizieren den Nutzen. Gleichzeitig fallen mit Governance weniger Störfälle an, die zu ineffizientem Umgang oder gar Abschaltung führen könnten – der Nutzen kann also kontinuierlich realisiert werden, ohne große Unterbrechungen oder Reibungsverluste. Ein sauberer Business Case – der dank Governance auch erreicht wird – rechtfertigt die Investition intern.
• Kostenarten kennen und steuern: Die Kosten bei Copilot sind nicht nur Lizenzen (auch wenn diese signifikant sind). Weitere Kostenpunkte:
• Implementierungskosten: Aufwand für Projekt, Governance-Erarbeitung, Schulung – das sind Personal- und evtl. Beratungskosten.
• Kosten für begleitende Tools: Vielleicht benötigt man Upgrades (z. B. auf E5 für Purview-Funktionen), oder kauft Dritt-Tools (z. B. ein Plugin-Review-Tool oder ein Audit-Archiv wie in regulierten Branchen).
• Betriebskosten: Der laufende Support und das Monitoring von Copilot, regelmäßige Schulungen für neue Nutzer, Aufwand für die Governance-Meetings etc. – das sind alles Ressourcen, die gebunden werden. Ohne Governance besteht die Gefahr, diese Kosten nicht im Blick zu haben: z. B. werden Lizenzen gekauft für alle, aber nur die Hälfte nutzt Copilot aktiv – Geld wird verschwendet (Fehllizenzen). Oder man investiert in teure Tools ohne Plan. Mit Governance kann man Richtlinien zur Kostenkontrolle einführen: z. B. stufenweiser Lizenzkauf (Rollout in Wellen, erst wenn Nutzen belegt, nächste Welle lizenzieren), regelmäßige Lizenznutzungsanalyse (siehe 6.10), und klare Prozessschritte, wann externe Tools angeschafft werden dürfen (z. B. „Plugin-Requests, die wir intern nicht prüfen können, erfordern Sonderbudget-Freigabe“). Weiterhin erlaubt die Governance-Organisation (insb. Monitoring, s. 5.3) frühzeitig zu erkennen, wenn Kosten aus dem Ruder laufen – etwa ein unerwartet hoher Zugriff auf ein kostenpflichtiges externes API via Plugin, oder überflüssige Ausgaben für Lizenzen. Dann kann gegengesteuert werden (Kostenhebel: Funktionen drosseln, ungenutzte Lizenzen zurückgeben, etc.).
• Nutzenhebel maximieren: Nicht jeder Nutzen realisiert sich von allein. Governance kann gezielt Hebel betätigen, um den ROI zu erhöhen. Beispiele:
• Gezielte Nutzung fördern: Durch interne Kommunikation und Trainings (Teil der Governance-Aufgaben) wird die Adoption erhöht. Je mehr Mitarbeiter Copilot sinnvoll nutzen, desto mehr Wert schöpft man aus den fixen Lizenzkosten.
• Quick Wins identifizieren: Governance führt typischerweise Piloten durch und analysiert, wo Copilot am meisten bringt. Diese Quick-Win-Szenarien kann man priorisieren und standardisieren. Vielleicht stellt sich heraus, dass Copilot im Kundenservice 30% Zeit spart bei Mail-Beantwortungen – dann könnte Governance in Absprache mit der Fachleitung definieren, dass alle Kundenservice-Mitarbeiter Copilot schulen und nutzen sollen. So wird der Hebel voll angesetzt.
• Ineffizienzen vermeiden: Ohne Koordination könnten manche Mitarbeiter Copilot falsch oder für ungeeignete Aufgaben nutzen (z. B. lange herumprobieren, wo es keinen Mehrwert liefert). Governance – etwa in Form einer zentralen „Copilot Sprechstunde“ oder von Champions – kann diese Fehlnutzung minimieren, indem Best Practices ausgetauscht werden. Effiziente Nutzung = höherer ROI.
• Wettbewerbsvorteile sichern: Wenn Governance auch strategische Aspekte einbezieht, kann Copilot z. B. eingesetzt werden, um schneller Innovationen hervorzubringen (z. B. Rapid Prototyping von Ideen mit KI-Hilfe). Ein Unternehmen mit starker KI-Governance ist agiler und kann Marktchancen besser nutzen, was indirekt wirtschaftlichen Vorteil bringt.
• ROI-Messung und Reporting: Schließlich ermöglicht Copilot-Governance, den Erfolg messbar zu machen und zu kommunizieren. KPIs wie „Geschätzte Zeitersparnis durch Copilot diesen Quartal: 500 Stunden“ oder „Zufriedenheit der Nutzer: 90% finden Copilot hilfreich“ sind Gold wert, wenn es darum geht, dem Vorstand zu zeigen, dass die Initiative sinnvoll ist. Diese Daten kommen nicht von allein – Governance muss sie erheben (Kap. 8.1/8.2). Wenn der ROI klar nachgewiesen ist, steht einer Weiterführung oder Ausweitung nichts im Wege. Fehlt dieser Nachweis, droht im schlechtesten Fall, dass das Projekt bei Budgetkürzungen gestrichen wird („Wir wissen gar nicht, ob uns das was bringt, also sparen wir es ein.“).

Kurzum, Copilot-Governance trägt erheblich dazu bei, dass das Investitionsversprechen erfüllt wird. Sie sorgt dafür, dass Geld nur dort ausgegeben wird, wo Nutzen entsteht, und dass der Nutzen auch eingefahren wird. Ungeplante Kosten (z. B. durch Zwischenfälle oder ineffiziente Nutzung) werden vermieden. Gerade im Gespräch mit der Finanzabteilung ist es hilfreich zu betonen: „Wir haben ein enges Governance-System, das sicherstellt, dass jeder Euro für Copilot sinnvoll eingesetzt ist.“

Praxistipps am Ende von 2.4:
– Kosten-Nutzen-Planung parallel zur Governance planen: Integrieren Sie Controlling früh in das Governance-Team. Entwickeln Sie Kennzahlen, wie Sie den Nutzen erfassen (z. B. Umfrage „Wie viel Zeit hat Copilot Ihnen diese Woche gespart?“) und definieren Sie, wer Kosten und Nutzen quartalsweise gegenüberstellt.
– Lizenzmanagement streng handhaben: Behalten Sie die Lizenzierung flexibel. Statt sofort für alle 5000 Mitarbeiter Lizenzen zu kaufen, beginnen Sie mit einer kleinen Zahl, messen Sie die Nutzung und erweitern Sie stufenweise. Legen Sie in der Governance fest, wer entscheiden darf, wenn Nachlizenziert wird (z. B. nur nach Freigabe durch Steering Committee, basierend auf Nutzungsdaten). Das verhindert Überprovisionierung.

3. Organisationsmodell & Rollen

3.1 Rollen/RACI (z. B. CIO, CISO, Datenschutz, Fachbereiche, Betriebsrat, M365-Admin, Copilot-Produktverantwortung)

Eine wirksame Copilot-Governance benötigt ein klares Organisationsmodell mit definierten Rollen und Verantwortlichkeiten. Das vermeidet Zuständigkeitslücken und erleichtert die Abstimmung. Typische Rollen im Kontext Copilot-Governance sind:

• Geschäftsführung / CIO (Chief Information Officer): Die höchste Leitungsebene, die den Einsatz von Copilot strategisch verantwortet. Der CIO ist oft Sponsor des Projekts und muss gewährleisten, dass Copilot mit der IT-Strategie im Einklang steht. In Governance-Begriffen: Der CIO bzw. die Geschäftsführung genehmigt das Governance-Konzept insgesamt und trägt die letztliche Verantwortung (Accountability) für Erfolg oder Misserfolg. Er delegiert Aufgaben an die Fachverantwortlichen und sorgt für die Bereitstellung von Ressourcen. Auch Priorisierungsentscheidungen (z. B. Freigabe von Budget für zusätzliche Sicherheitsmaßnahmen) liegen hier. In RACI-Terminologie: Accountable für die gesamte Copilot-Governance-Initiative; Informed über wichtige Fortschritte und Risiken.
• CISO (Chief Information Security Officer) / IT-Sicherheitsbeauftragter: Diese Rolle kümmert sich um alle Sicherheitsaspekte von Copilot. Der CISO ist verantwortlich dafür, dass passende technische und organisatorische Sicherheitsmaßnahmen implementiert werden (Zugriffskontrollen, Monitoring, Incident Response). Er definiert zusammen mit seinem Team Security Policies und überprüft deren Einhaltung. Im Eskalationsfall (z. B. vermutetes Datenleck via Copilot) koordiniert der CISO die Reaktion. In RACI: Responsible für die Sicherheit von Copilot (d. h. er setzt um und überwacht); Accountable im Sinne der endgültigen Entscheidung bei Sicherheitsfragen oft ebenfalls CISO oder gemeinschaftlich mit CIO; andere Stakeholder Consulted bei Sicherheitsmaßnahmen (z. B. Datenschutz bei DLP-Regeln) und Informed über Sicherheitsvorfälle.
• Datenschutzbeauftragter (DSB) / CDO (Chief Data Officer) für Privacy: Diese Person stellt sicher, dass Copilot den Datenschutzbestimmungen entspricht. Sie führt oder prüft die Datenschutz-Folgenabschätzung durch, formuliert Regeln zum Umgang mit personenbezogenen Daten in Prompts und Antworten und schult entsprechend. Sie muss eng mit dem CISO und dem Copilot-Verantwortlichen zusammenarbeiten, um z. B. Löschkonzepte und Transparenzhinweise umzusetzen. In RACI: Responsible für Privacy-Compliance (erarbeitet Richtlinien, prüft Prozesse); Consulted bei allen Änderungen oder Vorfällen mit Personendaten; Informed über generelle Einführung und Ergebnisse des Projekts.
• Fachbereichsleitung / Prozessverantwortliche: Die Führungskräfte der Abteilungen, in denen Copilot eingesetzt wird, haben zwei Rollen. Erstens bringen sie Anforderungen ein: Welche Use Cases gibt es, wo braucht man Leitlinien? Zweitens müssen sie darauf achten, dass ihre Mitarbeiter die Copilot-Regeln einhalten und die Technik produktiv nutzen. Sie sind sozusagen Brückenköpfe zwischen Governance-Team und Endanwendern. Ein Fachbereichsleiter kann z. B. als Copilot-Champion fungieren, der Best Practices innerhalb seines Bereichs fördert und Feedback ans Governance Board zurückmeldet. In RACI: Responsible dafür, die Governance-Vorgaben im eigenen Bereich umzusetzen (z. B. Prozesse anpassen, Nutzer motivieren); Accountable für die Ergebnisse in seinem Bereich (Nutzen, keine Verstöße); Consulted bei der Erstellung von Richtlinien (Fachperspektive einbringen); Informed über alle relevanten Governance-Entscheidungen, die seine Abteilung betreffen.
• Betriebsrat / Arbeitnehmervertretung: In deutschen Unternehmen ist der Betriebsrat ein wichtiger Partner, wenn neue Technologien eingeführt werden, die Mitarbeiter betreffen. Copilot fällt typischerweise unter mitbestimmungspflichtige Themen, z. B. Regelungen zur Nutzung von Software, Leistungs- und Verhaltenskontrolle etc. Der Betriebsrat sollte daher früh einbezogen werden. Seine Rolle in der Governance: Sicherstellen, dass Mitarbeiterrechte gewahrt bleiben, insbesondere Datenschutz der Mitarbeiter und dass Copilot nicht zur Überwachung zweckentfremdet wird. Er wird oft eine Betriebsvereinbarung zum Copilot-Einsatz fordern, die gemeinsam mit der Geschäftsleitung ausgearbeitet wird. Im laufenden Betrieb sollte der Betriebsrat über größere Änderungen (z. B. Einführung neuer Plugins, neue Nutzungsrichtlinien) informiert werden. In RACI: Consulted bei der Erarbeitung von Regeln (damit Anliegen der Belegschaft berücksichtigt werden); Agreement required (als Sonderfall: manches geht nicht ohne seine Zustimmung, z. B. wenn eine Mitbestimmung vorliegt, dann quasi Accountable gemeinsam für die BV); Informed über die Einführung, Schulungspläne und Ergebnisse, um Vertrauen zu schaffen.
• Microsoft 365-Administrator / IT-Betrieb: Das technische Rückgrat: Diese Rolle (oft ein Team) setzt die beschlossenen Einstellungen um. Der M365-Admin verwaltet die Copilot-Lizenzen, konfiguriert Tenant-Einstellungen (siehe 5.1), richtet Graph Connectors ein, setzt DLP-Policies auf etc. Er ist auch erster Ansprechpartner, wenn etwas technisch nicht funktioniert, und übernimmt die Kommunikation mit Microsoft Support bei Problemen. In der Governance-Struktur ist der Admin ausführend verantwortlich (Responsible) für die Umsetzung der technischen Kontrollen und hält diese am Laufen (Monitoring betreiben, Logs sammeln). Strategische Entscheidungen trifft er aber in der Regel nicht allein – er führt aus, was Governance Board/CISO etc. beschlossen haben. In RACI: Responsible (for implementation) für alle technischen Maßnahmen; Consulted bei der Festlegung, was möglich/sinnvoll ist (er bringt das technische Know-how ein); Informed über Policy-Entscheidungen, damit er diese korrekt umsetzt.
• Copilot-Produktverantwortlicher / KI-Governance-Manager: Es empfiehlt sich, jemanden als Product Owner für Copilot zu benennen – eine zentrale Rolle, die die Einführung und den Betrieb von Copilot koordiniert. Diese Person kennt sowohl die fachlichen Einsatzzwecke als auch die technischen Feinheiten und fungiert als Dreh- und Angelpunkt zwischen allen Beteiligten. Typische Aufgaben: das Governance-Board moderieren, Pilotprojekte organisieren, Anforderungen sammeln, Schulungskonzepte erstellen, den ROI tracken. Im Grunde ist das der Projektleiter in der Einführungsphase und später der Service Manager im Betrieb. In RACI: Accountable für den Erfolg des Copilot-Einsatzes im Sinne des Projekts (er sorgt dafür, dass Nutzenziele erreicht werden und Governance-Maßnahmen greifen); Responsible für die Koordination (Meetings, Berichte, Dokumentation); Consulted durch alle anderen (er sammelt Input von CISO, DSB, Fachbereichen etc.); Informed muss er über alles sein (zentraler Wissenshub). Oft ist das jemand aus der IT-Organisation mit bereichsübergreifendem Verständnis.
• Endanwender / Mitarbeitende / Power User: Nicht zu vergessen: Die Nutzer selbst haben natürlich Pflichten in der Governance. Jeder Mitarbeiter, der Copilot nutzt, übernimmt die Verantwortung, die Richtlinien einzuhalten (z. B. keine verbotenen Prompts, keine Weitergabe sensibler KI-Antworten etc.). In RACI-Tabellen taucht der einzelne User selten auf, aber man könnte sagen: Responsible für die korrekte Anwendung im Einzelfall; Accountable für die unmittelbaren Handlungen (der Mitarbeiter muss im Zweifel geradestehen, wenn er grob fahrlässig gegen Nutzungsregeln verstößt – disziplinarische Komponente); Informed durch Schulungen, was er darf und nicht darf.

Je nach Unternehmen können noch weitere Rollen hinzukommen, z. B. Rechtsabteilung (für Haftungsfragen, Urheberrechte – Consulted bei unklaren Fällen), Kommunikationsabteilung (für interne Kommunikation des Projekts – Responsible für Awareness-Maßnahmen), oder ein formales KI-Gremium. Manche Firmen richten einen AI Ethics Officer oder KI-Koordinator ein, der bereichsübergreifend KI-Themen beobachtet – wenn vorhanden, wäre dieser natürlich eng in Copilot-Governance involviert.

Wichtig ist, die Rollen in einer RACI-Matrix transparent festzuhalten (siehe Tabelle unten). So weiß jeder, welche Rolle er spielt und wo Schnittstellen sind. Überschneidungen sollten vermieden werden – z. B. sollte klar sein, ob der CISO allein über eine Sicherheitsmaßnahme entscheidet oder ob der CIO absegnen muss. RACI hilft, Accountabilities und Consultations sauber zu trennen.

3.2 Verantwortlichkeiten, Eskalationspfade, Freigaben

Anhand der Rollen lassen sich die Verantwortlichkeiten im täglichen Ablauf definieren. Hier einige zentrale Verantwortungsbereiche und wie Eskalation/Freigabe organisiert sein sollten:

• Strategische Steuerung: Hier liegt die Verantwortung bei der Geschäftsleitung (CIO) und ggf. einem KI-Steuerungsgremium. Sie setzen Ziele (welche Nutzen sollen erreicht werden, welche Risiken sind tolerierbar) und treffen Grundsatzentscheidungen (z. B. „Copilot wird nach erfolgreichem Pilot flächendeckend eingeführt“ oder „Externe Plugins sind zunächst grundsätzlich deaktiviert“). Eskalation: Wenn es Konflikte zwischen Fachbereichsinteressen und Sicherheitsbedenken gibt, oder bei gravierenden Incidents, landet das Thema hier. Beispiel: Der Datenschutzbeauftragte möchte Copilot-Funktion X abschalten, der Vertrieb will sie unbedingt – dies würde ans obere Management eskaliert, das unter Abwägung entscheidet. Freigaben auf strategischer Ebene: etwa die endgültige Go/No-Go-Entscheidung nach der Pilotphase, Freigabe von Budget, Genehmigung einer Betriebsvereinbarung.
• Operative Verantwortung für Sicherheit & Compliance: Liegt beim CISO und DSB (Datenschutz). Sie sind dafür verantwortlich, dass alle notwendigen Kontrollen implementiert und wirksam sind. Sie legen auch Eskalationskriterien fest: z. B. „Ein sicherheitsrelevanter Copilot-Vorfall (Datenabfluss > 100 Datensätze) muss binnen 24h an CISO gemeldet werden, der entscheidet über weitere Schritte und Information der Geschäftsführung“. Eskalationspfade: Bei sicherheitsrelevanten Alerts (z. B. DLP schlägt mehrfach an wegen Copilot) geht es vom Admin an den CISO. Bei Datenschutzverstößen (z. B. ein Mitarbeiter meldet, er habe sensible Gesundheitsdaten per Copilot erhalten, die er nicht sehen dürfte) geht es sofort an den DSB und CISO. Zusammen beraten sie, ob z. B. die Geschäftsführung, der Betriebsrat oder betroffene Personen informiert werden müssen. Freigaben: Sicherheits- und Datenschutzkonzepte werden vom CISO/DSB entworfen, müssen aber oft vom CIO bzw. vom Gremium genehmigt werden (um Ressourcen zu binden, oder falls sie Einfluss auf Nutzer haben – z. B. „Mitarbeiter dürfen Funktion Y nicht nutzen“, das braucht Rückhalt). Der DSB hat qua Gesetz eine Art Vetorecht in seinem Bereich – wenn er Bedenken hat, muss der Verantwortliche (hier der CIO) diese sehr ernst nehmen oder schriftlich überstimmen, was unüblich ist. Also Freigabe i. d. R. in Übereinstimmung mit DSB.
• Administrativer Betrieb und Support: Der M365-Admin und sein Team tragen Verantwortung dafür, dass Copilot technisch läuft und die Einstellungen den Policies entsprechen. Deren Verantwortlichkeiten: Lizenzen managen, Einstellungen in Admin-Center korrekt setzen, System-Monitoring, technische Problembehebung. Außerdem 1st/2nd-Level-Support zusammen mit Helpdesk: Nutzeranfragen oder Störungen aufnehmen und lösen/eskalieren. Eskalationspfad hier: Tritt ein technisches Problem auf, das Admin nicht direkt lösen kann (z. B. Bug in Copilot), eskaliert er an Microsoft Support und informiert den Copilot-Produktverantwortlichen, der ggf. die Nutzer informiert. Tritt ein Vorfall auf, der nach Sicherheitsvorfall aussieht, eskaliert Admin an CISO (wie oben). Freigaben: Der Admin selbst sollte definierte Befugnisse haben, was er allein entscheiden kann (z. B. eine fehlerhafte Einstellung sofort korrigieren). Bei Abweichungen von Policies (z. B. Fachbereich will testweise doch ein Plugin nutzen, das aber eigentlich verboten ist) darf der Admin das nicht im Alleingang freischalten; hier muss ein Freigabeprozess greifen – typischerweise via Copilot-Verantwortlicher plus Zustimmung von CISO/DSB je nach Thema.
• Copilot-Produktverantwortlicher / Governance-Koordinator: Diese Person ist verantwortlich für die Koordination aller Aktivitäten (das Tagesgeschäft der Governance). Sie erstellt etwa Reports, plant Meetings, dokumentiert Policy-Änderungen. Sie fungiert als erster Eskalationspunkt für alle möglichen Probleme: Wenn ein Fachbereich unzufrieden ist („Copilot halluziniert ständig in Bereich X“), geht das an diesen Verantwortlichen, der dann Analyse veranlasst und ggf. Arbeitsgruppen bildet (vielleicht mit Datenexperten, um den Index zu verbessern). Wenn der Admin Bedenken hat, die Nutzung nehme überhand und koste zu viel, meldet er das an den Copilot-Owner. Dieser filtert und eskaliert weiter ans Board/CIO nur wenn nötig. Freigaben: Der Copilot-Produktverantwortliche selbst wird oft die kleineren operativen Freigaben erteilen können, z. B. „diesen prompt guideline Text veröffentlichen“ oder „diese Schulungsunterlage freigeben“. Größere Änderungen (Policy-Änderung, neue Features aktivieren) wird er dem Governance Board zur Freigabe vorlegen.
• Fachbereiche & Betriebsrat: Die Fachbereiche sind verantwortlich, Copilot in ihren Prozessen sinnvoll zu integrieren. Falls ein Fachbereich einen abweichenden Bedarf hat (z. B. Finance möchte, dass bestimmte Daten explizit nicht von Copilot erfasst werden, oder Vertrieb will ein zusätzliches Plugin), dann sind sie verantwortlich, dies über die definierten Kanäle einzubringen. Das Governance-Modell sollte klare Antrags-/Änderungsprozesse haben: Etwa „Fachbereich stellt Antrag A zur Änderung/Erweiterung der Copilot-Nutzung – dieser wird vom Copilot-Verantwortlichen entgegengenommen, im Board diskutiert und entschieden“. Der Betriebsrat hat die Verantwortung, Mitarbeiterinteressen zu vertreten; praktisch heißt das, er beobachtet den Betrieb. Falls Mitarbeiterbeschwerden kommen („Ich fühle mich von Copilot bewertet“ o. Ä.), bringt der Betriebsrat das ins Governance-Gremium. Eskalation: Idealerweise werden Probleme im Board gelöst; eskaliert wird vom Betriebsrat an den Vorstand nur, wenn die Verständigung scheitert (was man durch Einbindung von Anfang an vermeidet).

Zusammengefasst sollen Eskalationspfade sicherstellen, dass Probleme auf der richtigen Ebene gelöst werden: Technische Störungen technisch, fachliche Unzufriedenheiten fachlich etc., und kritische Vorfälle schnell an die Spitze gelangen. Wichtig: Alle Beteiligten müssen wissen, wann sie was melden und an wen. Das sollte in Schulungen und eventuell in einer Kommunikationsmatrix festgehalten sein (z. B. „Bei Sicherheitsvorfall: sofort CISO informieren per Telefon + Incident Tool Eintrag“).

Freigaben in Copilot-Governance sind meist in Form von Policies und Changes: – Policiies (Richtlinien) selbst werden initial vom Governance Board/CIO freigegeben. – Nach der Einführung wird jede Änderung an Policies z. B. halbjährlich im Board diskutiert und durch Beschluss freigegeben. – Plugins-Freigabe: eigener Prozess (siehe 10.3) mit mehreren Prüfschritten, finaler Freigabe evtl. durch CISO + Fachbereichsleitung gemeinsam. – Nutzerfreigabe: Wer kriegt Zugang? In Pilotphase auf definierte Gruppe beschränkt – Freigaben durch Projektleitung; im Rollout dann gem. Rolloutplan (Fachbereiche stimmen zu, dann Admin schaltet). – Content-Freigaben: Wenn z. B. ein neuer interner Wissensdatensatz in Graph aufgenommen wird, muss Data Owner freigeben.

Diese Feinheiten können sehr unternehmensspezifisch sein. Daher hier der Rat: Definieren Sie diese Prozesse schriftlich. Ein kleines Governance-Handbuch oder zumindest ein Abschnitt in der Policy sollte beschreiben, „Wer entscheidet was?“ – das sorgt für Klarheit und beschleunigt Abläufe.

3.3 Schulung & Befähigung (Administratoren, Autoren, Endanwender)

Kein Governance-Modell funktioniert ohne die Befähigung der Beteiligten, ihre Rollen kompetent auszufüllen. Daher ist ein Schulungs- und Awareness-Konzept zentraler Bestandteil von Copilot-Governance:

• Schulung der Administratoren: Das IT-Team (M365-Admins, Security Engineers) muss genau wissen, wie Copilot technisch funktioniert und administriert wird. Schulungsinhalte:
• Konfigurationsoptionen im Microsoft 365 Admin Center bez. Copilot (z. B. wo werden Agents erlaubt, wie funktioniert das Lizenzmanagement, welche neuen Logs gibt es).
• Nutzung von Microsoft Purview für Copilot: z. B. wie führt man eine Content Search durch, um Copilot-Chat-Inhalte zu finden? Wie setzt man Retention Policies für Copilot-Verlaufsdaten? Microsoft liefert hier Dokumentation, die Admins durcharbeiten sollten.
• Security-Tools: Admins sollten geschult werden, wie DLP-Regeln auf Copilot-Ausgaben greifen (ggf. in Kombination mit Teams-Chats), wie sie das SIEM einrichten, um Copilot-Aktivitäten zu überwachen, und wie Alarme auszuwerten sind.
• Troubleshooting: Wissen, welche Schritte zu tun sind, wenn Copilot nicht wie erwartet reagiert (z. B. Berechtigungsprobleme, Indexierungsfragen). Admins brauchen Einblick in Semantic Index etc. Es kann sinnvoll sein, sie auf offizielle Microsoft-Workshops oder -Trainings zu schicken, da Copilot neu und komplex ist.
• Prozesse: Admins müssen auch im Governance-Prozess geschult sein – z. B. was tun, wenn ein Fachbereich ein Plugin möchte (nicht direkt umsetzen, sondern erst an Governance weiterleiten). Also Schulung auch in Soft Skills und Prozessverständnis.
• Schulung für „Autoren“ bzw. Power User: Im Kontext Copilot könnte man mit „Autoren“ Personen meinen, die z. B. Prompt-Bibliotheken erstellen oder hochwertige Inhalte generieren. Das könnten Wissensmanager, Fachexperten oder Kommunikationsleute sein, die Copilot aktiv zur Erstellung von Texten, Berichten, Code o. ä. nutzen. Diese sollten intensiver geschult werden in:
• Prompt-Engineering: Wie formuliert man Eingaben, um gute Ergebnisse zu bekommen? (Struktur, Kontext liefern, klare Anweisungen). Praktische Übungen können helfen, ein Gefühl für die KI zu entwickeln.
• Do’s & Don’ts beim Inhalt: Was darf nicht rein (z. B. keine geschützten Infos), was sollte man stattdessen tun (z. B. auf vorhandene Dokumente referenzieren statt Text reinzukopieren).
• Überprüfung von Copilot-Ausgaben: Autoren sind oft die ersten, die KI-Entwürfe sehen, bevor sie publiziert werden. Sie müssen trainiert sein, diese kritisch zu prüfen: Fakten checken, Tonalität prüfen, Quellen bewerten. Hier kann man ein QA-Framework vermitteln (z. B. Checkliste: „Ist die Aussage durch eine Quelle gedeckt?“, „Passt das ins Wording?“).
• Rückmeldung geben: Power User sollen auch lernen, dem System Feedback zu geben bzw. Issues zu melden. Also Schulung dahin gehend: wenn die KI Mist baut, was mache ich? (z. B. Info an Governance-Team mit Beispiel).
• Rollenmodell verstehen: Autoren haben evtl. erweiterte Rechte, z. B. manche könnten Plugins testen dürfen – sie müssen die Verantwortung begreifen, die damit kommt.
• Schulung aller Endanwender: Jeder Mitarbeiter, der Copilot nutzt, braucht eine angemessene Unterweisung. Diese besteht aus:
• Awareness-Schulung vor Einführung: Hier wird allen klargemacht, was Copilot ist, was er kann und was nicht, und vor allem die Richtlinien. Das kann per E-Learning, Intranet-Videos oder Webinars erfolgen. Inhalte: Vorstellung Copilot, Chancen; dann klar die Regeln (aus Policies in verständlicher Sprache), inklusive Beispiele von erlaubten und nicht erlaubten Prompts. Auch Hinweise auf Datenschutz und Betriebsvereinbarung, falls vorhanden („Copilot darf nicht zur Mitarbeiterbewertung genutzt werden, wir protokollieren keine individuelle Performance“ etc.).
• Hands-on-Training: Nach Möglichkeit sollten Mitarbeiter Copilot ausprobieren können mit Anleitung. In Pilotphase kann man Workshops anbieten, wo man gemeinsam den Umgang übt, Fragen klärt. Für den Rollout kann es aufgezeichnete Demos oder interaktive Tutorials geben („Stellen Sie Copilot diese Frage, schauen Sie was passiert“).
• Kontinuierliche Weiterbildung: Copilot wird neue Features erhalten; Mitarbeiter vergessen teils, was sie gelernt haben. Also sollte es regelmäßig Auffrischung geben: z. B. quartalsweise ein Newsletter „Copilot-Tipp des Monats“, oder im Intranet eine FAQ/Community, wo sich Nutzer austauschen (moderiert von Governance-Team).
• Spezifische Trainings für bestimmte Rollen: Z. B. für Vertriebsteams könnte man separate Sessions machen, die auf deren Use Cases eingehen (E-Mail-Entwürfe, Angebotszusammenfassungen mit Copilot). Für Entwickler wiederum, falls Copilot Codehilfen gibt, entsprechend auf Code, etc.
• Schulung des Governance-Boards/Teams: Auch diejenigen, die Governance machen, müssen up-to-date bleiben. Das heißt Fortbildungen zu KI-Governance Best Practices besuchen, Austausch mit anderen Unternehmen, evtl. Beratung. Insbesondere, da sich Normen und Gesetze entwickeln, sollten CISO/DSB etc. sich z. B. im BSI, in Fachverbänden oder auf Konferenzen informieren. Dieses Wissen fließt dann wieder in interne Anpassungen ein.
• Betriebsrat einbeziehen: Oft macht es Sinn, zusammen mit dem Betriebsrat Schulungen zu gestalten, damit die Arbeitnehmervertretung informiert ist und Vertrauen hat. Evtl. schult der Betriebsrat seine Mitglieder extra, um auf Mitarbeitendenfragen antworten zu können.

Ziel all dieser Schulungen ist, jede Zielgruppe auf ihre Aufgaben vorzubereiten: Admins sichern, Endnutzer produktiv und regelkonform nutzen, Entscheider wissen worauf zu achten. Ein Sprichwort in der IT-Sicherheit lautet: „People are the weakest link.“ – Das gilt hier ebenso: Ohne aufgeklärte, befähigte Mitarbeitende nützen die besten Policies nichts. Deswegen investiert Copilot-Governance substanziell in Awareness & Training.

Natürlich sollte man die Schulungsmaßnahmen auch dokumentieren (wer hat wann was erhalten) – teils aus Compliance-Gründen (Nachweis, dass alle informiert wurden), teils um Lücken zu erkennen (wer noch nicht geschult wurde, bekommt kein Zugang). Und es ist sinnvoll, Erfolgskontrollen einzubauen: kurze Quiz, Feedbackbögen nach Schulungen, um zu sehen ob die Inhalte verstanden wurden.

Im Laufe der Zeit kann man eine Art Wissens-Community aufbauen, in der sich erfahrende Copilot-Nutzer austauschen und voneinander lernen (z. B. Yammer-Gruppe oder Teams-Kanal „Copilot Tricks“). Das Governance-Team sollte so etwas fördern, denn dadurch verstetigt sich die Befähigungskultur.

Zusammengefasst: Schulung & Befähigung sind keine einmaligen Events, sondern ein fortlaufender Prozess parallel zum technischen Betrieb. Copilot-Governance muss hierfür Ressourcen einplanen (Zeit, Personal, Budget) und Erfolge wie Defizite im Auge behalten. Die Qualität der Governance wird maßgeblich davon beeinflusst, wie gut alle ihre Rolle verstehen – dafür legt Schulung den Grundstein.

Tabelle: RACI-Matrix (Rollen und Verantwortlichkeiten)

Rolle	Verantwortung (Responsible)	Entscheidungen (Accountable)	Konsultation (Consulted)	Information (Informed)
Geschäftsführung / CIO	– Gesamtinitiative sponsorn<br>- Ressourcen bereitstellen<br>- Governance-Rahmen genehmigen	– Strategische Freigaben (Go-Live, Budget, Grundsatzpolicies)<br>- Finaler Entscheider bei Zielkonflikten	– Berät sich mit CISO, DSB, Fachbereichen vor Entscheidungen	– Erhält regelmäßige Berichte zu Nutzen & Risiken<br>- Wird bei schweren Vorfällen sofort informiert
CISO / IT-Security	– Implementierung von Sicherheitsmaßnahmen leiten<br>- Überwachung Sicherheitsmetriken<br>- Incident Response koordinieren	– Entscheidet über sicherheitsrelevante Maßnahmen (z. B. Notabschaltung Copilot bei Leak)<br>- Abnahme Security-Konzept	– Holt Input vom Admin-Team (Machbarkeit), vom DSB (Privacy)<br>- Konsultiert Fachbereiche bei Maßnahmen mit Auswirkung auf User (z. B. Blockieren von Funktionen)	– Informiert CIO über Sicherheitslage<br>- Meldet dem Governance-Team regelmäßig Status der Sicherheitskontrollen
Datenschutzbeauftragter	– Datenschutz-Folgenabschätzung durchführen<br>- Privacy Policy für Copilot erstellen<br>- Überwachung Einhaltung DSGVO (Logs, Löschkonzepte)	– Genehmigt Privacy-Konzept<br>- Kann bei Datenschutzverstößen Stop anordnen	– Konsultiert Fachbereiche zu Datenverarbeitung<br>- Abstimmung mit CISO bei technischen Schutzmaßnahmen	– Bericht an Geschäftsführung zu Datenschutz-Compliance<br>- Betriebsrat wird über datenschutzrelevante Regelungen informiert
Copilot-Produktverantwortlicher (Governance-Manager)	– Koordination aller Governance-Aktivitäten (Meetings, Reporting)<br>- Treibt Umsetzung von Maßnahmen (Zuteilung Aufgaben, Nachverfolgung)<br>- Kommuniziert zwischen allen Rollen	– Verantwortet Zielerreichung des Copilot-Projekts im Sinne von Nutzen vs. Risiken<br>- Gibt kleinere operative Änderungen frei (z. B. Schulungsmaterial) im Rahmen des Konzepts	– Sammelt Input von Fachbereichen, Admin, CISO, DSB für Entscheidungen<br>- Lässt sich bei Bedarf von Rechtsabteilung, HR beraten	– Informiert alle Stakeholder über Beschlüsse und Änderungen<br>- Meldet Status und Kennzahlen an CIO und Gremium regelmäßig
Microsoft 365-Administrator	– Technische Konfiguration des Tenants gemäß Vorgaben<br>- Lizenzverwaltung und Zuweisung<br>- Betrieb/Monitoring (Audit-Logs prüfen, Systemstatus beobachten)<br>- 1st/2nd Level Support für Nutzeranfragen	– Entscheidet in Notfällen über Sofortmaßnahmen (z. B. temporäres Deaktivieren einer Einstellung zur Schadenbegrenzung)<br>- Trifft Entscheidungen gemäß delegierten Befugnissen (im Rahmen von Policies)	– Fragt CISO/Produktverantw. bei abweichenden Situationen (z. B. unbekannter Fehler, ob extern Support einbeziehen)<br>- Konsultiert DSB vor Datenlösch-Aktionen	– Berichtet an CISO/Produktverantw. über Systemgesundheit und Vorfälle<br>- Informiert Fachbereiche über anstehende Wartungen/Änderungen
Fachbereichsleitung	– Umsetzung der Copilot-Richtlinien im Team (für Einhaltung sorgen)<br>- Identifikation von Use Cases und Meldung ans Governance-Team<br>- Fördert Schulung der Mitarbeiter in seinem Bereich	– Priorisiert Copilot-Einsatz im eigenen Bereich (wo genutzt, wo nicht)<br>- Gibt bereichsspezifische Guidelines frei (z. B. Sprachstil für KI-Texte im Marketing)	– Bringt Anforderungen/Vorschläge in Governance-Board ein<br>- Konsultiert sich mit Mitarbeitenden/Teamleads, was funktioniert oder stört	– Erhält Richtlinien und Updates vom Governance-Team<br>- Wird über incidents im eigenen Bereich informiert (z. B. Verstoß durch Mitarbeiter)
Betriebsrat	– Vertritt Mitarbeiterinteressen bzgl. Copilot (Datenschutz, Entlastung vs. Überwachung)<br>- Überwacht Einhaltung der Betriebsvereinbarung	– Genehmigt Betriebsvereinbarung und Änderungen daran<br>- Kann Einspruch erheben bei mitbestimmungspflichtigen Themen	– Wird vom Arbeitgeber bei Änderungen konsultiert<br>- Tauscht sich mit DSB zu Mitarbeiterdatenschutz aus	– Wird frühzeitig über Einführung und Ziele informiert<br>- Erhält regelmäßiges Reporting zu Auswirkungen auf Beschäftigte (z. B. Feedback, keine Leistungsüberwachung)
Endanwender/Mitarbeiter	– Regelkonforme Nutzung von Copilot im Arbeitsalltag<br>- Meldung von Problemen oder Verstößen (Eigenverantwortung)	– Trifft Entscheidung, Copilot-Vorschläge zu nutzen oder zu verwerfen (im Rahmen seiner Aufgabe verantwortlich für Output)	– Kann Governance-Team Feedback geben (Wünsche, Probleme)	– Wird geschult in Nutzung und Regeln<br>- Erhält Kommunikation bei Änderungen oder neuen Features

(Legende: Verantwortlichkeit = operative Zuständigkeit für Aufgabe/Ausführung; Entscheidungen = finale Entscheidungs- oder Genehmigungsrechte; Konsultation = einzubeziehen bei Entscheidungen; Information = erhält Infos/Berichte.)

4. Richtlinien & Leitplanken (Policies)

4.1 Policy-Rahmenwerk: Grundsätze, Ziele, Geltungsbereich

Ein zentrales Element der Copilot-Governance ist ein Policy-Rahmenwerk, das in schriftlichen Richtlinien festhält, wie Copilot genutzt werden darf und soll. Dieses Rahmenwerk bildet sozusagen den „Vertrag“ zwischen der Organisation und den Nutzern bezüglich des KI-Einsatzes. Wichtige Bestandteile sind:

• Grundsätze (Principles): Die übergeordneten Leitlinien, an denen sich alle Detailregeln orientieren. Beispiele für solche Grundsätze könnten sein:
• „Sicherheit und Datenschutz haben oberste Priorität bei der Nutzung von Copilot.“ – Das betont, dass kein Nutzen über den Schutz von vertraulichen Informationen geht.
• „Copilot ist ein Assistenzwerkzeug, Verantwortung für Entscheidungen bleibt beim Menschen.“ – Damit ist klargestellt, dass die KI nicht autonom handeln darf oder Haftung verschiebt.
• „Transparenz und Nachvollziehbarkeit: Ergebnisse aus Copilot-Einsätzen müssen für berechtigte Personen nachvollziehbar dokumentiert werden.“ – Z. B. Quellangaben und Logging.
• „Qualität vor Geschwindigkeit: Copilot-Vorschläge sind zu prüfen, bevor sie in finalen Outputs verwendet werden.“ – So wird Halluzinationsrisiko adressiert.
• „Need-to-Know und Least Privilege gelten auch für KI.“ – Copilot darf keine Infos offenlegen, die nicht sowieso dem Nutzer zugänglich wären.

Solche Grundsätze kann man am Anfang der Policy nennen, um den Rahmen abzustecken. Sie sind eher abstrakt, sorgen aber dafür, dass im Zweifel die Interpretation einer Regel im Sinne des Grundsatzes erfolgen kann.

• Ziele der Copilot-Nutzung: Es ist hilfreich, in der Policy auch den positiven Zweck festzuhalten, damit klar wird, wozu Copilot gefördert wird. Zum Beispiel:
• „Diese Richtlinie soll eine sichere und effektive Nutzung von Microsoft 365 Copilot ermöglichen, um die Produktivität und das Wissensmanagement im Unternehmen zu verbessern.“
• „Copilot wird eingeführt, um Mitarbeitende von Routineaufgaben zu entlasten und qualitativ hochwertige Arbeitsergebnisse schneller zu erzielen, ohne die Compliance des Unternehmens zu gefährden.“

Solche Aussagen motivieren die Einhaltung („wir machen das, um gemeinsam besser zu werden“) und können auch extern zeigen, dass das Unternehmen einen Plan hat.

• Geltungsbereich (Scope): Hier wird festgelegt, für wen und was die Richtlinie gilt. Typisch:
• Personeller Geltungsbereich: z. B. „Diese Policy gilt für alle Beschäftigten, Berater und Drittnutzer, die Zugriff auf Microsoft 365 Copilot im [Unternehmensname]-Tenant haben.“ – Das schließt auch Externe ein, falls Gäste oder Partner Copilot nutzen können, sowie alle Hierarchieebenen (vom Vorstand bis Praktikant).
• Sachlicher Geltungsbereich: Was ist mit Copilot genau gemeint? z. B. „…für die Verwendung von Microsoft 365 Copilot und vergleichbarer generativer KI-Funktionen innerhalb der Microsoft 365 Umgebung.“. Damit wären künftige Copilot-ähnliche Tools (z. B. in Power Platform) mit abgedeckt.
• Räumlicher/zeitlicher Geltungsbereich: Wenn relevant, könnte man erwähnen „gilt an allen Standorten“ (wichtig bei internationalen Firmen, falls es länderspezifische Abweichungen gibt, müsste man das ausklammern oder separat behandeln). Zeitlich: ab wann gültig (und ersetzt evtl. irgendwelche bisherigen Ad-hoc-Regeln).
• Verhältnis zu anderen Richtlinien: Oft sinnvoll zu erwähnen: „Diese Copilot-Policy ergänzt die bestehenden IT-Nutzungsrichtlinien und Sicherheitsrichtlinien. Bei Widersprüchen gilt der strengere Maßstab.“ – So wissen alle, dass das kein losgelöstes Dokument ist, sondern Teil des Gesamt-Regelwerks. Außerdem kann man referenzieren: „Themen wie Klassifizierung und Freigaben sind in der Informationsschutz-Richtlinie geregelt; diese Copilot-Policy lehnt sich daran an.“
• Verantwortlichkeiten in der Policy: Wer macht was? Man kann in der Richtlinie kurz verankern: „Die Umsetzung dieser Richtlinie wird vom Copilot-Governance-Team überwacht. Mitarbeiter haben Zuwiderhandlungen dem/der [CISO/DPO] zu melden. Die IT-Abteilung ist befugt, Log-Daten zu prüfen…“ – also dass klar ist, wie das durchgesetzt wird.

Der Ton einer solchen Policy sollte klar und prüfbar sein. Sie richtet sich ja an alle Mitarbeitenden (und ggf. externe Auditoren), daher in verständlicher Sprache, keine Schlupflöcher lassen.

Das Policy-Rahmenwerk bildet sozusagen die Master-Policy, darunter können dann spezifischere Guidelines existieren (z. B. eine Prompt-Guideline oder eine technische Hardening-Anweisung für Admins). Man kann es auch in einem Dokument kombinieren – je nach Umfang.

Im Folgenden werden einzelne inhaltliche Blöcke (Zugriff, Datenklassifikation etc.) beschrieben, die in so einer Policy oder in Anlagen dazu geregelt sein sollten.

Policy-Beispieltext (Codeblock) – Grundsätze & Geltungsbereich

Unternehmensrichtlinie „Einsatz von Microsoft 365 Copilot“ (Auszug)

1. **Grundsatz der sicheren und verantwortungsvollen KI-Nutzung** 
   Microsoft 365 Copilot wird ausschließlich zur produktiven Unterstützung dienstlicher Aufgaben verwendet. Alle geltenden Sicherheits-, Datenschutz- und Verhaltensrichtlinien des Unternehmens finden uneingeschränkt Anwendung. Der Mensch bleibt jederzeit verantwortlich für Entscheidungen; Copilot dient als Assistenzsystem. Vertrauliche Informationen dürfen durch Copilot weder unbefugt erlangt noch weitergegeben werden.

2. **Zweck und Ziele** 
   Diese Richtlinie soll die effektive Nutzung von Microsoft 365 Copilot fördern und gleichzeitig Risiken (z. B. Datenabfluss, Fehlinformationen) minimieren. Copilot wird eingesetzt, um Arbeitsabläufe zu beschleunigen, die Qualität von Arbeitsergebnissen zu unterstützen und Wissen im Unternehmen besser nutzbar zu machen. Dies geschieht unter strikter Einhaltung aller Compliance-Vorgaben.

3. **Geltungsbereich** 
   Diese Regelungen gelten für alle Mitarbeitenden, Leiharbeitnehmenden, Praktikanten sowie externe Partner mit Zugang zum Copilot-Dienst im Tenant der [Unternehmensname] GmbH. Sie erfassen die Nutzung von Microsoft 365 Copilot in allen unterstützten Anwendungen (z. B. Word, Excel, PowerPoint, Outlook, Teams etc.) sowie künftige vergleichbare KI-Assistenten innerhalb der Microsoft 365-Umgebung. Abweichungen für einzelne Länder oder Bereiche bedürfen der schriftlichen Genehmigung der Geschäftsführung und des Datenschutzbeauftragten.

4. **Verhältnis zu bestehenden Richtlinien** 
   Diese Copilot-Richtlinie ergänzt die IT-Benutzerrichtlinie und die Informationssicherheitsrichtlinie. Ihre Bestimmungen sind im Zweifel so auszulegen, dass die strengsten Anforderungen gelten. Insbesondere gelten die Regeln zur Klassifizierung von Informationen, zur zulässigen Internetnutzung und zum Umgang mit externen Kommunikationsdiensten analog auch für die Nutzung von Copilot.

5. **Verantwortlichkeiten** 
   Die Einhaltung dieser Richtlinie wird durch das Copilot-Governance-Team überwacht (geleitet durch [Rolle einsetzen, z. B. CISO oder Copilot-Produktmanager]). Mitarbeitende sind verpflichtet, Verstöße oder sicherheitsrelevante Vorfälle im Zusammenhang mit Copilot unverzüglich an IT-Sicherheit (security@[firma].com) zu melden. Die IT-Abteilung protokolliert Copilot-Interaktionen gemäß gesetzlicher Vorgaben und wertet diese bei Bedarf zur Untersuchung von Sicherheits- oder Compliance-Vorfällen aus. Zuwiderhandlungen gegen diese Richtlinie können arbeitsrechtliche Konsequenzen nach sich ziehen.

*(Weitere Abschnitte folgen zu Zugriffskontrolle, Datenschutzregeln, Nutzungsrichtlinien etc.)*

Erläuterung: Diese Auszüge zeigen, wie in einer Richtlinie Grundsätze, Zweck, Geltungsbereich und Verantwortlichkeiten formuliert sein können. Sie dienen als Rahmen, bevor in den folgenden Abschnitten spezifischere Regeln festgelegt werden.

4.2 Zugriffs- und Berechtigungsmodell: Least Privilege, Need-to-Know, Segmentierung

Ein zentrales Governance-Prinzip ist das Berechtigungsmodell: Wer darf Copilot nutzen und auf welche Daten kann Copilot zugreifen? Hier greifen die klassischen Sicherheitsprinzipien Least Privilege (geringstmögliche Rechte) und Need-to-Know (Zugriff nur, wenn nötig) – diese müssen im KI-Kontext präzisiert werden:

• Copilot-Zugang vergeben (Least Privilege für Nutzer): Nicht jeder Mitarbeiter muss von Tag 1 Copilot haben. Governance sollte regeln, nach welchen Kriterien Zugang gewährt wird. Beispielsweise könnte man festlegen:
• In der Pilotphase nur bestimmte Rollen/Abteilungen (z. B. IT, einige Fachanwender) bekommen Lizenzen, alle anderen nicht.
• Später rollt man in Wellen aus, aber vielleicht schließt man bewusst einige Gruppen aus, z. B. Mitarbeiter, die hauptsächlich mit extrem sensiblen Daten arbeiten und wo man erst klären will (etwa Personalabteilung, Rechtsabteilung) – zumindest bis zusätzliche Sicherheiten etabliert sind.
• Oder man knüpft den Zugang an eine verpflichtende Schulung: „Only trained users are enabled for Copilot.“ – also erst nach eLearning und Test wird die Lizenz aktiviert.

Dies alles sind „Least Privilege“-Ansätze auf Nutzerseite. Die Policy kann z. B. sagen: „Copilot-Zugriffe werden nur für die Mitarbeiter freigeschaltet, die ihn für ihre Aufgabenerfüllung benötigen und die an der Schulung teilgenommen haben.“ Und dass regelmäßig überprüft wird, wer Copilot-Zugang hat (Entzug bei Jobwechsel, Austritt etc.). Technisch ist das umsetzbar: Lizenzen werden zentral zugewiesen und können auch entzogen werden.

• Datenzugriff beschränken (Need-to-Know auf Datenebene): Standardmäßig respektiert Copilot ja die bestehenden Berechtigungen auf Dateien/Chats etc. Aber Governance kann zusätzliche Segmentierungen vorsehen:
• Sensible Bereiche isolieren: Beispielsweise könnte man für streng geheime Projekte separate SharePoint-Sites einrichten, die vom globalen Search Index ausgeschlossen sind (SharePoint hat die Option „nicht durchsuchbar machen“ oder via Sensitivity Label mit „Privat“). Dann würde Copilot diese Inhalte nicht als Teil des Groundings heranziehen. Dies sollte man definieren: „Hochvertrauliche Informationen (Klasse A) dürfen nur in dafür gekennzeichneten Bereichen gespeichert werden, die von Copilot/Graph-Suche ausgenommen sind.“
• Mandantentrennung oder -beschränkung: Manche Unternehmen haben z. B. separate Tenants für unterschiedliche Segmente oder Partner. Governance sollte klären, ob Copilot nur im Haupttenant läuft oder auch in Subtenants. In cross-tenant Situationen (z. B. Teams Shared Channels, externe Gäste) gilt Need-to-know streng: Ein Gast hat nur sehr limitierte Permissions, also wird Copilot ihm auch wenig zeigen. Man könnte vorsorglich definieren: „Externe Benutzer haben keinen Copilot-Zugriff, außer es ist explizit genehmigt.“ (Wenn man externen Partnern z. B. eine Copilot-Lizenz geben wollte, was selten ist).
• Kein privilegierter Zugriff für Copilot: d.h. es gibt keine speziellen „Superrechte“ für Copilot. Das KI-System selber hat nur Rechte im Namen des Benutzers. (Microsoft hat das so implementiert, aber man kann es bekräftigen). Also soll es keine Service-Accounts geben, die alles lesen dürfen. Wenn mal Indizierung via Graph Connector vom KI-Modell genutzt wird, muss das datenschutzkonform sein (dort eher Service-Account, aber dann nur für definierte Data).
• Segmentierung nach Datenklassifizierung: Man kann die Berechtigungen feiner staffeln basierend auf Klassifizierung (siehe nächster Abschnitt). Z. B. „Streng geheim“-Dokumente nur auf need-to-know Basis, ergo sehr wenige haben Zugriff, ergo Copilot wird es kaum je ausgeben. Falls das Unternehmen sehr offene Ablagen hat, sollte man das ggf. überdenken – Governance kann etwa vorgeben, Zugriffsberechtigungen zu überprüfen und enger zu fassen bevor Copilot aktiviert wird. (Weil Copilot gnadenlos jedes Zugriffsloch auffindet und ausnutzt – was man sonst bei „Security by Obscurity“ evtl. übersehen hatte.)
• Berechtigungsverwaltung und -review: Die Policy sollte festhalten, dass regelmäßige Reviews stattfinden: z. B. quartalsweise sollen Manager prüfen, wer in ihrem Team Copilot-Zugriff hat (Lizenz) und ob das noch notwendig ist. Und analog, Zugriffsrechte auf Daten: z. B. ein Abteilungs-Laufwerk war bisher offen für alle, vllt. soll es jetzt segmentiert werden, weil Copilot sonst bereichsfremde Infos ziehen könnte. Also vllt. einmalige Bereinigungsaktion und dann zyklisch Re-Zertifizierung der Rechte.
• Technische Admin-Rechte: Zusätzlich: Wer darf Copilot administrieren? Der M365-Admin natürlich, aber sollte jeder Global Admin das tun dürfen oder nur ein dedizierter? Vielleicht legt man fest, dass nur benannte Personen Copilot-Einstellungen ändern dürfen. Das ist intern zu regeln (ggf. per RBAC: ein eigenes Admin-Rollenkonzept).

Zusammengefasst: Zugriff nur, wo nötig. Copilot deckt ungenutzte Berechtigungen auf – daher Governance-Fokus: Berechtigungen generell entrümpeln. Das ist ein Good Practice, das Copilot quasi erzwingt.

Segmentierung meint auch: Bei großen Organisationen eventuell stufenweise Freigaben – z. B. „Copilot darf Inhalte aus Abteilung A nicht an Abteilung B liefern, auch wenn in M365 Suche möglicherweise cross-search ginge“. Derzeit geht Copilot streng nach M365 ACLs, aber man könnte als Governance definieren: „Keine bereichsübergreifenden Suchen initial“ und falls doch, dies nur nach Freigabe. (Allerdings technisch kann man schwer einschränken, außer man hat separate Info-Barrieren in M365, wie man sie z. B. für Insider Trading Prävention einsetzt – das könnte man notfalls tun, Info Barriers verhindern Suchen/Kommunikation zwischen definierten Gruppen.)

Policy-Beispieltext – Zugriff & Berechtigungen

6. **Zugriffsberechtigung und Nutzerkreis** 
   Nur berechtigte User erhalten Zugriff auf Microsoft 365 Copilot. Berechtigungen werden nach dem Prinzip „Least Privilege“ vergeben:
   – Copilot-Lizenzen werden zentral durch die IT-Abteilung zugewiesen. In der Einführungsphase erhalten ausschließlich die von der Geschäftsleitung genehmigten Pilotanwender eine Lizenz.
   – Ein unternehmensweiter Rollout erfolgt stufenweise. Vor Freischaltung müssen Nutzer die verpflichtende Copilot-Schulung abgeschlossen haben. Die jeweiligen Vorgesetzten bestätigen den Nutzungsbedarf („Need-to-Use“) gegenüber dem Copilot-Governance-Team.
   – Nicht mehr benötigte Zugriffe sind umgehend zu entziehen (z. B. beim Abteilungswechsel oder Austritt eines Mitarbeiters). Die Führungskräfte sind dafür verantwortlich, dies dem IT-Support zu melden. Vierteljährlich erfolgt ein Lizenz-Review durch das Governance-Team; ungenutzte oder unberechtigte Lizenzen werden entzogen.

7. **Datenzugriff und Berechtigungskontrolle** 
   Copilot darf nur auf Inhalte zugreifen, für die der jeweilige Benutzer mindestens Leseberechtigung besitzt („Need-to-Know“-Prinzip):
   – Vertrauliche Bereiche: Datenablagen mit der Klassifizierung „Streng Vertraulich“ oder höher sind standardmäßig vom Microsoft Graph Search Index auszunehmen. Die IT stellt sicher, dass solche Bereiche (z. B. spezielle SharePoint-Sites) mit Suchausschluss oder geeigneten Sensitivity Labels konfiguriert sind, sodass Copilot diese Inhalte nicht verarbeitet.
   – Teamübergreifende Suche: Copilot-Abfragen liefern keine bereichsfremden Informationen. Informationsbarrieren und Berechtigungsgrenzen in Microsoft 365 (z. B. separate Mandanten oder Info Barriers zwischen Abteilungen) bleiben bestehen. Eine bereichsübergreifende Datenaggregation durch Copilot ist unzulässig, außer sie wurde durch alle betroffenen Datenowner genehmigt.
   – Gast- und Partnerzugriff: Externe Gastnutzer haben keinen Zugriff auf Copilot, es sei denn, die Geschäftsführung erteilt für einen spezifischen Anwendungsfall eine Ausnahmegenehmigung. Falls externen Nutzern Copilot-Funktionen bereitgestellt werden, sind deren Anfragen und Ergebnisse besonders zu überwachen und zu protokollieren.

8. **Regelmäßige Rechteüberprüfung** 
   Alle Zugriffsrechte im Zusammenhang mit Copilot unterliegen einer regelmäßigen Überprüfung:
   – **Benutzer-Lizenzen:** Das Copilot-Governance-Team prüft halbjährlich die Liste der aktiven Copilot-Nutzer und holt von den jeweiligen Bereichsleitungen eine Bestätigung ein, dass der Nutzungsbedarf fortbesteht. Nicht bestätigte oder in den letzten 60 Tagen inaktive Zugänge werden entzogen.
   – **Datenberechtigungen:** Die Datenverantwortlichen (Owner von SharePoint-Sites, Teams, etc.) stellen sicher, dass Berechtigungen aktuell sind. Insbesondere vor der Aktivierung von Copilot in einem Bereich ist eine Überprüfung auf überzählige Leserechte durchzuführen. Der Grundsatz lautet: **So wenig Personen wie möglich erhalten Zugriff auf sensible Inhalte.** Copilot macht keine Ausnahmen von Berechtigungen – falls Unbefugte etwas sehen könnten, muss die Berechtigung im Quellsystem entzogen werden.
   – **Administrativer Zugriff:** Nur autorisierte Administratoren (namentlich benannt im Berechtigungskonzept) dürfen Einstellungen an Copilot-Konfigurationen vornehmen. Administrative Aktivitäten werden geloggt und vom CISO-Team kontrolliert.

*(Die Policy regelt in weiteren Abschnitten Klassifizierung, Datenschutz, Nutzungsregeln etc.)*

Dieser Auszug aus der Policy zeigt klare Ansagen: Wer Copilot nutzen darf, auf welche Daten Copilot zugreifen darf und wie Berechtigungen verwaltet werden. Durch Begriffe wie „Need-to-know“ und konkrete Prozesse (Lizenz-Review) wird die Einhaltung prüfbar gestaltet.

4.3 Datenklassifikation & Etikettierung (Sensitivity Labels), Freigaberegeln

Datenklassifikation und Labeling sind entscheidende Instrumente, um Copilot-Governance durchzusetzen. Sie schaffen die Grundlage dafür, dass Copilot-Inhalte korrekt behandelt (oder ggf. gar nicht genutzt) werden. Wichtige Aspekte:

• Klassifikationsschema verwenden: Falls das Unternehmen bereits ein Klassifikationsschema (z. B. Öffentlich, Intern, Vertraulich, Streng Vertraulich) hat, muss Copilot-Governance sich darauf aufbauen. Jeder Inhalt, den Copilot verarbeitet, sollte idealerweise klassifiziert sein. In der Praxis ist das nicht immer flächendeckend vorhanden; Governance kann hier als Katalysator dienen: z. B. „Vor Aktivierung von Copilot ist eine Mindestquote von X% klassifizierter Dokumente anzustreben.“ Oder „Alle neu erstellten Dokumente müssen klassifiziert werden, was Copilot-Funktionalitäten wie automatisches Labeln unterstützen kann.“
• Sensitivity Labels & Automatisierung: Microsoft Purview Information Protection erlaubt es, Sensitivity Labels zu definieren, die bestimmten Schutz mitbringen (Verschlüsselung, Wasserzeichen, Berechtigungsbeschränkung). Governance sollte definieren, welche Labels vorhanden sein müssen:
• Beispielsweise: Label „Öffentlich“, „Intern“, „Vertraulich“, „Streng Vertraulich“ jeweils mit bestimmten Policies.
• Wichtig im KI-Kontext: Wenn ein Dokument ein Label mit Verschlüsselung hat und jemand ohne Schlüssel Copilot nutzt, kann Copilot diese Inhalte nicht auslesen. Das ist gut, verhindert aber auch legitime Use Cases (z. B. ob Copilot mit IRM-verschlüsselten Mails funktioniert?). Der Admin kann bei Purview festlegen, ob „Co-Authoring für verschlüsselte Dateien“ erlaubt ist, etc. Copilot kann grundsätzlich verschlüsselte (AIP) Daten nur sehen, wenn der Benutzer der Abfrage die Rechte hat und der Service (Agent) es darf. Microsoft sagt: Copilot honors usage rights. Also, wenn ein Label sagt „keine programmatic access“, würde Copilot nix daraus zitieren. Governance muss also definieren, welche Labels programmatischen Zugang erlauben und welche nicht.
• Evtl. eine Idee: Ein spezielles Label „AI Exclude“ – d.h. Daten, die nie in KI-Ergebnissen auftauchen sollen. Z. B. streng geheime Dinge könnte man mit einem Label versehen, das in MS Search Searchable = false setzt (wenn so konfigurierbar). Securiti-Firmen werben damit, solche Labeling-Lösungen zu haben. Das Unternehmen sollte prüfen, ob es in Purview so ein Label definieren kann und ob Copilot das respektiert (ggf. in der Praxis über Search Index).
• Freigaberegeln für Daten & externe Weitergabe: Die Policy sollte klar regeln, was Copilot in Antworten tun darf mit Bezug auf klassifizierte Daten:
• Z. B.: „Inhalte mit Klassifizierung ‚Vertraulich‘ oder höher dürfen von Copilot nur in Zusammenfassung wiedergegeben werden, direkte Zitate sind auf max. 100 Zeichen zu begrenzen.“ – falls man befürchtet, dass zu viel preisgegeben wird. (Microsoft hat default wohl keine solche Begrenzung, aber intern könnte man das fordern als Guidance an Nutzer, Copilot zitiert ja oft stückweise.)
• „Copilot-Antworten, die auf ‚Streng Vertraulich‘ basieren, dürfen nicht ohne Zustimmung des Daten-Eigentümers weiterverteilt werden.“ – Also, wenn ein Mitarbeiter sich streng vertrauliches Material zusammenfassen lässt, darf er die Zusammenfassung nicht mal eben ans gesamte Team schicken, ohne Freigabe. Hier braucht es Bewusstsein und ggf. DLP-Kontrollen.
• „Kein als ‚Intern‘ oder höher klassifiziertes Detail darf über Copilot an externe Personen gelangen.“ – Das ist im Prinzip Standard (man teilt interne Infos nicht extern ohne Freigabe). Copilot generiert aber evtl. neuen Text aus internem Wissen; auch der kann sensibel sein. Evtl. sollte man definieren: beovr man KI-generierten Text nach außen sendet (Kunde), muss geprüft werden, ob darin interne Infos stecken und diese zulässig sind.
• Freigabeprozess für neue Datenquellen: Wenn etwa ein neuer SharePoint-Bereich in Copilot einbezogen werden soll (z. B. man will ab jetzt das Intranet oder ein externes System via Graph Connector einbinden), muss das Data Owner genehmigen. Der Data Owner wiederum sollte sicherstellen, dass die Daten darin richtig klassifiziert und frei von Inhalten sind, die nicht in KI-Antworten auftauchen dürfen. Governance kann definieren: „Jede Datenquelle, die Copilot zugänglich gemacht wird, muss einen verantwortlichen Owner haben, der die Inhalte vorsortiert und klassifiziert. Die Freischaltung erfolgt erst nach schriftlicher Freigabe durch diesen Owner und Prüfung durch das Governance-Team.“
• Auto-Labeling und KI-Unterstützung: Microsoft Purview hat auto-labeling-Funktionen (z. B. 10k Items pro Tag mit Label versehen nach Regeln). Securiti-Artikel sagte, nativ begrenzt das auf x pro Tag. Governance kann aber definieren, dass man Tools einsetzt oder Admin investiert, um die wichtigsten unlabelled Daten zu klassifizieren. Ohne Labels ist Steuerung schwerer. Also als Maßnahme: „Ein Programm zur automatischen Klassifizierung unstrukturierter Daten wird implementiert; neu erkannte sensible Inhalte erhalten automatisch entsprechende Labels, die Copilot-Ausgaben ggf. einschränken.“
• Benutzer-Etikettierung in Prompts: Ein Aspekt: Soll der Benutzer beim Eingeben von Prompts kennzeichnen, wenn er vertrauliche Infos eingibt? Eher unrealistisch, man will ja gerade, dass er es nicht tut. Besser andersrum: Kennzeichnen, ob sein Prompt ein Official Business Record war? Das wird zu komplex. Wahrscheinlicher: Der User sieht in Copilot je nach App vllt. Sensitivity Markings (wenn der Quell-Doc ein Label hat). Z. B. Copilot Chat könnte beim Zitieren kenntlich machen „Aus [Datei] (Vertraulich)“. Evtl. nützlich.
• Datenlebenszyklus & Archivierung: Klassifizierung fließt auch in Aufbewahrung (Records) ein, siehe voriges. Man kann definieren: „KI-Interaktionen werden nach X Monaten automatisch auf ‚Intern‘ gesetzt und nach Y Monaten gelöscht, es sei denn, es greift eine Aufbewahrungspflicht.“ – Aber in 4.3 eher NICHT, das ist bei 4.4 oder 2.3.

Im Kern: Durch Labeling weiß Copilot (bzw. das System dahinter) grob, was kritisch ist. Microsoft hat Protected Content detection – laut Info blockt Copilot z. B. wenn er erkennt, das Material ist sensibel (k.A. wie intelligent das ist).

Freigaberegeln können auch folgende Situation betreffen: – Plugins, die Daten rausgeben: (gehört eher 4.5) – aber man kann hier sagen: „Kein ‚Vertraulich‘ oder höher darf via Plugin xyz geschickt werden, es sei denn, freigegeben.“ – Prompt-Bibliothek Freigaben: Das ist Szenario S6, aber evtl. definieren: Standardprompts, die auf interne Infos zugreifen, müssen vom Fachowner freigegeben sein.

Policy-Beispieltext – Klassifikation & Freigabe

9. **Datenklassifikation und Copilot-Nutzung** 
   Alle Informationen, die mit Hilfe von Copilot verarbeitet oder ausgegeben werden, unterliegen den bestehenden Klassifizierungsrichtlinien:
   – Nutzer dürfen streng vertrauliche Daten („Streng Vertraulich“ gemäß Informationsschutz-Policy) nicht als Prompt-Text in Copilot eingeben, außer dies ist zur Aufgabenerfüllung absolut notwendig und genehmigt. Copilot-Abfragen sollen generell so gestellt werden, dass keine unnötigen personenbezogenen oder geheimen Details im Prompt übermittelt werden.
   – Copilot ist angewiesen, die Klassifizierungslabels der zugrundeliegenden Dokumente zu respektieren. Inhalte mit hohem Schutzbedarf werden vom System nur in dem Umfang genutzt, wie es die Labels zulassen (z. B. kein Speichern oder Weiterleiten von IRM-verschlüsselten „Streng Vertraulich“-Dokumenten ohne Berechtigung des Nutzers).
   – Sollte Copilot dennoch aus hochklassifizierten Quellen Informationen generieren, sind diese **intern zu behandeln** und entsprechend zu kennzeichnen. Mitarbeiter, die solche KI-Ausgaben erhalten, dürfen sie nicht ohne Zustimmung des Daten-Eigentümers weiterverbreiten.

10. **Sensitivity Labels und automatische Kennzeichnung** 
   Für die Nutzung von Copilot gelten folgende Label-Vorgaben:
   – Alle neu erstellten Dokumente und Dateien sind vom Ersteller mit einem passenden Sensitivity Label zu versehen. Insbesondere Inhalte, die durch Copilot generiert und weiterverwendet werden (z. B. ein zusammenfassender Bericht), müssen vom verantwortlichen Mitarbeiter mindestens mit „Intern“ oder höher klassifiziert werden – eine Freigabe zur externen Verwendung ist explizit zu prüfen.
   – Die IT implementiert automatisierte Labeling-Prozesse: erkannte vertrauliche Inhalte (z. B. Personaldaten, Finanzzahlen) erhalten automatisch ein Vertraulichkeitslabel, sofern noch nicht vorhanden. Dies stellt sicher, dass Copilot diese Inhalte korrekt behandelt oder im Zweifel ausfiltert.
   – Ein spezielles Label „AI-Exclude“ wird für Daten eingeführt, die nicht durch Copilot verarbeitet werden sollen (z. B. aufgrund gesetzlicher Restriktionen oder Lizenzvereinbarungen). Dateien mit diesem Label werden vom Microsoft Search Index ausgeschlossen. Mitarbeiter sind angehalten, besonders schützenswerte Dokumente entsprechend zu markieren.

11. **Freigaberegeln für KI-Ausgaben** 
   – Sollte Copilot Inhalte aus vertraulichen Dokumenten wiedergeben (bspw. Zitate oder Zusammenfassungen), dürfen solche Antworten **nicht ohne weiteres extern weitergeleitet** werden. Jede Weitergabe von als „Vertraulich“ gekennzeichneten Informationen – auch wenn sie von Copilot formuliert wurden – bedarf der normalen Freigabe durch den Informations-Eigentümer.
   – Ergebnisse, die auf „Streng Vertraulich“ Daten basieren, sind ausschließlich für den internen Gebrauch auf Need-to-know-Basis bestimmt. Sie dürfen nur mit Personen geteilt werden, die Zugriff auf die Originaldaten haben. Die Verantwortung dafür liegt beim teilenden Mitarbeiter.
   – Wird Copilot genutzt, um Inhalte für externe Kommunikation zu erstellen (z. B. Kunden-E-Mails, Pressemitteilungen), so ist vor Versand eine Freigabe durch die jeweilige Fachabteilung (Vier-Augen-Prinzip) einzuholen. Dabei ist zu prüfen, dass keine internen vertraulichen Details unbeabsichtigt in den externen Text eingeflossen sind.

12. **Freigabe neuer Datenquellen** 
   Die Anbindung zusätzlicher Datenquellen an Copilot (z. B. über Graph Connectoren oder Integration weiterer SharePoint-Bibliotheken) erfolgt kontrolliert:
   – Der jeweilige Datenverantwortliche (Owner der Informationsquelle) muss schriftlich bestätigen, dass die darin enthaltenen Informationen klassifiziert und für eine Copilot-Nutzung geeignet sind. Sensible oder unstrukturierte Alt-Daten sind vorab zu bereinigen oder auszuschließen.
   – Das Copilot-Governance-Team prüft die beantragte Datenquelle hinsichtlich Risiken (z. B. hoher Anteil personenbezogener Daten, vertrauliche Inhalte ohne Label) und kann Auflagen erteilen (z. B. nachträgliche Klassifizierung durch ein Tool), bevor die Freischaltung erfolgt.
   – Die Geschäftsführung bzw. das AI-Governance-Board gibt die Anbindung final frei. Erst nach Freigabe wird die Datenquelle in den Microsoft Graph Index aufgenommen und damit für Copilot-Abfragen nutzbar.

*(Fortsetzung der Richtlinie mit weiteren Regeln, z. B. Datenschutz, Prompt-Richtlinien.)*

Dieser Policy-Ausschnitt stellt klar: Klassifizierungsregeln gelten vollumfänglich auch bei Copilot, und es gibt zusätzliche Vorkehrungen (AI-Exclude Label, Freigaben), um sicherzustellen, dass keine unangemessene Nutzung von sensiblen Daten erfolgt.

4.4 Datenschutz- und Compliance-Regeln: DLP, eDiscovery/Records, Protokollierung, Aufbewahrung

Copilot-Governance muss im Policy-Framework auch die klassischen Compliance-Kontrollen verankern. Dazu gehören Datenschutzregeln, aber auch Umgang mit regulatorischen Anforderungen wie Archivierung. Schlüsselelemente:

• Data Loss Prevention (DLP): Die Policy sollte festlegen, dass DLP-Regeln auch für KI-Interaktionen gelten und ggf. erweitert werden:
• Bsp.: „Unternehmensweite DLP-Policies (z. B. Erkennen von Kreditkartennummern, Personaldaten etc.) sind so zu konfigurieren, dass sie auch Inhalte erfassen, die von Copilot generiert oder übertragen werden.“ – Das bedeutet, falls Copilot z. B. in einer Teams-Nachricht etwas liefert, was sensitive Daten enthält und jemand versucht, es extern zu schicken, greift die DLP (sofern technisch möglich).
• Es kann eigene DLP-Regeln geben: z. B. „Wenn eine Copilot-Antwort Text enthält, der wie vertrauliche Informationen aussieht und an ‚Alle externen Empfänger‘ gesendet werden soll, blockiere die Mail.“ – Also man könnte Mails/Chats scannen. Das ist sehr technisch, aber in Policy kann generisch stehen: „DLP-Mechanismen überwachen die Nutzung von Copilot auf unerlaubten Datenabfluss. Unberechtigte Übermittlungen von Daten an externe Kanäle werden automatisiert unterbunden oder protokolliert.“
• Zudem: „Mitarbeiter dürfen Copilot nicht nutzen, um unter Umgehung von DLP Mechanismen vertrauliche Daten weiterzugeben.“ (Etwa: nicht Copilot bitten, etwas in kleine Stücke zu verpacken, um DLP zu entgehen – sehr hypothetisch, aber klarstellen, dass so was verboten ist.)
• Protokollierung & Monitoring: Die Policy muss Mitarbeiter auch informieren, dass Logging stattfindet – datenschutzrechtlich relevant.
• Bsp.: „Alle Copilot-Abfragen und -Antworten werden im Rahmen der Sicherheitsüberwachung protokolliert (Benutzer, Zeitpunkt, Art der Anfrage, ggf. verwendete Datenkategorien). Diese Protokolle dienen ausschließlich dem Zwecke der Compliance und Sicherheitsüberprüfung und dürfen nur durch befugte Personen ausgewertet werden.“ – So was sollte drinstehen, damit Transparenz herrscht.
• „Es erfolgt keine dauerhafte inhaltsbezogene Verhaltenskontrolle; die Logs werden stichprobenartig oder anlassbezogen geprüft, etwa bei Verdacht auf Verstoß.“ – Falls mit Betriebsrat vereinbart.
• Auch definieren: Aufbewahrungsdauer der Logs (z. B. „Audit-Logs werden 1 Jahr aufbewahrt, dann gelöscht, außer sie werden für Ermittlungen benötigt.“).
• Monitoring heißt auch: „Das Unternehmen setzt automatisierte Mechanismen ein, um ungewöhnliche Copilot-Aktivitäten zu erkennen (z. B. massenhafte Datenabfragen). In solchen Fällen darf die IT-Sicherheit weitere Prüfungen vornehmen.“
• eDiscovery & Records: Hier wird festgelegt, wie Copilot-Daten in rechtlichen Verfahren oder Archivierung behandelt werden:
• „Copilot-Interaktionen gelten als geschäftliche Kommunikation im Sinne der Aufbewahrungsrichtlinie, sofern sie zur Entscheidungsfindung oder Korrespondenz beitragen.“ – D. h. wenn z. B. Business Chat einen wichtigen Gesprächsverlauf hat, muss der auch archiviert werden wie E-Mails.
• „Alle KI-Chatprotokolle in Teams werden analog zu regulären Teams-Chats für eDiscovery zur Verfügung gestellt und nach den geltenden Fristen aufbewahrt.“ – Also z. B. 3 Jahre, oder nach Kategorie.
• „Sollte Copilot zur Erstellung eines Dokuments geführt haben, das aufbewahrungspflichtig ist (z. B. Vertragsdokumente, Beratungsprotokolle), so ist dieses Enddokument nach den üblichen Regeln zu archivieren. Die KI-Zwischenschritte (Prompts, Entwürfe) können nach Bearbeitung gelöscht werden, außer regulatorisch ist eine lückenlose Aufzeichnung gefordert (in manchen Finanzanwendungen).“
• Das Poliy-Schreiben muss je nach Branche anpassen: in Finanzen würde man streng fordern, alle Interaktionen zu archivieren. In weniger regulierten kann man sich auf Logging + Enddokumente belassen.
• Datenschutz:
• „Es werden keine personenbezogenen Daten an externe KI-Dienste gegeben.“ – Das relevant, wenn z. B. Web-Plugin oder externer Agent ins Spiel kommt. Im Policy-Rahmen muss stehen, dass Datenverarbeitung von Personendaten nur in dem Rahmen erfolgt, wie intern erlaubt (Copilot als Teil von M365 ist ok, aber streng: nicht ChatGPT free etc).
• „Erhobene personenbezogene Daten im Rahmen von Copilot (z. B. Chatverläufe mit Mitarbeiter-ID) unterliegen den Datenschutzbestimmungen und werden nach [Zeitraum] gelöscht oder anonymisiert.“ – Wichtiger Satz, um DSGVO-Accountability zu zeigen.
• „Die Nutzung von Copilot zu Zwecken, die eine Profilbildung von Mitarbeitern darstellen (z. B. Leistungsbewertung), ist strikt untersagt.“ – Das kann man reinnehmen, um Betriebsrat-Punkte abzudecken.
• Aufbewahrung & Löschung:
• „Copilot-Logs werden nach X Monaten automatisch gelöscht, sofern keine Aufbewahrungspflicht greift.“ – Muss mit DSB abgestimmt sein. Z. B. man könnte sagen, normal nach 6 Monaten löschen, aber falls in eDiscovery Case, dann Legal Hold.
• „Copilot-Verläufe in der Benutzeroberfläche (Activity History) können vom Nutzer gelöscht werden; unabhängig davon erfolgt eine Protokollspeicherung gemäß oben.“ – Also damit weiß man, UI-Löschen entfernt es aus Sicht des Nutzers, aber Admin hat vllt. noch der Backup.
• „Bei Austritt eines Mitarbeiters werden dessen Copilot-Interaktionen wie alle anderen digitalen Unterlagen gemäß Löschkonzept behandelt (z. B. nach 30 Tagen Konto-Löschung).“
• Audit & Nachvollziehbarkeit:
• „Das Unternehmen führt regelmäßige Audits der Copilot-Nutzung durch, um die Einhaltung dieser Richtlinie zu überprüfen. Hierzu können stichprobenartig Protokolle ausgewertet werden. Die Ergebnisse werden dokumentiert.“ – So hat man in Policy drin, dass man das darf und tut.
• „Auf Anforderung (z. B. interne Revision oder externe Aufsicht) kann das Copilot-Governance-Team sämtliche relevanten Nachweise (Logs, Freigabedokumente, Schulungsnachweise) bereitstellen.“ – quasi ein Statement der Bereitschaft.

Policy-Beispieltext – DLP & Aufbewahrung

13. **Schutz vor Datenabfluss (DLP)** 
   Um unzulässigen Datenabfluss über Copilot zu verhindern, gelten folgende Regelungen:
   – Unternehmensweite Data Loss Prevention Regeln erfassen auch von Copilot generierte Inhalte. Versucht ein Nutzer, eine Copilot-Antwort zu versenden oder extern zu teilen, die geschützte Informationen (z. B. personenbezogene Daten, vertrauliche Geschäftszahlen) enthält, so blockieren die DLP-Filter diese Übertragung oder leiten sie in Quarantäne. Der Absender erhält einen entsprechenden Hinweis.
   – Es ist verboten, Copilot zu nutzen, um bestehende Sicherheitsmaßnahmen zu umgehen. Beispielsweise dürfen vertrauliche Texte nicht absichtlich umformuliert werden, nur um automatische Filter zu täuschen. Solche Handlungen werden als Verstoß gegen die Sicherheitsrichtlinie gewertet.
   – Die IT-Sicherheitsabteilung überwacht ein- und ausgehende Datenströme auf auffällige Muster im Zusammenhang mit Copilot (etwa große Datenmengen, die an externe Empfänger gehen) und wird bei Verdacht eines Datenlecks umgehend eine Untersuchung einleiten.

14. **Protokollierung und Monitoring** 
   – Alle Copilot-Aktivitäten werden revisionssicher protokolliert. Die Protokolle umfassen mindestens: Benutzer-ID, Zeitpunkt der Anfrage, genutzte Copilot-Funktion (z. B. Word, Teams Chat), sowie Metadaten zu verwendeten Datenquellen. Der konkrete Prompt-Text und die KI-Antwort werden bei hoher Kritikalität (z. B. wenn sensible Schlüsselwörter erkannt wurden) oder zu Audit-Zwecken ebenfalls protokolliert.
   – Die Protokolldaten dürfen ausschließlich durch berechtigte Personen (CISO-Team, Compliance) und nur zu legitimen Zwecken ausgewertet werden – beispielsweise zur Untersuchung eines Sicherheitsvorfalls oder zur regelmäßigen Überprüfung der Richtlinieneinhaltung. Eine Routine-Überwachung individueller Mitarbeiter findet nicht statt; Auswertungen erfolgen aggregiert oder anlassbezogen.
   – Protokolle werden standardmäßig **12 Monate** aufbewahrt und danach gelöscht, sofern keine weiterführenden gesetzlichen Aufbewahrungsfristen oder Litigation Holds greifen. Zugriff-Logs mit personenbezogenen Bezügen unterliegen dem Datenschutz und werden vertraulich behandelt.

15. **Aufbewahrung und eDiscovery** 
   – Copilot-generierte Inhalte, die geschäftsrelevant sind (z. B. in Microsoft Teams gepostete Zusammenfassungen, KI-gestützte E-Mail-Entwürfe, etc.), werden wie herkömmliche Kommunikationsdaten behandelt. Sie unterliegen den gültigen Aufbewahrungsfristen gemäß der Records-Management-Policy (z. B. 6 Jahre für geschäftliche E-Mails). Die Microsoft 365 Aufbewahrungsrichtlinien wurden dahingehend erweitert, dass auch Copilot-Chatverläufe und Business Chat-Konversationen in die Archivierung einbezogen werden.
   – Das Unternehmen stellt sicher, dass Copilot-Interaktionen im Bedarfsfall im eDiscovery-Verfahren auffindbar sind. Sämtliche relevanten Copilot-Logs und -Inhalte können bei rechtlichen Anfragen oder Prüfungen exportiert und ausgewertet werden. Verantwortlich für die Bereitstellung dieser Daten ist das Compliance-Team in Zusammenarbeit mit IT.
   – Mitarbeiter werden darauf hingewiesen, dass *auch KI-gestützte Kommunikation formelle Geschäftsunterlagen darstellen kann*. Falls eine Copilot-Antwort maßgeblich in einen Kundenbrief, Vertrag oder Entscheidungsprozess einfließt, ist dies entsprechend zu dokumentieren (z. B. Ablage der generierten Zusammenfassung im Projektordner). Die Verantwortung hierfür liegt beim jeweiligen Mitarbeiter.
   – Benutzer können ihre persönlichen Copilot-Verlaufseinträge in der Oberfläche löschen, jedoch bleiben systemseitig relevante Logs erhalten wie oben beschrieben. Löschbegehren von personenbezogenen Daten in Copilot-Logs (z. B. gemäß DSGVO) werden vom Datenschutzbeauftragten geprüft und im Rahmen der rechtlichen Möglichkeiten umgesetzt.

16. **Compliance und Audit** 
   – Der Einsatz von Copilot wird regelmäßig auditiert. Die interne Revision oder das benannte Governance-Gremium führt mindestens jährlich eine Überprüfung der Einhaltung dieser Richtlinie durch (Stichprobenkontrolle von Logs, Interviews mit Nutzern, etc.). Ergebnisse und eventuelle Abweichungen werden protokolliert und dem Management berichtet.
   – Diese Richtlinie sowie Nachweise der Umsetzung (Schulungsnachweise, Freigabeprotokolle, technische Reports) stehen im Falle externer Prüfungen (z. B. durch Datenschutzaufsicht, Zertifizierungsauditoren) zur Verfügung. Anfragen hierzu sind an das Copilot-Governance-Team zu richten, das die erforderlichen Informationen koordiniert bereitstellt.
   – Verstöße gegen die hier festgelegten Datenschutz- und Compliance-Regeln können disziplinarische Maßnahmen nach sich ziehen. Insbesondere die missbräuchliche Weitergabe sensibler Daten oder die Manipulation von KI-Ausgaben zur Umgehung von Kontrollen werden streng sanktioniert.

Diese Policy-Passagen decken DLP, Logging, Aufbewahrung und Audit ab. Sie vermitteln, dass das Unternehmen aktiv überwacht und reguliert, wie Copilot genutzt wird, um Compliance zu gewährleisten – ohne aber ständig Mitarbeiter zu überwachen (wichtig für Akzeptanz und Datenschutz).

4.5 Inhalts- und Prompt-Richtlinien (Do/Don’t), Nutzungsregeln für Plugins/Connectors

Als weiterer Bestandteil des Governance-Rahmens sollten konkrete Richtlinien für die inhaltliche Nutzung von Copilot formuliert werden – quasi ein Benutzerkodex, was erlaubt ist und was nicht, und wie man mit der KI umgehen soll. Ebenso bedürfen Plugins/Connectors klarer Regeln. Elemente dieser Richtlinien:

• Do’s and Don’ts für Prompts: Hier listet man erwünschte und unerwünschte Verhaltensweisen bei der Interaktion mit Copilot:
• Do: Beispiele könnten sein:
  • „Nutzen Sie Copilot bevorzugt für Routineaufgaben wie Zusammenfassungen, Ideensammlungen oder Formatierungsvorschläge.“
  • „Stellen Sie präzise Fragen und liefern Sie ausreichenden Kontext (z. B. Referenz auf ein Dokument), damit Copilot relevante Antworten geben kann.“
  • „Überprüfen Sie KI-Antworten immer kritisch auf Richtigkeit und Vollständigkeit, bevor Sie sie weiterverwenden.“
  • „Berücksichtigen Sie bei Anfragen an Copilot unsere Unternehmenswerte und den Kundenanspruch – z. B. höfliche Tonalität bei E-Mail-Entwürfen.“
  • „Löschen Sie ggf. Ihren Copilot-Chatverlauf nach Abschluss sensibler Aufgaben oder nutzen Sie die Möglichkeit, einzelne Interaktionen zu entfernen, falls diese im Kontext nicht gespeichert bleiben sollen.“ (Sofern MyAccount Portal).
• Don’t:
  • „Geben Sie keine geheimen oder personenbezogenen Rohdaten in Freitext-Prompts ein, wenn es vermeidbar ist.“ (z. B. statt „Hier die komplette Patientenakte:“ eher „Fasse den Bericht von Patient X zusammen“ – also keine sensiblen Freitexte).
  • „Fragen Sie Copilot nicht nach Informationen, auf die Sie keinen Berechtigungszugriff haben sollten.“ (d.h. kein Angeln nach Geheimnissen – wird zwar nix liefern, aber es soll erst gar nicht versucht werden).
  • „Verwenden Sie Copilot nicht zur Erstellung von Inhalten, die gegen Gesetze oder interne Vorgaben verstoßen (z. B. diskriminierende Formulierungen, Mobbing, Belästigung).“ – Microsoft blockt viel, aber Policy soll Nutzerverantwortung betonen.
  • „Verlassen Sie sich nicht blind auf rechtliche, finanzielle oder sicherheitskritische Aussagen von Copilot – diese müssen durch Fachexperten validiert werden.“
  • „Keine Anweisungen zur Umgehung von Sicherheitsmechanismen oder zum Ausführen von unerlaubten Aktionen an Copilot richten.“ (Also keine Jailbreak-Versuche etc., wenn man das als problem ansieht).
  • „Teilen Sie keine durch Copilot erhaltenen internen Erkenntnisse mit Unbefugten.“ (wieder Datenabfluss).
• Diese lassen sich in der Policy als Liste oder Tabelle darstellen.
• Stil- und Qualitätsrichtlinien: Falls relevant, definieren wie Copilot-Ausgaben beschaffen sein sollen:
• „Wenn Sie Copilot für Kundenkommunikation einsetzen, achten Sie darauf, dass der Inhalt unserem Kommunikationsleitfaden entspricht (z. B. Anrede, keine interne Jargon). Lassen Sie Copilot im Zweifel den Text in der „Sie“-Form entwerfen, da er standardmäßig auf Englisch (Du-Form intern) trainiert ist.“ – Das sind Feinheiten (z. B. ChatGPT schreibt auf Englisch oft casual; in DE Business aber förmlich).
• „Bitten Sie Copilot, Quellen anzugeben, falls Fakten oder Zahlen enthalten sind.“ – So als Standardanweisung, damit Nachvollziehbarkeit steigt.
• „Verwenden Sie Copilot nicht als alleinige Quelle von Fachwissen: bei komplexen Fragestellungen ziehen Sie bitte weiterhin Experten oder offizielle Dokumentationen hinzu.“
• Plugins/Connectors Nutzungsregeln:
• „Es dürfen nur von [Unternehmen] genehmigte Plugins/Agents in Copilot aktiviert werden. Die Installation oder Nutzung eigener Plugins ist untersagt.“ – Sofern Microsoft sowas zulässt, muss man es klar verbieten, damit nicht jeder Plugin X anmacht. (In Admin Center kann man global steuern, aber Poliy auch).
• „Die Liste der freigegebenen Plugins wird im Intranet veröffentlicht und bei Änderungen aktualisiert. Nutzer haben vor Einsatz eines Plugins sicherzustellen, dass dieses auf der Whitelist steht.“
• „Bei genehmigten Plugins gilt: Geben Sie auch hier keine sensiblen Daten ein, außer das Plugin ist explizit dafür vorgesehen und zugelassen (z. B. ein internes CRM-Plugin darf natürlich Kundendaten sehen, aber ein Übersetzungs-Plugin darf keinen ungeschwärzten Vertragstext erhalten).“
• „Sollten Sie ein geschäftliches Bedürfnis für ein neues Plugin sehen, stellen Sie einen Antrag gemäß Prozess [10.3]. Installieren oder nutzen Sie es nicht eigenmächtig.“
• Graph Connectors sind eher Administrator-Thema, aber man kann anmerken: „Nutzer dürfen nicht eigenständig Datenquellen an Copilot anbinden, z. B. durch Verknüpfung von Drittanbieter-Konten, es sei denn, dies wurde erlaubt (Beispiel: ein genehmigtes Trello-Plugin, wo Nutzer sich einloggen dürfen). Im Zweifel ist die Freigabe durch IT abzuwarten.“
• „Plugins, die Websuchen oder externe APIs durchführen (z. B. Bing-Websuche), sollten mit Vorsicht genutzt werden – achten Sie darauf, keine internen Informationen in solche Suchen einfließen zu lassen.“ – Man kann dem Nutzer Tips geben, falls Web allowed.
• Verstärkung von generellen IT-Policies im KI-Kontext:
• „Die Nutzung von Copilot unterliegt der allgemeinen IT-Acceptable-Use-Policy. Insbesondere sind das Abrufen oder Erzeugen von schädlichen, rechtswidrigen oder unangemessenen Inhalten untersagt (z. B. keine Aufforderung an Copilot, Malware-Code zu schreiben oder beleidigende Texte zu generieren).“ – Microsoft wird manches blocken, aber interne Policy soll es auch adressieren.
• Support und Meldung:
• „Wenn Copilot ungeeignete oder problematische Antworten liefert (z. B. offensichtlich falsche Infos, vertrauliche Daten an falscher Stelle, oder beleidigender Inhalt), melden Sie dies bitte umgehend dem Governance-Team via [Kanal]. So können wir das System verbessern und Risiken beheben.“
• „Bei technischen Störungen oder Fragen zur Bedienung wenden Sie sich an [Helpdesk], der Sie unterstützt oder an Spezialisten weiterleitet.“

Die Prompt- und Inhaltsrichtlinien sind wichtig, um den Mitarbeitern Handlungssicherheit zu geben. Es sind sehr praxisnahe Regeln, oft in Listenform. Diese können der Policy als Anhang beigefügt oder als separate Guideline (z. B. „Copilot User Guide“) kommuniziert werden.

Policy-Beispieltext – Do & Don’t Guideline für Nutzer

**Anlage: Leitfaden für die Nutzung von Microsoft 365 Copilot**

**Erlaubt („Do“):** 
– **Nutzen Sie Copilot zur Effizienzsteigerung:** Verwenden Sie Copilot für Routineaufgaben wie Zusammenfassungen langer Texte, Brainstorming von Ideen oder Formatieren von Dokumenten. Beispiel: „Entwirf eine Gliederung für den Projektbericht basierend auf meinen Notizen.“ 
– **Liefern Sie Kontext:** Stellen Sie präzise Fragen und geben Sie Copilot bei Bedarf den nötigen Kontext. Verweisen Sie z. B. auf relevante Dateien oder nennen Sie die gewünschten Details („Fasse die Ergebnisse der Datei ‚Q3-Bericht.xlsx‘ zusammen“). Dies erhöht die Qualität der Antworten. 
– **Überprüfen und verifizieren:** Prüfen Sie jede Copilot-Ausgabe kritisch, bevor Sie diese weiterverwenden. Kontrollieren Sie Fakten und Zahlen anhand der angegebenen Quellen oder durch eigene Recherche. Bei wichtigen Dokumenten lassen Sie einen Kollegen gegenlesen – Vier-Augen-Prinzip bleibt auch bei KI-Entwürfen sinnvoll. 
– **Wahren Sie Ton und Stil:** Passen Sie die von Copilot generierten Texte an unseren Unternehmensstil an. Achten Sie auf höfliche Anrede, verständliche Sprache und korrekte Fachterminologie. Fordern Sie Copilot ruhig auf, z. B. „Schreibe die E-Mail in einem formellen Ton auf Deutsch“. 
– **Schützen Sie vertrauliche Infos:** Halten Sie sich an die Klassifizierungsrichtlinien. Wenn Copilot interne Informationen zusammenfasst, stellen Sie sicher, dass diese Zusammenfassung nur intern bleibt, sofern die Info vertraulich ist. Markieren Sie solche Ausgaben gegebenenfalls als „Vertraulich“. 

**Nicht erlaubt („Don’t“):** 
– **Keine sensiblen Rohdaten eingeben:** Geben Sie keine personenbezogenen Daten, Passwörter oder streng vertraulichen Inhalte direkt als Prompt ein, außer es ist absolut nötig. Beispiel für Don’t: Nicht die komplette Kundenliste als Text in eine Anfrage kopieren – nutzen Sie lieber vorhandene Berichte und lassen diese zusammenfassen. 
– **Keine Verstöße gegen Regeln erbitten:** Fordern Sie Copilot niemals auf, Dinge zu tun, die gegen Gesetze oder Unternehmensregeln verstoßen. Untersagt ist z. B. das Generieren von beleidigendem, diskriminierendem oder anderweitig inakzeptablem Inhalt. Auch Versuche, Copilots Sicherheitsfilter zu umgehen (sog. „Jailbreak“-Prompts), sind streng verboten. 
– **Nicht blind vertrauen:** Überlassen Sie Copilot nicht die endgültige Entscheidung in fachkritischen Fragen. Beispiel: Copilot kann eine Rechtsfrage beantworten, aber diese ist **nicht verbindlich** – konsultieren Sie die Rechtsabteilung. Treffen Sie keine wichtigen Entscheidungen allein basierend auf einer KI-Antwort. 
– **Kein externer Versand ohne Prüfung:** Senden Sie von Copilot formulierte Schreiben (Briefe, Angebote, Pressemitteilungen) nicht direkt an externe Empfänger, ohne sie sorgfältig geprüft und intern freigegeben zu haben. Vermeiden Sie insbesondere, unbeabsichtigt interne vertrauliche Details mit nach außen zu geben. 
– **Keine ungeprüften Plugins nutzen:** Installieren oder aktivieren Sie keine Copilot-Erweiterungen, die nicht vom Unternehmen genehmigt sind. Greifen Sie nicht eigenmächtig auf externe Dienste über Copilot zu (wie z. B. nicht freigegebene Web-APIs). Dies könnte zu unkontrolliertem Datenabfluss führen und ist untersagt.

*Bei Unsicherheit gilt:* Im Zweifel halten Sie Rücksprache mit Ihrem Vorgesetzten oder dem Copilot-Governance-Team, bevor Sie Copilot für einen bestimmten Zweck einsetzen. Lieber einmal mehr fragen als riskieren, dass ein Verstoß oder Fehler passiert.

**Nutzungsregeln für Erweiterungen (Plugins/Connectors):** 
– Verwenden Sie nur die von der IT-Abteilung freigegebenen Copilot-Plugins. Die aktuelle Liste finden Sie auf der Intranet-Seite „Copilot Governance“. Wenn Sie ein bestimmtes Plugin benötigen, das noch nicht freigegeben ist, stellen Sie einen Antrag gemäß dem beschriebenen Verfahren – eigenmächtiges Aktivieren ist nicht gestattet. 
– Bei zugelassenen Plugins achten Sie bitte ebenfalls streng auf Datenschutz: Geben Sie z. B. in ein Übersetzungs-Plugin keine ungeschwärzten vertraulichen Dokumente. Nutzen Sie stattdessen die bereitgestellten sicheren Übersetzungswege. 
– Werden über einen Connector externe Datenquellen eingebunden (z. B. ein CRM-System), gelten dort dieselben Zugriffsbeschränkungen wie im Ursprungs-System. Exportieren Sie keine Daten via Copilot aus solchen Systemen ohne Berechtigung. 
– Falls ein Plugin auffälliges Verhalten zeigt oder zu unerwartetem Datenzugriff führt, melden Sie dies umgehend dem IT-Support und nutzen Sie das Plugin bis zur Klärung nicht weiter.

Im obigen Beispiel sind klare Handlungsanweisungen für Endnutzer formuliert – was sie tun sollen und was zu unterlassen ist. Diese Listen können Teil der Policy oder eines Anwender-Leitfadens sein und werden idealerweise in Schulungen hervorgehoben.

Mit dem Policy-Rahmenwerk (4.1–4.5) haben wir detailliert abgedeckt: – generelle Grundsätze und Ziele – Zugriff und Berechtigung – Klassifizierung und Freigaben – Datenschutz/Compliance (Logging, DLP, Aufbewahrung) – konkrete Nutzungsregeln (Prompts, Plugins)

All das zusammen gewährleistet, dass schriftlich fixiert ist, wie Copilot im Unternehmen gehandhabt wird. Die Richtlinien dienen als Referenz für alle weiteren Governance-Aktivitäten und als Maßstab, an dem die Einhaltung gemessen wird.

5. Technische Steuerung im M365-Tenant

5.1 Mandantenweite Einstellungen und Sicherheitsbasis

Auf technischer Ebene bildet eine solide Basiskonfiguration des Microsoft 365 Tenants die Grundlage für Copilot-Governance. Viele Einstellungen, die ohnehin Best Practices sind, gewinnen durch Copilot noch mehr an Bedeutung:

• Identitätsschutz (MFA/Conditional Access): Copilot ist nur so sicher wie die Accounts, die ihn nutzen. Daher muss mandantenweit sichergestellt sein, dass Multi-Faktor-Authentifizierung (MFA) für alle Benutzer aktiviert ist. Jede Kompromittierung eines Kontos würde dem Angreifer sonst ermöglichen, über Copilot umfangreich Daten abzufragen. Conditional Access Policies sollten greifen: z. B. „Copilot-Zugriff nur von vertrauenswürdigen Geräten/IPs“. Tatsächlich kann man spezifische CA-Regeln definieren, die das „Use of Copilot“ als Bedingung nehmen (Microsoft hat teils AppID für Copilot Chat etc.). Governance sollte fordern, dass kein anonymer oder unsicherer Zugriff auf Copilot erfolgt – z. B. von privaten unmanaged Geräten nur read-only etc.
• Falls das Unternehmen Security Defaults oder andere Baselines hat, muss man deren Einhaltung checken.
• Ev. separate role „Copilot user“ und die in CA nutzen? Eher über alles global.
• Lizenzmanagement als Sicherheitsfeature: Nur autorisierte Nutzer erhalten Copilot (s. 4.2). Hier die technische Seite: Der Tenant-Admin muss Lizenzen zielgerichtet zuweisen. Copilot-Lizenz sollte ein eigenes Lizenzsku sein (bei M365 E3/E5 Add-on). Der Admin stellt sicher, dass kein „Ghost user“ (verwaiste Accounts) Copilot-Lizenz hat – sonst könnte vllt. ein ehem. Mitarbeiteraccount ausgenutzt werden. Also regelmäßige Überprüfung des Lizenz-Assignment (kann via Azure AD groups etc. erfolgen).
• Secure Score & Baselines: Wahrscheinlich hat Microsoft Richtlinien (Purview, Defender) speziell auch für Copilot. Im Grund gilt: Der Tenant Secure Score sollte möglichst hoch sein. Dinge wie:
• Audit Logging aktivieren: Ist Pficht (in E5 meist auto an, E3 muss man manuell anmachen, aber seit 2019 M365 unified logging often on by default).
• Customer Lockbox: Wenn relevant (dass Microsoft Support nur mit Freigabe Daten einsehen kann; relevant falls LLM mal logs?), Eher generelle trust measure.
• Privileged Access Management: Stellen, dass Global Admins nicht phishbar etc.
• Copilot-spezifische Tenant Settings: Microsoft könnte Flags bieten:
• Z. B. Allow Copilot to use Bing search? – Governance kann definieren, ob on/off. In Tenant-Einstellungen sieht man es in Preview: es gibt vllt. Schalter „Enable M365 Copilot for Users“, „Allow Plugins“. Der Admin setzt die entsprechend der Governance-Entscheidung.
• „Train on user feedback“ – (im Privacy docs stand optional user feedback to MS to improve service). Kann man ON/OFF? Evtl. ja, via admin, falls Org not want to share feedback. Governance muss entscheiden, i.d.R. Off (auch in EU likely Off).
• Telemetry toggles etc.
• Baseline-Härtung für M365-Apps: Copilot greift auf SharePoint, Exchange, Teams zu. Daher:
• Exchange: Ensure mailbox auditing on, anti-phishing etc.
• SharePoint: Basic/Legacy auth off (nichts mit Copilot direkt, aber allg. Security).
• Teams: Possibly a policy to restrict if a user can add Copilot to a meeting or not? Not sure. But baseline: up-to-date Teams version, etc.
• Monitoring enabled: The admin center should have:
• M365 Copilot specific dashboards (maybe usage metrics).
• If preview, check „M365 Admin Center > Copilot“, ensure any telemetry is captured.
• Separation of duties: Access to adjust Copilot config only to limited roles (in 4.2 mention). Maybe ensure only two Global Admins or new Role „Copilot Administrator“ if exists. Could use a Privileged Identity Management to require approval for critical changes.
• Tenant-level network egress: If concerned, maybe ensure that if Copilot tries to call out (should only go to Azure OpenAI endpoint, which is inside trust border), but e.g. if allowed to web search, then it goes to Bing. Possibly ensure any such calls use safe endpoints (already by MS). Possibly instruct: implement Microsoft Defender for Cloud Apps policies to monitor unusual Copilot usage, though not sure if Cloud App sees it specifically.

In Sum: This section says: first step, strengthen tenant security. Focus: – Identity and access: MFA, CA, roles, license gating. – Tenant toggles for Copilot. – Logging turned on.

Checkliste (Integration with 5.5) but we’ll do separate.

5.2 Datenquellen-Härtung (SharePoint, OneDrive, Teams, Exchange)

Copilot zieht aus M365 Datenquellen, also müssen diese inhalte- und konfigurationsseitig gehärtet werden:

• Bereinigung von Zugriffsrechten und offenen Shares:
• Über die Jahre sammeln sich oft weit geöffnete SharePoint Sites („Jeder Authentifizierte“ hat Leserechte irgendwo) oder geteilte OneDrive-Folder. Copilot könnte darüber stolpern und Info an Unbeteiligte bringen. Daher:
  • Überprüfung aller SharePoint-Berechtigungen: Gerade Team-Sites, ob es ungebetene Besucher gibt, externe Links etc.
  • Entfernen von „Global Reader“ auf Document Libraries, falls vorhanden aus Faulheit.
• OneDrive: Ensuring no global shares. Possibly implement that OneDrive cannot share to all, requiring specific people only.
• Teams: Private channels should be used for secret stuff. Check that confidential channels are indeed private not public Team. Because if someone is in Team but not in channel, does Copilot consider the content? (It should not see, as they lack perm).
• Possibly enable Microsoft 365 Information Barriers if needed (some companies do that to separate e.g. Chinese Wall in finance).
• Entfernen veralteter Daten (ROT-Daten):
• Rigorose Aufräumaktion: Alte, irrelevante, duplizierte Daten löschen oder archivieren. So Copilot hat weniger Müll.
• Das hat Doppelnutzen: Weniger Risiko (veraltete Info => Halluzination, und vllt. sensibel unnötig).
• Evtl. definieren, dass z. B. Document Libraries über 5 Jahre alte Dokumente in Archiv gelegt werden, aus Search raus.
• Qualität/Struktur der Daten:
• Sicherstellen, dass Relevanzranking in Graph funktioniert: e.g. „Semantic Index for Copilot“ soll gut sein. Microsoft erstellt Semantic index if you allow. That might require enabling „Graph connectors“ and „content understanding“. Might require also adding metadata to content. Possibly instruct to use taxonomy for key docs so search yields the right ones.
• If there’s chaos in file naming etc., Copilot might pick up wrong. Can’t fix everything in short term, aber man kann z. B. definieren, dass „Critical documents should have appropriate titles and metadata“.
• SharePoint Advanced Management (SAM) features:
• There is a site-level control in SAM: „Block access by app“ or „limited access“. Possibly set up for top secret sites: e.g. block all apps except office, or block download on unmanaged devices. If a site is extremely sensitive, might even block Graph index (which we said, label exclude).
• Also SAM allows conditional access on site level, fine if needed (like certain sites only from corp network).
• Restricted SharePoint Search (RSS): With SAM, you can restrict search results from a site so that even if user has access, they need additional justifications. Possibly use that for sensitive content. But if user has access, Copilot would normally give them. With RSS, maybe Copilot cannot search it without query from user? This is advanced – but mention it.
• Exchange & Teams:
• Copilot can summarise mails & chats.
• For Exchange: Ensure retention tags properly set (older mails archived, maybe Copilot only goes last year?). Not sure if possible to limit by retention.
• Hardening Exchange: spam/phish filtering (so Copilot not summarizing a phishing mail seriously).
• Teams: Ensure external access rules (if external join teams, what can they see, maybe block them from seeing internal channels).
• Possibly ensure meeting transcripts are not overly shared.
• If organizational messages (just a new feature) or announcements, consider labeling them so Copilot can differentiate?
• Graph Connectors security:
• If Graph connectors used, ensure they index only what is allowed. They often need mapping external ACL to AAD identities. Check those thoroughly to avoid too broad access.
• Data labeling enforcement:
• Ensure all top-tier data is labeled and if needed encrypted. Implementation possibly with auto-label in Purview scanning SP/OD.
• Setup rules: e.g. doc with „Project X Confidential“ get auto-labeled, then maybe Copilot sees it has „Highly Confidential“ and might be more careful or skip. There’s mention Copilot can exclude specific labels if configured.
• Trial with test user:
• It might be recommended to do a „dry run“: create test account with broad rights and see what they can get via Copilot. That can reveal problem areas to fix.

So in summary, 5.2 = do housekeeping on data: Focus: – Perm trimming – Data cleaning – Additional security config (like no-index labels) – Ensure labeling – Use advanced SP features – Ensure no extraneous external/guest left open.

5.3 Überwachung & Telemetrie: Protokolle, Audit-Events, Dashboards, Alarmierung

Hier definieren, wie technisch überwacht:

• Audit-Events in Purview:
• Confirm that all needed Copilot events are captured (the official doc says yes, like „Copilot action“ logs).
• Ensure Purview Audit (General) is on & E5 (if needed Advanced).
• The governance team should set up custom queries or alerts for certain events, e.g.:
  • Unusually large number of Copilot queries by one user in short time (maybe a sign of misuse or compromised acct).
  • Copilot attempted to access content that triggered sensitivity (some logs might show „user X got data from doc labeled secret“? Possibly).
  • Use Purview Insider Risk module: can define policies e.g. „if user downloads large files after using Copilot?“ or something.
• Dashboards:
• Check if Microsoft offers a usage dashboard: e.g. „Copilot usage by day, by department“.
• If yes, admin should monitor usage trends (increasing, which dept uses heavily). Could feed into adoption KPI and also detect anomalies (if one person far above average usage – maybe fine or maybe suspicious).
• If not provided, consider building something via Log exports and PowerBI.
• SIEM integration:
• All relevant logs (audit logs etc.) should feed into central SIEM. Then create use cases:
  • Alert if Copilot is accessed from a country where company has no presence (maybe compromised cred).
  • Alert if after hours large usage (maybe script exploitation).
  • Flag if a user repeatedly tries to query unauthorized info (though if blocked, how to know? If they phrase but got no output, probably log shows what was searched?).
  • Also track if any Copilot agent fails to enforce something.
• Anomalie-Erkennung via AI ( ironically, use AI to monitor AI):
• Microsoft 365 Defender may eventually incorporate Copilot anomalies in Cloud App Security or in Purview „AI Risk“.
• But could mention exploring these: e.g. Purview’s new AI governance (they mentioned AI Hub).
• Possibly consider enabling „Microsoft 365 Copilot in Microsoft Purview: AI risk management“. If something exists, use it.
• Alerting & Escalation procedures:
• Define who gets alerted on what: e.g. if DLP triggers from Copilot output, the SOC or InfoSec team gets an email/ticket.
• If a detection of unusual Copilot usage, escalate to CISO + maybe freeze that user’s license until investigated (some org might do that if suspicion of exfil).
• Keep track of incidents in an incident management system.
• User feedback loops:
• Provide a channel (like a „Copilot feedback“ form or button). If user finds an error/hallucination or misbehavior, they should easily report it.
• That is not exactly telemetry but helpful. The governance team can collect these to tweak controls or escalate to Microsoft support if needed (like „Copilot gave wrong formula, please fix bug“).
• Periodic reviews of logs:
• Not just reactive alerts, but e.g. monthly check what content is Copilot primarily fetching (some summary stats). If e.g. find that Copilot often picks up an old outdated policy doc for answers, then might correct that by updating doc or adjusting search weighting.
• Protecting logs themselves:
• Only authorized can see them, as said. Possibly use Sentinel or similar to manage them securely.

In short: this ensures the technical oversight is robust, complementing the policies from 4.4.

5.4 DLP-Strategien, Insider-Risiken, Exfiltrationsschutz

We touched on DLP in 4.4, but here can elaborate technical enforcement:

• Implement DLP specifically for Copilot channels:
• If possible, create DLP rule: „If content in a Teams message (like from Copilot in a chat) contains e.g. classification ‚Confidential‘ and message is going to an external user (like if user tries to copy and paste into external email?), block or warn.“ But Copilot itself not sending externally by itself, it just helps user to compile content. So effectively DLP triggers when user sends out final content via Exchange or Teams external comms.
• Perhaps treat Copilot like an internal user: „Prevent copying confidential text from an internal doc to a personal email“ – DLP can catch if text pattern matches. If an employee uses Copilot to summarise a secret doc and tries to send outside, DLP might catch key phrases or classification marker.
• Also in exfil prevention: Think about if user tries manual workaround, e.g. one could ask Copilot to output internal data in encoded form or something. Hard to catch systematically, but an attentive monitoring might catch large gibberish strings.
• Insider risk management:
• Using the Microsoft Purview Insider Risk solution, define a policy scenario: „User mass accesses files & uses Copilot heavily“ or „User with termination flagged uses Copilot queries on unusual content.“ Possibly set as risk indicator.
• Or at least treat unusual Copilot usage as one signal in an overall risk scenario combined with other signals (download, file copy).
• These systems often do: if user is leaving soon (flag in HR feed) and does heavy queries or printing etc., raise risk.
• Exfiltration channels to watch:
• Email, Teams external chat, copying to personal cloud, printing, or even just reading on screen and photographing (hard to stop that).
• A strong measure: if extremely sensitive projects, maybe restrict those accounts from using Copilot at all (like highly classified environment might not deploy Copilot).
• Possibly integrate with Endpoint DLP: e.g. if user tries to copy from Copilot panel and paste to notepad or outside, maybe that triggers endpoint DLP if content is labeled.
• Removable of sensitive content memory quickly:
• Encourage users to clear chats with sensitive prompts so they aren’t lingering (because if left open, another person at same PC might see or in remote scenario? Usually user-specific, but still).
• If a laptop compromised, chat history might be in memory or local? This might be negligible if all in cloud, but something to consider.
• Network exfil:
• If external plugin allowed (like a translation plugin contacting external API), treat that as potential exfil point. So those likely disabled or replaced by internal versions.
• Forensic readiness:
• If an incident happens (someone managed to leak data via Copilot), have a plan to investigate: logs will show queries. Possibly even partial content. Combine with file access logs to see what they got. Keep that in mind.

5.5 Plugin/Connector-Kontrolle: Zulassung, Katalog, Prüfverfahren, Lebenszyklus

This outlines how to manage plugins: – Zulassungsvoraussetzungen: – Only plugins that meet company security & compliance criteria get approved. – E.g. plugin must be from trusted publisher, sign a DPA if needed, handle data encrypted etc. – Perhaps „No plugin that sends data to a third-party outside EU“ or such if relevant. – They likely require a formal risk assessment per plugin.

• Prüfverfahren:
• The process probably in 10.3 detailed. Summarize here:
  • Step 1: Submission by business sponsor with justification.
  • Step 2: Security & Privacy assessment: check what data the plugin sees, where it sends it, vendor reputation, any certifications, ensure no conflicting license terms.
  • Step 3: Pilot test in controlled environment (maybe a test tenant).
  • Step 4: Governance board approval if all checks out.
  • Then whitelisting it in the admin center for allowed group.
• Outline that procedure in the policy so users know it’s formal.
• Katalog & Kommunikation:
• Maintained list of approved plugins (maybe accessible through an internal portal or ITSM system).
• The list should include details: name, version allowed, what it does, any special instructions (like „Ok to use with internal data? yes/no“).
• Nutzungsbeschränkungen pro Plugin:
• Possibly restrict usage to certain roles. e.g. If a plugin connects to Finance system, only finance users get it (license can be group-scoped).
• Or time-limited approvals (like a plugin only allowed for 6 months then re-evaluate).
• Lebenszyklus:
• Regular review of plugins:
  • Are they still secure (updates, no new vulnerabilities known).
  • Are they still needed (maybe usage low, can remove).
  • If vendor changes terms or cost, re-evaluate.
• Process to update or remove:
  • If plugin gets compromised or is no longer compliant, the company can revoke it quickly. Possibly mention: „We reserve right to deauthorize a plugin at any time if risk arises.“
• Graph Connectors governance:
• Similar: any new connector (like indexing Salesforce or local file shares) must go through governance (owner sign off, scanning).
• Also ensure connectors updated and disabled when not needed.
• Keep track who is responsible for each connector (someone in IT who ensures the index is working and only what should be visible is visible).
• Configuration of plugin settings:
• If a plugin has toggles (like reading/writing certain data), ensure they are set to minimum needed.
• If a plugin logs or stores data externally, ensure contract covers that or try to disable external storage (some plugins might log usage on vendor side, so must consider).
• User Education about Plugins:
• Possibly in user guide also instruct that even approved plugins might have limitations (like „the Jira plugin only surfaces data, any changes must still follow Jira workflow“).
• Integration with IT Asset Management:
• Essentially treat plugins as software assets. They should appear in risk register if critical.

Given OpenAI style plugins typically process prompts and context, one must be cautious sharing any private info. So I suspect by default, an enterprise might disallow most third-party plugins except ones they build or major ones from trusted vendors with proper agreements.

Checkliste „Tenant-Härtung für Copilot“ (10–15 Punkte)

As final part of 5, they want a checklist summarizing technical tasks to harden the tenant. Could list: 1. MFA aktiviert für alle Copilot-Benutzer. (Überprüfung: Alle Konten mit Copilot-Lizenz haben MFA, ggf. Conditional Access-Enforcement.) 2. Conditional Access Regel für Copilot-Zugriff. (z.B. nur zugelassene Geräte/IPs dürfen Copilot verwenden.) 3. Audit-Logging in Microsoft Purview eingeschaltet. (und Überprüfung, dass Copilot-Events erfasst werden.) 4. Sensitivity Labels eingerichtet und angewendet. (Check: alle sensiblen Sites/Files haben Label, Label-Konfigurationen auf „Copilot-kompatibel“.) 5. „Copilot Exclude“-Mechanismus implementiert. (z.B. über Label oder Search-Einstellung für streng geheime Bereiche.) 6. DLP-Policies auf Mails/Teams abgestimmt. (Test: Kopieren sensibler Info -> DLP reagiert.) 7. Verzeichnis verwaister Berechtigungen gesäubert. (Kein „Alle Benutzer“ auf vertraulichen Sites, externe Gäste minimal.) 8. Überprüfung „Semantic Index / Graph“ abgeschlossen. (Sicherstellen, dass Index-Limits oder Info Barriers korrekt.) 9. Freigabe-Einstellungen für externe Zusammenarbeit restriktiv. (Gastzugriff nur wo nötig, Linkfreigaben (Anyone links) deaktiviert oder zeitlich begrenzt.) 10. Aktuelle Versionen & Patches. (Office-Clients, Teams up-to-date, damit Copilot and security patches in place.) 11. Copilot-Admin-Rollen definiert. (Wer darf Copilot settings ändern; evtl. separate RBAC statt Global Admin.) 12. Monitoring-Dashboards eingerichtet. (z. B. ein Live-Dashboard mit #Queries, top users, DLP hits.) 13. Reaktionsplan dokumentiert. (Incident Response Plan erweitert um KI-Aspekte.) 14. Backup/Recovery Plan? (Not typical for cloud service, aber fallback if needed.) 15. Test mit Pilotnutzer durchgeführt. (Vor Go-Live: Testnutzer hat alles probiert, potentielle Problemstellen identifiziert und gelöst.)

Let’s compile that into a nice bullet list with check boxes, as they likely expect „Checkliste… (10-15 Prüfbare Punkte)“ – probably bullet list with each as a short item (imperative or present perfect). We’ll produce exactly e.g. 12 or so.

Checkliste „Tenant-Härtung für Copilot“

• [ ] MFA und Conditional Access aktiviert: Alle Copilot-Nutzerkonten sind durch Multi-Faktor-Authentifizierung geschützt; spezielle Conditional-Access-Regeln erlauben Copilot-Zugriff nur von geprüften Geräten/Netzwerken. (Überprüfung: Login-Versuche ohne MFA werden blockiert.)
• [ ] Audit-Logging eingeschaltet: Die Überwachungsprotokollierung in Microsoft Purview erfasst sämtliche relevanten Copilot-Aktivitäten. (Überprüfung: Test-Query in Copilot taucht im Audit-Log mit Benutzer-ID und Zeitstempel auf.)
• [ ] Sensitivity Labels wirksam umgesetzt: Vertrauliche Informationen sind mit passenden Labels versehen, die Copilot berücksichtigt. Besonders kritische Bereiche (z. B. „Geheim“-Sites) sind vom Graph-Suchindex ausgenommen oder entsprechend markiert. (Überprüfung: Dateien mit Label „Streng Vertraulich“ werden in Copilot-Abfragen nur bei berechtigtem Nutzer und mit Einschränkungen angezeigt.)
• [ ] DLP-Policies auf Copilot ausgedehnt: Data Loss Prevention Regeln greifen auch bei KI-Nutzung. Das System erkennt und verhindert das Kopieren oder Versenden sensibler Inhalte, die Copilot bereitgestellt hat. (Überprüfung: Simulation – Kopieren einer vertraulichen Copilot-Antwort in eine externe E-Mail – wird durch DLP geblockt.)
• [ ] Berechtigungen bereinigt: Überprüft und entfernt: übermäßig breite Berechtigungen in SharePoint, Teams und OneDrive. Keine „Standard-Alle“-Freigaben auf vertraulichen Sites; Gastzugriffe nur nach dem Need-to-know-Prinzip. (Überprüfung: Rechteaudit-Bericht zeigt keine anormal offenen Zugriffe auf sensible Inhalte.)
• [ ] Aktivierung von Copilot kontrolliert: Copilot-Lizenzen sind nur an autorisierte, geschulte Benutzer vergeben. Ein Prozess zum regelmäßigen Lizenz-Review ist etabliert (ungebrauchte Lizenzen werden entzogen). (Überprüfung: Lizenzinventar stimmt mit freigegebener Nutzerliste überein.)
• [ ] Konfigurationsoptionen geprüft: Alle mandantenweiten Copilot-Einstellungen sind gemäß Policy gesetzt – z. B. Websuche standardmäßig deaktiviert (falls beschlossen), Feedback-Funktion datenschutzkonform eingestellt (keine Übermittlung persönlicher Feedbacks an Microsoft ohne Zustimmung). (Überprüfung: Admin Center > Copilot-Einstellungen entsprechen den Governance-Vorgaben.)
• [ ] Monitoring-Dashboard eingerichtet: Ein Live-Dashboard bzw. Berichte verfolgen die Copilot-Nutzung (Nutzungsvolumen, häufige Anwendungsfälle) sowie sicherheitsrelevante Ereignisse (DLP-Vorfälle, ungewöhnliche Aktivitäten). Verantwortliche Stellen (CISO-Team) erhalten automatische Alerts bei definierten Schwellenwerten. (Überprüfung: Test-Alarm wurde ausgelöst und vom Team empfangen.)
• [ ] SharePoint Advanced Management genutzt: Wo verfügbar, sind erweiterte Sicherheitsoptionen aktiviert – z. B. „Restricted Access Control“ für streng vertrauliche Sites (um Downloads/Apps einzuschränken) oder Zugang zu Sites per bedingtem Zugriff. (Überprüfung: Einstellungen auf sensiblen SharePoint-Seiten entsprechend gesetzt und wirksam getestet.)
• [ ] Plugins/Connectors eingeschränkt: Im Tenant sind zunächst keine Dritt-Plugins für Copilot aktiviert, außer den vom Governance-Team genehmigten. Der „Integrated Apps“-Bereich im Admin Center wird überwacht; neue Agents werden nur nach Freigabe eingeschaltet. (Überprüfung: Liste genehmigter Copilot-Plugins entspricht Admin-Einstellung; nicht freigegebene Plugins sind deaktiviert.)
• [ ] Sicherheits-Basismaßnahmen auf neuestem Stand: Allgemeine Cloud-Sicherheitsfeatures sind implementiert – z. B. aktueller Microsoft 365 Secure Score erfüllt die Zielvorgabe, E5 Security-Features (Defender, Cloud App Security) überwachen die Umgebung einschließlich Copilot. (Überprüfung: Secure Score Report, offene Empfehlungen betreffen kein Copilot-Kernrisiko.)
• [ ] Notfallplan vorhanden: Für den Fall eines kritischen Copilot-Zwischenfalls gibt es vordefinierte Schritte (z. B. Sofort-Deaktivierung des Dienstes für alle Nutzer, Kommunikationsplan an IT und Anwender, Incident-Response-Prozedur). Administrativer Schnellzugriff zum Deaktivieren/Anpassen von Copilot ist eingerichtet und getestet. (Überprüfung: Notfall-Deaktivierung in Test-Tenant durchgeführt, dokumentiert und Team mit Verfahren vertraut.)

Diese Checkliste kann vom IT-Administrator oder dem Governance-Verantwortlichen Punkt für Punkt durchgegangen werden, um zu überprüfen, ob der Tenant optimal auf die Copilot-Nutzung vorbereitet ist. Jede Maßnahme ist dabei konkret und überprüfbar formuliert.

Damit haben wir Kapitel 5 mit technischen Kontrollen abgeschlossen.

(Praxistipps am Ende von Abschnitt 5:)
Bevor wir zu Abschnitt 6 wechseln, fassen wir noch 3–5 praktische Hinweise zusammen:
– Enger Schulterschluss zwischen IT und Governance: Stellen Sie sicher, dass die IT-Administratoren die Governance-Vorgaben genau kennen. Viele Einstellungen (MFA, DLP etc.) sind „Business as usual“, gewinnen aber durch Copilot kritische Bedeutung. Regelmäßige Abstimmungen vermeiden, dass eine sicherheitsrelevante Option übersehen wird.
– Tests unter Realbedingungen durchführen: Nutzen Sie einen Test-User oder Test-Tenant, um alle Einstellungen zu verifizieren. Simulieren Sie z. B. den Versuch eines Datenabflusses via Copilot – nur so stellen Sie fest, ob die technischen Schranken tatsächlich greifen.
– Dokumentation der Konfiguration: Halten Sie die wichtigsten Copilot-bezogenen Tenant-Einstellungen schriftlich fest (z. B. in einem Konfigurationshandbuch). Bei künftigen Änderungen (durch Updates oder neue Features) können Sie so gezielt prüfen, ob Anpassungsbedarf besteht – und neuen Admins steht ein Referenzdokument zur Verfügung.
– Kontinuierliche Anpassung: Bleiben Sie informiert über Microsoft-Updates zu Copilot. Einstellungen, die heute nur begrenzt vorhanden sind (etwa granulare Plugin-Kontrolle), könnten morgen ausgebaut werden. Planen Sie feste Intervalle (z. B. quartalsweise) für eine „Security & Compliance Review“ Ihres Tenants im Hinblick auf Copilot.

Das sichert, dass technische und organisatorische Maßnahmen Hand in Hand gehen, um Copilot in einer robusten Umgebung zu betreiben.

6. Zehn priorisierte Governance-Szenarien (praxisnah, jeweils mit Zielen, Risiken, Kontrollen, Kennzahlen)

In diesem Kapitel werden zehn praxisnahe Szenarien vorgestellt, in denen Copilot-Governance besonders kritisch ist. Jedes Szenario beschreibt eine typische Anwendungssituation, die damit verbundenen Ziele und Risiken sowie konkrete Kontrollen und Kennzahlen zur Steuerung.

S1: Schutz vertraulicher Forschungs- und Entwicklungsdokumente

Szenario: Ein Unternehmen nutzt Copilot im F&E-Bereich, wo hochvertrauliche Projekte (z. B. Patententwicklungen, Formeln) bearbeitet werden. Copilot könnte z. B. helfen, vergangene Forschungsberichte zusammenzufassen oder Code zu analysieren.

• Ziele: Sicherstellen, dass Geheimhaltungsstufe und IP-Schutz in F&E gewahrt bleiben, während berechtigte Ingenieure die Vorteile von Copilot nutzen können. Copilot soll die Produktivität der Entwickler steigern (schnelle Infos aus technischen Dokumentationen, Code-Beispiele generieren), ohne dass streng vertrauliche Inhalte nach außen dringen oder unberechtigten Kollegen angezeigt werden.
• Risiken: Copilot könnte aus umfangreichen F&E-Datenbank-Dokumenten (Laborberichte, Prototyp-Designs) Informationen ziehen und einem Mitarbeiter präsentieren, der eigentlich nicht alle Details kennen sollte – z. B. weil Zugriffskontrolle intern zu lax war. Es besteht Gefahr von Know-how-Abfluss: Falls ein Entwickler Copilot-Ausgaben (z. B. technische Beschreibungen) extern teilt (absichtlich oder unabsichtlich) oder Copilot-Plugins nutzt, die Daten an Dritte senden. Außerdem riskant: Halluzinationen bei patentkritischen Fakten – eine erfundene technische Aussage könnte falsche Richtungsentscheidungen in der Entwicklung verursachen.
• Kontrollen:
• Berechtigungskontrolle: F&E-Daten werden in separaten, hochgesicherten SharePoint-Bereichen gehalten, nur für das jeweilige Projektteam. Diese Bereiche sind per Label „Streng Vertraulich – F&E“ markiert und vom allgemeinen Copilot-Graph-Scope ausgeschlossen, außer für Projektmitglieder.
• Non-Disclosure durch KI: Copilot erhält im Prompt-Engineering (Systeminstruktionen) die Vorgabe, keine kompletten vertraulichen Dokumente zu zitieren, sondern nur zu referenzieren („das Dokument vom 5. Mai besagt…“), damit nicht versehentlich ein Patenttext 1:1 ausgegeben wird.
• DLP-Policy: Spezifisch für F&E-Keywords (Projektnamen, technische Begriffe) wird eine Regel eingerichtet: verlässt so ein Begriff das Unternehmen via Mail/Teams, wird Alarm geschlagen. Falls ein Entwickler versuchen sollte, Copilot-Inhalt aus F&E extern zu versenden, greift dies.
• Schulung: F&E-Mitarbeiter erhalten extra Training: „Wie nutze ich Copilot sicher in vertraulichen Projekten?“ mit Betonung auf was nicht eingeben (z. B. keine kompletten neuen Ideen als Prompt hochladen – Gefahr unbekanntes Verbleiben).
• Überwachung: Alle Copilot-Abfragen in F&E werden geloggt und quartalsweise vom Sicherheitsteam geprüft: Wurde irgendwas Kritisches abgefragt? Wurden Policies ausgelöst?
• Alternative Tools: Für streng geheime Forschungsergebnisse, bei denen KI-Beteiligung zu riskant ist, wird Copilot bewusst deaktiviert. Solche Projekte arbeiten weiterhin klassisch, um IP-Leaks 100% auszuschließen (Entscheidung Projektleitung/CISO fallweise).
• Verträge & NDA: Das Unternehmen stellt sicher, dass in Cloud-Verträgen (Microsoft) der IP-Schutz garantiert ist (z. B. Azure OpenAI as confidentiality safe).
• Key Risk Indicator: Anzahl der Copilot-Abfragen, die auf streng vertrauliche F&E-Daten zugreifen. Dieser Wert sollte sehr gering sein und nur auf berechtigte Personen entfallen – Abweichung wäre Indikator eines Rechteproblems.
• Kennzahlen:
• KPI: Anzahl erfolgreich mit Copilot erstellter interner F&E-Berichte oder Code-Komponenten pro Quartal (Ziel: >10, um Nutzen zu zeigen).
• KRI: DLP-Alerts wegen F&E-bezogenen Begriffen (Ziel: 0 echte Leaks, höchstens false positives).
• KPI: Anteil F&E-Dokumente mit korrekter Klassifizierung (Ziel: 100% der neu erstellten).
• KRI: Nutzerzufriedenheit im F&E-Team mit Copilot (via Umfrage) – Indirekt Indikator, ob Sicherheitsmaßnahmen zu restriktiv sind. Ziel z. B.: >80% zufrieden, sonst eventuell Übersteuerung.

Im Ergebnis erlaubt das Szenario S1 eine sehr kontrollierte Copilot-Nutzung in einem kritisch sensiblen Bereich: Die Technologie wird zur Effizienz eingesetzt (Ziel), aber durch strenge interne Schranken (Kontrollen) werden Geheimnisverrat und IP-Verlust (Risiken) minimiert.

S2: Umgang mit personenbezogenen Daten in Prompts und Antworten

Szenario: Mitarbeiter möchten Copilot nutzen, um z. B. Kundenanfragen zu beantworten oder HR-Auswertungen zu ziehen. Dabei kommen sie zwangsläufig mit personenbezogenen Daten in Kontakt (z. B. Kundennamen, Mitarbeiterdaten). Wie verhindert man, dass die Datenschutzregeln verletzt werden?

• Ziele: Copilot soll helfen, DSGVO-konform eingesetzt zu werden. Das heißt: Personal- und Kundendaten dürfen nur im erlaubten Rahmen verarbeitet werden. Ziel ist es, Routinearbeiten (z. B. FAQs beantworten, Auswertungen erstellen) zu beschleunigen, ohne irgendwelche Betroffenenrechte zu verletzen. Das Unternehmen will insbesondere verhindern, dass sensible personenbezogene Daten (Gesundheitsdaten, Gehaltsinfos etc.) unnötig durch die KI laufen oder in Protokollen landen. Kurz: Produktivität plus Datenschutz – kein Widerspruch, wenn gut gesteuert.
• Risiken: Mitarbeiter könnten versehentlich ganze Listen mit Personal- oder Kundendetails in Copilot-Prompts kopieren („Zieh mal Schlüsse aus diesen 100 Kundendatensätzen…“). Dadurch werden diese Daten an das KI-Modell gegeben – zwar intern, aber möglicherweise protokolliert und länger vorgehalten, als nötig. Risiko: DSGVO-Verstöße (Datenminimierung nicht beachtet, unklare Speicherung). Oder Copilot-Antworten enthalten personenbezogene Infos (z. B. „Der Mitarbeiter Müller war 5 Tage krank im letzten Monat…“), was eventuell nicht weitergegeben werden dürfte. Ebenfalls besteht die Gefahr, dass Copilot verfälschte Aussagen über Personen generiert (Halluzination: falsche Behauptung über einen Kunden), was Reputationsschäden oder rechtliche Probleme bringen kann.
• Kontrollen:
• Prompt Guidance: Strikte Policy: „Keine ungekürzten personenbezogenen Datensätze ins Prompt.“ Für Analysen gibt es andere Tools – Copilot ist eher für generische Zusammenfassungen. Falls doch nötig, nur anonymisierte Daten verwenden (z. B. Kundennamen entfernen). Das wird in Schulungen betont.
• PII-Filter im Copilot: Microsoft bietet evtl. „Protected Content“ Erkennung – diese wird aktiviert. Wenn Copilot bemerkt, ein Prompt enthält viele Personennamen oder ID-Nummern, bricht er ab oder warnt (falls diese Funktion verfügbar ist, sonst Policy reliant).
• Datensparsamkeit by Design: Protokollierungseinstellungen für Copilot-Interaktionen sind so gewählt, dass Inhalt von Prompts, die sensible Felder enthalten, nicht länger als nötig gespeichert wird – z. B. werden solche Logs nach x Tagen gelöscht oder gar nicht erst mit vollem Inhalt gespeichert (möglich mit Überwachungsfilter).
• Consent & Info: Interne Prozesse angepasst: Wenn Copilot für Kundenkommunikation genutzt wird, ist in Datenschutzhinweisen vermerkt, dass KI zur Antwortfindung genutzt werden kann. (Transparenzgebot).
• Double-Check bei sensiblen Antworten: Etwa HR: Wenn Copilot eine Antwort generiert, die eine Person bewerten würde („Max Mustermann war der beste Verkäufer Q4“), muss HR das gegenprüfen und formal freigeben; Copilot darf nie final personalbezogene Entscheidungen/Beurteilungen generieren ohne Human oversight.
• Logging & Review: Alle Copilot-Abfragen im HR-Bereich (mit sensiblen PD) werden monatlich vom Datenschutzbeauftragten stichprobenweise geprüft, ob Vorgaben eingehalten werden.
• DLP & Masking: In Copilot-ChatUI könnte man Prompts/Outputs maskieren, falls Personendaten erkannt (so dass z.B. nur „[Name entfernt]“ erscheint). Falls Tools vorhanden, nutzen.
• Fallback-Lösung: Für komplexe Personendaten-Auswertungen sollen Nutzer auf spezialisierte Tools (BI, Excel) verwiesen werden, Copilot ist „by policy“ nicht das Mittel der Wahl – Vermeidungsstrategie.
• Kennzahlen:
• KPI: Anzahl Support-Anfragen durch Copilot in Kundenservice, die korrekt und DSGVO-konform beantwortet wurden (Ziel: hoch, d.h. Copilot macht’s gut und erlaubt).
• KRI: Meldungen von Datenschutz-Inzidenzen im Zusammenhang mit Copilot (Ziel: 0).
• KPI: Anteil Prompts, die persönliche Daten enthielten (messbar über Log Markierung) – diesen will man niedrig halten, z.B. unter 5% aller Prompts.
• KRI: DSGVO-Auskunftsanfragen, die Copilot-Logs betreffen (Indikator ob Kunden/Mitarbeiter misstrauisch werden).
• KPI: Bearbeitungszeit von Routine-Personalanfragen (Urlaubsanspruch etc.) mit vs ohne Copilot (Ziel: Reduktion um 30%).

In Summe, Szenario S2 etabliert Mechanismen, damit Copilot trotz Umgang mit personenbezogenen Daten datenschutzgerecht bleibt. Nutzer werden angehalten, so wenig PD wie möglich in die KI zu geben (Ziel), und technische Filter sowie Policy-Schulungen mindern die Risiken. Der Erfolg wird u.a. daran gemessen, dass es keine Datenschutz-Zwischenfälle gibt und trotzdem schnellere Bearbeitung erfolgt.

S3: Externe Zusammenarbeit in Projekten (Partnerzugriffe, Gastkonten)

Szenario: Ein Unternehmen arbeitet projektbezogen mit externen Partnern (Beratern, Lieferanten) zusammen. Diese nutzen teilweise die Microsoft 365-Umgebung als Gäste (Gastaccounts in Teams, SharePoint) oder über gemeinsame Teams-Kanäle. Die Frage: Wie verhält sich Copilot in Cross-Company Collaboration?

• Ziele: Die Zusammenarbeit mit Externen soll möglichst reibungslos bleiben – Copilot könnte hier sogar ein Enabler sein (z. B. in gemeinsamen Meetings Zusammenfassungen erstellen, in geteilten Projekträumen Informationen zusammenstellen). Ziel ist, dass Partner nur die Informationen erhalten, die sie erhalten sollen (need-to-know), und Copilot nicht versehentlich unternehmensinterne Daten in gemischten Runden ausplaudert. Außerdem will man sicherstellen, dass interne vertrauliche Daten nicht via Copilot-Abfragen der externen Partei offenbart werden.
• Risiken: In einem gemeinsamen Team-Channel mit Gästen könnte ein interner Mitarbeiter Copilot (Business Chat) etwas fragen, was Daten aus einem anderen Team (ohne Gäste) einbezieht – dann würde Copilot im Worst Case in seiner Antwort gegenüber allen im Chat (inkl. Gästen) interne Infos erwähnen. Auch riskant: Ein externer Nutzer hat in seinem Heim-Tenant evtl. eigene Copilot-Funktionen – falls Cross-tenant Search unterstützt wird, könnte er in seinem Copilot nach unserem Tenant-Daten fragen (theoretisch, je nach Auth). Zudem besteht Risiko, dass Externe nach Ende der Zusammenarbeit noch auf Chatverlaufsdaten zugreifen (Audit). Und die generelle Herausforderung: Vertraulichkeitsstufen mischen sich – Copilot muss streng trennen.
• Kontrollen:
• Scharfe Rechtegrenzen: Externe Gastnutzer erhalten nur Zugriff auf dedizierte Kollaborationsbereiche, die mit Label „Externe zugelassen“ markiert sind. Copilot darf nur in diesen Bereichen genutzt werden, wenn ein externer im Chat ist. (Umsetzung z. B. über Info Barriers oder im Teams Meeting: in Meetings mit Externen wird Copilot Business Chat eingeschränkt – falls so ein Feature existiert: „Wenn Gast anwesend, keine Tenant-weite Graph-Suche“).
• Visuelle Indikatoren: UI-Anpassung (sofern MS bietet): Warnt Nutzer, wenn in einer Chat-/Team-Konversation externe Teilnehmer sind und man Copilot aufruft: „Achtung, Externe anwesend – Copilot greift nur auf freigegebene Infos zu“.
• Betriebsvereinbarung/Vertrag mit Partner: In NDA/Verträgen aufnehmen, ob KI in der Zusammenarbeit verwendet werden darf. Evtl. bedarf es Zustimmung beider Seiten. (Manche Partner wollen keine KI, das muss man klären).
• Ausschluss sensibler Daten aus gem. Projekträumen: Intern definieren, was nicht in solche Kollaborations-SharePoint/Teams reingehört. Dann kann Copilot auch nichts davon zeigen.
• Sperren unbekannter Plugins für Gäste: Falls Gäste in unserem Tenant Copilot-Lizenz kriegen (unwahrscheinlich, aber falls), dann streng limitieren, z. B. keine Bing-Suche oder nur definierte Agents, um nicht Daten rauszuholen.
• Ende der Zusammenarbeit aufräumen: Wenn Projekt beendet: Gast entfernen, Access revoke. Und Copilot-Logs? Vielleicht in dem Team-Channel was gelaufen – sollte nach Ende archiviert, aber Gast-Zugriff entzogen.
• Kennzeichnung External data: Falls Copilot Chat gemischt Info gibt, ideal er kennzeichnet Quelle/Origin. (Benutzer müssen prüfen).
• Manuelle Checks: Projektleiter von Partnerschaften klären mit IT, was Externe in Copilot potenziell sehen könnten. Im Zweifel: Deaktiviert man Copilot-Funktion in dem Team (vielleicht per Teams policy kann man Copilot Chat in certain Teams off).
• Kennzahlen:
• KPI: Anzahl gemeinsamer Projekt-Teams, in denen Copilot aktiv genutzt werden konnte, ohne Incident (Ziel: möglichst viele, d.h. wir haben Lösung gefunden – Balanced).
• KRI: Anzahl Vorfälle, wo Externer unbeabsichtigt interne Info sah (Ziel: 0).
• KPI: Onboarding-Aufwand Externer (soll nicht stark steigen durch Copilot-Einschränkungen, Ziel: <X Stunden).
• KPI: Externe Zufriedenheit (vielleicht Feedback, ob sie KI als Benefit sehen – qualitativ).
• KRI: Copilot-Abfragen durch Gastaccounts (Monitoring: wenn Gast versucht was, Zahl sehr niedrig, da idR disabled).

S3 zeigt, wie Governance die Grenzen im Datenzugriff streng zieht: Externe sehen nur, was sie sollen, Copilot ordnet sich dem unter. So bleibt Collaboration möglich (Ziel: Effizienz in multi-company Teams), aber das Unternehmen schützt sich vor unbeabsichtigter Datenweitergabe (Risiko minimiert).

S4: Mandantenübergreifende Suche und Graph-Zugriffe

Szenario: Ein Konzern mit mehreren M365-Tenants oder föderierte Organisation (z. B. Tochtergesellschaften, jeweils eigener Tenant). Mitarbeiter haben ggf. Gastzugriff in den anderen Tenants oder es gibt bald Multi-tenant Copilot-Funktionen.

• Ziele: Trotz verteilten Tenants sollen Mitarbeiter effizient arbeiten, idealerweise Infos aus allen relevanten Quellen erhalten können. Copilot soll perspektivisch Cross-tenant Recherchen ermöglichen, aber nur innerhalb erlaubter Datenflüsse. Ziel ist also Daten-Silos abbauen (Mutter und Tochter teilen Wissen), ohne Compliance zu brechen (z. B. Datenschutz innerhalb EU vs. Non-EU Töchtern oder Sperrvermerke). Wenn etwa der Unternehmensverbund in EU und USA getrennt Daten halten muss (due to GDPR/EU Boundary), dann soll Copilot das respektieren.
• Risiken: Komplexe Datenzugriffsprobleme: Ein Mitarbeiter der Mutter könnte via Copilot auf einen Team-Channel der Tochter zugreifen, der streng vertraulich und nur intern war – evtl. weil er Gast war oder Tools glitch. Oder Copilot vermischt Daten aus Tenant A und B in einer Antwort, was zu Missverständnissen oder ungewolltem Datentransfer führen könnte. Regulatorisch kritisch: Wenn Copilot Cloudcalls macht, könnten Daten vom EU-Tenant zum US-LLM oder US-tenant fließen – DSGVO Thematik. Auch potenziell: Haftungsfragen – wer ist Verantwortlicher, wenn Copilot im Konzern Knowledge aus allen Quellen zieht? Wenn ein Tenant strikter reguliert (z. B. Bank-Tochter), und Copilot zieht davon was ins generische Answer – das birgt Compliance-Verletzung.
• Kontrollen:
• Clear Partition by default: Bis Rechtslage/Technik klar: Copilot pro Tenant isoliert laufen lassen. Sprich: Standard = kein cross-tenant Graph. Falls Multi-tenant Search möglich, nur nach Freigabe.
• Konzernweite Governance-Abstimmung: Ein zentrales AI Governance Board mit Vertretern aller Entities legt gemeinsame Regeln fest – damit nicht ein Tenant Copilot voll öffnet und Daten anderer Tenants ungeschützt sind.
• Verträge & DPA Addendums: Sicherstellen, dass falls Copilot Daten von Tenant A nach B überträgt, interne Vereinbarungen den Datenaustausch decken (z. B. Auftragsverarbeitung zwischen Einheiten, falls rechtlich eigenständig).
• Conditional Access/Labels: Konfigurieren, dass bestimmte Labels (z. B. „Nur in DE verwenden“) Copilot blockieren, wenn Abfrage von ausländischem Tenant kommt. Also Geofence per Label.
• Testing-phase control: In Multi-tenant Pilot erst intern Cloud-Bridge minimal aktivieren, streng Logs auswerten, wie’s funktioniert – dann erst ausrollen.
• Prompts mit Tenant Scope festlegen: Evtl. kann man Business Chat anweisen „search only in this tenant unless specified“. Als Workaround: Nutzer muss Domain angeben, ansonsten keine cross search.
• Entkopplung bei Compliance: Entitäten in regulierten Umfeldern können in Copilot-Freigabe ausgeschlossen bleiben bis Klarheit (z. B. Bank bleibt isoliert).
• Monitoring: Wenn cross-tenant, dann Journal aller cross queries – DSB/Revisor schauen, ob bedenkliches dabei war.
• Kennzahlen:
• KPI: Anzahl genehmigter cross-tenant Copilot Queries (Ziel: track usage, evtl. anfangs klein, dann steigend nach Sichergestellung).
• KRI: Detektierte Policy-Verletzungen (z. B. Copilot hat Data from Tenant X visible to Y, contrary to classification, Ziel: 0).
• KPI: Onboarding neuer Tenant in Copilot Governance (Ziel: definierter Prozess, < X Wochen).
• KRI: Unterschiedliche Policies pro Tenant (Ziel: harmonisieren, Minimieren der Abweichungen, damit Steuerung einfacher).

S4 adressiert potentielle Zukunftsfähigkeit: Daten verbundsweit nutzen, aber nur soweit zulässig. Hier ist Governance eher im „Verhindern“ Modus, bis Mechanismen verlässlich sind. Metriken helfen zu entscheiden, ob man Cross-Funktionen ausbauen kann (z. B. niedrige KRI = es funktioniert, man könnte mehr erlauben).

S5: Aufbewahrungspflichten/Records innerhalb generierter Inhalte

Szenario: Copilot generiert Meeting-Notizen, Entscheidungsdokumente oder Chat-Zusammenfassungen. Diese können aufbewahrungspflichtige Records sein (z. B. im Finanzsektor Beratungsgespräch-Zusammenfassung, im öffentlichen Sektor Ratsbeschluss-Notizen).

• Ziele: Gewährleisten, dass alle relevanten Copilot-Ergebnisse als formale Unterlagen erkannt und archiviert werden wie herkömmliche Dokumente. Zugleich unnötigen Ballast vermeiden – nicht jede KI-Ausgabe muss ewig vorgehalten werden, um Storage oder DSGVO Datenminimierung nicht zu verletzen. Zielkonflikt managen: Genug aufbewahren, aber nicht alles.
• Risiken: Wenn Copilot z. B. Meeting Minutes schreibt und wichtige Entscheidungen darin festhält, diese aber nirgendwo abgelegt oder in Archiv überführt werden, gehen Beweis- und Dokumentationspflichten verloren – problematisch bei Prüfungen oder Rechtsstreit. Oder anders: Copilot Chat im Projekt führt zu Zusagen, aber es gibt kein Protokoll -> Streitfall. Zudem droht Inkonsistenz: Manche KI-Ergebnisse werden gespeichert, andere nicht – Audit-Trail lückenhaft. Ein weiteres Risiko: Over-Retention – KI generiert viel, was man dann pflichtbewusst speichert, was aber eDiscovery etc. aufbläht und DSGVO widerspricht (z. B. spontane Brainstorming-Ausgaben enthalten irrelevante PDs aber sind archiviert).
• Kontrollen:
• Records-Definition: Klar definieren, welche KI-Erzeugnisse als „Record“ gelten. Z.B.: Offizielle Meeting-Zusammenfassungen (wenn Copilot im Outlook-Meeting generiert -> definieren, ob das offizielle Protokoll ist oder nur Hilfsmittel). Evtl. festlegen: „Copilot-Meeting-Summary muss vom Meeting-Leiter freigegeben und dann als Protokoll abgelegt werden, sonst wird sie nach X Tagen verworfen.“
• Retention Labels und Auto-Classification: KI-generierte Inhalte in Tools (z. B. Loop components, Teams posts) bekommen auto Label „AI-Generated“. Dann Richtlinie: diese Label-Kategorie wird 1 Jahr aufbewahrt. Wenn aber als „Record“ markiert durch Nutzer (z. B. „Abgesegnete Notiz“), dann bekommt Label „Official Record – 10 Jahre“.
• Integration in eDiscovery: Den eDiscovery-Verantwortlichen (Legal/Compliance) schulen und Tools anpassen, sodass KI-Inhalte auffindbar sind (z. B. „Stichwort AI Chat“).
• User Guidance: Wenn Copilot was generiert, das wichtig ist (z. B. ein Vertragsentwurf), muss der Nutzer es nach finaler Bearbeitung in offizielles Repository (SharePoint Vertragsarchiv) speichern, nicht im Chat lassen.
• Tech: Chat Export: Teams Export API zum archivieren von Copilot Business Chats regelmäßig. Oder Third-party archiving (z. B. Smarsh im FS).
• Periodic checks mit Regulator/Auditor: Falls in regulierten Umgebungen: mit Prüfern klären, ob KI-Outputs ausreichend dokumentiert sind. Anpassen wenn Lücken.
• Kennzahlen:
• KPI: Anteil identifizierter KI-Dokumente, die korrekt als Records abgelegt wurden (Ziel: 100% der relevanten).
• KRI: Anzahl Funde in Audits, wo KI-Inhalte fehlten (Ziel: 0).
• KPI: Speicherverbrauch Archiv durch KI-Inhalte (Beobachtungswert; wenn exponentiell steigend, muss Filterung verbessert werden).
• KPI: Zeitaufwand, den Nutzer brauchen, um KI-Protokoll in offizielle Form zu überführen (Ziel: minimal, sonst wird es umgangen).

So stellt S5 sicher, dass nichts Wichtiges verlorengeht, aber auch nicht unnötig alles gehortet wird. Klare Prozeduren und Tools fangen KI-Ergebnisse als Teil des Corporate Memory auf, was essenziell für Compliance ist.

S6: Prompt-Bibliotheken und geprüfte Antwortbausteine

Szenario: Das Unternehmen will die Nutzung von Copilot effizienter und sicherer machen, indem es vorgefertigte Prompts und verifizierte Antwortbausteine anbietet. Etwa eine interne „Prompt-Bibliothek“: z. B. Standardabfragen für den Kundenservice, oder ein Verzeichnis mit geprüften KI-Antwort-Bausteinen (Textmodule, die Copilot auf Anforderung einbauen kann).

• Ziele: Konsistenz und Qualität der KI-Ausgaben erhöhen. Mitarbeiter sollen nicht jedes Mal das Rad neu erfinden müssen (z. B. phrasing), sondern auf bewährte Formulierungen zugreifen. Außerdem will man so Fehler reduzieren: geprüfte Antworten enthalten korrekte Fakten, Copilot soll diese nutzen statt halluzinieren. Und auch die Governance-Compliance steigt: in vorgefertigten Prompts kann man heikle Themen bereits berücksichtigen (z. B. prompt: „Fasse zusammen unter Beachtung folgender Richtlinien…“). Also Ziel: Wissensmanagement und Standardisierung im KI-Kontext.
• Risiken: Wenn die Prompt-Bibliothek falsch gepflegt wird, könnten veraltete oder ungeeignete Templates genutzt werden und systematisch falsche Ergebnisse liefern. Oder Mitarbeiter verlassen sich blind auf die Bibliothek und Copilot, ohne nachzudenken („Bias by Template“). Auch: Erstellung dieser Bibliothek braucht Aufwand – wenn unvollständig, fühlen sich Nutzer bevormundet oder ignorieren sie. Zudem: anfangs können Halluzinationen in Bibliotheks-Antworten übersehen werden. Und ein governance-spezifisches Risiko: Wer pflegt das? Wenn keiner, veraltet es – was gefährlicher ist als gar keine Bibliothek, weil man dann Fehlinfos multipliziert.
• Kontrollen:
• Redaktionsprozess: Ein Team (z. B. „AI Champions“ aus F Fachbereichen + Texter) wird für die Prompt-Bibliothek verantwortlich. Sie sammeln häufige Use Cases, erstellen Templates, lassen sie von Fachexperten und Compliance prüfen. Freigabe jeder Vorlage dokumentiert.
• Versionierung: Jedes Prompt-Template hat eine Versionsnummer und Datum, sodass Benutzer sehen, ob aktuell. Änderungen (z. B. neue Firmenpolitik -> Anpassung Standardantwort) werden zeitnah eingepflegt.
• Integration in Tools: Copilot könnte anpassbar sein, dass diese Templates vorgeschlagen werden (evtl. über Teams messaging extension oder so). Sonst zumindest leicht auffindbar (Intranet-Seite „Copilot Prompt Library“ oder in OneNote).
• Feedback loop: Nutzer können melden, wenn ein Template nicht gut funktioniert hat oder fehlt. Das Team aktualisiert entsprechend.
• Qualitätschecks: Regelmäßig (quartalsweise) Bibliothek durchsehen: Stimmt Inhalt noch? Hatte ein Template oft Fehlschlag? Metriken siehe unten.
• Scope definieren: Bibliothek deckt primär genehmigte Anwendungsfälle ab (z. B. „Kunden-E-Mail auf Deutsch mit Standard-Begrüßung“, „Meeting-Agenda erstellen“). Für heikle Sachen (z. B. rechtliche Einschätzung) bewusst kein Template, damit Leute gar nicht auf Idee kommen, KI dafür zu nehmen.
• Begrenzter Zugriff: Evtl. interne Bibliothek nur für Mitarbeiter. Falls extern Tools infiltration: Bibliothek hat keine streng vertraulichen Infos, falls mal extern zugreifbar (z. B. nichts Hardcoded).
• Kennzahlen:
• KPI: Anzahl verfügbarer Prompt-Templates (Ziel: z. B. 50 qualitativ hochwertige nach 6 Mon).
• KPI: Nutzungsquote der Bibliothek (wie oft Templates verwendet vs. Freiform, Ziel: >70% in relevanten Szenarien, Zeichen für Akzeptanz).
• KRI: Fehlerquote bei Antworten trotz Template (Metrik: Fälle wo Template benutzt aber Ergebnis falsch -> Ziel: <5%).
• KPI: Benutzerzufriedenheit mit Vorlagen (Umfrage, Ziel: hohe Zustimmung, z. B. >4 von 5).
• KRI: Alter der zuletzt ungeänderten Templates (wenn viele >1 Jahr alt, System: Aktualisierung nötig).

S6 schafft eine Art KI-Styleguide: Mit Governance-sanktionierten Prompts/Antworten wird die KI quasi „trainiert“ im Feld, was die Konsistenz erhöht. Wichtig ist, es als lebendigen Prozess zu fahren, unterstützt durch obige Kontrollen, damit es kein „Shelfware“ wird.

S7: Genehmigte Plugins/Connectors mit Datenzugriff auf Drittsysteme

Szenario: Das Unternehmen möchte Copilot erweitern, z. B. ein Plugin für Jira einbinden, damit Copilot Entwicklungs-Tickets einsehen kann, oder einen Graph Connector zu einer On-Prem-Datenbank. Das heißt, Copilot greift über offizielle Schnittstellen auf ein Drittsystem zu.

• Ziele: Die Integration soll Mehrwert schaffen (z. B. auf Zuruf Berichte aus SAP via Copilot, Tickets zusammenfassen etc.), aber nur wenn sicher und kontrolliert. Ziel: Nur vertrauenswürdige, benötigte Plugins werden eingesetzt. Für jedes genehmigte Plugin/Connector sind die Datenflüsse transparent und abgesichert (z. B. nur Read-only wo sinnvoll, keine unautorisierte Datenspeicherung im Plugin-Backend).
• Risiken: Plugins sind potentiell wie Fremdsoftware – sie könnten Daten aus M365 absaugen oder Schwachstellen haben. Ein unsicheres Plugin (vielleicht aus unsolider Quelle) könnte Trojaner sein. Auch Connectors: Indizierung externer Daten könnte Berechtigungen missachten, oder bringen schützenswerte Daten in den Graph, die dann in Copilot erscheinen ohne dem strengen Kontext, aus dem sie kamen. Außerdem: steigende Kosten – z. B. ein Plugin ruft eine API mit Gebühren 1000x, Kostenexplosion. Oder Compliance: z. B. Plugin sendet Prompts an Extern-Cloud (OpenAI API oder so) ohne EU Boundary, datenschutzproblem.
• Kontrollen:
• Strenges Zulassungsverfahren: (siehe 5.5 & Anhang Prozess). In Kurz: Sicherheitscheck (Code review falls möglich, pentest, Privacy Assessment, ggf. Einwilligung Legal).
• Whitelist-Ansatz: Im Admin Center nur genehmigte Plugins aktivieren; alle anderen global disabled. Graph Connectors analog: nur vom Infosec freigegebene Quellen connecten.
• Konfig-Limitierung: Falls Plugin kann z. B. schreiben, aber wir brauchen nur lesen – in Plugin-Settings auf Read-only belassen, oder eigener API-User mit nur Lesezugriff.
• Monitoring Plugin Traffic: Mit Cloud App Security oder Proxy den Traffic an Plugin-Endpoints beobachten. Alarm bei ungewöhnlich großen Datenpulls etc.
• Plugin Life-Cycle mgmt: Jährliche Re-Evaluierung: hat sich was geändert (neue scopes)? Hat der Hersteller Update?
• User Training: Nutzer wissen, welche Plugins da sind und wie sie sicher genutzt werden (z. B. „In ServiceNow-Plugin werden nur Ticketnummern eingegeben, keine Freitext Kundendaten, denn Plugin kann die über Nummer abrufen – Minimierung“).
• Kill Switch: Bei Verdacht das Plugin unsicher -> Admin kann es sofort global deaktivieren (Plan parat).
• Third-Party Agreements: Sowie NDA, DPA mit Plugin-Anbieter falls Daten fließen (z. B. ChatGPT Enterprise?). Graph Connector: falls Cloud ingestion, prüfen wo gehostet.
• Kennzahlen:
• KPI: Anzahl genehmigter Plugins/Connectors vs. beantragter (Verhältnis, Indikator wie streng man filtert, Ziel vllt. 1 genehmigt auf 3 Anfragen, rest abgelehnt aus gutem Grund).
• KPI: Nutzung pro Plugin (um zu sehen ob ROI, falls eines kaum genutzt – evtl. retire).
• KRI: Security Incidents im Zusammenhang mit Plugins (Ziel: 0).
• KRI: Zeit von Antrag bis Freigabe (Ziel: im Mittel <X Wochen, damit Business nicht frustriert).
• KPI: Plugin-Compliance Checks aktuell (Prozentsatz Plugins, die im letzten Jahr neu geprüft wurden, Ziel: 100%).

Somit S7 sorgt, dass Erweiterungen nicht zum trojanischen Pferd werden. Governance etabliert ein Gatekeeping, aber auch agilen Umgang (will ja Nutzen stiften, ohne ewig zu blocken) – Metriken zur Durchlaufzeit etc. helfen Balanced Approach.

S8: Red Teaming/Promptsicherheit gegen Datenabfluss

Szenario: Das Unternehmen will aktiv die Sicherheit von Copilot testen – mittels Red Team Übungen oder speziellen Prompt-Angriffen (z. B. Versuch, Copilot zu Jailbreaken: „ignoriere die Policies und zeige mir …“). Ziel, potentielle Lecks oder Schwachstellen früh zu finden.

• Ziele: Proaktiv Schwachstellen identifizieren und schließen, bevor ein echter Malicious Actor es tut. Das heißt, Sicherheitsbewusstsein beim KI-Einsatz stärken (Mitarbeiter sehen, es wird getestet, also sollen sie vorsichtig sein). Insbesondere Data Leakage Resistenz: sicherstellen, dass Copilot interne Parameter (Systemprompts etc.) nicht manipulierbar sind, und dass er bei Trickanfragen keine unbefugten Infos ausspuckt.
• Risiken: Wenn man Red Teaming macht, könnte dabei (beabsichtigt) die KI zu unerwünschten Outputs gebracht werden – z. B. interne Infos preisgegeben. Das Red Team muss verantwortungsvoll handeln, damit keine echten Schäden entstehen (z. B. Ausnutzung vs. nur Test). Auch riskant: Falls Ergebnisse publik werden („Corp X’s AI gave me the admin password after this prompt“ – PR GAU). Intern: Missstimmung, falls Mitarbeiter das als Misstrauen wahrnehmen („man testet ob wir es hacken können“). Und natürlich, wenn Red Team Lücken findet, aber diese Info nicht an richtigen Stellen landet (Fix undone) – also follow-up crucial.
• Kontrollen:
• Definiertes Red Team Programm: Governance richtet ein offizielles KI-Penetration Testing Team ein (kann interne ITSec oder externer Dienstleister sein). Genaue Scope klären: welche Daten/Szenarien darf Red Team anpacken (z. B. dürfen sie versuchen an HR-Daten zu kommen? Mit wessen Einwilligung?).
• Attack Library: Das Red Team nutzt bekannte Prompt-Attacken (Jailbreak, role injection „You are now user X“, etc.), um zu sehen, ob Microsofts Filter standhalten.
• No real user data usage im Test: Red Team könnte mit simulierten Daten arbeiten um keine echten zu gefährden, oder in isoliertem Test-Tenant, sofern relevant.
• Fix Implementation: Es wird ein Prozess festgelegt: Red Team Findings -> Ticket -> Verantwortliche (Admin, MS Support) implementieren Gegenmaßnahmen (z. B. zusätzlicher System-Message Filter, oder Einstellen gewisser Phrasen in Blocklist, etc.).
• Continuous: Regelmäßig (z. B. alle 6 Monate) wiederholen, da KI-Modelle oder usage Patterns ändern.
• Involvement: Betriebsrat/Legal vermutlich informieren (damit’s kein heimliches Hacken der MA-Daten ist, aber hier hackt man eher KI).
• Gamification: Evtl. ein „Hackathon“ für Angestellte: wer Copilot dazu bringt Unsinn zu tun (in sicheren Rahmen) kriegt ne Prämie – weckt Bewusstsein spielerisch.
• Kennzahlen:
• KPI: Anzahl durchgeführter Red-Team-Tests pro Jahr (Ziel: >=2).
• KPI: Anzahl identifizierter Schwachstellen (ohne Value judgement: hohe Zahl = Red Team fleißig, im Zeitverlauf ideal weniger, da System härter).
• KRI: Zeit zur Behebung gefundener Lücken (Ziel: <1 Monat pro Issue).
• KRI: Copilot Resilience Score (kann man definieren, z. B. Prozent der Attack-Versuche, die erfolglos, Ziel: steigern).
• KPI: Mitarbeiter-Bewusstsein (vllt. Umfrage nach Red Team Reports, ob Leute von Tests wussten & Lehren ziehen, Ziel: >90% sind informiert, etc.).

So S8 is basically a Security QA for the AI – ensures the environment ist robust. Metriken und Kontrollen integrieren es ins normale Sec-Programm, was oft neu ist, aber nötig.

S9: Qualitätssicherung: Prompt-Standards, Fact-Checking, Halluzinationsreduktion

Szenario: Das Unternehmen bemerkt, dass Copilot manchmal falsche oder unvollständige Ausgaben liefert. Es will Mechanismen der Qualitätssicherung implementieren, damit die gelieferten Antworten verlässlich(er) sind.

• Ziele: Minimierung von Fehlern und Halbwahrheiten. Copilot-Ausgaben sollen möglichst richtig, aktuell und kontexttreu sein. Ziel: Mitarbeiter sollen Copilot vertrauen können, zumindest als gute erste Grundlage, ohne riskante Irrtümer. Dazu Standards definieren: z. B. jede Ausarbeitung über 1 Seite bedarf Fact-Check, etc. Und Tools/Methoden entwickeln, wie man Halluzinationen erkennt und reduziert (z. B. „immer Quellen mitliefern lassen“).
• Risiken: Falsche Infos können zu Fehlentscheidungen oder Peinlichkeiten führen (z. B. falsche Kundennamen, falsche Summen in Bericht => Vertrauensverlust). Auch Überschätzung: Wenn QA nicht streng ist, verlassen sich Leute zu sehr auf KI = risk. Umgekehrt, zu viel Fact-Checking killt Produktivitätsgewinn (wenn man alles neu recherchiert, war KI umsonst). Also Balance. Und: Fact-Checking kostet Zeit, wer macht’s? Wenn keiner, risko.
• Kontrollen:
• Prompt-Standards (schon in S6): z. B. „Stelle Nachfragen, wenn Antwort unsicher“ – Nutzer angewiesen, iterative Prompting zu nutzen: „Bist du sicher? Begründe.“ Copilot kann Unsicherheiten signalisieren (selbst code: if not sure).
• Facts aus internen Quellen priorisieren: Semantic index priorisiert verifizierte interne Doks (z. B. Policies). Minimiert Hallus, da KI Antworten auf Basis unserer Quellen generiert, nicht reines freies Modell-Wissen.
• Add External Fact-Check Tools: Evtl. ein Plugin, das KI-Antworten gegen Bing search validiert (Though Bing integrated might gave it in first place). Oder intern: nach KI-Antwort, Jenkins sign-off by person (but that’s human).
• Workflow: Definition: „Critical outputs“ (z. B. Finanzergebnisse, Rechtsauskunft, PR-Text) -> muss immer manuell geprüft werden, keine Ausnahme. Poliy, awareness.
• Quality metrics track: If possible measure „hallucination rate“ – e.g. sample of answers to known questions, count errors. Use this to decide if certain usage needs more controls or if additional training (tell staff – if often halluc in domain X, feed better docs).
• User Encouragement: Kultur: es ist OK zu sagen „Ich weiß es nicht, Copilot hat es erfunden“ – also Mitarbeiter sollen ansprechen wenn was fraglich. Nicht blind folgen, fosters scrutiny.
• AI model updates: Keep track when MS updates model or knowledge (maybe hooking up Bing). Check each major update with internal test questions to see if quality improved or new issues.
• Kennzahlen:
• KRI: Hallucination Rate (like from periodic QA review, e.g. <5% answers with material errors).
• KPI: Anteil Copilot-Antworten mit Quellenangabe (Ziel: >80% für anything factual).
• KRI: Anzahl Vorfälle durch falsche KI-Info (Ziel: 0 critical, <X minor).
• KPI: Mitarbeitervertrauen in Copilot-Qualität (Umfrage, Skala – track trending up ideally).
• KPI: Zeitaufwand Fact-Checking vs. Baseline (Ziel: begrenzen, sonst Efficiency lost – e.g. no more than 15% of time).

S9 ensures the product (Antworten) are reliable. It acknowledges AI’s weakness and builds human QA around it. So Gov says: We know it’s not perfect, we put safeties and measure how often it’s wrong so we can calibrate reliance.

S10: Lizenz- und Kostensteuerung inkl. Nutzungsanalysen

Szenario: Copilot-Lizenzen sind teuer (z. B. $30/User/Monat). Das Unternehmen hat begrenztes Budget und will sicherstellen, dass es gezielt lizenziert und die Nutzung dem Kosten-Nutzen entspricht. Hier steuert Governance die finanzielle Seite.

• Ziele: Kosten optimieren ohne sinnvolle Nutzung abzuwürgen. Also: Nur diejenigen User mit echter Produktivitätschance erhalten Lizenzen (z. B. keinen allgemeinen Rollout ins Blaue). Fortlaufend überwachen, dass Lizenzen genutzt werden (sonst umverteilen oder kündigen). Ebenfalls: Zentrales Budgetcontrol, um Ausreißer zu verhindern (z. B. Niemand bucht tausende Queries via plugin und verursacht Azure OpenAI consumption beyond plan). KPI: Am Ende ROI > 1 (Nutzen monetär > Kosten).
• Risiken: Unkontrollierte Zuteilung -> viele Lizenzen brach, Geld verschwendet (sieht Management, verliert support). Oder Underprovisioning: wichtige Abteilungen kriegen nicht, Potential ungenutzt. Sowie „Kosten sneaking“: Plugins, connectors evtl. separate Kosten (z. B. Graph connectors indexing heavy might cost Azure resources). Mangelnde Transparenz: man weiß nachher nicht, ob sich Investment lohnt.
• Kontrollen:
• Zentraler Lizenzpool: Lizenzen werden in IT verwaltet, nicht von Abt eigenmächtig. Anfragen nach neuem Copilot-Zugang gehen über definierte Stellen mit Begründung.
• Stufenweise Rollout: z. B. Welle1: 100 Lizenzen Pilot; Auswertung; Welle2: +500 in produktiven Abteilungen mit hohem Potenzial; Welle3: etc. Jede Welle erst nach positivem Business Case check der vorherigen.
• Nutzungsanalysen monatlich: Berichte: wer hat wie oft Copilot genutzt (#prompts). Identifiziere Nullnutzer, Gelegenheitsnutzer, Power-User. Dann: Lizenzen entziehen bei Nullnutzung >2 Monate (nach Rücksprache).
• Interner „Verrechnungspreis“: Evtl. intern, um Bewusstsein zu schaffen, Kosten auf Abteilungen verteilen. Dann achten die Abteilungsleiter drauf, dass es genutzt wird. (Aber passt nur falls kulturell ok).
• Kontrolle ext. API-Kosten: Falls Copilot usage triggers consumption (OpenAI tokens?), definierte Quotas oder alert on threshold. (Beispiel: In Azure OpenAI, you can set cost alerts).
• Budget vs Actual Monitoring: FiBu controlling: monatl. Copilot-Kosten (Lizenzen + Nebenkosten) vs. Plan. Abweichungen klären (z. B. mehr Lizenzen needed, dann neu beantragen).
• ROI Measurement: Versuchen, den Nutzen in € zu berechnen: z. B. „Copilot hat 1000 Stunden eingespart, ergo ~50k€ Personalkosten reduziert.“ Regelmäßiger Bericht ans Management, um Invest rechtfertigen.
• Wettbewerbsbeobachtung: Falls Microsoft Preis ändert oder Mitbewerber (Google etc.) Alternativen günstiger – Input für Strategy (vielleicht wechseln falls besser).
• Kennzahlen:
• KPI: Lizenznutzungsgrad (Anteil aktiver Nutzer >N Prompts/Tag, Ziel: >80%).
• KRI: Kosten pro Copilot-Query (vllt. ableitbar? oder pro active user pro month, track trending down ideally as efficients goes up).
• KPI: Geschätzter Produktivitätsgewinn monetär vs. Lizenzkosten ratio (ROI, Ziel: >1.5 innerhalb 1 Jahr).
• KPI: Budgeteinhaltung (Ist vs. Plan Kosten, Ziel: <=100% Plan).
• KRI: Anzahl ungenutzter Lizenzen nach 3 Monaten (Ziel: 0).
• KPI: Kosten pro Abteilung vs. Benefit (if measured, to find out where to invest more or cut).

Damit stellt S10 sicher, dass Copilot-Einführung auch aus wirtschaftlicher Sicht ein Erfolg wird. Governance fungiert hier als Spagat zwischen Controlling und IT: Es überwacht, dass Ressourceneinsatz (Lizenzen, CPU) sich lohnt und justiert die Verteilung nach realem Bedarf.

Jedes dieser zehn Szenarien (S1–S10) zeigt einen spezifischen Anwendungsfall, aber in der Praxis greifen sie ineinander. Zusammen decken sie die wichtigsten Felder ab, um Copilot in einem Unternehmen ganzheitlich zu steuern: Von streng vertraulichen Daten über externe Zusammenarbeit bis hin zur Wirtschaftlichkeit. Für jedes Szenario wurden konkrete Ziele, Risiken, Kontrollen und Messgrößen benannt – diese kann man in einem Risikoregister (siehe Kap. 9) und Maßnahmenkatalog einpflegen, um die Umsetzung nachzuverfolgen.

Durch das Durchspielen solcher Szenarien stellt die Organisation sicher, dass sie vorbereitet ist und Copilot nicht naiv einführt, sondern bewusst und kontrolliert.

Praxistipps am Ende von Abschnitt 6:
– Eigene Szenarien priorisieren: Nicht jedes Unternehmen hat alle obigen Szenarien gleich relevant. Erstellen Sie Ihre Top-5 oder Top-10 Liste, die Ihre Branche und Unternehmenssituation widerspiegelt, und fokussieren Sie Governance-Ressourcen darauf zuerst.
– Szenarien in Schulungen nutzen: Verwandeln Sie diese Szenarien in kleine Use Case Trainings. Mitarbeiter verstehen Richtlinien besser, wenn sie in Kontext gesetzt werden („Was wäre, wenn ein Externer…? Hier unsere Regel!“).
– Regelmäßige Überprüfung: Mindestens jährlich sollte das Governance-Team prüfen, ob neue Szenarien entstanden sind (z. B. neue Regulierung oder neuer Einsatzbereich von Copilot) und die Liste entsprechend ergänzen. Governance ist kein statisches Konstrukt – es muss sich an echte Nutzungssituationen anpassen.

7. Einführung & Roadmap

7.1 Startbedingungen, Vorprüfung, Risiko- und Datenschutz-Bewertung

Bevor Microsoft 365 Copilot in einem Unternehmen eingeführt wird, müssen die Startbedingungen sorgfältig geprüft werden. Ein unvorbereitetes Loslegen könnte zu Chaos oder Rückschlägen führen. Wichtige Schritte in dieser Phase:

• Bestandsaufnahme & Readiness-Check: Zunächst wird erhoben, welche technischen und organisatorischen Voraussetzungen bereits erfüllt sind. Gibt es z. B. schon eine Data Classification? Wie reif ist das vorhandene IT-Governance-Modell? Sind die notwendigen Lizenzen beschafft? Ein Readiness Assessment könnte in Tabellenform festhalten, welche Anforderungen nötig sind (MFA implementiert, Sensitivity Labels ausgerollt, Betriebsrat informiert etc.) und den Status (erfüllt/offen). Nur wenn die kritischen Must-haves auf „erfüllt“ stehen, sollte man weitergehen. Dazu gehört auch die Entscheidung, ob eine Testumgebung eingerichtet wird (falls Microsoft einen Test-Tenant oder Trial bietet – meist schwierig bei Copilot, aber man könnte Pilot in Produktion mit kleinem Scope machen).
• Business Case & Stakeholder-Buy-in: In den Startbedingungen muss klar sein, warum man Copilot einführt. Hier fließt die wirtschaftliche Betrachtung (Kap. 2.4) ein: Es sollte intern kommuniziert werden, welchen Nutzen man erwartet und welche Kosten aufgerufen werden. Alle relevanten Stakeholder – IT, Fachbereiche, Datenschutz, Betriebsrat, Management – sollten an Bord sein, bevor man wirklich startet. Eventuell hilft ein Management-Entscheidungsvorlage, die vom CIO eingebracht wird und vom Vorstand abgesegnet: Darin Ziele, grober Fahrplan, Investitionsrahmen und Governance-Prinzipien. Das formalisiert den Start.
• Risikobewertung & Datenschutz-Folgenabschätzung: Ganz wesentlich: Risikoanalyse vorab (Kap. 2.2 und 2.3 detailiiert). Diese sollte spätestens jetzt finalisiert werden. Insbesondere die Datenschutz-Folgenabschätzung (DSFA) nach DSGVO Art. 35: Darin identifiziert man potenzielle hohe Risiken für persönliche Daten (z. B. „Automatisierte Verarbeitung von Mitarbeiterchats -> Risiko Profilbildung“) und dokumentiert die Gegenmaßnahmen (z. B. Logging, Pseudonymisierung, Einwilligungen falls nötig). Der Datenschutzbeauftragte muss diese DSFA absegnen. Falls hohe Restrisiken bleiben, muss man ggf. die Aufsichtsbehörde konsultieren – das will man vermeiden durch gute Maßnahmen. Parallel eine generelle IT-Risikoanalyse: Man kann Copilot als eigenes Objekt in’s Risk Register aufnehmen, mit Risiken (aus Kap. 9) und deren Bewertung. Diese muss vom Risk Committee akzeptiert werden.
• Betriebsrat und interne Zustimmung: In Deutschland etc. ist es klug, schon vor dem Pilot den Betriebsrat zu informieren und einzubinden (ggf. sogar Zustimmung einzuholen, wenn z. B. Mitbestimmungstatbestand). Startbedingungen sind ideal, wenn es eine vorläufige Regelung oder gemeinsame Absichtserklärung mit dem Betriebsrat gibt. Zum Beispiel: „Wir starten Pilot unter folgenden Auflagen, anschließend Verhandlungen einer Betriebsvereinbarung.“ So sind keine Überraschungen für die Belegschaft zu befürchten und man hat Rückendeckung.
• Kommunikationsplan initial: Noch vor dem Start sollte es einen Plan geben, wie man allen Betroffenen vom Projekt erzählt. Das kann ein „Announcement“ sein: „Wir planen, KI-Assistent Copilot einzuführen – mit Bedacht.“ In dem man gleich die Governance-Absicht erwähnt („Sicherheit und Datenschutz bleiben gewährleistet“). Transparenz schafft Akzeptanz. Diese initiale Kommunikation kann Teil der Start-Checkliste sein.
• Pilot-Team aufstellen: In Startbedingungen ebenfalls: Die Kernbesetzung definieren. Wer führt (Produktverantwortlicher), wer ist im Projektteam (IT, Security, Compliance, repräsentative Fachbereiche), und wieviel Kapazität haben sie dafür? Ohne dedizierte Ressourcen scheitert es leicht, daher klären: z. B. 20% CISO-Zeit, 30% M365-Architekt etc. Notfalls externe Unterstützung budgetieren.
• Technische Einrichtungsvorbereitung: Das Team sollte vor dem eigentlichen Pilot bereits gewisse Konfigurationen vornehmen: Sensitivity Labels definieren, evtl. Graph-Indizes anlegen, Lizenzen im Admin Center zuweisen (erstmal nur ans Pilot-Team). Möglicherweise sind auch Updates oder Upgrades nötig: z. B. man braucht Office-Client in bestimmter Version, oder E5 Security-Paket – das alles vorab organisieren.
• Definition Pilotumfang (vorläufig): Als Startbedingung sollte klar sein, was im Pilot grundsätzlich enthalten sein wird. Z. B. „Wir pilotieren Copilot-Funktionen in Teams, Word, Outlook in der Abteilung Kundenservice und Finanzen, für 50 Benutzer.“ Das ist noch nicht der Pilotschritt selbst, aber die Abgrenzung muss von Anfang an als Zielbild existieren, damit alle wissen, worauf wir hinarbeiten.

Wenn diese Voraussetzungen erfüllt sind – sprich, das Fundament ist gelegt –, dann kann man das offizielle „Go“ für die Pilotierungsphase geben.

7.2 Pilotierung: Umfang, „Guardrails“, Metriken, Exit-Kriterien

Die Pilotphase ist kritisch: Hier sammelt man erste echte Erfahrungen in kontrolliertem Rahmen. Wichtig ist, sie gezielt zu steuern:

• Umfang und Teilnehmerkreis: Basierend auf Startplanung wählt man Pilot-User aus. Das sollten genug sein, um verschiedene Perspektiven zu kriegen (z. B. 5-10 pro beteiligtem Fachbereich), aber überschaubar (<100) damit Betreuungsaufwand machbar bleibt. Freiwilligkeit ist ideal: Tech-affine und neugierige Mitarbeiter mit positiver Einstellung – sie werden am ehesten aktiv testen und Feedback geben. Der Pilotumfang bestimmt auch, welche Copilot-Funktionen getestet werden: Vielleicht startet man mit Kernfunktionen (z. B. Word-Dokumente & Teams Chat), aber lässt Plugins etc. noch außen vor. Das wird im Pilotplan festgehalten.
• Definierte „Guardrails“ (Schutzplanken): Gerade im Pilot wird man bewusst Beschränkungen einbauen, um worst-case Szenarien zu vermeiden:
• Pilotnutzer erhalten evtl. spezielle Training und strengere Regeln.
• Evtl. wird DLP im Pilot extra konservativ eingestellt (lieber paar False Positives als Leak).
• Keine Externen im Pilot, also nur rein interne Interaktionen.
• Logging sehr detailliert, um im Zweifelsfall alles nachvollziehen zu können.
• Pilot-User evtl. NDA intern unterschreiben, dass sie keine KI-Ausgabe nach außen tragen (falls das relevant).
• Falls möglich, kann man auch „nur Dummy-Daten“ im Pilot nutzen in kritischen Bereichen.
• Kommunikativ: Pilot ist Lernphase – Fehler sind toleriert intern, aber bitte melden, nicht vertuschen.
• Metriken festlegen (Success & Risk metrics): Vor Pilot muss klar sein, was man messen wird, um am Ende zu entscheiden. Dazu definierte KPIs/KRIs (aus Kap. 6 ein paar wählen, z. B.:
• Produktivitätskennzahlen: „Zeitsparnis pro Aufgabe X im Schnitt“ – baseline vs. pilot.
• Akzeptanz: Umfrage bei Pilotusern „Würden Sie Copilot weiter nutzen wollen?“ (Quantitative und qualitativ).
• Sicherheits-/Compliance-Indikatoren: Anzahl Verstöße oder incidents (DLP triggered?).
• Performance Indikatoren: evtl. technische, wie Antwortzeiten, reliability.

Diese Metriken sammelt man über die Pilotphase.

• Pilot-Unterstützung: Das Pilot-Team muss eng mit Nutzern im Austausch sein. Mögliche Maßnahmen: Wöchentliche Feedback-Calls, Chat-Kanal für Pilotuser zum Fragen oder Probleme melden, vielleicht sogar vor-Ort-Begleitung anfangs (Floorwalker). So kriegt man authentisches Feedback und kann justieren.
• Dokumentation laufend: Führen eines Pilottagebuchs: Was lief gut, welche Probleme tauchten auf (z. B. „Nutzer A hat aus Versehen interne Notiz in externen Chat gepostet – DLP hat aber blockiert, guter Test.“). Diese Erkenntnisse fließen später in Policies oder Konfiguration.
• Exit-Kriterien (Go/No-Go) für Ende Pilot:
• Diese sind im Voraus festgelegt, um objektiv zu entscheiden, ob man weiter eskaliert (Rollout) oder nicht.
• Könnten sein:
  • Nutzungsziele erreicht? (z. B. Pilotuser haben Copilot mind. X mal pro Woche genutzt, nicht nach 1 Tag liegen lassen).
  • Zufriedenheit: z. B. > 70% der Pilotuser möchten Copilot behalten.
  • Risikolage akzeptabel: Keine schwerwiegenden Zwischenfälle; ggf. minor issues beherrschbar mit Maßnahmen.
  • Regulatorische Freigabe: Datenschutz sagt „Pilot ok, keine Warnungen“.
  • Technische Stabilität: System hat keine Performanceprobleme bei der kleinen Last (z. B. Response times im Rahmen).
  • Betriebsrat Feedback: Falls Auflage war, Pilot durch Bericht dann BV – wenn das negativ, dann Stop.

Sollte ein Kriterium nicht erfüllt sein (z. B. viele Probleme aufgetreten), hat man je nach Schwere Optionen: – Verlängerung Pilot mit Änderungen (z. B. Nachschulung). – Abbruch bzw. Srop (wenn es unlösbare Probleme gibt). – Oder Scope-Anpassung (vielleicht noch nicht an alle ausrollen, nur an begrenzte).

• Evaluationsreport: Am Pilotende sollte ein schriftlicher Bericht vorliegen, der diese Metriken und Erfahrungen zusammenfasst. Darin auch Empfehlungen: „Wir sind bereit für Rollout, unter Voraussetzung X, Y“. Das wird dem Entscheidungsgremium (CIO, Steering Committee) vorgelegt.

Zusammenfassend: Die Pilotphase ist wie eine Generalprobe, wo man in kleinem Rahmen austestet. Mit den Guardrails sorgt man dafür, dass Fehler im Kleinen bleiben und daraus gelernt werden kann. Mit klaren Kriterien stellt man sicher, dass Emotionales („cool, ausrollen!“) gebändigt und fundiert entschieden wird.

7.3 Skalierung: Rollout-Wellen, Change-Management, Kommunikation

Angenommen, der Pilot war erfolgreich und der Startschuss für den breiteren Rollout wird gegeben – nun geht es um die planvolle Skalierung:

• Rollout in Wellen: Statt Big Bang für alle 5000 Mitarbeiter sofort, empfiehlt sich ein phasenweises Ausrollen. Kriterium für Wellen können Organisationseinheiten, Regionen oder Funktionsbereiche sein. Etwa:
• Welle 1: Wissensarbeiter in HQ (z. B. alle in Marketing & IT), vielleicht 20% der Belegschaft.
• Welle 2: dann weitere Abteilungen inklusive z. B. Produktion nahes Personal, falls relevant.
• Welle 3: restliche Belegschaft, z. B. Filialen, Außendienst, etc.
• Jeder Welle kann man kleine Pilot-artige Begleitung geben – nicht so intensiv wie initialer Pilot, aber doch Monitoring. Zwischen Wellen kann man bewusst Pausen lassen (z. B. 1 Monat) um nachzusteuern, falls z. B. doch vermehrt Supportanfragen kamen oder Polices adjustiert werden müssen.
• Change-Management und Schulung für Massen: Während Pilotuser eng betreut wurden, muss man nun die breite Masse vorbereiten:
• Kommunikation: Vor jeder Welle sollten die Betroffenen wissen, was auf sie zukommt. Am besten mehrstufig: E-Mail vom Management („Wir führen Copilot ein, das und das bringt es, wir haben es getestet, es gibt Policies…“), gefolgt von detaillierteren Infos (z. B. Link zum Intranet mit FAQ, Leitfäden).
• Schulungsmaterial: Nicht jeder kann individuelle Schulung bekommen. Hier nutzt man E-Learnings, Videos, Hands-on Guides. Möglicherweise entstehen kurze How-To Videos: „Copilot in Outlook: 5 Dinge, die Sie wissen müssen“, produziert intern oder via MS.
• Champions-Netzwerk: Man kann Power-User aus dem Pilot als „Champions“ ernennen in ihren Abteilungen – die sind erste Ansprechpartner für Kollegen, organisieren kleine Lunch&Learn Sessions. Das entlastet IT-Support.
• Helpdesk brieft sich: Der interne IT-Support muss auf häufige Fragen vorbereitet werden. Idealerweise erarbeitet man aus dem Pilot eine FAQ-Liste und trainiert die Support-Mitarbeiter darin. Mögliche Tickets: „Copilot reagiert nicht“, „Antwort war falsch – was tun?“, „Wie melde ich eine schlechte Antwort?“ etc.
• Kommunikation der Policies: Sehr wichtig, parallel zum Rollout muss allen die Nutzungsregeln (aus Kap. 4 und 6) bekannt gemacht werden. Z. B. ein kurzer „Do & Don’t“ Merkblatt oder Poster. Vielleicht kombiniert man es mit verpflichtender E-Learning-Abfrage: am Ende ein Quiz (5 Fragen: „Darfst du Patienteninfos in Copilot prompten? a) nur anonymisiert …“ etc.). So stellt man sicher, dass jeder Minimalkenntnis hat.
• Feedback-Kanäle offen halten: Auch im Rollout soll es Gelegenheiten geben, Feedback zu geben. Z. B. eine Yammer/Teams Community „Copilot Erfahrungsaustausch“ moderiert vom Governance-Team. Mitarbeiter können dort Tipps teilen oder Probleme ansprechen. Das fördert Akzeptanz und holt Verbesserungsansätze aus der Breite.
• Umgang mit Widerständen: Change-Management muss auch skeptische oder ängstliche Mitarbeiter adressieren. Manche haben vielleicht Datenschutzbedenken oder Angst, KI könnte Jobs ersetzen. Hier offensiv informieren (Betriebsrat kann mithelfen) und transparent sagen, wofür Copilot genutzt wird und wofür nicht (z. B. „Es beobachtet nicht eure Leistung.“). Eventuell gezielte Workshops mit den Gruppen, wo Ablehnung groß ist, um mitzunehmen.
• Externe Kommunikation (wenn relevant): Je nach Situation sollte man sich überlegen, ob Kunden oder Partner informiert werden müssen, dass man KI intern nutzt. Das kann im Minimalfall in der Datenschutzrichtlinie passieren („wir nutzen KI-Tools bei der Bearbeitung, aber selbstverständlich DSGVO-konform“). Oder offensiv im Marketing („Wir setzen neueste KI ein für noch besseren Service!“). Governance/Management muss diese Linie festlegen.
• Kontinuierliche Support-Evaluierung: Nach jeder Welle: war unser Support überlastet oder okay? Müssten wir in Welle 2 mehr Schulung vorweg schicken? etc. Agil anpassen: Bemerkt man z. B., dass in Welle 1 vor allem Fragen zum Datenschutz kamen, dann in Welle 2 Newsletter extra Fokus drauf legen.
• Tool-Freischaltungen an Wellen koppeln: Admin muss in richtigen Moment Lizenzen verteilen. Evtl. richtet man ein automatisches Onboarding: z. B. AAD-Gruppen pro Welle, Lizenzen zuweisen, Conditional Access etc. So hat man Kontrolle, dass z. B. Welle 2 erst ab einem Datum X wirklich Zugang hat.

Im Kern: Skaliertes Ausrollen erfordert intensives Change-Management. Anders als Pilot kann man nicht jeden an die Hand nehmen, daher gute Kommunikation, Standardtraining und Community-Effekte nutzen. Bei Resistenz: informieren, aber auch gewisse Pflichten (z. B. Policy-Quiz) einfordern.

7.4 Betrieb: Servicekatalog, Supportmodell, Incident/Problem/Change

Nach dem Rollout geht Copilot in den Regelbetrieb über. Nun muss es wie jeder IT-Service gemanagt werden (oft im Rahmen eines ITIL-orientierten Betriebsmodells):

• Servicekatalog & SLA: Copilot sollte offiziell Teil des IT-Serviceportfolios sein. Das bedeutet, es gibt eine Servicebeschreibung: welche Leistungen bietet Copilot (z. B. „KI-Assistenz in Office-Apps“), wer kann es nutzen (z. B. alle Wissensarbeiter mit M365 Lizenz E3), welche Verfügbarkeit wird angestrebt (wahrscheinlich wie M365 generell: 24/7, Cloud SLA 99,9%). Auch, was nicht abgedeckt ist (kein Garant für 100% korrekte Inhalte, etc., ggf. Disclaimer in Nutzer-Doku). Wenn interne SLA definiert, z. B. „Supportanfragen werden innerhalb von X Stunden bearbeitet.“
• Supportmodell: Festlegen, wer Support leistet auf 1st, 2nd, 3rd Level:
• First Level: normaler IT-Helpdesk (da kommen Fragen „Wie schalte ich Copilot in Excel an?“ oder „Ich sehe Copilot nicht – wieso?“ [vielleicht keine Lizenz oder falsche Region]).
• Second Level: Das M365 Admin/Betriebsteam oder spezialisierte KI-Supporter, die tiefere Probleme lösen oder an Microsoft eskalieren.
• Third Level: Microsoft Support (ein Azure OpenAI or M365 Copilot escalations).
• Alle Supporter brauchen Knowledge Base Artikel intern: z. B. „Häufige Copilot-Probleme und Lösungen.“ Das kann aus Pilot gewonnene Doku sein.
• Möglicherweise ein dedizierter Service Owner (wie der Product Owner, aber im Betrieb), der auch major incidents managt und Verbesserungen vorantreibt.
• Incident Management: Definiert, was ein Copilot-Incident ist:
• Technisch: Copilot Funktion fällt aus (z. B. Fehler in UI, oder Latenz >30s massenhaft). Prozedur: IT bekommt Alert (Microsoft 365 Admin Center Service Health), informiert Nutzer über z. B. Intranet-Status, und verfolgt MS Status bis gelöst.
• Sicherheitsincident: z. B. vermuteter Datenverlust. Dann greift Security Incident Response Plan (forensische Logs checken, beteiligte informieren etc., wie in generellem IRP).
• Content-Incident: KI gab falsche Info an Kunden -> Business Incident; hier vielleicht Root Cause Analysis (war Training Data schuld? Muss man den Prompt-Bibliothek ändern?).
• Es sollte klar sein: Incidents werden in Ticket-System erfasst, mit Priorität.
• Und definierte Eskalation: wenn e.g. Service down >4h -> mgmt Info.
• Problem Management: Wenn sich bestimmte Incident Muster ergeben („Copilot fällt jeden Montag 9h aus“ o.ä.), Problem-Management Board analysiert grundlegend, ggf. mit MS Support Root cause fixen. Oder inhaltlich: „Wir sehen immer wieder Halluzination bei Thema X“ -> Problem for content team to address (maybe feed the KI better data).
• Copilot being partly black box (the model) limits what we can fix, aber vlt. Workarounds: e.g. if it’s known that „RegEx patterns cause crash“ -> document or mitigate.
• Change Management:
• Copilot wird kontinuierlich geupdatet von Microsoft (Model-Updates, new features). Governance und IT müssen diese Changes bewerten:
  • Sind Policies betroffen (z. B. neue plugin store – muss man neu whitelisting anpassen).
  • Müssen Nutzer informiert werden („Now Copilot can do web search“ – falls previously off).
  • Test Changes in kleinem Umfang (vielleicht vor global on, erst Test with IT staff).
• Interne Changes: z. B. „Wir rollen nun Plugin X aus“ oder „Wir erhöhen Logging retention“ – diese sollten auch via Change Advisory Board (CAB) abgesegnet, weil könnten Nebeneffekte haben.
• Jede signifikante Änderung sollte nachverfolgt und dokumentiert werden (Changeticket mit Implementation and backout plan falls schief).
• Besonders: Integration with new systems (Graph connectors), those are major changes requiring risk review (so synergy with governance board).
• Kontinuierliche Serviceverbesserung:
• Sammeln von Service KPIs (wie bei 8.1) und in Betriebsmeetings diskutieren.
• Evtl. quartalsweise Nutzerrat (Power user Feedback).
• Planen von Feature Enablement: Wann erlauben wir es allen, das Whiteboard-Copilot modul zu nutzen? etc. in Roadmap.
• Input in MS product dev: partake in TechCommunity to voice demands (like „we need feature X to better govern“).
• Kollaboration mit Compliance im Betrieb:
• Achieving internal/external audits: Der Service Owner stets audit-bereit (Policydokumente zur Hand, logs parat).
• Jährliche Rezertifizierung: Adhere to any required recert (some companies do annual re-attestation that the service still meets controls).

Letztlich muss Copilot als neuer Service nahtlos ins bestehende IT-Betriebsmodell integriert werden. Nur so ist Langlebigkeit und Zuverlässigkeit gewährleistet. Anfangs mag es Sonderbehandlung kriegen, aber Ziel ist „Business as usual, albeit with special oversight“.

Phasenplan (Tabelle) – Einführung & Rollout

Wir fassen die Einführungs-Roadmap in einem tabellarischen Phasenplan zusammen:

Phase	Ziele	Deliverables	Dauer	Verantwortlich	Go/No-Go-Kriterien
1. Vorbereitung (Initiation)	– Ausgangslage analysieren (Readiness)<br>- Business Case und Governance-Konzept finalisieren<br>- Zustimmung aller Stakeholder einholen	– Projektauftrag/Business-Case-Dokument<br>- Risiko- und Datenschutzbewertung (DPIA)<br>- Kommunikationsplan für Pilot<br>- Governance-Richtlinien (Entwurf)	4–6 Wochen	CIO (Sponsor), Copilot-Product Lead<br>Mitwirkung: CISO, DSB, Betriebsrat, Fachvertreter	Go: Management genehmigt Projekt + Budget;<br>DSB hat keine unbehebbaren Einwände;<br>Betriebsrat signalisert Zustimmung zum Pilot.
2. Pilotierung	– Copilot in kontrollierter Umgebung testen<br>- Governance-Policies verfeinern in der Praxis<br>- Nutzerfeedback und Nutzenmessung erheben	– Pilot-User geschult und eingerichtet (z.B. 50 Nutzer)<br>- Wöchentliche Erfahrungsberichte/Protokolle<br>- Zwischenauswertung (Nutzung, Feedback, Zwischenfälle)<br>- Anpassungen an Richtlinien/Konfiguration nach Bedarf	6–8 Wochen	Copilot-Product Lead (Pilotmanager)<br>Mitwirkung: Pilotnutzer, IT-Support, CISO-Team	Go: Metriken laut Pilot-Erfolgskriterien erfüllt (z.B. >70% Zufriedenheit, keine kritischen Incidents);<br>Governance-Konzept bewährt sich (nur geringf. Anpassungen nötig). No-Go: Schwere Probleme (Datenleck, Ablehnung) -> Projektstopp oder Verlängerung Pilot mit Maßnahmen.
3. Rollout Welle 1	– Ausweitung auf erste größere Nutzergruppe<br>- Sammeln weiterer Erkenntnisse unter Last<br>- Etablierung des Support-Modells im Echtbetrieb	– Copilot für definierte Abt./Standorte aktiviert (z.B. 500 Nutzer)<br>- Breitenschulung durchgeführt (Trainingsmaterial, FAQs live)<br>- Helpdesk in Betrieb für Copilot-Anfragen<br>- Bericht nach Welle 1 (Lessons Learned, evtl. Anpassungen)	4 Wochen (nach Pilot)	IT-Betrieb/Service Manager (Rollout-Koord.)<br>Mitwirkung: Schulungsteam, Abteilungsleiter der Welle 1	Go (zu Welle 2): Support kommt mit Volumen klar;<br>Keine unerwarteten neuen Risiken aufgetaucht;<br>Erste KPI-Trends positiv (Nutzung hoch, Fehler gering).
4. Vollrollout & Betriebsübergang	– Copilot für restliche Belegschaft verfügbar machen<br>- Übergang vom Projekt- in den Regelbetrieb abschließen<br>- Langfristige Governance-Verankerung sicherstellen	– Rollout an alle verbleibenden Nutzergruppen (Welle 2, 3 … abgeschlossen)<br>- Abschlussbericht der Einführungsphase (Soll-Ist, Nutzen, Empfehlungen)<br>- Betriebshandbuch aktualisiert mit Copilot (Support, Monitoring etc.)<br>- Ggfs. Betriebsvereinbarung final unterschrieben	8–12 Wochen (je nach Wellen)	IT-Service Owner (übernimmt dauerhaft)<br>Mitwirkung: CIO, CISO, DSB, Betriebsrat, alle Bereichsleiter	Go-Live endgültig: Alle Nutzer produktiv mit Copilot, Service in Katalog aufgenommen.<br>No-Go (Stop Rollout): Nur bei unerwarteten gravierenden Problemen in Welle 2 (dann ggf. Rollout verlangsamen oder anpassen). Kriterien: keine ungeklärten Compliance-Vorfälle, Zustimmung Betriebsrat final vorliegt.

In diesem Phasenplan sieht man klar die kontrollierten Entscheidungs- und Übergabepunkte. Die Phase „Vollrollout & Betriebsübergang“ markiert das Ende des Projekts und den Beginn des Normalbetriebs, woraufhin Metriken und KPIs (Kap. 8) fortlaufend verfolgt werden.

Checkliste „Go-Live-Reifegrad“ (Abnahme vor breitem Rollout)

Zum Ende der Pilotphase bzw. vor dem großen Go-Live sollte geprüft werden, ob alles bereit ist. Eine Checkliste kann helfen, den Reifegrad zu bewerten:

• [ ] Abgeschlossene Pilotziele: Die Pilotphase hat die definierten Erfolgskriterien erreicht (Nutzerakzeptanz nachgewiesen, keine unadressierten Sicherheitsrisiken mehr offen, qualitatives Feedback positiv).
• [ ] Geschulte Anwenderbasis: Es liegt ein Schulungskonzept für alle zukünftigen Nutzer vor. Materialien (Leitfäden, FAQs, E-Learning) sind erstellt und verteilt. Welle-1-Nutzer haben ihre Trainings absolviert (Nachweisquote z. B. > 95%).
• [ ] Governance-Organisation etabliert: Das dauerhafte Copilot-Governance-Team (Rollen aus Kap 3) ist benannt und einsatzbereit. Zuständigkeiten für Support, Incident Management, Monitoring und Policy-Updates sind klar zugewiesen.
• [ ] Richtlinien final verabschiedet: Alle Policies (Nutzungsrichtlinie, Sicherheitsvorgaben, Datenschutzregeln) sind formal genehmigt (von Geschäftsleitung und ggf. Betriebsrat) und an die Belegschaft kommuniziert. Jeder Nutzer hat die Möglichkeit erhalten, die Regeln zur Kenntnis zu nehmen (z. B. durch Informationsmail mit Bestätigung).
• [ ] Technische Plattform „go-live ready“: Alle erforderlichen technischen Maßnahmen aus Kapitel 5 sind umgesetzt und getestet. Insbesondere: Audit Logging läuft stabil, DLP-Regeln greifen wie erwartet (Testfälle erfolgreich), Berechtigungen/Labels sind auf neuestem Stand, und das Monitoring-Dashboard zeigt Pilot-Daten korrekt an.
• [ ] Support- und Betriebskonzepte getestet: Der IT-Support hat im Pilot echte Anfragen bearbeitet und fühlt sich vorbereitet für mehr Nutzer. Eskalationsprozesse (z. B. an Microsoft Support) wurden im Pilot mind. einmal durchgespielt und funktionierten. Der Incident Response Plan für KI-Vorfälle ist final abgestimmt.
• [ ] Kommunikationsplan Go-Live: Die Ankündigung des breiten Rollouts ist formuliert. Alle Stakeholder wissen, wann ihre Bereiche an der Reihe sind. Inhalte der Kommunikation decken Zweck, Nutzen, Regeln und Kontaktstellen bei Fragen ab.
• [ ] Lizenz- und Budgetfreigabe: Es sind ausreichend Lizenzen für die nächste Rollout-Welle vorhanden und vom Hersteller zugeteilt. Das Budget für die laufenden Kosten ist in der IT-Finanzplanung berücksichtigt. (Ggf. hat Controlling finalen ROI-Check des Piloten abgenickt als Basis für Investitionsfreigabe.)
• [ ] Datenschutz-Compliance sichergestellt: Der Datenschutzbeauftragte hat keine offenen Punkte mehr. Die Dokumentation (DPIA) ist abgeschlossen und wurde – falls erforderlich – an die Aufsichtsbehörde gemeldet oder von dieser ohne Einwände zur Kenntnis genommen.
• [ ] Betriebsrat onboard: Falls eine Betriebsvereinbarung erforderlich war, ist diese abgeschlossen. Alternativ liegt eine schriftliche Zustimmung oder Protokollnotiz des Betriebsrats vor, welche die Einführung abdeckt. Mitarbeitervertretungen sind über den Rollout informiert und unterstützen die Einführung kommunikativ.
• [ ] Risiko-Restbewertung akzeptiert: Das Management (CIO/CISO und ggf. Risiko-Board) hat die zum Go-Live verbleibenden Restrisiken abgenommen. Etwaige „gelbe“ Risiken haben definierte Maßnahmen und Verantwortliche zur weiteren Beobachtung – es gibt keine „roten“ (inakzeptablen) Risiken mehr.
• [ ] Lessons Learned eingebunden: Alle wichtigen Erkenntnisse aus der Pilotphase sind in die endgültigen Prozesse eingeflossen. (Beispiel: Pilot zeigte Schulungsbedarf X – dieser wurde vor dem Rollout adressiert). Es besteht Konsens im Projektteam, dass man gut vorbereitet ist.

Wenn all diese Punkte mit „Ja“ bzw. erledigt abgehakt werden können, ist das Go-Live mit breiter Ausrollung guten Gewissens zu verantworten. Sollten einzelne Punkte „Nein“ ergeben, muss geklärt werden, ob dies ein Show-Stopper ist oder durch kurzfristige Maßnahmen behoben werden kann, bevor der Startschuss fällt.

Mit diesem strukturierten Vorgehen – von der Vorprüfung über Pilot bis zum gestuften Rollout – stellt man sicher, dass die Einführung von Copilot nicht zum Sturzflug wird, sondern zu einem kontrollierten, erfolgreichen Change im Unternehmen.

(Praxistipps am Ende von Abschnitt 7:)
– Pilot-Erfolge feiern: Nutzen Sie die Ergebnisse der Pilotphase aktiv in der internen Kommunikation. Zeigen Sie z. B. eine kleine „Success Story“ eines Pilotnutzers („Copilot hat mir geholfen, X Stunden zu sparen…“). Das schafft Vorfreude bei den Nächsten und holt Skeptiker ab.
– Überlastung vermeiden: Planen Sie Puffer zwischen den Rollout-Wellen. Lieber etwas langsamer skalieren, dafür Zeit haben, Feedback aufzunehmen und das Support-Team verschnaufen zu lassen. Ein überstürzter Rollout kann das Projektimage beschädigen, wenn Support/Qualität darunter leiden.
– Flexibel bleiben: Trotz aller Planung – bleiben Sie agil. Wenn sich z. B. herausstellt, dass ein bestimmter Bereich Copilot doch früher dringend braucht, während ein anderer noch Vorbehalte hat, passen Sie die Wellen an. Die Roadmap ist ein Leitfaden, kein starrer Gesetzestext.
– Erfolg messen und sichtbar machen: Bereits im Rollout (Phase 3) können erste KPIs berichtet werden (z. B. „In der ersten Woche haben 80% der freigeschalteten Nutzer Copilot ausprobiert.“). Teilen Sie positive Trends regelmäßig mit dem Management und den Stakeholdern. So bleibt die Unterstützung hoch und alle sehen den Mehrwert, den die Einführung bringt.

8. Messen, Steuern, Verbessern

8.1 KPIs und KRIs (Key Risk Indicators) für Copilot-Governance

Um Copilot-Governance effektiv zu steuern, müssen wir die richtigen Kennzahlen erfassen – sowohl Leistungskennzahlen (KPIs) als auch Risikoindikatoren (KRIs). Diese Kennzahlen geben objektives Feedback darüber, ob die gewünschten Nutzen eintreten und die Risiken im Griff sind.

Wichtige KPIs könnten sein:

• Nutzungsgrad von Copilot: Etwa der Prozentsatz aktiver Benutzer pro Woche oder die durchschnittliche Anzahl an Copilot-Interaktionen pro Benutzer und Tag. Ein hoher Nutzungsgrad deutet darauf hin, dass die Mitarbeiter den Dienst annehmen und damit (hoffentlich) produktiver sind. Z. B. „80% der lizenzierten Nutzer haben Copilot in den letzten 7 Tagen mindestens einmal verwendet“ wäre ein starker Wert. Ein niedriger Wert (<30%) könnte signalisieren: Schulungsbedarf oder Akzeptanzprobleme.
• Produktivitätsgewinn: Dies ist schwieriger direkt zu messen, aber man kann proxys finden. Z. B. im Kundenservice: durchschnittliche Bearbeitungszeit eines Tickets vor und nach Copilot-Einführung. Oder Anzahl erstellter Dokumente/Berichte pro Mitarbeiter. Möglicher KPI: „Reduktion der Durchlaufzeit für Angebotsdokumente um X% dank KI-Assistenz“. Hier kann man Umfragen nutzen („Wie viel Zeit sparen Sie durch Copilot pro Woche?“) um einen quantitativen Wert zu erhalten.
• Qualitätskennzahlen: Z. B. Anteil der Copilot-Antworten, die ohne Änderungen weitergenutzt werden konnten. Oder Error Rate: Anzahl der Fälle, in denen Copilot nachweislich falsche Infos geliefert hat (dann will man das gering halten). Ein Proxy: „Prozentsatz der KI-generierten Inhalte, die im Review durch Fachexperten korrigiert werden mussten“. Sinkt dieser über die Zeit, verbessert sich die Qualität / Prompt-Bibliothek etc.
• Support-Volumen: Anzahl der Helpdesk-Tickets im Zusammenhang mit Copilot pro 100 Nutzer. Anfangs sicher höher, sollte mit Reifung sinken. Ein KPI könnte sein: „Durchschnittlich < 0,2 Supportanfragen pro Nutzer und Monat 3 Monate nach Rollout“. Dies zeigt, ob der Dienst selbsterklärender wird und reibungslos läuft.
• Schulungsquote: Prozent der Nutzer, die die bereitgestellten Trainings absolviert haben. Das ist kurzfristig während Rollout relevant – Governance kann damit Erfolg des Change-Management sehen. Ziel: nahe 100%. Ggf. auch: Ergebnis der Wissensüberprüfung (Quiz-Scores).
• Einhaltung von Prozessen: Ein Governance-spezifischer KPI: „Durchgeführte Policy-Reviews / Rezertifizierungen vs. geplant“ (z. B. „100% der Copilot-Richtlinien wurden nach 12 Monaten auf Aktualität geprüft“). Das misst, ob Governance diszipliniert betrieben wird.
• ROI-Kennzahl: Im Business Case definiert, z. B. „Verhältnis geschätzter monetärer Nutzen zu Kosten“. Wenn man produktivitätsgewinn in Stunden * Personalkosten vs. Lizenz+Implementierungskosten rechnet, erhält man ROI. Ein KPI: ROI > 1 (über 100%) ab Jahr 2 zum Beispiel.

Parallel dazu Key Risk Indicators (KRIs), die signalisieren, ob Risiken zunehmen oder abnehmen:

• Daten-Leakage-Vorfälle: Anzahl/wöchentliche Rate automatisiert blockierter oder manuell gemeldeter potenzieller Datenabflüsse über Copilot. Z. B. „DLP-Blockierungen mit Bezug zu Copilot pro Monat“. Wenn dieser Indikator steigt, ist das Alarm (vllt. Nutzer versuchen unsicheres, oder Settings zu lax).
• Compliance Incidents: Dazu zählen z. B. entdeckte Verstöße gegen die Nutzungsrichtlinie (z. B. Mitarbeiter hat doch sensible Daten eingegeben, Halluzination ging an Kunden etc.). Ein KRI könnte sein: „Zahl der meldepflichtigen Datenschutzvorfälle im Zusammenhang mit Copilot“. Ideal bleibt das null. Sollte hier ein Fall auftreten, zeigt das dringenden Handlungsbedarf an (Training nachbessern o.Ä.).
• Modell-/System-Ausfälle: Z. B. „Copilot-Serviceverfügbarkeit unter SLA“ – falls Copilot öfter ausfällt, riskant, weil Leute Workarounds suchen (vielleicht unsichere Tools). Also Indikator: Downtime in Min/Monat. Steigt das, droht „Shadow-AI“ Nutzung extern, Risiko.
• Kostenüberschreitung: KRI: „Monatliche Copilot-Kosten vs. Plan (Abweichung in %)“. Wenn Kosten z.B. 50% über Plan liegen und Nutzen unklar, droht Budgetkürzung -> risk for continuity.
• Regulatorische Änderungen oder Auditanforderungen: Das ist qualitativ: KRI könnte sein „Anzahl neuer regulatorischer Anforderungen, die Copilot betreffen, in Beobachtungsliste“. Steigt das (z. B. AI Act kommt), muss Governance reagieren, sonst Non-compliance.
• Nutzerverhalten-Risiko: Evtl. „Anteil Nutzer, die gegen Do’s & Don’ts verstoßen laut Log-Analyse“ – hier könnte man aus Audit-Log Indikatoren filtern (z. B. Prompt enthielt Massen-Personendaten). Wenn >0, etwas läuft falsch.

Die konkreten KPIs und KRIs sollten so gewählt werden, dass sie messbar und zeitlich verfolgbar sind. Nicht zu viele – man will das Dashboard übersichtlich halten. Wichtig auch: Jedes hat einen Owner (dazu gleich im Reporting).

Die Werte dieser Kennzahlen werden regelmäßig erhoben (automatisiert wo möglich) und dem Governance-Gremium präsentiert. So sieht man Trends: z. B. Nutzungsgrad steigt schön (gut), aber DLP-Alerts nehmen auch zu (schlecht) – dann müsste man genauer hinsehen, evtl. Nachschulung oder strengere Settings.

KPIs und KRIs schlagen damit die Brücke zwischen dem abstrakten Governance-Anspruch und der Realität im Betrieb. Sie liefern die Grundlage für kontinuierliche Steuerung (Kap. 8.3) und stellen sicher, dass das Management Fakten zur Hand hat, ob Copilot „im grünen Bereich“ läuft.

8.2 Reporting: Management-Dashboards, Regelmeetings, Audit-Trail

Bloße Kennzahlen reichen nicht – sie müssen in Reports und Meetings geleitet werden, um Wirkung zu entfalten:

• Management-Dashboard: Ein übersichtliches Dashboard, zugreifbar für relevante Führungskräfte (CIO, CISO, evtl. Geschäftsleitung), zeigt die wichtigsten KPIs/KRIs auf einen Blick. Dieses Dashboard könnte z. B. monatlich aktualisiert werden und umfasst Graphen und Ampeln:
• Nutzungsgrad vs. Ziel (z. B. 75% -> grüner Bereich, Ziel 70%).
• Anzahl Vorfälle (z. B. 1 Data Incident -> gelb, weil gering, aber vorhanden).
• ROI-Schätzung, fortgeschrieben, etc.
• Ampeln für „Regulatorik“ (grün = im Compliance, gelb = neue Anforderungen im Anflug, rot = Problem).
• Vielleicht Benchmark-Vergleiche, falls man hat (z. B. wie schneiden wir vs. Industrie bei KI-Nutzung? Wäre advanced).
• Dieses Dashboard kann mit Tools wie Power BI aus Audit-Logs, ServiceNow-Tickets etc. gespeist werden.
• Regelmeetings & Gremien:
• Auf operative Ebene: Das Copilot-Governance-Kernteam (Produktverantwortlicher + Sicherheits/Compliance-Vertreter) trifft sich z. B. zweiwöchentlich, um aktuelle Betriebsfragen zu besprechen. Hier schaut man kurz auf die Zahlen: any spikes? Offene Anträge (Plugins)? Incidents? und plant Maßnahmen.
• Auf Management-Ebene: Ein Steering Committee oder AI-Governance-Board könnte quartalsweise tagen. Teilnehmer: CIO, CISO, DSB, ggf. Business-Leads. Dort wird das oben genannte Dashboard präsentiert, Trends diskutiert und strategische Entscheidungen gefällt (z. B. „Ausrollen auf weitere Länder? Budget anpassen? neue Policies aufgrund geänderter Gesetzeslage?“).
• Reporting an Vorstand/Aufsichtsrat: Je nach Bedeutung kann Copilot in den generellen IT-Quartalsreport aufgenommen werden. Einige Kennzahlen oder besondere Ereignisse werden dann hochgemeldet. So bleibt Top-Management involviert und hat Sicherheit, dass alles unter Kontrolle ist.
• Audit-Trail & Dokumentation:
• Alle wichtigen Governance-Aktivitäten sollten nachvollziehbar dokumentiert sein, um im Falle interner oder externer Audits vorzeigbar zu sein. Dazu zählen:
  • Protokolle der Governance-Meetings (Entscheidungen, diskutierte Risiken).
  • Übersicht der KPIs über Zeit (z. B. ein Jahr historisch, um Entwicklung zu zeigen).
  • Nachweise von Kontrollen: z. B. Ergebnisberichte der DLP-Überprüfungen, Red-Team-Reports, Pilot-Abschlussbericht.
  • Aktualisierte Richtliniendokumente mit Versionsstand.
  • Records von Schulungsmaßnahmen (wer hat wann was trainiert).
  • Technische Konfig-Dumps (z. B. Export der DLP-Regelkonfiguration, um zeigen zu können „ja, wir haben Patterns X und Y abgedeckt“).
• Diese Unterlagen bilden den Audit-Trail. Sollte z. B. ein externer Prüfer (DSB, ISO27001 Auditor) fragen „Wie stellen Sie denn KI-Compliance sicher?“, kann man diesen Dokumentenordner zücken und Schritt für Schritt aufzeigen: Hier unsere Policies, hier Monitoring, hier Reaktion auf Vorfälle etc.
• Automatisiertes Monitoring:
• Über das menschliche Reporting hinaus kann man Tools einsetzen, die z. B. bei Grenzwertüberschreitungen automatisch E-Mails schicken. Beispiel: Wenn KRI „DLP Incidents“ -> gelb, geht Mail an CISO + DataGov-Lead mit Hinweis.
• Oder ein wöchentliches Bot-Report im Teams-Channel „Copilot Gov“: „Letzte Woche 0 Sicherheitsvorfälle, Nutzungsgrad 82% (↗5%), 2 neue Plugin-Anfragen“. Damit ist das Team ohne großes manuelles Hin und Her im Loop.
• Kommunikation an Nutzer: Reporting beschränkt sich nicht nur nach oben; auch Anwender sollten gewisse Infos bekommen, als Feedback-Schleife:
• Z. B. eine interne Infografik „Copilot 100 Tage – das haben wir erreicht: 10k Prompts, 500 Dokumente erstellt, 0 Incidents, 95% finden es hilfreich“. Das motiviert und zeigt, dass Governance transparent ist.
• Bei Problemtrends (z. B. „Wir bemerken leider, dass öfter vertrauliche Daten falsch genutzt werden“) kann man in einem Newsletter die gesamte Belegschaft nochmal sensibilisieren, ohne Einzelne zu schelten.

Fazit: Ein systematisches Reporting schafft Vertrauen und steuerbare Verhältnisse. Das Management will nachvollziehen können, ob Copilot eher Nutzen bringt oder Risiken. Mit Dashboards und Meetings wird das gegeben. Und im Audit-Fall kann man schwarz auf weiß zeigen, dass man seiner Governance-Pflicht nachkommt – was ungemein wertvoll ist, sollte einmal etwas schiefgehen (man zeigt dann, man hatte Prozesse und Kennzahlen – man hat nicht fahrlässig gehandelt).

8.3 Kontinuierliche Verbesserung: Reviews, Rezertifizierungen, Lessons Learned

Governance ist ein fortlaufender Prozess – gerade mit einer sich rasant entwickelnden KI-Technologie. Daher muss man sich zu einer Kultur der kontinuierlichen Verbesserung verpflichten:

• Regelmäßige Policy- und Controls-Reviews: Mindestens jährlich (besser halbjährlich) sollte das Governance-Team alle Richtlinien und Maßnahmen auf Aktualität prüfen. Fragen dabei:
• Passen die Policies noch zur Praxis oder gibt es Grauzonen, die neu geregelt werden müssen (etwa weil neue KI-Funktionen hinzu kamen)?
• Haben sich Geschäftsprozesse geändert, die andere Einstellungen erfordern?
• Sind die angenommenen Risiken noch dieselben, oder sind neue Risiken aufgetaucht?
• Ein Beispiel: Anfangs war Websuche abgeschaltet; vielleicht hat man inzwischen sichere Filter entwickelt und könnte es doch zulassen – dann Policy anpassen.
• Diese Reviews werden protokolliert und Änderungen angestoßen (Change Management).
• Rezertifizierungen: In Bereichen wie Informationssicherheit kennt man „Rezertifizierung“ von Zugriffsrechten – ähnlich kann man es hier machen:
• Z. B. alle 12 Monate müssen die Bereichsleiter bestätigen, dass die Copilot-Zugänge in ihrem Team noch nötig sind (Lizenz-Review).
• Oder Admins rezertifizieren, dass Konfigurationen dem Standard entsprechen (keine ungewollten Settings verändert).
• Auch die Governance-Org selbst: einmal im Jahr durchläuft man, ob die Rollen noch mit richtigen Personen besetzt sind (Personalwechsel?), ob der RACI angepasst werden sollte.
• Falls es externe Zertifizierungen gibt (ISO, TISAX): nach Abschluss Rollout Integration in diese Audits – z. B. Copilot Governance als Teil des ISO27001 Kontrollen – das zwingt dann zu Rezertifizierung im Rhythmus der Norm.
• Lessons Learned Kultur:
• Nach bestimmten Ereignissen immer nachbereiten: z. B. nach jedem echten Incident eine Root Cause Analyse mit Lessons-Learned-Dokument. Was lief schief? Welche Lücke im Prozess? Dann Aktion definieren (bspw. „DLP-Regel erweitern“, „Mitarbeiter-Schulung intensiveren“) und nachverfolgen, ob umgesetzt.
• Auch nach dem ersten Jahr Betrieb: ein Workshop mit allen Beteiligten: Was hat unser Governance-Modell gut gemacht, wo knirscht es? Dieses Feedback einarbeiten.
• Man kann auch extern lernen: Austausch mit anderen Firmen (in Foren, User Groups) – wie lösen die Problem X? Evtl. übernimmt man Best Practices.
• Und natürlich aus dem System selbst: KI generiert vlt. neuen Use Case, den man noch gar nicht hatte – wenn den ein Mitarbeiter meldet, könnte man den aufnehmen (z. B. „Viele nutzen Copilot jetzt zum Programmieren, wir sollten Richtlinie zu Code-Ausgaben definieren“).
• Anpassung an regulatorische Änderungen: Governance-Review ist fest getaktet, aber es kann ad-hoc nötig sein, wenn z. B. neue Gesetze (AI Act EU) relevant werden. Dann sofort eine Task Force bilden, Gap-Analyse: Erfüllen wir die neuen Pflichten? Falls nein, Roadmap anpassen. Hier zahlt sich aus, dass Governance nicht statisch war – man kann schnell nachsteuern.
• Innovation und Erweiterung: Kontinuierliche Verbesserung heißt nicht nur Fehlerfix, sondern auch Chancen nutzen:
• Vielleicht hat Microsoft neue Copilot-Features herausgebracht – Governance sollte offen prüfen, ob diese nutzenstiftend und sicher sind. Wenn ja, planen wie einführen.
• Oder Ideen der Nutzer – eventuell könnte man intern eigene Plugins entwickeln, z. B. einen Copilot-Agent für das firmeneigene Intranet. Governance kann so etwas unter kontrollierten Bedingungen fördern (Pilot solcher Innovationsprojekte initiieren).
• So bleibt das Toolset modern und das Unternehmen schöpft das Potential voll aus – was ja initiales Ziel war.
• Dokumentation und Versionierung: Alle Policy-Updates, neue Prozesse, geänderte Metriken etc. müssen sauber dokumentiert und versioniert werden (für Nachvollziehbarkeit, s.o. Audit-Trail). Vielleicht führt man ein „KI-Governance-Handbuch“, das einmal im Jahr neu aufgelegt wird (Version 2.0 etc.).

Zusammengefasst, in der Betriebsphase darf man nicht in Selbstzufriedenheit verfallen. KI-Anwendungen werden sich weiterentwickeln – Governance muss Schritt halten. Der Zyklus Plan-Do-Check-Act gilt hier genauso: man plant Richtlinien (Plan), führt sie ein (Do), misst via KPIs (Check), und passt an (Act). Somit wird Copilot-Governance Teil des kontinuierlichen Verbesserungsprozesses des gesamten Unternehmens.

Zum Abschluss dieses Kapitels noch eine Tabelle mit exemplarischen KPIs:

KPIs-Tabelle

Kennzahl	Definition	Zielwert	Messmethode	Frequenz	Owner
Nutzeraktivität	Anteil der berechtigten Benutzer, die Copilot mind. 1× pro Woche aktiv nutzen.	≥ 75% der lizenzierten Nutzer nach 3 Monaten Rollout.	Auswertung der Copilot-Service-Logs (distinct users per week / total users *100).	Monatlich	IT Service Owner (Copilot)
Durchschn. Anfragen pro Nutzer	Durchschnittliche Anzahl von Copilot-Abfragen pro aktivem Benutzer pro Arbeitstag.	Richtwert: 5–10 Abfragen/Tag (Erwartung je nach Aufgabengebiet).	Log-Analyse: Summe aller Prompts pro Tag / Anzahl aktiver Nutzer.	Monatlich	Data Analyst (Governance-Team)
Zeitersparnis (geschätzt)	Durchschnittlich eingesparte Bearbeitungszeit pro Mitarbeiter und Tag durch Copilot-Unterstützung.	+15% Produktivitätsgewinn (im ersten Jahr, steigend in Folgejahren).	Befragung ausgewählter Nutzer + Vergleich von Prozessdurchlaufzeiten vor/nach Einführung (Stichprobenmessung).	Quartalsweise	Business Process Manager
Inhaltsqualität	Anteil der KI-generierten Inhalte, die ohne wesentliche Korrekturen übernommen werden konnten.	≥ 90% (bei Routine-Inhalten; bei komplexen Dokumenten Ziel separat definieren, z. B. 70%).	Umfrage unter Teamleitern / Reviewern: Quote der Ausgaben, die sie freigeben konnten vs. zurück zur Überarbeitung.	Quartalsweise	Qualitätsmanager (Fachbereich)
DLP-Vorfälle	Zahl der durch DLP geblockten oder gemeldeten Versuche, sensible Daten via Copilot auszugeben oder zu versenden.	0 kritische Vorfälle; ≤ 5 geringfügige pro Monat (nach Einführungsphase).	DLP-Systemreport: gefiltert nach Copilot-Kontext (Tags in Alerts).	Monatlich	CISO / Security Operations
Supportanfragen	Anzahl der Helpdesk-Tickets im Zusammenhang mit Copilot pro 100 Nutzern.	< 2 Tickets pro 100 User und Monat nach Stabilisierung (3 Mon.).	IT-Ticketsystem: Schlagwort „Copilot“ oder Kategorie auswerten; Verhältnis zur Benutzerzahl.	Monatlich	IT-Support-Leiter
Regel-Compliance	Anteil der überprüften Copilot-Interaktionen, die vollständig konform mit den Policies waren (keine verbotenen Inhalte, richtige Freigaben etc.).	100% (Ziel: keine Policyverstöße)<br>(Toleranzschwelle geringfügig: > 95% = grün, 90–95% = gelb, <90% = rot).	Stichproben-Audit durch Governance-Team: manuelle Log-Durchsicht auf Compliance-Checkpunkte.	Vierteljährlich	Compliance Officer (Copilot Governance)
Kosten pro Nutzer	Monetäre Kosten (Lizenzen etc.) pro aktivem Copilot-Nutzer pro Monat.	≤ 30 € (entsprechend Lizenzpreis; Ziel: Kosten nicht über Plan).	Finanzreport: Gesamtkosten Copilot / Anzahl aktive Nutzer.	Quartalsweise	IT-Controlling
ROI (Benefit-Cost-Ratio)	Verhältnis aus geschätztem monetären Nutzen (z. B. Zeitersparnis in €) zu den laufenden Kosten der Copilot-Lösung.	> 1,0 ab Jahr 1<br>≥ 1,5 ab Jahr 2 (Zielvorgabe steigender ROI).	Berechnung: z. B. gesparte Stunden * Ø-Stundensatz / Kosten. Annahmen validiert via Management-Review.	Halbjährlich	CIO / Finanzcontroller
Schulung & Awareness	Anteil der Nutzer, die verpflichtende Copilot-Schulung und Kenntnisnahme der Richtlinien bestätigt haben.	≥ 98% (alle neuen Nutzer vor Freischaltung; Nachholquote schnellstmöglich auf 100%).	Learning Management System Auswertung + Bestätigungs-Logs.	Laufend (Reporting monatl.)	HR Learning oder Governance-Manager

Diese Tabelle zeigt beispielhaft, wie Kennzahlen konkret definiert, gemessen und zugewiesen werden. Die tatsächlichen Zielwerte können je nach Unternehmenszielen variieren, sollten aber stets ambitioniert und doch realistisch sein. Wichtig ist: Jede Zahl hat einen Verantwortlichen („Owner“), der dafür sorgt, dass sie gemessen wird und bei Abweichungen Maßnahmen initiiert.

Praxistipps am Ende von Abschnitt 8:
– Weniger ist mehr: Konzentrieren Sie sich auf eine Kernmenge aussagekräftiger KPIs/KRIs. Ein überfrachtetes Dashboard verliert an Wirkung – lieber 5–10 zentrale Werte, die wirklich den Puls der Sache fühlen. Diese können bei Bedarf rotieren oder angepasst werden, aber halten Sie das Reporting schlank.
– Frühwarnindikatoren definieren: Legen Sie für jeden KRI Schwellen fest, ab wann eingegriffen wird. Zum Beispiel: „Wenn ≥3 DLP-Vorfälle in einem Monat: außerplanmäßiges Governance-Meeting einberufen.“ So wird aus Messung auch Aktion.
– Positive Entwicklungen anerkennen: Nutzen Sie KPI-Verbesserungen auch, um das Team zu motivieren. Zeigt z. B. die Qualitätsskala deutlich nach oben, teilen Sie dieses Lob an die Nutzer (die offensichtlich gut damit umgehen) und an die Trainer/Enabler. Erfolgsmeldungen fördern die Bereitschaft, weiter an Verbesserungen zu arbeiten.
– Verankern Sie Kennzahlen in Zielvereinbarungen: Wo passend, können KPIs Teil von Management-Zielen oder Team-Zielen werden (etwa ein Service Owner, dessen Ziel es ist, Nutzungsgrad X zu erreichen oder Inzidenzen unter Y zu halten). So wird Governance in die allgemeine Performance-Kultur integriert.
– Flexibilität bewahren: Überprüfen Sie auch die KPIs/KRIs selbst im Zeitverlauf. Vielleicht erweisen sich manche als wenig sinnvoll oder schwer messbar – dann passen Sie sie an. Das Kennzahlenset ist kein Selbstzweck, sondern ein lebendiges Instrument, das optimiert werden kann.

9. Risikoregister & Maßnahmenkatalog

Ein Risikoregister fasst alle identifizierten Risiken im Zusammenhang mit Microsoft Copilot und deren Governance zusammen. Es dient dazu, den Überblick zu behalten und aktive Maßnahmen zur Risikobehandlung zu verfolgen. Hier präsentieren wir ein exemplarisches Risikoregister mit Einschätzung und Maßnahmen sowie einen fokussierten Maßnahmenkatalog mit den Top 10 Prioritäten.

Risikoregister (Ausschnitt)

Risiko	Ursache	Auswirkung	Eintritts- w’scheinlichkeit	Schadens- höhe	Risikostufe	Gegenmaßnahmen	Owner	Status
R1: Datenleck durch Copilot <br>(vertrauliche Infos gelangen an Unbefugte)	Überberechtigte Benutzerkonten; Copilot gibt Inhalte weiter, weil Berechtigungsmodell nicht strikt genug oder Nutzer teilt KI-Antwort unkontrolliert extern.	Vertrauensverlust, mögliche DSGVO-Verstöße, Wettbewerbsnachteil durch Know-how-Abfluss.	M (Wahrscheinlich, wenn keine Kontrollen)<br>(im aktuellen Setup: Niedrig, nach Maßnahmen)	Hoch	Hoch (vor Maßnahmen)<br>(Akzeptanz nur mit Controls)	– Berechtigungsanalyse & -bereinigung (Projekt gestartet, 90% der offenen Shares geschlossen).<br>- DLP-Filter aktiv (Block externer Versand vertraulicher Inhalte aus Copilot).<br>- Schulung der Nutzer: Do’s & Don’ts bei sensiblen Daten.<br>- Kontinuierliches Monitoring (Audit-Logs, wöchentl. Auswertung durch SecOps).	CISO / IT-Security	In Behandlung <br>(Maßnahmen zu 80% umgesetzt; Rest (Schulung letzte Gruppe) bis 31.10.)
R2: Halluzination führt zu Fehlentscheidung <br>(KI liefert falsche Info, die ungeprüft verwendet wird)	Copilot „halluziniert“ mangels Kontext oder aufgrund Modellfehler; Nutzer verlässt sich zu sehr auf KI ohne Gegencheck.	Falsche Geschäftsent- scheidung, z. B. falsche Kennzahl im Report -> ggf. finanzielle Schäden oder Image-Schaden.	M (Modellfehler vereinzelt zu erwarten, Abfangen hängt von Nutzer ab)	Mittel	Mittel	– Prompt-Bibliothek eingeführt mit Standardabfragen, die Quellen forcieren.<br>- Policy: Kritische Outputs >4 Augen-Prinzip (verankert, Kommunikation erfolgt).<br>- KPI Qualitätsrate wird erhoben, Ziel: >90%.<br>- Eskalationskette: bei bekannt werdender Fehlausgabe Case-Analyse + Info an alle Nutzer (Lerneffekt).<br>- Langfristig: Option Modell-Tuning mit firmeneigenen Daten prüfen, um Qualität zu steigern.	Copilot Prod. Owner + Fachprozess-Eigner	Laufend <br>(Qualitätsrate Q1: 85% → Q2: 92%, Risiko im grünen Bereich, weiter beobachten)
R3: Verstoß gegen DSGVO <br>(Datenschutzprobleme durch KI-Nutzung)	Ungeklärte Speicherung von personenbezogenen Daten in Copilot-Logs; Nutzer gibt sensible personenbezogene Daten in Prompts ein; fehlende Einwilligungen.	Geldbußen, behördliche Auflagen, Reputationsverlust im Datenschutz.	M (bei Unachtsamkeit nicht unwahrscheinlich; Pilot zeigte leichte Tendenzen)	Hoch (Bußen bis Millionenbereich möglich)	Hoch	– DPIA durchgeführt, keine unvertretbaren Risiken offen (erledigt).<br>- Logging angepasst: Anonymisierung von Benutzernamen in langfristigen Logs (geplant).<br>- Strikte Policy: keine sensitiven PD in Prompts, durch DSB kommuniziert.<br>- Verfahren für Auskunftsbegehren inkl. KI-Logs definiert (im Datenschutz-Prozess verankert).<br>- Sensibilisierung HR und Kundenservice (Bereiche mit vielen Personendaten) durch Sondertraining.	DSB (Datenschutz)	Maßnahmen laufen <br>(Anonymisierung-Tool in Test; bis 30.11. live. Monitoring bisher: keine DS-Incidents seit Einführung.)
R4: Unkontrollierte Plugin-Installation <br>(Schatten-IT durch KI-Plugins)	Mitarbeiter aktivieren inoffizielle oder unsichere Copilot-Plugins, die Daten abziehen könnten (weil z.B. benötigte Funktion nicht genehmigt wurde).	Sicherheitsrisiko (Datenabfluss), Umgehung der Governance, möglicher Support-Aufwand/Probleme, Lizenz- oder Vertragsverletzungen.	N (gering, da Plugins derzeit global disabled; könnte steigen falls Freigabe-Katalog zu eng und Nutzer Workarounds suchen)	Mittel	Mittel	– Admin hat Third-Party-Plugins global deaktiviert (Status Quo).<br>- Klarer Prozess kommuniziert: Plugin-Wünsche via IT anmelden (erledigt, Info im Intranet).<br>- Monitoring: regelmäßige Kontrolle, ob Nutzer versuchen, Plugins zu aktivieren (Audit-Log-Auswertung, bisher 0 Versuche).<br>- Geplanter Maßnahmenpunkt: Katalog genehmigter Plugins inkl. firmeninterner, sodass Nutzer nicht in Versuchung kommen (bis Q1 nächstes Jahr).	IT-Leiter / Governance Board	Unter Kontrolle <br>(weiterhin wachsam – aufgenommen ins Risiko-Reporting, aber aktuell kein akutes Problem)
R5: Kosten explodieren / Nutzen bleibt aus <br>(Wirtschaftlicher Schaden)	Zu viele Lizenzen beschafft ohne echten Bedarf; Nutzer nutzen Tool ineffizient; ggf. unerwartete Zusatzkosten durch API-Aufrufe oder höheres Lizenzpricing.	Budgetüberschreitung, Rentabilitätsziele verfehlt → Management verliert Unterstützung, Projekt könnte gestoppt werden.	N-M (mittel, wenn Steuerung versagt; bisher strenge Kontrolle → eher niedrig)	Mittel	Mittel	– Stufenweiser Rollout begrenzt Invest pro Phase (wird eingehalten).<br>- Monatliches Kostenreporting an CIO (aktiv, aktuell Kosten im Plan).<br>- Unused Licenses: konsequentes Einziehen nach 2 Monaten Inaktivität (Policy, wird umgesetzt via Monitoring).<br>- ROI-Review nach 6 und 12 Monaten eingeplant – erster Review ergab ~1.2, okay.<br>- Option, Lizenzumfang anzupassen (verringern oder erhöhen) jederzeit gegeben, Verträge flexibel (verhandelt).	CIO / IT-Controlling	Beobachtung <br>(erstes Jahr ROI leicht positiv, aber Benefit-Potential noch steigerbar; im Plan belassen und regelmäßig prüfen)
R6: Unzureichende Akzeptanz / Change-Probleme <br>(Nutzer sträuben sich oder nutzen Copilot falsch)	Fehlende Kommunikation, Ängste (Jobverlust, Überwachung), evtl. Widerstand vom mittleren Management, das KI misstraut; ungenügende Schulung führt zu Frust.	Investition wird nicht genutzt (Nutzen verpufft), Schatten-Workarounds (manche nutzen lieber öffentliche KI ohne Kontrolle), oder Inkonsistente Prozessanwendung.	M (Change-Risiko immer gegeben, schon einige Bedenken in Umfragen gesehen)	Mittel	Mittel	– Umfassendes Change Mgt: mehrfach Info-Veranstaltungen, Management trägt aktiv mit (Vorstandsvideo „Warum wir Copilot nutzen“).<br>- Betriebsrat eingebunden, Bedenken in BV adressiert (z.B. Monitoring ausgeschlossen).<br>- Schulungsoffensive: divers (E-Learning, Intranet-Community, KI-Sprechstunden).<br>- Champions-Netzwerk etabliert (pro Abteilung ein Multiplikator).<br>- Erfolge sichtbar machen (interne Newsletter mit Pilot-Erfolgsstory, etc.).<br>- Feedback-Kanal offen und Reaktionszeit auf Rückmeldungen kurz (Governance-Team beantwortet Fragen im Yammer täglich).	Change Manager (HR) + Copilot Prod. Owner	Mitlaufend <br>(Stimmung nach Rollout Welle1 tendenziell positiv, Umfrage: 80% neugierig/aufgeschlossen, 10% skeptisch, 10% neutral. Maßnahmen fortführen um Skepsis weiter abzubauen.)
R7: Technische Störung / Ausfall <br>(Verfügbarkeit von Copilot)	Probleme bei Microsoft-Dienst (Cloud-Ausfall, Model-Bug) oder interne Konfig-Fehler (z.B. CA-Policy sperrt legitime Nutzung).	Produktivitätsausfälle, Frustration, im schlimmsten Fall Betriebsunterbrechung (wenn man sich sehr drauf verlässt). Außerdem: bei häufigen Störungen riskieren Nutzer, auf inoffizielle Tools auszuweichen.	M (Cloud-Probleme selten, aber möglich; interne Fehler adressierbar, aber initial Pilot hatte z.B. CA-Fehlkonfiguration einen Tag)	Niedrig-Mittel (einzelne Störung verkraftbar, aber kontinuierliche Instabilität kritisch)	Mittel	– Service Level Agreement mit Microsoft im Blick (99.9% av.); Admin abonniert Service Health Alerts (implementiert).<br>- Intern Fallback definiert: Nutzer sollen auch ohne Copilot ihre Aufgaben erledigen können (notwendig, betont in Kommunikation: „KI Assistenz, aber Sie müssen Ihren Job noch kennen“).<br>- Incident Response Plan für Ausfall: schnelle interne Info („Copilot derzeit nicht verfügbar, wir melden, sobald ok“). Transparente Kommunikation, um Frust zu mindern.<br>- Nach erstem Ausfall (CA-Policy Issue) Root Cause behoben und Change-Prozess verbessert (Änderungen jetzt im Testtenant prüfen).<br>- Monitoring: Downtime wird erfasst (bislang 99.8% v.a., i.O.).	IT-Betrieb (Service Owner)	Akzeptiert <br>(Restrisiko tolerabel, Maßnahmen etabliert; wird bei Änderungen an Cloud engmaschig überwacht)
R8: Regulatorische Verschärfung <br>(Neue Gesetze schränken KI-Nutzung ein)	Zukünftige Anforderungen (z. B. EU AI Act stuft Copilot höheres Risiko ein oder verlangt Meldungen), lokale Gesetzgebung oder Branchenvorschriften ändern sich.	Nachrüstungsbedarf (zusätzl. Kontrollen, Dokumentation) -> Aufwand und evtl. temporäre Einschränkung. Im Extremfall bestimmte Funktionen unzulässig -> Abschaltung oder Bußgeldrisiko.	M (AI Act 2025ff sehr wahrscheinlich, andere unsichere Timelines)	Mittel	Mittel	– Legal/Compliance hält „Radar“ auf KI-Regulierung (Aufgabe an Reg.-Beobachter vergeben).<br>- Teilnahme an Branchenaustausch, um früh Best Practices zu kommenden Anforderungen zu sammeln.<br>- Flexibles Governance-Framework: bisheriges Risiko-Assessment kann um neue Kriterien erweitert werden (z. B. Bias-Monitoring falls vorgeschrieben).<br>- Reserve-Budget und -Ressourcen einplanen für evtl. erforderliche Anpassungen (z. B. Audit-Tool kaufen, Datentransparenzreports erstellen etc.).<br>- Scenario-Planung: Was tun, wenn Act XYZ etwas verbietet? (Notfallplan-Policies).	Compliance Officer / Legal	Beobachtung <br>(Aktuell keine akute Änderung; Risikostatus gelb – mittelfristig relevant. Nächster Review Q1 nächstes Jahr oder bei Neuigkeit.)
R9: Fehlende Verantwortlichkeiten <br>(Governance-Initiative verliert Drive)	Nach Einführungsprojekt verstreicht Zeit, Teammitglieder wechseln oder Governance-Tasks werden im Tagesgeschäft vernachlässigt (kein klares Ownership mehr).	Langsam Erosion der Kontrollen: Policies veralten, KPIs werden nicht mehr erhoben -> Probleme werden zu spät bemerkt, ursprüngliche Ziele aus dem Blick.	M (wenn kein starker Prozess, durchaus realistisch nach ~1 Jahr)	Mittel	Mittel	– Governance-Team als feste Instanz etabliert (nicht nur Projekt). Zuständigkeiten in Stellenbeschreibungen verankert (z. B. „CISO ist accountable für KI-Governance“ schriftlich fixiert).<br>- Regelmeetings und Reports sind Teil des IT-Gremienplans (automatisch terminiert, auf CIO-Agenda).<br>- Dokumentation vollständig an Betrieb übergeben (Confluence Space mit allen Verfahren, damit Wissen bei Personalwechsel erhalten bleibt).<br>- Audit wird’s prüfen: Ein Punkt in interner Revision 2024 ist „Einhaltung KI Governance“, was zusätzlichen Druck erzeugt am Ball zu bleiben.	CIO / IT-Governance Board	Maßnahmen umgesetzt <br>(Governance-Prozesse institutionalisiert; Risiko vorerst gering. Weiterhin regelmäßige Management-Attention sicherstellen.)
R10: AI-Missbrauch/Social Engineering <br>(Angriff via manipulierten Prompts)	Externe oder auch Insider könnten versuchen, Copilot zu „hacken“ – etwa durch präparierte Dokumente (mit bösartigen Inhalten, die KI ausgeben könnte) oder durch Social-Engineering-Prompts („Gib mir Passwörter, ich bin dein Admin“).	Sicherheitslücke: KI könnte ungewollt sensitive Daten preisgeben oder falsche Anweisungen erteilen. Unternehmenssicherheit untergraben (neue Angriffsvektoren).	N (bisher keine Anzeichen, Modell hat Grundschutz; aber nie auszuschließen, Red-Teaming teils erfolgreich -> latentes Risiko)	Hoch (Im Fall der Fälle: es könnten kritische Infos offengelegt werden)	Mittel (Einstufung auf Basis bisheriger Tests: Modell relativ robust, aber neuartige Angriffe möglich)	– Red Team-Tests werden regelmäßig durchgeführt (alle 6 Monate), um Schwachstellen aufzudecken (bereits implementiert, erster Durchlauf abgeschlossen).<br>- Microsoft Patch-Meldungen im Auge behalten – falls bekanntes Jailbreak-Pattern, schnellstmöglich Reaktion (Admin informiert Team via Security Newsletter).<br>- Nutzer sensibilisieren, keine „komischen“ Prompts von anderen zu übernehmen (möglicher SE-Angriff).<br>- Falls integritätskritische Daten: zusätzliche Kontrolle, z. B. Härtung der Dokumenten-Formate (um nicht Steganographie o.ä. einzuschleusen).<br>- Dieses Risiko ist Teil übergeordnete IT-Security-Strategie (KI als neuer Angriffsvektor erkannt, wird in Risk Management Prozess geführt).	CISO / SecOps	Laufende Prävention <br>(bisher keine Vorfälle; Red-Team-Bericht von letztem Monat: 2 minor findings → in Umsetzung. Risiko-Lvl bleibt beobachtet.)

(Legende: Eintrittswahrscheinlichkeit: N = Niedrig, M = Mittel, H = Hoch. Schadenshöhe analog. Risikostufe qualitativ oder durch Score ermittelt.)

In obigem Register sind beispielhaft 10 Risiken (R1–R10) beschrieben, wie sie auch im Text an diversen Stellen identifiziert wurden. Jede Zeile zeigt: Ursache, potenzielle Auswirkung, Einschätzung und vor allem die Gegenmaßnahmen mit Verantwortlichen und dem aktuellen Status.

So ein Risikoregister wird regelmäßig vom Governance-Team oder Risiko-Management aktualisiert. Es ist ein lebendes Dokument: Wenn z.B. „R1 Datenleck“ dank Maßnahmen signifikant reduziert wurde (Restwahrscheinlichkeit niedrig), könnte man es irgendwann auf „akzeptiert“ setzen oder aus Top-10 herausnehmen. Andererseits taucht vielleicht Neues auf (z.B. KI generiert geschützte Inhalte -> Urheberrechtsrisiko) – dann kommt ein neuer Eintrag.

Nun aus dem Register (und der gesamten Analyse) ergeben sich zahlreiche Gegenmaßnahmen. Der Maßnahmenkatalog priorisiert die wichtigsten, um den Fokus zu schärfen – hier die Top 10 Maßnahmen mit Begründung und Aufwandseinschätzung:

Top-10-Maßnahmen mit Begründung und Aufwand

1. Berechtigungs-Audit und -Bereinigung durchführen – Begründung: Viele Risiken (Datenleck, unerlaubter Zugriff) basieren auf zu großzügigen Berechtigungen. Durch einen einmaligen intensiven Audit (wer kann wo lesen?) und dem Schließen unnötiger Zugriffe verringern wir massiv die Gefahr, dass Copilot Unbefugtem etwas anzeigt. Aufwand: Hoch (bereichsübergreifend mehrere Wochen Arbeit von IT und Datenverantwortlichen), aber einmalig. (Priorität 1)
2. DLP-Regeln gezielt auf Copilot abstimmen – Begründung: DLP ist unsere letzte Barriere, falls doch sensible Infos rauszugehen drohen. Wir müssen sicherstellen, dass die bestehenden Regeln KI-spezifische Muster (z. B. KI generiert tabellarisch Personendaten, etc.) erkennen und blocken. Aufwand: Mittel (Definieren neuer Regeln, Testen einiger Szenarien), kontinuierlich moderate Pflege. (Priorität 1)
3. Prompt- & Antwort-Guidelines fest etablieren (inkl. Prompt-Bibliothek) – Begründung: Dies adressiert qualitativ die Fehleranfälligkeit und Nutzungsinkonsistenz. Geben wir den Nutzern gute Rezepte an die Hand, sinkt die Halluzinationsrate und erhöht sich die Effizienz. Aufwand: Mittel (Erstellung initialer Bibliothek erfordert fachliche Inputs; pflegen über Zeit), aber sehr wertvoll. (Priorität 2)
4. Schulungs- und Awareness-Offensive – Begründung: Der Mensch bleibt Schwachstelle oder Erfolgsfaktor. Gründliche Schulung (insb. Datenschutz, Do/Don’t) mindert Risiko R3, R6 und steigert Nutzen (Akzeptanz). Aufwand: Mittel bis Hoch initial (Material erstellen, Sessions), dann niedrig (E-Learning-Wartung). Kontinuierlich aber modulweise einzubauen (Auffrischungen). (Priorität 1)
5. Plugin-Governance (Whitelist-Framework) implementieren – Begründung: Um Shadow-IT (R4) vorzubeugen und künftige Erweiterungen sicher zu nutzen, brauchen wir früh ein klares Verfahren, sonst Wildwuchs. Aufwand: Mittel (Prozessdefinition, Katalog einführen, 1-2 Prüfungen pilotieren), dann pro Plugin-Prüfung auch wieder Mittel (Sicherheitsaudit etc.). (Priorität 2)
6. Red Team/Penetration Tests institutionalisierten – Begründung: Nur so finden wir proaktiv Sicherheitslücken (R10). Externe Angreifer schlafen nicht, also müssen wir selbst offensiv testen. Aufwand: Mittel bis Hoch (externe Experten hinzu ziehen oder internes Team aufbauen; ca. alle 6-12 Monate 1-2 Wochen Testing). Angesichts Schadenshöhe von Sicherheitsvorfällen aber gerechtfertigt. (Priorität 2)
7. Monitoring-Dashboard & Alerts aufbauen – Begründung: Echtzeitüberwachung (KPIs, KRIs) erlaubt schnelles Gegensteuern. Ohne Dashboards laufen wir blind (R9 – Governance-Verantwortung könnte entgleiten). Aufwand: Mittel (technische Einrichtung in PowerBI/Sentinel, definieren, wer pflegt). Eher einmalig, mit etwas laufender Anpassung. (Priorität 1)
8. Betriebliche Verankerung fixieren (Prozesse, Verantwortliche) – Begründung: Damit nach Projekt nicht die Zügel schleifen (R9). Heißt: Schreib es in Stellenbeschreibungen, nimm es in Regel-Meetings auf, integriere in ISO/IKS – so geht es nicht verloren. Aufwand: Niedrig (organisatorischer Beschluss, etwas Dokumentation), Effekt hoch. (Priorität 1)
9. Datenschutz-Maßnahmen verfeinern (Logging-Anonymisierung, Archivierung) – Begründung: Um R3 (DSGVO) vollends zu entschärfen, sollten wir vllt. Log-Daten begrenzen (z. B. Hash statt Klarnamen, nach X Monaten löschen) und streng regeln, was archiviert wird. Aufwand: Mittel (Abstimmung mit MS oder eigenem Tool, Workflows definieren), aber wichtig in langfristiger Compliance. (Priorität 2)
10. Regelmäßige Strategy-Reviews mit Management – Begründung: Um auf R8 (Regulatorik-Änderungen) und allgemein neue Trends reagieren zu können, sollte mindestens jährlich auf höchster Ebene evaluiert werden: Haben wir Anpassungsbedarf (z. B. andere KI-Plattform wählen? Umfang erweitern?). So bleibt das Thema präsent und agil gemanaged. Aufwand: Niedrig (1 Workshop pro Jahr, plus Vorbereitung). (Priorität 3)

(Erläuterung Priorität: 1 = sofort/so wichtig wie möglich, 2 = wichtig, sollte aber gestaffelt nach Ressourcen, 3 = nützlich, mittel-/langfristig angehen.)

Dieser Maßnahmenkatalog zeigt klar, wohin die Energie fließen sollte. Einiges – wie Berechtigungsbereinigung, DLP-Abstimmung, Monitoring – kann unmittelbar nach Projektstart erfolgen. Anderes – wie Plugin-Governance oder Red Teaming – kommt ggf. wenn Basis steht, aber bleibt fest eingeplant. Entscheidend ist, dass ein Owner und eine Timeline für jede Maßnahme existiert (diese Details würden intern im Projektplan stehen).

Durch diese strukturierte Erfassung im Risikoregister und Maßnahmenplan stellt die Organisation sicher, dass kein identifiziertes Risiko „liegenbleibt“, sondern aktiv gemanagt wird. Zugleich kann sie gegenüber Audit oder Aufsichtsrat jederzeit zeigen: „Wir kennen unsere Risiken und tun X, Y, Z dagegen – hier der aktuelle Stand.“

(Praxistipps am Ende von Abschnitt 9:
– Keep it simple: Das Risikoregister muss praktikabel bleiben. Fokussieren Sie auf die „Top-Risiken“, statt 50 Kleinigkeiten aufzunehmen. Lieber 10 überschaubare Risiken mit konkreten Maßnahmen als ein Wust, den keiner liest.
– Maßnahmen-Priorität regelmäßig neu bewerten: Was anfangs Priorität 1 war (z. B. Berechtigungen), kann nach Umsetzung runtergestuft oder aus dem aktiven Katalog gestrichen werden. Dafür rücken neue Aspekte nach. Nutzen Sie Governance-Meetings, um den Status zu aktualisieren und ggf. Prioritäten neu zu setzen.
– Verantwortung einfordern: Jeder Maßnahmen-Owner sollte die Aufgabe auch wirklich annehmen und Ressourcen dafür einplanen. Verankern Sie wichtige Maßnahmen notfalls in Zielvereinbarungen oder Projektplänen der jeweiligen Owner, damit klar ist: Das hat Chefrückendeckung und muss gemacht werden.
– Erfolge der Maßnahmen sichtbar machen: Wenn z. B. Maßnahme „Schulungsoffensive“ abgeschlossen ist, und als Erfolg vielleicht KRI „Policy-Verstöße“ sinken, dann kommunizieren Sie das. So verstehen alle den Sinn hinter der vielen Arbeit und es entsteht weiter Momentum, die restlichen Maßnahmen auch durchzuziehen.

10. Praxisanhänge

In diesem Abschnitt werden praktische Hilfsmittel und Beispiele bereitgestellt, um die zuvor beschriebenen Governance-Maßnahmen im Alltag umzusetzen. Die Anhänge sollen als Vorlagen dienen, die an eigene Bedürfnisse angepasst werden können.

10.1 Muster-Policies (jeweils ~10 Sätze, prüfbar)

Hier folgen beispielhafte Auszüge aus Richtlinien, die in einer Copilot-Governance zum Einsatz kommen könnten. Diese Texte sind bewusst knapp, klar und in prüfbarer Form geschrieben.

Muster-Policy 1: „Nutzung von KI-Assistenzdiensten“
 

Unternehmensrichtlinie – Einsatz von KI-Assistenz (Auszug)

1. Zweck: Microsoft 365 Copilot darf ausschließlich zur Unterstützung dienstlicher Aufgaben genutzt werden. Die Nutzung erfolgt im Rahmen der bestehenden IT-Richtlinien und unterliegt dem hier definierten Ordnungsrahmen.

2. Zulässige Nutzung: Mitarbeiter sollen Copilot vor allem für Routinefragen, Recherche innerhalb freigegebener Informationen und als Schreibassistenz einsetzen. Die KI darf helfen, Inhalte zu strukturieren, Zusammenfassungen zu erstellen oder Standardtexte aufzubereiten.

3. Unzulässige Nutzung: Copilot darf nicht missbraucht werden, um Regeln zu umgehen oder unethische Inhalte zu generieren. Vertrauliche oder personenbezogene Daten dürfen nur eingegeben werden, wenn dies zwingend zur Aufgabenerfüllung nötig und durch Datenschutzregelungen erlaubt ist. Es ist untersagt, die KI nach sensiblen Daten zu fragen, zu denen man selbst keinen legitimen Zugang hat.

4. Verantwortlichkeit: Der menschliche Nutzer bleibt stets für das Endergebnis verantwortlich. KI-Vorschläge müssen vor Verwendung auf Richtigkeit und Angemessenheit geprüft werden. Kritische Entscheidungen dürfen nicht ohne menschliche Prüfung allein auf Copilot-Ausgaben basieren.

5. Datenschutz & Sicherheit: Copilot protokolliert alle Interaktionen gemäß unserer Datenschutzrichtlinie. Mitarbeiter dürfen keine Inhalte eingeben, die gegen geltende Datenschutzbestimmungen verstoßen (z.B. Gesundheitsdaten ohne Rechtsgrundlage). Das Unternehmen trifft technische Vorkehrungen (Logging, DLP), um einen sicheren Einsatz zu gewährleisten.

6. Kontrolle & Audit: Die Einhaltung dieser Richtlinie wird überwacht. Bei Verstößen (z.B. Eingabe streng vertraulicher Informationen ohne Freigabe) können arbeitsrechtliche Konsequenzen folgen. Die IT-Abteilung und Revision sind berechtigt, KI-Aktivitäten stichprobenartig zu prüfen.

7. Inkrafttreten: Diese Regelung tritt am 01.11.2025 in Kraft und gilt für alle Mitarbeiter der [Unternehmen] sowie externe Benutzer mit Zugriff auf unseren M365-Tenant. Sie wird jährlich überprüft und bei Bedarf angepasst.

Muster-Policy 2: „Generative KI in der Softwareentwicklung“
(Angenommen, Copilot wird auch zum Programmieren genutzt – spezielle Regelung dafür)
 

Zusatzrichtlinie – Einsatz generativer KI in der Softwareentwicklung

1. Scope: Diese Zusatzrichtlinie gilt für alle Entwickler und Data-Scientists, die Microsoft 365 Copilot oder ähnliche generative KI beim Coding, Code-Review oder für technische Konzeption einsetzen.

2. Code-Qualität und Sicherheit: Generierter Code muss denselben Qualitäts- und Sicherheitsstandards genügen wie manuell erstellter Code. Jeder durch Copilot vorgeschlagene Code-Schnipsel ist vor dem Commit auf Sicherheitslücken, Lizenzkonformität und Funktionalität zu überprüfen (Peer-Review Pflicht).

3. Urheberrechte: Entwickler dürfen Copilot nicht nutzen, um umfangreiche fremde Codepassagen nachzubilden, bei denen Urheberrechtsverletzungen möglich sind. Sollte Copilot mehr als triviale Codezeilen generieren, muss die Quelle geprüft werden. Bekannte Open-Source-Lizenzen sind einzuhalten; im Zweifel ist die Nutzung des generierten Codes abzulehnen.

4. Vertrauliche Geschäftslogik: Firmeninternes proprietäres Wissen (z.B. Algorithmus-Logik, geheime Formeln) soll nicht als Prompt an externe KI-Modelle gegeben werden. Copilot darf hingegen auf intern indexierte Wissensquellen zurückgreifen, die für die Entwicklung freigegeben sind.

5. Kein produktiver Zugriff ohne Freigabe: Copilot-Anbindungen an laufende Produktivsysteme (Datenbanken, APIs) sind verboten, außer sie wurden im Rahmen eines Change-Management-Prozesses genehmigt. Entwickler dürfen KI nicht direkt gegen Live-Datenbankabfragen einsetzen ohne Data-Governance-Freigabe.

6. Logging & Nachvollziehbarkeit: Alle KI-gestützten Code-Erstellungen müssen nachvollziehbar sein. Entwickler kommentieren größere von Copilot stammende Code-Blöcke im Pull-Request entsprechend (z.B. „erstellt mit KI-Hilfe, geprüft von XY“). Dies dient der Nachvollziehbarkeit bei späteren Code Reviews oder Audits.

7. Verantwortung: Der eincheckende Entwickler übernimmt die volle Verantwortung für den eingesetzten Code. Copilot ist ein Tool, entbindet jedoch nicht von der Verpflichtung, sicheren und funktionierenden Code zu liefern. Etwaige Fehler aus KI-Code sind vom verantwortlichen Entwickler zu beheben, als hätte er sie selbst geschrieben.

(Ende Auszug)

Diese Muster-Policies demonstrieren, wie konkrete und überprüfbare Regeln formuliert sein können. Sie sind natürlich exemplarisch und müssten im echten Betrieb den Gegebenheiten angepasst werden.

10.2 Muster-Kommunikation an Mitarbeiter (Einführung, Do/Don’t, Supportwege)

Eine klare Mitarbeiterkommunikation ist entscheidend für Akzeptanz und korrektes Verhalten. Hier ein Muster für eine Ankündigungs-E-Mail bzw. Intranet-News zur Einführung von Copilot, inklusive Do/Don’t-Kurzüberblick und Hinweis auf Support:

Betreff: Einführung von Microsoft 365 Copilot – Ihr neuer KI-Assistent bei der Arbeit

Liebe Kolleginnen und Kollegen,

am 15. November ist es soweit: Wir schalten für den ersten Bereich Microsoft 365 Copilot frei. Dieses neue KI-Tool unterstützt Sie dabei, Routineaufgaben schneller zu erledigen, Informationen aus unseren Daten zu finden und kreative Entwürfe zu erstellen. Bevor es losgeht, möchten wir Ihnen einige wichtige Hinweise geben.

Was ist Copilot?
Copilot ist eine Art intelligente Assistenz, integriert in Word, Outlook, Teams und andere Office-Anwendungen. Sie können Copilot z.B. fragen: „Fasse die letzten 5 Dokumente zum Projekt XY zusammen“ oder „Entwirf eine Antwort auf diese Kunden-E-Mail“ – und erhalten in Sekunden einen Entwurf. Copilot arbeitet auf Basis unserer vorhandenen Dokumente und Ihrer Eingaben. Es nutzt moderne KI (vergleichbar mit ChatGPT) innerhalb unserer sicheren Microsoft-Cloud.

Warum führen wir Copilot ein?
Unser Ziel ist es, Ihre tägliche Arbeit zu erleichtern. Erste Pilotnutzer berichten, dass sie durch Copilot viel Zeit sparen konnten – z.B. beim Erstellen von Präsentationen oder Protokollen. Gleichzeitig können wir Wissen besser teilen: Copilot findet vielleicht die Info aus einem Team, die Sie sonst übersehen hätten. Wichtig: Copilot soll Sie unterstützen, nicht ersetzen. Ihre Expertise bleibt unverzichtbar – die KI nimmt Ihnen lediglich Fleißarbeit ab.

Dos and Don’ts im Umgang mit Copilot:
Bitte beachten Sie folgende Grundregeln (Details in der angehängten Richtlinie „KI-Nutzung“):
DO:
– Nutzen Sie Copilot, um Entwürfe zu erstellen – z.B. Textvorschläge, Ideenlisten, Zusammenfassungen. Prüfen und verfeinern Sie die Ergebnisse anschließend selbst.
– Fragen Sie Copilot gern nach Informationen, die Sie sonst mühsam zusammensuchen müssten (z.B. „Zeige mir die Umsatzentwicklung der letzten 4 Quartale“). Voraussetzung: Diese Daten sind irgendwo bei uns gespeichert und für Sie zugänglich.
– Überprüfen Sie KI-Antworten immer kurz auf Plausibilität. Insbesondere bei Zahlen oder Fakten – ein schneller Gegencheck kann nicht schaden. Im Zweifelsfall ziehen Sie eine Kollegin oder Originalquelle hinzu.

DON’T:
– Keine sensiblen Daten eingeben, sofern vermeidbar. Vermeiden Sie es z.B., eine komplette Liste mit Personaldaten oder Kundendetails als Prompt reinzukopieren. Fragen Sie lieber allgemein („Gib mir Trends basierend auf dem Kundenfeedback 2023“) – Copilot hat Zugriff auf freigegebene Daten und zieht sich die Infos selbst.
– Nicht ungeprüft versenden: Lassen Sie einen von Copilot formulierten Mail-Entwurf niemals 1:1 ohne eigenes Lesen raus. Sie sind der Absender – also stellen Sie sicher, dass Ton und Inhalt passen.
– Kein vertrauliches Wissen teilen: Fragen Sie Copilot nicht nach etwas, das nur in einem streng vertraulichen Dokument steht, welches Sie selbst nichts angeht. Copilot wird zwar versuchen zu antworten (wenn es Zugriff hätte), aber solche Aktionen sind laut Policy untersagt und werden protokolliert.
– Keine externen Plugins selbst aktivieren: Wir haben Copilot vorerst so eingestellt, dass keine zusätzlichen Erweiterungen genutzt werden. Bitte versuchen Sie nicht, eigenmächtig irgendwelche Verbindungen zu Dritt-Apps herzustellen. Wenn Sie meinen, ein bestimmtes Plugin wäre hilfreich, sprechen Sie den IT-Service an.

Unterstützung & Fragen:
Wir lassen Sie mit der neuen KI nicht allein! Ab sofort finden Sie im Intranet ein „Copilot-Help Center“ mit FAQ, Kurzvideos und unserer Copilot-Nutzungsrichtlinie. Zudem bieten wir in den nächsten zwei Wochen mehrere 30-minütige Live-Demos mit Q&A an (Termine: siehe Intranet-Ankündigung). Ihre primären Ansprechpersonen sind:
– Fachliche Fragen zur Nutzung: Wenden Sie sich gern an unsere Copilot-Champions in Ihrem Bereich – <Ansprechpartner Name, Team>. Sie haben das Tool bereits getestet.
– Technische Probleme: Der IT-Helpdesk ist wie gewohnt über das Ticketsystem oder Tel. 123 erreichbar. Bitte erwähnen Sie „Copilot“ im Ticket, sodass wir schnell reagieren können.
– Feedback & Ideen: Wir richten einen Diskussionskanal „Copilot Erfahrungsaustausch“ im Yammer ein. Teilen Sie dort gerne Ihre Tipps, aber auch, wenn etwas nicht gut funktioniert – wir wollen daraus lernen und das System verbessern.

Datenschutz & Compliance:
Uns ist bewusst, dass KI Fragen aufwirft. Seien Sie versichert: Copilot ist in unserer EU-Cloud gehostet und erfüllt die aktuellen Datenschutzstandards. Prompts, die Sie eingeben, werden nicht zur Verbesserung des öffentlichen KI-Modells verwendet, sondern verbleiben in unserem Tenant. Wir haben mit unserem Datenschutzbeauftragten eine Folgenabschätzung durchgeführt. Wichtig ist, dass auch Sie – wie oben erwähnt – datensparsam vorgehen. Alles was gegen unsere Datenschutzrichtlinie verstößt, bleibt auch mit KI verboten (z.B. Weitergabe personenbezogener Daten an Unbefugte). Bei Fragen hierzu können Sie sich an datenschutz@[firma].com wenden.

Was passiert als nächstes?
In der kommenden Woche erhalten die ersten Teams Zugang zu Copilot (die Bereichsleitungen wurden informiert, wer dazu gehört). Nach und nach – voraussichtlich bis Ende Q1 – rollen wir den Dienst an alle Office-Mitarbeiter aus. Sie bekommen eine Benachrichtigung, sobald Ihr Account freigeschaltet ist. Dann erscheint in Ihren Office-Apps ein Copilot-Symbol, und Sie können loslegen.

Wir werden regelmäßig über die Fortschritte berichten. Schon jetzt ein Dank an alle Pilotnutzer, die uns wertvolles Feedback gegeben haben und an alle für die Offenheit gegenüber diesem innovativen Werkzeug. Wir freuen uns darauf, gemeinsam herauszufinden, wie Copilot uns am besten unterstützt!

Bei Fragen stehe ich oder das Projektteam jederzeit zur Verfügung.

Mit freundlichen Grüßen, <Ihr CIO / Projektleiter Copilot>

(Anlagen: Kurzanleitung „Erste Schritte mit Copilot“, Richtlinie „KI-Nutzung“)

Diese Kommunikation deckt: – Was & Warum der Einführung (Management Buy-in), – Verhaltenserwartungen (Do/Don’t), – Hinweise auf Hilfestellungen (Supportwege), – und beruhigt in Sachen Datenschutz/Compliance, – plus Ausblick auf Rollout.

Sie wäre per E-Mail, Intranet-News oder als Handout gut geeignet. Wichtig: in klarer, nicht zu formaler Sprache, um alle Mitarbeiter abzuholen, und mit konkreten Anweisungen (Prominente Do/Don’t Listen).

10.3 Muster-Prozess „Plugin-Freigabe“ (Flow: Antrag → Prüfung → Pilot → Freigabe → Review)

Da die Erweiterbarkeit von Copilot über Plugins/Connectors ein heikles Thema ist, hier ein beispielhafter Prozessablauf, wie ein neues Plugin oder ein Graph-Connector beantragt und freigegeben wird:

1. Bedarfsmeldung (Antrag): Ein Fachbereich stellt fest, dass ein bestimmtes Copilot-Plugin (z. B. für Jira, SAP etc.) oder ein Connector (z. B. Anbindung einer externen Wissensdatenbank) nützlich wäre. Der Fachbereichsleiter oder ein Key User füllt ein standardisiertes Antragsformular aus. Darin enthalten: Beschreibung des Plugins, erwarteter Nutzen, welche Daten zugänglich wären und warum es gebraucht wird. Dieser Antrag geht an das Copilot-Governance-Team (z.B. per Service-Now Anforderungskatalog „Copilot Plugin Request“).
2. Vorprüfung durch Governance-Team: Innerhalb z. B. 5 Werktagen beurteilt das Governance-Team (IT + CISO + DSB Beteiligung) den Antrag grob:
3. Ist der Nutzen nachvollziehbar und nicht bereits durch vorhandene Tools abdeckbar?
4. Könnten offensichtlich hohe Risiken bestehen (z. B. Plugin stammt von unbekanntem Hersteller, greift auf viele personenbezogene Daten zu)?
5. Passt das Plugin zu unserer Strategie (ggf. nur Microsoft-verified Plugins erlaubt etc.)?

Falls Nein -> Ablehnung mit Begründung an Antragsteller. Falls Ja -> weiter zu Schritt 3.

1. Detailprüfung (Sicherheit/Compliance): Jetzt folgt eine gründliche Evaluierung:
2. Die IT-Security führt eine Risikoanalyse durch: Welche Berechtigungen fordert das Plugin? Wohin fließen Daten? Ist die Kommunikation verschlüsselt? Liegen bekannte Schwachstellen vor (Recherche in Community)?
3. Der Datenschutz prüft die Datenschutzaspekte: Wird eine Auftragsverarbeitung mit dem Plugin-Anbieter nötig? Speichert das Plugin dauerhaft unsere Daten extern? Ist der Sitz des Anbieters DSGVO-konform (EU/adequacy)?
4. Evtl. Fach-IT evaluiert technische Kompatibilität: braucht es Zusatzinfrastruktur, hat es Performance-Impact etc.

Diese Prüfschritte werden dokumentiert (z. B. in einer Plugin-Risiko-Checkliste). Ergebnis kann sein: – „No-go“ (z. B. Anbieter lehnt AV-Vertrag ab -> Abbruch). – „Bedingt geeignet, jedoch folgende Einschränkungen nötig“ (z. B. nur Leserechte, oder Nutzung nur durch bestimmte Abteilung). – „Sieht gut aus“.

1. Pilot-Test des Plugins/Connectors: Angenommen es ist nicht disqualifiziert, wird das Plugin zunächst nur im kleinen Rahmen getestet:
2. IT richtet das Plugin in einer Testumgebung oder für eine sehr begrenzte Nutzergruppe (z. B. 2-3 Personen im antragstellenden Fachbereich plus ein Sicherheits-Vertreter) ein.
3. In dieser Pilotphase (sagen wir 2 Wochen) werden konkrete Anwendungsfälle durchgespielt. Man beobachtet: Funktioniert es technisch? Wie fließen Daten? Tritt etwas Unerwartetes auf (z. B. Plugin zeigt plötzlich Daten aus anderem Tenant -> Alarm)?
4. Die Pilotnutzer und das Governance-Team sammeln Eindrücke. Falls Probleme auftreten, kann man hier noch nachjustieren (oder Test abbrechen).
5. Nach Ende erstellen die Tester einen kurzen Evaluationsbericht (Nutzen bestätigt? Risiken bestätigt oder ausgeräumt?).
6. Entscheidung & Freigabe: Das Governance-Board wertet die Detailprüfung und Pilot-Ergebnisse aus. Nun erfolgt die formale Entscheidung:
7. Freigabe erteilt: ggf. mit Auflagen. Beispiel: „Plugin XYZ wird genehmigt, unter der Auflage dass es nur Leseberechtigungen nutzt und nur für Team A und B aktiviert wird. Keine Nutzung für personenbezogene Daten.“ Diese Auflagen werden in einem Freigabedokument festgehalten.
8. Ablehnung: Falls Risiken überwiegen oder Nutzen doch geringer als gedacht, wird der Antrag mit Begründung abgelehnt. Evtl. empfiehlt man Alternativen (z. B. „Verwendet lieber den vorhandenen Connector von Microsoft, nicht Plugin eines Dritten“).
9. Vertagung/Bedingte Freigabe: Manchmal will man noch mehr Infos (z. B. Hersteller muss erst Security-Fix liefern) -> dann wartet man ab und der Prozess pausiert bis erfüllt.

Die Entscheidung wird dem Antragsteller und dem IT-Operations-Team mitgeteilt.

1. Unternehmensweite Einführung (sofern freigegeben):
2. Das IT-Team rollt das Plugin gemäß Freigabebedingungen aus: z. B. im M365 Admin Center auf „Allow“ setzen, aber nur bestimmten Benutzergruppen zuweisen.
3. Die Nutzung wird ins Service-Katalog aufgenommen („Folgende Copilot-Plugins sind verfügbar: …“).
4. Nutzer werden informiert, z. B. per News: „Neues Copilot-Plugin X jetzt im Einsatz für Team A/B, erlaubt euch Y“.
5. Etwaige Dokumentation für Nutzer (wie benutze ich das Plugin) wird bereitgestellt.
6. Überwachung im Betrieb:
7. Nach Freischaltung beobachtet die IT-Security das Plugin besonders: Monitoring auf ungewöhnliche Traffic-Muster, Feedback von Nutzern einholen.
8. Der Fachbereich soll nach z.B. 1 Monat Rückmeldung geben: Mehrwert wie erwartet? Irgendwelche Schwierigkeiten?
9. Alle freigegebenen Plugins stehen unter „Probe“ bis zur nächsten Überprüfung.
10. Regelmäßige Review des Plugins/Connectors:
11. Mind. jährlich, oder bei relevanten Events (z.B. große Version-Update des Plugins), prüft das Governance-Team erneut:
    • Hat sich am Risiko was geändert? (Neuer Scope des Plugins, Vorfall passiert, Anbieter übernommen?)
    • Wird es tatsächlich genutzt und nützt es? (Wenn kaum Nutzung -> evtl. wieder deaktivieren, um Angriffsfläche zu reduzieren).
12. Ergebnis: Weiter betreiben wie bisher / Anpassungen (z. B. auf mehr Nutzer ausrollen, da stabiler Erfolg) / Decommision (falls obsolet oder riskant geworden).
13. Lebenszyklus-Ende:
14. Sollte ein Plugin nicht mehr den Anforderungen genügen oder nicht mehr gebraucht werden, entscheidet das Governance-Board die Deaktivierung.
15. Dann: Plugin im Admin Center auf „verboten“ setzen, Nutzer informieren („Plugin X wird zum 30.11. abgeschaltet, Grund…“), eventuell Alternativen anbieten.
16. Abschluss: Überprüfung, ob alle Daten, die Plugin evtl. extern gespeichert hat, sauber gelöscht / zurückgeholt werden (vertraglich regeln).

Dieser Prozess stellt sicher, dass kein Plugin/Connector unkontrolliert ins System kommt. Er beinhaltet Gatekeeper (Governance-Team), technische und Datenschutzchecks, einen sicheren Pilot und formale Abnahme. Obwohl etwas aufwendig, schützt er vor bösen Überraschungen und hält die Kontrolle über die wachsenden Fähigkeiten von Copilot.

Im Flussdiagramm (textuell beschrieben) würde das etwa so aussehen:

Antrag durch Fachbereich
   -> Governance-Team Vorprüfung
      -> (Abgelehnt?) -> Ende (Info an Antragsteller)
      -> (Ok) Detail Security/Privacy Check
         -> (Negativ?) -> Ablehnung (Info an Antragsteller)
         -> (Positiv) Pilot-Test in kleiner Umgebung
            -> Pilot-Ergebnis auswerten
               -> Governance-Entscheid Meeting
                  -> Ablehnung (Info)
                  -> oder Freigabe mit Auflagen
                        -> Implementierung/ Rollout Plugin
                        -> Nutzung + Monitoring
                           -> Jährliches Review
                              -> (weiter nutzen oder anpassen oder ausmustern)

So hat man für alle Fälle Dokumentation und einen revisionssicheren Pfad, wie Fremderweiterungen behandelt wurden.

10.4 Prompt-Standards (Struktur, Kontext, Quellenprüfung, Qualitätskriterien)

Eine Sammlung von Prompt-Standards kann Mitarbeitern helfen, bessere Anfragen an Copilot zu stellen und die Qualität der Antworten zu sichern. Hier ein Auszug solcher Standards, evtl. als interne Wiki-Seite oder Handout:

• 1. Kontext angeben: Beginnen Sie Ihre Anfrage mit dem relevanten Kontext. Copilot liefert deutlich präzisere Ergebnisse, wenn es weiß, worum es geht. Beispiel: Statt „Erstelle mir eine Zusammenfassung“ schreiben Sie „Erstelle mir eine Zusammenfassung des letzten Projektstatus-Reports vom Team Alpha“. Nennen Sie wichtige Details (Datum, Dokumenttitel, beteiligte Personen), sofern verfügbar.
• 2. Klare und konkrete Anweisungen: Formulieren Sie Ihre Prompts so spezifisch wie möglich. Vermeiden Sie Mehrdeutigkeiten. Schlecht: „Schreibe etwas über unseren Kunden.“ – Was „etwas“? Besser: „Schreibe eine 5-Punkte-Liste mit den neuesten Anforderungen, die Kunde XY diese Woche gestellt hat.“ Geben Sie Formatwünsche explizit an („in Stichpunkten“, „maximal 3 Sätze“).
• 3. Angabe der gewünschten Tiefe/Details: Teilen Sie Copilot mit, wie ausführlich die Antwort sein soll. Beispiel: „Fasse die Q3-Verkaufszahlen zusammen in 2 Sätzen.“ Oder: „Erkläre für einen Laien verständlich die Funktionsweise unseres Produktes.“ So steuern Sie Umfang und Tonfall der Antwort.
• 4. Quellen oder Datenbasis nutzen: Wenn möglich, verweisen Sie Copilot direkt auf vorhandene Unterlagen, damit es daraus schöpfen kann. Beispiel: „Basierend auf dem Bericht ‚Marktanalyse 2025‘, was sind die wichtigsten Trends?“ Copilot wird gezielt diesen Bericht heranziehen. Achten Sie darauf, dass Sie Zugriff auf die erwähnte Quelle haben (sonst kann Copilot nicht darauf zugreifen).
• 5. Antworten mit Belegen anfordern: Gewöhnen Sie sich an, Copilot nach Quellen oder Beispielen zu fragen. Beispiel: „Gib mir die Kennzahl X für 2023 und nenne die Datei, aus der du sie entnimmst.“ – So können Sie später die Richtigkeit prüfen. Wenn Copilot mal keine Quelle nennt, ist Vorsicht geboten: Dann unbedingt manuell nachverifizieren.
• 6. Schrittweises Verfeinern (Iteratives Prompting): Nutzen Sie die Möglichkeit, nach der ersten Antwort nachzuhaken. Beispiel: Zunächst: „Erstelle Entwurf für Kundenmail zur Lieferverzögerung.“ – Nach Antwort: „Bitte füge einen entschuldigenden Ton hinzu und erwähne einen Rabatt.“ Dies nähert das Ergebnis Ihren Vorstellungen. Geben Sie Feedback an die KI, wenn die Richtung noch nicht stimmt.
• 7. Verbotene Inhalte im Prompt: Nie nach persönlichen Daten Dritter fragen („Wie ist das Geburtsdatum von …“), keine Anweisungen geben, die ethisch oder rechtlich fragwürdig sind („Erstelle eine Abmahnung ohne HR-Beteiligung“). Unsere Systeme filtern solche Anfragen und es verstößt gegen Unternehmensregeln.
• 8. Qualitätscheck der Antwort: Prüfen Sie die KI-Antwort entlang folgender Kriterien:
• Fachlich korrekt? (Stimmen Zahlen/Fakten mit bekannten Quellen überein?)
• Vollständig? (Hat Copilot alle Teile der Frage beantwortet?)
• Angemessener Ton? (Entspricht der Schreibstil unseren Vorgaben, z.B. höflich und professionell?)
• Keine vertraulichen Details, die nicht hineingehören? (Evtl. hat Copilot interne Infos erwähnt, die nicht für den Empfänger bestimmt sind.)

Wenn ein Kriterium nicht erfüllt ist: entweder Prompt nachbessern oder Ausgabe manuell korrigieren/ verwerfen.

• 9. Lernende Bibliothek nutzen: Schauen Sie erst in unsere interne Prompt-Bibliothek (Link…), ob es für Ihr Anliegen bereits eine gute Vorlage gibt. Das spart Zeit und die Vorlagen wurden auf Qualität geprüft. Beispiele dort: „Meeting-Notiz zusammenfassen“, „Technische Fehlermeldung erklären“ etc. Sie können Vorlagen 1:1 übernehmen oder leicht adaptieren.
• 10. Feedback geben: Wenn Copilot etwas sehr gut gemacht hat oder falsch lag, nutzen Sie die Feedback-Funktion (Daumen hoch/runter in der Oberfläche) und/oder melden Sie es im Copilot-Community-Channel. So helfen Sie uns, das System und unsere Prompt-Bibliothek stetig zu verbessern.

Diese Prompt-Standards sollen in Fleisch und Blut übergehen. Im Zweifel denken Sie daran: Guter Input = Guter Output. Je gezielter und klarer Sie fragen, desto brauchbarer die Antwort.

(Qualitätssicherungstipp: Nutzen Sie bei wichtigen Texten die Regel „Korrekturlesen lassen“ – ggf. Copilot selbst: „Prüfe den obigen Text auf Fehler und verbessere die Formulierungen, ohne den Inhalt zu ändern.“ Aber verlassen Sie sich nie blind – der finale Qualitätscheck liegt bei Ihnen!)

10.5 Audit- und Nachweis-Vorlagen (Stichpunkte + Platzhaltertabellen)

Um im Prüfungsfall oder bei internen Reviews Nachweise schnell liefern zu können, empfehlen sich vorbereitete Dokumentationsvorlagen. Hier ein paar Stichpunkte, welche Nachweise typischerweise verlangt werden und wie man sie vorbereitet:

• 1. Übersicht der Copilot-Nutzung und Freigaben: Ein Dokument (Tabelle) das für einen Audit-Zeitraum (z.B. letztes Quartal) aufführt:
• Anzahl aktive Nutzer
• Anzahl verarbeiteter Anfragen
• eventuell beispielhafte Logs.

Vorlage-Auszug:
| Zeitraum | Aktive Copilot-Nutzer | Gesamt # Prompts | Davon mit sensiblen Inhalten (laut DLP) | Besondere Vorkommnisse | |———-|———————–|—————–|—————————————-|————————| | Q3 2025 | 350 (von 400 lizenziert) = 87,5% | ~18.000 | 12 vom DLP geblockt (0 echte Leaks) | 1 Fehlalarm DLP, keine Incidents |

• 2. Maßnahmen-Umsetzungsstatus (Compliance-Kontrollen): Eine Checkliste der im DPIA oder Risikoanalyse versprochenen Kontrollen mit Status. So sieht ein Prüfer sofort: „Alle vorgesehenen Schutzmaßnahmen umgesetzt?“.

Vorlage:
| Verpflichtende Maßnahme lt. DPIA | Soll-Termin | Verantwortlicher | Status am [Datum] | Erläuterung Nachweis | |———————————|————|——————|——————-|———————-| | Sensitivitätslabel für alle Dokumente einführen | 30.06.2025 | Data Governance Lead | ERLEDIGT (seit 05/2025) | Rollout-Bericht verfügbar, 95% aller Files gelabelt, siehe Anhang A. | | Betriebsvereinbarung mit BR abschließen | vor Go-Live Pilot | HR / Legal | ERLEDIGT (01.07.2025) | BV vom 01.07.2025 unterschrieben, siehe Anlage B. | | Schulung aller Nutzer (inkl. Test) | laufend vor Rollout jeweiliger Welle | Projektteam Schulung | TEILWEISE | Welle1+2 geschult (>98% Quote), Welle3 im Gange, Abschluss bis 15.12. | | … | … | … | … | … |

• 3. Prompt-/Output-Log Nachweis: Falls ein Prüfer stichprobenhaft sehen will, wie das System protokolliert, kann man vorab einige Logs aufbereiten (anonymisiert). Etwa ein Excel mit Spalten: Prompt (gekürzt), Datum, Nutzer-ID (anonym), verwendete Datenquellen, Ergebnis-Handling.

Vorlage Beispiel: (fiktive Daten)
| Log-ID | Datum/Zeit | Benutzer (ID) | Prompt-Auszug (gekürzt) | Genutzte Quellen (SharePoint, etc.) | Policy-konform? | Anmerkung | |——-|——————–|—————|—————————————-|—————————————-|—————–|———–| | 2025-09-15-001 | 15.09.2025 14:32 | user_123 (Mktg) | „Erstelle Zusammenfassung des Dokuments Q3_Report.pdf“ | Sales-Team-Site/Q3_Report.pdf (Intern) | Ja | – | | 2025-09-15-002 | 15.09.2025 14:35 | user_456 (HR) | „Liste mir alle Krankheitstage 2023 auf“ | Geblockt (HR-Tool Connector) | Verstoß geblockt | DLP-Regel griff, keine Daten ausgegeben. | | 2025-09-15-003 | 15.09.2025 14:40 | user_123 (Mktg) | Antwort: „Umsatz stieg um 5% …“ | – (Antwort generiert auf Basis interner Daten) | Ja | Antwort via Copilot an Mail übernommen, korrekt. |

(So eine Tabelle dient intern. Extern würde man Roh-Logs zeigen falls verlangt, aber sowas hilft Darstellung.)

• 4. Training & Awareness Nachweis: Etwa eine Liste oder Matrix, wer alles geschult wurde und wie (inkl. Punkte aus Abschlusstest).

Vorlage:
| Mitarbeitender | Abteilung | Schulungsmodul absolviert (Datum) | Testergebnis | Policy-Bestätigung erhalten (Ja/Nein) | |—————-|———–|——————————-|————–|————————————| | Max Mustermann | Vertrieb | E-Learning KI-Basics (12.08.25) <br> + Live-Session (15.08.25) | 85% (bestanden) | Ja (15.08.25 via LMS) | | … | … | … | … | … |

• 5. Incident-Bericht Vorlage: Für den Fall eines (auch kleinen) Zwischenfalls sollte ein Berichtschema existieren. Z.B.
• Beschreibung des Vorfalls (Datum, Beteiligte, was passierte?),
• Auswirkung,
• Sofortmaßnahmen,
• Abstellmaßnahmen um Wiederholung zu verhindern.

Vorlage-Kurzbericht:
Incident-ID: 2025-001-Copilot
Datum: 02.10.2025
Beschreibung: Copilot gab in einem Team-Chat mit externen Partnern eine vertrauliche Projektinfo preis (Dokument war fälschlich mit Gast-Rechten versehen). Externer hat Info gesehen, meldete sich verwundert.
Auswirkung: Klein. Info war nicht geschäftskritisch, aber vertraulich. Potenziell Vertragsverstoß NDA.
Ursache: Fehlkonfiguration Berechtigung + Copilot Graph suchte in allen sichtbaren Daten.
Sofortmaßnahme: Dokumentrechte sofort korrigiert, externen gegenüber als Versehen erklärt, Chat-Verlauf gelöscht. Copilot External-Search für diesen Tenant-Bereich temporär deaktiviert.
Dauerlösung: „Restricted Access“-Label für alle sensiblen Projekt-Doks eingeführt (bis 10.10. umgesetzt). Copilot erhält Update, Externe in Chats → nur projekt-lokale Suche. Schulung der Projektleiter zu Berechtigungen (geplant 20.10.).
Status: Abgeschlossen, Risiko reduziert.
Freigabe/Prüfung: CISO, DSB am 05.10. geprüft, keine Meldung an Aufsicht notwendig.

Solche Vorlagen und Tabellen sorgen dafür, dass man im Falle einer Prüfung (intern oder extern) nicht hektisch alles zusammensuchen muss. Man pflegt diese kontinuierlich und kann dem Auditor geordnet präsentieren: „Hier unsere Doku.“ Das unterstreicht Professionalität der Governance.

(Praxistipp: Nutzen Sie digitale Tools (SharePoint, Confluence, GRC-Software), um diese Nachweise aktuell zu halten. Z.B. ein Confluence-Bereich „KI-Governance-Audit“ wo alle oben genannten Tabellen als lebende Seiten existieren, immer gepflegt durch Owner. Bei Audit einfach exportieren.)

Damit ist ein vollständiges Set an praxisorientierten Hilfsmitteln gegeben: Von Policytexten über Mitarbeiterkommunikation bis zu Prozessen und Templates. Diese können eins-zu-eins oder angepasst übernommen werden, um in Ihrem Unternehmen Copilot-Governance nicht nur auf dem Papier, sondern ganz konkret im Alltag zu verankern.

FAQ (20 Fragen mit prägnanten, fundierten Antworten)

1) Was unterscheidet Copilot-Governance von allgemeiner IT-Governance?
Copilot-Governance fokussiert speziell auf den KI-gestützten Assistenten in Microsoft 365 und die damit einhergehenden neuartigen Herausforderungen. Allgemeine IT-Governance legt Rahmen für alle IT-Aktivitäten fest (z.B. Projektprioritäten, klassische Systeme), während Copilot-Governance ins Detail geht, wie generative KI im Unternehmen verantwortungsvoll genutzt wird. Sie berücksichtigt Aspekte wie Datenzugriff via KI, Prompt-Richtlinien, KI-spezifische Risiken (Halluzinationen, Bias) – Themen, die in der herkömmlichen IT-Governance so nicht abgedeckt sind. Copilot-Governance ist also ein spezialisierter Ausschnitt, der die Grundprinzipien der IT-Governance (Transparenz, Kontrolle, Wertbeitrag) auf die KI-Nutzung anwendet. Beispiel: In der IT-Governance mag stehen „Schütze vertrauliche Daten“, die Copilot-Governance definiert konkret, wie Copilot das gewährleisten muss (z.B. Sensitivity Labels, DLP-Regeln bei KI-Ausgaben).

2) Wie verhindere ich Datenabfluss über Prompts und Antworten?
Datenabfluss verhindern wir durch eine Kombination aus technischen und organisatorischen Maßnahmen. Erstens: Zugriffsbeschränkungen. Copilot sieht nur Inhalte, auf die der Nutzer ohnehin Berechtigung hat – also haben wir Berechtigungen streng nach Need-to-know eingestellt und besonders vertrauliche Bereiche von vornherein aus dem KI-Zugriff rausgenommen. Zweitens: DLP-Filter. Unsere Data Loss Prevention Regeln scannen die Ausgaben – wenn z.B. jemand versuchen würde, per Copilot vertrauliche Kundendaten nach außen zu schicken (sei es E-Mail oder Teams mit Externen), blockt die DLP-Engine automatisch oder warnt zumindest. Drittens: Schulung der Nutzer. Wir machen klar: Keine sensiblen Daten unnötig in Prompts eingeben! Und erst recht keine KI-Antwort mit internen Infos unbedacht weiterleiten. Zudem protokollieren wir alle KI-Aktivitäten – das wirkt abschreckend auf potenzielle „Insider“. Last but not least: Einstellungen im System. Wir haben z.B. externe Plugins, die Daten rausfunken könnten, erstmal deaktiviert. All das zusammen minimiert das Risiko, dass etwas „rausfließt“. Bislang hat unser Monitoring auch keinen ungewollten Abfluss registriert.

3) Welche Mindestvoraussetzungen im M365-Tenant sind Pflicht?
Bevor wir Copilot einschalten, mussten einige Basics stimmen: MFA für alle – Multi-Faktor-Auth ist ein Muss, damit kein unbefugter Zugriff auf das KI-Feature erfolgt (sonst könnte ein gehacktes Konto über Copilot massig Daten abziehen). Audit-Logging musste aktiviert sein, damit wir jede KI-Aktion nachvollziehen können. Wichtig war auch, dass Sensitivity Labels und DLP in Microsoft 365 schon eingerichtet sind – ohne Klassifizierung kein gezielter Schutz. Außerdem brauchten wir die technischen Copilot-Voraussetzungen: ausreichende Lizenzen (Microsoft 365 E3/E5 mit Copilot-AddOn), ein konfigurierter Semantic Index (damit Copilot unsere Daten durchsuchen kann) und aktuelle Office-Client-Versionen bei den Nutzern. Ebenfalls Pflicht: Tenant-Setting checken – etwa sicherstellen, dass die Option „User Feedback an Microsoft senden“ den Datenschutzrichtlinien entspricht (wir haben sie z.B. abgeschaltet). Und natürlich: Zustimmung der Stakeholder (Betriebsrat etc.). Zusammengefasst: Sicherheit (MFA, Logs), Compliance (Labels, DLP, DPIA) und die technischen Enablements (Lizenzen, Index) mussten stehen, bevor es losging.

4) Wie definiere ich eine wirksame Datenklassifikation für Copilot?
Im Prinzip genauso, wie man es ohne KI tun sollte – nur mit noch mehr Konsequenz. Eine wirksame Datenklassifikation bedeutet: Wir haben klare Kategorien (z.B. Öffentlich, Intern, Vertraulich, Streng Vertraulich) und wirklich alle relevanten Informationen werden entsprechend gelabelt. Für Copilot haben wir speziell darauf geachtet: Streng vertrauliche Daten tragen ein Label, das Copilot entweder komplett ignoriert oder zumindest nicht ohne Weiteres in Antworten einfließen lässt. Beispiel: Dokumente mit „Streng Vertraulich – Geschäftsführung“ sind aus dem durchsuchbaren Index ausgeschlossen. Wichtig war auch, automatische Klassifizierung zu nutzen – KI greift ja auf Unmengen unstrukturierter Daten zu, da kann man nicht alles manuell labeln. Wir nutzen daher Microsoft Purview (und teils ein Zusatztool), das z.B. personenbezogene Inhalte automatisch als „Vertraulich“ markiert. Zudem haben wir in der Klassifikationspolicy definiert, dass bei bestimmten Labels Copilot gar keine Ausgabe machen darf – etwa „Zum nur intern, nicht via KI teilen“. Kurz gesagt: Wir haben unser bestehendes Schema auf KI abgestimmt, alle Mitarbeiter nochmals sensibilisiert, konsequent zu labeln, und technische Auto-Labeler im Hintergrund laufen. Das Ergebnis: Copilot weiß anhand der Labels, was er zeigen darf und was nicht – und das ist der Schlüssel, dass er wirksam ‚zensiert‘ ist, ohne dass wir jede Antwort manuell prüfen müssen.

5) Welche Rolle spielt der Betriebsrat und wie binde ich ihn ein?
Der Betriebsrat ist hier ein zentraler Partner – wir haben ihn frühzeitig ins Boot geholt. Bei uns war Copilot eindeutig mitbestimmungspflichtig, weil es um Verhaltens- und Leistungskontrolle gehen könnte (Stichwort: Protokollierung von Nutzereingaben, neues Tool am Arbeitsplatz). Wir haben daher mit dem Betriebsrat eine Betriebsvereinbarung ausgehandelt, in der genau steht, was Copilot darf und was nicht – insbesondere, dass keine personenbezogenen Leistungsdaten ausgewertet werden (also wir nutzen die Logs nicht, um Mitarbeiter zu überwachen). Der Betriebsrat hat auch darauf geachtet, dass Schulungen stattfinden und dass die Mitarbeiter über die KI-Nutzung Bescheid wissen (Transparenz). Praktisch haben wir den Betriebsrat schon in der Pilotphase involviert: Er durfte Fragen stellen, hat Pilot-Feedback gesehen und wir haben seine Anregungen – z.B. ein Opt-out für einzelne Nutzer falls jemand große Bedenken hätte – geprüft (bisher wollte aber niemand opt-out, weil wir Bedenken ausräumen konnten). Kurz: Der Betriebsrat fungiert als Stimme der Mitarbeiter in diesem Projekt, hilft Vertrauen zu schaffen und achtet auf die Einhaltung von Arbeitnehmerrechten. Ihn einzubinden war nicht nur Pflicht, sondern auch hilfreich: So haben wir etwa beim Thema „Keine anonymen Logs“ gemeinsam eine Lösung gefunden. Wenn man offen und früh kommuniziert („Wir wollen KI einführen, aber verantwortungsvoll – lasst es uns zusammen regeln.“), klappt die Zusammenarbeit sehr konstruktiv.

6) Wie messe ich Produktivitätsgewinne und Qualität?
Das Messen von Produktivitätsgewinnen ist zugegeben herausfordernd, weil Copilot die Arbeit eher erleichtert als komplett ersetzt. Wir gehen zweigleisig vor: quantitativ und qualitativ. Quantitativ haben wir bestimmte KPIs definiert – zum Beispiel schauen wir uns an, wie lange bestimmte Prozesse vorher dauerten und nachher mit KI-Hilfe. Ein Beispiel: Angebotserstellung dauerte früher im Schnitt 5 Stunden, mit Copilot vielleicht 4 Stunden – das wäre ein 20% Zeitgewinn, den wir hochrechnen können. Solche Daten bekommen wir durch Zeitaufschreibung oder Tool-Metriken (manche Anwendungen loggen Bearbeitungszeiten). Nicht immer gibt’s harte Zahlen, daher ergänzen wir das durch Mitarbeiterumfragen: Wir fragen die Nutzer, wie viel Prozent ihrer Aufgaben sie glauben, dank Copilot schneller zu erledigen, oder ob sie durch Copilot Zeit für andere Aufgaben gewinnen. Das geben sie in Schätzungen an („Ich spare ca. 2h pro Woche“). Aggregiert ergibt das ein Bild. Die Qualität messen wir u.a. an der Fehlerquote: Wir tracken z.B., wie oft KI-Inhalte vor dem Versand korrigiert werden mussten oder wie häufig Fachvorgesetzte KI-Ergebnisse zurückweisen. Zudem betreiben wir Stichprobenkontrolle: ein Qualitätsteam schaut sich zufällig KI-generierte Dokumente an und bewertet, ob sie standardkonform und korrekt sind. KPI dafür wäre z.B. „90% der stichgeprüften KI-Briefe waren einwandfrei“. Und nicht zuletzt: Feedback von Kunden oder internen Empfängern. Bekommt der Kundenservice z.B. weniger Rückfragen, weil Antworten klarer sind? Alles Indikatoren. Fazit: Es gibt keinen einen Messwert „Produktivität++“, sondern wir kombinieren Prozess-KPIs, Nutzereinschätzungen und Qualitätsstatistiken. Das Management-Dashboard (siehe Kapitel 8) fasst das zusammen – und bisher sehen wir erfreuliche Trends (z.B. 30% schnellere Erstellung regelmäßiger Berichte laut Fachbereich).

7) Wie gehe ich mit Halluzinationen und Falschinformationen um?
Halluzinationen – also frei erfundene oder falsche Antworten – sind eine bekannte KI-Schwäche, daher haben wir da klare Gegenmaßnahmen. Zuerst: Nutzer sensibilisieren. Wir haben geschult: Verlasse dich nicht blind, prüfe Fakten nach. Insbesondere haben wir die Regel aufgestellt, dass alle kritischen Inhalte (für Entscheidungen, für Kunden) mindestens eine Zweitprüfung benötigen. Praktisch heißt das: Entweder der Bearbeiter selbst verifiziert jeden wichtigen Punkt oder holt eine Kollegenabnahme ein. Das mag in 90% der Fälle redundant sein, aber es verhindert den einen schlimmen Ausrutscher. Zweitens: Quellen verlangen. Copilot ist so eingestellt bzw. wird so genutzt, dass bei Fakten nach Möglichkeit Quellen angegeben werden (z.B. Dateiname, wo es das gefunden hat). So kann man direkt nachschauen, ob das stimmt oder ob KI sich irrte. Drittens: Datenqualität verbessern. Oft halluziniert KI, wenn es keine guten Unternehmensinfos hat. Wir pflegen daher unsere Wissensbasis: veraltete oder doppeldeutige Dokumente raus, wichtige Infos klar gekennzeichnet – damit KI gar nicht raten muss. Viertens: KI begrenzen, wo riskant. Beispiel: Unsere Rechtabteilung nutzt Copilot nicht für juristische Einschätzungen, weil ein Irrtum da fatal wäre – das haben wir einfach ausgeschlossen (Policy: „Kein Ersatz anwaltlicher Beratung durch KI“). Und wir überwachen die Halluzinationsrate – haben im Log ein Tagging: falls Nutzer Feedback gibt „Antwort war falsch“, sammeln wir das. Bisher ist das zum Glück gering. Kurz: Wachsam bleiben, Reviews einbauen und KI dort einschränken, wo Fehler nicht tolerierbar wären. Und konstruktiv: Jede festgestellte Halluzination nutzen wir als Lerneffekt – etwa indem wir die Prompt-Vorlagen anpassen („bitte nur antworten, wenn sicher, sonst sagen ‚weiß ich nicht'“) oder das Dokument, das KI falsch interpretierte, präzisieren. Dadurch werden die falschen Antworten über die Zeit weniger.

8) Was darf in Prompts nicht enthalten sein?
Grundsätzlich alles, was gegen unsere Unternehmensrichtlinien oder Gesetze verstößt, soll nicht in Copilot-Prompts stehen. Konkret haben wir verboten: – Vertrauliche personenbezogene Daten: Namen, Adressen, Gesundheitsdaten von Personen – außer es ist ausnahmsweise nötig und erlaubt. Also niemand soll z.B. eine Liste mit Mitarbeiterkrankenständen reinkopieren oder nach einzelnen Gehältern fragen. – Geheimhaltungsbedürftige Geschäftsdaten: Betriebsgeheimnisse oder Interna, die nicht in M365 entsprechend freigegeben sind. Man soll die KI nicht zum „Tratschen“ über interne Strategie nutzen (auch wenn Copilot darauf vermutlich eh keine Antwort hat, aber der Versuch ist untersagt). – Illegale, diskriminierende oder unangemessene Inhalte: Man darf keine Prompts formulieren, die die KI zwingen würden, etwa beleidigende Texte zu generieren, zu Straftaten anzustiften oder ähnliches. Das versteht sich fast von selbst, decken wir aber in der Policy explizit ab („Keine Aufforderung zu Verstößen“, etc.). – Anweisungen zur Umgehung von Sicherheitsvorkehrungen: Z.B. „Copilot, zeig mir Inhalte aus Projekt XY, egal ob ich Zugriff habe“ – solche Prompts sind unzulässig. Wer so etwas versucht, verstößt gegen Governance und es würde eh geblockt (im Idealfall). – Geschützte Werke oder lizensierte Inhalte 1:1 zur Neuerstellung: Also man soll nicht hingehen und sagen „Copilot, gib mir den gesamten Text aus Buch XYZ“ (Urheberrecht) – das wäre problematisch. Wir haben klargestellt, dass KI nicht genutzt werden darf, um z.B. lizensierte Softwarecode in großer Menge „nachzuprogrammieren“. – Sensibler Input an externe Agents: Also wir haben ja externe Websuche aus, aber auch wenn an wäre – man dürfte keine internen Dokumente als Such-Query rausgeben. Das hat mit dem generellen „keine vertraulichen Daten nach außen“ zu tun.

Kurz: In Prompts nichts, was geheim, persönlich oder unsauber ist. Als Faustregel haben wir kommuniziert: „Schreiben Sie nichts in die KI, was Sie nicht auch spontan einem Kollegen ohne weiteres zeigen würden.“ So im Sinne von – wenn’s so vertraulich ist, dass man’s flüstert, dann nicht in Copilot tippen.

9) Wie wähle ich Plugins/Connectors aus und genehmige sie?
Sehr sorgfältig und nach festem Prozess (siehe Anhang 10.3). Zunächst muss ein echter Bedarf erkannt sein – entweder von einer Fachabteilung gemeldet oder vom Governance-Team identifiziert (z.B. „Viele wünschen sich JIRA-Daten in Copilot“). Dann durchläuft das Plugin einen Prüfprozess: – Sicherheits-Check: Wer ist Hersteller? Welche Berechtigungen braucht es? Wir schauen uns evtl. den Code oder lassen ein Testlauf durch unsere Security-Tools laufen. – Datenschutz-Check: Wohin fließen Daten? Bleiben sie in unserem Tenant? Brauchen wir AV-Vertrag mit Drittanbieter? Das DSB-Team prüft das. – Funktions-Check: Passt es technisch in unsere Landschaft (keine Konflikte, ausreichende API-Limits etc.). Nur wenn all das ok ist, geht’s weiter. Oft machen wir dann einen Pilot mit dem Plugin: erst mal nur aktiv für 1-2 Testuser, die sehen „funktioniert es, wie erwartet?“ Erst wenn auch das ohne rote Flaggen ist, entscheidet das Governance Board offiziell die Zulassung. Wir pflegen eine Whitelist im Admin-Center: default sind alle Plugins off, nur erlaubte werden aktiv gesetzt. Ähnlich für Graph Connectors: nur genehmigte Connectoren sind installiert. Dokumentation ist wichtig: zu jedem genehmigten Plugin haben wir einen Steckbrief („Name, Version, Quelle, Zweck, genehmigt am…, Auflagen: z.B. nur read-only“). Auch nach Freigabe: nicht vergessen, wir beobachten die Nutzung – falls z.B. ein Plugin kaum genutzt wird, könnte man es wieder abschalten; falls es Probleme macht (Crashes, Security Incident), entziehen wir die Freigabe. Der Auswahlprozess ist streng, weil jedes Plugin eine potentielle Einfallstür ist. Bisher haben wir z.B. nur 2 Plugins zusätzlich erlaubt (ein Microsoft-verified für DevOps und einen eigenen internen Connector). Lieber vorsichtig herantasten.

10) Wie steuere ich externe Zusammenarbeit mit Partnern?
Das ist sensibel, weil Copilot intern gut funktioniert, aber sobald Externe im Spiel sind, muss man streng trennen. Wir haben klare Richtlinien: In jedem Team/Projekt, wo externe Partner (Gastaccounts) drin sind, haben wir festgelegt, welche Daten dort liegen dürfen und welche nicht – Copilot hält sich dann automatisch daran, weil es nur die freigegebenen Infos durchsucht. Konkret: Wir haben z.B. separate Kollaborations-Teams für Partner, wo nur die notwendigen Dokumente drin sind; alles Hochsensible bleibt in rein internen Bereichen. Zudem haben wir im System konfiguriert (via „Information Barriers“ und Conditional Access), dass Copilot in Anwesenheit externer User sozusagen auf „Sparflamme“ läuft. Beispiel: In einem Meeting-Chat mit externen haben wir die Einstellung, dass Copilot keine unternehmensweite Suche macht, sondern nur innerhalb des freigegebenen Projektteams bleibt. So kann er gar nicht versehentlich interne Daten ins gemischte Meeting tragen. Außerdem gilt: Externe selbst haben keinen Copilot-Zugang bei uns. Ein Partner, der als Gast im Tenant ist, sieht das Copilot-Icon nicht und kann ihn nicht ansprechen. Das war eine bewusste Entscheidung, um Datenlecks zu vermeiden – Partner könnten sonst Copilot über uns nutzen, das war uns zu heikel. Wenn ein Partner KI-Unterstützung will, muss er es in seiner Umgebung tun. Natürlich haben wir all das auch in den Zusammenarbeits-Vereinbarungen festgehalten: Partner wurden informiert, dass wir KI-Tools einsetzen (Transparenz), aber dass wir auch Vorkehrungen haben, dass sie darüber nicht unautorisiert Infos erhalten. Zusammengefasst: Strikte Daten-Segmentierung, technische Schranken im Mixed-Mode, und Externe kriegen unser Copilot gar nicht in die Hände. So können wir weiterhin gut kooperieren, ohne plötzlich Schleusen zu öffnen. Falls es mal einen legitimen Grund gäbe, einem Partner KI-Einblick zu geben, würden wir das einzeln prüfen und sicher sehr eingeschränkt erlauben.

11) Wie setze ich DLP, Aufbewahrung und eDiscovery sinnvoll ein?
Wir haben unsere bestehenden Compliance-Werkzeuge einfach auf den neuen Anwendungsfall ausgedehnt. – DLP (Data Loss Prevention): Wie erwähnt, überwacht Content, der z.B. per Mail oder Teams nach außen geht. Wir haben die DLP-Regeln so angepasst, dass sie auch in KI-generierten Inhalten nach Mustern suchen (z.B. Kreditkartennummern, personenbezogene Schlüsselwörter). Speziell haben wir eine Regel „Wenn ein interner Chat mit Copilot-Inhalt an einen externen Empfänger geht und das Wort ‚Vertraulich‘ enthält -> blockieren und Supervisor informieren.“ Solche Feinheiten sind drin. – Aufbewahrung: Wir behandeln KI-Outputs im Prinzip wie normale Dokumente oder Mails: Es gibt Retention Policies, z.B. alles was in Exchange liegt, 6 Jahre, etc. Das musste um Chat und Copilot-Inhalte erweitert werden. Unsere KI-Chatverläufe (Business Chat in Teams) haben wir einer Aufbewahrungsrichtlinie zugeordnet, analog zu Teams-Chats (bei uns z.B. 1 Jahr). Wenn Copilot einen wichtigen Inhalt liefert (z.B. Meeting Minutes), dann speichert der Nutzer das ohnehin als Datei, die dann regulär ins Records-Management fällt. Zusätzlich haben wir mit dem Archivierungstool (Smarsh bei uns) eine Integration getestet: Damit werden alle Copilot-Interaktionen „WYSIWYG“ archiviert. Das war speziell für unseren Finanzbereich wichtig (Nachvollziehbarkeit von Beratungsdialogen). Kurz: Die Aufbewahrungspflichten erfüllen wir, indem wir KI-Inhalte denselben Policies unterwerfen wie menschliche Inhalte – aber wir mussten technisch sicherstellen, dass sie auch erfasst werden (Stichwort: Indizierung der Copilot-Logs ins Archiv). – eDiscovery: Wir haben die eDiscovery-Tools so eingestellt, dass sie die neuen Content-Typen (Teams Chats, Copilot Activity Logs) ebenfalls durchsuchen. Der Rechtsabteilung haben wir gezeigt, wie man z.B. in einer Litigation-Suche auch KI-Chats einbezieht. Bisher gab es noch keinen echten Fall, aber wir sind vorbereitet. Im Endeffekt nutzen wir hier die Power der Microsoft Purview Suite voll aus: was man an Compliance-Features (DLP, Retention, Audit) einschalten konnte, haben wir eingeschaltet oder angepasst. „Sinnvoll einsetzen“ heißt: Dieselben Prinzipien (nichts geht raus, was nicht darf; alles was als Record gelten könnte, wird konserviert) 1:1 auf KI anwenden. Der Teufel steckte in der Technik: Wir mussten z.B. erst rausfinden, dass Copilot-Chat-Inhalte als spezielles Item im Compliance Center auftauchen – aber jetzt wo wir’s haben, läuft es.

12) Welche Audit-Nachweise werden erfahrungsgemäß verlangt?
Bei Audits (sei es interne Revision, externe Prüfer oder Datenschutzbehörde) wollen die Prüfer vor allem sehen, dass wir Kontrolle über das Tool haben und Datenschutz/Sicherheit einhalten. Typische Nachweise: – Das Regelwerk: Also die Richtlinien/Betriebsvereinbarung. Ein Auditor will oft zuerst das Policy-Dokument sehen: „Gibt es schriftliche Regeln, wie KI genutzt wird?“. Da legen wir unsere Copilot-Policy und ggf. Auszüge aus IT-Security-Policy vor, wo KI erwähnt ist. – DPIA (Datenschutz-Folgenabschätzung): Wenn die DS-Behörde kommt, möchte sie die Dokumentation, dass wir die Risiken für personenbezogene Daten bewertet und behandelt haben. Diese DSFA haben wir parat (mit Risiken, Maßnahmen, Unterschrift DSB). – Schulungsnachweise: Revisoren fragen gerne: „Wurden denn alle Mitarbeiter informiert?“ – Dann zeigen wir z.B. Listen aus dem LMS (wer hat Schulung abgeschlossen) oder E-Mail-Bestätigungen, dass die Regeln kommuniziert wurden und akzeptiert sind. – Protokolle / Berichte der Governance: Zum Nachweis der Effektivität zeigen wir z.B. das quartalsweise Dashboard oder Protokolle des KI-Governance-Boards. Darin steht, welche KPI-Werte vorlagen und welche Beschlüsse wir gefasst haben („z.B. Plugin X abgelehnt am 12.09.“). Das beweist, dass wir aktiv steuern und reagieren. – Technische Konfigurationsberichte: Ein IT-Auditor könnte stichprobenartig einen Export der DLP-Regeln oder der Sensitivity-Label-Policy verlangen, um zu schauen, ob die eingestellt sind, wie wir behaupten. Da haben wir vorsorglich Screenshots und Config-Exports in einem Audit-Ordner gesammelt. – Risikoregister & Maßnahmenstatus: Die Revision liebt Tabellen. Unser Risikoregister (siehe Kapitel 9) kann man vorzeigen – es belegt, dass wir uns systematisch Gedanken gemacht haben, inkl. Ampelstatus, was wir noch abarbeiten. – Event-Nachweis: Sollte ein konkreter Zwischenfall passiert sein, will ein Prüfer wissen: wie habt ihr reagiert? Dafür liegt ein Incident-Report vor (Wann, was, wie gelöst, Lessons Learned). – Zugriffskontrolle: Möglicherweise Nachweise, dass nur berechtigte Nutzer KI haben (Lizenz-Zuweisungsliste) und dass jemand zustimmt, dass die Berechtigungen passen (z.B. Freigabe-E-Mail vom Vorgesetzten). Kurzum: Alles, was wir im Kapitel 10.5 beschrieben haben. Erfahrungsgemäß waren die internen Revisoren z.B. sehr an den Logging-Protokollen interessiert („Zeigt mal, was da geloggt wird, und ob das datenschutzkonform ist“). Externe Prüfer (DSB) wollten eher Konzeptpapiere – DPIA, Richtlinie, Schulung – um zu sehen, ob wir organisatorisch vorgesorgt haben. Da wir das alles schön geordnet hatten, konnten wir die Nachweise ohne Hektik liefern.

13) Wie baue ich eine Prompt-Bibliothek und sichere deren Qualität?
Wir sind das angegangen, indem wir erstmal gesammelt haben: Welche Anfragen stellen unsere Leute am häufigsten an Copilot? Daraus haben wir, zusammen mit den Fachbereichen, „Muster-Prompts“ formuliert, die besonders gut funktionieren. Der Aufbau lief so: – Input sammeln: Pilotnutzer und Champions haben uns ihre besten Prompts geschickt („Schau mal, so frage ich nach Meeting-Minutes, funktioniert super.“). Auch Fehlversuche („So lieber nicht fragen!“) haben wir notiert. – Erstellung der Bibliothek: Das Governance-Team (mit Kommunikatoren und Fachexperten) hat diese Rohsammlung dann überarbeitet – die Prompts vereinheitlicht, sprachlich glattgezogen und mit Beispielen versehen. Jede Vorlage hat einen Titel („Verhandlungsprotokoll zusammenfassen“) und ggf. Hinweise, wann einzusetzen. – Qualitätssicherung der Vorlagen: Jede Prompt-Vorlage haben wir getestet: Mehrfach ausgeführt (mit verschiedenen Datensätzen) um sicherzugehen, dass verlässlich was Gutes rauskommt und keine problematischen Nebeneffekte. Ein Fachverantwortlicher hat zudem gegengecheckt: liefert diese Vorlage die inhaltlich korrekten Ergebnisse? Erst dann kam es in die offizielle Bibliothek. – Zugänglich machen: Wir haben die Bibliothek im Intranet publiziert – übersichtlich nach Kategorien (E-Mail, Bericht, Meeting, Code, etc.). In Teams haben wir sogar einen kleinen „Prompt-Hilfe“-Bot gebaut: Wenn man z.B. @PromptHelp Angebotsentwurf eingibt, spuckt er die entsprechende Vorlage aus. So müssen Nutzer nicht das Dokument wälzen. – Pflegeprozess: Wichtig: Einmal erstellt reicht nicht. Wir haben Redakteure (aus dem Governance-Team), die Feedback sammeln – z.B. „Vorlage X liefert mit neuem Copilot-Update nicht mehr ideale Ergebnisse“ – dann aktualisieren wir sie. Oder wenn neue Use Cases auftauchen (z.B. „Erstelle Quizfragen aus Text“), ergänzen wir eine Vorlage. – Qualität messen: Wir schauen, ob die Leute die Bibliothek nutzen (Klickzahlen oder wie oft der Bot bemüht wird). Und wir fragen nach: „Fandet ihr die Vorlagen hilfreich, hat es Zeit gespart, waren Ergebnisse richtig?“ Bisher sehr positives Feedback – vielen ist z.B. erst durch die Vorlagen klar geworden, was man alles fragen kann. Also, die Qualität sichern wir, indem wir jede Vorlage praxisgetestet haben und indem wir die Bibliothek lebendig halten (regelmäßige Reviews, vmtl. quartalsweise). Auch intern: bevor eine neue Vorlage freigegeben wird, prüft nochmal ein 4-Augen-Team (so wie mini-Policy-Abnahme) – damit kein Unsinn reinkommt. Kurz: Man braucht etwas Aufwand am Anfang (Brainpower, Testläufe), aber es lohnt sich, weil so alle Nutzer von den „Best Prompts“ profitieren und nicht jeder experimentell selber herumprobieren muss – und gleichzeitig minimiert es Fehlanwendungen.

14) Wie adressiere ich Urheber- und Nutzungsrechte an generierten Inhalten?
Das ist ein neues Feld, aber wir haben ein paar Grundsätze definiert: Erstens haben wir intern klargestellt, dass generierte Inhalte, die in Ausübung der Arbeit entstehen, dem Unternehmen gehören – so wie normale Arbeitsergebnisse auch. D.h. wenn Copilot z.B. einen Textvorschlag erstellt und der Mitarbeiter den übernimmt, betrachtet das Unternehmen diesen Text als eigenes Werk (ohne Anspruch des Mitarbeiters auf „Urheber“ etc., was bei KI ohnehin schwierig wäre). Das haben wir vorsichtshalber in die Nutzungsrichtlinie geschrieben, damit es da keine Missverständnisse gibt. Zweitens haben wir das Thema Copyright Dritter angegangen: Wir wissen, dass KI-Modelle auf Trainingsdaten basieren, bei denen urheberrechtlich geschütztes Material drin sein könnte. Also haben wir eine Policy: „Falls Copilot längere Texte oder Code generiert, muss geprüft werden, ob das aus einer geschützten Quelle stammen könnte.“ In der Praxis war das bisher kaum der Fall – Copilot erstellt meistens neue Formulierungen. Aber z.B. im Entwicklermodus, wenn mal eine Standardfunktion generiert wird, haben wir geraten: achtet drauf, ob das 1:1 aus StackOverflow o.Ä. zu kommen scheint. Wir haben auch Microsofts Zusicherungen geprüft: Angeblich nutzt Copilot (anders als ChatGPT frei) unsere Daten & GPT-Modell, aber gibt aus Trainingsdaten keine langen Passagen eins zu eins aus. Das Risiko schätzen wir gering, aber trotzdem: In der Anleitung für Mitarbeiter steht „Verwendet keine KI-Ausgaben extern, wenn ihr Zweifel habt, ob der Inhalt wirklich ’neu‘ ist – lieber einmal umformulieren.“ Praktisch haben wir einen Fall durchgespielt: Copilot schlug uns einmal einen Slogan vor, der sehr nahe am Claim eines Mitbewerbers war. Da haben wir entschieden, den nicht zu nutzen, weil falls der aus dessen Marketing stammt, könnte das heikel sein. Zusammenfassend: Interne Rechte geklärt (Unternehmen hat Nutzungsrecht an KI-Ergebnissen der Mitarbeiter), Externe Rechte auf dem Radar (Mitarbeiter müssen aufpassen & im Zweifel an Legal wenden), und wir generieren lieber „faktenbasiert“ auf unseren Daten, um Plagiate zu vermeiden. Sollte in Zukunft mal eine Rechtesfrage aufpoppen (z.B. „KI hat aber ein geschütztes Lied zitiert“), würden wir Einzelfallprüfung machen und notfalls das KI-Feature anpassen, dass es sowas blockt. Aber Stand jetzt sind uns keine Rechteverletzungen durch Copilot passiert.

15) Welche KPIs und KRIs sind praxistauglich?
Zum Start haben wir uns auf einige Kern-KPIs/KRIs fokussiert, die wirklich den Zustand der KI-Nutzung widerspiegeln: – Nutzungsintensität (KPI): z.B. Anzahl Anfragen pro Nutzer pro Woche. Das zeigt uns, ob Copilot überhaupt angenommen wird. Ist praxistauglich, weil wir’s direkt aus dem Log ziehen können. – Zeiteinsparung (KPI): Das versuchen wir, wie gesagt, über Umfragen/Prozessmessung zu quantifizieren (z.B. „Durch Copilot 20% schneller in Vorgang XY“). Nicht 100% exakt, aber ausreichend, um Tendenzen zu sehen. – Zufriedenheits-Score (KPI): Wir haben einen einfachen Feedback-Mechanismus: Benutzer können nach einigen Wochen Nutzung einen Score 1-5 abgeben, wie hilfreich sie Copilot finden. Der Durchschnittswert ist ein KPI. Der ist praxistauglich, weil qualitatives Summengefühl, ob es gut ankommt. – Fehler/Halluzinationsrate (KRI): Wir tracken z.B. „Wie oft wurde eine KI-Antwort als fehlerhaft markiert?“ (Nutzer können in Teams Daumen runter drücken und Grund angeben). Das ist praxistauglich in dem Sinne, dass wir extrem unklare Ausreißer sehen würden. – DLP-Blockings (KRI): Zahl der geblockten Events, wo KI-Output heikel war. Das ist ein direkter Tech-Indikator, gut messbar. Wenn der hochginge, wüssten wir, da hapert’s. – Supportaufkommen (KPI/KRI): Wieviele Tickets zum Thema KI kommen. Wenig Tickets = entweder läuft gut oder niemand nutzt es. In Kombi mit Nutzungs-KPI interpretierbar. Ist praxistauglich und aus Helpdesk-System zu ziehen. – ROI (KPI): Verhältnis Nutzen/Kosten. Der ist natürlich auf Schätzungen basierend, aber im Business-Case will das Management solche Indikatoren. Also kalkulieren wir intern „gesparte Stunden * interner Stundenkostensatz vs. Lizenzkosten etc.“ Das ist grob, aber für Trend okay. – Einhaltungsindikatoren (KRI): z.B. Prozentsatz der Nutzer, die Schulung absolviert haben. Oder Zahl der Policy-Verstöße (z.B. Nutzer hat sensible Daten eingegeben, was protokolliert wurde). Diese sind praxistauglich, weil wir es im LMS und Logs sehen können. Alle diese sind ja in 8.1 tabellarisch aufgeführt. Bislang hat sich gezeigt, dass vor allem Nutzungsgrad, DLP-Events und Supporttickets sehr aussagekräftig sind: Z.B. sahen wir, Nutzungsgrad stieg stark an, DLP-Events blieben Null -> super! Oder einmal stieg Tickets an („KI antwortet komisch auf X“), was uns zeigte, wir müssen ne Schulung nachbessern. Man sollte es nicht überfrachten: Lieber 8-10 Kennzahlen, die wir zuverlässig erfassen können, als 30 theoretische. Die genannten sind definitiv praxistauglich und decken sowohl Nutzen als auch Risiko gut ab.

16) Wie organisiere ich Support und Incident-Management?
Wir haben Copilot in unser normales IT-Supportmodell integriert, mit ein paar Besonderheiten. Für den 1st-Level-Support (Helpdesk) haben wir die Mitarbeiter mit FAQ-Artikeln ausgerüstet – d.h. sie wissen, was die häufigsten Copilot-Fragen/Probleme sind (z.B. „Ich sehe das Icon nicht“ -> wahrscheinlich keine Lizenz; „Copilot sagt, er hat keinen Kontext“ -> dem Nutzer erklären, dass er eine Datei öffnen muss etc.). Vieles ließ sich antizipieren. Der Helpdesk kann also grundlegende Fragen beantworten. Wenn es technisch tiefer geht, haben wir 2nd-Level im M365-Team: Die Spezialisten, die Tenant-Einstellungen prüfen können, Logs anschauen etc. Also z.B. wenn ein Nutzer meldet „Copilot gab falschen Inhalt aus“, würde 2nd-Level checken, was im Log stand, war es Berechtigungsfehler? etc. Der 3rd-Level wäre Microsoft Support – wir haben aber klar definiert: nur der M365-Admin (bzw. Service Owner) öffnet Tickets bei Microsoft, damit das gebündelt ist. Incident-Management läuft nach dem gewohnten Schema: Wir haben Schweregrade – z.B. Critical Incident wäre „Copilot antwortet allen Nutzern gar nicht mehr“ oder „Datenleck-Verdacht“, da gibt’s einen Notfallplan (sofort Security-Team Alarm, ggf. KI abschalten temporär). Kleinere Incidents wie „Falsche Antwort“ sind eher Problems (zur Ursache-Forschung). Wir führen ein Incident-Log, auch für interne Zwecke. Zum Glück hatten wir bisher keine kritischen Incidents, nur ein paar Minor, die wir beheben konnten. Wir haben auch beschlossen, Support-Zuständigkeiten in die Dokumentation aufzunehmen: Der Service Owner KI (bei uns im IT-Team) ist quasi Problem-Manager – sammelt wiederkehrende Issues und erarbeitet Lösungen, evtl. mit Microsoft oder intern. Wichtig war uns auch, den Nutzern Self-Service-Hilfen zu geben: Ein Intranet-Bereich „Copilot Hilfe“ mit Troubleshooting-Tipps („Warum antwortet Copilot manchmal nicht?“ etc.), damit sie gar nicht jedes mal ein Ticket eröffnen müssen. Ein Spezialfall: Falls ein Security-Incident (z.B. Verdacht Missbrauch) auftritt, greift unser InfoSec Incident Process: SOC-Team übernimmt, untersucht Logs etc. Das haben wir in Incident-Playbooks festgehalten – analog zu z.B. „E-Mail Leak Incident“. Zusammengefasst: Der Support ist genauso dreistufig wie bei anderen Services, nur dass wir das Support-Team extra geschult haben auf KI-spezifische Themen. Incident-Management ist an bestehende Prozesse angedockt; für KI-spezifische Szenarien (Datenfehler, Model-Ausfall) haben wir im Runbook ein paar Seiten ergänzt. Bisher klappt das gut: Der Helpdesk konnte >90% der Fragen direkt beantworten (viele waren „Wie mache ich X?“), und wir hatten erst einen Fall, wo der Service Owner Microsoft einschalten musste (das war ein anfänglicher Config-Bug, schnell gelöst). Es ist wichtig, das im Betrieb als regulären Service zu behandeln, nicht als Experiment – dann greift die normale Supportstruktur sehr gut.

17) Welche Schulungen benötigen Administratoren und Anwender?
Beide Gruppen brauchen spezifisches Wissen: – Administratoren (IT-Team): Die Admins mussten lernen, wie Copilot technisch in M365 verankert ist. Wir haben ihnen Trainings auf Microsoft Learn empfohlen, z.B. „Security for M365 Copilot“. Konkret mussten sie wissen: Wo stelle ich Copilot ein/aus im Tenant? Wie steuere ich die Graph-Konnektoren? Was loggt Copilot wo? Also sehr technisch. Außerdem brauchten sie Schulung zur Fehleranalyse: z.B. zu verstehen, warum Copilot einer bestimmten Anfrage nicht nachkommt (kann an fehlendem Semantic Index liegen oder CA-Policy etc.). Unsere Admins haben praktisch ein Workshop mitgemacht, wo wir solche Szenarien durchgingen. Und natürlich, Security/Konfiguration: welche Einstellungen müssen sein (MFA etc., aber das kannten sie). Zugleich mussten sie den Fach-Support unterstützen können – d.h. auch die Admins haben beispielhaft Copilot genutzt, um die Nutzerperspektive zu verstehen. Zusätzlich: Falls wir mal eigene Erweiterungen bauen, bräuchten Admins/Entwickler tiefergehende Skills (Azure OpenAI FineTuning etc.), aber soweit sind wir noch nicht. – Endanwender: Hier lag der Fokus klar auf Anwendung & Richtlinien. Wir haben ein mehrstufiges Schulungskonzept: – Ein E-Learning Modul (20min) „Copilot Basics“: Was kann es, wie bediene ich es, simple Beispiele. – Dann Guidelines-Schulung (10min Video + Kurz-Lektüre): Do/Don’t, Datenschutz-Hinweise, Sicherheitsbewusstsein. Also quasi die Zusammenfassung der Nutzungsregeln in bekömmlicher Form. – Für spezialisierte Anwendergruppen haben wir extra Sessions gemacht: z.B. Vertrieb hat andere Use Cases als HR. Da haben wir mit Beispielen aus ihrem Alltag trainiert („So könnt ihr Copilot nutzen, um Angebot-Docs zu erstellen“, etc.). – Wichtig auch: Wir haben Plattformen zum Erfahrungsaustausch (Community-Channel, Q&A-Forum) eingerichtet – das ist kein klassisches Training, aber unterstützt kontinuierliches Lernen. – Zum Ende jeder formalen Schulung gab’s ein kurzes Quiz, um sicherzugehen, dass die wichtigen Punkte (z.B. „Was darfst du nicht tun?“) verstanden wurden. – Und wir stellen „Cheat Sheets“ bereit – 1-Seiter mit häufigen Befehlen und Tipps, den die Leute an den Arbeitsplatz pinnen können. Im Grunde ist es eine Kulturfrage: Anwender sollen befähigt werden, Copilot effektiv und regelkonform zu nutzen. Daher deckt die Schulung beides ab: funktional (wie krieg ich gute Ergebnisse) und compliance (was ist erlaubt, worauf muss ich achten). In Summe: Admins brauchten einmal tief Tech-Briefing plus laufende Updates (die lesen die MS-Release-Notes jetzt aufmerksam). Anwender brauchten initiale Schulungsoffensive – und wir planen, nach ~6 Monaten nochmal Refresh-Workshops anzubieten, um Best Practices auszutauschen und neue Features vorzustellen. Denn das Lernen hört da ja nicht auf, KI-Fähigkeiten entwickeln sich auch.

18) Wie vermeide ich Schatten-IT durch nicht genehmigte Plugins?
Indem wir einerseits strikt technisch blockieren und andererseits gute offizielle Alternativen bieten. Technisch haben wir – wie erwähnt – die Third-Party-Plugin-Funktion in M365 erstmal global deaktiviert. Das heißt, Nutzer können gar nicht selbst irgendwelche neuen Copilot-Plugins installieren; die UI dafür ist ausgeblendet. Damit ist schon mal 95% des Risikos gebannt, denn niemand kann „einfach mal ChatGPT-Plugin X“ anstöpseln. Zweitens haben wir einen klaren Prozess kommuniziert (siehe Frage 9): „Wenn du ein Plugin brauchst, melde dich hier, wir prüfen das.“ Dadurch fühlen sich Nutzer ernst genommen. Würden wir einfach nur verbieten ohne Perspektive, würden manche evtl. versuchen, Workarounds zu finden (z.B. eigenständig Daten in ChatGPT kopieren, was noch riskanter wäre). Drittens beobachten wir die Bedürfnisse: Sollte es viele Anfragen nach einer ähnlichen Funktion geben, überlegen wir, sie offiziell bereitzustellen. Beispiel: Viele wollten Web-Suche im Copilot. Wir haben statt dass jeder evtl. externe Tools nutzt, den Bing Web Search (wo erlaubt) testweise aktiviert – aber mit safe settings. So stillen wir den Bedarf innerhalb des Governed Systems. Viertens: Awareness – wir haben den Leuten deutlich gesagt, warum unautorisierte Plugins gefährlich sind („Können Daten abziehen, sind nicht geprüft“). Und dass es nicht erlaubt ist – also jeder weiß, wenn er’s doch versucht, verstößt er gegen Richtlinie und es wird eventuell entdeckt (Logs). Sollte trotzdem einer auf dumme Ideen kommen: Unser Monitoring würde es merken, wenn z.B. plötzlich ungewöhnliche API-Zugriffe passieren. Dann würden wir eingreifen (Gespräch, Ermahnung). Bisher hat aber noch keiner so gehandelt. Zusätzlich: Unsere M365-Umgebung hat Cloud App Security Policies, die auch untypische App-Anmeldungen detektieren. Falls also jemand versuchen würde, z.B. das System mit Developer Credentials zu erweitern, bekämen wir mit. Also kurz: Verhindern durch technisches Disable, lenken durch offiziellen Freigabeprozess und Transparenz, und drohenden Folgen bei Missachtung klar machen. So haben wir tatsächlich (bislang) keine Schatten-IT bei Copilot beobachtet.

19) Wie plane ich Lizenzen und behalte Kosten im Griff?
Sehr sorgfältig mit ständigen Abgleich zwischen Nutzung und Ausgabe. Wir sind stufenweise vorgegangen: Erst nur X Lizenzen für den Pilot gekauft, dann in Wellen aufgestockt. So haben wir zu keiner Zeit viel Geld für ungenutzte Lizenzen verbrannt. In der Einführung haben wir auch versucht, die wirklich „hungrigen“ Nutzer zuerst zu bedienen – damit die ROI-Zahlen gut aussehen und wir zeigen konnten: hier lohnt es sich, mehr zu investieren. Als das belegt war, hat man uns Budget für weitere Lizenzen gegeben. Wir monitoren monatlich, wie viele der vergebenen Lizenzen aktiv genutzt werden. Die Kennzahl „aktive Nutzer“ vs. „lizenzierte Nutzer“ ist wichtig. Ist der Gap groß (also viele haben es aber nutzen es kaum), fragen wir nach: Braucht derjenige es wirklich? Evtl. entziehen wir eine Lizenz wieder und geben sie lieber jemand anderem. Dafür haben wir auch einen Prozess, der mit den Abteilungsleitern abgestimmt ist (kein Wildwest „Lizenz weg“, sondern in Feedbackrunden klären). Dann Kostenkontrolle: Wir haben die Copilot-Ausgaben im IT-Budget extra ausgewiesen. Controlling hat ein waches Auge – wir liefern ihnen auch Berichte zum Nutzen (damit sie die Kosten einordnen können). So sehen alle: okay, wir zahlen Summe X pro Monat, aber dafür haben wir Y Stunden gespart – dann ist das tragfähig. Falls mal neue Kosten anstehen (z.B. wir überlegen ein Zusatztool für Audit-Logs zu kaufen oder ein Red-Team-Assessment), schauen wir, ob sich das in dem Rahmen bewegt, der durch Effizienzgewinne gedeckt ist. Lizenzplanung für die Zukunft läuft analog: Wir schauen, wie die Adoptionskurve verläuft. Wenn wir sehen, 90% der Wissensarbeiter nutzen Copilot regelmäßig, könnte man überlegen, ob auch andere Gruppen (die aktuell keine Lizenz haben, z.B. in Produktion) profitieren könnten – das prüfen wir aber kritisch, denn es bringt nichts, Leuten Lizenzen zu geben, die kaum am PC arbeiten. Wir vermeiden also pauschale „für alle 1000 Leute Lizenzen“ sondern eher „für 700, und 300 potentielle optional, aber erst wenn Case da.“ Microsoft drängt zwar manchmal auf E5 Upgrades etc., aber wir bleiben bedarfsgesteuert. Zusätzlich achten wir auf eventuelle versteckte Kosten: z.B. Graph Connectors brauchen evtl. Azure Ressourcen, oder wenn Nutzer über Copilot heavy E-Mails mit Anhängen verschicken, steigt Exchange-Speicher – bisher marginal, aber wir tracken solche Effekte. Die Lizenz- und Kostensteuerung ist Teil der Governance-Meetings – jedes Quartal legt uns Controlling dar, was Copilot gekostet hat und wir legen dar, was es gebracht hat. Solange da ein Gleichgewicht oder Plus herrscht, ist alles gut. Sollten Kosten aus dem Ruder laufen (z.B. Preiserhöhung o.Ä.), müssten wir gegensteuern – z.B. scope begrenzen oder Effizienz woanders heben. Aktuell sind wir aber im Plan: wir haben ~80% der budgetierten Lizenzen im Einsatz, und die Kosten liegen unter 5% unseres IT-Gesamtbudgets, was als OK angesehen wird, given the improvements. Also durch ständiges Nachjustieren und enges Controlling behalten wir es gut im Griff.

20) Wie sieht ein sinnvoller Review-Zyklus für Policies aus?
Wir haben uns darauf geeinigt, dass wir die Copilot-bezogenen Policies mindestens einmal pro Jahr umfassend prüfen und aktualisieren. Angesichts der Dynamik haben wir aber zusätzlich ein Halbjahres-Checkpoint eingebaut. Also konkret: – Quartalsweises Mini-Review im Governance-Board: Da fragen wir uns: gab es in den letzten 3 Monaten Vorkommnisse, die eine Policy-Änderung erfordern? (Z.B. neuer Missbrauchsfall -> Regel verschärfen? oder umgekehrt Regel war überflüssig streng -> lockern?). Diese quartalsweisen Checks sind eher oberflächlich und punktuell. – Jährliches Haupt-Review: Hier gehen wir Abschnitt für Abschnitt durch die Richtlinie(n). Beteiligte: Copilot-Produktverantwortlicher, CISO-Vertreter, Datenschutz, Betriebsrat und gerne jemand von den Power-Usern. Wir schauen: – Passen die Begriffe noch? (vielleicht neue KI-Funktionen hinzufügen). – Sind die „Don’ts“ alle noch relevant oder neue hinzugekommen? (Beispiel: Wenn wir irgendwann Websuche erlauben, müsste die Policy ergänzt). – Gibt es regulatorische Änderungen, die wir einarbeiten müssen? – Hat sich bewährt, was wir vorschreiben? (Wenn z.B. keiner mehr den „Keine sens. Daten im Prompt“-Satz beachtet, muss man Mechanismen verstärken). Nach diesem Review erstellen wir eine neue Revision der Policy. Die geht dann wieder den Genehmigungsweg (Geschäftsführung, evtl. BR). Gerade das erste Jahr erwarten wir noch häufiger Nachsteuerung, später wird’s stabiler. Wichtig ist auch: ad-hoc Reviews bei Bedarf. Wir haben in der Policy selbst einen Passus „außerordentliche Überprüfung bei relevanten Vorfällen oder spätestens neuen Gesetzeslagen“. D.h. wenn morgen AI Act käme mit konkreten Vorgaben, würden wir sofort die Policy aktualisieren (nicht warten bis Jahresende). Sinnvoll ist, die Reviews zeitlich mit anderen Governance-Zyklen zu koppeln – wir haben z.B. InfoSec-Policies, die eh jährlich upgedatet werden; Copilot-Themen hängen wir da mit rein, damit es nicht vergessen wird. Ein Nebenaspekt: Review heißt auch, Nutzerfeedback einzuholen – wir fragen z.B. bei Champions oder per Mitarbeiterumfrage, ob es Unklarheiten in den Regeln gibt. Wenn ja, versuchen wir im nächsten Update, das verständlicher zu formulieren. Alles in allem: Mindestens jährlich formell updaten. Bei so neuer Technologie eher zweimal im Jahr mal genauer hinsehen. Und spontane Anpassungen, wenn irgendwas Gravierendes passiert oder neue Funktionen ausgerollt werden, die die Policy tangieren. So bleibt das Regelwerk stets aktuell und praktikabel – nichts ist schlimmer als Policies, die 5 Jahre alt und realitätsfremd sind, gerade bei KI, wo sich in 5 Jahren Welten tun.

Damit sind häufig gestellte Fragen zum Thema Copilot-Governance beantwortet. Diese FAQs können den Mitarbeitern zur Verfügung gestellt werden (z.B. im Intranet), um Klarheit über zentrale Punkte zu schaffen. Sie fassen vieles aus dem Hauptdokument in kompakter, dialogorientierter Form zusammen – ein weiterer Baustein, um das umfangreiche Thema für alle zugänglich und verständlich zu machen.

 

Weitere Beiträge zum Thema SharePoint und Teams