MICROSOFT 365 – Neuerungen Q4/2025

von | Sep. 21, 2025 | Copilot, Fachartikel, SharePoint, Teams | 0 Kommentare

Table of Contents
2
3

Consulting, Beratung

Microsoft 365 - die erwarteten Neuerungen in Q4/2025
Consulting Startseite

In diesem Artikel stelle ich die erwarteten Änderungen dar, soweit aus öffentlich zugänglichen Quellen recherchierbar. Keine Gewähr, dass dies wirklich so kommt!

 

Management Summary

  • KI im Fokus: Microsoft 365 Copilot wird bis Ende 2025 breiter ausgerollt – mit neuen Funktionen wie Sprachsteuerung und automatischen E-Mail-Entwürfen. Dies verspricht einen deutlichen Produktivitätsschub, erfordert aber klare Richtlinien (z. B. DSGVO-konformes Prompting) und Schulungen[1][2].
  • Teams-Premium-Funktionen: Für Microsoft Teams erscheinen im Q4/2025 hochrelevante Neuerungen. Dazu zählen ein Bildschirmaufnahme-Schutz in Meetings (Vertraulichkeitsschutz, nur mit Teams Premium)[3] sowie KI-gestützte Raum-Empfehlungen für Hybrid-Meetings[4]. Diese Features erhöhen Sicherheit und Effizienz, bringen aber Lizenzkosten und Änderungsmanagement-Aufwand mit sich.
  • Optimiertes Teilen & Content-Automation: OneDrive/SharePoint führen mit dem Hero Link einen einzigen Freigabelink pro Datei ein (Rollout ab Ende 2025), der Zugriffsrechte konsolidiert und versehentliche Freigaben reduziert[5]. Parallel bringt SharePoint Premium KI-gestützte Dokumentenverarbeitung (ehemals Syntex) in den Produktiveinsatz, um Inhalte automatisch zu klassifizieren und für Copilot aufzubereiten[6] – ein großer Schritt für Governance und Wissensmanagement.
  • Produktivitäts-Updates: Die neue Outlook-Version erreicht Funktionsparität: Mehrere E-Mail-Signaturen kommen laut Roadmap bis Q4 2025 zurück[7]; Drag-&-Drop von Mails zwischen Konten ist ab Oktober 2025 möglich[8]. Microsoft Planner verschmilzt mit Project – Premium-Funktionen (Zeitpläne, Abhängigkeiten) und der KI-gestützte Planungsassistent („Project Manager“) stehen nun allgemein zur Verfügung[9].
  • Security & Compliance gestärkt: Neue Purview DLP-Funktionen schützen Daten noch gezielter: Just-in-Time-Regeln für SharePoint (Preview) verhindern Datenabfluss genau im Risikofall[10]. Außerdem blockiert Purview ab Nov 2025 sensible Eingaben in ChatGPT & Co. im Edge-Browser[11]. Defender for Office 365 warnt jetzt bei bösartigen Links in Teams-Chats[12]. Diese Neuerungen erfüllen teils BSI-Empfehlungen und kommende EU AI Act-Vorgaben zur sicheren KI-Nutzung.

Inhaltsverzeichnis

Einordnung: Was ändert sich in Q4 2025 in Microsoft 365?

Q4 2025 (Oktober–Dezember 2025) markiert für Microsoft 365 eine entscheidende Phase: KI-Funktionen werden vom Hype zur Praxis. Nachdem 2023/2024 vor allem Pilotprojekte liefen, stehen viele KI-gestützte Funktionen jetzt vor dem breiten Rollout. Das betrifft insbesondere Microsoft 365 Copilot, der als digitaler Assistent Office-Anwendungen durchdringt. Die Ankündigungen aus dem Microsoft 365 Roadmap und den Tech Communities zeigen: Im letzten Jahresquartal sollen Copilot und andere Neuerungen „allgemein verfügbar“ werden – teils mit Zusatztarif (z. B. 30 USD/E5-Benutzer für Copilot), teils als Bestandteil vorhandener Pläne (z. B. Neuerungen in Exchange Online, OneDrive, etc.).

Gleichzeitig legt Microsoft großen Wert auf Sicherheit und Compliance. Mehrere neue Features zielen darauf ab, Datenabflüsse zu verhindern (etwa durch Policy-Verbesserungen in Purview DLP) und Bedrohungen frühzeitig abzuwehren (z. B. erweiterter Phishing-Schutz bis in Teams hinein). Diese technischen Änderungen erfolgen vor dem Hintergrund verschärfter Regulierungen: So steht der EU AI Act in den Startlöchern, der den Einsatz von KI-Systemen wie Copilot regulieren wird, und Unternehmen in Deutschland müssen weiterhin DSGVO und BSI-Empfehlungen bei Cloud-Nutzung beachten. Microsoft reagiert hier mit neuen Kontrollmöglichkeiten, etwa Entra ID für KI-Identitäten oder Purview-Funktionen zum sicheren Umgang mit KI-Plattformen.

Auch die Nutzererfahrung entwickelt sich weiter. Im Modern-Workplace-Bereich fallen besonders Verbesserungen in Teams (neue Premium-Funktionen) und Outlook (Funktionalitätslücken der neuen App werden geschlossen) ins Gewicht. SharePoint und OneDrive bringen Innovationen, um Zusammenarbeit effizienter zu gestalten – von smarteren Links bis zu KI in der Dokumentenverwaltung. Für Administratoren bedeutet dies, sich auf einige Änderungen in Admin-Portalen, Richtlinien-Workflows und Lizenzlandschaft einzustellen.

Insgesamt lässt sich Q4 2025 als Übergangsphase vom Pilot zum Standardbetrieb neuer Microsoft-365-Funktionalitäten begreifen. Untenstehend finden Sie eine nach Bereichen sortierte Tabelle der wichtigsten Neuerungen mit Status, Zeitplan, Relevanz und Nutzen – gefolgt von detaillierten Beschreibungen pro Eintrag. Prognosen („Erwartungen“) sind klar gekennzeichnet und enthalten eine geschätzte Wahrscheinlichkeit. Regulierte Organisationen sollten insbesondere die Abschnitte zu Security/Compliance sowie Lizenzierung beachten, um rechtzeitig Vorbereitungen (z. B. DPIAs, Budgetierung) für die kommenden Änderungen zu treffen.

Neuerungen nach Bereich (Q4 2025)

Bereich

Neuerung/Funktion

Status

Zeitraum/Fenster

Relevanz (Zielgruppe)

Nutzen auf den Punkt

Eintritts- wahrscheinlichkeit

Copilot für Microsoft 365

Voice Chat für M365 Copilot – Sprachbefehle zur Interaktion mit Copilot (Desktop/Mobile)[1]

Allgemein verfügbar

August 2025

hoch (IT-Leitung, Fachbereich)

Ermöglicht freihändiges Arbeiten: Nutzer können Copilot per Stimme steuern, um Infos zu suchen, Meetings nachzubereiten etc. – schnellerer, intuitiver Workflow.

–

Copilot für Microsoft 365

Proaktive E-Mail-Entwürfe in Outlook – Copilot schlägt Antworten auf wichtige Mails vor[2]

Allgemein verfügbar

September 2025

hoch (Fachbereich)

Spart Zeit bei E-Mails: Copilot identifiziert unbeantwortete Top-Mails und erstellt automatisch 3 Vorschläge für Antworttexte – priorisiertes Abarbeiten des Postfachs.

–

Microsoft Teams

Bildschirmaufnahme-Schutz (Teams Premium) – Sperrt Screenshots/Aufnahmen im Meeting[3]

Allgemein verfügbar

Oktober 2025

hoch (Security, Compliance)

Verhindert Abfotografieren sensibler Inhalte während Besprechungen (Multi-Plattform). Erhöht Vertraulichkeit in vertraulichen Meetings, z. B. Vorstandssitzungen, ohne manuelle Kontrollen.

–

Microsoft Teams

KI-Raum-Empfehlung (Teams Premium) – Automatische Vorschläge für Meetingräume[4]

Allgemein verfügbar

Oktober 2025

mittel (Fachbereich, Facility Mgmt)

Steigert Präsenzmeeting-Quote: Ist kein Raum gebucht, empfiehlt Teams ~1 Stunde vor Start einen passenden freien Raum auf Basis der Teilnehmer-Standorte – erleichtert spontane Hybrid-Meetings.

–

OneDrive<br/>SharePoint Online

“Hero Link” Freigabe – Einheitlicher Freigabelink pro Datei ersetzt multiple Einzel-Links[5][13]

Angekündigt (Rollout ab Ende 2025)

Q4 2025

hoch (Admin, alle Nutzer)

Vereinfachtes Teilen: Jede Datei hat einen zentralen Link, der sämtliche Zugriffsrechte steuert. Weniger versehentliche Freigaben & einfachere Verwaltung von Berechtigungen, da Benutzer nicht mehr mehrere Links je Datei handhaben müssen.

–

SharePoint Premium

KI-Dokumentenverarbeitung (Syntex) – Autom. Klassifizierung, Metadatentagging, eSignatur u.a.[6]

Public Preview

seit 2024 (Ignite 2023)

hoch (IT-Leitung, Compliance)

Nutzbarmachung unstrukturierter Inhalte: KI extrahiert aus Verträgen & Co. wichtige Metadaten, versieht Dateien mit Term-Labels und automatisiert Routine-Dokumente. Steigert Datenqualität, spart Zeit und bereitet Inhalte optimal für M365 Copilot vor (bessere Antworten).

–

Outlook (Neu)

Mehrere E-Mail-Signaturen – Neue Outlook-App unterstützt wieder mehrere Signaturvorlagen[7]

Angekündigt

Q4 2025

hoch (Fachbereich, Admin)

Wiederherstellung einer essentiellen Produktivitätsfunktion: Benutzer können je Absenderkonto oder Zweck unterschiedliche Signaturen nutzen (z. B. intern vs. extern). Erhöht Effizienz und Professionalität der Kommunikation.

–

Outlook (Neu)

Drag-&-Drop zwischen Konten – E-Mails/Anhänge direkt zwischen Postfächern verschieben[8]

Allgemein verfügbar

Oktober 2025

mittel (Admin, Fachbereich)

Verbesserte Nutzerfreundlichkeit im neuen Outlook: Anwender können z. B. eine Mail aus dem privaten in das Firmenkonto ziehen oder Anhänge zwischen Konten teilen, ohne Umweg. Erleichtert Multi-Account-Workflows erheblich.

–

Planner / Project

KI-Planungsassistent (Project Manager) – Copilot-Funktionen integriert in Planner[9]

Allgemein verfügbar

seit Aug 2025

mittel (Fachbereich, Projektleiter)

Intelligente Projektplanung: Teams mit M365 Copilot-Lizenz können in Planner per Chatbot komplette Pläne generieren lassen, Statusberichte erstellen oder Aufgaben automatisiert ausformulieren. Entlastet Projektmanager, fördert Standardisierung.

–

Microsoft Entra ID

Agent ID für KI-Bots – Eindeutige Identitäten & Zugriffssteuerung für AI/Autonomous Agents[14]

Angekündigt (Preview)

ab Juni 2025

mittel (Architektur, Security)

Identitäts-Governance für KI: Jeder KI-Agent (z. B. Copilot-Plugin) erhält eine eigene Entra-ID. Dadurch können org.-weit dieselben Security-Prinzipien gelten wie für Nutzer (Login, Conditional Access, Logging). Verringert Risiko unkontrollierter KI-Aktionen und schafft Compliance-Transparenz.

–

Microsoft Purview

JIT DLP für SharePoint – „Just-in-Time“-Schutz greift beim sensiblen Zugriff[10]

Public Preview

Oktober 2025

mittel (Compliance, Admin)

Dynamischer Datensschutz: Dateien, die bislang unklassifiziert sind, werden erst im Moment eines externen Zugriffs automatisch mit DLP-Restriktionen belegt. So wird Datenabfluss unterbunden, ohne interne Kollaboration unnötig einzuschränken.

–

Microsoft Purview

DLP für KI-Apps im Edge – Blockiert Eingabe vertraulicher Daten bei ChatGPT & Co[11][15]

Allgemein verfügbar

November 2025

hoch (Compliance, Security)

KI-gerechter Datenschutz: Edge for Business erkennt nun, wenn Nutzer z. B. vertrauliche Texte in generative KI-Webtools eingeben, und verhindert dies inline. Schutz vor unbewusstem DSGVO-Verstoß (z. B. Kundenpaste in ChatGPT) – wichtig im Kontext EU AI Act.

–

Defender für Office 365

Böslink-Warnungen in Teams – Safe Links prüft & markiert schadhafte URLs in Chats[12]

Allgemein verfügbar

Q4 2025

hoch (Security, Admin)

Ausweitung des Phishing-Schutzes: Klickt ein Nutzer auf einen unsicheren Link im Teams-Chat, wird nun analog zu E-Mails eine Warnmeldung angezeigt bzw. der Zugriff blockiert. Erhöht die Sicherheit in der internen Kommunikation, ohne dass Endanwender aktiv werden müssen.

–

Detaillierte Beschreibungen der Neuerungen

Im Folgenden werden alle in der Tabelle gelisteten Neuerungen aus Q4 2025 ausführlich beschrieben – unterteilt nach Zweck, Bedeutung, technischen Hintergründen, Governance-Aspekten, Anwendungsbeispielen, Lizenzfragen, Risiken sowie Empfehlungen für die Einführung. Offiziell bestätigte Funktionen haben den Status Allgemein verfügbar, Public Preview oder Angekündigt (per Roadmap oder Blog), während als Erwartung gekennzeichnete Punkte plausible Prognosen sind (mit begründeter Wahrscheinlichkeit).

Copilot für Microsoft 365 – Voice Chat (Sprachsteuerung)

Kurzbeschreibung: Microsoft 365 Copilot unterstützt nun die Sprachsteuerung auf Desktop und Mobilgeräten. Anwender können also per gesprochenem Wort mit Copilot interagieren, fast so, als würden sie mit einem Kollegen reden. Diese Voice Chat-Funktion wurde im Sommer 2025 angekündigt und allgemein freigegeben[1]. Copilot kann durch ein Mikrofon aktiv zuhören und auf Befehle oder Fragen des Nutzers reagieren – z. B. Dokumente suchen, Zusammenfassungen vorlesen oder Aktionen ausführen. Im Grunde erweitert diese Neuerung die Eingabemodalitäten von Copilot: neben Tippen ist jetzt auch freihändige Bedienung möglich.

Warum es wichtig ist: Durch Voice Chat wird Copilot noch intuitiver und schneller nutzbar. Viele Tätigkeiten lassen sich mündlich oft effizienter anstoßen, als sie umständlich zu tippen – insbesondere unterwegs oder in Multitasking-Situationen. Beispielsweise kann ein Manager im Auto per Sprache eine Teams-Zusammenfassung anfordern, ohne auf die Tastatur schauen zu müssen. Dies fördert die Produktivität, da Mitarbeiter flexibler arbeiten können. Auch Barrierefreiheit ist ein Aspekt: Nutzer mit motorischen Einschränkungen oder Sehschwierigkeiten profitieren von Sprachbedienung. Nicht zuletzt senkt es die Hemmschwelle, KI im Alltag einzusetzen – was die Akzeptanz von Copilot weiter erhöhen dürfte. Allerdings erfordert Sprachsteuerung auch Vertrauen (Geräte „lauschen“ mit) – daher müssen Unternehmen transparente Kommunikation über Datenschutz betreiben.

Technische Details: Voice Chat für Copilot basiert auf Microsofts Spracherkennung (Azure Cognitive Services). Die Funktion ist in den jeweiligen Apps integriert (z. B. Copilot-Fenster in Teams, Word etc.) und erfordert ein Mikrofon am Gerät. Datenfluss: Das gesprochene Kommando wird als Audiostream an Microsoft-365-Cloudserver übertragen, dort transkribiert und an das KI-Modell (GPT-4-basiert) geschickt. Wichtig: Die Spracheingabe wird nicht lokal verarbeitet, sondern in Microsofts Cloud – Audio-Aufnahmen könnten temporär gespeichert werden, was DSGVO-relevant ist (s. Risiken unten). Der Tenant-Admin hat jedoch Einstellungen, um Copilot-Funktionen zu steuern; in den Tenant-Einstellungen (Power Platform Admin Center unter „AI settings“) lässt sich Copilot für bestimmte Apps aktivieren/unterbinden – inkl. der Spracheingabe. Die Rollout-Mechanik war „standard“: In E5-Testtenants erschien Voice automatisch ab August 2025, in Produktion je nach Release-Ring bis Ende Oktober. Es gibt keine besonderen Limits – außer natürlich eventuelle Latenz bei schwacher Internetverbindung.

Architektur/Governance: Aus Governance-Sicht bringt Voice Chat neue Herausforderungen: Sprachkommandos können andere Aktionen auslösen als beabsichtigt (Erkennungsfehler). Unternehmen sollten Richtlinien definieren, wann und wie Spracheingabe zulässig ist (z. B. nicht in Großraumbüros, um Störungen oder versehentliche Auslösungen zu vermeiden). Rollen und Berechtigungen: Die Fähigkeit, Copilot per Sprache zu bedienen, hängt von der allgemeinen Copilot-Berechtigung ab – d. h. wer Copilot lizenziert hat und nutzen darf, kann auch die Sprache nutzen, es sei denn, Admins deaktivieren Voice gezielt. Datenfluss: Audioaufnahmen könnten theoretisch als diagnostische Daten bei Microsoft landen – dies sollte im Verzeichnis der Verarbeitungstätigkeiten berücksichtigt werden. Der EU AI Act klassifiziert Sprachsteuerung zwar nicht direkt, aber als Teil eines generativen KI-Systems; Unternehmen sollten prüfen, ob eine Risiko-Bewertung nötig ist (wahrscheinlich eher nein, da Copilot vom Provider kontrolliert wird und nicht hochrisiko-eingestuft ist). Gleichwohl könnte die BSI empfehlen, Sprachinterfaces in sicherheitskritischen Bereichen (z. B. KRITIS-Unternehmen) restriktiv zu handhaben – analog zu Smartphones mit aktiven Mikros.

Anwendungsbeispiel (Schritte): Szenario: Ein Vertriebsleiter möchte sich während der Fahrt einen schnellen Überblick über ein Angebot verschaffen, ohne auf den Laptop zu schauen.
1. Er öffnet auf dem Smartphone die Teams-Mobile-App, wo Microsoft 365 Copilot integriert ist (alternativ könnte es auch die mobile Outlook-App sein).
2. Per Klick auf das Copilot-Mikrofon-Symbol aktiviert er den Voice Chat. Copilot signalisiert (Ton/Symbol) dass es zuhört.
3. Er spricht: „Gib mir eine Zusammenfassung des Angebots Projekt Alpha im OneDrive-Ordner Vertrieb/Deals.“
4. Die Sprachaufnahme wird in Text umgewandelt. Copilot erkennt Schlagworte („Zusammenfassung“, „Angebot Projekt Alpha“, Pfadangabe) und durchsucht OneDrive/SharePoint nach dem betreffenden Dokument.
5. Copilot öffnet das Dokument in der Cloud, analysiert den Inhalt (evt. mit GPT-4 Modell) und erstellt eine stichpunktartige Zusammenfassung.
6. Über Text-to-Speech liest Copilot dem Vertriebsleiter die Zusammenfassung laut vor. Gleichzeitig zeigt die App die erkannten Kernpunkte als Text an.
7. Der Leiter kann nun weiter per Sprache Fragen stellen, z. B. „Vergleiche das mit dem Angebot Projekt Beta“. Copilot würde dann entsprechend beide Dokumente heranziehen und Unterschiede erläutern.
8. Zum Abschluss sagt er „Schicke diese Zusammenfassung an mein Team“. Copilot generiert aus den Punkten eine Chat-Nachricht und sendet sie in den ausgewählten Teams-Kanal – fertig.

(Hinweis: Ob letzter Schritt – automatisches Versenden – erfolgt, hängt von Copilots Fähigkeiten in der jeweiligen App ab. In Teams Chat dürfte es klappen; in Outlook müsste es einen Mail-Entwurf erstellen, den der Nutzer noch absendet.)

Auswirkungen auf Lizenzen & Kosten: Die Voice-Funktion erfordert keinen separaten Lizenzkauf, ist aber natürlich an Microsoft 365 Copilot selbst gebunden. Sprich: Nur Kunden mit dem Copilot-Add-On (derzeit ~30 USD/Benutzer/Monat) können davon profitieren. Es gibt keine gestaffelte Voice-Option – alle Copilot-Lizenzen enthalten alle Interaktionsmodi. Allerdings könnte durch den gesteigerten Nutzen die Adoption von Copilot im Unternehmen zunehmen, was zu Mehrkosten führt, wenn mehr Benutzer eine Lizenz erhalten sollen. Von den Microsoft 365 Plänen her gilt: Copilot (und damit Voice Chat) setzt E3/E5 voraus (für Business Basic/Standard wird es bisher nicht angeboten). In regulierten Branchen mit Telemetrie-Vorgaben sollte man einkalkulieren, dass die Bandbreite für Audio etwas höher sein kann – Kosteneffekt aber minimal.

Risiken & Gegenmaßnahmen: Bei Spracheingabe besteht ein Datenschutzrisiko: Gesprächsmitschnitte könnten persönliche Daten enthalten. Auch wenn Microsoft versichert, Audio nur transient zu verarbeiten, sollte die Rechtsabteilung klären, ob eine DSFA (Datenschutz-Folgenabschätzung) nötig ist. Gegenmaßnahmen: Genaue Dokumentation im Verzeichnis der Verarbeitung, Info an Mitarbeiter, ggf. Einwilligungen falls erforderlich. Ein weiteres Risiko ist Fehlerkennung – Copilot könnte Befehle missverstehen (z. B. etwas löschen). Hier empfiehlt es sich, sicherheitskritische Aktionen durch Copilot zu begrenzen (ggf. deaktivieren Admins die Funktion „Inhalte löschen“ über Copilot). Außerdem drohen Mikro-Missbrauch: Theoretisch könnte jemand in der Nähe eines Computers durch lautes Rufen Copilot aktivieren. Unternehmen können diesem „unauthorisierten Zuruf“ vorbeugen, indem sie z. B. die Wake-Words in Besprechungsräumen deaktivieren oder Nutzer sensibilisieren, Headsets zu verwenden. Vom EU AI Act her ist Copilot als Generative AI ein System, das Transparenz erfordert: Unternehmen sollten offenlegen, wo KI (per Sprache) genutzt wird. BSI-Hinweis: Audioeingaben könnten Teil der Voice-Phishing-Angriffsfläche sein – Schulung und Tools (z. B. akustisches Signal bei Aktivierung) minimieren dieses Risiko.

Einführung & Change Management: Die Aktivierung von Voice Chat verlief tenant-weit; es gibt keine spezifische Pilot-Freischaltung außer der generellen Copilot-Testphase. Daher ist es ratsam, vor dem Rollout an alle Copilot-User eine Pilotgruppe definieren zu lassen (etwa IT-Abteilung oder „Early Adopter“-Team), um praktische Erfahrungen und potenzielle Probleme zu sammeln. Idealerweise wird die Sprachsteuerung erst nach diesem internen Test dem gesamten Unternehmen verfügbar gemacht. Kommunikation: Ein mehrstufiger Informationsplan ist sinnvoll – zunächst Ankündigung im Intranet/Newsletter („Ab sofort können Sie Copilot auch ansprechen…“), gepaart mit einem kurzen How-to-Video zum neuen Bedienkonzept. Wichtig: auch auf Datenschutz eingehen („Ihr Gesagtes wird nur zu Microsoft gesendet, um…“). Schulung: Hier bietet sich eine interaktive Live-Demo in einer Teams-Schulung an, damit Nutzer Hemmungen verlieren und den Nutzen erkennen. Metriken (KPIs) für Erfolg könnten sein: Anzahl der Voice-Copilot-Anfragen pro Woche (im Vergleich zur Texteingabe), Zufriedenheitsbewertungen nach dem Rollout (durch Survey). Change-Agenten (Tech-Begeisterte aus Fachbereichen) können als Ansprechpartner fungieren, um Feedback einzusammeln. Wichtig ist auch der Support: Helpdesk sollte vorbereitet sein auf Fragen wie „Copilot versteht mich nicht“ – evtl. mit Checklisten (Mikro an? Sprache richtig erkannt? etc.). Ein begleitendes FAQ (intern) ist hilfreich.

Checkliste Umsetzung:
– [ ] IT-Policies geprüft: Datenschutzteam hat Freigabe für Voice Chat erteilt (ggf. DSFA durchgeführt, Mitarbeiterinformationen versandt).
– [ ] Admin-Einstellungen konfiguriert: Option für Copilot Voice Input tenant-weit erlaubt oder falls gewünscht auf bestimmte Apps/User beschränkt (nach heutigem Stand nur global möglich).
– [ ] Pilotphase durchgeführt: Kleine Nutzergruppe hat Voice Chat getestet; Feedback gesammelt (Erfolgsquote Sprachbefehle, Missverständnisse dokumentiert).
– [ ] Schulungsmaterial bereit: Kurzanleitung und ggf. Video-Tutorial erstellt, mit Praxisbeispielen speziell für unser Geschäftsmodell (z. B. Vertriebs-Use-Case).
– [ ] Support vorbereitet: Helpdesk-Mitarbeiter über Funktionsweise und häufige Probleme informiert (Mikrofonzugriff, Sprache nicht erkannt, etc.).
– [ ] Kommunikation an alle: Launch-Mitteilung veröffentlicht (Intranet-News, E-Mail der IT-Leitung) mit Betonung des Nutzens und Hinweis auf verfügbare Trainings und Datenschutz.
– [ ] Monitoring aktiv: Post-Rollout Überwachung der Nutzung (z. B. via Microsoft 365 Admin Report für Copilot-Usage) sowie Abfrage von Nutzerfeedback nach ~4 Wochen (ggf. über Viva Insights Stimmungsumfrage).
– [ ] Notfall-Plan vorhanden: Falls gravierende Probleme auftreten (z. B. Fehlfunktionen oder Datenschutz-Inzident), ist klar definiert, wie Voice Chat temporär deaktiviert werden könnte (z. B. via Support-Ticket bei Microsoft).

Quellen/Referenzen: Microsoft TechCommunity Blog – “What’s new in Microsoft 365 Copilot | August 2025”, 01.09.2025[1]; Microsoft 365 Roadmap ID 481138 – “Voice in Microsoft 365 Copilot”, Stand: Aug 2025[16].

Copilot für Outlook – Proaktive E-Mail-Entwürfe

Kurzbeschreibung: Copilot hält nun Einzug in den Posteingang: In Microsoft Outlook (für Web und neue Windows-App) erkennt der KI-Assistent dringende, unbeantwortete E-Mails und erstellt automatisch proaktive Antwortentwürfe. Konkret generiert Copilot bis zu drei formulierte Antwortvorschläge, aus denen der Nutzer auswählen kann[2]. Diese Funktion – in der Roadmap als „Proactive Drafts“ geführt (ID 497671) – wurde im September 2025 allgemein verfügbar gemacht. Sie soll Benutzer unterstützen, die E-Mail-Flut effizienter zu bewältigen, indem Routineantworten vorbereitet werden. Copilot analysiert dazu den Inhalt empfangener Mails und antizipiert mögliche Antworten, ohne dass der Nutzer danach fragen muss.

Warum es wichtig ist: E-Mail ist nach wie vor eines der zeitintensivsten Kommunikationsmittel. Proaktive Entwürfe bieten enormes Produktivitätspotential: Benutzer sparen täglich Minuten bis Stunden, wenn Copilot Standardanfragen (z. B. Terminbitten, Statusanfragen, einfache Nachfragen) automatisch beantwortet. Insbesondere Führungskräfte oder Sachbearbeiter mit hohem Mail-Aufkommen profitieren. Darüber hinaus werden durch KI-Formulierung auch Qualität und Einheitlichkeit erhöht – Copilot zieht relevante Fakten heran (z. B. aus vorangegangenen E-Mails) und formuliert höflich und kontextbezogen. Für die Benutzerakzeptanz ist diese „Magie“ ein Aha-Effekt: Anders als bei Chatbots, die man aktiv befragen muss, zeigt Copilot hier eigeninitiativ Mehrwert. Natürlich gilt: Der Mensch behält Kontrolle – kein Mailversand ohne Prüfung. Trotzdem könnten Nutzer Ängste haben („antwortet Copilot in meinem Namen falsch?“), was mit Kommunikation und Training adressiert werden muss. Aus Compliance-Sicht ist relevant, dass KI auf E-Mail-Inhalte zugreift – Stichwort DSGVO und Betriebsvereinbarung.

Technische Details: Die proaktive Draft-Funktion ist eng in Outlook integriert (verfügbar ab Version 2025 Build 16.x oder höher bzw. im Outlook Web). Voraussetzung ist, dass der Benutzer Microsoft 365 Copilot lizenziert und aktiviert hat. Copilot läuft serverseitig: Es scannt regelmäßig den Posteingang nach ungelesenen oder markierten Nachrichten, die innerhalb eines definierten Zeitfensters (z. B. letzte 7 Tage) keine Antwort vom Nutzer erhalten haben. Dabei priorisiert es nach Wichtigkeit (erkennt z. B. Mails vom Vorgesetzten oder solche mit Fragezeichen im Text). Für ausgewählte Mails generiert das GPT-4-Modell im Hintergrund bis zu drei Antwortvarianten (formell, neutral, knapp – dies kann variieren). Anzeigen: In der Outlook-Oberfläche erscheinen diese Vorschläge oberhalb des Antwortfelds, inklusive einer kurzen Erläuterung („Copilot hat 3 Antwortentwürfe für Sie vorbereitet“). Der Nutzer kann einen auswählen, bei Bedarf bearbeiten und dann versenden. Technisch ruft Copilot dafür E-Mail-Inhalte aus Exchange Online ab (entsprechende Graph-API-Berechtigungen hatte es ja schon für bestehende Copilot-Funktionen). Limits: Copilot wird nicht für jede Mail Vorschläge liefern – bei sehr komplexen oder sensiblen Themen bleibt es stumm (Trainingsdaten/Governor). Außerdem verarbeitet es nur Mails in unterstützten Sprachen (Deutsch wird unterstützt, jedoch erfolgte initialer Preview auf Englisch). Tenant-Einstellungen: Admins können im Microsoft 365 Admin Center unter Einstellungen > Copilot steuern, ob proaktive Vorschläge aktiviert sind. Standard war bei Rollout „an“ für berechtigte Nutzer. Falls Organisationen Bedenken hatten, konnte es via PowerShell (Set-UserCopilotConfig) abgeschaltet werden.

Architektur/Governance: Governance-Frage: Dürfen KI-Modelle eigenständig E-Mail-Inhalte verarbeiten? Hier ist Transparentz wichtig – Unternehmen sollten Nutzern klarmachen, dass E-Mail-Inhalte vom KI-Service analysiert werden (im Rahmen des genehmigten Copilot-Einsatzes). Die Datenauswertung erfolgt in Microsofts Cloud (OpenAI-Backbone in US-Rechenzentren, Stand 2025), was unter DSGVO als Auftragsverarbeitung läuft – MS bietet DPA dafür. Richtlinien: Falls es already eine Betriebsvereinbarung zum Mail-Scanning (z. B. für Spamfilter) gibt, muss geprüft werden, ob KI-Analysen abgedeckt sind. Möglicherweise verlangen Arbeitnehmervertreter, dass kein vollautomatischer Versand erfolgt (hier ist zum Glück ein menschlicher Review ohnehin vorgesehen – Key-Control!). Rollen: Welche Benutzer diese Funktion nutzen dürfen, richtet sich nach Copilot-Lizenz und eventuell Pilot-Zulassung; Governance-Boards könnten aber entscheiden, es z. B. für bestimmte Abteilungen vorerst nicht zu erlauben (etwa HR, wenn dort keine KI in Mails gewünscht). Datenfluss intern: Proaktive Vorschläge können Daten aus anderen Mails zusammenfassen – theoretisch könnte Copilot also Interna in den Entwurf packen, die im ursprünglichen Mailverlauf nicht standen (aber aus ähnlichen Fällen gelernt sind). Das ist ein potenzielles Compliance-Thema (unbeabsichtigte Informationsweitergabe). Hier empfiehlt es sich, Policies/Awareness zu schaffen, dass Nutzer Entwürfe gründlich prüfen, insbesondere auf vertrauliche Inhalte. Entra ID und Compliance-Logs: Alle KI-Aktivitäten werden als Copilot-Actions geloggt, Admins können nachverfolgen, welche Antworten generiert wurden (Audit Log). Dies unterstützt bei eventuellen späteren Analysen (z. B. bei Fehlversand).

