Project Osmos in Microsoft Fabric: Autonomes Data Engineering sicher einsetzen

Mit Project Osmos erweitert Microsoft Fabric die Möglichkeiten von KI-Agenten um eine neue Dimension: Statt nur Fragen zu Daten zu beantworten oder Programmcode vorzuschlagen, können Agenten vollständige Data-Engineering-Aufgaben planen, ausführen und ihre Ergebnisse überprüfen. Das eröffnet neue Wege für die Automatisierung komplexer Datenprojekte. Gleichzeitig entstehen neue Anforderungen an Berechtigungen, Datenintegrität und Governance. Wir zeigen, wie Project Osmos funktioniert, wo die Grenzen der Preview liegen und wie Unternehmen einen kontrollierten Pilot aufbauen können.

Was ist Project Osmos in Microsoft Fabric?

Project Osmos ist eine autonome Data-Engineering-Funktion in Microsoft Fabric, die komplexe Aufgaben als persistente, in Fabric ausgeführte Tasks verarbeitet. Anwender beschreiben ein gewünschtes Ergebnis – beispielsweise die Bereinigung und Zusammenführung mehrerer Datenquellen zu einer validierten Delta-Tabelle – und überlassen die technische Planung und Umsetzung innerhalb festgelegter Grenzen dem Agentensystem.

Im Unterschied zu einem klassischen KI-Coding-Assistenten beschränkt sich Project Osmos nicht auf das Generieren von PySpark-Code. Das System kann vorhandene Lakehouse-Ressourcen untersuchen, Spark-Notebooks erstellen, Transformationen ausführen, Ergebnisse überprüfen und seine Implementierung anhand tatsächlich beobachteter Resultate überarbeiten. Die entscheidende Neuerung ist die Verbindung aus autonomer Planung, realer Ausführung und integrierter Validierung.

Technisch nutzt Project Osmos eine Fabric-gehostete Task-Ausführung mit SparkCore, OneLake-Zugriff und persistentem Zustand. Eine Aufgabe bleibt bestehen, auch wenn der lokale Client geschlossen oder die Verbindung unterbrochen wird. Der Fortschritt lässt sich anschließend wieder aufrufen. Das macht Project Osmos besonders für umfangreichere Data-Engineering-Arbeiten interessant, die nicht in einer einzelnen Chat-Interaktion abgeschlossen werden können.

Wichtig: Project Osmos befindet sich derzeit in der Preview. Microsoft sieht Preview-Funktionen nicht für den Produktionseinsatz vor und stellt für sie keine regulären Service-Level-Agreements bereit. Auch wenn das System technisch hochwertige Ergebnisse erzeugen kann, ist damit keine Produktionsfreigabe verbunden.

Project Osmos, Fabric Data Agents und Operations Agent: Wo liegt der Unterschied?

Microsoft Fabric umfasst inzwischen mehrere KI-gestützte Funktionen, die unterschiedliche Aufgaben übernehmen. Für Architekturentscheidungen ist diese Trennung wesentlich, denn nicht jeder Agent darf Daten verändern und nicht jeder Agent führt eigenständig Data Engineering aus.

Technologie	Hauptaufgabe	Typischer Einsatz
Project Osmos	Data Engineering planen, ausführen und validieren	Lakehouse-Transformationen, Modernisierung, Datenqualität
Fabric Data Agents	Daten über natürliche Sprache abfragen	Conversational Analytics und datenbasierte Antworten
Operations Agent	Betriebszustände beobachten und untersuchen	Pipeline-Monitoring, Fehlerdiagnose, Empfehlungen
Fabric Core MCP Server	Fabric-Funktionen für KI-Clients zugänglich machen	Authentifizierte Steuerung und Verwaltung von Fabric-Ressourcen
Klassischer Coding Agent	Software und Code entwickeln oder verändern	Codegenerierung, Tests und Entwicklungsunterstützung

Ein Fabric Data Agent beantwortet beispielsweise die Frage, wie sich der Umsatz im vergangenen Quartal entwickelt hat. Project Osmos kann dagegen eine Transformation entwickeln und ausführen, die solche Umsatzdaten erst in der benötigten Qualität und Struktur bereitstellt. Beide Technologien greifen damit an unterschiedlichen Stellen der Analytics-Wertschöpfung ein.

