DSPM for AI im Detail: was das Dashboard über Copilot und fremde KI zeigt – und was nicht

Der IT-Leiter hatte DSPM for AI geöffnet, um dem Vorstand zu zeigen, wie sicher die KI-Nutzung im Haus sei. Das Dashboard zeigte: null Interaktionen mit fremden KI-Diensten, null sensible Daten in Prompts, keine Risiken. Der Vorstand war beruhigt. Ich war es nicht, denn ich hatte am Vormittag in der Kaffeeküche zwei Kollegen über ihre ChatGPT-Prompts reden hören. Die Auflösung dauerte fünf Minuten: Kein Gerät war für Endpoint DLP onboardet, keine Browser-Erweiterung verteilt, und das Audit-Log war für Copilot-Interaktionen zwar an, aber die einzige Copilot-Lizenz gehörte dem IT-Leiter selbst. DSPM hatte nicht gelogen. Es hatte nur nichts zu sehen bekommen – und ein Armaturenbrett ohne Sensoren zeigt null, nicht „unbekannt".

DSPM for AI – Data Security Posture Management für KI, früher AI Hub – ist die Stelle im Purview-Portal, an der KI-Nutzung sichtbar wird: Wie viele Copilot-Interaktionen gab es, welche sensiblen Daten steckten in Prompts und Antworten, welche Labels trugen die Quellen, welche fremden KI-Dienste nutzt die Belegschaft im Browser, welche SharePoint-Sites sind für Copilot am gefährlichsten. Dazu kommen Empfehlungen mit One-Click-Richtlinien und Datenrisikobewertungen für Oversharing. Das ist viel – und es ist die Bestandsaufnahme, mit der jede Copilot-Readiness beginnt. Aber DSPM misst nichts selbst. Es liest Signale, die andere Module erzeugen: das Audit-Log, Sensitive Info Types und Labels, Endpoint DLP, Insider Risk. Fehlt ein Signal, fehlt der Bericht, und das Dashboard sieht trotzdem beruhigend aus.

Dieser Artikel zeigt den Aufbau von DSPM for AI, welche Berichte es liefert und welche Voraussetzungen jeder Bericht hat, wie die Datenrisikobewertungen funktionieren, was die One-Click-Empfehlungen wirklich anlegen und wo die Grenzen liegen – für Copilot, für Copilot-Studio-Agenten und für fremde KI. Der Readiness-Fahrplan, in dem DSPM die Bestandsaufnahme liefert, steht im Spoke zur Copilot-Readiness mit Purview; wo DSPM im Gesamtbild von Purview sitzt, zeigt der Überblick zum Kompetenzbereich Microsoft Purview.

Aufbau und Berichte: was DSPM for AI zeigt – und welche Signale dafür fließen müssen

Wer DSPM for AI zum ersten Mal öffnet, sieht eine Übersichtsseite mit ersten Schritten, die man ernst nehmen sollte, weil sie genau die Sensoren beschreiben, ohne die alles null bleibt: Audit aktivieren (für Copilot-Interaktionen), Geräte für Endpoint DLP onboarden und die Purview-Browsererweiterung verteilen (für fremde KI im Browser), Empfehlungen aktivieren (für die One-Click-Richtlinien) und – wo vorhanden – Konnektoren zu Enterprise-KI-Diensten einrichten. Darunter liegen fünf Bereiche: Berichte, Datenrisikobewertungen, Empfehlungen, der Aktivitätsexplorer und die Liste der aus DSPM erzeugten Richtlinien. Die Logik dahinter ist einfach und wird trotzdem ständig missverstanden: DSPM ist die Sicht, nicht das Werkzeug. Was es zeigt, entsteht woanders; was es empfiehlt, wird woanders konfiguriert.

Die Berichte im Detail