Anwendungsbeispiel (konkret): Szenario: Eine Sachbearbeiterin im Kundenservice hat viele offene E-Mails. Copilot hilft ihr, Routineantworten schneller zu erstellen.
1. Die Mitarbeiterin öffnet morgens Outlook. Im Posteingang befinden sich u.a. mehrere Kunden-E-Mails, die gestern eingingen.
2. Sie klickt auf eine unbeantwortete Mail von Kunde X, Betreff „Status meiner Bestellung?“. Die Mail ist markiert als wichtig.
3. Outlook zeigt oberhalb der Nachricht drei hervorgehobene Antwortvorschläge von Copilot an, z. B.:
– Entwurf 1 (freundlich-informativ): „Guten Tag Frau Schulz, vielen Dank für Ihre Anfrage. Ihre Bestellung

befindet sich aktuell auf dem Versandweg und wird voraussichtlich am 5. Dezember zugestellt. Bei weiteren Fragen stehe ich gern zur Verfügung…“
– Entwurf 2 (knapp): „Hallo Frau Schulz, Ihre Bestellung

ist unterwegs. Vsl. Lieferdatum: 5. Dez. Bei Fragen melden Sie sich gern.“
– Entwurf 3 (sehr formal): „Sehr geehrte Frau Schulz, wie gewünscht informiere ich Sie über den Status Ihrer Bestellung. Diese wurde am 1. Dezember versandt und wird gemäß DHL-Tracking am 5. Dezember eintreffen…“
4. Die Mitarbeiterin wählt Entwurf 1 aus, ergänzt noch eine persönliche Anrede und überprüft Fakten (Copilot hat Sendungsnummer und Datum korrekt eingefügt, ggf. aus dem ERP-System via Graph?).
5. Ein kurzer Blick auf Entwurf 2 zeigt ihr, dass Entwurf 1 ausführlicher ist – sie bleibt dabei.
6. Sie klickt auf „Senden“. Die Antwort geht an den Kunden raus.
7. Bei der nächsten Mail (ähnliches Anliegen eines anderen Kunden) stellt sie fest, dass Copilot fast denselben hochwertigen Entwurf anbietet – die KI hat also aus dem vorherigen Kontext gelernt, was gut passte (bzw. es ist ein Template, das auf ähnliche Anfragen angewandt wird).
8. Die Bearbeiterin spart so pro Mail vielleicht 2–3 Minuten. Über die Woche verteilt summiert sich das auf Stunden.

Auswirkungen auf Lizenzen & Kosten: Auch diese Copilot-Funktion ist im Copilot-Add-On enthalten – keine zusätzlichen Kosten pro se. Allerdings tangiert es möglicherweise Exchange Online Postfächer: Administrativ sollte geprüft werden, ob durch die KI-Analyse das Mailbox Throttling beeinflusst wird (unwahrscheinlich). Keine Anpassung der M365-Pläne nötig, so lange Copilot lizenziert ist. Copilot-Lizenzierung: Falls anfangs nur ein Teil der Belegschaft Copilot hatte (wegen Kosten), könnte der Mehrwert bei E-Mail-Bearbeitung ein Grund sein, den Lizenzumfang auszuweiten – das gehört in die Lizenzstrategie-Betrachtung. Copilot-Vorschläge generieren minimal mehr Rechenlast auf Microsoft-Seite; Microsoft könnte langfristig, wenn solche Features massiv genutzt werden, die Preise anpassen – aber im Q4 2025 nicht abzusehen. Für IT-Einkauf relevant: Es gibt (Stand heute) keine separate SKU für „nur Copilot für Outlook“ – immer nur das Gesamtpaket.

Risiken & Gegenmaßnahmen: Die automatisierte Analyse von E-Mails durch KI wirft Datenschutzfragen auf: Werden dadurch sensible Inhalte zu Trainingszwecken genutzt? Microsoft betont, dass Kundendaten nicht zur allgemeinen KI-Modellschulung verwendet werden, sondern nur instanzbezogen[16]. Dennoch sollte die DSGVO-Compliance geprüft sein (Auftragsverarbeitung durch Microsoft, TOMs vorhanden, evt. Erwägungsgrund 22 anwendbar, da semiautomatisiert). Eine DSFA kann ratsam sein, insbesondere falls in Mails personenbezogene Daten im Spiel sind (was fast immer der Fall ist). Fehlantworten sind ein konkretes Risiko: Copilot könnte falsche Auskünfte geben (etwa falsches Lieferdatum, weil es trainierte Muster falsch anwendet). Gegenmaßnahme: strikte interne Vorgabe, dass kein Copilot-Entwurf unkontrolliert versendet werden darf – was ja auch dem Design entspricht. Man könnte auch bewusst Limits setzen: bestimmte Schlüsselwörter (Preise, Rabatte) vielleicht als No-Go für aut. Vorschläge definieren – aber diese Granularität bietet Copilot Stand jetzt nicht. Soziale Risiken: Manche Mitarbeiter könnten sich zu sehr auf Copilot verlassen und irgendwann ohne Prüfung versenden, was zu peinlichen Fehlern führen kann. Hier hilft nur Change Management (Training, Kultur des „KI ist Helfer, nicht Ersatz“). Datenschutz/Governance: Falls E-Mails Betriebs- oder Personalräte involvieren (z. B. interne Personalfragen per Mail), kann der Einsatz von KI auf Widerstände stoßen. Eine enge Einbindung des Betriebsrats vor Einführung ist ratsam, um Bedenken auszuräumen. Gemäß EU AI Act könnte man argumentieren, dass generative KI hier informationsgestützt aber unter menschlicher Endkontrolle arbeitet – wahrscheinlich keine Hochrisiko-KI, aber Transparenzgebot: Externe Empfänger sollten ggf. erfahren, dass Teile der Antwort KI-generiert sind (aktuell nicht verpflichtend, aber ein ethischer Aspekt).

Einführung & Change Management: Diese Funktion sollte – trotz aller Begeisterung – vorsichtig eingeführt werden. Empfehlung: Erst Pilot mit freiwilligen Teilnehmern (z. B. Support-Team, das viele Standardmails schreibt). Hier Feedback sammeln: Wie gut sind die Vorschläge, welche Fehler passieren, wo sind Lücken? Danach in Wellen an weitere Abteilungen ausrollen, vielleicht beginnend mit denen, die klaren Nutzen haben (Kundenservice, Vertrieb). Kommunikation & Schulung: Ein Launch sollte Hand in Hand gehen mit Schulungen zum richtigen Umgang: Also z. B. interne Workshops „Besser antworten mit Copilot – aber richtig!“ anbieten. Darin live zeigen, wie man einen KI-Entwurf verifiziert, Fakten checkt etc. Toolseitig kann man Überwachungsmechanismen einziehen: Etwa Qualitätskontrollen in ersten Wochen – Teamleiter könnten stichprobenartig KI-gestützte Antworten gegenlesen. Akzeptanz fördern: Erklären, dass Copilot Vorschläge macht, aber niemand gezwungen ist, sie zu nutzen. Ermuntern, auch mal „Nein, passt nicht“ zu sagen – denn Microsoft verbessert das System mit Feedback-Buttons in Outlook (Daumen hoch/runter). KPIs: Relevant ist die Zeitersparnis. Man könnte z. B. tracken, wie viele Antworten Copilot generiert und wie viele davon tatsächlich versendet wurden – ein Quotenwert >50% wäre Erfolg. Auch kann eine Mitarbeiterumfrage nach 3 Monaten quantifizieren, ob die E-Mail-Bearbeitungszeit spürbar sank. Eine besondere Change-Management-Maßnahme ist zudem, Erfolgsgeschichten zu teilen: Falls ein Team durch Copilot 30% mehr Mails schafft, das intern als Story publizieren.

Checkliste Umsetzung:
– [ ] Betriebsrat eingebunden: Falls erforderlich, wurde der Einsatz von KI zur Mail-Analyse mit dem Personalrat abgestimmt und schriftlich festgehalten (inkl. Zweck, Nicht-Überwachung von Mitarbeitern etc.).
– [ ] AV-Vertrag geprüft: Die Vereinbarung zur Auftragsverarbeitung mit Microsoft deckt Copilot ab; Datenschutz hat bewertet, ob zusätzliche Klauseln oder DSFA nötig sind (Ergebnis dokumentiert).
– [ ] Admin-Setup: Copilot proaktives Draft-Feature in Tenant-Einstellungen aktiviert (Standard war an, aber überprüfen). Ggf. Selected User-Pilot eingerichtet (über Berechtigungsfilter, falls Microsoft das ermöglicht hat).
– [ ] Pilotfeedback ausgewertet: Testnutzer haben Entwürfe bewertet, typische Fehlertypen identifiziert. Diese Erkenntnisse flossen in Schulungsmaterial ein (z. B. „Check facts from system Y bei Terminangaben“).
– [ ] Schulung/Guidelines verteilt: Alle User haben einen Leitfaden erhalten („Dos & Don’ts bei Copilot-Antworten“). Schulungen (Live oder eLearning) sind durchgeführt oder terminiert, mit Praxisübungen.
– [ ] Monitoring eingerichtet: IT hat Monitoring, z. B. über OWA-Protokolle oder Copilot-Dashboard, um bei ungewöhnlichem Verhalten Alarm zu schlagen (z. B. Massenversand ungewöhnlicher Antworten).
– [ ] Support gewappnet: Helpdesk-FAQs umfassen nun auch Copilot-typische Fragen (z. B. „Warum schlägt Copilot keine Antwort vor?“ -> Mögliche Gründe: vertrauliche Mail, Sprache nicht erkannt, etc.).
– [ ] Phasenweiser Rollout: Rollout-Plan in Wellen erstellt, jede Welle mit Feedback-Phase und Option zum Halten, falls Probleme auftauchen (z. B. Welle 1: Customer Support, nach 2 Wochen Lessons Learned, dann Welle 2: Vertrieb, usw.).
– [ ] Nutzer-Feedbackkanal aktiv: Es gibt einen einfachen Weg für Anwender, Feedback zu geben (z. B. dedizierter Teams-Kanal „Copilot E-Mail Feedback“) – und dieses wird aktiv ausgewertet.

Quellen/Referenzen: Microsoft 365 Roadmap ID 497671 – “Outlook: Copilot Proactive Drafts”, Stand: Sep 2025[2]; Microsoft TechCommunity – Outlook Blog, 30.09.2025 (Einführung Copilot in Outlook angekündigt, inkl. Drafts).

Teams Premium – Bildschirmaufnahme-Schutz in Meetings

Kurzbeschreibung: Microsoft Teams erhält im Rahmen des Teams Premium-Add-ons eine neue Sicherheitsfunktion: den Bildschirmaufnahme-Schutz. Damit können Organisatoren von Besprechungen verhindern, dass Teilnehmer Bildschirmfotos (Screenshots) oder Bildschirmaufzeichnungen vom Meeting-Inhalt anfertigen[3]. Microsoft adressiert damit ein häufiges Compliance-Problem – bislang konnten Benutzer z. B. via Snipping Tool oder Handy-Kamera jedes Meeting-Material abfotografieren. Die neue Option blockiert dies plattformübergreifend: In unterstützten Teams-Clients (Windows, Mac, Web, mobile Apps) wird bei aktivierter Einstellung versucht, Screenshot-Hotkeys und Aufnahmefunktionen zu deaktivieren; zudem erkennt Teams, wenn z. B. auf Mobilgeräten ein Screenshot erstellt wird, und blendet den vertraulichen Inhalt aus (ähnlich wie bei DRM-geschütztem Video). Diese Funktion ist seit Mitte Oktober 2025 allgemein verfügbar (Rollout abgeschlossen) und erfordert die Teams Premium Lizenz pro Veranstalter.

Warum es wichtig ist: Gerade in sensiblen Meetings (Vorstand, F&E, Personalgespräche) war es bisher quasi unmöglich sicherzustellen, dass niemand unerlaubt Inhalte mitfotografiert. „Prevent screen capture“ erhöht den Schutz von Geschäftsgeheimnissen enorm, da es die Datenabflussschnittstelle Mensch-Kamera einschränkt. Es trägt somit zur Compliance (z. B. Wahrung von Geheimhaltungsverpflichtungen) und zum Vertrauen zwischen Meeting-Teilnehmern bei – insbesondere in bereichsübergreifenden oder externen Besprechungen. Für regulierte Branchen (Gesundheitsdaten, Finanzzahlen) erfüllt dieses Feature auch Empfehlungen von Aufsichtsbehörden, die Kontrollmaßnahmen gegen unerlaubte Aufnahmen fordern. Aus IT-Security-Sicht rundet es die End-to-End-Verschlüsselung und Information Protection in Teams ab: Bisher war der Schwachpunkt Endgerät – jemand konnte immer abfilmen – nun wird zumindest die Hürde erhöht. Wichtig zu betonen: 100% verhindert es Leaks nicht (eine externe Kamera auf dem Bildschirm könnte immer noch filmen), aber der spontane Screenshot ist unterbunden. Für die Nutzer kann es anfänglich verwirrend sein („Warum geht mein Screenshot nicht?“), daher ist begleitende Kommunikation nötig. Dennoch dürfte der Mehrwert die Nutzerakzeptanz erhöhen, da vertrauliche Infos unbesorgter geteilt werden können.

Technische Details: Der Meeting-Organisator (Host) kann beim Planen einer Besprechung oder während eines laufenden Meetings in den Meeting-Optionen den Schalter „Prevent screen capture“ aktivieren (sofern Teams Premium in seinem Tenant aktiv ist). Wird dies aktiviert, setzen im Hintergrund mehrere Mechanismen ein: Auf Windows 10/11 und macOS nutzt Teams OS-APIs bzw. eigene Overlays, um Screenshot-Befehle abzufangen. Versucht ein Teilnehmer z. B. die Druck-Taste oder Snipping Tool, blockiert Teams die Anzeige des geschützten Inhalts (schwarzer Bildschirm oder Blur). In der Teams-Mobile-App (iOS, Android) wird ein System-Event ausgelöst, das das Betriebssystem anweist, Screenshots zu verhindern – auf iOS führt das dazu, dass kein Screenshot gespeichert wird; auf Android eventuell, dass der Screenshot komplett schwarz wird. Bei Versuchen, Screen Recording Tools zu nutzen, erkennt Teams dies ähnlich wie Digital Rights Management (DRM) und unterbindet die Aufnahme (bzw. das Aufzeichnungs-Output enthält nur einen leeren bzw. geschwärzten Frame). Wichtig: Diese Funktion erfordert aktuelle Teams-Clients – alte Versionen könnten ggf. noch Screenshots zulassen, aber Microsoft hat via Update die gängigen Clients kompatibel gemacht (auch Teams Rooms wird unterstützt, dort eher irrelevant). Es gibt keine Aufzeichnung davon, wer versucht hat zu fotografieren – es ist eine präventive Sperre, keine Protokollierung. Limitierung: Im Webclient ist es schwieriger, Shots zu verhindern, da Browser teils eigene Funktionen haben; Microsoft Edge mit DLP kann zusammenwirken (Edge for Business könnte Screenshot in Web verhindern). Integration: Diese Einstellung kann auch via Meeting Policies tenantweit forciert werden (z. B. kann Admin definieren, dass standardmäßig alle Meetings screenshot-geschützt sind oder nur bestimmte Usergruppen das Feature nutzen dürfen). Teams-Premium-Lizenz muss mindestens der Organisator haben; Teilnehmer ohne Premium können aber teilnehmen und die Einschränkung gilt trotzdem für sie.

Architektur/Governance: Aus Governance-Sicht ist das Feature weitgehend positiv: Es reduziert Risiken, ohne dass komplexe Prozesse nötig sind. Allerdings bedarf es klarer interner Richtlinien, wann diese Schutzmaßnahme eingesetzt wird. Beispielsweise könnte man in einer Meeting-Richtlinie festhalten: „Bei Besprechungen mit Vertraulichkeitsstufe Hoch ist der Screenshot-Schutz verpflichtend zu aktivieren.“ Die Verantwortung dafür liegt beim Organisator – hier sollten Schulungen und Erinnerungstexte (z. B. Templates im Outlook-Meeting, die dran erinnern) helfen. Berechtigungen: Alle Premium-lizensierten Benutzer können es nutzen; es sollte verhindert werden, dass jemand ohne Bedarf es überall einschaltet (Balance zwischen Sicherheit und Nutzererfahrung: permanent „no screenshots“ könnte Kulturprobleme geben). Evtl. kann das Compliance-Team Guidelines erstellen, wann nicht einzusetzen (z. B. in firmenweiten Info-Meetings, wo wir sogar wollen, dass Screenshots gemacht und verteilt werden – da wäre es kontraproduktiv). Datenfluss: Hier fließen keine zusätzlichen Daten ab – im Gegenteil, es verhindert Abfluss. Eventuell relevant: Die Info, dass Meeting X screenshot-geschützt war, taucht in Audit-Logs auf (ja, in Meeting Join Logs wird Option mitgeloggt). Falls ein Teilnehmer remote aufs Meeting zugreift (z. B. per Web) und versucht, trotzdem Bild zu machen – streng technisch kann es das Meeting nicht verlassen. EU-Compliance: Wahrscheinlich ist dieses Feature im Kontext EU DSGVO unkritisch, es verarbeitet ja keine persönlichen Daten neu, sondern schützt eher. Aber es könnte Arbeitsrechtlich relevant sein: Wenn etwa Betriebsrat meint, Mitarbeiter würden bevormundet, keine Screenshots machen zu dürfen – allerdings ist es primär zum Schutz des Unternehmens. BSI: Das Bundesamt empfiehlt in C5 sinnvolle restriktive Mechanismen zum Infosphären-Schutz – das passt hierzu.

Anwendungsbeispiel (konkret): Szenario: Vorstandssitzung mit streng vertraulichen Finanzzahlen.
– Vor dem Meeting aktiviert die Vorstandsassistentin beim Erstellen des Teams-Termins die Option „Keine Bildschirmaufnahmen zulassen“.
– Das Meeting findet statt, CFO präsentiert Quartalszahlen via Bildschirmfreigabe in Teams. Am Rand sehen alle Teilnehmer ein kleines Schloss-Symbol (hypothetisch), das anzeigt „Screenshot-Schutz aktiv“.
– Ein neuer Teilnehmer, dem das unbekannt ist, versucht per Windows-Tastenkombination Druck einen Screenshot zu machen.
– Auf seinem PC passiert nichts – oder das Snipping Tool zeigt nur ein schwarzes Rechteck. Der Teilnehmer wundert sich kurz, sieht dann in der Meeting-Chat-Leiste eventuell einen Hinweis „Screenshots sind für dieses Meeting deaktiviert“.
– Damit ist die Sache erledigt – die vertrauliche Folie wurde nicht erfasst.
– Nach dem Meeting will der Vorstandsvorsitzende die Folien an einen Kollegen mailen, der nicht dabei war. Da erinnert ihn Copilot oder der Assistent: es gilt NDA, aber nun außerhalb des Meeting-Rahmens darf er natürlich die Daten teilen (Screenshot-Schutz gilt nur im Meeting live).

(Dieses Beispiel zeigt zugleich eine Lücke: Außerhalb des Meeting-Kontexts könnte man ja trotzdem an Inhalte gelangen, aber zumindest während der Präsentation war es sicher.)

Auswirkungen auf Lizenzen & Kosten: Lizenzbedarf: Teams Premium (Aufpreis ca. 10 USD pro Nutzer/Monat) ist erforderlich – allerdings nur für den Meeting-Organisator. Teilnehmer benötigen keine Premium-Lizenz, um „mitgeschützt“ zu sein. Das heißt, eine Organisation könnte mit relativ wenigen Premium-Lizenzen auskommen, wenn nur bestimmte Leute streng vertrauliche Meetings hosten. Dennoch ist das Pricing so gedacht, Premium pro Kopf in Führungsetagen o. ä. zu kaufen. Add-On vs. Plan: Teams Premium ist ein Add-On auf E3/E5; E5 benötigt es trotzdem extra, d.h. auch E5-Kunden müssen für diese Funktion extra zahlen (da es nicht in E5 inkludiert ist). Kosten-Nutzen: In Vergleich zu möglichen Schäden durch Informationsabfluss (Stichwort Insider-Trading bei Finanzleaks) sind die Lizenzkosten gering – aber es muss intern argumentiert werden. Evtl. kann man es als Teil eines Security-Pakets rechnen: Teams Premium bietet ja auch andere Vorteile (Meeting-Intelligence, Watermarking, etc.), sodass der Einkauf es eher genehmigt, wenn mehrere Use Cases vorliegen. Insofern kann der Einkauf/Lizenzmanagement diese Funktion zum Anlass nehmen, Teams Premium evaluiert einzuführen (falls noch nicht geschehen).

Risiken & Gegenmaßnahmen: Scheinsicherheit: Ein Restrisiko bleibt – ein Teilnehmer könnte einfach sein Smartphone nehmen und den Bildschirm abfotografieren. Die Funktion verhindert digitale Aufnahmen, aber nicht analoge. Das Unternehmen sollte also dennoch vertrauliche Meetings auf möglichst wenige Teilnehmer beschränken und denen vertrauen. Gegenmaßnahme: Klare NDAs und Sensibilisierung, dass Abfotografieren ebenfalls verboten ist (notfalls Meeting-Policy „keine Handyfotos“). Ein weiteres Risiko ist Kompatibilität: Wenn Teilnehmer veraltete Teams-Clients nutzen oder per Teams-Web in einem exotischen Browser teilnehmen, greift der Schutz u.U. nicht zuverlässig. Admins sollten daher fordern, dass interne Clients aktuell sind (via Endpoint Management erzwingen) und Externe möglichst die Desktop-App nehmen. Usability: Eventuell sorgt die Funktion für Supportfälle: „Mein Screenshot-Tool geht nicht mehr“ – worauf Support erklären muss, dass es am Meeting-Schutz liegt. Transparente In-Meeting-Benachrichtigungen sollen das minimieren, aber in gemischten Umgebungen kann es zu Missverständnissen kommen. Außerdem: Wenn jemand legitimerweise doch einen Screenshot braucht (z. B. um intern weiterzuarbeiten), wird er frustriert sein, dass es nicht geht. Hierfür kann man „offizielle Workarounds“ definieren (z. B. Organisator kann nachträglich die Folien zur Verfügung stellen oder kurz den Schutz ausschalten für einen bestimmten Abschnitt – sollte aber protokolliert werden). Technische Probleme: Kaum gemeldet, aber denkbar: Performance-Einbußen, wenn diese Funktion aktiv ist (z. B. auf älteren PCs etwas Overhead). Bisher gab es keine solche Berichte, doch Admins könnten testweise die Systemlast prüfen.

Einführung & Change Management: Vorbereitung: Wenn Teams Premium bisher nicht lizenziert war, zunächst Business Case erstellen: Welche Meetings brauchen das wirklich? Oft im Top-Management – dort muss man zunächst Awareness schaffen (evtl. ein kleines Security-Briefing mit Demo: „Schauen Sie, so einfach war es bisher, Ihre Folie zu fotografieren, jetzt mit neuem Feature nicht mehr“). Die Zustimmung der „Sponsoren“ (z. B. CFO, CISO) erleichtert die Einführung. Rollout: Die Funktion kann global eingeschaltet werden, steht dann zur Verfügung. Aber man will ggf. nicht, dass jeder Meeting-Organiser wild rumprobiert. Daher bietet es sich an, erst mal einen Soft Launch zu machen: Kommunikation gezielt an definierte Nutzergruppen, z. B. alle, die eine Teams Premium Lizenz zugeteilt bekommen haben (Vorstände, Recht, F&E-Leiter etc.). In der Admin Policy kann man anfangs restriktiver sein (z. B. per Teams Meeting Policy festlegen, dass nur diese Gruppen die Option sehen). Später kann man es ausweiten, falls gewünscht. Training: Eigentlich selbsterklärend, aber ein knapper Guide „So aktivieren Sie Screenshot-Schutz“ plus FAQ („Was genau verhindert es, was nicht?“) ist sinnvoll. Kommunikation an alle Mitarbeiter: Wichtig ist, dass alle wissen, was das Schloss-Symbol bedeutet und dass Screenshots dann absichtlich blockiert sind – damit es nicht zu Fehlermeldungs-Irrtümern kommt. Ein kurzer Post im Intranet Newsfeed: „Neue Funktion: geschützte Teams-Meetings – gut zu wissen“ kann genügen, mit Infografik. Support: Helpdesk sollte vorbereitet sein, etwa auf Fragen von externen Gästen (die sich evtl. beim Host melden à la „ich kann nix screenshotten“). Hier sollten Meeting-Organisatoren vorab informiert werden, ihre Gäste darauf hinzuweisen, wenn solch Meeting läuft. Erfolgsmessung: KPIs können sein: Anzahl der Meetings mit aktiviertem Schutz (steigend?), und qualitative Metriken: Hat es Incidents gegeben (Leaks trotz Schutz vs. weniger Leaks). Falls Unternehmens-Whistleblowing vorher Screenshot-Leaks sah, nun vielleicht weniger. Man könnte auch Feedback der Nutzer einholen nach einigen Monaten, ob sie sich sicherer fühlen. Change bei Verhalten: Langfristig soll die Kultur etabliert werden, in wichtigen Meetings Routinemäßig den Schutz einzuschalten – das bedarf steter Erinnerung (z. B. Checkliste für Meeting-Moderatoren) bis es zur Gewohnheit wird.

Checkliste Umsetzung:
– [ ] Teams Premium lizenziert: Für definierte Benutzer (z. B. alle ab Abteilungsleiter-Ebene) wurde Teams Premium Add-on beschafft und im Tenant zugewiesen.
– [ ] Feature-Tests durchgeführt: In einer Testumgebung/mit IT-internen Meetings wurde „Prevent screen capture“ ausprobiert (verschiedene Geräte, auch Externe simuliert), um sicherzustellen, dass es wie erwartet greift.
– [ ] Meeting-Richtlinie aktualisiert: Offizielle Company-Policy zu Online-Meetings ergänzt um Abschnitt „Vertrauliche Meetings – Nutzung des Bildschirmaufnahme-Schutzes verpflichtend bei Schutzstufe X“ (inkl. Verantwortlichkeiten, z. B. wer entscheidet Schutzstufe).
– [ ] Admin-Einstellung geprüft: Default in Teams Meeting Policies so gesetzt, dass die Option verfügbar ist. Ggf. eigene Policy für Premium-User erstellt, um nur diesen die Option zu zeigen und für andere auszublenden (Konfliktvermeidung).
– [ ] Nutzerinfo Top-Manager: Spezielle Schulung/Briefing der leitenden Angestellten, die das Feature nutzen sollen – inkl. Demo in deren realen Meeting, Q&A (dadurch Buy-In geschaffen).
– [ ] Kommunikation allgemein: Interne News/Infomail versandt an alle Mitarbeiter über die neue Funktion. Inhalte: Warum, wie es funktioniert, was zu beachten (z. B. dass bewusst kein Screenshot geht – kein IT-Fehler).
– [ ] Dokumentation bereit: Kurzanleitung erstellt (evtl. mit Screenshots – hier paradox, aber man kann ja Meeting-Optionen fensterweise screenshotten), abgelegt im IT-Wissensportal.
– [ ] Support involviert: Helpdesk kennt die Schalterposition, kennt typische Fragen (Mobile: „Warum sehe ich nur schwarzen Screen beim Screenshot?“ -> Anwort parat).
– [ ] Externen-Hinweis vorbereitet: Vorlage-Text für Meeting-Einladungen mit Externen, der optional genutzt werden kann: „Dieses Meeting ist screenshot-geschützt, bitte sehen Sie von Aufnahmen ab…“.
– [ ] Kontrolle & Review: Nach dem Rollout Monitoring: Meeting-Logs auswerten, sind Probleme aufgetreten? Feedback der Premium-User gezielt einholen nach 1 Monat (Meeting organisieren: „wie läuft’s?“). Erfolge (z. B. „Chef war happy, dass nichts geleakt ist bei Meeting Y“) intern gegebenenfalls feiern/kommunizieren.

Quellen/Referenzen: Microsoft 365 Message Center – MC1140178: „Prevent screen capture in Microsoft Teams“, 05.10.2025[3]; Microsoft TechCommunity – Teams Blog, Beitrag vom 10.10.2025 (Feature-Ankündigung und FAQ).

Teams Premium – KI-gestützte Raum-Empfehlung

Kurzbeschreibung: Ebenfalls im Teams Premium-Paket erscheint die KI-gestützte Raum-Empfehlung für Meetings. Dieses Feature – auch Room Recommender genannt – nutzt künstliche Intelligenz, um in Teams-Meetings ohne gebuchten Konferenzraum automatisch passende Besprechungsräume vorzuschlagen[4]. Die Funktion greift etwa eine Stunde vor Beginn einer geplanten Besprechung, sofern festgestellt wird, dass (a) es sich um ein anstehendes Hybrid-Meeting handelt (mehrere Teilnehmer vor Ort in gleicher Location, aber kein Raum reserviert) und (b) mindestens zwei Teilnehmer in derselben Gebäudeumgebung sind. In solchen Fällen postet Teams in den Meeting-Chat einen Hinweis wie: „Es sind noch Räume frei – z. B. Berlin Raum A mit Platz für 5 Personen.“ Die Vorschläge basieren auf Kalender-/Outlook-Ressourcendaten (freie Räume) sowie Standorten der Teilnehmer (Büro-Standort aus Outlook-Profil oder Entra ID). Ziel ist es, spontane physische Zusammenkünfte zu fördern, wenn mehrere Leute eh vor Ort sind.

Warum es wichtig ist: In Zeiten hybrider Arbeit werden Büromeetings oft virtuell abgehalten, obwohl mehrere Beteiligte am selben Standort sind – schlicht weil kein Raum ad hoc organisiert wurde. Die KI-Raum-Empfehlung schafft hier Mehrwert für Produktivität und Zusammenarbeit: Persönliche Treffen können effizienter sein und Missverständnisse reduzieren. Das Feature sorgt dafür, dass Gelegenheiten zum Face-to-Face nicht verpasst werden – was auch der Unternehmenskultur zuträglich ist (mehr persönlicher Austausch). Für Facility Management ergibt es ebenfalls Sinn: Konferenzräume werden besser ausgelastet. Insbesondere mittlere Unternehmen oder Abteilungen mit knappen Raum-Ressourcen profitieren, wenn KI die Buchung proaktiv anstößt. Die Wahrscheinlichkeit, dass Teamkollegen sich spontan zusammenfinden, steigt. Außerdem beseitigt es einen typischen Reibungspunkt: bisher musste jemand daran denken „Lass uns doch einen Raum nehmen“, nun regt das System dies von selbst an. Natürlich hängt der Nutzen vom Vorhandensein freier Räume ab – aber wenn vorhanden, vermeidet es, dass Leute unnötig am eigenen Schreibtisch sitzen und in Laptops reden, obwohl nebenan ein Meetingraum leer steht. IT-Leitung sieht darin auch eine bessere ROI für Office-Infrastruktur. Die Endnutzer könnten es zunächst als „nannying“ empfinden („Teams sagt mir, ich soll in einen Raum gehen“), doch gut kommuniziert wird es eher als hilfreicher Tipp wahrgenommen. Letztlich fördert es den Hybrid-Work-Gedanken, optimal beide Welten (virtuell und Präsenz) zu verbinden.

Technische Details: Teams Premiums Room Recommender greift auf mehrere Datenquellen: 1) Outlook-Kalender (um festzustellen, ob dem Meeting eine Raumbuchung zugeordnet ist; wenn nein, potenzieller Kandidat), 2) Exchange Ressourcenpostfächer (um verfügbare Räume an Standorten und Zeiten zu ermitteln), 3) Entra ID/Outlook-Profilinfos (wo sind Benutzer geographisch verortet), 4) möglicherweise Tenant-Netzwerkinfo (Teams erkennt, wenn mehrere Teilnehmer unter gleicher IP/BSSID angemeldet sind, als Indikator für gleichen Standort – das ist spekulativ, aber plausibel). Etwa ~60 Minuten vor Meeting-Beginn läuft ein Dienst im Hintergrund: Er prüft, ob mindestens zwei Teilnehmer denselben Büro-Standort haben (z. B. beide in „München HQ, 3. Stock“) und kein Raum reserviert ist. Ist beides erfüllt, führt die KI eine Suche nach geeigneten Räumen im Gebäude durch: Kriterien sind freie Verfügbarkeit zur Meetingzeit, ausreichende Kapazität (≥ Anzahl dieser vor-Ort-Teilnehmer) und Nähe (ggf. gleiche Etage). Der am besten passende Raum wird ermittelt. Dann wird eine Nachricht im Meeting-Chat gepostet (mit einer kleinen Maps/Location-Angabe). Gleichzeitig erhalten die vor Ort befindlichen Teilnehmer evtl. eine Teams-Benachrichtigung. Akzeptiert jemand den Vorschlag (Button „Raum buchen“), so reserviert Teams im Hintergrund den Raum via Exchange (so als hätte man manuell den Raum dem Termin hinzugefügt). Alle Teilnehmer sehen dann im Termin, dass ein Raum hinzugefügt wurde. Falls niemand reagiert, passiert nichts weiter – es ist unverbindlich. Voraussetzungen: Das Unternehmen muss in Exchange/Outlook Locations und Räume ordentlich gepflegt haben (inkl. Raummailboxen mit Standortattributen). Außerdem müssen Benutzerprofile einen Büro-Standort enthalten (Attribut in Entra ID oder manuell im Teams-Client „Arbeitsort“ eingestellt). Grenzen: Bei Meetings mit sehr vielen Teilnehmern oder standortübergreifend wird wohl kein Vorschlag kommen (nicht relevant oder kein Raum groß genug). Externe Teilnehmer ignoriert es (fokussiert auf interne). Meeting muss im Kalender existieren – spontan Ad-hoc-Calls ohne Termin werden nicht abgedeckt. Tenant-Einstellungen: Administratoren können diese Funktion in den Teams Premium Policies an- oder abschalten (z. B. wenn es nicht gewünscht ist). Standard bei Premium: aktiv.