Ähnlich unterscheidet sich Project Osmos vom Operations Agent für Fabric Pipelines. Dieser konzentriert sich auf die Beobachtung und Diagnose von Pipeline-Ausführungen. Project Osmos übernimmt dagegen die eigentliche Erstellung oder Überarbeitung von Data-Engineering-Ergebnissen. Überschneidungen bei Analyse und Empfehlungen ändern nichts an den verschiedenen Verantwortungsbereichen.

Auch die Verbindung zu Coding Agents ist wichtig: GitHub Copilot CLI, Claude Code oder Codex dienen bei Project Osmos als unterstützte lokale Einstiegspunkte. Die eigentliche autonome Data-Engineering-Aufgabe läuft anschließend in Fabric. Ein Coding Agent ist damit nicht automatisch selbst Project Osmos, sondern kann dessen Task-Ausführung anstoßen und steuern.

Wie funktioniert die autonome Ausführung?

Der Arbeitsablauf beginnt mit einem sogenannten Project Outcome. Dabei handelt es sich um die Beschreibung des vollständigen gewünschten Ergebnisses – nicht lediglich um den nächsten technischen Schritt.

Anschließend lässt sich die Ausführung in fünf Phasen einteilen:

1. Define: Ziel, Lakehouse-Kontext, Quellen, Transformationen und gewünschte Ergebnisse festlegen.

2. Plan: Project Osmos untersucht den verfügbaren Kontext und schlägt operative Einstellungen vor.

3. Execute: Die Task-Ausführung erstellt und testet Artefakte und verarbeitet Daten über Fabric Spark.

4. Validate: Ergebnisse werden anhand definierter Qualitäts- und Erfolgskriterien überprüft.

5. Monitor: Fortschritt, Aktivitäten, Fehler und Ergebnisse werden im Fabric-Task-Kontext sichtbar.

Der ausgewählte Lakehouse-Kontext bestimmt das standardmäßige Lakehouse der Spark-Sitzung. Er stellt jedoch keine automatische Beschränkung auf genau eine Datenquelle oder ein Zielsystem dar. Mit entsprechenden Berechtigungen können auch weitere Ressourcen erreichbar sein.

Das ist ein zentraler Unterschied zu eng begrenzten Automatisierungen. Project Osmos kann mehrere abhängige Verarbeitungsschritte innerhalb eines gemeinsamen Auftrags bearbeiten. Daraus entsteht ein größerer Automatisierungsumfang – allerdings auch ein größerer potenzieller Wirkungsbereich bei fehlerhafter Konfiguration.

Welche Aufgaben eignen sich für Project Osmos?

Besonders interessant sind Aufgaben, bei denen mehrere Engineering-Schritte zusammengehören und das Ergebnis tatsächlich getestet werden muss. Microsoft nennt beispielsweise Datenaufbereitung, Tabellenintegration, Lakehouse-Modernisierung, Datenqualitätsverbesserung und Migrationen.

Ein typischer Anwendungsfall wäre die Modernisierung einer vorhandenen Verarbeitung. Bisherige Full-Reloads sollen durch inkrementelle Verarbeitung ersetzt werden. Dafür muss das System zunächst Quellen und bestehende Logik verstehen, Änderungen korrekt erkennen, Dubletten vermeiden und die neue Implementierung mit dem bisherigen Ergebnis vergleichen.

Project Osmos kann solche Schritte als zusammenhängenden Auftrag bearbeiten: bestehende Daten untersuchen, alternative Implementierungen entwickeln, Notebooks erstellen, Testläufe ausführen und Ergebnisse anhand definierter Kriterien vergleichen. Der Mehrwert entsteht gerade dadurch, dass die technische Umsetzung nicht nach der ersten plausiblen Codeversion endet.

Weniger geeignet sind einfache SQL-Fragen, kleinere manuelle Codekorrekturen oder reine Power-BI-Berichtsanpassungen. Hier wäre die Nutzung eines umfangreichen autonomen Data-Engineering-Tasks häufig unnötig. Die Technologie lohnt sich vor allem dort, wo der zusätzliche Ausführungs- und Validierungszyklus einen nachvollziehbaren Nutzen erzeugt.

Die wichtigsten Voraussetzungen und Preview-Grenzen

Vor einem Pilot müssen die technischen und organisatorischen Voraussetzungen geklärt werden. Microsoft verlangt einen Workspace auf einer geeigneten Fabric-Kapazität, ein Lakehouse und mindestens Contributor-Berechtigungen im betreffenden Workspace. Fabric-Trial-SKUs werden nicht unterstützt.

