Position Paper · April 2026

AI Transition in der Microsoft-Weltwarum Prompting nicht der Engpass ist

Eine Position für CIOs und Enterprise-Architekten zur nächsten großen IT-Welle nach Active Directory, Cloud, Modern Workplace und Cloud Security.

Lead

Wenn Microsoft 365 Copilot in einem Unternehmen nicht den Wert liefert, der erwartet wurde, liegt das nach meiner Erfahrung selten nur am Modell oder an den Prompts. Häufiger zeigen sich die Probleme eine Ebene tiefer: Datenhygiene, Permission-Architektur, Adoption-Realität und Schatten-IT-Strukturen, die quer zur formalen IT-Governance laufen.

Diese vier Schichten sind aus den letzten großen Microsoft-Transitions bekannt. Sie sind genau die Stellen, an denen Beratungsangebote oft am dünnsten sind. Am Ende entscheiden diese Schichten oft stärker über den Nutzen als das Modell selbst oder die Qualität einzelner Prompts.

Das Paper richtet sich an CIOs und Architekten, die den ersten AI-Hype gesehen haben und jetzt wissen wollen, was in der zweiten Welle wirklich tragfähig ist.

1. Die Wiederholung – fünf Wellen, ein Muster

Active Directory war 1999 keine LDAP-Frage. Es war eine Datenfrage. Wer aus einer NT4-Domäne migriert hat, weiß: Was die Migration aufgehalten hat, waren nicht Schemata oder Replikationspfade. Es waren inkonsistente Account-Datenbestände, die sich über Jahre angesammelt hatten – tote User mit aktiven Mailboxen, Service-Accounts ohne Owner, Gruppenstrukturen, die niemand mehr abbilden konnte.

Die Cloud-Welle ab 2011 brachte dasselbe Muster eine Schicht höher. Was Migrationen nach Office 365 oder Azure ausgebremst hat, waren nicht die Hyperscaler-Features. Es waren On-Prem-Permissions, die nie sauber waren, NTFS-Berechtigungen, die mit jedem Domain-Trust komplexer wurden, Mailbox-Delegationen, die historisch gewachsen waren. Die Cloud hat diese Strukturen nicht erzeugt – sie hat sie sichtbar gemacht.

Modern Workplace ab 2017 hat das Spiel auf die Verhaltensseite gezogen. Teams, Intune, Conditional Access waren technisch kein Problem. Was die Skalierung bremste, war die Adoption-Realität: Wer arbeitet wirklich in Teams, wer schickt weiter Word-Anhänge per Mail? Wer nutzt SharePoint, wer schiebt PDFs durch persönliche OneDrive-Ordner?

Cloud Security ab 2020 hat dieselbe Lektion eine Etage höher wiederholt. Conditional Access, Defender for Cloud Apps, Purview – die Tools waren da. Was nie passiert ist: die Vorarbeit. Sensitivity-Labels wurden nicht ausgerollt, Information-Protection-Policies blieben Strategie-Folien, Compliance-Reporting war eher Kunst als Routine.

Das Muster wiederholt sich: Microsoft liefert die Welle technisch sauber. Schwierig bleibt die organisatorische und architektonische Vorarbeit – die Datenstrukturen, die Berechtigungslogik, die Abbildung tatsächlicher Workflows. Die fünfte Welle ist agentisches AI in M365 und Azure. Sie wirkt – und das ist ihr entscheidender Unterschied – in allen vorigen Schichten gleichzeitig.

2. Was AI anders macht

Bisherige Wellen waren additiv. Active Directory hat SAM und NTLM ergänzt. Die Cloud hat On-Prem ergänzt. Modern Workplace hat das klassische Office ergänzt. AI in M365 und Azure ergänzt nichts. Es liest und interpretiert die existierende Datenbasis live – und es macht das so umfassend, dass alle Defizite der vorherigen Wellen erstmals gleichzeitig sichtbar werden.

Das Symptom kennt jeder, der Copilot in einem realen Tenant aktiviert hat: Eine Frage wird perfekt beantwortet – aus einem fünf Jahre alten Word-Dokument, das niemand in der Organisation mehr als gültig betrachtet. Das ist kein Modellfehler. Das ist ein Lifecycle-Versagen, das das Geschäft jetzt täglich trifft.

