KI-Anbieter haben einen Heißhunger auf alle erdenkliche Inhalte, um damit ihre Sprachmodelle zu trainieren. Vertrauliche Firmendaten, die auf M365 gespeichert werden, können sowohl Ziel externer Crawler als auch des integrierten Copilot werden. Neben einem sauberen Berechtigungskonzept schützen mehrere M365-Features sowie restriktive Einstellungen gegen das unerwünschte Absaugen von Daten.
Wenn Daten ungeschützt in der Cloud liegen, dann kann man getrost davon ausgehen, dass sie irgendwann von KI-Crawlern auch gefunden werden. Dass die KI-Systeme dabei sogar erhebliche Hürden selbständig überwinden können, zeigte der Angriff von OpenAI-Agenten auf Hugging Face im Juli 2026.
Dieser Artikel konzentriert sich auf die technischen Aspekte der AI-Risiken und klärt, welche Mechanismen in Microsoft 365 zur Verfügung stehen, um den Zugriff von KI-Systemen auf Unternehmensdaten zu kontrollieren.
Einfallstore für KI-Systeme
Der oft in diesem Zusammenhang verwendete Begriff KI-Crawler ist etwas unscharf. Konkret geht es eigentlich um mehrere Kategorien:
Externe Web-Crawler von KI-Anbietern: Sie indexieren öffentlich erreichbare Inhalte aus dem Web für Trainingsdatensätze oder Suchanfragen. Dazu gehören GPTBot von OpenAI, Google-Extended oder CCBot. Diese sind nur relevant, wenn Inhalte aus SharePoint oder anderen M365-Diensten öffentlich im Web zugänglich sind.
KI-Integration von Drittanbietern: Hierbei handelt es sich um KI-Lösungen, die Nutzer selbst einbinden. Dazu gehören zum Beispiel Browser-Plugins, die Inhalte von Web-Seiten an externe KI-Dienste senden, etwa für Übersetzungen oder Zusammenfassungen, Teams-Apps aus dem App Store, die auf Chat-Verläufe oder Kalenderdaten zugreifen, sowie Low-Code-Tools wie Copilot Studio, die externe KI-Endpunkte anbinden.
Microsofts eigene KI-Dienste (Copilot): Der M365 Copilot beschränkt seinen Aktionsradius zwar auf den eigenen Tenant, greift aber trotzdem unkontrolliert auf Daten zu, wenn Berechtigungsstrukturen nicht sauber konfiguriert sind. Das ist jedoch kein Scraping im klassischen Sinne, aber ein verwandtes Governance-Problem.
Für jedes Szenario bietet M365 jeweils eigenen Mittel, um sensible Informationen vor unbefugtem AI-Zugriff zu bewahren.
Öffentlichen Zugriff auf SharePoint-Inhalte prüfen
SharePoint Online erlaubt es, Sites oder einzelne Bibliotheken so zu konfigurieren, dass Inhalte ohne Anmeldung zugänglich sind (Anonymous Access). In vielen Organisationen existieren solche Sites aus älteren Projekten oder für Extranet-Szenarien. Solche Inhalte sind dann für externe Crawler grundsätzlich erreichbar.
Sie können aber im SharePoint Admin Center unter „Richtlinien -> Teilen -> Externes Teilen bei Datei und Ordnerlinks“ den maximalen Freigabetyp auf Tenant-Ebene festlegen.
Die restriktivste Einstellung ist Nur Personen in Ihrer Organisation. In diesem Fall sind keine anonymen Links und keine Gastfreigaben mehr möglich. Weniger restriktiv, aber besser als der Standard ist Neue und vorhandene Gäste, kombiniert mit einem Ablaufdatum für externe Links.
Für eine Bestandsaufnahme der aktuell freigegebenen Inhalte eignet sich der Sharing Report im SharePoint Admin Center oder ein PowerShell-basierter Scan:
Get-SPOSite -Limit All | Where-Object { $_.SharingCapability -ne „Disabled“ } |
Select Title, Url, SharingCapability
Crawling öffentlicher M365-Inhalte steuern
Für den Fall, dass tatsächlich öffentlich zugängliche SharePoint-Inhalte existieren (etwa externe Wissensdatenbanken), können Admins das Crawling durch externe Bots mit Hilfe von Einstellungen auf HTTP-Ebene oder des SharePoint-eigenen Noindex-Mechanismus einschränken.
Microsoft hat 2024 die Unterstützung für das X-Robots-Tag-Header-Feld in SharePoint Online angekündigt, das Crawlern signalisiert, Inhalte nicht zu indexieren. Für bestehende öffentliche Sites ist eine Überprüfung sinnvoll, ob die verfügbaren Mechanismen genutzt werden.
Darüber hinaus können Organisationen mit Hilfe von IP-Allowlists oder Conditional-Access-Policies für SharePoint explizit festlegen, dass nur authentifizierte Zugriffe aus bekannten Netzwerken zulässig sind, was anonyme Crawler wirksam ausschließt.
Externe App-Zugriffe kontrollieren
Drittanbieter-Apps greifen über OAuth-Consent auf M365-Daten zu. Entra-Nutzer können, sofern nicht eingeschränkt, Anwendungen den Zugriff auf ihre Mailbox, ihren Kalender oder OneDrive-Inhalte gewähren. Viele KI-basierte Produktivitäts-Tools funktionieren so.
Der entscheidende Hebel liegt in den App-Consent-Einstellungen in Entra ID unter „Unternehmensanwendungen -> Einwilligungen und Berechtigungen -> Einstellungen für die Benutzerewilligungen“. Ich empfehle, den Nutzer-Consent auf „Benutzereinwilligung nicht zulassen“ oder auf „Für ausgewählte Berechtigung die Benutzereinwilligung für Apps von verifizierten Herausgebern zulassen“ zu setzen. Neue Drittanbieter-Apps müssen dann explizit durch einen Admin genehmigt werden.
Bereits erteilte Einwilligungen können im Entra ID-Portal unter „Unternehmensanwendungen -> Alle Anwendungen“ bei der jeweiligen Anwendung eingesehen und widerrufen werden. Klicken Sie dazu auf die betreffende App und wechseln Sie dann zum Menüpunkt „Berechtigungen“. Eine zentrale Übersichtsseite für alle Einwilligungen („Consent and permissions“) ist in manchen Tenants im Menü Schutz zentral verfügbar.
In meinem Tenant ist das nicht der Fall. Bei älteren Mandanten kann es durchaus vorkommen, dass neue Menüs oder Features noch nicht ausgerollt oder aus Lizenz- bzw. Konfigurationsgründen nicht sichtbar sind. Die vollständige neue Oberfläche wird schrittweise zugänglich gemacht und hängt teilweise von der genauen Lizenzkombination ab (auch bei P2).
Zur Prävention weiterer unsicherer Einwilligungen empfiehlt Microsoft zudem, in bei der Identitätssicherheitsbewertung („Microsoft Secure Score“) die Empfehlung „Erlauben Sie Benutzern nicht, unzuverlässigen Anwendungen ihre Einwilligung zu geben“ („Do not allow users to grant consent to unmanaged applications“) zu aktivieren.
Microsoft 365 Copilot und den Datenzugriff steuern
Der M365 Copilot erhält Zugriff auf dieselben Daten wie der jeweilige Nutzer, nicht mehr und nicht weniger. Hat ein Nutzer Leserechte auf eine SharePoint-Bibliothek, kann Copilot auch deren Inhalte im Kontext von Anfragen dieses Nutzers verwenden. Das ist kein Bug, sondern eine bewusste Design-Entscheidung.
Die eigentliche Governance-Herausforderung besteht darin, sicherzustellen, dass die Berechtigungen insgesamt korrekt gesetzt sind. In vielen Organisationen haben historisch gewachsene Berechtigungsstrukturen dazu geführt, dass Nutzer Zugriff auf Bibliotheken haben, von denen sie gar nicht wissen. Copilot macht diese „stillen“ Zugriffsrechte sichtbar und damit zu einem Problem.
Microsoft hat als Reaktion darauf das „SharePoint Advanced Management“ eingeführt. Es ist Teil von „SharePoint Syntex“ und als Add-on buchbar.
Tipp: SharePoint Syntex verwendet KI, um Inhalte zu organisieren und zu verwalten, Suche und Compliance zu optimieren, Inhalte zu generieren und Ihre wichtigsten Geschäftsprozesse zu verbessern. Bereits im April 2022 hat Microsoft seinen Syntex-Taxonomiedienst in Viva-Topics integriert.
Syntex kann Geschäftstaxonomien automatisch aus den Inhalten von M365- Bibliotheken erstellen. Dann können Topics diese Taxonomie-Tags verwenden, um Themenseiten vorzubauen und automatisch getaggte Dokumente an die Themenseiten anhängen, wenn neue Inhalte gefunden und verschlagwortet werden.
Das „SharePoint Advanced Management“-AddOn bietet unter anderem folgende Funktionen:
- Data Access Governance Reports: Übersicht über SharePoint-Sites mit breitem internem Zugriff oder vielen externen Freigaben
- Restricted SharePoint Search: Damit kann man die Copilot-Suche auf eine kuratierte Liste von Sites zu beschränken, statt alle zugänglichen Sites einzubeziehen.
- Site Access Review: Diese Funktion überprüft automatisch, wer Zugriff auf welche Sites hat, mit der Möglichkeit zur direkten Bereinigung
„Restricted SharePoint Search“ ist kurzfristig der wirksamste Hebel, wenn Sie den Datenzugriff einschränken möchten, nachdem Copilot bereits ausgerollt. Statt alle Sites zu durchsuchen, greift Copilot dann nur auf explizit genehmigte Sites zu.
Sensitivity Labels und DLP als Schutzschicht
Microsoft Purview Sensitivity Labels klassifizieren Dokumente sowie E-Mails und steuern, welchem Schutz oder welchen Einschränkungen sie unterliegen sollen, zum Beispiel ob sie verschlüsselt oder mit einem Wasserzeichen versehen werden sollen oder der Download erlaubt sein soll.
Für KI-Scraper ist der Verschlüsselungsaspekt maßgeblich. Ein via Sensitivity Label verschlüsseltes Dokument bleibt auch dann geschützt, wenn es aus dem Kontext des Tenants herausgelöst wird. Ein Zugriff ohne gültige Berechtigung ist dann nicht möglich.
Data Loss Prevention (DLP)-Richtlinien in Microsoft Purview können außerdem erkennen, wenn sensible Daten (Kreditkartennummern, personenbezogene Daten, selbst definierte Inhaltstypen) an externe Empfänger oder in Dienste übertragen werden und diese Übertragung blockieren bzw. zur Überprüfung markieren.
Für KI-spezifische Szenarien ist der DLP-Schutz für Microsoft Teams relevant: Fügt ein Nutzer sensible Inhalte in eine Teams-App oder einen Bot ein, der externe KI-Dienste nutzt, kann DLP die Nachricht abfangen, sofern die App als externer Endpunkt klassifiziert und in der DLP-Policy erfasst ist.
Fazit
Der Schutz von M365-Daten vor unkontrolliertem KI-Zugriff ist kein einzelnes Feature, sondern erfordert eine Kombination von Maßnahmen:
- Reduzierung des öffentlichen Datenzugriffs (Freigabe-Einstellungen)
- Kontrolle externer App-Einwilligungen in Entra ID
- Saubere Berechtigungsstrukturen als Grundlage für Copilot-Governance (SharePoint Advanced Management)
- Klassifizierung und DLP für sensible Inhalte (Microsoft Purview)