Die Berichte beantworten fünf Fragen. Erstens: Wie viel KI-Nutzung gibt es – Interaktionen über die Zeit, aufgeschlüsselt nach Microsoft 365 Copilot, Copilot-Studio-Agenten und fremden KI-Apps, mit der Zahl der aktiven Benutzer je App. Zweitens: Wie viele dieser Interaktionen enthielten sensible Daten – Prompts und Antworten, in denen ein Sensitive Info Type getroffen hat, nach Typ und App; das ist die Zahl, die dem Datenschutzbeauftragten am wichtigsten ist. Drittens: Welche Sensitivity Labels trugen die Quellen, die Copilot verwendet hat – die Kennzahl, an der man sieht, ob das Stufenmodell greift oder ob Copilot vor allem aus ungelabelten Inhalten schöpft. Viertens: Welche Risiken zeigen Insider Risk Management und Communication Compliance – riskante KI-Nutzung, unangemessene Prompts – nach Schweregrad, wenn diese Module lizenziert und aktiv sind. Fünftens: Welche fremden KI-Websites werden wie oft mit welchen sensiblen Daten genutzt – die Schatten-KI-Sicht, die nur mit Endpoint DLP existiert. Jeder Bericht hat seine Sensoren, und die Tabelle unten sagt, welche.

Ein Wort zum Aktivitätsexplorer, weil er in Projekten der meistgenutzte Bereich ist, sobald die Berichte laufen: Er zeigt Einzelinteraktionen – App, Benutzer, Zeitpunkt, erkannte Sensitive Info Types, Labels der verwendeten Quellen – filterbar nach allem, was man braucht, um einer Zahl aus dem Bericht auf den Grund zu gehen. „Warum 210 sensible Interaktionen mit dem Übersetzer?" beantwortet der Explorer mit einer Liste, aus der man sieht, dass es zwölf Anwender aus dem Vertrieb sind, die Kundenschreiben übersetzen. Das ist die Ebene, auf der Auswertungen zu Personen werden, und deshalb die Ebene, für die Rollen und Betriebsvereinbarung gelten. Wer den Explorer nur öffnet, um Trends je Bereich zu verstehen, bleibt auf der sicheren Seite; wer ihn öffnet, um zu sehen, „was Frau Müller so promptet", hat ohne Anlass und Regel nichts darin verloren.

Skizze 1: Der Datenfluss – Quellen, Signale und Klassifizierung, DSPM-Dashboard; das Armaturenbrett zeigt nur, was ein Sensor liefert.

Die Tabelle ordnet jedem Bericht die Frage zu, die er beantwortet, und die Voraussetzung, ohne die er leer bleibt. Die Spalte „Voraussetzung" ist der Grund, warum DSPM in vielen Tenants beruhigend aussieht.

Ein Wort zu den Prompt-Inhalten, weil die Frage in jedem Workshop kommt: DSPM zeigt in den Berichten und im Aktivitätsexplorer, dass ein Sensitive Info Type getroffen hat – welcher, wie oft, in welcher App, bei welchem Benutzer. Den Volltext eines Prompts oder einer Antwort zeigt es dort nicht; der steckt im Audit-Ereignis und in eDiscovery und ist nur mit den entsprechenden Rollen und – in Deutschland – mit einem Anlass einsehbar, den die Betriebsvereinbarung nennt. Was das Audit-Log über Copilot-Interaktionen im Einzelnen speichert und wie man es durchsucht, beschreibt der Spoke zum Copilot-Audit.

Datenrisikobewertungen: wie DSPM Oversharing für Copilot bewertet

