End-to-End-MLOps in Fabric mit Cross-Workspace-MLflow

Die meisten Teams trainieren ein Modell in einem Fabric-Notebook an einem Nachmittag. Dieses Modell durch einen geregelten Lebenszyklus zu bringen — versioniert, reproduzierbar, über Umgebungen hinweg freigegeben und rückverfolgbar bis zu den exakten Daten, aus denen es gelernt hat — ist die eigentliche Arbeit. Genau diese Lücke schließt Fabric MLOps, und 2026 ist der entscheidende Wegbereiter dafür Cross-Workspace-MLflow.

Dieser Beitrag ist eine praxisnahe Anleitung, wie wir End-to-End-Pipelines für Machine Learning in Fabric bauen, die die Anforderungen der Unternehmens-Governance erfüllen, ohne Data Scientists in Prozessen zu ertränken.

TL;DR / Die wichtigsten Erkenntnisse

• Cross-Workspace-MLflow entkoppelt wo trainiert wird von wo geregelt wird und schafft saubere Grenzen Dev → Staging → Produktion innerhalb von Microsoft Fabric.
• Das Modellregister in Fabric — gestützt auf OneLake — hält Modelle, Lineage und Trainingsdaten an einer Stelle, was für EU-Nachweispflichten und Reproduzierbarkeit entscheidend ist.
• Sie können Assets aus Azure Databricks und Azure ML in Fabric überführen — per MLflow-Logging-Interoperabilität, ohne erneutes Training und mit standardisierter Governance.
• Quelldaten müssen aus der Gold-Schicht einer Medaillon-Architektur stammen, damit jede Vorhersage auf validierte Eingaben zurückgeführt werden kann.
• Da das Power BI Copilot Tooling Format nun allgemein verfügbar ist, läuft die Konsumschicht (semantische Modelle, Berichte) gemeinsam mit dem Modellcode durch CI/CD.

Warum Cross-Workspace-MLflow das Bild verändert

Über weite Teile der Fabric-Geschichte war das MLflow-Tracking faktisch an einen Workspace gebunden: Runs und Modelle wurden in demselben Workspace protokolliert und registriert, in dem das Notebook lief. Für einen Proof of Concept ist das in Ordnung — für die Produktion aktiv schädlich. Es bedeutet, dass sich Experimentier-Sandbox und produktives Modellregister denselben Wirkungsradius, dieselbe Zugriffsliste und dieselbe Kapazität teilen.

Cross-Workspace-MLflow löst diese Kopplung auf. Ein in einem Data-Science-Workspace protokollierter Run kann aus einem separaten Governance-Workspace referenziert, registriert und freigegeben werden. Die praktische Folge: Fabric MLflow kann nun dieselbe Funktionstrennung abbilden, die reife Teams auf dedizierten ML-Plattformen voraussetzen — und das, ohne die OneLake-Landschaft zu verlassen, in der Ihre Analytics, Power BI und Data Agents bereits leben.

Die zweite Hälfte der Geschichte ist Interoperabilität. Fabric unterstützt MLflow-Logging, das Assets aus Azure Databricks und Azure ML in Fabric überführt. Wenn Ihr Data-Engineering-Team rechenintensives Spark-Training auf Databricks betreibt, müssen Sie sich nicht mehr zwischen deren Tooling und der Governance von Fabric entscheiden — Sie trainieren dort, wo es am günstigsten und leistungsfähigsten ist, und registrieren und betreiben dort, wo es am besten regelbar ist.

Referenzarchitektur: drei Workspaces, eine Registry-Disziplin

Die Architektur, die wir bei Kunden ausrollen, ordnet Umgebungen Workspaces und MLflow-Registry-Stufen Freigabe-Gates zu.

Loading diagram...