Architektur/Governance: Für diese KI gilt es Organisationsdaten aktuell zu halten – eine Governance-Aufgabe: Das Raumbuchungssystem (meist Exchange Resource Mailboxes) muss verlässlich sein, sonst schlägt KI evtl. Räume vor, die real nicht nutzbar sind. Also Governance: regelmäßige Pflege von Raumkalendern und -attributen (ggf. durch Facility). Auch Benutzerprofile: Hilfreich, wenn jeder seinen „primären Office-Standort“ korrekt eingetragen hat; HR/IT sollten Workday->Entra Sync nutzen, damit diese Daten stimmen. Policies: Wenn flexible Platzwahl (Desk-Sharing) herrscht, könnte KI Probleme haben (Standort im Profil != tatsächlicher Standort an Tag X). Hier überlegen: Zukünftig nutzen Leute vlt. Teams „Working hours & location“-Feature (gibt es für Outlook: man kann pro Tag angeben WFH oder Büro XY). Das würde KI noch präziser machen. Governance kann fördern, dass Mitarbeiter das pflegen. Datenschutz: Theoretisch fließen hier Standortdaten von Personen; das sollte transparent gemacht werden. Es ist aber alles im Rahmen interner Daten – keine externen Transfers außer dem Cloud-Service (der das verarbeitet). Zielgruppen: Eher ein Fachbereichsthema, Governance sollte mit den Teamleitern sprechen: Wollen wir das? Möglicherweise sind in manchen Kulturen spontane physische Treffen gar nicht gewünscht – aber meistens doch. Lizenz/Governance: Nur Premium-Lizenz org. -> ergo, nicht jeder Meeting-Organisator hat es. Aber die Intelligenz greift auch, wenn irgendein Premium-User in dem Meeting ist (Organisator muss m.W. Premium haben, sonst greift es nicht). Das heißt, wenn manche Abteilungen Premium nicht haben, kriegen sie diese Vorschläge nie – was okay ist. Governance kann steuern, wer Premium bekommt: vorrangig solche Teams, wo auch vor Ort gearbeitet wird (rein remote Mitarbeiter hätten davon nichts).

Anwendungsbeispiel: Szenario: Team Meeting, 4 Leute in der Zentrale, 2 im Homeoffice. Raum noch keiner gebucht.
– Teamleiter hat Teams Premium, stellt Termin „Weekly Sync“ ein, alle 6 eingeladen, kein Raum.
– Am Meeting-Tag sind zufällig 3 der 4 lokalen Leute im selben Büro. Eine Stunde vor Termin: Teams KI erkennt, 3 Personen „Berlin Office“ Status anwesend.
– Im Meeting-Chat (schon vor Meeting-Beginn verfügbar in Teams) erscheint Nachricht: „Es sind mehrere Teilnehmer im Berlin-Büro. Vorschlag: Buchen Sie einen Besprechungsraum. Freie Räume: Raum Aquarius (EG, 6 Personen) verfügbar um 14:00.“


– Teamleiter sieht das Pop-up auch als Banner. Klickt auf „Buchen“.
– Automatisch wird „Raum Aquarius“ dem Termin hinzugefügt und in Outlook geblockt. Der Chat meldet: „Raum Aquarius wurde reserviert.“
– Kurz darauf bekommen die 3 Berlin-Teilnehmer eine Teams-Benachrichtigung auf dem Handy: „Ihr Meeting Weekly Sync findet in Raum Aquarius statt“. In ihrem Kalender steht nun Ort drin.
– Um 14:00 treffen sich die 3 dort, die 2 Remoten wählen sich normal per Teams ein. Meeting läuft hybrid.
– Alle freuen sich über die spontane persönliche Zusammenkunft, KI hat sinnvoll unterstützt.

Auswirkungen auf Lizenzen & Kosten: Lizenztechnisch Teams Premium (Add-on) nötig – entscheidend ist, ob Organisator Premium hat. Falls nein, keine Empfehlungen. Das Unternehmen muss abwägen, wie viele Premium-Lizenzen dafür sinnvoll sind (evtl. lohnt es sich nur bei bestimmten Häufigkeiten). Wenn man Teams Premium ohnehin aus anderen Gründen hat (z. B. Intelligente Zusammenfassungen, Webinar-Funktionen), ist dies ein nettes Add-on im Add-on. Keine direkten Kosten außer der Lizenz. Indirekt: Wenn Meetingräume öfter genutzt werden, können vllt. die Bewirtungskosten steigen 😉 – aber im Ernst, Facility-Budget kaum beeinflusst. Möglicher Spareffekt: Effizientere Raumnutzung könnte mittelfristig bedeuten, man braucht weniger Gesamtmeetingfläche. Das Feature an sich verursacht keine Azure-Mehrkosten im Tenant.

Risiken & Gegenmaßnahmen: Falsche Vorschläge: KI könnte mal einen ungeeigneten Raum vorschlagen (zu klein, anderer Flügel, …) oder übersehen, dass Meeting vertraulich ist (vielleicht wollten die Leute gar keinen Raum wegen Remote). Gegenmaßnahme: Es ist ja nur ein Vorschlag, menschliche Akzeptanz nötig. Im schlimmsten Fall bucht einer unreflektiert Raum und es passt nicht, dann kann mans ja stornieren. Verfügbarkeitsprobleme: Was wenn KI immer denselben Raum vorschlägt und der dann ein Engpass wird? Eher geringes Problem, da sie Verfügbarkeit checkt. Privacy-Bedenken der Mitarbeiter: Manche könnten ungern ihren Standort tracken lassen (z. B. „Chef merkt, ich bin im Büro, also Raumvorschlag kommt…“). Hier Transparenz: Teams schaut nur auf selbe Location, kein feingranulares Tracking. Und man kann ja im Profil notfalls falschen Standort eingeben, wenn man’s boykottieren will (aber intern vielleicht thematisieren). Edge-Case: Wenn das Meeting gar kein physisches sein sollte (z. B. Diskretion – 3 Leute im Büro, aber wollen separat sitzen weil vertraulich), könnte Vorschlag unpassend sein. Falls so was gemeldet wird: Der Organisator kann Feature ignorieren, oder Admin kann es für bestimmte Meetings (Sensitivität) deaktivieren. Später könnte MS Kopplung mit Sensitivity Labels machen, wer weiß. Kulturell: Es besteht minimales Risiko, dass remote Teilnehmer sich „ausgeschlossen“ fühlen, wenn sich die anderen spontan zusammensetzen. Unternehmen sollten dennoch hybrides Mindset wahren (also z. B. die im Raum müssen weiter Kamera nutzen etc.).

Einführung & Change Management: Verglichen mit anderen KI-Features ist dies recht unkompliziert. Voraussetzung: Stammdaten-Check. Vor Ausrollen: Sicherstellen, dass Gebäude- und Raumdaten in Exchange korrekt sind (hier lohnt Einbeziehung Facility/Workplace-Management). Pilot kann man mit einer Abteilung machen, die Premium hat, und deren Offices gut ausgestattet sind, um zu schauen, ob es greift. Kommunikation: Bei Rollout an Premium-User: „Teams hilft Euch künftig, einen Raum zu finden, wenn Ihr eh im Büro seid.“ Gern mit Screenshot der Chat-Empfehlung, damit klar ist, wie es aussieht. Org Change: Evtl. mit HR oder internen Kommunikationsabteilung abstimmen, denn es tangiert Workstyle. Aber wahrscheinlich positive Resonanz („cool, Teams denkt mit“). Schulung: Braucht kaum – vielleicht 1-2 Sätze in den Teams-Premium-Schulungsunterlagen. Eher muss man Facility Manager informieren, damit sie sich nicht wundern, falls Buchungen „automatisch“ reinkommen. Aber im Kalender wird ja der Organisator eingetragen sein als Buchender. Nachjustieren: Nach Launch kann man auswerten, wie oft vorgeschlagen vs. gebucht. Das Exchange-Raum-Postfach liefert Log, wer bucht – wenn „via Teams KI“ irgendwie markiert, könnte man tracken. Wenn es nicht oft genutzt wird, nachfragen, warum. Evtl. Problem: Leute pflegen Arbeitsort nicht – dann HR pushen, das in Self-Service Portal updaten zu lassen. Überzeugung: Es hilft, Success Story zu kommunizieren, z. B. „Dank neuem Teams-Feature diese Woche 5 spontane Live-Meetings ermöglicht – Statement von Mitarbeiter: ‚war super, mal wieder in echt zu sprechen‘.“. So fühlen sich auch andere motiviert, ins Büro zu kommen, weil sie wissen, dass spontane Meetingräume kein Problem sind.

Checkliste Umsetzung:
– [ ] Datenqualität geprüft: Alle Konferenzräume sind in Exchange als Ressource angelegt, mit Standort/TAG (Gebäude, Kapazität) gepflegt. Mitarbeiterprofil-Standorte aktualisiert (am besten Abgleich mit HR-Daten oder Abfrage via Azure AD).
– [ ] Teams Premium verteilt: Entsprechende Lizenzen an definierte Pilotgruppe/Abteilungen zugewiesen.
– [ ] Funktion in Policies aktiviert: In Teams Admin Center (Premium-Features) kontrolliert, dass „Room suggestion“ aktiv ist. Gegebenenfalls testweise nur Pilot-User Policy = on, rest = off.
– [ ] Pilotfeedback eingeholt: Nach ein paar Wochen Pilot hat IT mit Pilot-Usern gesprochen – hat es Vorschläge gemacht? Wurden diese angenommen? Falls nein, warum? (Erkenntnis daraus fürs Rollout).
– [ ] Kommunikation an Benutzer: Hinweis im Intranet oder per Mail an Premium-User („Teams hilft Euch Räume zu finden. Achtet auf Chat-Vorschlag vor Meetings.“) – idealerweise inkl. Screenshot eines Beispiel-Vorschlags.
– [ ] FAQ erstellt: In interner Knowledge Base z. B. Frage „Wie weiß Teams, wo ich bin?“ => Antwort: nutzt Profil und Kalender, kein Live-Tracking. Oder: „Was tun, wenn vorgeschlagener Raum nicht passt?“ => Antwort: ignorieren oder manuell anderen Raum buchen.
– [ ] Einbindung Facility: Office Management informiert, dass ggf. neue Buchungen reinkommen. Klären, wer bei Raum-Konflikten reagiert (z. B. zwei Teams greifen denselben großen Raum), wobei Exchange das eigentlich verhindert.
– [ ] Feedback-Kanal: Möglichkeit eingerichtet, dass Nutzer positives/negatives Feedback zum Feature geben (z. B. via Forms oder Teams-Chat an IT). Damit man justieren kann (vielleicht Standorte anpassen etc.).
– [ ] Erfolgsmessung definiert: KPIs z. B.: Anzahl automatischer Raum-Buchungen pro Monat, Auslastung der Räume erhöht? (Abgleich vor/nach), evtl. Umfrage: „Fühlen Sie sich besser vernetzt im Büro seit dem Feature?“.
– [ ] Rollout an restliche (falls stufenweise): Falls Pilot erfolgreich, Teams Premium ggf. auf weitere relevant Büroteams ausgeweitet. Kommunikation entsprechend wiederholt/upgedatet für neue User.

Quellen/Referenzen: Microsoft 365 Roadmap ID 482191 – “Teams: Room Recommender for Meetings”, Ankündigung Q4 2025[4]; Microsoft Message Center – MC1128754, 18.10.2025 (Preview Info Teams Premium Raumvorschläge).

OneDrive/SharePoint – „Hero Link“ (ein Link für alle Berechtigungen)

Kurzbeschreibung: Microsoft führt mit dem sogenannten Hero Link ein neues Freigabemodell in OneDrive und SharePoint Online ein, das die Art und Weise der Dateifreigabe fundamental vereinfacht. Bisher konnten beim Teilen von Dateien mehrere verschiedene Freigabelinks generiert werden (jeder mit eigenen Berechtigungen – Personen, unternehmensweit, anonym etc.). Mit Hero Link wird jede Datei über genau einen zentralen Link identifiziert, der alle Freigaben steuert[5]. Dieser Hero-Link fungiert als „Held“ im Hintergrund – egal, ob man „Kopie des Links senden“ klickt, in Teams eine Datei teilt oder die URL aus dem Browser kopiert: Es ist immer derselbe Link, nur mit unterschiedlichem Kontext. Nutzer müssen nicht mehr mit verschiedenen Link-Versionen jonglieren. Ändert man die Zugriffsberechtigung am Hero Link (z. B. von intern zu nur bestimmte Personen), gilt das einheitlich für alle. Diese dritte Generation des Sharing-Modells wurde im Mai 2025 angekündigt und rollt laut Microsoft Roadmap Ende 2025 aus[13]. Es handelt sich um eine umfangreiche Umstellung im Hintergrund, die aber für Endanwender vor allem spürbare Erleichterung bringt und für Admins deutliche Sicherheitsvorteile (weniger unkontrollierte Links) bedeutet.

Warum es wichtig ist: Die Verwaltung von Freigaben war in SharePoint/OneDrive immer wieder Quelle von Verwirrung und Sicherheitsrisiken. Benutzer erstellten teils mehrere Links für dieselbe Datei (z. B. einen fürs Team, einen für extern) und verloren den Überblick. Das führte zu Oversharing, da alte Links oft gültig blieben oder vergessen wurden. Hero Link löst dieses Problem: Ein Link pro Datei = single source of truth für Berechtigungen. Das macht das Teilen einfacher und transparenter – was auch die Benutzerakzeptanz steigert (weniger frustrierende „Zugriff verweigert“ Szenarien, weil man weiß, Link = Datei und Berechtigungen sind klar regelbar). Aus Security/Compliance-Sicht ist es ein Gewinn: Administratoren können nun zentral alle geteilten Links je Datei managen, anstatt verstreute IDs zu suchen. DLP und eDiscovery profitieren ebenso (einfacheres Tracking, da heroische ID). Zudem werden Anwender ermächtigt, eigenständig den Link-Zugriff zu aktualisieren, z. B. nachträglich den Kreis einzuschränken, wenn sie merken, er war zu weit offen[17]. Das schließt eine große Lücke in der Data Governance – bislang war es oft „Link einmal raus = fast unmöglich einzufangen“, jetzt kann man bestehenden Link einfach restriktiver machen. Für DSGVO relevant: Weniger anonyme Links, da Standard auf interne Personen geht[18], was unkontrollierte Exfiltration erschwert. Letztlich entspricht Hero Link einem Branchenbenchmark, den Nutzer von Google Drive oder Box eventuell erwarten – Microsoft zieht hier nach und übertrifft mit dem einheitlichen Modell sogar, da historisch gewachsene Komplexität abgebaut wird. Für IT-Admins reduziert sich auch Supportaufwand (weniger „Ich habe Link A geschickt aber Empfänger hat Link B und geht nicht“-Tickets). Insgesamt also eine Verbesserung in Usability und Sicherheit gleichermaßen.

Technische Details: Hero Link ersetzt das bisherige Konzept der separaten Share-Links (View/Edit etc.). Technisch erhält jede Datei beim Upload eine unveränderliche „Hero-ID“ (eine URL). Diese wird intern mit einer Zugriffsliste verknüpft. Wenn ein Nutzer nun auf „Link kopieren“ klickt, generiert OneDrive keinen neuen Link, sondern gibt immer den Hero-Link zurück (ggf. mit bestimmten Parametern, aber die ID bleibt gleich). Im Manage Access-Paneel sieht man künftig nicht mehr x unterschiedliche Links, sondern genau einen, und darunter Einstellungen wie: Wer hat Zugriff: direkt hinzugefügte Personen/Gruppe und optional eine Scope-Einstellung (z. B. „Alle in Organisation mit Link“). Wenn man früher einen separaten Link für „Alle intern“ erstellen konnte, wird das nun abgebildet durch das Hero-Link mit dem Scope „Organisation“. Ändert man diesen auf z. B. „Nur bestimmte Personen“, wandelt das System den bisherigen universellen Zugriff entsprechend um – Leute, die per Hero-Link zugriffen, aber nicht benannt sind, verlieren Zugriff, und man kann gezielt Personen hinzufügen. Copilot-Integration: Interessant, Microsoft betont auch Copilot + Sharing: Der Hero Link erlaubt es Copilot, Inhalte besser zusammenzufassen und gleich den relevanten Link mitzuschicken[19]. Default-Verhalten: Standardmäßig startet jeder neue Hero-Link sehr restriktiv – nämlich nur für bereits explizit berechtigte Personen[18]. D.h. wenn man eine Datei neu erstellt, kann zunächst nur man selbst zugreifen (und Mitbesitzer in Bibliothek). Teilt man dann, muss man definieren, wer dran darf; Hero-Link wird übergeben, aber wenn Empfänger noch keinen Zugriff hatte, kommt Meldung, er muss angefragt werden oder Absender muss Link-Einstellungen erweitern – hier bietet UI gleich Option „Zugriff für Contoso intern erlauben?“ etc. Admins können diese Standardfreigaberichtlinie aber anpassen (z. B. wie bisher auf „Org-weit“ setzen). Auswirkungen auf existierende Links: Microsoft hat Migrationsmechanismen – existierende klassische Links bleiben gültig, aber sie werden intern auf die Hero-ID gemappt, sodass sie nach und nach im System vereinheitlicht werden. Für die Übergangsphase wird es einen Dualmodus geben: alter Manage Access zeigt alten Links, neuer Manage Access (Preview) zeigt nur Hero. Wichtig: Kein Link hört abrupt auf zu funktionieren, aber Admins sollten Altlasten bereinigen. Rollout-Mechanik: Der Rollout begann als opt-in Preview (z. B. per PowerShell Set-SPOTenant -EnableHeroLink Preview), dann allgemeines Release. Zunächst Tenant opt-out möglich, aber Plan ist, bis Ende 2025 global umzustellen[13]. Limits: Named links kann man weiterhin mehrere anlegen? Hier unterscheidet Microsoft: Man kann zusätzliche Freigabelinks (z. B. für andere Zwecke) erzeugen, aber diese sind dann benannte Hero-Links mit Label – quasi Sub-Links mit Zweck, aber intern gleiches System[20]. Also theoretisch mehrere parallele, aber man kann sie z. B. benennen „Link für Vertriebspartner“ etc., aber sie steuern alle die selbe Datei. Das ist etwas fortgeschrittener Use-Case; normaluser wird das nicht brauchen. Adminsteuerung: In SharePoint Admin Center kann man global definieren, ob externe Links erlaubt, ob anonyme Links generiert werden können (auch mit Hero noch möglich, aber Admin muss erlauben). Im Hero-Modell kann man aber anonyme Linkso mehr managen, z. B. verfallsautomatisch etc., zentral.

Architektur/Governance: Governance-Änderungen: Unternehmen sollten ihre Freigaberichtlinien überprüfen und ggf. anpassen. Beispiel: Bisher war es Nutzern vielleicht verboten, anonyme Links zu verwenden; mit Hero Link ist Standard ohnedies intern, aber Admin sollte sicherstellen, dass „Anonymer Zugriff“ global aus bleibt, wenn Richtlinie es so vorsieht. Weiters: Schulungsmaterial zu Datenklassifizierung (welche Daten dürfen extern geteilt) muss evtl. aktualisiert werden, um das neue Modell abzubilden (z. B. statt „erstellen Sie einen Besucherlink“ nun „fügen Sie externen Gast dem Hero-Link hinzu“). Rollen & Berechtigungen: Es ändert sich an den SharePoint-Berechtigungsrollen nichts, aber Admins haben nun zentrales Monitoring pro Datei. Datenlebenszyklus: Ein Held-Link gilt Datei-Lebensdauer – sollte die Datei umbenannt oder verschoben werden, Link bleibt (war bisher auch so). Governance kann das positiv nutzen: Man kann persistent auf Dokumente verlinken. Compliance-Funktionen: DLP, Sensitivity Labels – gut: es muss nichts Neues konfiguriert werden, existierende Mechanismen (wie „Block extern teilen, wenn vertraulich“) funktionieren mit Hero genau so, aber administrativer check vllt. mit neuem Flow. Audit & eDiscovery: Alle Zugriffe laufen über eine ID, was Logging erleichtert. Zukünftig kann man sagen: „Zeig alle externen Zugriffe auf Datei X“ – einfacher, da ein Identifier. Änderung für Nutzer: Das UI „Manage Access“ wird sich ändern; Governance/Adoption Team sollte informieren, damit es keine Verwirrung gibt. BSI-Empfehlungen: Deutsche Behörden (BSI etc.) verlangen oft Minimierung von Freigabelinks; Hero erfüllt dies voll (1 Link = minimal).

Anwendungsbeispiel: Szenario: Mitarbeiterin möchte große Datei mit Team und externem Kunden teilen.
– Früherer Ablauf: Sie hätte evtl. internen Link erzeugt fürs Team und separaten Gastlink für den Kunden. Das ergab 2 URLs, schwer zu managen.
– Neuer Ablauf mit Hero: Sie lädt die Datei in Teams (SharePoint) hoch. Anfangs hat nur Team Zugriff.
– Sie klickt „Teilen“ und gibt E-Mail des Kunden an, setzt Häkchen „darf nur lesen“.
– Hero Link wird generiert und dem Kunden per Outlook eingeladen (als „X hat Datei mit Ihnen geteilt“). Gleichzeitig kann ihr Team denselben Link nutzen (die Teamkollegen haben ja ohnehin Zugriff via Site-Berechtigung).
– Einige Tage später stellt sie fest, dass doch nur ein Teil des Kunden die Datei sehen sollte, nicht alle ursprünglich eingeladenen. Sie öffnet Manage Access, entfernt die externe Gruppe und fügt stattdessen nur 2 Kundenpersonen hinzu. Hero Link bleibt gleich, aber wenn jetzt jemand anders mit altem Mail-Link versucht, kommt Zugriffsverweigerung. Die neu benannten 2 Externe können jedoch weiterhin mit dem selben Link zugreifen.
– Nach Projektende entscheidet sie, externen Zugriff komplett zu entziehen. Statt jeden Link einzeln ungültig zu machen (früherer Prozess: beide externen Links widerrufen), ändert sie im Manage Access den Hero Link Scope auf „Nur Personen mit bestehendem Zugriff“ (sprich nur noch intern). Zack, alle externen verlieren Zugang. Ein einziger Klick sozusagen.
– Ihr Vorgesetzter fragt: „Hast du sichergestellt, dass keine offenen Links mehr draußen sind?“ Sie prüft Access – sieht ja nur noch interne Einträge, kann beruhigt nicken.

Auswirkungen auf Lizenzen & Kosten: Die Hero Link-Funktion ist eine grundlegende Plattformänderung, keine lizenzpflichtige Zusatzoption. Sie steht allen Kunden mit OneDrive/SharePoint (unabhängig ob Business Basic, E3, E5 etc.) zur Verfügung. Es gibt keine Kosten. Indirekt könnte ein minimaler Performance/Storage-Overhead anfallen (die heroische Berechtigungsstruktur braucht sicher ein paar Bytes pro Datei extra, vernachlässigbar). Auch im Azure AD B2B Kontext: Evtl. werden mehr externe als Guest user eingeladen, statt anonyme Links – das könnte bedeuten, dass man (falls bisher vermieden) mehr Gastkonten verwalten muss. Das hat leichte Lizenzimplikationen (Externe kosten nichts, außer >50k dann ggf. bezahlen – aber meist irrelevant). Summiert: Keine Kosten, aber mehr wert. Insofern kein Thema für Einkauf außer, dass man möglicherweise eine kleine Schulungsausgabe einplant (Zeitbudget um Nutzer upzudaten).

Risiken & Gegenmaßnahmen: Change-Risiko: Nutzer sind an bisherigen Share-Dialog gewohnt. Der neue Hero-Dialog könnte anfangs Verwirrung stiften („Wo ist Option ‚Jeder mit Link‘?“ – diese gibt es nur, wenn Admin erlaubt, und dann heißt es anders). Hier helfen Tooltips und Kommunikation. Microsoft hat sicherlich UI/UX drauf ausgelegt, dass es selbsterklärend ist. Übergangsphase: Es besteht Risiko, dass vorhandene Freigaben durcheinander geraten – aber MS hat versichert, Alt-Links bleiben valide, also kaum Impact. Dennoch sollte IT anfangs bei Supportfragen gewappnet sein (z. B. „Mein alter Link geht nicht mehr“ – überprüfen, ob Heldumstellung). Sicherheitsrisiko: Wenngleich Hero primär Sicherheit steigert, könnte es in manchen Situationen erlauben, dass ein Link breiter gestreut wird, als man will (z. B. jemand leitet intern erhaltenen Hero Link an Extern weiter – hat aber keinen Effekt, da Extern nicht berechtigt, außer Org-scope Link). Also nein, eher sicherer. Edge Cases: Mit Hero Link kann man mehrere vergebene Zugänge schwerer unterscheiden – z. B. man kann nicht mehr zwei separate anonyme Links mit verschiedenen Ablaufdaten parallel haben. Aber diese Komplexität war eh problematisch. Falls jemand solche Workarounds brauchte, muss er nun den Weg über Named additional links gehen (die Option dafür bietet Hero, aber etwas versteckt). Technisch: Falls Third-Party Apps auf das alte Linkmodell angewiesen waren (z. B. Drittsysteme, die OneDrive-Sharing via Graph so nutzten), müssen die angepasst werden. Graph-API hat sicher Updates, aber Altskripte evtl. überarbeiten – Admin sollte prüfen.

Einführung & Change Management: Microsoft rollt Hero Link global aus – Admins können es wohl nicht dauerhaft verhindern (nur opt-out Phase bis GA). Daher sollte man proaktiv intern kommunizieren: “Neues vereinfachtes Teilen – so funktioniert’s.”, lieber selbst die Narrative gestalten (Vorteile hervorheben), als dass Nutzer sich wundern. Die IT könnte z. B. Ende Q3/2025 ein internes Webinar „Neues aus M365“ veranstalten, Hero Link als Top-Topic. Schulungsbedarf: Moderat, aber alle User betrifft es. Daher vielleicht kleine In-App Hinweise oder E-Mail an alle: „Ab Datum X ändert sich Linksharing. Keine Sorge, bestehende Freigaben bleiben – neu nur noch 1 Link pro Datei. Für Sie wird’s einfacher! Hier Details…“. Microsoft könnte auch in der App ein Walkthrough einblenden (das machen sie oft). IT-Service: Helpdesk sollte upgedatet sein, alte Knowledge-Artikel (z. B. „Wie erstelle ich externen Link“) neu schreiben nach neuem Modell. Aufräumen nutzen: Vielleicht benutzt man die Gelegenheit, mit Security-Team einen Audit zu machen und alte ungenutzte Anonym-Links zu entfernen – quasi Frühjahrsputz. Hero Link kann dann neu starten mit minimal extern offen. Erfolgsmessung: Evtl. Metrik: Anzahl anonymer Links vorher/nachher (sollte sinken), Supporttickets zu Sharing vorher/nachher (sollte sinken). Governance adhoc: Manche Abteilungen hatten Workarounds um Linksharing (z. B. sie versenden keine Links, sondern Anlagen, weil unsicher waren). Nach Einführung versuchen, diese ans neue Modell heranzuführen (weniger Angst, da besser kontrollierbar).

Checkliste Umsetzung:
– [ ] Tenant-Setting geprüft: Falls Microsoft phasenweise Rollout ermöglicht (Targeted Release?), hat man es entweder aktiviert zum Test oder opt-out bis final. Entscheidungen dokumentiert.
– [ ] Tests mit Pilot-Usern: Einige Nutzer im „Targeted Release“-Ring probieren Hero Link UI aus – Feedback (ist es selbsterklärend? wo haken?); IT testet insbesondere externe Freigabe-Szenarien mit neuem Modell.
– [ ] Dokumentation aktualisiert: Interne Hilfeartikel zum Datei teilen entsprechend neu formuliert. Möglicherweise separate Info für externe Partner (z. B. „So greifen Sie nun auf geteilte Contoso-Dokumente zu“ – aber vermutlich für Externe ändert sich weniger).
– [ ] Kommunikationsplan: Vor dem Rollout ein „Coming Soon“ Teaser (Ankündigung), beim Rollout eine detailliertere Info (Mail vom CIO, Blog im Intranet etc.), danach Erinnerung im Team-Meeting (Teamleads bitten, kurz im Teammeeting darauf hinzuweisen – mit Provided Folie).
– [ ] Schulung: E-Learning Module oder Video (2 Minuten) erstellt, das neuen Teilen-Dialog zeigt. Optional Q&A-Session via Teams anbieten paar Tage nach Launch für Fragen.
– [ ] Security-Review alt vs neu: Admin/Security Team nutzt Berichte (SharePoint admin -> Links report) um altes Link-Vorkommen zu checken. Gleich Aktion: abgelaufene oder riskante Links entfernen (kann man per PowerShell). So geht man bereinigt in die neue Ära.
– [ ] Policies angepasst: Interne Policies, z. B. „Externe Freigaben erlauben nur via Named accounts“ – nun deckt sich das mit Standard. Falls bisher anonyme Links bei sensiblen Daten blockiert, config in Purview DLP/Labelling geprüft, ob mit neuem Modell kompatibel (Label block share – ja geht).
– [ ] Monitoring: Nach Einführung genau auf Nutzerfeedback achten – ggf. Survey 1 Monat später: „Zurechtgekommen mit neuem Teilen? Braucht Ihr mehr Info?“; Supporttickets auswerten (vielleicht initial ansteigend wegen Neuerung, soll dann runter).
– [ ] Third Party Apps: Prüfen, ob Custom Scripts oder Anwendungen das Teilen-API nutzen. Wenn ja, Developer informiert, Graph-API Anpassungen implementiert.
– [ ] Erfolg feiern: Wenn spürbar besser (z. B. Abnahme Access Requests weil Leute Links selbst fixen können), das ruhig intern kommunizieren – zeigt digitale Kompetenzfortschritt.

Quellen/Referenzen: Microsoft TechCommunity – “Simple, Smart, and Secure: The next step in sharing files in M365”, Miceile Barrett, 07.05.2025[5][13]; Microsoft 365 Roadmap ID 492622 (Hero Link Rollout Q4 2025).

SharePoint Premium – Automatisierte Dokumentenverarbeitung (Syntex)

Kurzbeschreibung: SharePoint Premium ist Microsofts nächste Generation einer intelligenten Content-Management-Plattform und umfasst umfangreiche KI-gestützte Dokumentenverarbeitungs-Funktionen, die vormals unter dem Namen Microsoft Syntex bekannt waren[6]. In Q4 2025 erreicht SharePoint Premium den produktiven Einsatz (Public Preview seit Ignite 2023) und bringt eine Palette von Automatisierungen mit sich: automatisches Klassifizieren von Dokumenten (z. B. Vertragsarten erkennen), Extrahieren von Metadaten (z. B. Vertragsnummer, Betrag aus PDF auslesen)[21], Steuerung von Inhalten (z. B. automatische Zuordnung von Sensitivity Labels oder Retention an erkannte Inhalte), Content Assembly (dynamisches Generieren von Dokumenten aus Vorlagen)[22] sowie integrierte elektronische Signatur-Prozesse. All dies geschieht direkt innerhalb von SharePoint Libraries, angetrieben durch vorgefertigte KI-Modelle oder anlernbare Modelle. Die Idee: Routinearbeiten im Umgang mit großen Dokumentenmengen radikal zu vereinfachen und gleichzeitig Inhalte so aufzubereiten, dass Tools wie M365 Copilot darauf besser zugreifen können[6]. SharePoint Premium positioniert sich damit als „KI-Schicht“ über der Informationsverwaltung – ein großer Unterschied zur klassischen SharePoint Nutzung, die meist manuell war.

