Microsoft 365 Copilot Readiness: Was das ARA-Tool prüft und was es übersieht
- Marcus Machon
- 26. Apr.
- 10 Min. Lesezeit
Aktualisiert: 27. Apr.
Microsoft 365 Copilot Readiness klingt erst einmal nach einem rein technischen IT-Thema. In der Praxis entscheidet sie aber darüber, ob ein Microsoft 365 Copilot Rollout Vertrauen schafft – oder ob bei der Copilot Einführung plötzlich alte Risiken sichtbar werden. Denn Copilot arbeitet nicht in einem perfekt aufgeräumten Tenant, sondern in Ihrer realen Microsoft-365-Umgebung: mit alten Projekt-Teams, offenen SharePoint-Links, verwaisten Sites und historisch gewachsenen Berechtigungen. Genau deshalb stellen sich viele Unternehmen vor dem Start Fragen wie: Ist unser Tenant bereit für Microsoft 365 Copilot?, welche Berechtigungen sollte man vor dem Copilot Rollout prüfen? und welche Risiken entstehen durch Copilot in SharePoint und Teams?
Genau für diese Microsoft 365 Copilot Readiness Prüfung hat Microsoft ein eigenes Prüfwerkzeug veröffentlicht: das Automated Readiness Assessment (ARA). Open Source, MIT-Lizenz, Python, wenige Minuten Laufzeit. Die Pointe: Ein Teil dessen, wofür Unternehmen bisher teure Copilot Readiness Assessments oder externe Audits beauftragt haben, lässt sich damit automatisiert prüfen. Oder eben doch nur zum Teil.
Die Kurzversion: ARA erleichtert die technische Erstdiagnose und senkt den Aufwand für eine erste Copilot Readiness Analyse. Es ersetzt aber nicht die Übersetzung in einen belastbaren Microsoft 365 Copilot Rollout-Plan. Für Projektleitende ist deshalb nicht die entscheidende Frage, ob ARA „grün“ oder „rot“ meldet. Was davon ist wirklich relevant, was ist nur Tool-Rauschen, und welche Maßnahmen gehören vor den Copilot-Rollout?"
Warum braucht Microsoft 365 Copilot überhaupt ein Readiness-Audit?
Ein Readiness-Audit prüft, ob Ihre Microsoft-365-Umgebung für den Einsatz von Copilot vorbereitet ist. Dabei geht es nicht nur um Lizenzen, sondern vor allem um Berechtigungen, Sicherheitsregeln, Datenklassifikation und die Frage, wie Informationen im Arbeitsalltag tatsächlich genutzt und geteilt werden.
Der Grund ist einfach: Copilot kann nur auf Inhalte zugreifen, auf die Mitarbeitende selbst zugreifen dürfen. Wenn in SharePoint zu viel offen liegt, erzeugt Copilot dieses Problem nicht neu. Aber Copilot macht es schneller sichtbar – und damit oft auch dringlicher.
Genau an dieser Stelle geraten viele Copilot-Rollouts ins Stocken. Gartner berichtete 2024, dass 40 Prozent der befragten IT-Entscheider ihren Rollout wegen Oversharing und fehlender Data Governance um mindestens drei Monate verschoben hatten. Eine Folge-Erhebung 2025 zeigte zudem, dass nur rund fünf Prozent der pilotierenden Unternehmen Copilot tatsächlich in den breiten Einsatz überführen. Für Projektleitende ist das eine zentrale Erkenntnis: Solche Vorhaben scheitern selten am Kick-off, sondern an der Skalierung.
Auch auf der Nutzenseite ist das Bild gemischt. Gartner fand 2024, dass nur drei Prozent der befragten CIOs Microsoft 365 Copilot nach zwei Jahren als „significant value“ bewerten. Recon Analytics meldete Anfang 2026 unter US-Befragten mit bezahltem Arbeitsplatz-Zugang eine aktive Copilot-Nutzung von rund 36 Prozent – deutlich niedriger als bei ChatGPT. Anders gesagt: Ohne klaren Adoption-Plan wird aus Copilot schnell ein Lizenzthema statt eines echten Produktivitätsprojekts.
Für den DACH-Mittelstand kommt ein zweiter Punkt hinzu: Die Nutzung von KI wächst schneller als die zugehörige Governance. Bitkom-Daten aus 2025/2026 zeigen, dass 41 Prozent der deutschen Unternehmen ab 20 Mitarbeitenden KI bereits einsetzen, weitere 48 Prozent planen oder diskutieren den Einsatz. Gleichzeitig haben laut Maximal-Digital-Studie 76 Prozent der KMU kein KI-Governance-Framework.
Mein Eindruck: Copilot scheitert selten an Microsoft allein. Es scheitert meist an zwei vorbereitenden Fragen, die zu spät gestellt werden: Ist der Tenant sauber genug? Und sind die Menschen auf einen KI-Assistenten vorbereitet, der mit Unternehmenswissen arbeitet?
Was prüft das ARA-Tool tatsächlich?
ARA liest über Microsoft-APIs und PowerShell-Module Konfigurationen aus Ihrem Microsoft-365-Tenant aus und gleicht sie mit Copilot-Readiness-Checklisten ab. Dazu gehören unter anderem Microsoft Graph, Defender-APIs, Exchange/Purview-PowerShell, Power-Platform-APIs und Copilot-Admin-APIs. Geprüft werden sieben Service-Bereiche: M365, Entra, Defender, Purview, Power Platform, Copilot Studio und A365 (Agent 365).
Das Ergebnis ist kein fertiger Beratungsbericht, sondern ein technischer Snapshot: CSV- und Excel-Dateien mit Empfehlungen, Prioritäten und Beobachtungen. ARA sagt also ungefähr: „Diese Einstellungen habe ich gefunden, diese Punkte passen zur Readiness-Checkliste, diese Punkte sollten Sie prüfen."
Wichtig für Nicht-Admins: ARA ist kein Werkzeug, das heimlich Inhalte liest und bewertet wie ein Mensch. Es prüft Konfigurationen und Metadaten. Trotzdem braucht der Scan weitreichende Lesezugriffe, zum Beispiel auf Verzeichnis-, Nutzer-, SharePoint-, Defender- und Reportdaten. Deshalb gehören Betriebsrat, Datenschutz und eine saubere Ablage der Reports vor dem Lauf geklärt. Bei externen Dienstleistern kommt ein Auftragsverarbeitungsvertrag dazu.
ARA beantwortet also eine wichtige Frage: Wie sieht die technische Ausgangslage aus? Es beantwortet nicht automatisch: Was sollen wir jetzt tun?
Was zeigt ein ARA-Report in der Praxis?
Ich habe ARA auf meinem eigenen Tenant getestet. Der Scan lief in 14 Sekunden durch. Ergebnis: 109 Empfehlungen, zwei davon rot markiert. Auf den ersten Blick klingt das nach Arbeit. In meinem Fall war es das nicht.
Ein rotes Finding lautete sinngemäß: „Nur 11 Prozent der Nutzer haben MFA aktiviert." MFA bedeutet Multi-Faktor-Authentifizierung, also die zusätzliche Anmeldung per App, SMS oder Sicherheitsschlüssel. Klingt kritisch. Tatsächlich zählte ARA aber auch B2B-Gäste, eine Shared Mailbox und einen bewusst ohne MFA angelegten Notfall-Admin mit. Für die relevanten interaktiven Konten war MFA erzwungen.
Der Unterschied ist wichtig: ARA misst, ob ein Konto eine MFA-Methode registriert hat. Es sieht nicht immer sauber, ob Conditional Access die MFA in der Praxis erzwingt. Für einen automatisierten Scanner ist das nachvollziehbar. Für eine Management-Entscheidung ist es ohne Übersetzung irreführend.
Ein zweites Finding meldete keine SharePoint-Sites, obwohl per PowerShell 28 Sites sichtbar waren. Das war schlicht ein Tool-Artefakt.
Meine Bilanz aus dem Test: Diagnose ist kein Maßnahmenplan. Rohdaten sind keine Empfehlung. „High Priority" heißt nicht automatisch „sofort handeln".
Von 91 Report-Zeilen in der Detailauswertung waren rund 70 Prozent Lizenz-Bestandsnachweise, weitere 15 Prozent allgemeine Adoption-Hinweise, einige Einträge Tool-Artefakte oder alte Produktreste. Nur fünf bis sechs Punkte waren echte Handlungshinweise. Genau deshalb ist ARA wertvoll, aber nicht selbsterklärend.
Was sieht ARA nicht?
ARA ist ein Konfigurations-Scanner. Es prüft, ob bestimmte Regeln, Policies oder Einstellungen existieren. Die größten Copilot-Risiken liegen aber oft eine Ebene darunter: in echten Daten, echten Berechtigungen und echten Arbeitsweisen.
1. Berechtigungs-Tiefe in SharePoint. ARA kann Hinweise auf Policies geben. Es sieht aber nicht zuverlässig, welche Dateien über „Jeder mit dem Link" geteilt sind, wo Berechtigungen in Unterordnern abweichen und welche Sites historisch zu offen geworden sind. Concentric AI fand im Data Risk Report 2H 2025, dass 57 Prozent aller organisationsweit geteilten Datensätze sensitive Inhalte enthalten. Mehr als ein Drittel der untersuchten „Anyone Link"-Freigaben führte auf vertrauliches Material. Das ist kein DACH-Benchmark, aber ein starkes Risikosignal: Freigabeprobleme sind selten Einzelfälle, sie sind oft Strukturprobleme.
2. Qualität der Sensitivity Labels. Sensitivity Labels sind Vertraulichkeitskennzeichnungen wie „Intern", „Vertraulich" oder „Streng vertraulich". ARA kann sehen, ob Label-Policies existieren. Es weiß aber nicht, ob eine Gehaltsliste fälschlich als „Public" markiert wurde. Und ein wichtiger technischer Punkt: Ein Label auf einer Teams- oder SharePoint-Site klassifiziert nicht automatisch jede Datei darin.
3. Adoption-Readiness. ARA kann nicht prüfen, ob Mitarbeitende Copilot sinnvoll nutzen werden. Eine große Feldstudie von Dillon et al. mit mehr als 6.000 Personen in 56 Firmen fand, dass nur 38 Prozent der Personen mit Zugriff Copilot wöchentlich nutzten. Positive Gegenbeispiele gibt es: Der UK Government Digital Service Pilot mit 20.000 Beschäftigten kam auf 26 Minuten Zeitersparnis pro Tag, und mehr als 80 Prozent wollten Copilot behalten. Der Unterschied liegt nicht im Lizenzschlüssel, sondern im Rollout: Training, Champion-Netzwerk, konkrete Copilot Use Cases (und das klingt leichter als es ist). ARA sagt, ob der Tenant technisch vorbereitet ist. Es sagt nicht, ob die Menschen vorbereitet sind.
4. Ownership und Prozesse. Viele Mittelständler haben Teams ohne klare Owner, alte SharePoint-Sites, inaktive Gruppen und Daten aus Projekten, die niemand mehr verantwortet. Das ist keine einzelne Einstellung, sondern ein Prozessproblem. ARA kann es nur begrenzt erkennen.
Diese Grenzen sind keine Schwäche von ARA. Sie zeigen nur, was ein automatisierter Scan leisten kann und was nicht.
Welche Werkzeuge gehören neben ARA?
Wenn ARA die technische Policy-Schicht prüft, braucht es für die Daten- und Prozess-Schicht andere Bausteine. Der wichtigste Microsoft-Baustein ist SharePoint Advanced Management (SAM) oder auf Deutsch: SharePoint Erweiterte Verwaltung.
SAM hilft bei Fragen wie: Welche Sites haben besonders offene Berechtigungen? Wo gibt es „Anyone Links"? Welche Sites sollen für Copilot vorübergehend nicht auffindbar sein? Welche Sites brauchen Owner-Reviews oder eine Inactive-Sites-Policy?
Für Projektleitende ist dabei weniger der Produktname entscheidend als die Rollenverteilung:
ARA liefert eine technische Baseline.
SAM und Purview helfen bei Datenzugriff, Klassifikation und Schutzregeln.
Fachbereiche müssen Ownership, Datenklassen und Freigabeentscheidungen tragen.
Projektleitung muss daraus eine priorisierte Roadmap machen.
Das ist der Kern: ARA ersetzt nicht das Projekt. ARA unterstützt die Diagnosephase.
Was sollte vor dem Copilot-Rollout passieren?
ARA und SAM sind Werkzeuge, keine Strategie. Ein guter Copilot-Rollout braucht wenige, klare Arbeitspakete. Nicht 20 parallele Governance-Workstreams, sondern die Punkte, die Risiko und Nutzbarkeit wirklich beeinflussen.
In den ersten zwei Wochen sollten Sie die größten offenen Flanken prüfen. Dazu gehören Sharing-Defaults, also die Standard-Einstellung beim Teilen von Dateien. „Jeder mit dem Link" ist bequem, aber häufig die wichtigste Quelle für Oversharing. Für viele Unternehmen ist „Bestimmte Personen" der bessere Standard.
Ebenfalls wichtig ist die SharePoint-Gruppe „Alle außer externe Nutzer". Sie klingt harmlos, bedeutet aber oft: fast alle internen Personen können zugreifen. Wenn diese Gruppe historisch in Sites oder Bibliotheken steckt, wird Copilot später genau diese Offenheit respektieren.
Dazu kommen Gastzugriffe, Baseline-Reports aus SharePoint und ARA sowie ein Blick auf EU-Flex-Routing. Microsoft erlaubt seit April 2026 in bestimmten Situationen KI-Inferenz außerhalb der EU-Datenregion. Das muss nicht automatisch ein Problem sein, sollte aber bewusst entschieden werden.
In den nächsten 30 bis 90 Tagen braucht es ein schlankes Klassifikationsmodell. Vier Stufen reichen meistens: Public, Intern, Vertraulich, Streng vertraulich. Mehr klingt sauberer, wird aber im Alltag schlechter benutzt.
DLP-Regeln sollten zunächst im Audit-Modus starten. DLP steht für Data Loss Prevention, also Regeln, die sensible Inhalte erkennen und Aktionen protokollieren oder blockieren können. Wer sofort zu viele Regeln blockierend aktiviert, produziert Frust und Ausweichverhalten.
Jede wichtige SharePoint-Site braucht außerdem mindestens zwei fachliche Owner. Nicht „die IT", sondern Menschen im Fachbereich, die entscheiden können: Wer braucht Zugriff? Was ist noch aktiv? Was kann archiviert werden?
Im laufenden Betrieb gehören monatliche Reports, regelmäßige Access Reviews, eine Richtlinie für inaktive Sites, ein Blick auf Copilot-Nutzung und eine saubere Betriebsvereinbarung dazu.
Concentric meldete im selben Report im Schnitt vier Millionen verwaiste Datensätze pro Organisation.
Auch diese Zahl ist als Risikosignal zu lesen, nicht als Mittelstands-Benchmark. Die Richtung ist aber klar: Ohne laufende Ownership-Pflege wächst das Problem nach dem Audit sofort wieder nach.
Was Sie eher vermeiden sollten: eine Taxonomie mit 20 Labels, ein Komplettstopp von Copilot beim ersten Oversharing-Fund, 30 DLP-Regeln im Blockier-Modus oder ein neues Drittanbieter-Tool, bevor Owner-Modell und Klassifikation geklärt sind.
Warum SharePoint-Informationsarchitektur die eigentliche Langstrecke ist
Viele SharePoint-Tenants im Mittelstand sind gewachsen, nicht geplant. Microsoft Teams wurden erstellt, sobald jemand sie brauchte. Projektsites blieben nach Projektende bestehen. Berechtigungen wurden einzeln angepasst, weil es in dem Moment schnell gehen musste.
Copilot macht diese Struktur nicht kaputt. Aber Copilot arbeitet mit ihr.
Deshalb braucht ein Copilot-Rollout eine einfache Informationsarchitektur: Team Sites für Zusammenarbeit, Communication Sites für Intranet und Publishing, Hub Sites als Dach für zusammengehörige Bereiche. Jede Site braucht einen fachlichen Owner, einen Zweck und einen Lebenszyklus.
Ausführlicher Blogpost dazu hier: https://www.nous-works.de/post/sharepoint-struktur-im-mittelstand
In Kundengesprächen nutze ich oft dieses Bild: SharePoint ist das Großhirn, Teams sind die Muskeln. Teams ist die tägliche Arbeitsoberfläche. SharePoint ist der strukturierte Wissensspeicher darunter. Wenn SharePoint unklar ist, wird Teams hektisch und Copilot findet zwar viel, aber nicht zwingend das Richtige.
Informationsarchitektur ist kein Tool-Kauf. Sie ist ein Prozess über Monate und Jahre. Aber sie ist die nachhaltigste Antwort auf Oversharing. Und hat Auswirkungen auf Produktivität, Daten, Wissen, Kollaboration, Kommunikation, Adoption und vieles, vieles mehr.
Warum Adoption genauso wichtig ist wie Technik
Die meisten Oversharing-Situationen entstehen nicht aus bösem Willen. Sie entstehen aus Zeitdruck und Unsicherheit. Jemand muss schnell eine Datei teilen, kennt die Berechtigungslogik nicht genau und nimmt den Link, der garantiert funktioniert.
Deshalb gehört in jeden Copilot-Rollout eine Adoption-Schicht. Gute Trainings sind kurz, szenariobasiert und nah an echten Aufgaben: „Wie teile ich einen Finanzbericht richtig?", „Welche Daten gehören nicht in einen Prompt?", „Wann ist ein Team besser als ein Chat?"
Champion-Netzwerke helfen ebenfalls. Ein Champion pro Bereich oder Team ist oft wirksamer als eine zentrale Schulung für alle. Dazu kommen offene Sprechstunden, kleine FAQ-Sammlungen und ein Ort, an dem Mitarbeitende Fragen stellen können, ohne ein offizielles Ticket zu eröffnen.
Das klingt weniger technisch als ARA, ist aber genauso Copilot Readiness. Die technische Seite reduziert Risiko. Die Adoption-Seite erzeugt Nutzen.
Was heißt das für Ihren Rollout-Plan?
Wenn Sie aktuell einen Copilot-Readiness-Audit planen, bereits Copilot-Lizenzen ausgerollt haben oder feststellen, dass viele Lizenzen kaum genutzt werden, ist ARA ein guter Startpunkt. Es zeigt schnell, wo die technische Basis steht.
Aber der eigentliche Wert entsteht danach. Ein ARA-Report muss sortiert werden: Was ist kritisch? Was ist ein Artefakt? Was ist ein Quick Win? Was gehört in eine 90-Tage-Roadmap? Was ist langfristige Informationsarchitektur?
Für Projektleitende heißt das: Behandeln Sie ARA nicht als Abnahmeprotokoll, sondern als Eingangsmaterial. Der Rollout wird nicht dadurch besser, dass ein Excel-Report viele grüne Zeilen enthält. Er wird besser, wenn die roten und gelben Punkte in verständliche Entscheidungen übersetzt werden.
Wenn Sie ARA selbst nicht laufen lassen können oder den Output nicht allein in einen Copilot-Rollout-Plan übersetzen wollen, unterstütze ich dabei.
Marcus Machon berät Mittelständler bei Microsoft 365 Governance und KI-Readiness.
Quellen
Microsoft Tech Community: „Accelerating Microsoft 365 Copilot Adoption with Automated Readiness Assessment", techcommunity.microsoft.com, März 2026
GitHub-Repo: microsoft/m365-copilot-automated-readiness-assessment, MIT License
Concentric AI Data Risk Report 2H 2025 (Jan–Jun 2025, sechs Branchen): Copilot-Zugriff, Org-weite Freigaben, Anyone Links, Personal Accounts, Orphaned Data
Gartner (Juni 2024, n=132; öffentlich berichtet u.a. Computerworld): 40 Prozent verzögern Copilot-Rollout wegen Oversharing, 64 Prozent Governance-Aufwand
Gartner 2025 M365 & Copilot Survey (n=187): nur 5–6 Prozent skalieren zum Breiteneinsatz
Gartner „The State of Microsoft 365 Copilot: Survey Results" (Herbst 2024, n=165 CIOs): 3 Prozent „significant value"
Recon Analytics U.S. AI Survey (150.000+ Befragte, Jul 2025 – Jan 2026): Conversion 35,8% vs. ChatGPT 83,1%, NPS −19,8, Marktanteil 18,8 → 11,5 Prozent
Microsoft Earnings Q2 FY2026 (28.01.2026): 15 Mio. Copilot-Seats bei 450 Mio. M365-Seats = 3,3 Prozent
Dillon et al. (2025) RCT, arXiv 2504.11443, n=6.000+ in 56 Firmen
UK Government Digital Service / Microsoft WorkLab Copilot Pilot (Sep–Dez 2024, n=20.000)
Microsoft Learn: Flex Routing (EU/EFTA), April 2026
CVE-2025-32711 („EchoLeak"), CVSS 9,3: Aim Labs Disclosure, Microsoft-Patch Juni 2025
Microsoft Purview Sensitivity Labels Documentation: Container-Labels vererben sich nicht auf Items
Microsoft Learn Purview DLP for Copilot: labelbasierte Exklusion GA, Prompt-DLP im Rollout
Microsoft Learn Retention for Copilot & AI apps + eDiscovery AI data: Konversationslöschung löscht Memory nicht automatisch
Microsoft Learn SharePoint Advanced Management: DAG Reports, RCD, RAC, RSS, Site Access Reviews, Site Ownership Policy, Inactive Sites Policy, Licensing (Stand April 2026)
Hessischer Beauftragter für Datenschutz (HBDI), 15.11.2025: M365 datenschutzkonform
Europäischer Datenschutzbeauftragter (EDPS), 08.03.2024 / 11.07.2025: Verfahren gegen EU-Kommission nach Nachbesserungen geschlossen
Bitkom KI-Studien 2025/2026 (CATI, n=602/604 Unternehmen ≥20 MA): 41 Prozent KI-Nutzung in Deutschland, 48 Prozent planen/diskutieren, wachsende Schatten-KI-Realität
Maximal Digital KI-Studie 2025 (DACH-Mittelstand): 76 Prozent ohne KI-Governance-Framework, 81 Prozent ohne systematische ROI-Messung
Eigene Praxis-Beobachtungen aus Sales-Calls und Workshops 2026 (Top-Frust-Punkte, Hybrid-Nutzung, Frontline-Gap)
Randnotiz: Wie dieser Beitrag entstanden ist
ARA habe ich nicht durch eine Google-Suche gefunden, sondern weil mein eigenes KI-Wissenssystem es mir vorgelegt hat. Stellt euch das vor wie eine digitale Assistenz, die jeden Tag und jede Woche Fachquellen für mich durchliest: Microsoft-Blogs, Gartner-Berichte, Fachstudien, Newsletter, wissenschaftliche Paper. Sie erkennt, welche Inhalte für meine Themen relevant sind, zieht Kernaussagen heraus, ordnet sie ins Wissenssystem ein und merkt sich Quelle, Datum und Vertrauensgrad. Wenn ich an einem Beitrag schreibe oder einen Kunden berate, holt sie mir die passenden Zahlen automatisch hervor.
Für diesen Artikel heißt das: Die Zahlen im Text, von den 57 Prozent org-weit geteilter sensibler Daten bis zur 64-Prozent-Shelfware-Quote, stammen aus einer Sammlung von Studien, Vendor-Reports, Behördenberichten und verifizierten Quellen-Notizen, die über Monate gewachsen ist. Der Concentric-Report 2H 2025 landete morgens als neue Quelle im System, wurde gegen eine ältere Version abgeglichen und war nachmittags als Beleg im Text. Jede Erfahrung mit Tools wie ARA fließt zurück ins System. Details hier: https://www.nous-works.de/post/ki-faktenpruefung-wissenssystem. Dieses System funktioniert immer besser, Fehler können trotzdem passieren.
Das Prinzip: Nicht KI als Antwort-Automat, sondern KI als kontinuierlich wachsendes Zweit-Gehirn. Wie ich das technisch gebaut habe, beschreibe ich in meinem Beitrag Mein Multi-Agent-System aufbauen. Der gleiche Mechanismus lässt sich auf Unternehmenswissen übertragen: Produktdokumentation, Kundenwissen, regulatorische Änderungen, alles wo Wissen schneller veraltet als Menschen es lesen können.