Workspace	Zweck	MLflow-Rolle	Schreibzugriff
ml-dev	Experiment, Feature Engineering, Training	Protokolliert Runs und Experimente frei	Data Scientists
ml-staging	Validierung, Integrationstests, Shadow-Scoring	Hält registrierte Kandidatenversionen	ML-Engineers + CI
ml-prod	Bereitstellung, Batch-Scoring, Monitoring	Hält nur den Produktions-Alias	Nur Deployment-Pipeline

Die Disziplin ist einfach: Menschen protokollieren; Pipelines geben frei. Ein Data Scientist registriert ein Modell niemals direkt in die Produktion. Stattdessen wird ein Run in ml-dev mit Signatur und Metriken protokolliert, eine Pipeline registriert den besten Kandidaten in ml-staging, automatisierte Gates validieren ihn, und erst dann verschiebt ein Freigabeschritt den Produktions-Alias in ml-prod. Cross-Workspace-MLflow macht diese Referenz sauber statt zu einem Bündel fragiler Kopierskripte.

Woher die Trainingsdaten kommen

Ein Modell ist nur so vertrauenswürdig wie seine Eingaben. Trainingsdaten müssen aus der Gold-Schicht — oder einer kuratierten Silber-Schicht — einer Medaillon-Architektur in OneLake stammen, niemals aus dem rohen Bronze-Layer. Das liefert dreierlei zugleich: reproduzierbare Feature-Eingaben, validierte Qualität und eine Lineage-Kette, die vom Quellsystem über Bronze/Silber/Gold bis zum MLflow-Run reicht, der sie verarbeitet hat. Wenn eine Prüfinstanz fragt „welche Daten haben das Modell trainiert, das diese Entscheidung getroffen hat", ist die Antwort eine Abfrage und keine Ausgrabung.

Die Pipeline Schritt für Schritt aufbauen

Dies ist die Reihenfolge, die wir in einem typischen Projekt befolgen.

1. Workspaces und Kapazität einrichten. ml-dev, ml-staging und ml-prod anlegen. Kapazität bewusst zuweisen — produktives Scoring darf nicht mit dem Experimentieren konkurrieren.
2. Training auf Gold ausrichten. Features über OneLake-Shortcuts aus der Gold-Schicht lesen. Die Datenversion fixieren, damit der Run reproduzierbar ist.
3. Alles mit MLflow protokollieren. Parameter, Metriken, Modellsignatur und Eingabebeispiele erfassen. Die Signatur ist nicht optional — sie ermöglicht es Staging, Eingaben automatisch zu validieren.
4. Den Kandidaten Cross-Workspace registrieren. Aus dem Dev-Run die gewählte Version in das ml-staging-Register registrieren. Das ist der Cross-Workspace-Schritt, den ältere Fabric-Versionen nicht sauber konnten.
5. Automatisierte Gates ausführen. In Staging die Signatur validieren, Metriken gegen das Bestandsmodell vergleichen, Bias- und Drift-Prüfungen durchführen und einen Holdout bewerten. Bei Regression bricht der Build ab.
6. Per Alias freigeben, nicht per Kopie. Den production-Alias in ml-prod auf die validierte Version verschieben. Ein Rollback ist dann eine einzeilige Alias-Änderung.
7. Konsumschicht an CI/CD anbinden. Semantische Power-BI-Modelle im Copilot Tooling Format exportieren, damit Berichte, die die Vorhersagen darstellen, gemeinsam mit dem Modell versioniert und bereitgestellt werden.
8. Den Kreis mit Monitoring schließen. Produktive Eingaben und Ausgaben zurück in OneLake protokollieren und auf Daten-Drift gegenüber der Trainingsverteilung der Gold-Schicht achten.

Bei einer kürzlichen Datenkonsolidierung nach einer Fusion haben wir genau dieses Muster genutzt, um zwei übernommene Teams — eines auf Azure Databricks, eines bereits in Fabric — auf ein einziges geregeltes Register zu bringen, ohne dass eines seinen Trainings-Stack aufgeben musste. Das Databricks-Team behielt seine Spark-Notebooks; ihre Modelle flossen per MLflow-Logging in das Fabric-Register ml-staging, und von dort teilten alle einen Freigabeprozess.