Das zweite Symptom ist heikler. Copilot zeigt einem Mitarbeiter Inhalte aus SharePoint-Sites und anderen Quellen, auf die er technisch Zugriff hat – aber organisatorisch nicht haben sollte. Permission-Sprawl, der seit Jahren toleriert wurde, weil ihn niemand aktiv suchte, wird über die natürliche Sprache der LLM-Schnittstelle plötzlich geschäftskritisch sichtbar.

Und das dritte Symptom ist das aufschlussreichste. Copilot legt offen, welche Workflows tatsächlich in M365 stattfinden – und welche nur dort vermutet werden, während sie in Wirklichkeit in Excel-Anhängen, persönlichen Mail-Postfächern und Schatten-IT laufen. Die Audit-Trails, die nie sauber gepflegt wurden, schlagen jetzt täglich auf den Tisch der CIO-Offices auf.

Die Architekturfrage der nächsten zwölf Monate lautet deshalb weniger, welches Modell genutzt wird. Entscheidend ist, welche Daten, Berechtigungen und Arbeitsweisen unter dem Modell liegen.

3. Die realen Engpässe

Vier Schichten entscheiden, ob Copilot oder Agenten produktiv werden. Prompting steht nicht in dieser Liste.

3.1 Datenhygiene und Lifecycle

Die meisten M365-Tenants tragen ein Erbe von zehn bis fünfzehn Jahren ungeordnetem Wachstum. SharePoint-Sites, die nie archiviert wurden. OneDrive-Bestände ehemaliger Mitarbeiter, die nicht migriert oder gelöscht wurden. Mail-Archive, die im Graph-Index gewichtet werden, ohne dass Inhalt oder Aufbewahrungspflicht je dokumentiert wurde. Sensitivity-Labels, wo sie überhaupt vorhanden sind, sind oft inkonsistent verteilt – einige Sites streng klassifiziert, andere völlig offen.

Wer Copilot auf diese Datenbasis loslässt, bekommt ein Modell, das aus redundantem oder nicht mehr gültigem Material antwortet. Der Wert leidet dann weniger an schlechten Prompts als an einer Wissensbasis, die über Jahre niemand wirklich gepflegt hat.

3.2 Permission-Architektur

Die zweite Schicht ist die schwierigere. Restricted SharePoint Search ist eine Entscheidung, die jeder Tenant treffen muss – an, mit klarer Begründung, oder aus, mit klarer Begründung. Beides geht. Stillschweigend Default-Verhalten zu akzeptieren geht nicht. Graph Connectors, Sharing-Policies, Site-Level- versus Library-Level-Permissions, Guest-Access-Hygiene – jeder dieser Punkte war schon vor Copilot eine offene Baustelle. Mit Copilot wird er zur Compliance-Frage.

Die unbequeme Folgerung: Bevor Copilot über Department- oder Enterprise-Skalen geht, gehört ein Permission-Audit an mindestens den Top-50 Sites mit hochsensiblen Daten zwingend in den Plan. Nicht als optionales Add-On, sondern als Voraussetzung.

3.3 Workflow-Realität

Die dritte Schicht ist die ehrlichste – und sie ist unbequem. Welche Workflows laufen heute tatsächlich in M365? Welche laufen außerhalb, über Mail-Anhänge, über lokale Excel-Sheets, über persönliche OneDrives? Welche sind dokumentiert genug, dass ein Agent sie überhaupt ausführen könnte?

Diese Frage betrifft nicht die Technik, sondern die Organisation. Sie ist deshalb in den meisten Pilot-Projekten ein blinder Fleck – weil sie nicht durch Tooling beantwortet werden kann, sondern durch Beobachtung der realen Arbeitsweise.

Prompt-Engineering bleibt 2026 nützlich, vor allem für Endnutzer und konkrete Arbeitsroutinen. Für strategische Beratungsbudgets ist es aber selten der eigentliche Hebel.

3.4 Schatten-IT und interne Macht-Strukturen

Die meisten Whitepapers über Enterprise-AI ignorieren einen Punkt, den jeder Praktiker aus realen Großunternehmen kennt: in größeren Organisationen gibt es fast immer Macht- und Verhaltensstrukturen, die quer zur formalen IT-Governance laufen. Abteilungen bestellen Hardware bei Amazon. Bereichsleiter holen sich externe Berater, ohne den CIO zu informieren. Fachbereiche aktivieren SaaS-Tools mit der Firmen-Kreditkarte und schalten sie produktiv, bevor irgendeine Sicherheitsprüfung stattgefunden hat.

