Gartner zählt KI-Agenten als Sicherheitsrisiko aktuell zu den wichtigsten Cybersecurity-Trends für 2026. Das deckt sich ziemlich genau mit dem, was ich gerade im Arbeitsalltag erlebe. Immer mehr Kunden kommen auf mich zu und wollen Microsoft Copilot einführen. Das Interesse ist groß, die Lizenzen sind schnell gebucht. Nur übersehen viele dabei etwas Entscheidendes: Weder Copilot noch der M365 Tenant, wie wir ihn kennen, sind ab Werk sicher. Beide brauchen eine ordentliche Härtung, Schulung der Mitarbeiter und angepasste Arbeitsprozesse, bevor man die Plattform wirklich sicher und effizient betreiben kann. Genau darüber möchte ich in diesem Artikel schreiben, denn ich sehe das Problem gerade sehr häufig in der Praxis.
Der erste Reflex: Lizenzen kaufen, loslegen
Meistens läuft es bei mir so ab: Ein Kunde kommt auf mich zu und möchte Copilot-Lizenzen buchen, um damit produktiv zu arbeiten. Was dabei häufig fehlt, ist das Verständnis dafür, dass die eigentliche Einführung viel mehr Zeit braucht als die Lizenz selbst. Viele Kunden denken, Härtung und Schulung seien nur ein kleiner Nebenschritt. Das ist leider komplett falsch.
Wer Copilot sauber einführen möchte, hat schnell ein wochenlanges Projekt vor sich, gerade in gewachsenen Strukturen oder Umgebungen, die noch Reste einer alten IT-Zeit mit sich tragen, etwa On-Premises-Legacy-Systeme. Wenn ich das den Kunden dann so erkläre, schauen mich viele erstmal mit großen Augen an. In diesem Moment merken sie meistens selbst, dass das kein kleines Zusatzfeature ist, sondern ein echtes Projekt.
Das größte Problem: Purview wird komplett übersehen
Bei der Mehrzahl der KMUs, die in der Cloud arbeiten, fehlt der Einsatz von Microsoft Purview mit Sensitivity Labels und DLP-Richtlinien komplett. Ich sage dazu immer: Das ist eigentlich kein IT-Projekt, sondern ein Unternehmensprojekt. Die Mitarbeiter müssen massiv geschult werden, denn je nach Konfiguration müssen sie ihre Dokumente selbst labeln.
Gerade weil durch KI heute deutlich mehr Daten erzeugt werden, wird es immer wichtiger, diese Daten von Anfang an zu schützen. Hier fehlt bei vielen Kunden noch grundlegendes Verständnis, teilweise habe ich das Gefühl, dass sie von dieser Funktion schlicht noch nie gehört haben.
Das zweite Problem: Berechtigungswildwuchs in SharePoint
Das zweite große Problem sehe ich in SharePoint. Viele Strukturen sind über Jahre gewachsen, und irgendwann kam ein Admin auf die Idee, Berechtigungen individuell aufzubrechen statt sie sauber zu vererben. Das Problem dabei: Genau solche aufgebrochenen Berechtigungen lassen sich in SharePoint nur schwer nachvollziehen und sollten eigentlich aufgelöst werden.
Denn alles, worauf ich in SharePoint zugreifen kann, sieht mein Copilot Chat natürlich auch. Gibt es hier einen Berechtigungsfehler und ich habe Zugriff auf Dateien, die eigentlich nicht für mich gedacht sind, kann es zu einem unbewussten Datenabfluss kommen, ganz ohne böse Absicht.
Ein Beispiel das das gut greifbar macht: Lohnabrechnungen von Kollegen. Ist eine einzige Berechtigung falsch gesetzt, kann Copilot theoretisch Zugriff darauf bekommen, obwohl das nie so vorgesehen war.
Dazu kommt: In den meisten SharePoint-Umgebungen wird viel zu wenig mit Metadaten gearbeitet. Stattdessen wird munter in tief verschachtelten Ordnerstrukturen abgelegt. Das hat gleich mehrere Nachteile: Man läuft schnell in Zeichenlimits bei den Pfaden, Inhalte werden schlechter durchsuchbar, und auch Copilot selbst könnte mit sauberen Metadaten deutlich besser arbeiten. Das lässt sich natürlich nicht von heute auf morgen ändern, je nach Struktur ist das ein längeres Projekt, bei dem wieder viel Schulungsarbeit dazugehört.
Das dritte Problem: Power Platform ohne Data Loss Prevention
Neben Purview und SharePoint sehe ich noch einen dritten großen blinden Fleck: die Power Platform. Viele Kunden wissen gar nicht, dass Power Automate und Power Apps standardmäßig ohne echte Leitplanken laufen. Es fehlt oft eine klare Data Loss Prevention Policy für Connectoren, also eine Regel die festlegt, welche Connectoren als Business gelten und welche als Non-Business. Ohne diese Trennung kann theoretisch ein Flow Daten aus SharePoint oder Exchange ungeprüft an einen externen Connector weiterschicken, zum Beispiel an einen privaten Cloud-Speicher oder einen Social-Media-Account.
Dazu kommt die Frage, wer in der Power Platform überhaupt bauen darf. Häufig gibt es keine saubere Umgebungsstrategie, alle Mitarbeiter bauen einfach in der Default-Umgebung drauf los. Das mag am Anfang praktisch wirken, wird aber schnell unübersichtlich und ist aus Sicherheitssicht ein Problem, weil niemand mehr den Überblick hat, welcher Flow auf welche Daten zugreift.
Was ich Kunden empfehle
Wenn ein Kunde mit dem Wunsch nach Copilot auf mich zukommt, empfehle ich als ersten Schritt immer ein Audit des Tenants. Grob läuft das bei mir in mehreren Schritten ab.
Zuerst steht eine Bestandsaufnahme: Welche M365-Dienste werden überhaupt aktiv genutzt, also SharePoint, OneDrive, Exchange und die Power Platform. Das entscheidet schon vorab, wie umfangreich die weiteren Schritte werden.
Danach schaue ich mir SharePoint und OneDrive genauer an: Gibt es aufgebrochene Berechtigungen statt sauberer Gruppenberechtigung? Wie viele Seiten oder Bibliotheken sind davon betroffen? Gibt es externe Freigaben, die niemand mehr auf dem Schirm hat?
Parallel dazu prüfe ich den Purview-Status: Sind überhaupt Sensitivity Labels angelegt? Gibt es DLP-Richtlinien? Werden Labels automatisch oder nur manuell vergeben? Wird sensibler Content wie Gehaltsdaten oder Verträge aktuell überhaupt erkannt?
Dann folgt der Blick auf die Power Platform: Welche Connectoren sind aktuell erlaubt? Gibt es eine Trennung zwischen Business- und Non-Business-Connectoren? Wer darf überhaupt Flows und Apps bauen, und gibt es eine Umgebungsstrategie oder wird einfach alles in der Default-Umgebung gebaut?
Am Ende steht ein Ergebnisbericht mit Priorisierung. Das ist mir wichtig: Es bringt niemandem etwas, nur eine technische Liste an Problemen abzuliefern. Der Kunde muss verstehen, welches Risiko am dringendsten angegangen werden sollte und welches auch noch etwas warten kann.
Werden SharePoint und OneDrive zum Beispiel noch gar nicht richtig genutzt, macht das die Sache erstmal einfacher, dann ist man auch nicht so stark auf sauberes Labeling angewiesen. In dem Fall kann man die Mitarbeiter schon mal in Ruhe auf Copilot schulen und parallel, sobald Daten nach und nach in M365 wandern, direkt von Anfang an mit Labeling und ordentlicher Metadatenstruktur arbeiten. So kommt man nicht in die Situation, am Ende alles nachträglich geradeziehen zu müssen, sondern hat es von vornherein sauber eingerichtet.
Fazit
Wir weisen unsere Kunden auf all das natürlich hin, am Ende liegt die Entscheidung aber bei ihnen. Wenn kein Interesse an diesen Vorarbeiten besteht, kann man niemandem etwas aufzwingen. Gerade in der aktuell angespannten wirtschaftlichen Lage in Deutschland halten sich viele Kunden ohnehin mit größeren Investitionen zurück. Trotzdem sollte man sich dann ehrlich fragen, ob eine großflächige Copilot-Einführung überhaupt sinnvoll ist, solange die Sicherheit nicht gewährleistet ist.
Meine Kernbotschaft an Kollegen und Kunden: Nehmt den Aufbau und die Struktur in M365 ernster. Viel zu oft sehe ich Tenants, die von einem anderen Dienstleister betreut werden, in denen einfach Daten reingeschoben werden, ohne Sinn und Verstand dahinter. Das ist erstens gefährlich, und zweitens auch wirtschaftlich und effizienztechnisch nicht sinnvoll, weil man dann eben nicht das volle Werkzeug nutzt, das einem eigentlich zur Verfügung steht, um die Arbeit leichter zu machen.