Warum es wichtig ist: Viele Unternehmen – insbesondere in regulierten Branchen (Banken, Versicherungen, öffentliche Verwaltung) – hantieren täglich mit riesigen Mengen an Dokumenten: Verträge, Anträge, Formulare, Rechnungen. Diese manuell zu kategorisieren, erfassen und zu verwalten ist fehleranfällig, langsam und teuer. Automatisierte Dokumentenverarbeitung löst dieses Problem, indem KI diese Inhalte versteht und verarbeitet. Das bedeutet konkret: Produktivitätsschub, da Mitarbeiter weniger Zeit mit Abtippen von Daten oder Suchen nach Dokumenten verbringen. Compliance-Vorteil: Dokumente werden konsistenter verschlagwortet und klassifiziert, wodurch z. B. Datenschutz-relevante Inhalte (Personendaten) identifizierbar sind und richtig geschützt werden. Auch die DSGVO-Auskunftspflichten lassen sich einfacher erfüllen, wenn KI schon Dokumenttypen erkennt (z. B. alle „Datenauskunftsanfragen“ taggt). Ein weiterer Aspekt ist Copilot-Readiness: Copilot kann nur so gut Antworten geben, wie die Inhalte strukturiert sind. SharePoint Premium sorgt dafür, dass Inhalte mit Metadaten und Taxonomie angereichert sind – Copilot kann dann leichter und präziser darauf zugreifen (Microsoft wirbt explizit damit, dass Premium die Basis für „content ready for Copilot“ legt[6]). Für IT-Leiter und Compliance-Verantwortliche ist das attraktiv, weil es die Governance verbessert: Weniger Wildwuchs in Dokumentbibliotheken, stattdessen geordnete, findbare Informationen. Natürlich kommen auch Herausforderungen: Das Anlernen der KI-Modelle erfordert Know-how, und man muss ihre Trefferquote überwachen (um Fehlzuordnungen zu vermeiden). Dennoch – der Trend geht klar dahin, Routine zu automatisieren, und SharePoint Premium bringt das out-of-the-box, ohne Drittanbieter.

Technische Details: SharePoint Premium umfasst mehrere Dienste: Unstructured Document Processing (für Freitext-Dokumente wie Verträge), Structured Document Processing (für Formulare/Rechnungen mit fixen Feldern) und Prebuilt Models (fertige KI-Modelle etwa für Rechnungen, Personalausweise etc.)[23][24]. Diese Modelle laufen auf Azure AI und sind eng mit SharePoint verknüpft. Setup: Admins können im SharePoint Admin Center SharePoint Premium aktivieren (erfordert hinterlegtes Azure-Abonnement für Pay-as-you-go). Dann können in Dokumentbibliotheken Syntex Content Center Features genutzt werden: z. B. Train Classifier – man lädt 5–10 Beispielverträge hoch, labelt sie als „Vertrag“, Modell lernt Muster. Anschließend kann man definieren: Wenn künftig neues Dokument als Vertrag erkannt => extrahiere Felder (Vertragsdatum, Partner etc.) => schreibe diese in Spalten und setze Sensitivity Label „Vertraulich“. Diese Regeln konfiguriert man im Browser, KI übernimmt im Hintergrund. Content Assembly: erlaubt Erstellung von Vorlagen (via Word Template mit Platzhaltern), die von KI oder via Formular gefüllt werden – z. B. Standardangebot generieren. eSignature: SharePoint Premium integriert mit Adobe Sign oder Docusign – man kann Flows definieren, z. B. „Wenn Dokument genehmigt, starte Signaturprozess“. Tenant-weite Einstellungen: SharePoint Premium setzt sich aus bisherigen Komponenten zusammen, z. B. SharePoint Advanced Management (SAM) war ein Teil – das enthält auch Workflows, Zugriffspolicys etc. All das wandert unter Premium-Schirm[25]. Admin kann global steuern, wer KI-Modelle erstellen darf (z. B. nur Power User). Limits: Jedes KI-Feature hat Kapazitätsgrenzen (z. B. 300 Seiten pro Monat kostenlos im Trial, dann kostenpflichtig). Performance: KI-Extraktion dauert je nach Länge ein paar Sekunden pro Dokument, geschieht asynchron (nach Upload wird im Hintergrund analysiert). Ggf. taucht Hinweis „Processing“ in Spalte auf. Architektur: Die KI-Dienste laufen Cloud-basiert (Azure). Daten aus Dokumenten werden temporär in KI-Service geladen zur Analyse – laut MS bleibt alles in tenant region (bei Prebuilt Models teils global, aber EU Region aus DPA Sicht). Bekannte Limits: Handschrifterkennung (OCR) ist enthalten, aber bei sehr schlechter Scanqualität Limitierungen. Außerdem muss man Modelle gut trainieren, sonst Unsicherheit.

Architektur/Governance: Die Einführung von SP Premium erfordert Governance-Vorbereitung: Zunächst Inhaltsanalyse: Welche Dokumenttypen haben wir? Welche davon lohnen sich für KI-Modell? Das Governance-Team sollte zusammen mit Fachbereichen Prioritäten setzen (z. B. „Rechnungseingang automatisieren“ zuerst, dann „Verträge klassifizieren“ etc.). Datenschutz/Compliance müssen involviert sein: SharePoint Premium kann Daten extrahieren – z. B. persönliche Daten – diese werden dann in SharePoint-Spalten gespeichert. Das ist gut (strukturierter), aber man sollte z. B. Labeling/Retention darauf anwenden. Rollen & Rechte: Nicht jeder darf KI-Modelle publizieren – empfehlenswert ist, pro Fachbereich Content AI Champions zu benennen, die Modelle trainieren. Man kann in Content Center Site Berechtigungen vergeben (Syntex uses a special Content Center site for managing models). Lifecycle & Monitoring: KI-Modelle müssen gepflegt werden (retrained wenn Dokumentvorlagen ändern; Monitoring der Accuracy – es gibt Model metrics). Governance Board sollte regelmäßige Überprüfung definieren: z. B. vierteljährlich Evaluation „Modell X Treffgenauigkeit 95%, ok“ vs. „Modell Y 60%, nachbessern“. BSI/EU AI Act: Interessant, diese KI ist nicht generativ, sondern klassifizierend – also niedrigere Risikostufe. Dennoch unter EU AI Act je nach Einsatz (Vertragsprüfung, personal relevant) evtl. Transparency required. Muss im KI-Inventar geführt werden. Aus DSGVO-Sicht: es ist automatische Verarbeitung – für vollautomatisierte Entscheidungen wäre menschlicher Review nötig, aber hier werden ja nur Metadaten vorgeschlagen, Entscheidungen (z. B. genehmigen) treffen weiterhin Menschen. Trotzdem in Datenschutz-Folgenabschätzung erwähnen. Datenfluss: Administratoren sollten klären, in welchen Rechenzentren die KI-Auswertung passiert. Microsoft sagt EU Databoundary by 2023/24 – vermutlich ab Q4 2025 die Syntex-KI auch in EU-Region. Governance kann festlegen: Keine sensiblen Dokumente in Premium verarbeiten, bis das bestätigt ist, falls Bedenken. Lizenz & Governance: Payment-Modell (siehe unten) – Governance muss budgetieren, weil jede Seitenverarbeitung Geld kosten kann.

Anwendungsbeispiel (konkret, realitätsnah in Schritten): Szenario: Automatisiertes Vertragsmanagement mit SP Premium
1. Vorbereitung: Der Legal-Bereich identifiziert, dass Arbeitsverträge einheitlich ausgewertet werden sollen (Mitarbeitername, Eintrittsdatum, Position aus jedem Vertrag extrahieren).
2. Modellerstellung: Ein Rechtsassistent (Power-User mit Syntex-Berechtigung) sammelt 20 beispielhafte Arbeitsvertrag-PDFs, lädt sie ins Content Center. Er markiert pro Dokument die relevanten Elemente (Name, Datum, Position), sodass das KI-Modell lernt, wo im Text diese typischerweise stehen.
3. Nach dem Training testet er mit 5 neuen Verträgen, ob die KI die Felder korrekt zieht – feinjustiert ggf. mit sog. Regex oder weiteren Samples.
4. Deployment: Er veröffentlicht das Modell auf die „Arbeitsverträge“-Bibliothek der Legal-Teamsite. Zudem definiert er Extraktionsfelder, die in SharePoint-Spalten „Name“, „Eintrittsdatum“, „Position“ gespeichert werden sollen, und eine Aktion: Wenn Position = „Senior Management“, setze Sensitivity Label „Vertraulich“.
5. Produktiv: Künftig laden HR-Mitarbeiter unterschriebene Arbeitsverträge dort hoch. Sobald ein PDF erscheint, greift SharePoint Premium: Das Dokument wird als „Arbeitsvertrag“ klassifiziert, die Felder werden extrahiert und als Spaltenwerte angezeigt. HR sieht also gleich in der Listenansicht Name, Datum etc., ohne in die PDF schauen zu müssen.
6. Findet die KI mal nichts (z. B. neuer Vertragstyp), markiert sie das Dokument zur Überprüfung nötig. Ein Legal-MA kann dann manuell nachschulen (über UI klicken: falsch erkannt -> neu zuordnen).
7. Nutzung der Ergebnisse: Die extrahierten Daten können via Power Automate weiterverwendet werden (z. B. Flow: wenn Eintritsdatum extrahiert -> generiere Termin „Onboarding“ im Kalender). Oder Copilot kann gefragt werden: „Zeig mir alle Verträge, die im Januar beginnen“ – dank Spalte Eintritsdatum trivial beantwortbar.
8. KI-Kosten: Pro Vertrag fallen ca. 2 „Unstructured pages“ an, monatlich z. B. 50 Verträge = 100 Seiten. Da Premium 100 frei/Monat hat[21], bleibt es im Free-Kontingent – kein Azure-Billing.

Auswirkungen auf Lizenzen & Kosten: Microsoft hat SharePoint Premium als Add-On auf Verbrauchsbasis konzipiert (Pay-as-you-go). Anders als fixe Lizenzen wird pro verarbeiteter Seite oder pro Nutzung gezahlt – es gibt jedoch Kontingente kostenlos pro Monat im Promotionzeitraum bis Ende 2025[26][27]. Laut Angebot erhält jeder Tenant monatlich bspw.: 100 Seiten unstrukturierte Verarbeitung, 100 Seiten strukturierte, 100 Prebuilt, 50 content assembly Dokumente, 50 taxonomy Taggings, 2500 OCR-Seiten, 1 Mio. Übersetzungszeichen, 5 eSign-Vorgänge[28][29]. Diese reichen oft für Pilotzwecke. Ab 2026 (nach Promotion) wird es nach Überschreiten zu Azure Metering kommen – Preisliste ca. 1 USD pro 1000 Seiten o. ä., Details in MS Doku. Organisationen sollten somit mittelfristig ein Budget fürs Dokumenten-AI einplanen. Vorteil: Pay-per-use ist granular; Nachteil: schwerer planbar als fixe Lizenz. Wer z. B. 100k Rechnungen im Monat hat, könnte spürbare Cloudkosten haben – aber dann müsste man abwägen, was man an manueller Arbeit einspart (ROI). Copilot-Lizenzierung tangiert: Eigentlich unabhängig, aber Premium-Funktionenen setzen mindestens E3 plus E5-Compliance oder Syntex-Lizenz voraus, die nun in Premium aufgehen. E5-User haben Stand Ende 2025 keinen Sondervorteil – Premium ist extra. Es gibt aber Rabatte in Promotion (bis Dez 2025 ist Gratisfreikontingent da)[30]. Der IT-Einkauf muss also ab 2026 entscheiden, ob man Pay-as-you-go weiterführt oder ggf. Staffelpakete (MS könnte feste Pakete bringen). Kurz: bis Ende 2025 kostenlos testen, ab 2026 Ausgabenmonitor in Azure nutzen.

Risiken & Gegenmaßnahmen: Fehlerkennung & Haftung: Wenn KI z. B. einen Vertrag falsch klassifiziert, könnte das Folgen haben (vielleicht wird ein Critical Document als unwichtig eingestuft). Daher ist menschliche Validierung und iterative Verbesserung Pflicht. Gegenmaßnahme: Beginnen mit gering kritischen Anwendungsfällen, Schwellenwerte definieren (Modell macht 100% confident = auto, sonst review). Akzeptanzrisiko Fachbereiche: Manche könnten KI misstrauen („Erkennt die wirklich alles? Muss ich kontrollieren, also doppelte Arbeit?“). Hier Change mgmt: Pilot und Proof-of-concept mit händischer Vergleichsmessung, um Vertrauen aufzubauen (z. B. KI 95% korrekt, weit besser als manuell 80%). Datenschutzrisiko: KI extrahiert auch persönliche Daten – zwar intern, aber Admins sollten sicherstellen, dass extrahierte Felder ggf. DSGVO-konform behandelt (z. B. Löschfristen – einfach, da man in Purview nun Spalten gezielt retention geben kann). Zudem: Falls Prebuilt-Modell Personalausweis nutzt – wohin sendet es? Muss in AV-Vertrag klar abgedeckt sein. Info an Betroffene (Mitarbeiter): „Eure Dokumente verarbeitet KI, aber unter interner Kontrolle“ – Transparenz. Technisch: KI-Modelle können heavy load erzeugen, aber MS skaliert in Cloud gut. Einzig, wenn tausende Dokumente auf einmal uploaded (Migration etc.), kann es Queue geben, verzögert – Manage expectations. Kostenrisiko: Pay-go könnte unbemerkt Kosten erzeugen – initial Promo gratis, dann vlt. Rechungshock. Daher unbedingt Monitoring in Azure Cost Management, Budgets/Alerts einrichten („wenn >100 USD im Monat, Alarm“). Gegenmaßnahme: Modell-Einschränkung, z. B. nur auf neue Doks anwenden, nicht retrospektiv alle Altakten (außer man will bewusst). Vendor Lock-in: Einmal auf MS-KI trainiert, alternative Lösungen? Aber man kann Modelle exportieren bedingt – trotzdem Lock-in ist gegeben.

Einführung & Change Management: Pilotprojekt: Klar definieren, welcher Anwendungsfall zuerst – ideal: hoher Mehrwert, überschaubare Komplexität. Z. B. Rechnungseingang verarbeiten – dank Prebuilt rechnung Modell schneller Erfolge. Interdisziplinäres Team (IT, Fachbereich, Compliance) aufsetzen, Erfolgskriterien definieren (z. B. „80% automatische Verarbeitung in 3 Monaten“). Management-Buy-In: Führung muss verstehen, dass etwas menschliche Vorarbeit (Modelltraining) nötig, bevor Effizienzgewinn kommt. Budget für Pilot einplanen (Zeit Fachbereich!). Skill-Aufbau: Mitarbeiter (z. B. DMS-Spezialisten oder Power Platform Champions) trainieren in Syntex (MS Learn Module, evtl. Partner-Unterstützung). Change mgmt Enduser: Für Endanwender ändert sich Bibliotheksansicht (kommen Spalten, KI markiert was). Erklären, wieso z. B. „Vertragsnummer (KI)“-Feld da ist und wie es zu nutzen (Fehler melden, etc.). Eventuell Kickoff-Workshops mit den betroffenen Teams. IT-Betrieb: Definieren, wer KI-Modelle verwaltet (kann IT sein oder Fach mit IT-Support). Monitoring-Rollen klären. Success Metriken kommunizieren: Früh die Quick Wins teilen – z. B. „KI hat 200 Stunden Tipparbeit in Monat 1 gespart“. Stufenweise Ausrollen: Nach einem Use Case, nächster etc. Aber Achtung vor Feature-Überfrachtung: Lieber modulweise (erst Klassifikation, dann auch eSignature einführen, etc.), damit Teams nicht überfordert. Änderung in Prozessen: Dokumentationsprozesse evtl. anpassen – z. B. neu definieren „Eingehende Rechnung muss nicht mehr manuell im ERP erfasst, KI tut es, Mensch nur noch validieren.“ Das bedarf offiziellem Process Change mit Freigabe. Langfristig: Change mgmt muss auch Wartung der Modelle institutionalisiseren (z. B. wer passt Modell an, wenn Rechungsformular ändert; nicht vergessen!).

Checkliste Umsetzung:
– [ ] Use Case identifiziert & priorisiert: Fachbereich + IT haben konkreten Dokumenttyp gewählt, wo Automatisierung sinnvoll (inkl. Nutzenquantifizierung, z. B. ~500 Dokumente/Mo, bisher 10 Min pro Doc manuell = Potenzial 83h Einsparung/Mo).
– [ ] Stakeholder-Support: Führung im Fachbereich und CDO/CIO sind an Bord, haben Freigabe für Pilot (inkl. Data Governance Zustimmung, Budget PayGo Ok).
– [ ] Azure Setup erledigt: Azure Subscription mit Syntex-PayGo verknüpft (Promo-Kontingent läuft, Billing getestet an kleinem Job, um Flow zu checken).
– [ ] Rechte & Umgebung eingerichtet: Content Center Site erstellt (oder vorhandene genutzt), Berechtigungen gesetzt (Modellersteller, Reviewer Gruppen definiert).
– [ ] Mitarbeiter geschult: Mind. 2-3 Personen pro gewähltem Use Case durchlaufen Syntex Training (z. B. MS Learn „Automate Content understanding“ Module). Evtl. PoC mit Microsoft/Partner begleitet.
– [ ] KI-Modell trainiert & getestet: Modell(e) in Preview auf Testdaten entwickelt, Güte >= gewünschten Schwellwert. Testlauf mit echtem (nicht produktiv) Batch Doks, Ergebnis geprüft.
– [ ] Feedbackschleifen vorbereitet: Verfahren definiert, wie KI-Fehler gemeldet und korrigiert werden (z. B. in Bibliothek Spalte „Überprüfung nötig“, definierter Personenkreis schaut drauf; oder Power Automate benachrichtigt).
– [ ] Klassifikationsschema abgestimmt: Falls nötig, mit Compliance abgestimmt, welche Klassifizierungen KI macht (damit deckungsgleich zu Info Protection Scheme).
– [ ] Pilot Go-Live: Modell auf Produktiv-Bibliothek ausgerollt, Nutzer informiert (Mail oder Team-Meeting: „Ab jetzt unterstützt KI uns bei X. So seht Ihr das… Bitte gebt uns Feedback“).
– [ ] Monitoring & Kostenkontrolle: Azure Cost Alert konfiguriert für Syntex Meter (z. B. Warnung bei 80% Freikontingent). Modell-Performance Dashboard überprüft nach 2 Wochen (Accuracy etc.).
– [ ] Iterationen: Fehleranalyse durchgeführt, Modell nachtrainiert falls nötig. Fachanwender-Feedback eingeholt, Parameternachjustierung (z. B. Textfragmente hinzugefügt, Extraktionsfelder optimiert).
– [ ] Entscheidung Ausbau: Nach 1-2 Monaten Pilot KPIs ausgewertet (z. B. 70% Zeitersparnis erreicht, Ziel 80% in Reichweite). Dann Rollout auf breiter – entweder Feature auf weitere Teams/Biblio (wenn Use Case spartenübergreifend) oder nächster Use Case.
– [ ] Dokumentation & Governance: KI-Modell im Data Inventory aufgenommen (für AI Act), Prozessdokumente aktualisiert (z. B. SOP Rechnungsverarbeitung beinhaltet nun KI-Schritt). Fortlaufender Verantwortlicher benannt (Modell Owner).

Quellen/Referenzen: Microsoft Ignite 2023 Book of News – “Introducing SharePoint Premium – the future of AI powered content management”, Jeff Teper, 15.11.2023[25][6]; Microsoft TechCommunity Blog – “New promotional offer for SharePoint Premium”, 09.01.2024 (Update Jun 2025)[26][23].

Outlook (Neue Version) – Mehrere E-Mail-Signaturen

Kurzbeschreibung: Die neue Outlook für Windows App (auch „One Outlook“ genannt) erhält endlich wieder die Fähigkeit, mehrere E-Mail-Signaturen zu verwalten[7]. In der ersten Produktversion war dies schmerzlich entfernt worden – Benutzer konnten nur eine Signatur nutzen, was einen deutlichen Rückschritt zur Legacy-Outlook darstellte. Microsoft reagierte auf das Feedback und stellte im Microsoft 365 Roadmap Eintrag 384092 die Wieder-Einführung für Q4 2025 in Aussicht. Damit können Nutzer in der neuen Outlook-App wieder verschiedene Signaturen pro E-Mail-Konto oder Nutzungsszenario erstellen und beim Verfassen komfortabel auswählen. Zusätzlich soll ein stabileres Roaming der Signaturen über Geräte hinweg gewährleistet werden. Diese Funktion war offiziell angekündigt und Anfang Q4 2025 in Insider-Versionen sichtbar – die allgemeine Verfügbarkeit wird bis Jahresende 2025 erwartet (für alle Nutzer der neuen Outlook Version).

Warum es wichtig ist: Mehrere Signaturen sind ein wesentliches Produktivitätsmerkmal in der geschäftlichen E-Mail-Kommunikation. Viele Anwender benötigen z. B. eine interne kurze Signatur und eine formelle externe Signatur, oder unterschiedliche Signaturen je nach Rolle (etwa Berater mit verschiedenen Mandanten). Das Fehlen dieser Option in der neuen Outlook-App führte zu erheblichem Unmut und hinderte einige Firmen sogar daran, vom alten Outlook zu migrieren. Die Rückkehr dieser Funktion beseitigt also einen Adoptionsblocker für die neue Outlook-App. Zudem verbessert es die Benutzerzufriedenheit und Effizienz – man spart Workarounds wie Signatur-Templates manuell einfügen. Aus Unternehmenssicht trägt es zur Professionalität der E-Mail-Korrespondenz bei: Mitarbeiter können korrekte Signaturen je Kontext pflegen (inkl. rechtlicher Disclaimer extern vs. interne knappe Variante). Auch Marketing/CI profitieren: zentral vorgegebene Signaturen (via Outlook Signaturverwaltung oder Dritttools) lassen sich wieder vielfältig einsetzen. Insgesamt ist dies eher die Wiederherstellung gewohnten Komforts als eine Neuerfindung – aber genau deshalb so wichtig: Die Akzeptanz der neuen Outlook-Plattform hängt davon ab, dass solche Standardfunktionen vorhanden sind. In regulierten Umgebungen war es sogar ein Compliance-Thema: Fehlende Disclaimer extern wären problematisch. Daher erwarteten alle diese Nachbesserung mit hoher Dringlichkeit.

Technische Details: Die neue Outlook-App speichert Signaturen nicht mehr auf dem lokalen Gerät (wie das klassische Outlook mit Signaturen im AppData-Ordner), sondern in der Cloud (Outlook Roaming Signatures). Das heißt, alle erstellten Signaturen werden im Benutzerpostfach (vermutlich als versteckte Nachricht in mailbox) abgelegt und synchronisieren über Geräte hinweg. Bei der ursprünglichen Implementierung gab es Limits: nur eine Signatur pro Konto wurde unterstützt. Mit dem Update Q4 2025 wird die UI für Signaturen erweitert: Im Einstellungen-Menü unter E-Mail > Signaturen kann der Nutzer nun mehrere Signaturen anlegen (z. B. „Extern“, „Intern“, „Mobile“) analog zur Legacy-Outlook-Oberfläche. Er kann für jedes seiner E-Mail-Konten eine Standardsignatur für neue Nachrichten und eine für Antworten/Weiterleitungen festlegen, aus den erstellten Signaturen. Diese Zuweisung wird gespeichert. Beim Verfassen kann wie gewohnt über das Menüband bzw. die „…“ Menüoption zwischen den Signaturen gewechselt werden. Technisch speichert Outlook diese Infos in der Cloud-Einstellungen des Benutzers (wahrscheinlich in Exchange mailbox oder OWA-Einstellungen). Tenant Admin Einfluss: Administratoren konnten und können per Transport-Regeln oder externe Tools Signaturzusätze erzwingen, das bleibt unverändert. Die Outlook-Client-seitigen Signaturen sind primär User-Managed. Rollout: Microsoft hat dies zunächst in Beta-Channels der Outlook App ausgerollt (etwa ab Version 1.2025.xxx im Oktober). Ab November 2025 wird es per Office 365 Update auch im Current Channel produktiv verteilt. Bei Cloud-Apps passiert das auto, bei MSIX/Click-to-Run je nach Orchestrierung. Limits: Möglicherweise ist Zahl der Signaturen pro Konto (früher ~20) weiter ausreichend groß, keine nennenswerten Begrenzungen. Signaturen mit Bildern oder HTML werden unterstützt – war aber in Beta evtl. noch holprig. Migration: Falls ein User weiterhin parallel OWA (Outlook Web) nutzt: OWA unterstützt auch mehrere Signaturen seit 2023 – diese sollten eigentlich synchron sein mit Desktop. Ist noch unklar, aber zu erwarten, dass Cloud-basiert beides selbe Datentopf. Alte lokale Signaturen aus Legacy-Outlook werden beim ersten Setup der neuen App migriert (Beta hatte das nicht, GA soll das enthalten).

Architektur/Governance: Für die IT bedeutet dies: Der Migrationspfad zum neuen Outlook ist nun frei von diesem Hindernis. Governance-seitig sollte man planen, wann man Anwender endgültig auf das neue Outlook umstellt (Microsoft hat angekündigt, ab April 2026 automatische Migration, siehe Roadmap-Ausblick). Diese Signaturen-Funktion war eine oft erwähnte Voraussetzung in internen Projektplänen. Nun kann das Implementation-Team einen Haken dran machen und zügiger Pilot und Rollout des neuen Outlook vorantreiben. Policies: Falls das Unternehmen Tools für Signatur-Management einsetzt (z. B. CodeTwo, Exclaimer), muss geprüft werden, ob diese mit dem neuen Modell kompatibel sind. Viele dieser Tools fügten Signaturen via COM-Addin ein – im neuen Outlook funktionieren klassische COM-Addins nicht, man braucht ggf. ein Web-Addin. Governance muss sicherstellen, dass zentrale Signaturen weiter ausgerollt werden oder den Anwendern beigebracht wird, die neuen Möglichkeiten zu nutzen. IT-Support: Es sollte kommuniziert werden, dass „Signatur-Chaos“ nun behoben ist – viele Ticket bzgl. „ich habe nur eine Signatur“ werden entfallen. Compliance: In manchen Ländern sind Disclaimer vorgeschrieben; war bisher riskant, wenn nur eine Signatur = man wechselte nicht für extern. Jetzt kann man wieder regelkonform disclaimen. Das Compliance-Team kann nun Empfehlungen erneuern: „Bitte nutzen Sie bei externen E-Mails die Signatur XY mit vollem Disclaimer“. Governance könnte die Standardzuweisung entsprechend pushen (z. B. via GPO, aber hier Cloud, wohl schwer – eher kommunikationsgetrieben).

Anwendungsbeispiel: Szenario: Mitarbeiter hat zwei Rollen – Projekt A (mit externem Kundenkontakt) und interne Kommunikation.
– In neuem Outlook (nach Update) geht er in Einstellungen > Signaturen.
– Legt Signatur1 „Extern“ an mit Name, Titel, Firma, Tel, Rechtstext, Firmenlogo.
– Legt Signatur2 „Intern“ an – z. B. nur Vorname, Nachname, Abteilung.
– Weist seinem Firmenkonto (user@firma.de) die Standardsignatur „Extern“ für Neue Mails und „Intern“ für Antworten zu. Für sein privates Konto erstellt er separat was, falls gewünscht.
– Nun schreibt er eine neue Mail an Kundin – Outlook fügt automatisch „Extern“-Signatur an. Er sendet, alles gut.
– Auf interne Mail vom Kollegen antwortet er – hier fügt Outlook die „Intern“-Signatur ein (kein unnötiger Formalismus intern).
– Morgen arbeitet er am Laptop statt PC – Outlook (neue App) synchronisiert die Signaturen, so auch dort alles verfügbar.
– Ohne diese Option hätte er manuell Texte kopiert oder riskant nur mit falscher Signatur geantwortet (z. B. Kunde kriegt nur mgd. interne Signatur – unprofessionell). Jetzt läuft’s sauber.

Auswirkungen auf Lizenzen & Kosten: Keine direkten Lizenzkosten – neue Outlook App ist Bestandteil der bestehenden Microsoft 365 Pläne. Indirekt: Ein Hindernis weniger kann bedeuten, dass Organisationen früher den Wechsel forcieren – was wiederum Lizenzauswirkungen positiv haben kann (z. B. E3 zu E5 Upgrades um zukunftssicher Copilot etc. zu nutzen – aber das ist sehr indirekt). Kosten minimal: evtl. Schulungsaufwand / Ankündigung. Falls man Third-Party Signaturtools ablöst (viele Firmen investierten in Tools, weil roamende Multi-Signatures fehlte), kann man evtl. Lizenzkosten dort sparen, falls die Outlook-native Lösung nun ausreicht. Allerdings bieten diese Tools oft weitere Features (zentrales Branding, Kampagnenbanner etc.), die Outlook nativ nicht kann – vermutlich behält man sie.

Risiken & Gegenmaßnahmen: Verwirrung: Anwender, die sich über ein Jahr an „nur eine Signatur“ gewöhnt hatten (evtl. Kompromiss: lange externen und internen gemischt), müssen wieder umdenken – aber das ist eher positive Verwirrung. Trotzdem: Kleine Kommunikation notwendig, siehe unten. Technical glitch: Beta-Phasen zeigten, dass bei manchen Nutzern Signaturen verschwanden oder mehrfach dupliziert wurden – Migration bugs. IT sollte nach dem Rollout auf eventuelle Störungen achten: z. B. unbedingt neueste Version verteilen, notfalls Workaround haben („Signaturen neu anlegen, einmal logout/login“). Addin Konflikt: Externe Signatursoftware mit neuem Outlook kann initial durcheinanderkommen – Test mit dem Anbieter vor breitem Rollout. Policy mismatches: Falls Admins OWA-Policy definiert hatten (z. B. User darf nur eine Signatur?) – eigentlich nein, das gibts nicht – aber in Hybridumgebungen vielleicht. Ggfs. check Exchange Online Set-MailboxMessageConfiguration Parameter (gibt SaveSignaturesSwitch etc. – vielleicht uninteressant). User error: Mit mehreren Signaturen steigt auch chance, mal falsche zu verwenden (z. B. interne an extern aus Versehen). Das Risiko war gewollt in Kauf genommen vs. dem Zwang eine Signatur. Hier kann man gegensteuern durch Namenskonvention („Extern (enthält Kunden-Disclaimer)“) damit sie nicht versehentlich interne wählen.

Einführung & Change Management: Da dies primär eine Wiederherstellung ist, ist der Change-Prozess eher kommunikativ: Ankündigung im IT-Newsletter: „Gute Neuigkeiten – neue Outlook App jetzt mit Multi-Signature!“ – damit Nutzer, die es vermissten, informiert sind. Schulung: Nicht nötig, Standardfunktion, aber man kann 1-2 Screenshots in der Mail zeigen (wo in Settings). Pilot/Bewertungen: Falls Firma noch altes Outlook nutzt, könnte diese Änderung der Trigger sein, nun Pilot Migration anzugehen. Dann planen: z. B. Q4 2025 Pilotgruppe auf neue Outlook umstellen (evtl. per GPO den „Try new Outlook“ Hebel setzen), Monitoren ob Signaturproblem gelöst. Wechsel motivieren: Manche zögerten, jetzt argument: „jetzt sind Hindernisse weg, wechselt doch bitte“. Timeline: Laut Microsoft wird April 2026 altes Outlook zwangsweise migriert[31], also Q4 2025 idealer Zeit, proaktiv umzustellen. Support: Helpdesk soll auf häufige Fragen vorbereitet sein, z. B. „Wo sind meine alten Signaturen?“ -> Info über Cloud roam, notfalls Anleitung, wie aus altem Outlook exportieren. Policy intern: Evtl. neu definieren: „Bitte richten Sie mindestens 2 Signaturen ein – geschäftlich vs. intern“ als Best Practice. Könnte man in Styleguide aufnehmen.

