Für viele Unternehmen begann die Arbeit mit Daten in den vergangenen Jahren als ein Flickenteppich: ein Werkzeug zum Einlesen, ein anderes zum Speichern, ein drittes zum Rechnen, ein viertes für die Berichte. Jedes dieser Werkzeuge hatte eigene Zugänge, eigene Kostenmodelle, eigene Kopien der Daten – und an jeder Schnittstelle entstand Reibung. Microsoft Fabric setzt genau hier an. Die Idee ist, die einzelnen Disziplinen der Datenverarbeitung nicht länger als getrennte Produkte, sondern als Arbeitsbereiche einer einzigen Plattform zu behandeln, die sich einen zentralen Data Lake teilen.
Das Herzstück ist OneLake, ein einziger, mandantenweiter Data Lake, in dem alle Daten liegen. Alle Fabric-Bausteine – Data Engineering, Data Factory, Data Warehouse, Real-Time Intelligence, Data Science und Power BI – greifen auf denselben Speicher zu, statt jeweils eigene Kopien anzulegen. Dieses Prinzip, in der Fabric-Welt gern als „ein Data Lake für die ganze Organisation“ beschrieben, ist der eigentliche Bruch mit der bisherigen Werkzeug-Landschaft.
Fabric verfolgt zwei zusammenhängende Versprechen. Erstens die Vereinheitlichung: Ein Datenteam arbeitet in einer Oberfläche, mit einer Rechte- und Governance-Logik, auf einem Datenbestand – unabhängig davon, ob es gerade eine Pipeline baut, ein Notebook ausführt oder einen Bericht gestaltet. Zweitens die Betriebsvereinfachung als SaaS: Microsoft übernimmt den Betrieb der Infrastruktur; Unternehmen buchen Kapazität und arbeiten, ohne Server, Cluster oder Speicherkonten selbst provisionieren und warten zu müssen. Das senkt die Einstiegshürde spürbar gegenüber einem selbst zusammengesetzten Daten-Stack.
Wichtig für die richtige Erwartung: Fabric ist keine neue Datenbank und keine neue Programmiersprache, die alles Bisherige ersetzt. Es ist eine Integrations- und Betriebsschicht, die etablierte Bausteine – Spark-basierte Verarbeitung, SQL-Analytik, Datenpipelines, Streaming-Analysen, maschinelles Lernen und Business Intelligence – unter einem Dach zusammenführt und miteinander verbindet. Wer diese Bausteine bereits kennt, findet sie in Fabric wieder, nur eben vereinheitlicht.
Fabric richtet sich an Organisationen, die mit Daten mehr tun wollen, als einzelne Berichte zu erstellen: Häuser, die Daten aus mehreren Quellsystemen zusammenführen, aufbereiten und für Analysen, Dashboards oder erste KI-Anwendungen nutzbar machen möchten. Im Mittelstand sind das typischerweise die datenintensiveren, größeren Unternehmen – etwa mit einem gewachsenen ERP, mehreren Fachanwendungen und dem Wunsch nach einer verlässlichen, gemeinsamen Datenbasis. Für sehr kleine Häuser mit überschaubarem Datenbedarf ist Fabric in vollem Umfang oft überdimensioniert; hier reicht anfangs meist Power BI allein. Auf diese Realismus-Frage kommen wir in Kapitel 07 ausführlich zurück.
Ein zweiter Blickwinkel hilft beim Einordnen: Fabric adressiert nicht nur das technische Datenteam, sondern ausdrücklich auch die Fachbereiche. Weil Power BI als vertrautes Berichtswerkzeug Teil der Plattform ist und weil die Copilot-Funktionen viele Aufgaben sprachlich zugänglich machen, sollen auch Anwender ohne tiefe Data-Engineering-Kenntnisse mit den Daten arbeiten können. In unserer Beratungspraxis sehen wir darin eine Chance und eine Verantwortung zugleich: Die niedrigere Hürde beschleunigt die Verbreitung datengetriebener Arbeit, verlangt aber zugleich eine klare Governance, damit die zentral gehaltenen Daten nicht unkontrolliert breiter zugänglich werden, als es der Schutzbedarf erlaubt.
Die eigentliche Neuerung von Fabric liegt weniger in den einzelnen Fähigkeiten als in ihrer Zusammenführung. Wer früher eine Datenpipeline, ein Data Warehouse, einen Spark-Cluster und ein BI-Werkzeug betreiben wollte, musste mehrere Azure-Ressourcen einrichten, verbinden, absichern und überwachen. In Fabric sind diese Fähigkeiten Bausteine derselben Plattform: Sie teilen sich Speicher, Zugriff, Verwaltung und Abrechnung. Aus vielen Einzelentscheidungen wird eine Plattformentscheidung.
Power BI ist für viele der vertrauteste Zugang zu Fabric. Power BI ist heute Teil von Fabric und zugleich der Baustein, den die meisten Unternehmen ohnehin schon kennen und nutzen. Wer Power BI im Einsatz hat, arbeitet faktisch bereits in der Fabric-Welt – die weiteren Bausteine lassen sich später hinzuschalten, ohne die Plattform zu wechseln. Diese Kontinuität ist strategisch bedeutsam: Der Einstieg in Fabric muss kein Sprung ins Unbekannte sein, sondern kann eine Erweiterung des Vertrauten sein.
Gegenüber dem klassischen Azure Synapse Analytics positioniert Microsoft Fabric als die modernere, stärker vereinheitlichte und als SaaS betriebene Weiterentwicklung des Analytik-Gedankens. Wo Synapse einzelne Analytik-Komponenten in Azure zusammenführte, geht Fabric einen Schritt weiter in Richtung eines geschlossenen, verwalteten Produkts mit OneLake als gemeinsamer Grundlage. Für neue Vorhaben empfiehlt Microsoft in der Regel Fabric; bestehende Synapse-Landschaften bleiben davon zunächst unberührt und können schrittweise betrachtet werden. Eine pauschale Migrationspflicht gibt es nicht – die Entscheidung ist immer eine Einzelfallabwägung.
Im Verhältnis zu Azure insgesamt gilt: Fabric ist kein Ersatz für die Azure-Plattform, sondern ein SaaS-Angebot, das auf Azure-Technologie aufsetzt und Datendienste bündelt, die man zuvor als einzelne Azure-Ressourcen betrieben hätte. Für Häuser, die tiefe, individuelle Kontrolle über einzelne Infrastruktur-Komponenten benötigen, bleiben die granularen Azure-Dienste relevant. Für Häuser, die vor allem eine funktionierende, integrierte Datenplattform ohne hohen Betriebsaufwand wollen, ist Fabric der bequemere Weg.
Die Bündelung hat eine tiefere Wirkung als reine Bequemlichkeit. Weil alle Bausteine denselben Data Lake teilen, entfällt ein großer Teil der Datenkopiererei und der Synchronisationsprobleme, die klassische, aus Einzeldiensten zusammengesetzte Architekturen plagen. Daten müssen nicht mehr zwischen einem Data Lake, einem Warehouse und einem BI-Modell hin- und herbewegt werden, sondern liegen an einem Ort und werden von den verschiedenen Werkzeugen unterschiedlich betrachtet. Das reduziert Fehlerquellen, Verzögerungen und Governance-Lücken – und es ist der eigentliche Grund, warum Fabric für datenintensive Häuser attraktiv sein kann.
Alles in Fabric ruht auf OneLake. Der Name ist Programm: Statt vieler kleiner Data Lakes und Speicherkonten gibt es einen zentralen Lake für die gesamte Organisation. Daten werden dort in offenen Formaten abgelegt, sodass die verschiedenen Bausteine – SQL-Warehouse, Spark-Engine, BI-Modell – auf denselben Bestand zugreifen, jeder mit seiner eigenen Betrachtungsweise. Das Lakehouse verbindet dabei zwei Welten: die Offenheit und Flexibilität eines Data Lake mit der geordneten, tabellarischen Struktur eines Warehouse. Für Datenteams bedeutet das, dass sie rohe und aufbereitete Daten am selben Ort halten und schrittweise veredeln können, ohne die Plattform zu wechseln.
Der praktische Nutzen zeigt sich im Alltag: Eine Datenaufbereitung, die im Data Engineering per Notebook läuft, schreibt ihr Ergebnis nach OneLake; das Data Warehouse liest dieselben Daten per SQL; Power BI baut darauf seinen Bericht – ohne dass die Daten je kopiert werden mussten. Diese Durchgängigkeit ist der Kern des Fabric-Versprechens.
In der Praxis fügen sich die Bausteine zu einer durchgehenden Kette. Data Factory holt die Daten aus den Quellsystemen – ERP, CRM, Fachanwendungen, Dateien – und legt sie in OneLake ab. Data Engineering bereitet sie mit Spark auf: bereinigen, zusammenführen, veredeln. Das Data Warehouse stellt die strukturierten Ergebnisse für SQL-Analytik bereit. Real-Time Intelligence ergänzt die Sicht auf laufende, zeitkritische Ereignisdaten. Data Science baut auf demselben Bestand Modelle für Vorhersagen. Und Power BI macht das Ergebnis für Fachbereiche in Berichten und Dashboards sichtbar. Kein Haus muss diese Kette komplett nutzen – aber wer sie braucht, findet sie in einer Plattform.
Fabric bringt Copilot-Funktionen mit, die in mehreren Bausteinen unterstützen: Sie helfen etwa dabei, Datenpipelines und Transformationen zu erstellen, Abfragen zu formulieren, Code in Notebooks zu entwerfen oder Power-BI-Berichte per natürlicher Sprache zu gestalten. Der Copilot senkt die Einstiegshürde und beschleunigt wiederkehrende Aufgaben. Wie bei jeder KI-Unterstützung gilt: Er beschleunigt das Arbeiten, ersetzt aber nicht das fachliche Verständnis von Datenmodellen und Prozessen. Für die datenschutzrechtliche Bewertung der Copilot-Nutzung verweisen wir auf Kapitel 09.
Der Kern des Modells ist einfach zu erklären: Ein Unternehmen bucht Rechenkapazität für Fabric, und alle Bausteine – Data Engineering, Warehouse, Real-Time Intelligence, Data Science, Power BI – teilen sich diese gemeinsame Kapazität. Statt für jeden Dienst eine eigene Rechnung zu führen, gibt es einen gemeinsamen Kapazitätstopf, aus dem sich die Workloads bedienen. Diese Kapazität wird in abgestuften Größen angeboten, deren Umfang mit dem Bedarf skaliert – vom kleinen Einstieg bis zur großen, unternehmensweiten Nutzung.
Microsoft bietet die Kapazität in gestaffelten Ausbaustufen an, im Fabric-Sprachgebrauch als Kapazitäts-Einheiten oder SKUs bezeichnet. Der Grundgedanke: Man wählt eine Kapazitätsgröße, die zum erwarteten Arbeitsvolumen passt, und kann sie später anpassen. Kleinere Stufen eignen sich für erste Vorhaben und moderate Datenmengen, größere Stufen für intensive, unternehmensweite Nutzung mit vielen parallelen Workloads. Ein wesentlicher Vorteil des Kapazitätsmodells ist die Flexibilität: Die Kapazität lässt sich in vielen Fällen bedarfsgerecht hoch- und herunterskalieren und – je nach Vereinbarung – auch pausieren, wenn sie nicht gebraucht wird. Konkrete Größen, Bezeichnungen und deren genaue Leistungswerte ändern sich und sollten stets aktuell geprüft werden; wir nennen hier bewusst keine Zahlen.
Für die Praxis wichtig ist das Zusammenspiel mit Power BI: Da Power BI Teil von Fabric ist, kann eine Fabric-Kapazität auch die Power-BI-Nutzung tragen. Wer bereits Power BI im Einsatz hat, findet sich in dieser Logik schnell zurecht, weil Power BI schon länger ein kapazitätsbasiertes Modell (neben der reinen Nutzerlizenzierung) kennt.
Für die ersten Schritte bietet Microsoft eine Testphase (Trial) an, mit der sich Fabric ohne sofortige Kapazitätsbuchung ausprobieren lässt. Das ist der empfohlene Weg, um die Plattform kennenzulernen, einen ersten Anwendungsfall zu bauen und ein Gefühl für den eigenen Kapazitätsbedarf zu bekommen, bevor eine kostenpflichtige Kapazität gebucht wird. Der Umfang und die Bedingungen einer solchen Testphase ändern sich; sie sollten vor dem Start aktuell geprüft werden. In unserer Beratungspraxis empfehlen wir, die Testphase gezielt für einen klar abgegrenzten Pilot-Anwendungsfall zu nutzen, statt planlos zu experimentieren – so entsteht schnell belastbare Erfahrung für die spätere Kapazitätsentscheidung.
Fabric spielt seine Stärke am deutlichsten aus, wenn Microsoft 365 und Power BI ohnehin die Arbeitsumgebung sind. Die Integration in Power BI, die gemeinsame Governance über Microsoft-Werkzeuge und der geringe Betriebsaufwand als SaaS machen den Einstieg für solche Häuser besonders reibungsarm. Wer eine vereinheitlichte Plattform will, ohne einen eigenen Data-Engineering-Betrieb aufbauen zu müssen, und wer den Wert vor allem in durchgängiger Analytik und Berichtswesen sieht, findet in Fabric einen bequemen Weg. Auch die Fähigkeit, klein über Power BI zu starten und die weiteren Bausteine später hinzuzuschalten, ist ein echter Vorteil gegenüber Plattformen, die einen technischeren Einstieg verlangen.
Ebenso ehrlich gehört die Gegenseite benannt. Databricks ist oft die reifere Wahl für Häuser mit anspruchsvollen Data-Science- und KI-Vorhaben, mit einem starken Data-Engineering-Team und dem Wunsch nach Multi-Cloud-Neutralität. Snowflake überzeugt dort, wo ein leistungsfähiges, herstellerneutrales Cloud Data Warehouse im Zentrum steht und die Bindung an ein einzelnes Ökosystem vermieden werden soll. Das klassische Azure Synapse bleibt für bestehende Landschaften relevant, in denen eine Umstellung auf Fabric keinen unmittelbaren Mehrwert bringt. Und Google BigQuery ist die natürliche Wahl für Häuser, die ohnehin in der Google-Cloud-Welt zu Hause sind. Die nüchterne Konsequenz: Fabric gewinnt aus der Logik eines Microsoft-nahen Stacks heraus – nicht, weil es in jeder einzelnen Disziplin führend wäre. Wer keinen Microsoft-Bezug hat, sollte die Plattform-Wahl bewusst und neutral treffen.
Der Zugang zu Fabric läuft über den Microsoft-Mandanten – dieselbe Identitäts- und Verwaltungsbasis wie bei Microsoft 365 und Power BI. Wer eine gebuchte Fabric-Kapazität hat, aktiviert damit die Plattform für die Organisation. Innerhalb dieser Kapazität organisiert sich die Arbeit in Workspaces: abgegrenzten Arbeitsbereichen, in denen Teams ihre Lakehouses, Warehouses, Pipelines, Notebooks und Berichte ablegen und gemeinsam bearbeiten. Workspaces sind das zentrale Ordnungsprinzip – sie strukturieren, wer an welchen Daten und Artefakten arbeitet, und sie sind die natürliche Einheit für Zugriffsrechte.
Die bewusste Gestaltung von Workspaces ist eine der wichtigsten Betriebsentscheidungen. In der Praxis trennt man üblicherweise nach Zweck – etwa Entwicklung, Test und Produktion – und nach Verantwortungsbereich, sodass jedes Team oder jede Fachdomäne einen klar zugeordneten Bereich hat. Diese Trennung verhindert, dass experimentelle Arbeit versehentlich produktive Berichte beeinflusst, und sie macht Verantwortlichkeiten sichtbar. Wer Workspaces von Anfang an mit klaren Konventionen für Benennung, Eigentümerschaft und Berechtigung aufsetzt, erspart sich später aufwendiges Aufräumen.
Da alle Workspaces auf denselben OneLake zugreifen, entsteht zugleich eine Chance und ein Risiko. Die Chance: Daten müssen nicht dupliziert werden, sondern lassen sich – kontrolliert – teilen und wiederverwenden. Das Risiko: Ohne klare Rechte- und Freigabestruktur können Daten breiter zugänglich werden, als beabsichtigt. Genau deshalb ist Governance bei einer zentralen Datenhaltung besonders wichtig.
Für Governance über Fabric hinweg ist die Anbindung an Microsoft Purview relevant. Purview ist Microsofts Werkzeug-Familie für Data Governance, Datenkatalogisierung, Klassifizierung und Compliance. In Verbindung mit Fabric hilft es dabei, den Überblick über die im OneLake liegenden Daten zu behalten: welche Daten es gibt, woher sie stammen, wie sensibel sie sind und wer darauf zugreifen darf. Für Häuser, die schützenswerte oder personenbezogene Daten verarbeiten, ist eine solche Governance-Schicht keine Kür, sondern die Voraussetzung für einen verantwortbaren Betrieb – gerade weil Fabric per Konstruktion viele Daten an einem Ort konzentriert.
In unserer Beratungspraxis empfehlen wir, Governance nicht als nachträgliche Übung zu behandeln, sondern von Beginn an mitzudenken: Wer definiert, welche Daten in OneLake landen? Wie werden sie klassifiziert? Wer darf welchen Workspace nutzen? Wie wird der Zugriff auf sensible Daten kontrolliert und protokolliert? Diese Fragen zu beantworten, bevor Fabric wächst, ist deutlich einfacher, als eine gewachsene, unkontrollierte Landschaft nachträglich zu ordnen.
Ehrlich betrachtet ist Fabric in vollem Umfang eher etwas für datenintensive und größere Mittelständler – Häuser, die genug Daten, genug Quellen und genug analytischen Bedarf haben, damit sich eine vereinheitlichte Plattform lohnt. Typische Merkmale sind ein gewachsenes ERP, mehrere Fachanwendungen, der Wunsch nach unternehmensweiter Analytik über Abteilungsgrenzen hinweg und erste Ambitionen in Richtung datengetriebener Entscheidungen oder KI. Für solche Häuser kann Fabric die zersplitterte Datenlandschaft ordnen und den Betriebsaufwand senken.
Für kleinere Häuser mit überschaubarem Datenbedarf ist die volle Fabric-Plattform hingegen oft überdimensioniert. Wer im Wesentlichen einige Berichte aus wenigen Quellen erstellen möchte, ist mit Power BI allein meist besser und günstiger bedient. Fabric zahlt sich dort aus, wo Datenmenge, Quellenvielfalt und analytischer Anspruch über das hinausgehen, was ein reines Berichtswerkzeug leisten kann. Diese Unterscheidung offen anzusprechen, gehört zu einer ehrlichen Beratung – nicht jede Plattform-Fähigkeit ist für jedes Haus ein Gewinn.
Der von uns empfohlene Weg ist evolutionär. Erstens: bei Power BI bleiben und dessen Nutzung konsolidieren – das ist der Ankerpunkt, den fast jedes Haus schon kennt. Zweitens: einen klar abgegrenzten Anwendungsfall identifizieren, bei dem eine gemeinsame Datenbasis oder eine anspruchsvollere Aufbereitung echten Mehrwert bringt. Drittens: diesen Anwendungsfall in der Testphase oder mit einer kleinen Kapazität pilotieren und Erfahrung sammeln. Viertens: erst danach, mit belastbarer Erfahrung, über einen breiteren Ausbau und die passende Kapazität entscheiden. So entsteht Wert schrittweise, ohne sich früh in eine große Kapazitäts- und Betriebsentscheidung zu verrennen.
Die zentrale Botschaft zuerst: Die Fabric-Kosten hängen vor allem an der gebuchten Kapazität, nicht an der Zahl der genutzten Bausteine. Man zahlt für einen gemeinsamen Kapazitätstopf, aus dem sich alle Workloads bedienen. Das hat einen angenehmen Nebeneffekt – man muss nicht für jeden Dienst separat kalkulieren – aber auch eine Konsequenz: Die passende Kapazitätsgröße zu wählen und sie im Betrieb sinnvoll zu steuern, ist der entscheidende Kostenhebel. Zu klein gewählt, stößt man an Grenzen; zu groß gewählt oder dauerhaft ungenutzt laufen gelassen, zahlt man für Reserve, die man nicht braucht.
Weil sich alle Workloads eine gemeinsame Kapazität teilen, entsteht eine neue Disziplin: das bewusste Steuern der Auslastung. Die Fähigkeit, Kapazität bei Bedarf hoch- und herunterzuskalieren und – je nach Modell – in Ruhezeiten zu pausieren, ist ein wichtiger Kostenvorteil, den man aktiv nutzen sollte. Eine Kapazität, die rund um die Uhr läuft, obwohl sie nur zu Geschäftszeiten gebraucht wird, verursacht vermeidbare Kosten. Ebenso lohnt es sich, den Kapazitätsbedarf regelmäßig zu überprüfen und an die tatsächliche Nutzung anzupassen, statt einmal groß zu buchen und nie wieder hinzuschauen.
Hinzu kommen weitere Kostendimensionen, die in eine ehrliche Gesamtrechnung gehören: der Speicher in OneLake, der mit der Datenmenge wächst; die Power-BI-Nutzung, die je nach Modell über Nutzerlizenzen oder über die Kapazität abgedeckt wird; sowie – nicht zu unterschätzen – der Betriebs-, Governance- und Personalaufwand. Eine Datenplattform ist mit der Buchung nicht fertig; sie muss betrieben, gepflegt und regiert werden. Diese Total-Cost-of-Ownership über die reine Kapazitätsrechnung hinaus zu betrachten, ist für eine belastbare Entscheidung unverzichtbar.
Für die Planung heißt das konkret: Beginnen Sie mit der Testphase oder einer kleinen Kapazität, sammeln Sie mit einem realen Anwendungsfall Erfahrung über den tatsächlichen Verbrauch, und leiten Sie daraus die dauerhaft passende Kapazität ab. Prüfen Sie die konkreten, aktuellen Preise stets im offiziellen Microsoft-Preisrechner, da sich Kapazitätsgrößen, Bezeichnungen und Konditionen ändern. Wir nennen in diesem Beitrag bewusst keine Zahlen, weil jede genannte Zahl schnell veraltet wäre und zu falschen Erwartungen führen könnte. Die verlässliche Aussage lautet: planbar, aber steuerungsbedürftig.
Ein häufiges Missverständnis, dem wir in Gesprächen begegnen, ist die Erwartung, Fabric sei entweder günstig, weil Power BI bereits vorhanden ist, oder unweigerlich teuer, weil es eine große Plattform ist. Beide Pauschalurteile führen in die Irre. Die tatsächlichen Kosten hängen davon ab, wie intensiv die Plattform genutzt wird, wie diszipliniert die Kapazität gesteuert wird und wie viele Bausteine über das reine Berichtswesen hinaus zum Einsatz kommen. Ein Haus, das Fabric bewusst und mit einem klar umrissenen Anwendungsfall betreibt, kann die Kosten gut im Griff behalten; ein Haus, das ohne Steuerung und ohne Governance wachsen lässt, riskiert vermeidbare Ausgaben. Deshalb gehört zu jeder Fabric-Einführung von Anfang an ein einfaches Kostenmonitoring, das die Auslastung sichtbar macht und frühe Nachjustierung erlaubt.
Der größte datenschutzrechtliche Aspekt von Fabric ergibt sich aus seinem Konstruktionsprinzip: Weil OneLake Daten aus vielen Quellen an einem zentralen Ort zusammenführt, entsteht eine hohe Konzentration schützenswerter Daten. Was einerseits der Sinn der Plattform ist – eine gemeinsame Datenbasis –, erhöht andererseits die Anforderungen an Zugriffskontrolle, Klassifizierung und Nachvollziehbarkeit. Je mehr sensible Daten an einem Ort liegen, desto wichtiger wird eine sorgfältige Governance, damit nicht mehr Menschen Zugriff erhalten, als erforderlich, und damit der Umgang mit personenbezogenen Daten den Grundsätzen der DSGVO entspricht.
Fabric lässt sich so betreiben, dass die zugrunde liegende Kapazitätsregion in der EU liegt und Daten in europäischen Rechenzentren verbleiben. Das ist ein wichtiger und richtiger Schritt für Datenhoheit und ein häufiger Ausgangspunkt europäischer Datenschutz-Überlegungen. Zugleich muss klar gesagt werden: Microsoft ist ein US-Konzern und unterliegt damit dem US Cloud Act. Die Wahl einer EU-Region beziehungsweise EU-Kapazitätsregion reduziert das Risiko eines Zugriffs, beseitigt es aber nicht vollständig. Ein Restrisiko bleibt, weil ein US-Unternehmen grundsätzlich unter US-amerikanische Herausgabepflichten fallen kann. Diese Realität gehört ehrlich benannt und in die Risikobetrachtung einbezogen – sie ist kein Grund gegen Fabric, aber ein Faktor in der Abwägung.
Für die Auftragsverarbeitung steht Microsofts Auftragsverarbeitungsvertrag (AVV) zur Verfügung, der die vertragliche Grundlage für die Verarbeitung personenbezogener Daten bildet. Wer Fabric für personenbezogene Daten nutzt, sollte den AVV mit Microsoft abschließen und die darin geregelten Pflichten und Zusagen kennen. Für Häuser, die Microsoft ohnehin als Auftragsverarbeiter im Einsatz haben, erweitert sich damit eine bekannte Vertragsbasis, statt dass eine völlig neue geprüft werden müsste.
Zur Nutzung der Copilot-Funktionen in Fabric gilt nach Microsofts eigener Zusage, dass die dabei verarbeiteten Kundendaten nicht zum Training der zugrunde liegenden Modelle verwendet werden. Diese Aussage ist ausdrücklich als Zusage des Herstellers zu verstehen und sollte im konkreten Fall anhand der aktuellen, verbindlichen Microsoft-Dokumente und Vertragsunterlagen überprüft werden – Zusagen und Bedingungen können sich ändern. Sie ersetzt keine eigene datenschutzrechtliche Prüfung, gibt aber eine wichtige Orientierung für die Bewertung der KI-Funktionen.
Die praktische Konsequenz aus all dem: Datenhoheit bei Fabric ist gestaltbar, aber sie ist Arbeit. Sie entsteht aus der bewussten Wahl der EU-Kapazitätsregion, dem abgeschlossenen AVV, einer sauberen Governance über Purview, einer restriktiven Zugriffssteuerung auf die zentral gehaltenen Daten und einer klaren Klassifizierung sensibler Bestände. Wir empfehlen ausdrücklich, die Datenschutz- und Rechtsfunktion des Unternehmens einzubeziehen, bevor personenbezogene oder besonders schützenswerte Daten in OneLake zusammengeführt werden. Die konkrete Bewertung hängt vom Einzelfall ab. Dies ist eine fachliche Einordnung und keine Rechtsberatung.