Freigabe-Gates, die wirklich greifen

Ein Freigabe-Gate ist nur nützlich, wenn es Nein sagen kann. Die Gates, die wir für eine Fabric-MLOps-Pipeline im Unternehmen als verpflichtend ansehen:

Gate	Prüfung	Blockiert die Freigabe, wenn
Signaturabgleich	Eingabe-/Ausgabe-Schema des Modells	Schema vom registrierten Vertrag abweicht
Metrik-Regression	Primärmetrik gegen Bestandsmodell	Neue Version über Toleranz hinaus schlechter ist
Daten-Drift	Trainings- gegen jüngste Produktionsverteilung	Drift den Schwellenwert überschreitet
Fairness / Bias	Leistung in Subgruppen	Disparität die Richtlinie überschreitet
Lineage-Vollständigkeit	Kette Quelle → Gold → Run	ein Glied fehlt oder unversioniert ist

Diese Gates sind keine Bürokratie um ihrer selbst willen. Vor dem Hintergrund der entstehenden EU-Erwartungen — einschließlich der Dokumentations- und Nachweispflichten, die sich durch den EU AI Act ziehen — wird die Fähigkeit, warum eine bestimmte Modellversion in die Produktion gelangte, nachweisen zu können, rasch zur Grundanforderung statt zum netten Extra. Insbesondere das Gate zur Lineage-Vollständigkeit macht aus „wir glauben, das ist reproduzierbar" ein „hier ist die exakte Kette".

Echtzeit-Scoring und agentische Nutzung

Batch-Scoring ist der Regelfall, doch die Fabric-Fähigkeiten von 2026 gehen weiter. Über diese Pipeline registrierte Modelle können von autonomen Workflows genutzt werden — Fabric Data Agents und Copilot Cowork können geregelte Modelle als Teil eines ausgeführten Plans aufrufen. Und wo Vorhersagen auf Live-Daten reagieren müssen, erlaubt das Eventhouse Remote MCP Agenten, Echtzeit-Streams per natürlicher Sprache und KQL abzufragen und so frische Features an ein Modell zu liefern, das über genau die oben beschriebene Pipeline trainiert und registriert wurde.

Der Kern ist: Das Register ist keine Sackgasse. Ein auf den ml-prod-Alias freigegebenes Modell ist für den Rest der Fabric-Plattform — Analytics, Agenten und Berichte — adressierbar, gerade weil es in OneLake liegt und nicht in einem isolierten ML-Dienst.

Häufige Fehler, die wir sehen

1. Ein Workspace für alles. Am ersten Tag bequem, am neunzigsten nicht mehr regelbar. Umgebungen früh trennen.
2. Training aus Bronze. Das Überspringen der Gold-Schicht zerstört Reproduzierbarkeit und Lineage. Immer aus kuratierten Daten trainieren.
3. Freigabe durch Kopieren von Artefakten. Registry-Aliasse verwenden. Kopien driften; Aliasse sind atomar und umkehrbar.
4. Die Modellsignatur weglassen. Ohne sie kann Staging Eingaben nicht validieren, und Schema-Brüche entdecken Sie erst in der Produktion.
5. Die Konsumschicht vergessen. Ein perfekt geregeltes Modell, das einen unversionierten Bericht speist, ist nur die halbe MLOps-Geschichte. Semantische Modelle im Copilot Tooling Format unter Versionsverwaltung stellen.

Fazit

Cross-Workspace-MLflow ist der Baustein, der Microsoft Fabric endlich befähigt, einen glaubwürdigen, prüffähigen MLOps-Lebenszyklus zu beherbergen, ohne eine separate ML-Plattform anzuflanschen. Trainieren Sie, wo es sinnvoll ist — auch in Azure Databricks oder Azure ML —, registrieren und regeln Sie in Fabric, geben Sie über Gates frei, die Nein sagen können, und halten Sie die gesamte Kette von der Gold-Schicht bis zur ausgelieferten Vorhersage in OneLake rückverfolgbar.