Zusätzlich muss die Tenant-Einstellung für Copilot und andere durch Azure OpenAI unterstützte Funktionen aktiviert sein. Microsoft empfiehlt außerdem die entsprechende Einstellung für OpenAI als Microsoft-Subprozessor. Weitere Einstellungen zum regionsübergreifenden Verarbeiten oder Speichern von Daten können relevant werden, wenn OpenAI am Standort der Kapazität nicht verfügbar ist. Diese Freigaben gehören in die Datenschutz- und Compliance-Prüfung.

Für den lokalen Zugriff sind Azure CLI und ein unterstützter Client erforderlich. Die Project-Osmos-Skill wird über Microsofts Skills for Fabric bereitgestellt. Unterstützt werden GitHub Copilot CLI, Claude Code sowie Codex mit Git. Eine direkte Interaktion über Copilot im Fabric-Portal wird in der aktuellen Dokumentation nicht unterstützt.

Eine besonders relevante Einschränkung betrifft die Netzwerkabsicherung: Project Osmos steht derzeit nicht für Workspaces zur Verfügung, bei denen Outbound Access Protection aktiviert ist. Unternehmen mit entsprechenden Sicherheitsvorgaben müssen dies vor der Pilotplanung berücksichtigen. Eine Abschaltung bestehender Schutzmaßnahmen sollte nicht allein vorgenommen werden, um eine Preview-Funktion auszuprobieren.

Auch die regionale Verfügbarkeit und Preview-Freischaltung müssen im konkreten Tenant überprüft werden. Die allgemeine Verfügbarkeit von Microsoft Fabric in einer Region bedeutet nicht automatisch, dass jede neue Preview-Funktion dort genutzt werden kann.

Permission Boundary ist nicht gleich Berechtigungsgrenze

Project Osmos fordert vor der Ausführung Entscheidungen zu den erlaubten Lese- und Schreibressourcen an. Diese Permission Boundary beschreibt, auf welchen benannten Ressourcen die Aufgabe arbeiten soll.

Entscheidend ist jedoch die Unterscheidung zwischen einer operativen Agentenanweisung und technisch durchgesetzten Berechtigungen. Microsoft weist ausdrücklich darauf hin, dass Fabric- und OneLake-Berechtigungen die tatsächliche Autorisierungsgrenze bilden.

Ein Auftrag, der eine bestimmte Tabelle als schreibgeschützt bezeichnet, ist deshalb kein ausreichender Schutz, wenn die ausführende Identität technisch wesentlich umfangreichere Rechte besitzt. Die Anweisung reduziert den gewünschten Handlungsspielraum des Agenten, ersetzt aber keine Zugriffskontrolle.

Für einen kontrollierten Pilot empfiehlt sich daher ein isolierter Workspace mit Testdaten und möglichst eng begrenzten Berechtigungen. Produktive Quellressourcen sollten nur dann erreichbar sein, wenn dies erforderlich und gesondert freigegeben ist. Schreibrechte auf produktive Lakehouses gehören nicht zum Standardumfang eines Preview-Piloten.

Gerade weil Project Osmos innerhalb des zugelassenen Kontexts eigenständig Code ausführen und Daten verändern kann, sollten Unternehmen Least Privilege, Datenklassifizierung und technische Isolation vor dem ersten Task prüfen – nicht erst beim Review des Ergebnisses.

Sichere Schreibmuster: Staging, Clone-and-Promote und Reruns

Bei autonomen Data-Engineering-Agenten reicht es nicht, die Qualität des generierten Codes zu bewerten. Entscheidend ist, wie Schreiboperationen ausgeführt werden, welche Folgen Teilfehler haben und wie sich ein Ergebnis erneut erzeugen lässt.

Staging statt direkter Änderungen

Beim Staging-Muster schreibt Project Osmos Ergebnisse zunächst in separate Tabellen oder einen isolierten Zielbereich. Erst nach fachlicher und technischer Prüfung erfolgt eine kontrollierte Übernahme. Das produktive Ziel bleibt während der autonomen Verarbeitung unverändert.

Für einen Pilot ist dieses Muster besonders geeignet. Es erlaubt, Datenqualität, Schemata, Schlüssel und Summen zu prüfen, bevor eine verantwortliche Person entscheidet, ob und wie die Ergebnisse übernommen werden.

Clone-and-Promote für bestehende Artefakte

Beim Clone-and-Promote-Muster werden Änderungen zunächst an einer Kopie ausprobiert. Bestehende Transformationen oder Tabellen bleiben erhalten, während die neue Implementierung ausgeführt und geprüft wird. Erst eine freigegebene Promotion ersetzt oder ergänzt den bisherigen Stand.