Checkliste Umsetzung:
– [ ] Outlook-Client Version geplant: Sicherstellen, dass neue Outlook App in Organisation verfügbar (per Microsoft 365 Apps Update). Falls Channel-Wechsel nötig (Beta vs Current), entscheiden.
– [ ] Pilotgruppe M365-Insider: Einige freiwillige Nutzer mit Insider-Build haben Multi-Signaturen getestet, Feedback gesammelt (z. B. Migration alter Signaturen ok? Synchronisation mobiler Outlook? – letzteres: Mobil-Outlook hat separate Sig).
– [ ] Externe Signatur-Tools validiert: Wenn Exclaimer/CodeTwo im Einsatz, vom Anbieter Update einholen, ob Integration mit OneOutlook klappt. Test in Lab.
– [ ] Kommunikation an Nutzer: Info-Mail oder Intranet-Beitrag: „Outlook (neu) jetzt mit mehreren Signaturen – was heißt das?“ inkl. kurzer how-to. Besonders an jene adressieren, die schon neu nutzen (erkennen per Adoption Score oder so).
– [ ] Update Rollout: Rollout der Office-Updates in gesteuerter Weise (z. B. erst IT, dann Häppchen Wellen), damit bei Problemen stoppbar.
– [ ] Support Awareness: Helpdesk informiert über Neuerung; interne Wissensdatenbank upgedatet (Eintrag „Neue Outlook: Signaturen verwalten“ mit Schritten, falls Nutzer nachfragen).
– [ ] Migration Hilfen: Falls Anwender vom alten Outlook zum neuen wechseln, Guide bereit: Wie exportiere ich meine Signaturen aus alt und importiere in neu (theoretisch neu holt alt automatisch, aber falls schief: manuell).
– [ ] Interne Policy adaptieren: Falls es Vorgaben zur Signatur gab (Design etc.), diese checken, ob anwendbar auf neue (z. B. Grafiken, Format – neu ist HTML also geht, ggf. Hilfstemplate bereitstellen).
– [ ] Adoption Push neues Outlook: Da nun Key-Feature da, Team für Outlook-Migration Kickoff abhalten: Timeline erstellen, Champions einbeziehen, Schulungsmaterial für generellen Umstieg neu vs alt. (Signaturen nur Teil davon).
– [ ] Monitor Issues nach GA: In ersten Wochen nach GA Monitoring Telemetrie: Möglicherweise Telemetry (Admin Center) zeigt vermehrt neue Outlook usage – gut. Supporttickets mit „Signatur“ Tag tracken – sollten sinken.
– [ ] Feedback sammeln: kleine Umfrage an die initialen Umsteiger: „Fehlen noch Funktionen? Alles ok?“ um ggf. weitere Lücken an Microsoft zu melden oder Workarounds einzurichten.

Quellen/Referenzen: Microsoft Q&A – “New Outlook multi-signature support”, Moderator Alice N., 24.07.2025[7]; Microsoft 365 Roadmap ID 384092 – Feature: Add multiple signatures in Outlook, Stand: Q4 2025 (Quelle: KbWorks Blog 24.01.2025).

Outlook (Neue Version) – Drag-&-Drop zwischen Konten

Kurzbeschreibung: In der neuen Outlook für Windows App wird mit dem Oktober 2025-Update die beliebte Drag-&-Drop-Funktionalität zwischen unterschiedlichen E-Mail-Konten und Postfächern ermöglicht[8]. Dies umfasst insbesondere: Anhänge oder E-Mails per Drag-&-Drop von einem geöffneten Mailfenster in ein anderes Konto ziehen, E-Mails aus einem Posteingang direkt in einen Ordner eines anderen Postfachs verschieben, oder Inhalte aus gemeinsam genutzten Postfächern in das eigene kopieren. Diese Funktion war im klassischen Outlook selbstverständlich, fehlte jedoch in der initialen Version der neuen OneOutlook-App. Ihr Nachreichen wurde im Microsoft Message Center für Mitte Oktober 2025 angekündigt[8] und inzwischen als Update ausgerollt. Admins können dieses Verhalten per Richtlinie steuern (siehe unten). Insgesamt schließt Microsoft damit eine weitere Lücke der neuen Outlook-App, was speziell Power-User mit mehreren Accounts (etwa Berater mit Kundenpostfächern oder Assistentinnen mit Chef-Postfach) aufatmen lässt.

Warum es wichtig ist: Viele Benutzer arbeiten mit mehreren Postfächern parallel – z. B. ein persönliches, ein Funktionspostfach (Info@) und vielleicht ein Archiv. Im alten Outlook gehörte es zum Arbeitsalltag, E-Mails zwischen diesen hin und her zu bewegen (z. B. eine eingegangene Mail aus dem persönlichen Postfach in das Team-Postfach verschieben, oder vice versa). Ohne Drag-&-Drop war dies in der neuen App nur umständlich via „Bewegen in Ordner“-Menüs möglich, was Zeitverlust und teils Frustration bedeutete. Die Wiederherstellung dieser Funktion steigert damit deutlich die Produktivität von Multi-Account-Usern. Auch im Kontext von gemeinsamen Postfächern (Shared Mailboxes) ist es relevant: Assistenten können nun E-Mails direkt aus dem Chef-Postfach in ein Team-Postfach ziehen etc. Dies spart Klicks und verringert Fehler (z. B. versehentlich falscher Zielordner, wenn man über Menüs geht). Für Benutzerakzeptanz der neuen Outlook-App war Drag-&-Drop ein „Must-Have“ – manche hielten am alten Outlook fest, weil sie sonst ihren Workflow umstellen müssten. Nun gibt es einen Hinderungsgrund weniger. Insgesamt trivial erscheinend, aber im Office-Workflow essentiell: Intuitive Bedienung. Das Fehlen wurde als Rückschritt empfunden, das Comeback wird als Zeichen gesehen, dass Microsoft die Feedback-Schleife ernst nimmt. In streng regulierten Szenarien (die z. B. journaling erfordern) ist es neutral – hat keine Compliance-Auswirkung außer, dass es Nutzer motiviert, Ordnung zu halten (was positiv ist, z. B. Mails ins richtige Postfach archivieren).

Technische Details: Die Umsetzung dieser Funktion erfordert in der neuen App (die auf einem Web-Technologie-Stack basiert) speziellen Support: Der Outlook-Client muss Drag-Events erkennen und kontextuell behandeln. Wenn ein Nutzer eine Mail aus der Liste mit gedrückter Maustaste auf einen anderen Konten-Ordner zieht, wird nun im Hintergrund die entsprechende EWS/Graph-API MoveMessage Operation ausgelöst, adressiert an das Quell- und Zielpostfach. Neu ist, dass das Zielpostfach anders sein kann als das Quellpostfach – dies war anfangs aus Sicherheitsgründen blockiert. Microsoft hat hierfür einen Parameter „ItemsToOtherAccountsEnabled“ in den OWA MailboxPolicies eingeführt[32]. Standardmäßig wurde dieser im Oktober-Update auf „True“ gesetzt, sodass es funktioniert. Admins könnten ihn auf False setzen, um Drag-&-Drop zwischen Accounts zu unterbinden – jedoch gibt es selten Grund dafür außer vllt. isolierte Compliance-Bedenken (z. B. falls man streng Datenfluss zwischen bestimmten Mailboxen verhindern will, aber das wäre unüblich, dann eher transportregeln nutzen). Also im Normalfall belässt mans aktiviert. Bekannte Grenzen: Drag-&-Drop von Anlagen zwischen Compose-Fenstern und Desktop (z. B. aus File Explorer in Compose, oder aus Outlook in andere App) war zum Großteil schon implementiert, hier geht’s primär um Mails zwischen Konten. Große Elemente verschieben kann etwas länger dauern (im UI evtl. erst nach refresh sichtbar, weil Cloud Operation). Freigegebene Postfächer: Der neue Outlook unterstützt Drag in/out von Shared Mailboxes analog – Nutzer braucht Schreibrechte im Ziel. Rollen: Normale User können zwischen Konten, auf die sie Zugriff haben, Items verschieben oder kopieren (beim Drag mit Ctrl). Das Add-In-Model wird hier nicht tangiert. Testing: Möglicherweise wird eine Fehlermeldung angezeigt, wenn man versucht, in ein unberechtigtes Ziel zu droppen (z. B. ins Archiv eines Kontos, wo man nur Leserechte hat). Diese Cases wurden in Beta getestet.

Architektur/Governance: Für die IT-Architektur bringt dies keine größeren Implikationen – es bewegt nur Daten zwischen Exchange-Postfächern, was schon immer erlaubt war. Interessant ist der Steuer-Parameter: „ItemsToOtherAccountsEnabled“ in OWA Mailbox Policy (Set-OwaMailboxPolicy). IT-Admins könnten definieren, dass z. B. für bestimmte sensiblere Konten Drag-&-Drop cross-account aus ist. Aber das wäre eine sehr spezielle Anforderung; in aller Regel belässt man default aktiviert. Governance sollte allenfalls darüber informieren, dass nun nichts mehr dem Umstieg im Wege steht. Falls es interne Schulungsunterlagen gab, die warnten „Achtung, neue Outlook kann kein cross-account Drag, Workaround XY“, sollten diese nun aktualisiert werden – Workaround überflüssig. Compliance: Der Datenfluss zwischen Postfächern ändert sich qualitativ nicht – Drag ist nur UI. Wenn ein Unternehmen Richtlinie hat, Mails strukturierter abzulegen, kann es das als positive Chance sehen (Nutzer werden es jetzt eher tun). Falls aber aus einem journaled Postfach in ein nicht-journaled gezogen wird, würde die Journalregel das als exit interpretieren – aber da Journal in ExO global greift, kein Problem. Eher: Mail aus geschütztem Aufbewahrungspostfach raus, aber das geht nominell nicht, da Person kein Zugriff auf z.B. eDiscovery-Holde Mails hat. Also kein direkter Impact. Sicherheit: Wenn ein User kompromittiert ist, könnte Angreifer Mails schneller massenweise in anderes Konto verschieben (allerdings spuren hinterlassen). Unwahrscheinlich Attack-Vector.

Anwendungsbeispiel: Szenario: Office-Managerin verwaltet das Shared Mailbox „Anfragen@“ neben ihrem persönlichen Postfach.
– Im gemeinsamen Postfach kommt eine wichtige Mail rein, die eigentlich die Chefin betrifft.
– Früher hat sie die Mail weitergeleitet oder Kopie rausgezogen. Jetzt nimmt sie die Mail per Maus und zieht sie auf ihr persönliches Postfach in den Ordner „Chef/ToDo“.
– Outlook verschiebt die Mail reibungslos. Im Shared Postfach ist sie weg (oder optional vor Drag-Klick Strg gehalten -> dann wäre sie kopiert, aber in der Praxis meist Move).
– Die Chefin sieht nun in dem geteilten Ordner in Office-Managers Postfach die Mail und kann reagieren.
– In anderem Fall: Office-Managerin hat pro Quartal Mails aus „Anfragen“ in Archivpostfach (PST) gezogen. Jetzt kann sie analog Mails ins Online-Archivpostfach droppen (sofern UI es anzeigt) oder in einen „Archiv“-Ordner in eigenem Postfach, von wo Archivierungsrichtlinie es wegräumt – Workflows erleichtert.

Auswirkungen auf Lizenzen & Kosten: Keinerlei direkte Lizenzänderung. Indirekt, wie bei Signaturen, ist es ein Wegbereiter, um Legacy-System (altes Outlook, evtl. Terminalserver, CITRIX Umwege) loszuwerden – könnte langfristig Kosten sparen. Aber hier Focus: Die neue Outlook App wird attraktiver, das kann bedeuten, man kann z. B. Modern Authentication Only durchsetzen (alte Outlook abschalten -> Sicherheitsgewinn, aber an Lizenzen ändert das nix).

Risiken & Gegenmaßnahmen: Versehentliches Verschieben: Drag & Drop birgt immer die Gefahr, dass man aus Versehen etwas in falschen Ordner zieht, besonders cross-account kann es unbemerkt bleiben („Wo ist die Mail hin? Ach im anderen Postfach gelandet“). Dagegen kann man in Schulungen sensibilisieren: Outlook bietet die Undo-Funktion (Strg+Z kurz nach Move hebt es auf, das war im alten Outlook so, hoffentlich im neuen auch implementiert). Performance: Große Moves (tausende Mails) via Drag sollten vermieden bzw. in Batches – wenn ein User das doch macht, kann es Outlook kurz belasten. Admins sollten bei Migrationen lieber eDiscovery export etc. nutzen als Drag by user. Policy Conflict: Wenn es interne Regel gäbe „keine Firmenmails ins privates Konto ziehen“ – mit Drag ginge das (wenn privates Konto in Outlook konfiguriert). Das ist aber kein neu geschaffenes Risiko, man konnte immer mails weiterleiten. Hier eventuell DLP regeln an, die extern sending filtern – aber Drag spoolt es ja auf Exchange, DLP kann es vielleicht erfassen (z. B. wenn privates Konto Gmail IMAP eingebunden -> auch improbable in Enterprise). Also kein echtes neues Leak-Risiko. Betrieb: Wenig riskant. Möglicherweise gibt es am Anfang UI-Bugs, z. B. man zieht was, Outlook zeigt es doppelt -> Refresh fixed. IT sollte Patchnotes verfolgen, aber das meiste in Beta ausgemerzt.

Einführung & Change Management: Kommunikation: Kombiniert mit Signaturen am besten: „Neues Outlook jetzt mit allen gewohnten Funktionen.“ Highlight Drag&Drop in interner Info, da einigen das gefehlt hat. „Sie können nun Mails per Drag zwischen Konten verschieben, wie gewohnt.“ Evtl. kurze Demonstration in virtueller Kaffeerunde. Pilot und Rollout: Wahrscheinlich floss es in denselben Update wie Signaturen, also man rollt es eh zusammen aus. Admin Task: OWA Mailbox Policy check: Standard weise enabled, aber Admin sollte in Org bestimmen, ob Ausnahmen: In 99% want it on. Wenn irgendwelche Gruppe aus obskuren Grund block (evtl. bestimmte Sensible?), könnte man separate OWA Policy and assign to them. Aber kein gängiger Fall. Support: Weniger kritisch. Evtl. Tickets „früher ging Drag&Drop, in neu ging’s nicht, jetzt geht’s wieder“ – die hat’s gegeben, jetzt kommen keine neuen, also abgehakt. Adoption Neuer Outlook: Ach hier, wie Signaturen: interne Umstiegsinitiative. Als Checkpoint: Mit dieser Funktion + Signaturen + (vielleicht demnächst) Offlinemodus, etc. ist Neuer Outlook reif. Also Press Go: In Schulungen zum neuen Outlook betonen „jetzt geht Drag&Drop, was neu is und war in alt Standard“ – Klammer damit.

Checkliste Umsetzung:
– [ ] OWA Policy geprüft: Set-OwaMailboxPolicy -Identity <policy> -ItemsToOtherAccountsEnabled $true sichergestellt (sollte default, aber double-check, v.a. falls Organisation mal in Preview aus war). Ggf. neue OWA-Policy (falls noch Standard an allen) updaten.
– [ ] Pilot/Testing: IT oder Early Adopter haben Drag mit verschieden Kombis ausprobiert: Shared Mailbox -> eigenes, eigenes -> Shared, eigenes -> PST (sollte PST gar nicht im neu geht, da PST support?), also das Reale: Archivpostfach (online archive) -> Primär, etc. Feedback: ok.
– [ ] Awareness-Kampagne neu Outlook: In Kommunikationsmaterial (siehe Signaturen-Sektion) Drag & Drop als Punkt aufnehmen. Möglicher Slogan: „Alt vertraute Features kehren zurück: Drag&Drop und Co.“
– [ ] Update Rollout orchestriert: (Wie bereits bei Signaturen, da es gleiches Update war) plan machen, falls noch nicht geschehen.
– [ ] Schulung angepasst: Wenn IT Anleitungen für „Wie bewege ich Mails im neuen Outlook, da drag fehlt?“ erstellt hatte, nun diese anpassen oder obsolet machen. In zukünftigen Trainings ‚Neuer Outlook‘ normal das Feature drin.
– [ ] Team-Meetings/Abteilungsinfo: Teamleiter / Champions in den Fachbereichen informieren Kollegen: „Neue Outlook kann nun (fast) alles was alt konnte. Versucht es doch, Umstieg ready.“
– [ ] Feedback & Logs: Monitoren nach Rollout: Falls es Bugs gibt (anhand evtl. Telemetrie „MoveMessageCrossMailboxFailed“), MS support eskalieren. Erste 2 Wochen nach Deployment extra hinhören ob user complains any anomalies.
– [ ] Altes Outlook Ablöseplan: Mit Wegfall der letzten Resistenzfunktionen Plan für Abschaltung/Standard-Wechsel auf neue Outlook definieren (im Tenant „Try the new Outlook“ Toggle autodistribute, Schalter alt->neu, etc.). – [ ] Policy doc (falls): Wenn Orga InfoSec hat, die Datenfluss Limits definieren, review ob Drag&Drop crossaccount concerns: i.d.R. unbedenklich vs. bisher.
– [ ] Third Party Tools: Falls Tools monitor Outlook usage, vlt. anpassen auf neuen flows (unwahrscheinlich).

Quellen/Referenzen: Microsoft Message Center – MC1104315: „Drag and Drop Between Accounts Coming to New Outlook“, 05.10.2025[8]; Microsoft 365 Roadmap Updates – TechCommunity „Mid-Oct 2025 – Drag and Drop…“[8].

Microsoft Planner – KI-gestützter Planungsassistent

Kurzbeschreibung: Microsoft Planner – das Aufgaben- und Projektplanungstool in Microsoft 365 – hat 2025 einen umfassenden Relaunch erlebt. Ein Herzstück davon ist der KI-gestützte Planungsassistent namens Project Manager Agent, der Funktionen des früheren „Copilot in Planner“ weiter ausbaut[9]. Dieser Assistent hilft Teams, automatisch Projektpläne zu erstellen, Aufgabenlisten zu generieren, Statusberichte zu schreiben und Aufgaben abzuarbeiten, indem er natürliche Sprache und Websuche nutzt. Mit dem Planner-Update Juli/August 2025 wurde der KI-Agent in alle Planner-Umgebungen integriert (für Nutzer mit Microsoft 365 Copilot Lizenz)[33]. Man kann nun z. B. in einem neuen Plan per KI-Eingabe grob das Projektziel beschreiben – der Agent legt daraufhin einen kompletten Plan mit Bucket, Phasen und Aufgaben an. Ebenso kann er aus einem Plan auf Knopfdruck einen Statusbericht formulieren (in mehreren Sprachen). Er kann Aufgaben mit Web-Recherche anreichern (z. B. bei einer Aufgabe „Marktanalyse“ automatisch aktuelle Marktdaten anhängen)[34]. All dies beschleunigt die Projektplanung und -steuerung erheblich.

Warum es wichtig ist: Projektplanung erfordert oft viel initiale Detailarbeit (Aufgaben definieren, Termine setzen) sowie laufend Reporting. Der KI-Assistent nimmt Teams hier enorm Arbeit ab, vor allem in der Startphase von Projekten und bei Standardaufgaben. Das bedeutet Zeitersparnis und Qualitätsgewinn: Pläne werden vollständiger (KI denkt an Aspekte, die Menschen evtl. vergessen) und Berichte werden schneller erstellt, in konsistenter Sprache. Für Unternehmen ist das interessant, um die Produktivität in Projekten zu steigern und die Schwelle zum Planen zu senken – früher wurden kleine Projekte vllt. gar nicht formal geplant, nun kann KI binnen Sekunden eine Struktur liefern. Auch die Zusammenarbeit profitiert: Der Planungsagent kann Chat-basiert Fragen beantworten („Welche Aufgaben sind riskant?“) und Hilfestellung geben, was als nächstes zu tun ist – quasi ein virtueller Projektcoach. Im Kontext Hybrid Work und agiler Methoden ist so ein Tool wertvoll, um remote Teams auf Stand zu halten. Allerdings erfordert es Change Management: Projektleiter müssen Vertrauen aufbauen, dass KI sinnvolle Pläne generiert, und lernen, diese als Startpunkt zu nutzen (Feinschliff bleibt beim Menschen). Sicherheits-/Compliance-Verantwortliche achten drauf, dass KI keine vertraulichen Projektdaten in unsichere Kanäle schreibt – hier gibt es aber Mechanismen, dass Daten im Tenant bleiben. Insgesamt ist der Planner-KI-Assistent ein Beispiel, wie Microsoft Copilot-Funktionalität gezielt in Business-Workflows integriert – ein Wettbewerbsvorteil und Grund mehr, M365 im Projektmanagement zu nutzen statt Dritttools.

Technische Details: Der Project Manager Agent in Planner ist Teil des Microsoft 365 Copilot Services. Voraussetzung: Mindestens ein Nutzer im Plan hat Copilot-Lizenz (der Agent in geteilten Plänen ist dann für alle Planmitglieder nutzbar, laut MS-Angaben). Integration: In der Planner Web-App und Teams-Integration erscheint ein Chatbot-Button (schwebend unten rechts)[35]. Darüber kann man per Chat-Befehl mit dem Agent interagieren. Zudem gibt es kontextspezifische KI-Aktionen: z. B. im Goals-View ein Button „Generate tasks“ neben einem definierten Ziel – der Agent erstellt dann passende Tasks[36]. Oder in Plan-Chat-Bereich kann man „Erstelle Statusbericht“ auswählen. Der Agent hat Zugriff auf: die Plandaten (Aufgaben, Status, Zuweisungen), den Graph (User, Gruppe) und kann bei erlaubtem Setting Websuche ausführen[34]. Letzteres bedeutet, er ruft über Bing/Web Search API Infos ab, die er in Aufgabenergebnisse einbauen kann (Beispiel aus August 2025: Agent kann relevante Neuigkeiten aus dem Web in den Aufgaben-Output einfließen lassen[34]). Das Websearch-Feature respektiert die entprechende Orgn-Einstellung (Admin kann Copilot Web Access erlauben oder nicht). Technisch ist der Agent ein generatives GPT-4 Modell, spezialisiert/trainiert auf Planner-Schema. Quality improvements* wurden in Aug 2025 ausgerollt (bessere Plan-Vorschläge)[37]. Alles passiert cloudseitig; im Client sieht man generierte Listen, die man akzeptieren oder modifizieren kann. Bekannte Limits: Sehr spezifische oder kreative Plananforderungen versteht er evtl. nicht perfekt; es dient eher als Kickstart. Der Agent „spricht“ Deutsch, Englisch etc. je nach Benutzer-Sprachsetting (Aug 2025 Einführungsinfo: Statusberichte in 40+ Sprachen verfügbar[38]). Zugriff: Der Agent beachtet Plan-Berechtigungen, kann nur Tasks in dem Plan generieren, wo er aufgerufen wird. Er generiert nicht autonom Dinge in allen Plänen. Datenspeicherung:** die generierten Aufgaben sind normale Planner-Daten, die Konversation mit Agent ist temporär (vsl. wie ChatGPt no persistent beyond session, oder Summaries could be saved if user chooses).

Architektur/Governance: Governance-Aspekt ist hier vor allem: Werden KI-erstellte Aufgaben als solche markiert? Aktuell nicht offensichtlich, es sei denn man schaut Historie. Organisationen könnten definieren, dass KI-Einsatz im Projektreporting transparent gemacht werden sollte (ethische KI-Richtlinie). Rollen: Jeder Plan-User mit Zugriff kann Agent nutzen, aber es könnte Sinn machen, intern Guidelines festzulegen, z. B. „Projektleiter ist verantwortlich, KI-Vorschläge zu prüfen, bevor Team sie sieht“ – aber da Team ja Plan sieht, könnte auch ein Teammitglied mal Agent anschmeißen. Damit muss man rechnen; Governance Board sollte Vertrauen in Team-Vernunft haben oder Kommunizieren „KI kann helfen, ersetzt aber nicht euer Brain“. Lizenz: Nur die Copilot-lizensierten sind Gatekeeper – falls es in Team nur einer hat, könnten alle profitieren, was Lizenzausnutzung optimiert (fraglich, ob Microsoft dem langfristig Schranken setzt). Risiko mgmt: Mögliche Fehleinträge (z. B. KI generiert zu viel oder falsche Deadline) – hier gilt der Mensch-in-Loop, Plan-Owner muss Kuratieren. Governance-Vorgabe: „KI Task generation only for initial brainstorm, dann manuell Feinplanung“. Datenzugriff: Der Agent greift auf Webinhalte – Governance muss abklären: Ist das okay, dass M365 was aus dem Internet holt? It’s read-only, keine Daten raus, also ansich Ok. Falls streng isolierte Environ., kann Admin Web Search Off schalten (dann Agent generiert nur aus internen Wissen). Sicherheit: Der Agent könnte Links aus Web einfügen – Projektteams müssen trotzdem InfoSec Policies zu unbekannte Links beachten (vllt. kommen references mit). BSI/DSGVO: Der Agent verarbeitet potenziell Projektinhalte um Berichte zu generieren – wie bei Copilot, sollte in DSFA KI-Einsatz erwähnt, aber es verbleibt im Tenant, kein extra Privacy risk.

Anwendungsbeispiel (in Schritten): Szenario: Marketing-Team plant Event, will groben Plan via KI.
1. Team erstellt neuen Plan „Product Launch Event“.
2. In Planner taucht Option auf: „Plan vom Project Manager Agent generieren lassen“. Das Team klickt und gibt ein: „Wir planen ein Produkt-Launch-Event im März mit ca. 200 Gästen. Erstelle Aufgaben für Vorbereitung (Location, Catering, Einladungen, Presse etc.).“
3. Der KI-Agent verarbeitet dies und erstellt im Plan: Buckets „Vor dem Event“, „Event-Tag“, „Nachbereitung“. Darunter Aufgaben: z.B. „Location buchen (Deadline 15. Jan)“, „Catering auswählen“, „Einladungs-Mailing versenden (Deadline 1. Feb)“, „Pressemitteilung vorbereiten“, etc., inklusive Vorschlag wer (evtl. basierend auf typischen Rollen im Team) und mit Prioritäten.
4. Das Team prüft die Liste, passt einige Dinge an (fügt vllt. Budget-Task hinzu, den KI vergaß).
5. Eine Woche später fragen Chefs nach Status. Der Projektleiter klickt „KI-Statusbericht generieren“. Agent liest alle offenen/erledigten Aufgaben und formuliert z.B.: „Von 10 Aufgaben sind 3 abgeschlossen (Location, Catering, Einladungstext), 7 in Arbeit. Zeitplan generell im grünen Bereich, jedoch ‚Pressemitteilung‘ verspätet (keine Zuweisung). Empfohlen: Verantwortlichen benennen und Deadline anpassen.“
6. Der Leiter kopiert diesen Bericht in eine E-Mail an Chef und ergänzt menschliche Note.
7. Während laufender Arbeiten nutzt das Team den Chat: Bsp: „@ProjectAgent: Liste uns die Top-Risiken im Plan.“ KI schaut auf überfällige oder kritische Pfade und antwortet: „Risiko: Pressemitteilung keine Zuweisung -> kann Launch-Presse fehlen; Risiko: Catering-Bestätigung ausstehend -> evtl. Ersatz suchen…“ (plus vllt. Web info „ein anderes Event am Tag belasten Catering-Kapazität“ falls Web Search).
8. Das Team ergreift auf Basis dieser KI-Hinweise Maßnahmen.
9. Projektende: Alle sind überrascht wie schnell sie Plan initial hatten. Der Chef lobt den formschönen Statusreport, der so gut formuliert war – vielleicht sogar mit Diagramm, denn KI kann in Viva Goals/PowerPoint was generieren.

Auswirkungen auf Lizenzen & Kosten: Der KI-Planungsassistent erfordert Microsoft 365 Copilot-Lizenzen – ergo ~30 USD/Benutzer/Monat. Allerdings muss nicht jeder Plan-Teilnehmer lizenziert sein; offiziell reicht Copilot-Lizenz pro Person, die KI-Abfrage macht, aber ob Ergebnisse alle sehen, ist im UI offen: Im Chat sieht es nur der Abfragende, aber generierte Aufgaben/Report sind dann für alle Plan-Mitglieder sichtbar. Somit kann in Team nur PL lizenziert sein, der generiert Plan/Reports. Dennoch, Microsoft wird das lizenztechnisch vielleicht limitieren. Daher konservativ: Team will vollen Benefit -> alle oder zumindest mehrere PLs Copilot-lizenziert. Lizenzpläne: Planner selbst ist in allen M365 Plänen (Business, E3/E5). Copilot-Lizenz ist Add-on auf E3/E5 (nicht Business Stand). D.h. Mittelstand Business Premium hat Planner, aber keinen Copilot – ergo keinen Agent. Das kann Druck erzeugen, auf E5 + Copilot upzugraden, was signifikante Mehrkosten. Hier muss IT-Einkauf abwägen, ob Nutzen das rechtfertigt. Add-ons: Der Planner Agent ist fix in Copilot – es gibt kein separates Add-on nur dafür. Kosten/Nutzen-Rechnung: Wenn Agent 10% Projektmanager-Zeit spart, und man hat x PMs, kann man argumentieren, Copilot-Lizenzen lohnen sich. Evlt. testet man mit kleineren Team (Lizenz-Pilotmonate). Also Lizenzeinfluss: Mögliche Ausweitung Copilot-Lizenzkauf 2024, was Budget relevant.

Risiken & Gegenmaßnahmen: Inhaltliche Fehler: KI kann unpassende Aufgaben generieren oder was Wichtiges vergessen. Gegenmaßnahme: Bewusst KI nur als Hilfsmittel, nie blinder Vertrauen. Teamintern Regel: „Review tasks thoroughly.“ Übermäßiges Vertrauen: Team neigt vllt. sich auf KI-Vorschlag zu beschränken und denkt nicht mehr kreativ – dem kann man mit Guidance entgegnen („Nutzt KI als Start, aber Brainstorm ergänzt“). Datenschutz: KI-Bot hat Webzugriff: in streng vertraulichen Projekten könnte man wollen, dass keinerlei externe Info reinspielt. Admin kann WebSearch off, oder Team offline halten. Plagiats-/Urheberrecht: KI generierter Bericht – unbekannt ob Textfragmente vielleicht ähnlichen Standardreport plagiiert. Eher gering, aber man ist hald Output-Verantwortlicher. Bias: KI könnte Vorschläge mit Systematiken machen (z. B. always Press Release, even if not needed) – Team muss anpassen. Abhängigkeit: Nicht risk, aber man muss aufpassen, dass Leute nicht Planen verlernen, aber sie nutzen es ja weiterhin, nur beschleunigt. Sicherheitsfreigabe: Ggfs. InfoSec hat Bedenken, generative KI hier (fear of hallucination misguiding project), address by pilot and rational demonstration.

Einführung & Change Management: Pilotphase: Da Planner Agent eng mit Copilot zusammenhängt, vermutlich erst verfügb nach Copilot-tenant Activation. Also initial in Early Adopter Teams mit Copilot-Lizenz. Sammeln, wie gut es ankommt. Einbindung PMO: Projektmanagement Office in Firma sollte mit im Boot: Evtl. Standard-Plan-Vorlagen definieren, die KI dann adaptieren kann. Oder Guidelines, wann KI-Statusreport genutzt vs. manuell. Training: Mitarbeiter mit Planner-Copilot sollten geschult, wie man gute Prompts gibt („Generiere X vs. Liste Y“). Und worauf bei KI-Basiertem Plan zu achten (Deadlines check, Dependencies hinzufügen manuell etc.). Kommunikation: Erklären, dass Planner aus „Aufgabentool“ jetzt fast „Mini-Projektmanagement KI“ wird – Begeisterung wecken, aber auch realistisch: „KI hilft, aber du bleibst Chef des Plans.“ Evtl. interne Webinar „Effiziente Projektplanung mit AI in Planner“ anbieten. Kultur: Encourage Teams to experiment freely in less critical Projects to get feel. Lizenz-Entscheid: Abhängig vom Testerfolg, mgmt invests more in Copilot seats. IT Support: Hilfreich, falls initial Issues (Beta bug z.B. spracherkennung?), aber likely minor. KPI: Track adoption: Wieviele Pläne nutzen Agent (telemetry?), Umfrage PL: Spart es euch Zeit? Rollout Steps: Erst Teams with open mind (IT, R&D), dann wenn positive results, breiter an heavy Planner user groups (Marketing, Product dev), etc.