---

Wenn Sie eine Fabric-MLOps-Plattform entwerfen oder fragmentierte ML-Landschaften auf ein geregeltes Register konsolidieren, hat unser Team für KI- und Datenplattform-Engineering genau das für europäische Unternehmen geliefert. Wir prüfen gerne Ihre Architektur.

FAQ

Was ist Cross-Workspace-MLflow in Microsoft Fabric?

Cross-Workspace-MLflow erlaubt es, Experimente, Runs und Modelle in einem Fabric-Workspace zu protokollieren und sie aus einem anderen Workspace zu referenzieren oder zu registrieren. Es entkoppelt den Workspace, in dem trainiert wird, von dem Workspace, in dem Modelle geregelt und freigegeben werden. Das ist die Grundlage eines sauberen MLOps-Lebenszyklus mit getrennten Grenzen für Dev, Staging und Produktion.

Wie unterscheidet sich das Modellregister in Fabric von Azure ML?

Beide implementieren die MLflow-Tracking- und Registry-APIs, die SDK-Aufrufe sind also weitgehend identisch. Der Unterschied liegt in der Schwerkraft der Daten: Fabric hält Modelle, Lineage und die Trainingsdaten innerhalb von OneLake direkt neben der Power-BI- und Analytics-Landschaft, während Azure ML eine eigenständige ML-Plattform ist. Mit Cross-Workspace-MLflow und der MLflow-Logging-Interoperabilität können Sie in Azure ML oder Azure Databricks trainieren und diese Assets zur Bereitstellung und Governance in Fabric überführen.

Kann ich in Azure Databricks oder Azure ML trainierte Modelle in Fabric überführen?

Ja. Das Cross-Workspace-MLflow-Logging von Fabric unterstützt End-to-End-MLOps, bei dem Assets aus Azure Databricks oder Azure ML in Fabric registriert und verwaltet werden. Das Modellartefakt und seine MLflow-Metadaten wandern mit, sodass Lineage und Signaturen erhalten bleiben. So vermeiden Sie erneutes Training und standardisieren die Governance an einer Stelle.

Welchen Bezug hat die Medaillon-Architektur zu MLOps in Fabric?

Trainingsdaten sollten aus der Gold-Schicht — oder einer kuratierten Silber-Schicht — einer Medaillon-Architektur in OneLake stammen, niemals aus dem rohen Bronze-Layer. Das liefert reproduzierbare, validierte Feature-Eingaben und eine saubere Lineage von der Quelle bis zum Modell. Medaillon-Schichtung und MLflow-Run bilden gemeinsam eine prüfbare Kette von Rohdaten bis zur ausgelieferten Vorhersage.

Was ist das Power BI Copilot Tooling Format und warum ist es für MLOps relevant?

Das Copilot Tooling Format erreichte im Mai 2026 die allgemeine Verfügbarkeit und ist ein Git-freundliches, textbasiertes Metadatenformat für semantische Power-BI-Modelle. Für MLOps ist es relevant, weil die nachgelagerte Konsumschicht — die Berichte und semantischen Modelle, die Vorhersagen darstellen — neben dem Modellcode in der Versionsverwaltung liegen kann, sodass die gesamte Analytics-zu-ML-Landschaft gemeinsam durch CI/CD läuft.

Brauche ich drei getrennte Fabric-Workspaces für Dev, Staging und Produktion?

Drei Workspaces bilden die sauberste Zuordnung zu MLflow-Registry-Stufen und Deployment-Pipelines, sind aber nicht zwingend. Kleinere Teams können Dev und eine kombinierte Staging-/Produktionstrennung mit strengen Registry-Aliassen und Zugriffskontrollen betreiben. Entscheidend ist das Prinzip, dass eine Freigabe ein geregelter, mit Gates abgesicherter Übergang zwischen Umgebungen ist und keine Änderung im Bestand.