Das war schon immer ein Problem. Mit AI wird es zu einem anderen.

Wer einer Schatten-IT erlaubt, neue SaaS-Tools mit AI-Funktionen anzulegen – ohne dass die darunterliegende Daten- und Berechtigungsstruktur unter Kontrolle ist – multipliziert die Risiken aus den vorigen drei Schichten. Sensible Daten landen in Drittanbieter-LLMs ohne Vertragsbasis. Berechtigungslücken werden in mehreren Tenants gleichzeitig sichtbar. Audit-Trails fragmentieren über Systeme, die der CISO nicht einmal kennt.

Die Frage ist deshalb nicht nur architektonisch, sondern auch politisch. Wie geht eine Organisation damit um, dass Fachbereiche faktisch souverän AI-Tools beschaffen – während die Hauptverantwortung für die Konsequenzen weiter bei der zentralen IT liegt? Diese Frage ist in sehr vielen deutschen Großunternehmen 2026 noch unbeantwortet. Sie wird 2027 nicht mehr verschoben werden können.

4. Die Adoption-Schere

Jede vorherige Welle hatte eine Schere zwischen privaten Frühnutzern und Verweigerern. Bei AI wirkt diese Schere anders – sie ist nicht mehr Privatsache, sondern wird zum direkten Produktivitätsfaktor im Unternehmen.

Ob bei PC, Mobilfunk, Internet, Streaming, Social Media – jedes Mal gab es eine private Adoptions-Spaltung. Mitarbeiter, die zuhause schon Tabellen kalkulierten oder ihre Bankgeschäfte digital erledigten, saßen neben Kollegen, die noch fünf Jahre später Faxe in der Hand hielten. Für Unternehmen war das weitgehend irrelevant: ob jemand abends Schallplatten oder Spotify hörte, hatte keinen messbaren Einfluss auf die Montagsleistung. Privatadoption war Privatsache.

Bei AI verschiebt sich das Gewicht deutlich.

Auf der einen Seite der Schere: der Performer, der vor dem Schlafengehen einen Agenten beauftragt, am nächsten Morgen den Lieferdienst zu organisieren. Der sich daran gewöhnt hat, Aufgaben in zwei Sätzen zu formulieren und in Sekunden umsetzen zu lassen. Auf der anderen Seite: der Mitarbeiter, der seinen Erfolg gerade darin misst, wie konsequent er AI aus seinem Leben fernhält. Beide Profile gibt es schon heute, in jeder Belegschaft.

Hier geht es nicht mehr nur um unterschiedlichen Geschmack. Hier treffen unterschiedliche Arbeitsmethoden, Geschwindigkeitserwartungen und Vorstellungen davon aufeinander, was eigentlich erledigt werden muss. Diese Differenz wirkt – ab dem ersten Arbeitstag.

Die Schere geht außerdem schneller auseinander als bei früheren Wellen. Wer privat tagtäglich mit Agenten arbeitet, baut innerhalb von Monaten eine Werkzeugkompetenz auf, die durch interne Schulungen kaum aufholbar ist. Wer verweigert, fällt im selben Tempo zurück. Was bei PC oder Internet noch über Jahre verteilt war, geschieht hier in Quartalen.

Was das für die nächste Phase bedeutet: Tenant-Architektur und Datenhygiene allein lösen das Problem nicht. Wer Copilot oder Custom Agents skaliert, ohne die unterschiedlichen privaten Adoptions-Niveaus seiner Belegschaft anzuerkennen und zu adressieren, baut auf eine schiefe Grundfläche – und wundert sich, warum dieselbe Investition in einem Team Wunder wirkt und in einem anderen verpufft.

5. Readiness-Checkliste – zehn Punkte vor Copilot

Bevor ein Tenant Copilot oder Agenten produktiv über Pilot-Skalen hinaus sieht, sollten diese zehn Punkte geklärt sein. Keiner ist optional.