Checkliste Umsetzung:
– [ ] Copilot Pilotphase initiiert: In z.B. 1-2 Projektteams Copilot-Lizenzen verteilt und Planner KI getestet (Beispielprojekt angelegt, KI-Vorschläge evaluiert). Feedback mit PLern durchgegangen (was gut, was unsinn, woran lag’s).
– [ ] PMO/Betriebsrat involviert: Projektmanagement Office informiert und befürwortet Einsatz (evtl. separate Freigabe nicht nötig, aber gut sie sind Key Sponsor in Kultur). Arbeitnehmervertretung in Kenntnis, falls relevant (KI im Prozess).
– [ ] Tenant-Setting (Websearch) gemäß Policy: Falls Org es erlaubt, Web Such einschalten. Falls Bedenken (z. B. streng intern), Copilot-Befehl zum Web togglen off per Admin (gibt es in Copilot config).
– [ ] Schulung Material: Quick Reference „So nutzt man den Planner-Planungsassistenten“ erstellt – inkl. Beispiele Prompts, Erklärungen wie man generierte Tasks nachpflegt (z. B. Abhängigkeiten manuell erstellen, KI macht das noch nicht).
– [ ] Lizenz Planning: Basierend auf Pilot ROI, Entscheidung: Rollout Copilot an alle PM? Oder pro Department-Leads? Budget entsprechend anpassen und zustimmen lassen.
– [ ] Phasenweiser Rollout: Z.B. Phase 1 an PMO und Schlüsselprojekte, Phase 2 dann an restliche Projektleiter, Phase 3 optional an alle Wissensarbeiter. Zwischendurch auswerten und Feinsteuer.
– [ ] Kickoff-Workshops: Mit Projektteams Workshops, KI-Agent live vorführen. Evtl. eigen Daten volley (in Demo Umgeb.) nutzen, damit sie Potential sehen.
– [ ] Best Practices teilen: Early Adopter PL, die erfolgreich KI nutzten, interviewen und interne Case Study verteilen: „In Projekt X hat uns der Planner Agent 5h Planungszeit gespart und an Risiko Y erinnert, was wir übersehen hatten.“
– [ ] Policy/Governance note: Intern festgehalten: „KI-Vorschläge sind vom PL zu überprüfen. Haftung und finale Verantwortung liegen beim Menschen.“ (so hat man es, falls mal was schief, dass KI nicht scapegoat sondern wir – sprich Nudging professional caution).
– [ ] Monitoring & Feedback: Set up a channel for user feedback, especially on quality: z. B. „Agent hat dummen Task generiert“, Team send screenshot -> kann man an Microsoft melden, who fine tunes mod. Oder intern ML specialist just collects patterns.
– [ ] Erfolgsmessung: 3-6 Monate nach Rollout Umfrage an Projektleiter: Zeitersparnis quantifizieren, Zufriedenheit mit KI. Falls positiv, weiter ausrollen / falls negativ, identifizieren woran (Fehlerkultur, tech issues, scope?).

Quellen/Referenzen: Microsoft Planner Blog – “What’s new in Microsoft Planner – August 2025”, 28.08.2025[33][39]; Microsoft TechCommunity – “Planner’s Project Manager agent enhancements” (Release Notes August 2025)[36][35].

Microsoft Entra ID – Identity Governance für KI-Agents

Kurzbeschreibung: Microsoft Entra ID (ehemals Azure AD) führt mit Entra Agent ID ein neues Konzept ein, um KI-gestützten Agents eindeutige Identitäten und Zugriffssteuerungen zu geben[40]. Dieser Mechanismus wurde im Juni 2025 vorgestellt und befindet sich Ende 2025 in ersten Pilotanwendungen. Die Idee: Sogenannte AI Agents (z. B. autonome Chatbots, Copilot-Plugins oder Skripte mit Entscheidungsfreiraum) erhalten eine eigene digitale Identität in Entra ID – analog zu einem Dienstkonto – mit der sie sich authentifizieren und autorisiert werden können. Dadurch lassen sich Conditional Access-Richtlinien, Rollen und Berechtigungen genauso auf KI-„Akteure“ anwenden wie auf menschliche Benutzer[41]. Unternehmen behalten so die Kontrolle, welche Daten und Systeme ein KI-Agent nutzen darf, und können Aktivitäten von Agents überwachen und protokollieren. Entra Agent ID ermöglicht es z. B., einem Vertriebs-KI-Bot nur Zugriff auf die CRM-Daten zu geben, die er wirklich braucht, und per Policies auszuschließen, dass er z.B. HR-Daten abruft – genau wie bei menschlichen Accounts das Prinzip der minimalen Rechte. Außerdem können Agent-Identitäten über den Lebenszyklus verwaltet werden (Erstellung, Zuweisung zu Besitzer, Deaktivierung, wenn Agent außer Betrieb geht). Das Hauptziel ist, KI-Lösungen sicher und nachvollziehbar in Unternehmensumgebungen einzubinden, ohne menschliche Konten „missbrauchen“ zu müssen oder Sicherheitslücken zu riskieren.

Warum es wichtig ist: KI-Systeme werden immer autonomer und agieren teils ohne direkten Nutzerauftrag – Beispiel: Ein KI-Agent durchsucht Mails und bucht Termine selbstständig. Aus Unternehmenssicht entsteht hier ein neuer Identitätstyp, der managenbar sein muss. Entra Agent ID ist ein absolut zukunftsweisendes Feature, weil es dem Unternehmen ermöglicht, Governance und Compliance auch auf KI-Dienste anzuwenden. Bislang war unklar, wie man KI-Workflows vom Berechtigungskonzept her einhegt – oft liefen diese mit weitreichenden Service-Accounts oder gar unter Adminrechten. Mit Agent ID kann man granulares Least Privilege auch für KI definieren[42]. Das reduziert Sicherheitsrisiken enorm: Sollte ein KI-Agent kompromittiert oder fehlgeleitet werden, ist sein Zugriff beschränkt, und er kann nicht grenzenlos Unfug anstellen (z. B. Kundendaten aus CRM löschen, wenn er dafür keine Entra-Rechte hat). Zudem schafft es Transparenz: Aktionen eines Agents lassen sich im Log dem Agent-Konto zuordnen (nicht mehr verwirrend unter generischem Token oder dem Namen eines Entwicklers). Für Compliance-Abteilungen ist das Gold wert, denn so können KI-Aktivitäten auditierbar gemacht werden – was im Rahmen des kommenden EU AI Act gefordert sein könnte. Außerdem erlaubt es Vertrauen in KI: Wenn man die Kontrolle hat, wann ein Agent was tun darf, sind Fachbereiche eher bereit, ihn einzusetzen. Und man kann Verantwortlichkeiten definieren (Agent hat Owner in IT, der dafür grade steht, wie wir es mit Service Accounts kennen). Kurz: Agent ID ist ein entscheidender Baustein, um KI nicht zum Wildwuchs werden zu lassen, sondern in bestehende IT-Governance zu integrieren. Für Enterprise-Architekten und Security Leads ist das hochrelevant, weil es den Weg ebnet, KI-Lösungen (Bots, RPA, etc.) im großen Stil sicher zu betreiben.

Technische Details: Entra Agent ID funktioniert ähnlich wie Service Principals oder Managed Identities in Azure. Für einen KI-Agent (z. B. Copilot-Erweiterung oder Drittanbieter-Autonomous Agent) wird in Entra ID ein Objekt angelegt, das eine eindeutige ID, Anmeldeinformationen (z.B. Zertifikat oder secret) und definierte Zuweisungen (Gruppen, Rollen) besitzt[40]. Dieser Agent kann sich dann mit OAuth 2.0 oder anderen Protokollen gegenüber Microsoft 365 Diensten authentifizieren, erhält Token mit seinem Agent-Account. Der Administrator kann diesem Agent-Account genau definierte Rollen zuweisen (z. B. Leseberechtigung auf Kalender, Schreibrecht in bestimmter SharePoint-Site). Ebenso greift Conditional Access: Man könnte z. B. festlegen, Agent X darf nur tagsüber und nur aus dem internen Netzwerk heraus agieren – falls er Cloud-Only ist, eher Device/Location not applicable, aber man könnte andere Bedingungen definieren (z. B. High-Risk sign-ins blocken, analog user). Die Agent-Objekte tauchen auch in Audit-Logs auf, z. B. „Agent SalesBot hat auf Datei Z zugegriffen“ – Admins können so differentiate ob Mensch oder KI das tat. Im Entra Admin Center wird es einen Bereich geben, wo Agent-Identitäten verwaltet werden, inkl. Owner Info. Agent IDs unterliegen dem Lifecycle: z. B. wenn KI-Projekt endet, kann man Agent-Account entfernen oder disable – so wird unerwünschte Weiterverwendung verhindert. Integration: Startend wohl mit Dynamics 365 und Microsoft 365 Copilot Agents (Build 2025 Info: Agentic Apps A2A Protocol – Agents kommunizieren untereinander, brauchen ID)[43]. Wahrscheinlich initial Preview: Admin per PowerShell eine App reg, mark as Agent Identity type. Der Agent bekommt “Consistent Identity across tools” – d.h. egal ob in Teams Meeting als Bot oder als Background script, immer selbe ID, so unify. Überwachung: Man kann vermutlich separate Monitoring definieren (z. B. sign-in logs filtern auf IdentityType=Agent). Bekannte Limits (Stand 2025): Feature ist Preview, vllt. noch nicht GA – beschränkt auf bestimmte KI-Szenarien (z. B. nur Dynamics CoPilot?). Aber Plan in 2026 GA broad. Lizenzierung: Eher Komponente von Entra ID P2 (logisch bei Identity Governance). Evtl. generieren Agents IDs Azure AD External Or Service privileges, unklar ob counted separate etc.

Architektur/Governance: Entra Agent ID ist primär ein Security & Governance Tool: Die IT-Security-Abteilung sollte dieses Konzept ab Q4 2025 strategisch einplanen. Action Items: Inventarisieren, welche KI-„Akteure“ im Einsatz oder geplant sind (z. B. Chatbots im HR? RPA-Bots in Finance?). Dann definieren: Wir werden für diese Agent Identities anlegen anstatt generischer Service Accounts. Das erfordert oft Absprachen mit Entwicklern: Sie müssen ihren Bots beibringen, statt global API-Keys nun Entra Auth zu nutzen. Für Governance heißt das: Richtlinienupdate – in Access Control Policies definieren, dass neu alle Bots eine AgentID bekommen müssen. Und Ownership klären: Wer ist Pate für welchen Agent (z. B. HR-Bot Owner = HR-IT Team). Rollen-Model: Org muss evtl. neue AD-Rollen definieren, z. B. „Bots dürfen nur lesen“ – realisierbar über custom roles oder fine-grained (z. B. Graph Perm „Mail.Read“). Fleißarbeit, aber man kann klein anfangen (pragmatisch minimal needed). Conditional Access: Überlegen, ob man z.B. separate CA for Agents macht – z. B. „Bot logins always require certificate auth, no password“ – sprich enforce one method. Possibly, man nutzt Federated Credentials (Managed Identity style). Auditing: Plan, wie oft Agent Activity reviewed (z. B. Quarter: audit logs check if any unusual agent action). EU AI Act compliance: Das Konzept unterstützt, weil man so KI-Bot Handeln protokollieren kann (Transparenz & menschl. oversight). Also Governance should mention it im KI-Register. BSI (C5 etc): likely positives, agent accounts rattern in Indentity mgmt. Ggf. AD Baseline anpassen: e.g. „Bots must MFAs ineligible or different conditions.“

Anwendungsbeispiel: Szenario: Ein Sales-KI-Bot darf CRM-Daten abfragen und Angebote erstellen, aber nichts im HR-Bereich tun.
– IT legt in Entra ID für „SalesBot“ einen Agent ID Account an. Zuweisung: Gruppe „CRM Readers“, welche nur ans Dynamics CRM lesen darf. Und Teams-Senden erlaubt. Keine Rechte auf SharePoint HR-Sites.
– Der Bot-Entwickler registriert seine Anwendung und stattet sie mit den Anmeldeinfos des SalesBot aus (z.B. Zertifikat).
– Wenn SalesBot nun läuft und z.B. im Hintergrund per Graph nach Kundendaten sucht oder E-Mails sendet, authentifiziert er sich als SalesBot (nicht als Person oder generischer App). Entra ID protokolliert diese Anmeldungen.
– Conditional Access checkt: Ist es wirklich SalesBot? (z.B. kennt sein Zertifikat – passt). Er bekommt ein Token mit erlaubten Scopes.
– Als er versucht, auf eine Mitarbeiter-Info zuzugreifen (nicht erlaubt), wird Access Denied (kein Scope im Token). Bot reagiert: „Access not authorized“ und lässt es.
– In der Azure AD Sign-In Log sieht Admin: SalesBot attempted Graph call to /users/HRAlice – failed by policy. Das könnte man alarmieren („Bot X tried unauthorized scope“) – Owner wird informiert und passt Bot-Programmierung an (Verbot auch intern code).
– In allen Reports sieht man, Datenzugriff durch SalesBot (nicht z.B. Developer’s account – gut).
– Als nächstes injiziert InfoSec eine neue CA Policy: Bot logins only allowed from trusted IP (Azure to Azure likely scenario). Also er blockte mal aus ext – falls Bot in Cloud runs, fine.
– So läuft Bot kontrolliert. Wenn Projekt endet, Admin disabled SalesBot account. Jegliche Bot-Action scheitert danach. (Im Log: attempts after decomm, gut track).

Auswirkungen auf Lizenzen & Kosten: Entra Agent ID ist voraussichtlich Teil von Entra ID P2 oder Microsoft E5 Security Suite (wo Identity Governance drin). Wenn ein Unternehmen P2 hat, keine Mehrkosten; falls nicht, könnte es den Case verstärken, P2 zu lizenzieren. Der Preview stand im Release Plan als „no addl lic during preview, likely need P2 at GA“. Also für Planning: falls man dies nutzen will und nur P1 hat, sollte man P2 Lizenzen (ggf. 10% user quantum rule) budgetieren. Agent Entities selbst: counts as App or user? Normal Azure AD limit etc – trivial. Volumen: Wenn sehr viele Bots, minimal overhead. Kosten indirekt: Implementation – Zeit um Setup & train devs. Gains: potentielle Einsparung, weil weniger potentielle KI-Schäden (Risiko Minimierung).

Risiken & Gegenmaßnahmen: Komplexität: Es ist neu – Dev Teams müssen lernen, Bot mit Entra identity authentifizieren (weniger trivial als Hardcoded Key). Gegenmaßnahme: Schulung und Patterns/Libs bereitstellen. Bot Developer circumvent: Evtl. Resistenz „Funktioniert grad mit Admin API Key, wozu change?“ – muss mgmt push; not risk but adoption challenge. Agent Creds theft: Wie schützt man Agent Credentials? -> z. B. Zertifikats-basiert, in Key Vault – definieren. Fehlkonfiguration: Falls Admin Agent zu viele Rechte gibt, Bot misused – treat like Service accounts: apply least privilege, review. False sense: Agent ID mitigates risk, aber Bot kann immer noch Mist mit allowed perms anstellen – oversight needed. Scale risk: If company starts many bots, Identity governance must scale; ensure processes (like: when new Bot project, mandatory AD registration etc.). Regulatorisch: By controlling bots identity, man hat „eingedämmt“, aber EU AI Act will auch risk mgmt pro Bot – Agent ID helps but not fully, man muss trotzdem KI output monitor.

Einführung & Change Management: Awareness in IT: Security Architects und DevOps Team müssen früh dieses Konzept verstehen (vielleicht Build 2025 Sessions). Plan entwerfen, welche existierenden Bots man migrieren kann. Pilot: Wähle 1-2 KI-Agents (z.B. interner Outlook Chatbot, RPA flow) und implementiere Agent ID. Lerne Stolpersteine. Define Process: Erstelle Guidelines: „So beantragst du eine Agent ID for your Bot“ – akin to Service Account process. Possibly in Identity Governance Workflows (Entra ID can do Access Package: Bot owner requests an Agent identity, gets approved by InfoSec, then can config secret etc.). Communication: Intern an alle Solutions Architects: „We now have a safe way to run your bots – please adopt.“ Tooling: Provide step-by-step or scripts to create agent accounts. Conditional Access: Decide baseline for Agents (z.B. require certificate or federated cred – no PW). Set that up. Integration with DevOps: e.g. define that pipeline obtains Agent credentials from KeyVault – train devOps eng. License: If not P2, plan to get P2 or at least trial for preview. Stakeholder: Possibly involve compliance, they might love it and champion it. Timeline: Q4 2025 Preview – maybe limited features; plan GA likely 2026 H1 – be prepared from mid 2026 fully.

Checkliste Umsetzung:
– [ ] Preview/test aktiviert: Falls verfügbar, Entra Agent ID Preview im Tenant oder Dev Tenant freigeschaltet (manchmal via Entra Labs). Erster Test-Agent angelegt, gem. Doku Patterns – Logging und Access evaluiert.
– [ ] Use Case Inventur: Liste aller vorhandenen KI-/RPA-/Bot-Dienste erstellt (inkl. Service Accounts, App Regs die diese nutzen). Priorisiert welche migr.
– [ ] Security Policy formuliert: „Jeder KI-Agent muss eigene Entra ID haben, mit minimal nötigen Rechten. Nutzung generischer Service Accounts für Bots ist untersagt nach dd.mm.yyyy.“ – von CISO abgesegnet.
– [ ] Rollen & Berechtigungskonzept erarbeitet: Mögliche Standardrollen für Bots definiert (z. B. Bot-Reader-CRM, Bot-SendMail etc.). Evtl. custom Graph permissions oder Umbau Anwendungsberechtigungen in Delegated via Agent (es ändert Auth-Flow).
– [ ] Entwickler informiert & geschult: Alle Teams, die Bots entwickeln, haben Info-Session erhalten. Inhalt: Was ist Agent ID, warum gut, wie adaptieren Code (z. B. AcquireTokenForClient mit specific clientid & cert). Q&A klären.
– [ ] Lifecycle Prozess implementiert: Im Identity Governance (Entra) Access Package oder ITSM-Workflows erstellt: Neuer Bot -> Request Agent ID -> Freigabe -> Provision -> OwnerZuweisung im AD. Ebenso Offboarding: beim Projektende Ticket -> Agent disable.
– [ ] Conditional Access für Agents: Separate CA Policy „Wenn PrincipalType=ServicePrincipal/Agent & Risky -> block“ oder „Anmeldung nur von vertrauenswürdiger Umgebung zulassen“ – konfiguriert.
– [ ] Key Management: Vorgaben: Agent Auth möglichst über Zertifikat via Federated Identity (z.B. Codesigner azure workload identity) statt statischem Secret. Falls secret, in KeyVault streng gesichert.
– [ ] Pilot Migrations ausgeführt: 1-2 vorhandene Bots vom alten Cred auf Agent ID umgestellt, Prod getestet, alles ok (ggf. minor code adj.).
– [ ] Audit & Monitoring eingerichtet: Log Analytics Query oder Entra Workbooks erstellt, die Agent-Aktivitäten auswerten (z. B. weekly report: which Agents did what, any access denied attempts, etc.). Alerts definieren (z. B. Agent X tries unauthorized scope => high severity alert).
– [ ] Review-Schleifen: Governance Board nimmt Agent IDs in sein Portfolio (z. B. quartalsweise Check: sind alle Agents noch aktiv, noch needed? owners ok?).
– [ ] Kommunikation an Management: Verdeutlichen, dass Orga proaktiv KI Governance etabliert hat (gut für interne/externe Compliance Reports, evtl. in Geschäftsbericht als positive KI-Kontroll-Maßnahme erwähnen).

Quellen/Referenzen: Microsoft TechCommunity – “What’s new in Microsoft Entra – June 2025”, 01.07.2025[40]; Directions on Microsoft – Build 2025 Highlights (Agent2Agent, AI Agents memory in Teams etc.)[44]; Microsoft Mechanics – Entra ID Agent IDs (Video, Sep 2025).

Auswirkungen auf Sicherheit, Compliance und Datenschutz

Sicherheits-Fazit: Die in Q4 2025 eingeführten Funktionen verstärken einerseits die Sicherheit – z. B. Hero Link reduziert unkontrollierte Datenfreigaben, „Prevent screen capture“ schützt vor Screenshots[3], Entra Agent ID ermöglicht strengere Zugriffssteuerung für KI-Bots[41] – andererseits bringen sie neue Herausforderungen mit sich. Copilot-Features wie proaktive E-Mail-Vorschläge oder Planner-Agent bedeuten, dass KI umfangreich auf Inhalte zugreift und sogar Handlungen vorschlägt; Security-Teams müssen sicherstellen, dass diese KI-Zugriffe protokolliert und begrenzt sind. Microsoft hat hier bewusst Mechanismen integriert (Audit Logs, Berechtigungsgrenzen für Copilot), dennoch sollten Unternehmen Copilot-Einsatzbereiche definieren (z. B. KI nicht auf streng geheime Projekte ansetzen). Die Schutzfunktionen im M365-Stack erfüllen zunehmend regulatorische Vorgaben: Etwa die Purview DLP-Steuerung für ChatGPT und KI-Apps[11] – diese erlaubt es, personenbezogene Daten am Verlassen der Organisation via generative KI zu hindern, was ein wichtiges DSGVO- und BSI-Konformitätsfeature ist. Firmen können damit z. B. definieren, dass niemand Kundenlisten in externe KI-Chats eingeben darf (solche Eingaben würde Edge for Business blockieren). Auch Defender for Office 365 mit Safe Links in Teams[12] schließt eine Lücke: Phishing-Angriffe über Teams werden so schwerer.

Compliance-Fazit: Durch Funktionen wie SharePoint Premium (Syntex) wird Compliance erleichtert – automatisches Tagging sensibler Inhalte sorgt für bessere DSGVO-Datensatzverwaltung. Allerdings braucht es hier sorgfältige Konfiguration, damit KI-Klassifikationen zuverlässig sind. Im EU-Umfeld ist ein Schwerpunkt die Nachvollziehbarkeit von KI-Entscheidungen (EU AI Act: Transparenz). Hier hilft Entra Agent ID im Hintergrund, weil KI-Aktionen personalisiert geloggt werden[42]. Dennoch sollten Unternehmen eigene KI-Protokolle führen: Wer hat wann KI genutzt, um z. B. Mails zu beantworten? Das kann über Copilot Insights Dashboard teilweise erfolgen – Admins können Copilot-Nutzung aggregiert einsehen. Im Hinblick auf Datenschutz sind vor allem Copilot und Planner-Agent relevant, da hierbei interne (evtl. personenbezogene) Daten durch KI verarbeitet werden. Microsoft versichert vertraglich, dass keine Kundendaten zum Modelltraining verwendet werden (Commitment in Online Service Terms) – dies bleibt essenziell für DSGVO-Compliance. Unternehmen sollten das in ihrer Datenverarbeitungsdokumentation erwähnen („Verarbeitung durch Microsoft Copilot, Stand: M365, Daten bleiben im Tenantscope laut MS-DPA“). Für sensiblere Daten empfiehlt es sich, Schutzmaßnahmen zu ergreifen: z. B. durch Sensitivity Labels, die Copilot-Zugriff einschränken (derzeit können Label allerdings Copilot nicht selektiv blockieren, aber man kann Copilot auf bestimmte SharePoint-Sites nicht einsetzen falls nötig). Betriebsvereinbarungen: Falls es Vereinbarungen mit Arbeitnehmervertretungen zu Überwachung gibt – KI-Auswertungen könnten neue Diskussionspunkte sein (z. B. „KI durchsucht Mails proaktiv“ – das klingt nach möglicher Leistungskontrolle). Hier sollte klar kommuniziert werden: Copilot agiert personenbezogen und nur im Auftrag des Nutzers, kein Dritter hat Einblick. Eventuell ist es ratsam, Mitbestimmung einzubeziehen, bevor Copilot flächendeckend ausgerollt wird, um Akzeptanz und Rechtssicherheit zu erhöhen.

BSI-Empfehlungen & EU-Regulatorik: Das BSI hat Cloud-Nutzern (insb. in Behörden) bisher eher Vorsicht bei KI-Services angeraten. Mit den neuen Steuerelementen (DLP für KI, Screenshot-Schutz, hero link etc.) wird M365 allerdings “BSI-konformer“, weil Administratoren nun technische Kontrollmöglichkeiten über bisher Grauzonen (wie KI-Prompting oder Teams-Inhaltsabfluss) erhalten. Für KRITIS-Betreiber sind insbesondere die Themen Auditierung (hier glänzt Entra Agent ID – KI-Accounts sind auditierbar) und DLP (neue KI-Kontrollen in Purview) relevant; diese sollten möglichst bald getestet und in Sicherheitskonzepte übernommen werden. Der EU AI Act (Entwurf Stand Ende 2025) fordert u.a. Risikomanagementsysteme für KI – Unternehmen sollten nachweisen können, dass sie KI-Einsatz überwachen und steuern. Durch Funktionen wie Copilot Dashboard (Nutzungsstatistiken) und Entra KI-Identitäten können diese Forderungen technisch untermauert werden. Dennoch ist organisatorisch vorzubereiten: Etwa ein KI-Einsatzregister führen (wo, welche KI, Verantwortlicher) und regelmäßige Risikoanalysen (z.B. bias-check von KI-generierten Ergebnissen). Microsoft bietet hier teils Hilfestellung – z. B. Leitfäden in TechCommunity – aber die Implementierung obliegt dem Unternehmen.

Zusammengefasst steigen mit Q4 2025 die Möglichkeiten, KI sicher und compliant einzusetzen, deutlich. Wichtig ist jedoch ein aktives Wahrnehmen dieser Möglichkeiten: Administratoren sollten die neuen Policy-Optionen (z. B. CA für Agents, DLP for Edge) zügig konfigurieren, anstatt Standardwerte ungeprüft zu lassen. Und Nutzer müssen sensibilisiert werden, dass KI-Tools unter Unternehmensregeln stehen (z. B. „Du darfst keine vertraulichen Infos in ChatGPT eingeben – und jetzt erzwingt es das System sogar“). Mit der richtigen Konfiguration bieten die Neuerungen einen Mehrwert: Sie reduzieren Risiken (Datenleak, Malware, Compliance-Verstöße) bei gleichzeitig höherer Produktivität. Die Balance aus Nutzen und Schutz verschiebt sich damit positiv – eine Entwicklung, die dem Einsatz von M365 in regulierten Szenarien weiteren Vorschub leisten dürfte.

Lizenzen & Kosten: Änderungen und Auswirkungen

Copilot-Lizenzierung & Add-Ons: Die Einführung der neuen Copilot-Funktionen in Q4 2025 (Sprachsteuerung, Outlook-Copilot etc.) setzt unverändert das Microsoft 365 Copilot Add-On voraus. Preislich liegt dieser bei ca. 30 US-Dollar pro Nutzer und Monat (für E3/E5-Pläne) – eine Investition, die viele Unternehmen zunächst nur für ausgewählte Nutzer (Führungskräfte, Wissensarbeiter) tätigen. Mit dem sprunghaften Mehrwert der neuen Copilot-Funktionen könnte jedoch der Druck steigen, mehr Lizenzen bereitzustellen. Etwa könnten nun auch Vertriebsmitarbeiter vom Outlook-Copilot (autom. Mail-Entwürfe) profitieren, während zuvor vielleicht nur die Vorstandsebene lizenziert war. Unternehmen sollten daher ihre Lizenzstrategie überprüfen: Die Frage „Copilot für alle oder selektiv?“ stellt sich in Q4 2025 drängender. Microsoft selbst hat bisher keine preislichen Anpassungen oder gestaffelten Angebote für Copilot signalisiert – allerdings laufen teils Pilotprogramme mit Rabatten. Budgetär sollte man mit den bisherigen Konditionen planen. Wichtig: Copilot-Funktionen sind nicht in E5 enthalten, sondern immer ein Aufpreis. Auch KMU-Pläne (Business Standard/Premium) haben (noch) keinen Copilot-Zugang – wer Copilot-Vorteile will, muss auf Enterprise Pläne wechseln. Das ist insbesondere in Deutschland für viele Mittelständler ein großes Thema; hier gilt es, den Mehrwert klar intern zu argumentieren, um ggf. Upgrade-Kosten zu rechtfertigen („durch Copilot sparen wir X Stunden, das lohnt die 30 USD/Nutzer“).

Teams Premium & Co.: Einige der neuen High-End-Funktionen (z. B. Raumempfehlungen, Screenshot-Schutz) erfordern Teams Premium. Teams Premium ist ein Add-On (~10 USD Nutzer/Monat) das pro Nutzer, der Meetings organisiert, lizenziert werden muss. Wenn also nur das Management sehr vertrauliche Meetings hält, kann man Teams Premium auf diese Gruppe beschränken. Viele Unternehmen haben Teams Premium schon wegen Live-Übersetzung oder Meeting-Aufzeichnungen eingeführt – diese profitieren nun von zusätzlichen Features ohne Mehrkosten. Wer Teams Premium noch nicht hatte, aber z.B. den Screenshot-Schutz wünscht, muss abwägen: Ist der Business Case stark genug? In regulierten Branchen (Anwaltskanzleien, F&E) könnte man sagen: Ja, Vertraulichkeit rechtfertigt Premium-Lizenz. In der Praxis sehen wir oft, dass Premium eher gezielt für z.B. Vorstand und einige Abteilungen gekauft wird. Microsoft bietet zudem Promotions an – in H2 2025 gab es z.B. 25% Rabatt-Aktionen im ersten Jahr. Es lohnt, mit dem Lizenzpartner zu verhandeln, ob solche Rabatte für anstehende Verlängerungen genutzt werden können.

SharePoint Premium (Syntex) Kosten: SharePoint Premium hat Microsoft bis Dez 2025 als Promo mit Frei-Kontingenten ausgestattet[26][23]. Das bedeutet: Viele KI-Content-Funktionen (bis zu 100 Seiten Analyse, 50 Dokus generieren etc. pro Monat) kann man erst einmal ohne Zusatzkosten testen. Ab Januar 2026 jedoch werden voraussichtlich Verbrauchskosten fällig (Pay-as-you-go über ein Azure-Abonnement). Unternehmen sollten also die Zeit bis Jahresende nutzen, um den Bedarf zu evaluieren: Wieviele Dokumente würden wir monatlich verarbeiten? Daraus kann man Kostenprojektionen erstellen (Beispiel: 5.000 Seiten KI-Analyse/Monat -> ~5 die Freimenge -> Preise von Microsoft definieren sich evtl. in 1000er-Schritten, momentan Indikation ~75 $ pro 5k Seiten). Es gilt, Budget in IT oder Fachbereich 2026 einzuplanen für diese KI-Automatisierung. Alternativ kann man sich nach Paket-Lizenzen umschauen: Microsoft könnte Syntex/SharePoint Premium auch als festen Aufpreis pro Nutzer/Monat nach Promo anbieten (Stand jetzt aber nicht angekündigt). Wichtig: Die Abrechnung erfolgt über Azure (also Azure-Vertrag nötig) – das Licensing-Team muss sicherstellen, dass hier nichts übersehen wird und ggf. Azure Budgets/Alerts* eingestellt sind, damit die KI-Kosten nicht davonlaufen.

Entra ID P2 und Compliance-AddOns: Funktionen wie Entra Agent ID und erweiterte Identity Governance sind typischerweise an Azure AD / Entra ID P2 gekoppelt (Bestandteil von EMS E5 oder M365 E5). Unternehmen, die bisher nur E3/P1 hatten, aber von Agent ID profitieren wollen, stehen vor der Frage: Upgraden auf Entra ID P2? Hier lohnt der Blick auf das gesamte P2-Paket: Es enthält z.B. Access Reviews, Privileged Identity Management – wer diese noch nicht nutzt, könnte durch Agent ID jetzt genug Mehrwert sehen, um auf P2 hochzustufen (Kosten grob 2 € Nutzer/Monat bei Step-up von P1). Für Agent ID allein würde man es vielleicht nicht machen – aber im Paket aller Identity Governance Features schon. Ähnliches beim Compliance-Add-On (E5 Compliance): Die neuen Purview-Funktionen (KI-DLP, OCR etc.) stehen meist E5 Compliance-Kunden zur Verfügung; E3-Kunden sehen ggf. nur begrenzte Funktion. Wenn z.B. KI-DLP via Edge als „Preview E5 only“ markiert ist, muss man E5C lizenziert haben oder testweise aktivieren. Das kann bedeuten, dass regulierte Firmen vermehrt E5 Compliance einplanen müssen, um alle neuen Schutzfunktionen zu kriegen. E5 Compliance liegt preislich bei ~8 USD/Nutzer; oft ist es aber sinnvoll, gleich voll M365 E5 zu lizenzieren (man erhält dann Security + Compliance + Voice etc.).

Einsparpotenziale: Auf der positiven Seite ermöglichen manche Neuerungen auch Kosteneinsparungen bzw. Konsolidierung von Drittanbieterlösungen. Beispiel: Die Rückkehr der Multi-Signatur-Funktion in Outlook – einige Unternehmen hatten dafür externe Tools im Einsatz (z. B. Exclaimer), evtl. kann man deren Lizenzanzahl reduzieren oder auf Basisversion downgraden, wenn Outlook wieder nativ mehr kann. Ebenso könnte die Hero-Link-Einführung die Nutzung mancher DLP-Plugins vereinfachen (z.B. kein Need mehr für separate Linktracking-Tools). Planner’s neue Premium-Funktionen ersetzen teilweise Project Online oder Dritt-Planungstools – eventuell kann man dort Lizenzen abbauen, wenn Planner (mit Copilot) ausreicht. Diese Einsparungen sollte das Lizenzmanagement erfassen und gegenrechnen.