Dieses Muster ist besonders hilfreich, wenn Project Osmos vorhandene Notebooks modernisiert oder Transformationen optimiert. Es ermöglicht einen direkten Vergleich, ohne die bisherige Verarbeitung unkontrolliert zu verändern.

Locked Schema und deterministische Reruns

Ein Locked Schema verhindert unerwartete Schemaänderungen. Alternativ kann eine gezielt eingeschränkte Schemaentwicklung erlaubt werden, beispielsweise kompatible Erweiterungen von Datentypen. Welche Variante sinnvoll ist, hängt vom Datenvertrag des jeweiligen Outputs ab.

Ebenso wichtig ist die Idempotenz: Ein erneuter Lauf darf nicht unbemerkt doppelte Datensätze, widersprüchliche Historien oder fehlerhafte Summen erzeugen. Für inkrementelle Verarbeitung sollten deshalb stabile Business Keys, Änderungszeitpunkte und eindeutige Regeln für Insert, Update, Deduplication oder Replacement definiert werden.

Die Wiederholbarkeit muss praktisch getestet werden. Ein erfolgreich abgeschlossener erster Lauf beweist noch nicht, dass derselbe Task nach einer Unterbrechung oder bei erneut eintreffenden Daten sichere Ergebnisse liefert.

Praxisbeispiel: Einen Project-Osmos-Pilot richtig beschreiben

Ein sinnvoller Pilot beginnt mit einer konkret messbaren Aufgabe. Angenommen, ein Unternehmen möchte aus Bestellungen und Kundendaten eine verlässliche monatliche Umsatzübersicht nach Kundensegment erzeugen.

Statt lediglich „Erstelle eine Umsatz-Tabelle“ zu formulieren, sollte das Project Outcome sämtliche wesentlichen Anforderungen enthalten. Eine mögliche Aufgabenbeschreibung lautet:

Verwende Project Osmos im freigegebenen Fabric-Pilot-Workspace und im Lakehouse SalesPilot. Lies ausschließlich die freigegebenen Quelltabellen Orders und Customers. Bereinige ungültige Kundenschlüssel, standardisiere Datentypen und verknüpfe die Bestellungen mit den zugehörigen Kundensegmenten. Erstelle eine Delta-Staging-Tabelle mit dem monatlichen Umsatz je Kundensegment sowie ein dokumentiertes Spark-Notebook. Verändere weder die Quelltabellen noch produktive Zieltabellen. Prüfe die Eindeutigkeit der Bestellungsschlüssel, fehlende Kundenreferenzen, ungültige Umsatzwerte und die Übereinstimmung der aggregierten Summen mit den gültigen Quelldatensätzen. Dokumentiere ausgeschlossene Datensätze, Transformationen, Testergebnisse und Abweichungen. Verwende ein gesperrtes Zielschema und deduplizierende Wiederholungsläufe. Führe mindestens einen erneuten Lauf mit identischen Quelldaten aus und prüfe, dass weder zusätzliche Dubletten noch veränderte Summen entstehen. Übernimm keine Ergebnisse in produktive Tabellen. Stelle den vollständigen Output zur menschlichen Prüfung bereit.

Dieser Auftrag unterscheidet sich wesentlich von einer offenen KI-Anweisung. Quellen, Transformationen, Outputs, Constraints und Validierungen sind explizit beschrieben. Gleichzeitig ist festgelegt, welche Ressourcen nicht verändert werden dürfen.

Beim anschließenden Review sollten nicht nur Notebook und Ergebnistabelle betrachtet werden. Auch verworfene Datensätze, Join-Kardinalitäten, verwendete Schlüssel, Summenabgleiche, Schemaänderungen und das Ergebnis des zweiten Laufs gehören zur technischen Abnahme.

Human Review, Monitoring und Wiederaufnahme

Project Osmos bietet eine persistente Task-Ausführung. Anwender können den Fortschritt über ihren unterstützten lokalen Agenten verfolgen und den Task im Lakehouse-Kontext des Fabric-Portals aufrufen. Dort werden unter anderem Status, Spezifikation und Agentenaktivitäten angezeigt.

Eine laufende Aufgabe bleibt grundsätzlich erhalten, wenn die lokale Verbindung endet. Über den bestehenden Task kann später weitergearbeitet werden. Ein Client-Neustart sollte deshalb nicht automatisch zum Anlegen eines zweiten Tasks führen. Stattdessen wird die vorhandene Task-ID für die Wiederaufnahme verwendet.

