Der entscheidende Gedanke hinter Fabric ist die Lake-zentrierte Architektur. Im Zentrum steht ein einziger, unternehmensweiter Datensee namens OneLake, in dem alle Daten offen und in einem einheitlichen Format liegen. Sämtliche Workloads – ob Data Warehouse, Notebooks für Data Engineering oder Power-BI-Berichte – greifen auf dieselben Daten in OneLake zu, ohne sie zu kopieren oder zu verschieben. Diese Idee „ein logischer See für alle“ ist der rote Faden, der Fabric von einer bloßen Werkzeugsammlung unterscheidet.
Drei Eigenschaften prägen Microsoft Fabric:
Um Fabric zu verstehen, hilft ein Blick auf die Vorgeschichte. Über Jahre bot Microsoft eine Reihe einzelner Analytics-Dienste an – etwa für Datenintegration, für ein Cloud-Data-Warehouse, für Big-Data-Verarbeitung (unter dem Namen Synapse) und für Business Intelligence mit Power BI. Diese Dienste ließen sich zwar kombinieren, mussten aber einzeln eingerichtet, verwaltet und miteinander verdrahtet werden. Fabric bündelt diese Fähigkeiten nun unter einem gemeinsamen Dach, mit einer gemeinsamen Datenbasis, einem gemeinsamen Sicherheits- und Berechtigungsmodell und einer gemeinsamen Bedienoberfläche.
Für die Praxis bedeutet das eine spürbare Vereinfachung: Statt fünf Werkzeuge zu integrieren, arbeiten die verschiedenen Rollen – Dateningenieurin, Analyst, Data Scientist, Fachanwender – im selben Portal auf denselben Daten. Der Preis dieser Bequemlichkeit ist eine engere Bindung an das Microsoft-Ökosystem. Ob dieser Tausch sinnvoll ist, hängt stark von der bestehenden IT-Landschaft und der langfristigen Datenstrategie ab – ein Punkt, auf den wir in Kapitel 06 zurückkommen.
Der zweite prägende Aspekt ist das SaaS-Modell. Anders als bei einer selbst betriebenen Datenplattform gibt es bei Fabric keine Cluster zu dimensionieren, keine virtuellen Maschinen zu warten und keine Updates einzuspielen. Sie erwerben eine Fabric-Kapazität, weisen ihr Arbeitsbereiche zu und arbeiten sofort. Das ist besonders für den Mittelstand attraktiv, der selten ein eigenes Datenplattform-Betriebsteam unterhält. Die Verantwortung verschiebt sich damit vom technischen Betrieb hin zu Governance, Datenmodellierung und Kostensteuerung – Themen, die zwar weniger sichtbar, aber nicht weniger anspruchsvoll sind.
Die eigentliche Stärke dieser Bausteine liegt in ihrem Zusammenspiel. In einer klassischen Landschaft würde jede dieser Aufgaben in einem eigenen Werkzeug erledigt, oft mit eigener Datenhaltung, eigenen Zugriffsrechten und eigenen Datenkopien. In Fabric arbeiten alle Rollen im selben Portal, auf denselben Daten in OneLake. Die Dateningenieurin lädt Daten über die Data Factory und bereitet sie im Lakehouse auf; der Analyst greift per Data Warehouse mit SQL darauf zu; der Data Scientist trainiert Modelle auf denselben Tabellen; und die Fachabteilung baut Power-BI-Berichte, die live aus OneLake lesen – ohne dass die Daten zwischen diesen Schritten kopiert werden müssen.
Diese Bündelung reduziert Reibungsverluste und Datensilos. Sie hat aber auch eine Kehrseite: Wer nur einen einzelnen Baustein benötigt – etwa ausschließlich Power BI – zahlt und verwaltet trotzdem eine Plattform, die auf das Zusammenspiel vieler Workloads ausgelegt ist. Die Frage „Brauchen wir wirklich die ganze Plattform oder nur einen Teil davon?“ ist deshalb ein wichtiger Bestandteil jeder ehrlichen Vorab-Bewertung.
Nicht jeder Workload ist gleich ausgereift oder gleich relevant für jedes Unternehmen. In der Beratungspraxis zeigt sich: Für den typischen Mittelständler stehen die Data Factory (Datenintegration), das Lakehouse beziehungsweise Data Warehouse (Datenaufbereitung und SQL-Analytik) und Power BI (Darstellung) im Vordergrund. Real-Time Intelligence und Data Science sind mächtige Erweiterungen, werden aber häufig erst in einer späteren Ausbaustufe relevant. Wir empfehlen, mit den Bausteinen zu starten, die einen konkreten Geschäftsnutzen liefern, statt von Anfang an die gesamte Bandbreite ausschöpfen zu wollen. Die Plattform wächst mit den Anforderungen – nicht umgekehrt.
OneLake ist das Herzstück von Fabric und der Grund, warum die Plattform als „Lake-zentriert“ beschrieben wird. Der Anbieter zieht gern den Vergleich zu einem bekannten Cloud-Dateispeicher: So wie ein Unternehmen einen zentralen Speicherort für Dokumente hat, soll OneLake der eine, zentrale Speicherort für alle Analysedaten sein. Jeder Fabric-Arbeitsbereich lebt automatisch in OneLake; es gibt keine separaten, voneinander getrennten Datenspeicher, die erst mühsam verbunden werden müssten.
Der praktische Nutzen liegt in der Vermeidung von Datensilos und redundanten Kopien. In gewachsenen Landschaften existiert dieselbe Kundentabelle oft in fünf verschiedenen Systemen, jeweils leicht abweichend und schwer synchronisierbar. OneLake soll dieses Muster durchbrechen: Die Daten liegen einmal, offen und für alle Workloads sichtbar. Über Shortcuts lassen sich zudem Daten aus anderen Speicherorten virtuell einbinden, sodass sie im See erscheinen, ohne physisch dorthin kopiert zu werden – ein wirksames Mittel gegen unnötige Datenbewegung.
Ein oft unterschätzter Aspekt ist die konsequente Nutzung offener Speicherformate. Fabric legt Daten in OneLake im Delta-/Parquet-Format ab – einem etablierten, offenen Standard, der auch von anderen Plattformen wie Databricks gelesen und geschrieben werden kann. Das hat eine strategische Bedeutung: Die Daten sind nicht in einem verschlossenen, proprietären Format gefangen, das nur Fabric versteht. Grundsätzlich lassen sich dieselben Daten auch mit anderen Werkzeugen bearbeiten, was das Risiko einer harten technischen Abhängigkeit verringert.
Realistisch eingeordnet mindert das offene Format zwar die technische Bindung an ein Format, hebt aber die Abhängigkeit von der Plattform als Ganzes nicht auf. Governance, Berechtigungen, Automatisierung und die eingespielten Prozesse leben weiterhin innerhalb von Fabric. Der offene Speicher ist also ein wichtiges Argument, aber kein Freifahrtschein für einen sorglosen Umgang mit dem Thema Anbieterbindung – dazu mehr in Kapitel 06.
Für Power-BI-Kenner ist Direct Lake eine der wichtigsten Neuerungen. Bislang gab es im Wesentlichen zwei Wege, wie Power BI an Daten kommt: den Import (Daten werden in das Power-BI-Modell geladen – sehr schnell, aber mit Aktualisierungsaufwand und Größengrenzen) und DirectQuery (jede Interaktion wird als Abfrage an die Datenquelle durchgereicht – stets aktuell, aber potenziell langsamer und lastintensiv). Direct Lake soll das Beste aus beiden Welten verbinden: Power BI liest die Daten direkt aus den offenen Dateien in OneLake, ohne sie vorab zu importieren und ohne jede Interaktion einzeln durchzureichen.
In der Praxis kann das Berichte liefern, die zugleich aktuell und schnell sind – ein Versprechen, das Power-BI-Teams seit langem beschäftigt. Wie bei jeder neueren Technik gilt jedoch: Der reale Nutzen hängt von der sauberen Modellierung der Daten in OneLake und vom konkreten Anwendungsfall ab. Wir empfehlen, Direct Lake in einem realistischen Szenario zu erproben und nicht blind auf Marketing-Versprechen zu vertrauen. Gut modellierte Daten bleiben auch hier die Voraussetzung für gute Ergebnisse.
Die Grundidee folgt einem Muster, das sich durch das gesamte Microsoft-Ökosystem zieht: Ein KI-Assistent wird als selbstverständlicher Teil der Arbeitsumgebung angeboten, statt als separates Werkzeug. In Fabric bedeutet das, dass KI-Unterstützung dort auftaucht, wo Menschen arbeiten – beim Aufbau von Datenpipelines, beim Schreiben von Abfragen, bei der Erstellung von Berichten. Ziel ist, die Einstiegshürde zu senken und wiederkehrende Aufgaben zu beschleunigen.
Copilot in Fabric ist ein KI-Assistent, der über die verschiedenen Workloads hinweg unterstützt. In der Data Factory kann er beim Aufbau von Datenflüssen helfen, im Data Warehouse beim Formulieren von SQL-Abfragen, im Data-Engineering-Bereich beim Schreiben von Notebook-Code und in Power BI beim Erstellen von Berichten oder beim Erläutern von Daten in natürlicher Sprache. Statt jede Abfrage von Hand zu schreiben, beschreibt der Nutzer sein Ziel in Alltagssprache, und Copilot schlägt einen ersten Entwurf vor.
Aus Beratungssicht ist Copilot ein hilfreicher Produktivitäts-Booster, insbesondere für weniger technische Nutzer und für Routineaufgaben. Er ersetzt jedoch nicht das fachliche Verständnis: Ein von der KI vorgeschlagener Bericht oder eine generierte Abfrage muss geprüft werden, denn die KI kennt weder die genaue Bedeutung Ihrer Kennzahlen noch die Feinheiten Ihrer Geschäftslogik. Wir raten dazu, Copilot als Assistenten zu begreifen, der Vorschläge macht – nicht als Autopiloten, dem man blind vertraut. Zudem ist die Verfügbarkeit von Copilot an bestimmte Kapazitäts- und Lizenzvoraussetzungen geknüpft, die vorab beim Anbieter zu prüfen sind.
Über den allgemeinen Assistenten hinaus rücken Data Agents in den Fokus. Die Idee: Fachanwender sollen in natürlicher Sprache Fragen an ihre Unternehmensdaten stellen können – etwa „Wie haben sich unsere Umsätze in der Region Süd im letzten Quartal entwickelt?“ – und eine fundierte Antwort erhalten, die auf den tatsächlichen Daten in OneLake beruht. Ein solcher Data Agent wird auf einen klar definierten Datenbereich ausgerichtet und liefert Antworten im Kontext dieser Daten.
Das ist ein vielversprechender, aber noch junger und sich schnell entwickelnder Bereich. Der Nutzen steht und fällt mit der Qualität und der klaren Modellierung der zugrunde liegenden Daten: Ein Data Agent, der auf einer chaotischen, uneinheitlich benannten Datenbasis aufsetzt, wird plausibel klingende, aber unzuverlässige Antworten liefern. Aus unserer Sicht ist die richtige Reihenfolge entscheidend – erst eine saubere, gut dokumentierte Datenbasis, dann die KI-gestützte Abfrage darauf. Wir empfehlen, Data Agents zunächst in klar abgegrenzten, überschaubaren Anwendungsfällen zu erproben und die Ergebnisse kritisch zu prüfen, bevor man sie breiter ausrollt.
Ein Aspekt, der leicht übersehen wird: KI-Funktionen sind selten kostenlos. Copilot und ähnliche Fähigkeiten verbrauchen Rechenkapazität und sind an bestimmte Kapazitäts- oder Lizenzvoraussetzungen gebunden. Wer KI-Funktionen breit einsetzt, sollte die daraus entstehenden Verbräuche von Anfang an mitdenken und beobachten. Wie sich diese in das Kapazitäts- und Kostenmodell einfügen, behandeln wir in Kapitel 09. Die konkreten Bedingungen und der Funktionsumfang entwickeln sich zudem schnell weiter – ein Blick in die aktuelle Anbieterdokumentation vor jeder verbindlichen Planung ist ratsam.
Der typische Vorteil zeigt sich im Alltag: Anmeldung und Berechtigungen laufen über dieselbe zentrale Identitätsverwaltung wie im übrigen Microsoft-Umfeld, Berichte lassen sich in Teams und andere Microsoft-365-Anwendungen einbetten, und die Datenverwaltung greift auf dieselben Governance- und Sicherheitswerkzeuge zurück, die viele Organisationen bereits im Einsatz haben. Für Anwender, die täglich mit Excel, Teams und Power BI arbeiten, wirkt Fabric weniger wie ein Fremdkörper als vielmehr wie eine Erweiterung der gewohnten Werkzeuge.
Die Integration erstreckt sich über mehrere Ebenen. Mit Microsoft 365 verbindet Fabric die Welt der Analysedaten mit der täglichen Büroarbeit: Berichte erscheinen in Teams, Erkenntnisse fließen in Präsentationen und Tabellen, und die vertraute Anmeldung senkt die Hürde für Fachanwender. Mit Azure teilt Fabric die zugrunde liegende Cloud-Infrastruktur und lässt sich mit weiteren Azure-Diensten kombinieren, etwa für spezialisierte KI- oder Datenaufgaben. Und über die Power Platform – mit Power Apps und Power Automate – lassen sich Daten aus Fabric in Anwendungen und automatisierte Abläufe einbinden, sodass aus Erkenntnissen konkrete Aktionen werden.
Diese durchgängige Integration ist der Kern des Fabric-Versprechens: nicht ein weiteres Werkzeug, das man anbinden muss, sondern ein Baustein einer bereits vorhandenen, zusammenhängenden Plattform. Für Microsoft-orientierte Organisationen ist das ein starkes, oft ausschlaggebendes Argument.
Ein wichtiger Baustein für seriöse Datenarbeit ist die Governance – also die Frage, wer welche Daten sehen darf, wie Daten klassifiziert werden und wie ihre Herkunft und Verwendung nachvollziehbar bleiben. Hier greift Fabric auf Microsofts übergreifende Governance-Werkzeuge zurück, insbesondere auf Microsoft Purview. Damit lassen sich Datenbestände katalogisieren, sensible Daten kennzeichnen und Zugriffsrichtlinien zentral verwalten – über Fabric hinaus im gesamten Microsoft-Datenraum.
Für Unternehmen mit hohen Anforderungen an Compliance und Nachvollziehbarkeit ist das ein relevanter Vorteil: Governance ist nicht ein nachträglich aufgesetztes Werkzeug, sondern in dieselbe Umgebung integriert, in der auch die Daten leben. Aus Beratungssicht ist entscheidend, diese Werkzeuge von Anfang an bewusst zu nutzen – Governance-Funktionen entfalten ihren Wert nur, wenn Rollen, Klassifizierungen und Richtlinien tatsächlich gepflegt werden, statt ungenutzt bereitzustehen.
Grob lässt sich sagen: Snowflake kommt aus der Data-Warehouse-Welt und ist besonders stark bei SQL-Analytik und Business Intelligence, mit sehr einfachem Einstieg und cloud-neutraler Ausrichtung. Databricks kommt aus der Data-Science- und Engineering-Welt (Lakehouse, Spark) und ist besonders stark bei anspruchsvollem Data Engineering und Machine Learning. Microsoft Fabric tritt als integrierte Gesamtplattform an, die viele dieser Fähigkeiten unter einem Dach bündelt und ihre entscheidende Stärke aus der tiefen Verzahnung mit dem Microsoft-Ökosystem – vor allem Power BI – zieht.
Aus unserer Beratungspraxis kristallisieren sich klare Muster heraus. Microsoft Fabric ist meist dann die naheliegende Wahl, wenn ein Unternehmen bereits stark in der Microsoft-Welt verankert ist – mit Microsoft 365, Azure und intensiver Power-BI-Nutzung –, wenn eine integrierte Lösung aus einer Hand gegenüber einer Best-of-Breed-Zusammenstellung bevorzugt wird und wenn der Wunsch besteht, Datenintegration, Aufbereitung und Berichtswesen ohne die Verdrahtung vieler Einzelwerkzeuge zu betreiben. Für Microsoft-Häuser senkt Fabric die Einstiegshürde in eine moderne Datenplattform spürbar.
Snowflake spielt seine Stärken aus, wenn eine bewusst cloud-neutrale, BI-zentrierte Data Cloud mit sehr einfachem SQL-Einstieg gewünscht ist. Databricks ist oft überlegen, wenn anspruchsvolles Data Engineering, große Streaming-Pipelines und fortgeschrittenes Machine Learning im Zentrum stehen und entsprechendes Code-Know-how vorhanden ist. Das klassische Modell aus reinem Power BI direkt auf den Quellsystemen bleibt für kleinere Szenarien sinnvoll – stößt aber an Grenzen, sobald Daten aus vielen Quellen zusammenlaufen. Wichtig: Es gibt selten ein objektiv „bestes“ System – die richtige Wahl hängt von der bestehenden IT-Landschaft, den vorhandenen Kompetenzen und der langfristigen Datenstrategie ab.
Ein besonders wichtiger Punkt bei Fabric ist die Frage der Anbieterbindung. Fabrics größter Vorteil – die tiefe Integration ins Microsoft-Ökosystem – ist zugleich seine deutlichste strategische Verpflichtung. Wer sich für Fabric entscheidet, verankert einen zentralen Teil seiner Datenarchitektur fest in der Microsoft-Welt. Das offene Speicherformat in OneLake mildert diese Bindung auf der reinen Datenebene, weil die Daten grundsätzlich auch von anderen Werkzeugen gelesen werden können. Die eingespielten Prozesse, Berechtigungen, Automatisierungen und Berichte leben jedoch innerhalb von Fabric.
Diese Abwägung ist keine, die man Fabric zum Vorwurf machen muss – jede große Plattform bringt eine gewisse Bindung mit. Entscheidend ist, sie bewusst und offenen Auges zu treffen. Wir empfehlen, die Frage „Wie stark wollen wir uns strategisch an Microsoft binden?“ zu einem festen Bestandteil der Vorab-Bewertung zu machen, statt sie erst nach der Einführung zu stellen.
Im Kern erwerben Sie bei Fabric eine Kapazität – ein Bündel an Rechen- und Verarbeitungsleistung, das über alle Workloads hinweg gemeinsam genutzt wird. Diese Kapazität steht Ihren Arbeitsbereichen zur Verfügung, unabhängig davon, ob gerade Daten geladen, Abfragen ausgeführt oder Berichte gerendert werden. Anders als bei Modellen, die jede einzelne Rechenaufgabe getrennt abrechnen, teilen sich bei Fabric alle Workloads eine gemeinsame Kapazität. Das vereinfacht die Planung, verlangt aber eine bewusste Steuerung, damit einzelne intensive Aufgaben die gemeinsame Kapazität nicht überlasten.
Die Fabric-Kapazität wird in Größenstufen angeboten – von kleinen Einheiten für erste Schritte bis zu großen Kapazitäten für unternehmensweite Nutzung. Ein wesentlicher Vorteil des SaaS-Modells ist die Möglichkeit, die Kapazität bei Bedarf zu vergrößern oder zu verkleinern und – je nach gewähltem Modell – auch zeitweise zu pausieren, etwa außerhalb der Geschäftszeiten. Damit lässt sich die bereitgestellte Leistung an den tatsächlichen Bedarf anpassen, statt dauerhaft für Spitzenlast zu zahlen.
Ein Konzept, das in diesem Zusammenhang wichtig ist, betrifft den Umgang mit Lastspitzen: Fabric erlaubt es innerhalb gewisser Grenzen, kurzfristige Verbrauchsspitzen über die nominelle Kapazität hinaus abzufedern, indem sie gegen ruhigere Zeiten verrechnet werden. Das macht den Betrieb elastischer, kann aber bei dauerhafter Überlastung zu spürbaren Einschränkungen führen. Die genauen Regeln und Grenzen dieses Verhaltens entwickeln sich weiter und sollten vor der Dimensionierung beim Anbieter geprüft werden.
Der SaaS-Charakter verändert die Rolle der IT-Abteilung grundlegend. Es gibt keine Server zu patchen, keine Cluster zu dimensionieren, keine Datenbank-Engine zu tunen. Microsoft übernimmt Betrieb, Wartung und Updates der Plattform. Was bleibt, ist die inhaltliche Verantwortung: die Anbindung der Quellsysteme, die saubere Modellierung der Daten, die Vergabe von Zugriffsrechten, die Überwachung des Kapazitätsverbrauchs und die Governance.
Aus unserer Sicht ist das für den Mittelstand eine gute Nachricht: Die anspruchsvolle Betriebsarbeit entfällt weitgehend, und die verbleibenden Aufgaben liegen näher an der eigentlichen Wertschöpfung – bei Datenqualität und Nutzen statt bei Infrastruktur. Zugleich verlangt der geteilte Kapazitäts-Charakter ein aktives Monitoring: Wenn mehrere Workloads und viele Nutzer auf dieselbe Kapazität zugreifen, muss jemand im Blick behalten, ob die Kapazität ausreicht und ob einzelne Aufgaben unverhältnismäßig viel verbrauchen. Genau hier setzt eine durchdachte Governance an.
Der typische Fabric-Kandidat im Mittelstand ist ein Unternehmen, das ohnehin tief in der Microsoft-Welt lebt: Microsoft 365 für die tägliche Büroarbeit, Azure für Teile der IT und – ganz entscheidend – Power BI als etabliertes Berichtswerkzeug. Für diese Organisationen ist die Einstiegshürde niedrig, weil vieles vertraut wirkt: dieselbe Anmeldung, dieselbe Bedienlogik, dieselben Governance-Werkzeuge. Die vorhandenen Power-BI-Kompetenzen lassen sich unmittelbar weiternutzen, und die Datenplattform fügt sich in eine bereits akzeptierte Umgebung ein, statt als weiteres Fremdsystem eingeführt werden zu müssen.
Typische Einstiegs-Use-Cases im Mittelstand sind etwa ein abteilungsübergreifendes Vertriebs- und Deckungsbeitrags-Reporting, das heute mühsam aus mehreren Systemen in Excel zusammengetragen wird; die Zusammenführung von ERP-, CRM- und Webshop-Daten zu einer einheitlichen Sicht auf den Kunden; oder ein Produktions- und Qualitäts-Dashboard, das Maschinendaten mit kaufmännischen Kennzahlen verbindet. Der Vorteil eines klar umrissenen ersten Anwendungsfalls: Er liefert schnell sichtbaren Wert, schafft Akzeptanz und hält den Aufwand überschaubar.
Aus unseren Datenprojekten hat sich ein bewährtes, schrittweises Vorgehen herausgebildet, das den Einstieg beherrschbar macht und typische Fehler vermeidet.
Auf der Kostenseite gilt: Fabric wird über die erworbene Kapazität abgerechnet, die alle Workloads gemeinsam nutzen. Der wesentliche Kostentreiber ist damit die gewählte Kapazitätsgröße, ergänzt um Speicherkosten für die in OneLake abgelegten Daten. Anders als bei rein verbrauchsbasierten Modellen zahlen Sie primär für die bereitgestellte Kapazität – was die Planung in einem Punkt vereinfacht, zugleich aber die Frage der richtigen Dimensionierung in den Vordergrund rückt. Konkrete Eurobeträge nennen wir bewusst nicht: Sie hängen von Kapazitätsgröße, Region, Vertrag und Lizenzmodell ab und ändern sich über die Zeit. Die verbindlichen Preise sind stets beim Anbieter zu prüfen.
Die gute Nachricht: Auch bei Fabric lassen sich die Kosten beherrschen, wenn man einige Hebel konsequent nutzt. Der wichtigste ist die passende Dimensionierung der Kapazität – lieber konservativ starten und bei Bedarf aufstocken. Wo das gewählte Modell es erlaubt, kann das Pausieren der Kapazität außerhalb der Geschäftszeiten spürbar sparen. Ein laufendes Monitoring des Kapazitätsverbrauchs deckt auf, welche Workloads und Nutzer wie viel verbrauchen, und macht Ausreißer sichtbar. Und schließlich senkt eine saubere Datenmodellierung mit effizienten Abfragen den Verbrauch nachhaltig. Wie bei jeder Cloud-Plattform ist Kostensteuerung keine einmalige Einstellung, sondern eine laufende Disziplin – vergleichbar mit einem bewussten Umgang mit Cloud-Ausgaben insgesamt.
Microsoft ist ein US-amerikanisches Unternehmen, und Fabric läuft auf Microsofts Cloud-Infrastruktur. Für deutsche und europäische Unternehmen wirft das berechtigte Fragen zu Datenschutz und Datenhoheit auf. Der wichtigste Hebel ist – wie bei anderen Cloud-Datenplattformen auch – die Wahl der Region: Fabric ist in mehreren Regionen innerhalb der Europäischen Union verfügbar. Wer eine EU-Region wählt, sorgt dafür, dass die Daten physisch in europäischen Rechenzentren liegen. Das ist eine notwendige Grundlage für einen DSGVO-konformen Betrieb.
Darüber hinaus bietet Microsoft mit der sogenannten EU-Datengrenze (EU Data Boundary) ein Rahmenwerk, das darauf abzielt, die Verarbeitung und Speicherung bestimmter Kundendaten weitgehend innerhalb der Europäischen Union zu halten. Das ist als DSGVO-freundlichere Option zu werten und ein wichtiges Argument für europäische Kunden. Ergänzend stellt Microsoft die üblichen vertraglichen Instrumente bereit – insbesondere einen Auftragsverarbeitungsvertrag (AVV) und Standardvertragsklauseln – sowie etablierte Zertifizierungen und Sicherheitsstandards.
Auch bei Speicherung in einer EU-Region und unter der EU-Datengrenze bleibt ein grundsätzliches Thema bestehen: Microsoft ist ein US-Mutterkonzern und unterliegt damit potenziell US-amerikanischem Recht – ein Punkt, der seit den Schrems-Urteilen und der Diskussion um den US Cloud Act kontrovers bewertet wird. Die EU-Region und die EU Data Boundary adressieren den Aspekt der Datenlokalisierung und reduzieren das Risiko erheblich, beseitigen aber nicht jedes theoretische Zugriffsrisiko, das aus der US-Konzernzugehörigkeit folgen könnte.
In der Praxis ist dieses Restrisiko für viele Mittelständler mit überschaubar sensiblen Analysedaten vertretbar – insbesondere mit EU-Region, EU Data Boundary, sauberem AVV, Verschlüsselung und einer durchdachten Datenminimierung. Für besonders schützenswerte Datenkategorien, für Berufsgeheimnisträger oder für Unternehmen mit hohen Souveränitätsanforderungen kann die Bewertung anders ausfallen. Dann sind zusätzliche Schutzmaßnahmen, eine Datenschutz-Folgenabschätzung oder – je nach Schutzbedarf – europäische bzw. souveräne Alternativen zu prüfen. Diese Abwägung ist der Kern jeder seriösen Vorab-Bewertung.