Software Assurance / Verträge: Kunden mit EA-Verträgen sollten prüfen, ob sie True-Up-Pflichten auslösen: Z.B. Copilot-addOn Zukauf oder Teams Premium Zubuch passiert oft im EA als Zusatz. Hier idealerweise im Dezember (vor Jahresende) Budget prüfen und bestellen, damit man im neuen Jahr konform ist. Möglicherweise bieten Microsoft oder Partner Bundle-Angebote an: In Vergangenheit gab es z.B. günstigeres Bundling von Teams Premium mit Viva Suite etc. Hier Augen offen halten – eventuell lässt sich z.B. Copilot mit Security-Bundle günstiger schnüren.

Empfehlung für Lizenzverantwortliche: – Szenarien priorisieren (wer braucht was) und danach stufenweise Lizenzen beschaffen statt gleich für alle. – Eng mit IT-Leitung und Fachbereichen argumentieren, wo KI- und Premium-Funktionen produktiven Mehrwert liefern (ggf. Pilot-Resultate nutzen). – Frühzeitig auf Microsoft Account Team zugehen, um eventuelle Promo- oder Testlizenzen abzugreifen (Microsoft hat 2024 sicher Interesse, Referenzkunden für Copilot zu gewinnen – ggf. gibt es dafür Incentives). – Und last but not least: Die Vertragskonditionen der neuen Services verstehen – Copilot & Premium sind Subscription ohne Kaufoption, d.h. ins langfristige IT-Budget aufnehmen. Bei Azure-Paygo (Syntex) je nach Finanzrichtlinie OPEX-Modell berücksichtigen.

In Summe werden die Neuerungen Q4 2025 voraussichtlich Mehrkosten im Lizenzbereich bedeuten – diese gehen Hand in Hand mit signifikantem Produktivitätsgewinn und Sicherheits-Upgrade, was man in internen Freigabe-Prozessen herausstellen sollte. Durch cleveres Lizenzmanagement (gestaffelter Rollout, Nutzung von Trials, Prüfen von Bündelung) lässt sich der Budgetimpact aber steuern.

Betrieb & Governance: Admin Centers, Richtlinien, Baselines, Monitoring

Admin Center-Updates: Q4 2025 bringt spürbare Veränderungen in den verschiedenen Microsoft 365 Admin Portalen. Im M365 Admin Center tauchen neue Bereiche für Copilot auf – z. B. ein Copilot-Nutzungsdashboard sowie Berichte zu aktiven KI-Agents. Admins können dort sehen, wie viele Benutzer Copilot nutzen, welche Befehle häufig sind und sogar, wie sich lizenzierte vs. unlizenzierte Nutzer verhalten. Diese Daten sind wertvoll, um den ROI von Copilot zu monitoren und Anhaltspunkte für Schulungen zu gewinnen („Welche Abteilung nutzt Copilot kaum – brauchen Nachhilfe?“). Auch das Teams Admin Center wird erweitert: Für Teams Premium Features (Screen capture Mode) gibt es neue Schalter in den Meeting Policies. Diese sind per Default aus („Disabled unless user activates in meeting“) – Admins könnten aber global vorschreiben „immer an für bestimmte Benutzer“. Hier lohnt es, die Baseline-Policies zu überarbeiten. Etwa könnte man eine benutzerbezogene Richtlinie „Top Management Meeting Policy“ einführen, in der PreventRecording und PreventScreenshot standardmäßig aktiviert sind, und diese Policy den VIPs zuweisen. Im SharePoint Admin Center muss man sich mit dem neuen „Content AI“ Setup befassen: Dort gibt es einen Bereich für Syntex/SharePoint Premium. Admins richten hier das Azure-Verbrauchsmodell ein (Verknüpfung zu einer Subscription) und definieren, welche Bibliotheken KI-Modelle nutzen dürfen. Governance-technisch sollte man hier eine schrittweise Aktivierung vornehmen – z.B. erst nur Pilot-Site Collections für Syntex zulassen und den Rest gesperrt halten, bis Policies klar sind.

Richtlinien & Baselines: Angesichts der Neuerungen sollten Unternehmen ihre M365 Governance-Baseline aktualisieren. Beispielsweise: – Freigaberichtlinie: Mit Hero Link ändert sich das Freigabeverhalten, daher Baseline anpassen: „Standard-Freigabe = Nur interne“ (so ist Hero default) und „Bei extern teilt man explizit mit bestimmten Gästen“. Ebenso kann die Policy, wann anonyme Links erlaubt sind, neu bewertet werden (ggf. noch restriktiver, da Hero-Standard so gut intern ist, dass anonyme kaum nötig). – Teams Meeting Baseline: Neu aufnehmen: „Vertrauliche Meetings – Option Bildschirmaufnahme-Schutz aktivieren“ als Vorgabe. – Conditional Access Baseline: Eventuell Agent ID mit aufnehmen (z. B. keine MFA erzwingen bei non-user logins, aber dafür Device Compliance check? Hier Baseline neu definieren: „All Agents must use certificate auth“ – kann via CA erzwungen werden). – DLP/Compliance Baseline: DLP-Policies für neue Kanäle (z. B. ChatGPT) definieren: Im Purview Portal neue Regeln aktivieren, die vordefiniert kommen („block sensitive input in Edge generative AI“). DSGVO-Baseline ergänzen: KI-Bann bei sensiblen Daten – nun technisch umgesetzt. – Informationssicherheitspolicy: Evtl. Passus zur KI-Nutzung ergänzen – z. B. „Es gilt die Unternehmensrichtlinie, dass KI-Assistenten nur unter Verwendung von genehmigten Identitäten (Agent ID) betrieben werden dürfen“ etc.

Alle diese Richtlinien sollten im IT-Governance-Gremium besprochen und formal beschlossen werden, damit man gegenüber Prüfern nachweisen kann, dass die neuen Tools unter Kontrolle sind.

Prozessanpassungen & Betrieb: Einige Admin-Vorgänge ändern sich leicht: – Signatur-Management: Der Helpdesk muss nicht mehr zig Anfragen zu fehlenden Multi-Signaturen lösen – dafür sollte er vorbereitet sein, Benutzern beim Import der alten Signaturen in neue Outlook zu helfen (z.B. Step-by-step, falls automatischer Transfer hakt). – Multi-Account-Support: Admins von Exchange müssen nun in der neuen Outlook App Fallstricke kennen (z.B. gecachte Berechtigungen, etc.). Möglicherweise steigen in Q4/2025 auch die Migrationen (neue Outlook wird Standard bis Anfang 2026) – der Betrieb muss also Transition planen (Kommunikation, GPOs umschalten, alt Outlook notfalls deinstallieren in Clients). – Monitoring & Telemetrie: Microsoft liefert vermehrt Signals an den Admin – z. B. M365 Admin Center Workload-Berichte (Copilot etc.). Das IT-Betriebsteam sollte diese proaktiv beobachten. Bsp.: Copilot Usage Report zeigt, welche Abteilungen wenig nutzen – könnte man als Indikator nehmen, dort gezielt Training anzubieten. Auch Security Monitoring: Der Entra ID Log jetzt mit Agent-Identitäten – Admins sollten SOC/SIEM Queries anpassen, damit Agent-Aktivitäten nicht als „unbekanntes Service Principal“ durchrutschen, sondern klassifiziert sind. – Updates & Change Management intern: Mit Q4 2025 nimmt die Update-Frequenz für Cloud-Services weiter zu. Admins sollten den Message Center intensiver lesen – so viele Neuerungen erfordern genaue Kenntnis der Aktivierungsmethoden (Preview vs GA, default on/off). Ein Best Practice: Ein interdisziplinäres Team (IT-Pro, InfoSec, Compliance) trifft sich monatlich, um anstehende M365 Änderungen zu sichten und die interne Reaktion zu koordinieren. Q4 2025 z.B. stünde auf Agenda: Hero Link (Auswirkungen intern?), Copilot GA Plan, etc. – Schulung der Admins: Nicht nur Enduser – auch Administratoren (Tenant Admins, Teams Admin, Compliance Officers) müssen geschult sein, die neuen Tools zu bedienen. Das Purview-Portal z.B. hat KI-gestützte DLP neu – Admins brauchen Wissen, wie man das konfiguriert (ggf. Workshops mit MS oder Partners). – Third-Party Tools: Prüfen, ob Tools von Drittanbietern mit den Neuerungen zurechtkommen. Z.B. Backup-Lösungen für M365 – können die Hero Links handle? (Backup von Berechtigungen anders?). Oder Monitoring-Tools – interpretieren die ChatGPT DLP-Blogs richtig? Ggf. Updates einspielen.

Baseline-Sicherheitskonfiguration: Viele Firmen basieren auf der M365 Security Baseline (CIS Benchmarks etc.). Diese Baselines werden sich geringfügig ändern: So wird z.B. in der Microsoft Security Baseline 2025 vermutlich empfohlen sein, „ItemsToOtherAccountsEnabled = True“ (für Outlook) auf Standard lassen oder Edge DLP zu aktivieren. Admins sollten Baseline-Dokumente von Microsoft/CIS im Blick behalten und im Q4 2025-Update die neuen Einstellmöglichkeiten einpflegen.

Governance Boards: Der M365 Governance Board sollte Q4 2025 mindestens folgende Punkte auf der Agenda haben: – Copilot Governance: Erstellen wir Guidelines für die Verwendung? (z.B. „Keine Eingabe von Klassifizierungsstufe hoch in Copilot“ – wie überwachen? Purview?). – KI-Ethik: Brauchen wir einen internen KI-Ethik-Leitfaden? (z.B. Kennzeichnung KI-generierter Inhalte in Reports?). – Zugriffsrichtlinien & Agents: Integration Agent ID in Identity Governance – Rollen überprüfen. – Datenlebenszyklus: Mit Syntex DLM-Funktionen (z.B. bypass retention deletion[45]) kann man Teams-Aufzeichnungen steuern – wer verantwortet das? Wie nutzen wir es? – Löschkonzepte: Hero Link heißt, es gibt nur einen Link – das Governance Board kann entscheiden, ob man z.B. auto-expiry von Links nun öfter aktiviert, weil handelbarer.

In Summe verlagert sich mit Q4 2025 M365-Betrieb weiter Richtung Policy-Management und Monitoring, während klassische Aufgaben (Fehlerbehebung, OnPrem-Konnektivität) noch weiter abnehmen. Der Betrieb muss dafür aber deutlich mehr Know-how in Cloud-Features aufbauen – es lohnt, Admins gezielt auf TechCommunity und MS Learn die Neuerungen nachzulesen. Auch der Austausch in der Community (z. B. Erfahrungen anderer Admins via Twitter/TechCommunity) kann helfen, Best Practices schnell zu adaptieren. Governance-technisch gilt die Devise: Automation nutzen – man sollte z.B. Security Defaults und Baselines soweit es geht per Policies as Code oder Intune Settings enforce, um Konsistenz zu wahren.

Zusammenfassend: Der M365-Betrieb in Q4 2025 wird etwas komplexer, weil neue Stellschrauben hinzukommen, aber zugleich sicherer und effizienter, wenn man diese Schrauben korrekt einstellt. Das erfordert initial etwas Fleiß (Policy-Updates, Admin-Schulungen), zahlt sich aber in reduzierten Sicherheitsvorfällen und zufriedeneren Usern aus.

Migration & Change Management: Rollout-Wellen, Kommunikation, Schulung

Rollout-Strategie: Angesichts der zahlreichen Neuerungen ist eine strukturierte Rollout-Planung in Wellen essenziell. Nicht alle Benutzer sollten mit allen Funktionen gleichzeitig konfrontiert werden – insbesondere KI-Funktionen erfordern begleitendes Change Management. Unternehmen sollten die Einführung staffeln nach z.B. Nutzergruppen oder Feature-Sets. Eine mögliche Planung: – Welle 1 (Okt 2025): Pilotgruppen aus IT und Early Adoptern erhalten Microsoft 365 Copilot (falls nicht schon in Pilot) sowie Zugang zu Teams Premium Features. Hierbei werden die Funktionen im kleinen Kreis getestet und Feedback gesammelt. Gleichzeitig kann man Hero Link im „Targeted Release“-Modus zunächst nur für einige Sites aktivieren und überprüfen, ob Prozesse (z.B. DLP-Regeln) sauber funktionieren. – Welle 2 (Nov 2025): Einführung der breiten Änderungen der Benutzeroberfläche – z. B. Umstellung auf neues Outlook (wenn organisatorisch noch nicht erfolgt). Jetzt, wo Multi-Signatur und Drag&Drop da sind, können Changemanager mit gutem Gewissen das neue Outlook als Standard ausrollen. Dies sollte begleitet werden durch intensive Kommunikation (siehe unten). Zudem könnten in Welle 2 erste Fachbereiche Copilot erhalten – z. B. der Kundenservice (profitiert von Outlook-Copilot), das Projektmanagement-Team (Planner Copilot), etc., statt gleich alle. Ebenfalls in Welle 2: Aktivierung von Screenshot-Schutz für definierte hochsensible Meetings als Pilot (z.B. Vorstandssitzung im November schon damit schützen). – Welle 3 (Dez 2025): Breiter Rollout „für alle“ von restlichen Features: Hero Link global aktiv (sobald man sicher ist, dass Nutzer informiert sind), DLP for Edge for Business auf alle Clients ausgerollt (Edge-Update über Intune gesteuert), Purview-Funktionen im Live-Betrieb (DLP-Regeln scharf schalten). Copilot ggf. weiteren Abteilungen freigeben, wenn Pilot-Ergebnisse positiv. Außerdem Q4 ideal, um in kleiner Flamme SharePoint Syntex einzuführen (Jahresend-Dokumentenaufkommen nutzen, um KI zu testen, dann in Q1 skalieren).

Wichtig ist, jede Welle mit Kommunikation und Support eng zu begleiten, sowie Erfolgsmessung zu betreiben, bevor man nächste Welle zündet.

Kommunikation & Anwenderinformation: Ein Multi-Channel-Kommunikationsansatz ist angeraten: – Ankündigungs-E-Mails: Zu Beginn jeder Rollout-Welle eine Mail vom CIO oder IT-Leiter an alle Betroffenen. Inhalt sollte sein: Was wird neu, wann, warum (Nutzenfokus), wie Unterstützung erfolgt. Z.B. „Ab 15.11. wird das neue Freigabemodell Hero Link aktiv – Dateifreigaben werden einfacher und sicherer[5]. Bitte beachten Sie die Hinweise im beigefügten OnePager…“. – Intranet & Teams Posts: Parallel Artikel im Intranet (z.B. IT-Blog) mit Bildern/GIFs der neuen Funktionen. Und Posts in wichtigen Teams-Channels (etwa „IT-Announcements“ Team). Kurze Teaser wie: „Kennen Sie schon den neuen Copilot-Sprachassistenten? Schauen Sie hier…“ – Management-Briefings: Speziell bei sicherheitsrelevanten Themen (Screenshot-Hinweis, DLP) die Führungskräfte vorab informieren, sodass diese in ihren Teams Rückfragen beantworten können. – Enduser-Guides: Erstellen Sie verständliche Kurzanleitungen („Quick Start Guides“) für die Top-Funktionen: z. B. „So nutzen Sie Copilot in Outlook effektiv – 5 Tipps“, „FAQ: Hero Link – wie teile ich jetzt Dateien?“ etc. Diese Guides per Mail verteilen und in Wissensdatenbank ablegen. – Interaktive Formate: Halten Sie optional kurze „Ask the Expert“ Sprechstunden via Teams ab, wo Benutzer in den ersten Tagen nach Umstellung Fragen loswerden können. Auch interne Community-Foren können genutzt werden (z. B. ein Yammer/Teams-Kanal „Neu in M365 Q4“). – Gamification: Evtl. kleine Adoption-Kampagnen starten: Z. B. ein Quiz im Intranet zu den neuen Features mit Gewinnspiel („Welche neue Teams-Funktion verhindert versehentliche Aufnahmen?“). Das erhöht die Beschäftigung mit dem Thema.

Schulung & Training: Die Veränderungen – vor allem Copilot – erfordern mehr als eine einmalige Info. Trainingsmaßnahmen sollten vorgesehen werden: – Kompakte Videotrainings: Viele Nutzer bevorzugen 2-5 Minuten Videos, die die Neuerung erklären. Nutzen Sie Screen Recording, um Voice Chat vorzuführen oder den Unterschied alter/neuer Freigabe zu zeigen. Stellen Sie die Videos im Learning-Management-System oder Stream-Kanal bereit. Beispiel: „Neues Outlook: Top 3 Features in 3 Minuten“. – Live-Trainings/Webinare: Organisieren Sie Workshops: etwa „Effizienter arbeiten mit Copilot – Live Demo“ (30 Min, offen für alle) und „Sicher teilen mit Hero Link“ (gezielt für Viel-Teiler wie Assistenz, Vertrieb). Diese sollten kurz nach dem Rollout stattfinden, damit Neugier genutzt wird. – Champions-Programm: Setzen Sie auf Ihre Power-User und Champions in den Abteilungen. Briefen Sie sie vorab intensiver (ggf. NDA-Sessions wenn vor genereller Verfügbarkeit) und bitten Sie, als Multiplikatoren zu wirken. Ein Champion kann z.B. im Team-Meeting 10 Min neuen Planner-Assistent zeigen – das kommt besser an als von „zentraler IT“. – Just-in-Time Hilfen: Nutzen Sie Möglichkeiten wie das „Training Lab“ in Viva Learning oder integrieren Sie Hilfetexte in Tools. Bei Outlook z.B. könnten Sie in der Mail-Signatur einen Tag lang einen Hinweis verlinken: „Wussten Sie? Sie können jetzt mehrere Signaturen verwenden – hier klicken um zu erfahren wie.“ – Pflichtschulungen falls nötig: Bei kritischen Änderungen mit Compliance-Aspekt (z. B. DLP-Edge Schutz und generative KI) könnte eine kurze verpflichtende Schulung oder Policies-Bestätigung ratsam sein. Beispielsweise einen Banner im Intranet: „Ich habe gelesen, dass ich keine vertraulichen Daten in öffentliche KI-Systeme eingeben darf“ – mit Klick protokolliert.

Change Management – Besonderheiten KI: Der KI-Einsatz (Copilot, Planner Agent) erfordert einen kulturellen Wandel. Mitarbeiter müssen lernen, KI als „Partner“ zu sehen, aber dennoch kritisch zu hinterfragen. Hier spielt Change Management eine große Rolle: – Erwartungsmanagement: Machen Sie klar, dass Copilot nicht perfekt ist, sondern Unterstützung bietet. Verhindern Sie sowohl überhöhte Erwartungen („KI macht meinen Job“) als auch Angst („KI ersetzt mich“). – Erfolge hervorheben: Teilen Sie Early Wins: z. B. „In der ersten Woche konnte unser Vertriebsteam 50 Routine-E-Mails mit Copilot beantworten, was ~5 Stunden sparte.“ Solche Erfolgsgeschichten motivieren Nachzügler. – Feedback-Schleifen: Sammeln Sie aktiv Feedback zu KI-Funktionen. Vielleicht richten Sie eine spezielle E-Mail oder Umfrage ein („Wie hilfreich war Copilot diese Woche?“). So zeigen Sie den Mitarbeitern, dass ihr Input die Weiterentwicklung steuert. – Ansprechpartner intern: Benennen Sie KI-„Enthusiasten“ in Bereichen, an die sich Kollegen wenden können bei Unsicherheiten. So entlasten Sie den formalen Support und fördern Peer Learning.

Widerstände und Change-Risiken: Mit Neuerungen kommen oft auch Skepsis und Fehler. Planen Sie ein, wie Sie mit Widerständen umgehen: – Falls Nutzer „neuen Outlook ablehnen“ (das war 2023/24 ein Thema aufgrund fehlender Features), können Sie jetzt mit gutem Grund argumentieren, dass die Blocker behoben sind. Trotzdem: Gewähren Sie in Sonderfällen eine Übergangsfrist (z.B. wer unbedingt alt Outlook braucht, bis 31.3.2026 ausnahmsweise). Der harte Schnitt kommt ja von MS am 1.4.2026[31], also haben Sie Puffer. – Fehlerfall Hero Link: Eventuell verwirren sich Nutzer, dass ihr externer Partner nicht mehr auf Datei kommt, weil intern geteilt – hier Support-FAQ klar bereit halten („Bitte nutzen Sie ‚Mit extern teilen‘ im Manage Access – Hero Link hat standardmäßig intern begrenzt.“). Solche initialen Stolperer sind normal, mit klarer Hilfestellung lösbar. – KI-Ablehnung: Manche MA (oder Betriebsräte) könnten KI misstrauen (Datenschutz, Jobangst). Hier offene Kommunikation: Erklären Sie, welche Daten wie geschützt sind (z.B. „Copilot sieht nur, wozu Sie ohnehin Zugriff haben, es werden keine Daten zur KI-Trainingscloud geschickt.“[16]). Und betonen Sie, dass KI repetitive Aufgaben erleichtert, nicht die menschliche Kreativität ersetzt. – Sicherheitsbedenken: Externe Partner oder Kunden könnten zögern, z.B. wenn sie hören, M365 nutzt KI. Hier können Sie über vertrauensbildende Maßnahmen nachdenken: Etwa in E-Mail-Footern kennzeichnen, wenn eine Antwort mit KI-Unterstützung erstellt wurde („Erstellt mit Copilot, geprüft von [Name]“), um Transparenz zu zeigen. Ist nicht zwingend nötig, aber kann bei sensiblen Geschäftsbeziehungen positiv wirken.

Erfolgsmessung (KPIs): Schon vor dem Rollout sollte festgelegt werden, wie der Erfolg des Changes gemessen wird. Mögliche Indikatoren: – Nutzeradoption: z.B. Anteil der Benutzer, die Copilot x-mal pro Woche nutzen (diese Info liefert Admin Report). Oder Anzahl Teams-Meetings, in denen Screenshot-Schutz aktiviert wurde (kann man via Graph auswerten). – Zufriedenheit: Kurze Umfragen, z.B. „Hero Link hat das Teilen erleichtert (stimme zu/neutral/lehne ab)“. Oder generelle IT-Zufriedenheitsumfrage vor/nach Rollout (erwartet, dass positive Meinung zu „M365 Tools“ steigt). – Support-Tickets: Tracken der Ticket-Anzahl zu den jeweiligen Neuerungen. Erfolg wäre z.B.: Tickets „Dateifreigabe-Probleme“ sinken um 20%, weil hero link Klarheit brachte. Oder Ticket „neues Outlook stürzt ab“ – wenn niedrig, war Rollout stabil. – Sicherheitsmetriken: z.B. Anzahl extern geteilte anonyme Links sinkt (Dank Hero Link), Anzahl erkannter DLP-Verstöße (Edge KI) – zuerst vielleicht hoch (die Regeln schlagen an), dann nach Awareness sinkend, weil Leute es erst gar nicht versuchen.

Nachbetreuung & kontinuierliche Verbesserung: Change Management hört nicht nach dem Rollout auf. Planen Sie Review-Sitzungen ~1-2 Monate nach Rollout mit Key Stakeholdern: Was läuft gut, wo nachjustieren? Gerade KI-Funktionen werden laufend verbessert – man sollte z.B. im Q1 2026 neu trainierte Copilot-Fähigkeiten wiederum bekanntmachen. Erhalten Sie das Momentum: z.B. könnte man eine „M365 Neuerungen Community“ einführen, wo quartalsweise die wichtigsten Updates (wie aus diesem Artikel) im internen Kontext diskutiert werden. Damit bleiben Anwender und Admins adaptiv – eine wichtige Eigenschaft in der Cloud-Ära.

Schließlich: Feiern Sie Erfolge! Hat z.B. die Marketingabteilung durch Copilot in Q4 eine Kampagne schneller rausgebracht? Kommunizieren Sie das mit Dank an alle, die mitgemacht haben. Positives Verstärken ist der Schlüssel, damit Change nicht als lästige Daueraufgabe empfunden wird, sondern als Chance zur ständigen Verbesserung. Mit Q4 2025 liefert Microsoft viel „Stoff“ für Verbesserungen – nutzen wir ihn mit einem guten Change Management zu unserem Vorteil.

Fazit & Empfehlung

Fazit: Das vierte Quartal 2025 markiert für Microsoft 365 einen Wendepunkt, an dem KI-gestützte Produktivität und unternehmensgerechte Kontrolle Hand in Hand gehen. Die vorgestellten Neuerungen – von Copilot-Verbesserungen über Teams Premium Features bis zu SharePoint Premium – bieten Unternehmen in Deutschland und der EU greifbare Vorteile: Effizienzgewinne in der täglichen Arbeit, stärkere Sicherheitsmechanismen und Tools, um Compliance-Anforderungen auch im Zeitalter von KI gerecht zu werden. Wichtig ist eine klare Trennung zwischen dem, was bereits offiziell auf dem Weg zur Auslieferung ist, und den plausiblen Erwartungen. Microsoft hat viele Funktionen verbindlich angekündigt (teils mit Roadmap-ID, Preview-Phasen etc.) – diese sollten Unternehmen konkret einplanen (z. B. Hero Link, Multi-Signaturen, DLP for Edge). Darüber hinaus gibt es Trends und logische Weiterentwicklungen, die sehr wahrscheinlich eintreffen (z. B. GA von Entra Agent ID oder weitere Copilot-Verfeinerungen); hier lohnt es, sich schon jetzt organisatorisch aufzustellen, auch wenn letzte Details noch folgen.

Empfehlung: Für IT-Leiter und Enterprise-Architekten heißt das: Jetzt handeln, um vorbereitet zu sein. Konkret sollten Sie: – Funktionen priorisieren: Bewerten Sie, welche der Neuerungen für Ihre Organisation den größten Mehrwert oder Dringlichkeit haben (z. B. Copilot im Kundenservice, Screenshot-Schutz im Vorstand, Hero Link für alle). Konzentrieren Sie sich auf diese zuerst. – Roadmap in Projekte gießen: Erstellen Sie interne Micro-Projekte für jede Hauptneuerung inkl. Verantwortlichen, Milestones (Pilot, Rollout, Done). Unsere Checklisten oben können als Ausgangspunkt dienen. So vermeiden Sie Aktionismus und behalten den Überblick. – Kommunikationsstrategie festlegen: Machen Sie dem Management und den Fachbereichen proaktiv klar, was kommt und warum die Veränderungen positiv sind. Nutzen Sie das Momentum, um Digitalisierung und KI-Strategie im Unternehmen voranzubringen – Microsoft liefert die Tools, aber Sie müssen den Kulturwandel begleiten. – Security & Compliance einbeziehen: Binden Sie Ihre Datenschutzbeauftragten, Betriebsräte und CISOs eng ein – zeigen Sie ihnen die neuen Kontrollmöglichkeiten (etwa DLP für KI), um Vertrauen zu schaffen. So verwandeln Sie potentielle Blocker in Unterstützer. – Partner & Schulungen nutzen: Scheuen Sie nicht, externe Hilfe hinzuzuziehen, wo Know-how fehlt. Microsoft-Partner oder MVP-Community können z.B. Workshops zu Copilot-Einführung oder Syntex-Rollout durchführen. Das ist gut investiert, da es die Lernkurve verkürzt. – Nicht alles auf einmal: Die Fülle an Neuerungen ist groß – versuchen Sie nicht, alles parallel für alle umzusetzen. Lieber iterativ in Wellen, wie im Change-Abschnitt beschrieben. So bleiben Nutzer aufnahmefähig und das IT-Team überfordert sich nicht.

Insgesamt bietet Q4 2025 die Chance, Microsoft 365 als integrierte, intelligente Arbeitsplattform auf ein neues Niveau zu heben. Unternehmen, die jetzt vorausschauend planen und mutig pilotieren, werden Anfang 2026 einen Wettbewerbsvorsprung haben – durch agilere Prozesse, besser geschützte Daten und motiviertere Mitarbeiter, denen lästige Routine abgenommen wird. Das erfordert Investitionen (Lizenz- und Change-Budget), doch der erwartbare Return on Investment – sei es in Form von Zeitersparnis, vermiedenen Sicherheitsvorfällen oder schnellerer Projektdurchführung – ist hoch.

Abschließend: Die Empfehlung lautet, die offiziell angekündigten Funktionen zeitnah zu adaptieren (sie sind reif und getestet) und die prognostizierten Trends aufmerksam zu beobachten und vorzubereiten. Planen Sie mit „Faktor Mensch“ im Mittelpunkt – Technik ist nur so gut, wie sie von den Menschen akzeptiert und eingesetzt wird. Mit einem gesunden Gleichgewicht aus Technologie, Schulung und Governance werden Sie das Q4 2025-Update von Microsoft 365 erfolgreich meistern und optimal davon profitieren.

Checkliste „Nächste Schritte“

Nachfolgend eine kompakte ToDo-Liste, um die Neuerungen aus Q4 2025 systematisch anzugehen. Priorität (P) und grober Aufwand (A) sind jeweils angegeben:

  1. Funktions-Impact-Analyse durchführen – Identifizieren Sie, welche der Neuerungen für Ihre Organisation relevant sind (Copilot, Teams, SharePoint, Security). Erstellen Sie eine interne Roadmap mit Verantwortlichen. (P: hoch, A: M)
  2. Lizenzbedarf prüfen & Budget planen – Überprüfen Sie aktuelle M365 Lizenzen (E3/E5, Add-Ons) im Hinblick auf Copilot und Teams Premium. Holen Sie bei Bedarf Angebote für Upgrades ein (evtl. Pilotrabatte nutzen). (P: hoch, A: M)
  3. Security/Compliance Team involvieren – Briefing an Datenschutz, IT-Security und ggf. Betriebsrat über kommende Funktionen (insb. KI-Einsatz, DLP). Klären Sie Fragen und holen Sie Freigaben ein. (P: hoch, A: M)
  4. Admin-Einstellungen konfigurieren – Setzen Sie wichtige Tenant-Schalter frühzeitig: z. B. Copilot Admin Settings prüfen (Websuche an/aus), Teams „Prevent screen capture“ in Meeting Policy definieren, OWA MailboxPolicy für Drag&Drop checken[8], Purview DLP-Regeln für Edge KI aktivieren[15]. (P: hoch, A: S)
  5. Pilotgruppen festlegen & starten – Wählen Sie Pilotanwender oder -teams (IT, affines Fachteam) für Copilot & neue Outlook aus. Rollen Sie dort die Funktionen aus, sammeln Sie Feedback und justieren Sie. (P: hoch, A: M)
  6. Schulungskonzept erstellen – Planen Sie Trainingsmaßnahmen (Video-Tutorials, Webinare, FAQ-Dokumente) für Endanwender zu allen relevanten Neuerungen. Beginnen Sie mit kurzen Infohäppchen schon während des Pilots. (P: hoch, A: M)
  7. Kommunikationskampagne vorbereiten – Erarbeiten Sie Ankündigungen (E-Mails, Intranet-News) pro Neuerung. Stellen Sie sicher, dass Nutzen und Änderungen klar kommuniziert werden, um Gerüchten vorzubeugen. (P: hoch, A: M)
  8. Governance-Dokumente updaten – Überarbeiten Sie Richtlinien wie Acceptable Use Policy (KI-Nutzung), Freigabe-Policy (Hero Link), Klassifizierungsvorgaben (mit Syntex möglich). Dokumentieren Sie intern die neuen Controls (wichtig für externe Audits). (P: mittel, A: M)
  9. Support-Helpdesk vorbereiten – Schulen Sie Ihr IT-Supportteam auf die Änderungen: z. B. Lösung für „Externer kann nicht mehr zugreifen“ (Hero Link-Einstellungen), „Wo finde ich meine Signaturen?“ etc. Aktualisieren Sie Wissensdatenbank und SOPs. (P: mittel, A: S)
  10. Rollout-Plan finalisieren (Wellen) – Legen Sie konkrete Termine fest, wann welche Gruppe welche Neuerung erhält. Stimmen Sie diese mit der Geschäftsleitung und den Fachbereichsverantwortlichen ab, um Ressourcen und Timing zu sichern. (P: hoch, A: S)
  11. Monitoring & KPIs einrichten – Konfigurieren Sie Berichte/Dashboards (M365 Admin, Entra Logs) für die Erfolgsmessung. Beispielsweise Copilot Usage Report tracken, DLP-Incidents im Edge, Ticketaufkommen nach Rollout. Definieren Sie Erfolgsmetriken und Alarmierungen. (P: mittel, A: S)
  12. Feedbackschleifen festlegen – Planen Sie Review-Meetings nach dem Rollout jeder Welle. Sammeln Sie Anwenderfeedback (Umfragen, Champions-Rückmeldung) und bereiten Sie ggf. Nachschulungen oder Policy-Anpassungen vor. (P: mittel, A: S)