Der lokale Client unterstützt außerdem Anfragen zum Prüfen des Status, zur Ergänzung von Anweisungen und zum Abbrechen oder Löschen eines Tasks. Unternehmen sollten dennoch festlegen, wie sie auf unerwartetes Verhalten reagieren: Wer darf einen Task stoppen? Wer prüft bereits geschriebene Daten? Wer entscheidet über die Wiederaufnahme?

Ein wirksames Human-Review-Modell benötigt mindestens drei Kontrollpunkte: die Freigabe des Project Outcomes und der Ausführungsparameter vor dem Start, die Prüfung relevanter Zwischenergebnisse oder Rückfragen sowie die abschließende Abnahme von Artefakten und Daten. Besonders wichtig ist, dass technische Fertigstellung nicht automatisch fachliche Freigabe bedeutet.

Für nachvollziehbaren Betrieb sollten Task-ID, ausführende Identität, verwendete Ressourcen, erzeugte Artefakte, Qualitätsnachweise und relevante Entscheidungen dokumentiert werden. Die im Portal sichtbaren Aktivitäten sind dafür ein Ausgangspunkt; sie ersetzen nicht automatisch sämtliche unternehmensinternen Audit-Anforderungen.

Welche Kosten verursacht Project Osmos?

Project Osmos benötigt sowohl KI-Modellleistung als auch Fabric-Rechenressourcen. Microsoft dokumentiert für die Sprachmodellnutzung verbrauchsbasierte Raten in Capacity Units beziehungsweise CU-Sekunden. Die tatsächliche Nutzung hängt unter anderem von der Anzahl verarbeiteter Tokens, dem verwendeten Modellprofil und dem Umfang der Aufgabe ab.

In der Fabric Capacity Metrics App erscheint die KI-Modellnutzung unter einer eigenen Project-Osmos-Operation. Zusätzliche Fabric-Vorgänge, beispielsweise Spark-Ausführungen, müssen bei der Verbrauchsbewertung ebenfalls berücksichtigt werden. Ein einziger Project Outcome ist deshalb nicht mit einem pauschalen Festpreis gleichzusetzen.

Für den Pilot sollte vorab ein begrenztes Kapazitäts- und Zeitbudget festgelegt werden. Sinnvolle Messgrößen sind die verbrauchten CU-Sekunden, die Anzahl benötigter Ausführungs- und Korrekturschritte, die Laufzeit und die tatsächlich erzielte Reduktion manueller Engineering-Arbeit.

Ein belastbarer Wirtschaftlichkeitsvergleich stellt dem Verbrauch nicht einfach die theoretisch eingesparten Entwicklerstunden gegenüber. Entscheidend ist die gesamte Bearbeitungszeit einschließlich Vorbereitung, Kontrolle, Nacharbeit und gegebenenfalls notwendiger Fehlerkorrekturen.

Ein kontrollierter Pilot in vier Phasen

Phase 1: Eignung und Sicherheitsgrenzen prüfen

Zunächst werden Tenant, Kapazität, regionale Verfügbarkeit, erforderliche Einstellungen und Workspace-Berechtigungen überprüft. Das Team wählt einen abgegrenzten Use Case mit bekannten Eingangs- und erwarteten Ergebnisdaten. Produktive Schreibziele werden aus dem ersten Test ausgeschlossen.

Phase 2: Referenzlauf und Erfolgskriterien festlegen

Anschließend wird die Aufgabe mit einer vorhandenen, kontrollierten Implementierung oder einem fachlich verifizierten Referenzergebnis verglichen. Vor dem Start stehen die Qualitätskriterien fest: beispielsweise Vollständigkeit, korrekte Schlüssel, Summenabgleich, akzeptierte Datenverluste und unverändertes Schema.

Phase 3: Autonome Ausführung einschließlich Fehlertests

Project Osmos bearbeitet die Aufgabe in der isolierten Umgebung. Neben dem Normalfall werden mindestens ein Wiederholungslauf und ein kontrollierter Fehlerfall getestet. Zu prüfen sind unter anderem das Verhalten bei ungültigen Quelldaten, die Nachvollziehbarkeit der Ausgaben und der Umgang mit Unterbrechungen.

Phase 4: Technische und wirtschaftliche Bewertung