Der zweite Bereich ist der, der in Readiness-Projekten den größten Aha-Effekt erzeugt: die Datenrisikobewertungen, im Portal auch Oversharing-Assessments genannt. Sie beantworten die Frage, die vor jeder Copilot-Einführung im Raum steht und die bisher niemand beantworten konnte: In welchen SharePoint-Sites findet Copilot am ehesten etwas, das nicht gefunden werden sollte? Die Antwort entsteht aus drei Faktoren je Site: Wie viele sensible Elemente liegen dort (Sensitive Info Types), wie breit ist die Site freigegeben (Freigabelinks, große Gruppen, „Jeder"), und wie viele Elemente tragen kein Label. Dazu kommt, wie oft Copilot dort tatsächlich Inhalte verwendet hat. Aus diesen Faktoren entsteht eine Rangliste – viel Sensibles plus breite Freigabe plus kein Label steht oben –, mit Zahlen je Site, die man dem Site-Besitzer und dem Betriebsrat zeigen kann.

Es gibt zwei Arten von Bewertungen. Die Standardbewertung läuft automatisch und wöchentlich über die Sites, die Copilot am häufigsten nutzt – sie ist der schnellste Blick auf das Risiko, aber sie setzt voraus, dass Copilot bereits genutzt wird, sonst gibt es keine Top-Liste. Eigene Bewertungen legst du selbst an: für ausgewählte Sites, Benutzer oder Bereiche, etwa den Vertrieb vor der Freigabe oder die HR-Sites, bevor jemand fragt. Aus jeder Bewertung heraus lassen sich Maßnahmen anstoßen – Zugriff einschränken, was eine Aufgabe für den Site-Besitzer erzeugt; Sensitivity Labels anwenden, was ein Stufenmodell voraussetzt; Restricted Content Discovery setzen, was die Site aus dem Copilot-Suchraum nimmt. Nichts davon passiert automatisch, und das ist richtig so: DSPM bewertet, es räumt nicht auf. Wie die Bereinigung selbst läuft – Berichte, Restricted Content Discovery, Site-Access-Reviews, „Jeder"-Freigaben in drei Stufen –, beschreibt der Spoke zum Oversharing in SharePoint beheben.

Skizze 2: Die Datenrisikobewertung – Umfang, Prüfung, Rangliste, Maßnahmen je Site, wöchentliche Wiederholung.

Empfehlungen und One-Click-Richtlinien: was der Klick anlegt – und warum du trotzdem lesen musst

Der dritte Bereich ist der verführerischste. DSPM for AI zeigt eine Liste von Empfehlungen, jede mit einem Knopf, der eine fertige Richtlinie anlegt: „Sensible Daten schützen, auf die Copilot verweist" erzeugt eine DLP-Richtlinie für den Speicherort Copilot, die Inhalte mit bestimmten Labels von der Verarbeitung ausschließt. „Riskante KI-Nutzung erkennen" erzeugt eine Insider-Risk-Richtlinie mit KI-Indikatoren. „Datensicherheit stärken" schlägt Auto-Labeling-Richtlinien für ungelabelte sensible Inhalte vor. „Sensible Daten in KI-Prompts erkennen" erzeugt eine Endpoint-DLP-Richtlinie im Audit-Modus für die vorgefertigte Domänengruppe generativer KI-Websites. „Unethisches Verhalten in KI erkennen" erzeugt eine Communication-Compliance-Richtlinie. Ein Klick, eine Richtlinie – und in fünf Minuten sieht der Tenant nach Governance aus.

Genau hier liegt die Falle. Die One-Click-Richtlinien sind sinnvolle Startpunkte, aber sie sind Vorlagen: mit Microsofts Annahmen über Labels, Sensitive Info Types, Schwellenwerte und Bereiche, nicht mit deinen. Die Copilot-DLP-Richtlinie schließt die Labels aus, die du auswählst – wer keine hat, klickt ins Leere. Die Insider-Risk-Richtlinie erzeugt Alarme über Benutzer – ohne Betriebsvereinbarung ein Problem, kein Fortschritt. Die Auto-Labeling-Vorschläge landen im Simulationsmodus, und die Simulation muss gelesen werden wie jede andere. Und alle erzeugten Richtlinien leben technisch in ihren Modulen – DLP, Information Protection, Insider Risk, Communication Compliance – und werden dort gepflegt; DSPM listet sie nur. Meine Regel aus Projekten: Die Empfehlungen sind die Einkaufsliste, nicht das Essen. Jede angeklickte Richtlinie wird im Modul geöffnet, gegen das eigene Konzept geprüft, im Audit- oder Simulationsmodus belassen, bis die Ergebnisse gelesen sind – und erst dann scharf geschaltet, mit derselben Stufenlogik wie jede DLP-Richtlinie. Wie das für Schatten-KI aussieht – Domänen-Ampel, Warnen mit freigegebenem Weg statt Sperren –, beschreibt der Spoke zur DLP gegen Schatten-KI.

Als Umsetzungshilfe die Empfehlungen mit dem, was der Klick anlegt, in welchem Modul die Richtlinie danach lebt und was vor dem Scharfschalten zu prüfen ist. Die Namen im Portal ändern sich gelegentlich; die Mechanik bleibt.

Die Grenzen: kein Allheilmittel, keine Echtzeit, keine Bereinigung

DSPM for AI ist das beste Werkzeug, das es für die Bestandsaufnahme der KI-Nutzung in Microsoft 365 gibt – und es hat Grenzen, die man kennen sollte, bevor man dem Vorstand das Dashboard zeigt. Die erste ist die aus dem Intro: DSPM sieht nur, wofür es Sensoren hat. Geräte ohne Endpoint-DLP-Onboarding, Browser ohne Erweiterung, private Geräte und Handys, Desktop-Clients fremder KI-Dienste, API-Zugriffe von Entwicklern – all das ist für DSPM unsichtbar, und die Berichte zeigen null, nicht „unbekannt". Die zweite Grenze ist die Zeit: Berichte laufen dem Geschehen um Stunden bis Tage nach, Datenrisikobewertungen wöchentlich; DSPM ist ein Rückspiegel und ein Kompass, kein Echtzeitschutz – der Schutz selbst kommt aus DLP, Labels und Berechtigungen. Die dritte Grenze ist die Qualität der Signale: Ein Sensitive Info Type mit Fehlalarmen erzeugt Fehlalarme in DSPM, mit denselben Zahlen wie echte Treffer; wer die Berichte dem Vorstand zeigt, sollte vorher wissen, wie gut seine SITs sind.

Die vierte Grenze ist die wichtigste: DSPM räumt nicht auf. Es zeigt Oversharing, aber Berechtigungen ändern Site-Besitzer; es zeigt ungelabelte Kronjuwelen, aber labeln müssen Fachbereiche oder Auto-Labeling-Richtlinien nach gelesener Simulation; es zeigt fremde KI-Nutzung, aber bremsen und freigeben muss ein Konzept. Und die fünfte Grenze ist die Lizenz: Der volle Umfang – sensible Interaktionen, Datenrisikobewertungen, Aktivitätsexplorer, fremde KI – braucht E5 oder E5 Compliance; Insider-Risk- und Communication-Compliance-Berichte brauchen zusätzlich diese Module; mit E3 sieht man Teile, vor allem die Copilot-Interaktionszahlen, wenn Audit an ist. Was das für Mischkalkulationen und den Zukauf einzelner Add-ons bedeutet, steht im Spoke zur Purview-Lizenzierung. Wer diese fünf Grenzen kennt, kann DSPM richtig einsetzen: als Bestandsaufnahme, als Trendanzeige, als Argument gegenüber Fachbereichen und Betriebsrat – nicht als Schutzschild.

Skizze 3: Was DSPM for AI sieht – und was nicht; die Grenzen liegen bei den Sensoren, nicht beim Dashboard.

Der Deutschland-Winkel: Betriebsrat, Datenschutzbeauftragter und die Frage nach den Prompts

DSPM for AI ist aus Sicht des Betriebsrats zweierlei zugleich: das Werkzeug, mit dem man belastbar sagen kann, was Copilot sieht und protokolliert – und selbst eine Auswertung über die KI-Nutzung von Beschäftigten. Die Berichte zeigen Interaktionen und sensible Treffer je Benutzer, der Aktivitätsexplorer zeigt Einzelinteraktionen mit Namen, und die Insider-Risk-Empfehlung erzeugt Alarme über Kollegen. Das ist eine technische Einrichtung, die zur Verhaltenskontrolle geeignet ist – § 87 Abs. 1 Nr. 6 BetrVG –, und die Betriebsvereinbarung sollte deshalb regeln, wer DSPM sieht, welche Auswertungen zu welchem Zweck stattfinden (Trends und Bereiche ja, Ranglisten von Personen nein), wer den Aktivitätsexplorer mit Namen öffnen darf und unter welchen Bedingungen ein Prompt-Volltext eingesehen wird. Meine Erfahrung: Betriebsräte begrüßen DSPM als Nachweis, dass Copilot nicht blind eingeführt wird – wenn die Auswertungsregeln vorher stehen und die Insider-Risk-Richtlinie nicht als erstes geklickt wird.

Für den Datenschutzbeauftragten ist DSPM das Material für die Datenschutz-Folgenabschätzung zu Copilot: Welche personenbezogenen Daten stecken in Prompts, welche Quellen mit welchen Labels werden verwendet, welche fremden Dienste bekommen was – alles Fragen, die Art. 35 DSGVO stellt und die vorher niemand beantworten konnte. Zugleich sind die DSPM-Daten selbst eine Verarbeitung von Beschäftigtendaten mit Zweckbindung und Löschfrist, die ins Verzeichnis der Verarbeitungstätigkeiten gehört. Und der Prompt-Volltext – im Audit-Log und per eDiscovery erreichbar – ist Beschäftigtenkommunikation, die nur mit Anlass, Vier-Augen-Prinzip und laut Betriebsvereinbarung eingesehen wird, wie bei jedem anderen Postfach auch. Für NIS2-pflichtige Unternehmen ist DSPM der Nachweis, dass die KI-Nutzung im Risikomanagement erfasst ist – vorausgesetzt, die Sensoren laufen. Wie immer: keine Rechtsberatung, Stand 2026 – Datenschutzbeauftragter, Betriebsrat und bei Bedarf ein Jurist gehören an den Tisch, bevor die erste Empfehlung geklickt wird.

Stolperfallen aus der Praxis

Null verwechselt mit sicher. Kein Onboarding, keine Erweiterung, kaum Copilot-Lizenzen – das Dashboard zeigt null, der Vorstand ist beruhigt. Erst die Sensoren, dann die Sicht.

Alle Empfehlungen an einem Nachmittag geklickt. Copilot findet nichts mehr, Insider Risk erzeugt Alarme mit Namen, die Simulation liest niemand. Einkaufsliste, nicht Essen: jede Richtlinie im Modul prüfen, im Audit lassen, dann schärfen.

DSPM als Schutzschild verkauft. „Wir haben DSPM, also ist Copilot sicher." DSPM zeigt; schützen tun Labels, DLP und Berechtigungen. Und aufräumen tun Site-Besitzer.

Datenrisikobewertung ohne Folge. Drei Sites in Rot, wöchentlich neu, und niemand hat eine Aufgabe. Jede rote Site bekommt einen Besitzer, eine Frist und eine der drei Maßnahmen.

Aktivitätsexplorer für alle Admins. Wer Namen und sensible Treffer je Benutzer sehen kann, ohne Anlass und Rolle, hat ein Betriebsratsthema geschaffen. Rollen beschränken, Auswertungsregeln in die Betriebsvereinbarung.

Schlechte SITs, gute Berichte. Der Kreditkarten-Typ trifft Artikelnummern, und DSPM meldet Hunderte sensible Prompts. Sensitive Info Types testen, bevor die Zahlen den Vorstand erreichen.

Fazit: Das Armaturenbrett für KI – wenn die Sensoren angeschlossen sind

DSPM for AI ist die Stelle, an der KI-Nutzung in Microsoft 365 sichtbar wird: Copilot, Agenten, fremde Dienste; Interaktionen, sensible Treffer, Labels der Quellen; Oversharing je Site; Empfehlungen mit fertigen Richtlinien. Es ist die Bestandsaufnahme, mit der jede Copilot-Readiness beginnt, und das Argument, das Fachbereiche, Betriebsrat und Vorstand überzeugt – vorausgesetzt, Audit läuft, Geräte sind onboardet, die Erweiterung ist verteilt und die Sensitive Info Types taugen. Es ist keine Echtzeit, es räumt nicht auf, und seine One-Click-Empfehlungen sind Vorlagen, die im Modul geprüft und nach Simulation geschärft werden. Wer das weiß, hat ein exzellentes Armaturenbrett. Wo DSPM im Gesamtbild aus Labels, DLP und Copilot-Absicherung sitzt, zeigt der Purview-Überblick.

Wenn du wissen willst, was DSPM for AI über deinen Tenant sagen würde, wenn die Sensoren angeschlossen wären – wie viele fremde KI-Dienste, wie viele sensible Prompts, welche Sites in Rot: Die Purview-Standortbestimmung liefert genau diese Bestandsaufnahme – kompakt, zum Festpreis, mit Aktionsplan für die Empfehlungen, die sich wirklich lohnen.

FAQ: Häufige Fragen zu DSPM for AI

Was ist DSPM for AI in Microsoft Purview?

DSPM for AI (Data Security Posture Management für KI, früher AI Hub) ist der Bereich im Purview-Portal, der die KI-Nutzung im Unternehmen sichtbar macht: Interaktionen mit Microsoft 365 Copilot, Copilot-Studio-Agenten und fremden KI-Diensten, sensible Daten in Prompts und Antworten, Labels der Copilot-Quellen, Datenrisikobewertungen für Oversharing in SharePoint und Empfehlungen mit One-Click-Richtlinien. Es wertet Signale anderer Module aus – Audit-Log, Sensitive Info Types, Endpoint DLP, Insider Risk – und ist die Bestandsaufnahme für jede Copilot-Readiness.

Warum zeigt DSPM for AI bei uns keine fremden KI-Dienste?

Weil die Sensoren fehlen: Fremde KI-Dienste im Browser werden nur erfasst, wenn die Geräte für Endpoint DLP onboardet sind, die Purview-Browsererweiterung für Chrome und Firefox verteilt ist (Edge nativ) und eine DLP-Richtlinie – etwa die DSPM-Empfehlung „Sensible Daten in KI-Prompts erkennen" im Audit-Modus – Aktivitäten an KI-Domänen erfasst. Ohne das zeigt das Dashboard null, nicht „unbekannt". Private Geräte, Handys und Desktop-Clients bleiben in jedem Fall unsichtbar.

Zeigt DSPM for AI den Inhalt von Prompts an?

In Berichten und Aktivitätsexplorer zeigt DSPM, dass und welcher Sensitive Info Type in einem Prompt oder einer Antwort getroffen hat, bei welchem Benutzer und in welcher App – nicht den Volltext. Der Volltext steckt im Audit-Ereignis „Copilot-Interaktion" und ist über Audit-Suche und eDiscovery mit entsprechender Rolle erreichbar. In Deutschland gehört die Einsicht in Prompt-Volltexte in die Betriebsvereinbarung: nur mit Anlass, Vier-Augen-Prinzip und definierten Rollen.

Was ist eine Datenrisikobewertung in DSPM for AI?

Eine Datenrisikobewertung (Oversharing-Assessment) bewertet SharePoint-Sites danach, wie viele sensible Elemente sie enthalten, wie breit sie freigegeben sind, wie viele Elemente kein Label tragen und wie oft Copilot dort Inhalte verwendet – und liefert eine Rangliste der für Copilot riskantesten Sites. Die Standardbewertung läuft wöchentlich über die meistgenutzten Sites; eigene Bewertungen lassen sich für gewählte Sites oder Bereiche anlegen. Aus der Bewertung heraus können Zugriff einschränken, Labels anwenden oder Restricted Content Discovery angestoßen werden – die Bereinigung selbst leisten Site-Besitzer.

Sind die One-Click-Richtlinien aus DSPM for AI sofort produktiv nutzbar?

Sie sind Startpunkte, keine fertigen Konzepte. Der Klick erzeugt eine Vorlage – DLP für Copilot, Insider Risk, Auto-Labeling, Endpoint-Erkennung, Communication Compliance – mit Microsofts Annahmen zu Labels, Sensitive Info Types und Schwellen. Jede erzeugte Richtlinie lebt in ihrem Modul, sollte dort gegen das eigene Konzept geprüft, im Audit- oder Simulationsmodus belassen und erst nach gelesenen Ergebnissen scharf geschaltet werden. Insider Risk und Communication Compliance brauchen in Deutschland zusätzlich die Betriebsvereinbarung vorab.

Brauche ich für DSPM for AI Microsoft 365 E5?

Für den vollen Umfang ja: sensible Interaktionen, Datenrisikobewertungen, Aktivitätsexplorer und die Sicht auf fremde KI setzen Microsoft 365 E5 oder E5 Compliance voraus; Insider-Risk- und Communication-Compliance-Berichte brauchen zusätzlich diese Module. Mit E3 sind Teile sichtbar – vor allem die Copilot-Interaktionszahlen bei aktiviertem Audit. Microsoft 365 Copilot selbst ist ein separates Add-on; SharePoint Advanced Management mit ergänzenden Oversharing-Berichten ist darin enthalten (Stand 2026).

Wo fange ich mit DSPM for AI an?

Mit den Sensoren: Audit aktivieren, eine Pilotgruppe von Geräten für Endpoint DLP onboarden und die Browser-Erweiterung verteilen, die Empfehlung „Sensible Daten in KI-Prompts erkennen" im Audit-Modus aktivieren – nach Abstimmung mit Betriebsrat und Datenschutzbeauftragtem. Nach zwei Wochen die Berichte lesen, die Standard-Datenrisikobewertung durchgehen und für die roten Sites Besitzer und Fristen festlegen. Danach die weiteren Empfehlungen einzeln im Modul prüfen – nicht alle auf einmal klicken.