Diese Schritte helfen, den Übergang reibungslos zu gestalten und den Mehrwert der neuen Funktionen voll auszuschöpfen. Durch Priorisierung (Hauptaugenmerk auf sicherheits- und produktkritische Punkte) und agiles Vorgehen (Pilot -> Review -> Rollout) wird das Risiko minimiert und die Akzeptanz maximiert.

FAQ – Häufige Fragen zu den Neuerungen in Q4 2025

Frage: Wann wird Microsoft 365 Copilot bei uns verfügbar sein und was kostet es genau?
Antwort: Microsoft 365 Copilot ist seit 2024 im kostenpflichtigen Early Access und wird zum Jahresende 2025 allgemein verfügbar ausgerollt. Voraussetzung ist ein Microsoft 365 E3/E5 Plan plus das Copilot-Add-On. Die Add-On-Kosten liegen derzeit bei ca. 30 USD pro Nutzer und Monat[16]. Für Enterprise-Verträge sind oft Rabatte möglich, vor allem wenn es als Suite mit Security&Compliance gebucht wird. In Q4 2025 sollten interessierte Unternehmen die Early Access Programme nutzen oder mit dem Lizenzpartner planen, ab Q1 2026 eine bestimmte Nutzerzahl auszustatten. Wichtig: Copilot kann auch testweise tenantweit aktiviert werden, allerdings ist ohne Lizenz keine Nutzung möglich. Rechnen Sie also fest mit dem Zusatzbudget – Microsoft hat angedeutet, dass der Preis in nächster Zeit stabil bleibt. Beachten Sie auch die Einführungsreihenfolge: Englischsprachige Tenants wurden zuerst bedient, deutschsprachige folgen aber zeitnah im selben Rollout-Wave.

Frage: Sind die KI-Funktionen (Copilot, Planner Agent, etc.) datenschutzkonform nutzbar – sendet Microsoft unsere Inhalte an OpenAI oder ins Ausland?
Antwort: Microsoft hat klargestellt, dass alle mit Microsoft 365 Copilot verarbeiteten Daten innerhalb der Microsoft-Cloud verbleiben und nicht zur Verbesserung der generischen KI-Modelle verwendet werden[16]. D.h. Ihre Tenant-Daten werden isoliert gehalten. Die Verarbeitung erfolgt nach aktuellem Stand in Microsoft-Rechenzentren (für EU-Kunden in EU Data Boundary, meist Dublin/Amsterdam). OpenAI als Modelllieferant erhält nur anonymisierte Prompt-Daten im Microsoft-eigenen Rechenzentrum – laut Vertrag bleibt Microsoft Datenverarbeiter. Für den DSGVO-Nachweis stellt Microsoft entsprechende DPA-Dokumente bereit. Wichtig für Compliance: Führen Sie trotzdem eine Datenschutz-Folgenabschätzung durch, um die KI-Nutzung und Schutzmaßnahmen (z. B. DLP-Regeln, Logging) zu dokumentieren. Funktionen wie der Planner Agent oder Entra Agent ID operieren völlig innerhalb Ihres Tenants – dort gelten dieselben Datenschutzprinzipien wie für andere M365-Dienste. Also ja, mit korrekter Einstellung und Dokumentation sind die KI-Features datenschutzkonform einsetzbar. Transparenz gegenüber Mitarbeitern ist ratsam (siehe Betriebsratsinformation).

Frage: Wie können wir verhindern, dass Mitarbeiter sensible Daten in ChatGPT oder Bing Chat eingeben?
Antwort: Hier kommen zwei Neuerungen ins Spiel: Zum einen die Sensibilisierung – darüber sollten Mitarbeiter bereits aufgeklärt sein (Policy, Schulungen). Technisch bietet Q4 2025 aber jetzt eine zusätzliche Sicherung: Microsoft Purview DLP für Edge for Business[11]. Damit kann der Administrator Regeln definieren, die das Eintippen vertraulicher Informationen in bestimmte Web-Apps blockieren. Microsoft liefert Vorlagen, um populäre generative KI-Websites wie ChatGPT, Google Bard etc. zu erkennen[46]. Wenn z. B. ein Nutzer versucht, einen Text mit personenbezogenen Daten dort einzufügen, löscht Edge den Inhalt und zeigt eine Warnung – so wird der Vorgang unterbunden. Diese DLP-Regel können wir tenantweit ausrollen. Zusätzlich könnten wir unsere Proxy/Firewall so konfigurieren, dass der Zugriff auf die ChatGPT-URL nur über Edge for Business erlaubt ist (damit DLP greift) – allerdings ist das oft nicht nötig, wenn alle mit geschäftlichem Account surfen, erzwingt Edge selbst den richtigen Modus. Beachten Sie: Diese Technologie greift für Web-Eingaben. Was Copilot in Teams/Outlook betrifft: Hier verhindert Microsoft, dass Daten ins unsichere Umfeld gelangen – Copilot ist ja in den M365-Grenzen. Externe KI-Tools lassen sich durch Purview DLP effektiv kontrollieren, eine starke Verbesserung gegenüber vorher.

Frage: Brauchen wir für die neue Multi-Signatur-Funktion oder Hero-Link höhere Exchange-/SharePoint-Versionen oder spezielle Updates?
Antwort: Nein, da es sich um Cloud-Funktionen handelt, wird alles serverseitig durch Microsoft aktualisiert. Die Multi-Signatur-Unterstützung erfordert lediglich, dass die Benutzer die aktuelle Version der neuen Outlook App nutzen (diese wird über Microsoft 365 Apps automatisch verteilt, Version ab v2025 Build 16.xx). Stellen Sie also sicher, dass Ihre Clients regelmäßig Office-Updates beziehen – wir als IT können das via Intune/ConfigMgr steuern. Für Hero Link genügt es, abzuwarten bis Microsoft es in unserem Tenant aktiviert (geplant Ende 2025[13]). Wir sollten dann lediglich unsere Freigaberichtlinien prüfen; die Funktion an sich braucht keinen lokalen Patch oder ähnliches. Wichtig: Falls Nutzer noch das klassische Outlook 2016/2019 nutzen, dort spielt Multi-Signatur keine Rolle (die hatten es ja schon immer). Aber Hero Links funktionieren auch dort – es könnte aber sein, dass ältere Office-Versionen bestimmte Manage-Access-Features nicht zeigen. Insgesamt ist es empfehlenswert, auf dem aktuellen Microsoft 365 App Abo zu sein. SharePoint Hero Link-Umstellung passiert transparent im Hintergrund; wir müssen nur adminseitig ggf. Parameter setzen, falls wir externe Links sperren wollen. Also kurz: Keine neuen Server – alles Teil des Cloud-Dienstes. Nur auf Clients sollte Office aktuell sein und Edge for Business (für DLP) eingesetzt werden.

Frage: Lassen sich die neuen Funktionen auch in unserer Hybridumgebung nutzen (On-Prem AD, manche User noch mit lokalen Office 2021, etc.)?
Antwort: Teils-teils. Die innovativsten Funktionen (Copilot, Teams Premium Features, Syntex KI) sind rein Cloud-basiert – die Voraussetzung ist, dass die betroffenen Benutzer Azure AD-verbunden sind und mit Cloud-Identitäten arbeiten. In Hybrid-Setups ist das meist gegeben (AD Connect synchronisiert Konten). Problematischer ist es, wenn Nutzer noch lokale Office-Installationen ohne Cloud-Anbindung haben: z. B. Outlook 2021 in Verbindung mit Exchange Online – hier werden Copilot und einige KI-Funktionen nicht zur Verfügung stehen, da sie nur in Microsoft 365 Apps (Subscription) integriert werden. Multi-Signaturen oder Drag&Drop hingegen sind Client-Funktionen: Outlook 2021 hatte Multi-Signaturen schon immer, aber Drag&Drop cross-account in dem Sinn brauchte es dort nicht neu. Hero Link funktioniert grundsätzlich, aber ältere Clients könnten vermehrt „Zugriff anfragen“ anzeigen, wenn Link-Einstellungen strikter sind – man muss ggf. dann Berechtigungen manuell vergeben. Kurz gesagt: Für volle Nutzung wird empfohlen, auf Microsoft 365 Cloud-Software zu standardisieren. Hybrid AD ist in Ordnung, aber Office-Client sollte modern sein. Teams Premium Features funktionieren auch in Hybrid, da Teams eh Cloud ist. Entra Agent ID erfordert zumindest Azure AD auf P1/P2 – wenn man reine On-Prem Service Accounts nutzt, kann man Agent ID nicht on-prem abbilden; aber man könnte analog Service-Accounts in AD anlegen, das hat aber nicht die Conditional Access Vorteile. Zusammenfassend: Die Neuerungen entfalten ihr Potenzial nur im Cloud-Umfeld. Wir empfehlen daher, verbliebene Office-Perpetual-Clients und On-Prem-Exchangekomponenten zügig abzulösen oder zu modernisieren, um mit dem Q4 2025 Feature-Set arbeiten zu können.

Frage: Werden bestehende Freigabe-Links und Gastzugriffe durch das Hero-Link-Update ungültig oder beeinflusst? Müssen wir da manuell nacharbeiten?
Antwort: Microsoft hat darauf geachtet, dass das Hero Link Rollout abwärtskompatibel ist. Bestehende Sharing-Links bleiben gültig – sie werden unter der Haube dem Hero-Link zugeordnet[13]. Für Benutzer ändert sich nur die Darstellung im „Zugriff verwalten“-Fenster: statt vieler Einträge sieht man einen mit weiter gefasster Berechtigung. Wir müssen also nicht alle Links neu generieren. Allerdings ist es sinnvoll, die neue Einfachheit zu nutzen, um etwas aufzuräumen: Man könnte z.B. nach dem Rollout mit einem Skript alle historischen „Anyone“-Links, die nicht mehr gebraucht werden, entfernen – aber das ist optional. Gast-Zugriffe bleiben ebenfalls erhalten; Gäste werden als „hinzugefügte Person“ beim Hero-Link geführt, wenn vorher ein spezifischer Gastlink existierte, wandelt es sich entsprechend. Was wir prüfen sollten: Unsere Freigaberichtlinie-Einstellungen in der SharePoint-Admin Center. Wenn dort z.B. stand „beliebige Personen-Links erlaubt“ und wir das eigentlich gar nicht mehr wollen, könnten wir nach Umstellung die Policy strenger stellen (denn Hero Link macht’s möglich, ohne anonyme Links auszukommen). Aber rein für Funktion ist kein manuelles Eingreifen nötig. Microsoft wird diesen Übergang sicher im Message Center erläutern; wir sollten den Termin abwarten, sobald es aktiv wird, vielleicht mit ausgewählten Pilot-Usern testen, aber von uns bricht nichts. Es ist also kein disruptiver Change, eher eine UI-/Verhaltensänderung. Trotzdem: informieren Sie die Anwender, damit sie nicht verwirrt sind, warum z.B. „Link kopieren“ auf einmal möglicherweise eine restriktivere Freigabe erzeugt (Standard intern, statt vorher vielleicht Standard „Jeder“ – je nach Voreinstellung, die wir hatten).

Frage: Im April 2026 wird ja das klassische Outlook deaktiviert – sind nach aktuellem Stand nun alle kritischen Funktionen im neuen Outlook vorhanden? Sollen wir jetzt umstellen?
Antwort: Mit den Updates aus Q4 2025 zieht das neue Outlook (One Outlook) endlich in nahezu allen Punkten mit dem alten gleich. Die größten Lücken – Multi-Signaturen, QuickSteps, Drag&Drop, Offline-Speicher etc. – wurden geschlossen[7][8]. Es gibt noch wenige Spezialfälle (z.B. einige spezielle Add-Ins oder S/MIME-Verschlüsselung), die teils noch in Arbeit sind, aber Microsoft hat signalisiert, bis Ende Q1 2026 alles Relevante bereitzustellen. Wir empfehlen daher, spätestens Anfang Q1 2026 auf das neue Outlook zu migrieren, idealerweise schon im Jan/Feb, um einen sicheren Puffer vor der erzwungenen Abschaltung zu haben[31]. Q4 2025 kann genutzt werden, um Pilotnutzer wechseln zu lassen und um interne Schulungen vorzubereiten – z. B. „Neues Outlook Sprechstunde“, siehe Change Management oben. Da nun keine wichtigen Gründe mehr dagegen sprechen (die klassischen Beschwerden der Beta-Phase sind ja adressiert), sollten wir proaktiv umstellen, statt den April-Stichtag abzuwarten. Die Umstellung selbst kann zentral über eine Policy oder im Office 365 Admin Center (Toggle „Neue Outlook-Erfahrung standardmäßig aktivieren“) erfolgen. Wir sollten nur vorher sicherstellen, dass wirklich alle unsere eingesetzten Add-Ins oder Integrationen kompatibel sind – das kann man mit dem Hersteller abklären oder im Test verifizieren. Summa summarum: Ja, jetzt umstellen – wir haben die lange verzögerte Multi-Signatur-Funktion nun drin, sodass Anwender kaum mehr Gegenargumente haben dürften. Der Nutzen (zukunftssicher, Performance-Verbesserungen, KI-Integration in Outlook) überwiegt jetzt eindeutig.

Frage: Was erwartet uns in naher Zukunft – gibt es schon einen Ausblick auf Q1 2026 (wichtige Ankündigungen?), worauf wir uns vorbereiten sollten?
Antwort: Ein kurzer Ausblick auf Q1 2026: Microsoft legt den Fokus weiter auf KI und Integration. Bereits angekündigt (Roadmap „Wave 2 2025/26“) sind z.B. Automatische Data Preservation für High-Risk Users im Januar 2026[47] – d.h. wenn ein Nutzer als risikoreich eingestuft (Insider Risk) wird und Daten löscht, hält Purview DLM diese automatisch zurück. Darauf sollten wir uns durch Review unserer Insider Risk Policies vorbereiten. Im März 2026 kommt (in Preview) Microsoft 365 Backup Long-Term Retention[48] – das erlaubt längere Backup-Aufbewahrung als 1 Jahr. Wenn wir M365 Backup nutzen, können wir dann für bestimmte Daten 10 Jahre einstellen – vielleicht relevant für Compliance (BSI-Archivierung). Außerdem wird im März 2026 Entra ID Conditional Access umgestellt (Retirement „Require approved client app“)[49] – hier müssen wir bis dahin auf „Require app protection policy“ umsteigen. Das ist eher Admin-Hygiene, aber wir sollten Q1 dafür nutzen, unsere Conditional Access Policies zu prüfen und ggf. umzustellen. Ein großes Thema in Q1 2026 wird „Copilot for All Apps“ sein – es wird erwartet, dass Copilot z.B. in Whiteboard, OneNote und weiteren Bereichen (Power Platform flows generieren) GA geht. Unternehmen sollten daher schon in Q1 2026 ein planvolles Ramping der Copilot-Lizenzen vornehmen, damit mehr Nutzer damit arbeiten können. Nicht zu vergessen: Preise und Verträge – Microsoft hat für einige Cloud-Services Preiserhöhungen ab 2026 angedeutet (gering, ~5% für bestimmte Pläne). Wir werden das im Januar genau wissen, aber Budgetverantwortliche sollten eine Reserve einplanen. Und natürlich: Der Zwangsumstieg auf neues Outlook am 1. April 2026[31], den Sie aber, wenn Sie unserer Empfehlung folgen, bis Februar freiwillig erledigt haben. Kurz: Q1 2026 bringt weitere Verbesserungen bei Security (Backup, CA-Policys) und den Feinschliff an KI-Features. Größere neue Produkte (wie vielleicht Viva Amplify GA oder Edge for Business Phase 2) könnten auf der Ignite 2025 (voraussichtlich Nov 2025) angekündigt werden – hier müssen wir noch abwarten und uns dann gegebenenfalls neu orientieren.

Roadmap-Ausblick Q1 2026

Schon jetzt zeichnet sich ab, dass das erste Quartal 2026 die in Q4 2025 eingeschlagene Richtung fortführt: KI-Integration vertiefen, Sicherheitsschrauben anziehen, Altlasten abbauen. Ein kurzer Ausblick auf einige Highlights der M365-Roadmap für Q1 2026 (Jan–März 2026):

  • Copilot Everywhere: Microsoft plant, Copilot auf weitere Bereiche auszudehnen. Im Januar 2026 startet z.B. Copilot in Viva (Public Preview), das in Viva Insights Mitarbeiter-Skills analysiert und Entwicklungsvorschläge macht. Auch soll Copilot in Whiteboard und OneNote verfügbar werden – etwa kann man dann in Whiteboard per Sprache komplexe Diagramme erstellen lassen. Unternehmen sollten hierauf vorbereitet sein, indem sie Copilot-Lizenzen und Richtlinien ggf. auf diese Apps ausweiten. Eintrittswahrscheinlichkeit: hoch (bereits teilweise angekündigt auf Ignite 2025).
  • Outlook Zwangsumstellung: Zum 1. April 2026 (gehört noch zu Q2, aber Vorbereitung in Q1) migriert Microsoft alle Nutzer automatisch auf das neue Outlook für Windows[31]. Bis dahin muss die Umstellung intern abgeschlossen sein. Q1 2026 wird Microsoft ggf. letzte fehlende Funktionen (z.B. S/MIME, sehr spezielle Add-In-Supports) nachliefern. Unternehmen sollten in Q1 intern das alte Outlook „abschalten“, um dem Apriltermin gelassen entgegenzusehen.
  • Security & Compliance: Im Januar 2026 kommt Automatic Data Preservation for High-Risk Users[47]: Purview wird bei als riskant eingestuften Nutzern alle gelöschten Mails/Dateien automatisch sichern (Adaptive Protection). Das erhöht die Insider-Sicherheit. Organsiations müssen dann entscheiden, ob sie diese Funktion aktivieren (Policy-Opt-In) und entsprechende Prozesse (Überprüfung der Logs) aufsetzen. Ebenfalls im Januar wird Insider Risk Management OCR eingeführt[50] – IRM erkennt dann Risiko-Inhalte in Bildern (Screenshots etc.). Man sollte also Q1 die Insider Risk Policies aktualisieren, um Bilderkennung zu berücksichtigen (ggf. mehr Storage einplanen).
  • Exchange Online Modernisierung: Im Februar 2026 steht Moderations-Workflows via Adaptive Cards an[51]. Das heißt Freigabemails (Moderation) können dann direkt in Outlook genehmigt werden (Actionable Message). Das entlastet Admins und Support, weil Moderatoren (z.B. bei verteilerlisten) effizienter arbeiten. Keine große Vorbereitung nötig, aber nach Rollout vielleicht Quick Info an Moderatoren schicken. Außerdem endet Ende Q1 2026 (März) die alte Exchange Web Services API endgültig – Admins sollten sicherstellen, dass keine Legacy-Integrationen mehr darauf basieren (ggf. sind schon umgestellt auf Graph).
  • Teams-Weiterentwicklungen: Q1 2026 wird Teams v2 (die neue Architektur) Standard für alle Plattformen sein, voraussichtlich im März mit Linux-Client und Surface Hub Updates. Ignite 2025 könnte zudem Teams 3D-Avatare GA bringen (Erwartung mittel – falls Mixed Reality Schub). Unternehmen sollten das einfach nur beobachten; ggf. Pilotnutzer fragen, ob Bedarf für Avatare besteht (für Inklusion etc.).
  • SharePoint & Loop: Für SharePoint wurde auf der Ignite 2025 eine neue „Brand Center“ Funktion als Erwartung genannt – also eine zentrale Stelle, Corporate Design (Themes, Fonts) tenantweit auszurollen. Q1 2026 könnte dieses Brand Center GA gehen (Erwartung mittel). Das würde erlauben, z.B. mit einem Klick alle SharePoint-Seiten auf neues Firmenlogo zu aktualisieren. Hier kann man sich freuen – und vielleicht schon interne CI-Verantwortliche informieren. Loop, die Komponenten-Plattform, ist seit 2023 in Public Preview – man rechnet damit, dass Loop App GA Anfang 2026 erfolgt. Unternehmen sollten bis dahin Loop-Komponenten in Teams/Outlook zulassen (oder kontrollieren via DLP). Q1 2026 wäre ein guter Zeitpunkt, Loop offiziell einzuführen – inkl. Schulung, da es doch neuartiges Arbeitskonzept ist.
  • Lizenzänderungen: Anfang 2026 läuft bei vielen EA-Verträgen die Preisfixierung aus. Microsoft hat bereits im Juli 2025 Preisanpassungen (Wechselkurs-bedingt ~10% in EU) vorgenommen – es ist nicht unwahrscheinlich, dass ab Feb 2026 neue Preise für Cloud-Services gelten. Auch könnte bis Q1 2026 geklärt sein, ob es Copilot-Bundles geben wird (z.B. ein M365 E5+Copilot Kombi zu reduziertem Preis). Lizenzmanager sollten in Q1 die Microsoft-Ankündigungen genau verfolgen und ihre Planung flexibel anpassen.

Empfehlung für Ausblick: Q1 2026 wird also die Konsolidierung von jetzt Gelerntem sein (KI in Alltag integrieren) und die letzten Migrationsschritte aus der Legacy-Welt (altes Outlook, Basic Auth etc.) abschließen. Unternehmen sollten im ersten Quartal: – Den kompletten Abschluss der Outlook-Migration vollziehen (inkl. Nachschulungen). – Die neuen Sicherheitsfeatures aktiv nutzen (Adaptive Protection für Insider etc.). – Copilot Use-Cases erweitern: Weitere Abteilungen hinzunehmen, und die Nutzung qualitativ auswerten – um ggf. in Q2 Entscheidung zu treffen, ob noch mehr Lizenzen oder Re-Fokus (falls Nutzen geringer als erwartet). – Pilotbereiche für Loop und neue Viva-Features definieren, sodass bei GA direkt losgelegt werden kann. – Und nicht zu vergessen: Q1 2026 ist planmäßig die Zeit, in der Microsoft seine „2025 Wave 2“ Release (Okt 2025–März 2026) abschließt – hierzu wird im Februar ein neues Release-Plan-Dokument erscheinen, das man studieren sollte, um Q2 2026 ff. vorzubereiten.

Die Roadmap entwickelt sich stetig – doch mit dem soliden Fundament aus Q4 2025 und dem proaktiven Vorgehen, das wir empfohlen haben, wird Ihr Unternehmen bestens gerüstet sein, um auch im nächsten Quartal und darüber hinaus die Vorteile von Microsoft 365 voll auszuschöpfen und dabei sicher und compliant zu bleiben. [14][52]

[1] [2] [16] [45] Microsoft 365 Roadmap Updates – August 14, 2025 – Planet Technologies

https://go-planet.com/in-the-know/august-14-2025/

[3] [4] [8] [10] [31] [32] [47] [48] [49] [50] [51] [52] Microsoft 365: Upcoming Changes and End-of-Support Milestones – AdminDroid Blog

https://blog.admindroid.com/microsoft-365-end-of-support-milestones/

[5] [13] [17] [18] [19] [20] Simple, Smart, and Secure: The next step in sharing files in Microsoft 365 | Microsoft Community Hub

https://techcommunity.microsoft.com/blog/onedriveblog/simple-smart-and-secure-the-next-step-in-sharing-files-in-microsoft-365/4411655

[6] [21] [22] [23] [24] [26] [27] [28] [29] [30] New promotional offer for SharePoint Premium | Microsoft Community Hub

https://techcommunity.microsoft.com/blog/sharepoint_premium_blog/new-promotional-offer-for-sharepoint-premium/4021740

[7] Why have you limited the „NEW“ OutLOOK so much? – Microsoft Q&A

https://learn.microsoft.com/en-us/answers/questions/5490901/why-have-you-limited-the-new-outlook-so-much

[9] [33] [34] [35] [36] [37] [39] What’s new in Microsoft Planner – August 2025 | Microsoft Community Hub

https://techcommunity.microsoft.com/blog/plannerblog/what%E2%80%99s-new-in-microsoft-planner-%E2%80%93-august-2025/4449301

[11] [12] [15] [46] Microsoft Roadmap, messagecenter and blogs updates from 10-09-2025 – KbWorks – SharePoint and Teams Specialist

https://kbworks.eu/microsoft-roadmap-messagecenter-and-blogs-updates-from-10-09-2025/

[14] [40] [41] [42] [43] What’s new in Microsoft Entra – June 2025 | Microsoft Community Hub

https://techcommunity.microsoft.com/blog/microsoft-entra-blog/what%E2%80%99s-new-in-microsoft-entra-%E2%80%93-june-2025/4352579

[25] Introducing SharePoint Premium – the future of AI powered content management and experiences | Microsoft Community Hub

https://techcommunity.microsoft.com/blog/sharepoint_premium_blog/introducing-sharepoint-premium-%e2%80%93-the-future-of-ai-powered-content-management-and/3981076

[38] What’s new in Microsoft Planner – July 2025

https://techcommunity.microsoft.com/blog/plannerblog/what%E2%80%99s-new-in-microsoft-planner-%E2%80%93-july-2025/4438390

[44] Key Takeaways from Microsoft Teams at Build 2025 – erik365.blog

https://erik365.blog/2025/05/22/key-takeaways-from-microsoft-teams-at-build-2025/

Consulting Startseite

 

Weitere Beiträge zum Thema Microsoft 365

 

Copilot-Agenten in der Praxis

von | Nov. 23, 2025

1. Einleitung Montagmorgen, 8 Uhr im Büro: Sie starten entspannt in den Tag, während Ihr digitaler Assistent bereits die Arbeit aufgenommen hat. Ihr persönlicher Copilot-Agent fasst die wichtigsten E-Mails übersichtlich zusammen, protokolliert das Meeting vom Freitag...

mehr lesen

Voice over IP (VoIP) Grundlagen

von | Nov. 16, 2025

Management Summary Voice over IP (VoIP) spielt in der modernen Unternehmenskommunikation eine zentrale Rolle – zunehmend auch in Form von cloudbasierten Lösungen wie Microsoft Teams. Dieser Fachartikel bietet einen praxisorientierten Leitfaden für den Einsatz von...

mehr lesen

Microsoft Teams Telefonie-Governance

von | Nov. 16, 2025

1. Management Summary Microsoft Teams Telefonie-Governance bezeichnet den Ordnungsrahmen für die Telefoniefunktion von Microsoft Teams. Sie umfasst Richtlinien, Prozesse, Rollen und Kontrollen, um den Einsatz von Teams Phone (Cloud-Telefonanlage in Teams) sicher und...

mehr lesen

Teams-Telefonie aus Sicht der .NET-Entwicklung

von | Nov. 15, 2025

Hallo und herzlich willkommen! In diesem Fachartikel nehme ich Sie mit auf eine Reise durch die Welt der Microsoft Teams-Telefonie – allerdings aus der Perspektive eines .NET-Entwicklers. Warum ausgerechnet dieser Blickwinkel? Nun, weil Telekommunikation und...

mehr lesen

Weitere Beiträge zum Thema

Voice over IP (VoIP) Grundlagen

Nov. 16, 2025 | ,

Management Summary Voice over IP (VoIP) spielt in der modernen Unternehmenskommunikation eine zentrale Rolle – zunehmend auch in Form von cloudbasierten Lösungen wie Microsoft Teams. Dieser Fachartikel bietet einen praxisorientierten Leitfaden für den Einsatz von...

mehr lesen

Microsoft Teams Telefonie-Governance

Nov. 16, 2025 | ,

1. Management Summary Microsoft Teams Telefonie-Governance bezeichnet den Ordnungsrahmen für die Telefoniefunktion von Microsoft Teams. Sie umfasst Richtlinien, Prozesse, Rollen und Kontrollen, um den Einsatz von Teams Phone (Cloud-Telefonanlage in Teams) sicher und...

mehr lesen

SharePoint Hybrid in der Praxis

Nov. 15, 2025 | ,

1. Einleitung & Management Summary Stellen Sie sich vor, Ihr Unternehmen könnte gleichzeitig die volle Kontrolle einer eigenen IT-Infrastruktur und die Vorzüge moderner Cloud-Dienste genießen. Zu schön, um wahr zu sein? Genau das verspricht SharePoint Hybrid. Als...

mehr lesen

Microsoft Teams in KRITIS-Umgebungen

Nov. 9, 2025 | ,

Management Summary Microsoft Teams kann in Kritischen Infrastrukturen (KRITIS) – etwa Energieversorgern, Gesundheitswesen, Finanzsektor oder öffentlicher Verwaltung – sicher und regelkonform eingesetzt werden, sofern bestimmte organisatorische und technische...

mehr lesen

Wissensmanagement mit SharePoint Online

Nov. 5, 2025 | ,

1. Management Summary Ein systematisches Wissensmanagement mit SharePoint Online bietet Unternehmen einen klaren geschäftlichen Mehrwert. Durch eine zentrale, gut strukturierte Wissensplattform reduzieren Sie die Suchzeit Ihrer Mitarbeiter nach Informationen...

mehr lesen

Consulting SharePoint Dokumentenmanagement

Apr. 21, 2025 |

Die Einführung eines SharePoint Dokumentenmanagementsystems (DMS) bietet Unternehmen zahlreiche Funktionen und Vorteile, die die Effizienz und Zusammenarbeit erheblich verbessern können. Als Berater mit fast 25 Jahren Erfahrung im Bereich SharePoint möchte ich Ihnen...

mehr lesen

Beratung Teams Telefonie, Herausforderungen

Apr. 18, 2025 |

Die Einführung von Telefonie mit Microsoft Teams (Microsoft Phone System) bietet zahlreiche Vorteile, kann jedoch auch einige Herausforderungen und häufige Fehler mit sich bringen. Als erfahrener Berater kann ich Unternehmen dabei unterstützen, diese Hürden zu...

mehr lesen

Consulting Teams Dokumentenmanagement

Apr. 13, 2025 |

EinführungMicrosoft Teams hat sich als zentrale Plattform für Kommunikation und Zusammenarbeit in Unternehmen etabliert. Eine der leistungsstärksten Funktionen von Teams ist das integrierte Dokumentenmanagement, das auf SharePoint-Technologie basiert. Als erfahrener...

mehr lesen

Consulting Direct Routing in Teams

Apr. 13, 2025 |

EinführungDirect Routing ist eine leistungsstarke Funktion von Microsoft Teams, die es Unternehmen ermöglicht, ihre bestehende Telefonie-Infrastruktur mit Teams zu integrieren. Als erfahrener Berater habe ich zahlreiche Projekte zur Implementierung von Direct Routing...

mehr lesen

Consulting Data Loss Prevention DLP

Apr. 13, 2025 | ,

EinführungAls erfahrener Berater im Bereich der IT-Sicherheit und Unternehmenskommunikation habe ich zahlreiche Projekte zur Implementierung von Data Loss Prevention (DLP)-Richtlinien begleitet. Diese Richtlinien sind entscheidend für den Schutz sensibler Daten und...

mehr lesen

Microsoft Teams Sicherheit verbessern

Apr. 13, 2025 |

EinführungMicrosoft Teams ist ein leistungsstarkes Tool für die Zusammenarbeit und Kommunikation in Unternehmen. Doch mit der zunehmenden Nutzung von Teams steigt auch die Notwendigkeit, die Sicherheit der Plattform zu gewährleisten. Als erfahrener Berater habe ich...

mehr lesen

Microsoft Teams Lizenzierung, Standard vs. Premium

Apr. 13, 2025 |

EinführungAls erfahrener Berater im Bereich der Unternehmenskommunikation und IT-Implementierung habe ich zahlreiche Projekte zur Einführung von Microsoft Teams begleitet. Die richtige Lizenzierung und die Nutzung der erweiterten Funktionen von Teams Premium sind...

mehr lesen

Consulting Microsoft Teams – Herausforderungen

Apr. 12, 2025 |

EinführungAls erfahrener Berater habe ich zahlreiche Projekte zur Implementierung von Microsoft Teams begleitet. Dabei bin ich auf verschiedene Herausforderungen und häufige Fehler gestoßen, die Unternehmen überwinden müssen, um die Plattform erfolgreich zu nutzen. In...

mehr lesen

Consulting Teams Telefonie

Apr. 12, 2025 |

Einführung Als erfahrener Berater im Bereich der Unternehmenskommunikation habe ich zahlreiche Projekte zur Implementierung der Telefonie mit Microsoft Teams begleitet. Diese Lösung bietet Unternehmen eine moderne, flexible und kosteneffiziente Möglichkeit, ihre...

mehr lesen

Schulung Microsoft Teams für Professionals

März 19, 2021 | ,

Idee des Microsoft Teams-KursesMicrosoft Teams ist als Client für Zusammenarbeit und Kommunikation in letzter Zeit extrem erfolgreich. Für diesen Erfolg gibt es diverse Gründe. Einer ist sicherlich, dass die Anwender sich tatsächlich eine App gewünscht haben, in der...

mehr lesen