Abschließend bewertet das Team Codequalität, Datenqualität, Sicherheit, Laufzeit und Verbrauch. Die Ergebnisse werden mit dem bisherigen Engineering-Verfahren verglichen. Die Entscheidung lautet nicht automatisch „in Produktion übernehmen“, sondern zunächst, ob sich die Technologie für weitere abgegrenzte Tests eignet.

Welche Kennzahlen entscheiden über den Piloterfolg?

Die folgenden Kennzahlen sind ein sinnvoller Bewertungsrahmen der Daten-WG. Es handelt sich um vorgeschlagene Pilot-KPIs und nicht um von Microsoft garantierte Leistungswerte.

Kennzahl	Bewertung
Datenqualität	Anteil bestandener fachlicher und technischer Prüfungen
Reproduzierbarkeit	Identische oder fachlich äquivalente Ergebnisse nach einem Rerun
Eingriffsbedarf	Anzahl menschlicher Korrekturen und Freigabeinterventionen
Engineering-Aufwand	Gesamtzeit einschließlich Vorbereitung, Review und Nacharbeit
Sicherheit	Unzulässige Zugriffe oder unerwartete Änderungen an geschützten Ressourcen
Ressourcenverbrauch	Modell-CUs, weitere Fabric-Kapazitätsnutzung und Laufzeit

Ein Pilot gilt nicht allein deshalb als erfolgreich, weil der Agent eine fertige Delta-Tabelle eeugt. Er muss nachweisen, dass die Daten korrekt, wiederholbar, verständlich und innerhalb der vorgesehenen Berechtigungsgrenzen entstanden sind.

Typische Fehler beim Einstieg vermeiden

Ein häufiger Fehler besteht darin, dem Agenten nur ein grobes Ziel ohne messbare Erfolgsbedingungen zu geben. In diesem Fall entsteht möglicherweise eine technisch funktionierende, aber fachlich unpassende Transformation. Ebenso problematisch sind umfassende Workspace-Rechte, während Einschränkungen lediglich im Project Outcome formuliert werden.

Ein weiterer Fehler ist die direkte Verarbeitung in bestehenden Zieltabellen, ohne Rückfalloption oder getestetes Rerun-Verhalten. Besonders bei inkrementellen Lastprozessen können dadurch Dubletten und schwer nachvollziehbare Abweichungen entstehen.

Schließlich sollten Unternehmen vermeiden, den Abschlussstatus einer KI-Aufgabe mit einer technischen oder geschäftlichen Qualitätsgarantie zu verwechseln. Autonom ausgeführte Tests liefern wichtige Evidenz – die Verantwortung für Akzeptanzkriterien und Freigaben bleibt beim Unternehmen.

---

Fazit: Autonomes Data Engineering braucht kontrollierte Ausführung

Project Osmos zeigt, wohin sich KI-Unterstützung im Data Engineering entwickelt: weg von isolierten Codevorschlägen und hin zu persistenten Aufgaben, die eigenständig planen, reale Daten verarbeiten und ihre Ergebnisse validieren.

Der eigentliche Fortschritt liegt nicht in der Automatisierung einzelner Spark-Befehle, sondern in einem zusammenhängenden Engineering-Prozess mit überprüfbaren Ergebnissen. Genau darin liegt auch das Potenzial für die Modernisierung von Datenplattformen, die Verbesserung der Datenqualität und die Beschleunigung wiederkehrender Engineering-Aufgaben.

Die Preview-Grenzen dürfen dabei nicht unterschätzt werden. Insbesondere Berechtigungen, sichere Schreibpfade, regionale Voraussetzungen, Kapazitätsverbrauch und menschliche Freigaben müssen vor der Ausführung geklärt sein. Für Unternehmen ist ein isolierter, messbar bewerteter Pilot deshalb derzeit der sinnvollste Einstieg.

---

Nächste Schritte

Wer Project Osmos einsetzen möchte, sollte zuerst klären, welche bestehenden Data-Engineering-Aufgaben tatsächlich von autonomer Planung und Ausführung profitieren. Entscheidend sind ein abgegrenzter Anwendungsfall, belastbare Datenqualitätsregeln und eine Fabric-Umgebung mit geeigneten Sicherheitsgrenzen.

Im Rahmen eines Microsoft Fabric Kick-Starts lassen sich die technischen Voraussetzungen und ein konkreter Pilot gemeinsam bewerten. Bei weitergehenden Fragen zu Zielarchitektur, Berechtigungen und Betriebsmodell unterstützt die Microsoft Fabric Beratung der Daten-WG.