1. Sensitivity-Label-Strategie definiert und ausgerollt – mindestens drei Stufen (Public, Internal, Confidential), mit klaren Klassifizierungsregeln und durchgesetzter Default-Klassifizierung für Neu-Inhalte.
2. SharePoint-Site-Inventar mit klarem Owner und Lifecycle-Status. Sites ohne Owner sind Sicherheits- und Adoption-Risiko gleichermaßen.
3. Restricted SharePoint Search bewusst aktiviert oder bewusst deaktiviert – mit dokumentierter Begründung. Default-Verhalten akzeptieren ist keine Architektur.
4. Sharing-Policies auf aktuelle Geschäftslogik aktualisiert. Anonymous- und External-Sharing-Settings nach heutigem Bedarf, nicht nach historischen Defaults aus 2017.
5. Permissions-Audit für mindestens die Top-50 Sites mit hochsensiblen Daten – mit dokumentiertem Cleanup vor Copilot-Rollout.
6. Mail-Archivierung und PST-Konsolidierung abgeschlossen. PSTs auf Endpoints sind für Copilot unsichtbar – aber sie verschleiern, wo das Wissen wirklich liegt.
7. M365-Audit-Logs dauerhaft mindestens ein Jahr aufbewahrt und tatsächlich auswertbar – nicht nur theoretisch konfiguriert.
8. Conditional Access mit Microsoft 365 Copilot kompatibel. Kein implizites Bypass durch fehlende oder zu generische Policies.
9. Adoption-Baseline dokumentiert. Welche Workflows laufen wirklich in M365, welche außerhalb, und in welchen Volumina?
10. Stage-Plan Pilot → Department → Enterprise mit klar definierten Erfolgskriterien je Stufe – und mit Kill-Kriterien, die ein Eskalations-Stop ermöglichen, wenn die Architektur-Vorarbeit später nicht trägt.

Diese Liste ersetzt keine Roadmap. Sie ist die Vorbedingung, die jede Roadmap erst glaubwürdig macht.

6. Die nächsten zwölf Monate

Sobald Druck entsteht, läuft die Adoption schneller als bei früheren Wellen, weil die Arbeitsweise mit AI-Assistenten in vielen Fachbereichen längst über persönliche ChatGPT- oder Claude-Nutzung etabliert ist – nur eben außerhalb der Unternehmens-Tenants.

Das Phasenmodell, wie es sich aktuell darstellt:

Q2–Q3 2026: Konsolidierungsphase. Erste Welle Copilot-Pilots hat nicht den Wert geliefert, der versprochen wurde. Frustration in Linienorganisationen, tiefere Fragen erreichen die CIO-Offices. Die ersten Architektur-Diskussionen entstehen – oft zu spät für die Pilots, gerade rechtzeitig für die nächste Stufe.

Q4 2026 – Q1 2027: Zweite Welle mit Custom Agents über Copilot Studio. Erfolgreicher dort, wo die Architektur-Vorbereitung passiert ist. Skill-Gap im Markt wird sichtbar – die Kombination aus M365-Tiefe, Security-Verständnis und AI-Architektur-Kompetenz wird selten.

2027: Mainstream-Adoption mit deutlichem Druck auf Unternehmen ohne Vorarbeit. Skill-Verfügbarkeit wird knapp und teuer. Externe Beratung verschiebt sich vom Implementierungsfokus zur Sanierungsarbeit.

Für CIOs ist das vor allem eine Frage des Timings: Nutzen wir die nächsten zwölf Monate für Architektur-Vorarbeit, oder laufen wir 2027 hinter dem Markt her?

Closing

Diese Architektur-Vorarbeit ist die eigentliche Aufgabe der nächsten zwölf Monate. Sie ist nicht spektakulär. Sie produziert keine Demo-Folien, sie liefert keine Marketing-Geschichten, sie sieht in Konferenz-Slides langweilig aus. Aber sie ist genau das, was den Unterschied macht zwischen einem teuren Pilot-Friedhof und einer tatsächlich produktiven AI-Transition.

Gerade deshalb werden Microsoft-Architekten mit zwanzig oder mehr Jahren Stack-Erfahrung wieder wertvoll: Sie kennen die Ebene unter den Prompts.

Oliver Hanzal-Bayer arbeitet seit 1998 mit Microsoft-Plattformen und positioniert sich aktuell für die nächste große Transition. Mehr unter cv.haba-consult.de.

Persönliche/professionelle Präsentation. Produkt-, Firmen- und Markennamen gehören ihren jeweiligen Inhabern; ihre Nennung bedeutet keine Freigabe, Partnerschaft oder Empfehlung durch aktuelle oder frühere Arbeitgeber, Kunden oder Anbieter.