Data Lineage Power BI und Fabric Leitfaden 2026 für Agentic BI
Data Lineage in Power BI und Fabric: Was die native Ansicht leistet, wo Purview aufhört, wann Column-Level-Lineage mit ABIS nötig ist.
Automatisierte Data Lineage in Power BI und Microsoft Fabric: Der vollständige Leitfaden
Eine Spalte im Data Warehouse wird umbenannt — und drei Wochen später fällt auf, dass ein Vorstands-Dashboard seither die falsche Kennzahl ausweist. Niemand hatte auf dem Schirm, dass genau diese Spalte über vier Measure-Ebenen bis in ein KPI-Visual auf Seite 3 durchschlägt. Automatisierte Data Lineage schließt diese Lücke: die lückenlose Nachverfolgung eines Datenpunkts von der Quelle bis zum einzelnen Visual. Dieser Leitfaden zeigt, was Power BI und Microsoft Fabric nativ leisten, wo sie aufhören — und wann Sie einen graphbasierten Ansatz brauchen.
Das Wichtigste in Kürze
Data Lineage in Power BI verbindet einen Datenpunkt nachvollziehbar von der Quelle (z. B. einer SQL-Server-Spalte) über Transformationen (Power Query/M, Dataflows, DAX) bis zum konkreten Visual im Bericht. Microsoft liefert Lineage nativ — aber ausschließlich auf Item-Ebene. Spaltengenaue Nachverfolgung über SQL, SSRS, Excel und Power BI hinweg ist mit Bordmitteln nicht abgedeckt. Microsoft Purview beantwortet „Welche Assets gibt es und wie hängen sie zusammen?" — nicht „Welche Spalte treibt diese Kennzahl?". Column-Level-Lineage ist technisch schwer, weil ein Werkzeug drei Sprachen (SQL, M, DAX) parsen und miteinander verknüpfen muss. In einem realen Modell hingen an einer einzigen Faktenspalte 58 abhängige Objekte — 16 Measures, 19 Visuals, 21 Filter, 2 Berichtsseiten. Ab dieser Komplexität ist Lineage keine Dokumentations-, sondern eine Abfragefrage. Für Migration nach Fabric, DSGVO-Nachweise und Agentic-BI-Kontrolle wird spaltengenaue, cross-stack und lokal erzeugte Lineage 2026 zur Pflicht.
Was ist Data Lineage in Power BI?
Data Lineage in Power BI ist die nachvollziehbare Verbindung eines Datenpunkts von seiner Quelle über alle Transformationen bis zu seiner Verwendung im Bericht. Sie beantwortet die Frage, wo eine Zahl herkommt und wohin sie überall fließt — nicht, was sie fachlich bedeutet.
Zwei Abgrenzungen vorweg, weil sie im Alltag ständig vermischt werden: Lineage ist keine Dokumentation (eine Doku beschreibt Absichten, Lineage erfasst die tatsächliche technische Kette) und Lineage ist kein Datenkatalog (ein Katalog macht Assets auffindbar, sagt aber nichts über den Transformationsfluss zwischen ihnen).
Die drei Granularitätsstufen
Der entscheidende Unterschied zwischen „reicht schon" und „reicht nicht" liegt in der Granularität. Es gibt drei Stufen — und die native Ansicht deckt genau die oberflächlichste ab.
Tabelle 1 — Lineage-Granularität
| Stufe | Was sie beantwortet | Beispiel | Nativ in Fabric? |
|---|---|---|---|
| Item-Level | Welches Artefakt speist welches? | Lakehouse → Semantisches Modell → Bericht | Ja |
| Table-Level | Welche Tabelle landet wo? | dbo.FactSales → Tabelle Sales | Teilweise |
| Column-Level | Welche Spalte wird wo, wie und von wem verwendet? | Umsatz_Netto → M-Schritt → DAX-Measure → KPI-Visual auf Seite 3 | Nein |
Verwandte Begriffe sauber trennen
Wer Werkzeuge vergleicht, stolpert über eine Reihe benachbarter Begriffe. Sie überlappen, meinen aber Unterschiedliches — und ein Tool, das den einen kann, kann den anderen oft nicht.
Tabelle 2 — Begriffsabgrenzung
| Begriff | Was er leistet | Was er nicht leistet |
|---|---|---|
| Data Lineage | Herkunft und Fluss von Daten | Fachliche Bedeutung |
| Impact Analysis | Vorwärtsgerichtete Wirkungsanalyse einer Änderung | Historie |
| Data Catalog | Auffindbarkeit und Beschreibung von Assets | Transformationslogik |
| Semantic Layer | Fachliche Modellierung für Abfragen | Nachvollziehbarkeit der Herkunft |
| Knowledge Graph | Beziehungen zwischen Objekten und Konzepten als Graph | Ausführung von Abfragen auf Rohdaten |
Warum Data Lineage 2026 zur Pflicht wird
Lineage war lange ein „Nice-to-have" für ordentliche BI-Teams. 2026 ist sie das nicht mehr — aus fünf Gründen, die von der Alltagspanne bis zur Regulierung reichen.
Impact Analysis: Ein Schema-Change bricht 40 Berichte
Der Klassiker: Eine Spalte im Data Warehouse wird umbenannt oder ihr Typ geändert. Ohne Lineage ist unbekannt, welche Dataflows, Measures und Visuals daran hängen. Die Folge sind stille Fehler, die erst im Produktivbetrieb auffallen. Rechnen Sie das durch: Ausfallzeit pro Bericht × Anzahl betroffener Berichte × Stundensatz der Analysten, die tagelang suchen, statt die Ursache in Minuten zu kennen — die Zahl wird schnell unangenehm.
„Warum ist diese Zahl falsch?"
Der Fachbereich zweifelt eine Kennzahl an. Ohne Lineage beginnt das stundenlange Durchsuchen von Power-Query-Schritten und DAX-Ausdrücken. Mit Lineage wird daraus eine gezielte Rückverfolgung auf den einen Transformationsschritt — in Minuten statt Stunden. Vertrauen in Reporting entsteht nicht durch schöne Visuals, sondern durch die Fähigkeit, jede Zahl belegen zu können.
DSGVO und EU AI Act
Die DSGVO fordert den Begriff „Data Lineage" nicht wörtlich — aber Art. 30 (Verzeichnis von Verarbeitungstätigkeiten) und Art. 15 (Auskunftsrecht) setzen faktisch voraus, dass Sie wissen, wo eine personenbezogene Spalte überall landet. Der EU AI Act ergänzt das: Für als hochriskant eingestufte Systeme greifen Anforderungen an Datenqualität, technische Dokumentation und Protokollierung. Wer KI-Agenten auf BI-Modelle loslässt, braucht einen belastbaren Nachweis, welche Daten in welche Entscheidung eingeflossen sind.
Gut zu wissen: Ob der EU AI Act für Ihren Fall greift, hängt von der Einstufung des Anwendungsfalls ab, nicht pauschal von „BI mit KI". Seriöse Lineage-Argumente verzichten auf Bußgeld-Drohungen und verweisen auf die konkreten Artikel — das ist glaubwürdiger und rechtlich sauberer.
AI- und Copilot-Readiness
KI-Agenten und Copilot halluzinieren Geschäftslogik, wenn das semantische Modell nicht dokumentiert ist. Für ein LLM sind ein verwaistes Measure, eine ungenutzte Spalte und ein mehrdeutiger Bezeichner nicht von den gültigen Gegenstücken zu unterscheiden. Lineage ist die Voraussetzung dafür, Agentic BI überhaupt kontrollierbar zu machen — ein Punkt, den wir im Kontext von Agentic BI und lokaler Wissensgovernance ausführlich behandelt haben.
Kostenoptimierung
Spalten und Tabellen, die nie in einem Visual landen, kosten trotzdem: Refresh-Zeit, Speicher und — in Fabric — bare Capacity Units. Lineage macht diese toten Pfade identifizierbar und damit abschaltbar.
Tabelle 3 — Treiber, Rolle und die typische Frage dahinter
| Treiber | Betroffene Rolle | Typische Frage |
|---|---|---|
| Impact Analysis | Data Engineer | „Was bricht, wenn ich das ändere?" |
| Debugging / Vertrauen | BI-Analyst, Fachbereich | „Warum ist diese Zahl falsch?" |
| DSGVO / EU AI Act | CDO, Datenschutz | „Wo landet diese personenbezogene Spalte überall?" |
| Copilot-Readiness | Head of BI | „Kann ich einen KI-Agenten auf dieses Modell loslassen?" |
| Kostenoptimierung | Platform Owner | „Welche Spalte zahlt keine Miete, kostet aber Capacity?" |
Was Microsoft nativ liefert — und wo es aufhört
Kurzantwort: Microsoft liefert eine automatische, kostenlose Lineage-Ansicht auf Item-Ebene je Workspace, ergänzt um Impact Analysis und die tenant-weite Landkarte in Purview. Spaltengenaue Lineage über Lakehouse-Transformationen hinweg ist Stand Mitte 2026 nicht out-of-the-box enthalten.
Die Lineage-Ansicht in Fabric
Jeder Fabric-Workspace erzeugt automatisch einen gerichteten Graphen der enthaltenen Artefakte, aufrufbar über die Workspace-Toolbar, das Kontextmenü eines Items oder dessen Detailseite. Sie zeigt Verbindungen zwischen Lakehouses, SQL Analytics Endpoints, Notebooks, Data Pipelines, semantischen Modellen und Berichten sowie die Datenquellen von Modellen und Dataflows. Für einen schnellen Überblick „Was hängt in diesem Workspace womit zusammen?" ist das solide und ohne Zusatzkosten sofort verfügbar.
Die dokumentierten Grenzen
Wichtig ist, dass die folgenden Grenzen keine Vermutungen sind, sondern in der offiziellen Microsoft-Learn-Dokumentation stehen.
Tabelle 4 — Grenzen der nativen Lineage-Ansicht
| Grenze | Konkrete Auswirkung |
|---|---|
| Keine Column-Level-Lineage | Sie sehen, dass Tabelle A Bericht B speist — nicht, welche Spalte in welchem Measure und Visual landet |
| Downstream-Items in anderen Workspaces fehlen | Ein Bericht in Workspace B, der auf ein Modell in Workspace A zugreift, taucht in der Lineage von A nicht auf — nur über die separate Impact Analysis |
| Externe Upstream-Quellen nur eine Ebene | Die Kette hinter der ersten externen Quelle bleibt unsichtbar |
| Viewer-Rolle sieht keine Datenquellen | Governance-Transparenz für Fachanwender eingeschränkt |
| Dataflow-Lineage nur über die Get-Data-UI zuverlässig | Manuell erstellte Mashup-Queries werden nicht korrekt abgebildet |
Impact Analysis als Ergänzung
Die separate Impact-Analysis-Ansicht schließt eine dieser Lücken: Sie findet Downstream-Abhängigkeiten auch über Workspace-Grenzen hinweg. Das ist wertvoll — bleibt aber weiterhin auf Item-Ebene. Sie erfahren, dass ein Bericht betroffen ist, nicht welche Spalte in ihm.
Microsoft Purview: Wie weit trägt der Konzern-Ansatz?
Purview scannt den Fabric-Tenant automatisch und liefert eine tenant-weite Datenlandkarte auf Item-Ebene inklusive Klassifizierung. Spaltengenaue Lineage für Lakehouse-Transformationen ist Stand Mitte 2026 nicht out-of-the-box verfügbar. In der Community entstandene, metadatengetriebene Frameworks extrahieren Column-Level-Lineage aus Fabric-Lakehouses und publizieren sie nach Purview — automatisierbar sind dabei vor allem vorhersagbare Muster (Landing → Bronze, Bronze → Silver, Shortcuts, Umbenennungen). Komplexe Geschäftslogik und proprietäre Berechnungen bleiben Handarbeit.
Merksatz: Purview beantwortet „Welche Assets gibt es und wie hängen sie zusammen?". Es beantwortet nicht „Welche Spalte treibt diese Kennzahl?".
Die Lücke: Warum Column-Level-Lineage in Power BI technisch schwierig ist
Spaltengenaue Lineage scheitert nicht an fehlendem Willen der Hersteller, sondern an einem harten technischen Problem: Ein Werkzeug muss drei verschiedene Sprachen parsen und miteinander verknüpfen — und danach noch klären, wo das Ergebnis konsumiert wird.
Die drei Parsing-Ebenen
SQL / Quellsystem — Views, Stored Procedures, verschachtelte Subqueries. Eine Spalte kann über mehrere View-Ebenen umbenannt werden, bevor sie überhaupt in Power BI ankommt.
Power Query / M — Jeder angewandte Schritt kann Spalten erzeugen, umbenennen, zusammenführen oder entpivotieren. Der Bezug zur Quellspalte ist nur durch Nachvollziehen der gesamten Schrittkette rekonstruierbar.
DAX — Measures referenzieren Spalten indirekt: über andere Measures, über Variablen, über
CALCULATE-Kontexte. Ein Measure kann eine Spalte nutzen, die im Modell selbst nirgends sichtbar verknüpft ist. Hier hilft ein Bild: Die native Lineage-Ansicht ist der Grundriss eines Gebäudes — sie zeigt, welche Räume durch Türen verbunden sind. Column-Level-Lineage ist der Schaltplan dahinter: welches Kabel von welcher Steckdose zu welcher Sicherung läuft. Solange nichts kaputt ist, reicht der Grundriss. Sobald eine Leitung gekappt werden soll, brauchen Sie den Schaltplan.
Und dann die Verwendungsebene
Selbst wenn alle drei Sprachen geparst sind, bleibt die eigentliche Frage: Wo wird das Ergebnis tatsächlich konsumiert? Nicht nur in Diagrammen, sondern in Filtern, Tooltips, bedingter Formatierung, Slicern, paginierten Berichten, Composite Models und angebundenen Excel-Mappen. Ein Werkzeug, das nur „Feld in Diagramm" prüft, übersieht die Mehrheit der realen Abhängigkeiten.
Das ungelöste Randproblem: SSRS, Excel und Legacy
In DACH-Unternehmen endet die Datenkette selten in Power BI. SSRS-/RDL-Berichte, über Jahre gewachsene Excel-Mappen und Crystal Reports hängen an denselben Quellen. Kein Werkzeug, das ausschließlich die Power-BI-Welt kennt, kann diese Kette vollständig abbilden. Genau hier setzt der Graph-Ansatz an.
Wie man Lineage-Werkzeuge bewertet
Bevor Sie Tools vergleichen, brauchen Sie einen Maßstab dafür, welche Reife Ihre Organisation überhaupt benötigt. Ein Werkzeug „zu viel" kostet unnötig Setup; ein Werkzeug „zu wenig" merken Sie erst nach dem nächsten Go-live.
Das Lineage-Reifegradmodell
Tabelle 5 — Reifegrade der Data Lineage
| Stufe | Bezeichnung | Merkmal | Typisches Werkzeug |
|---|---|---|---|
| 0 | Undokumentiert | Wissen liegt bei Einzelpersonen | — |
| 1 | Artefakt-Lineage | Item-Ebene innerhalb eines Workspace | Native Fabric-Ansicht |
| 2 | Tenant-Lineage | Item-Ebene tenant-weit, katalogisiert | Microsoft Purview |
| 3 | Spalten-Lineage | Column-Level innerhalb der BI-Plattform | Power-BI-Spezialtools |
| 4 | Cross-Stack-Lineage | Spalten-Lineage über SQL, SSRS, Excel und BI hinweg in einem Graphen | Graph-basierte Plattformen |
| 5 | Aktive Lineage | Der Graph prüft Änderungen vorab (Pre-flight) und heilt Regelverstöße | Agentic-BI-Plattformen |
Die ehrliche Einordnung: Für ein kleines, sauber gehaltenes Modell in einem einzigen Workspace reicht Stufe 1–2 vollkommen. Der Sprung auf Stufe 4–5 lohnt sich, sobald Migrationsvorhaben, Legacy-Bestände oder regulatorische Nachweispflichten ins Spiel kommen.
Sieben Prüffragen für die Toolauswahl
Erreicht das Tool die Spaltenebene — oder endet es beim Dataset?
Parst es DAX und M , oder nur die Modell-Metadaten?
Deckt es die Verwendung in Filtern, Tooltips und bedingter Formatierung ab, nicht nur in Visuals?
Bezieht es Nicht-Power-BI-Assets (SQL, SSRS, Excel) in denselben Graphen ein?
Läuft die Analyse lokal , oder verlassen Metadaten das Haus? (Relevanz für die DSGVO-Freigabe)
Ist die Lineage nur lesbar, oder kann sie Änderungen vorab simulieren ?
Lässt sich das Ergebnis exportieren und auditierbar archivieren ?
Der Markt im Überblick
Tabelle 6 — Werkzeugkategorien
| Kategorie | Beispiele | Stärke | Grenze |
|---|---|---|---|
| Nativ | Fabric Lineage View, Impact Analysis | Kostenlos, sofort verfügbar | Item-Ebene |
| Konzern-Katalog | Microsoft Purview | Tenant-weite Landkarte, Klassifizierung | Column-Level für Lakehouse-Transformationen nicht out-of-the-box |
| Power-BI-Spezialisten | Measure Killer, Tabular Editor, ALM Toolkit | Tiefe innerhalb des Modells, Source-to-Visual | Kein Blick über die BI-Plattform hinaus |
| Enterprise-Kataloge | Atlan, IBM Manta, Dataedo | Breite Stack-Abdeckung, DAX-Parsing | Aufwand, Kosten, Cloud-Verarbeitung |
| Graph-Plattformen | ABIS (DBI Analytics) | Cross-Stack-Graph, Pre-flight, lokal | Setup-Aufwand, Desktop-gebunden |
Der Graph-Ansatz: Das semantische Modell als vollständiges Bild
Sobald Lineage unterhalb der Item-Ebene ansetzen soll, ist eine Liste von Abhängigkeiten das falsche Datenmodell — ein typisierter Graph aus Knoten und Kanten ist das richtige. Erst er macht das semantische Modell als vollständiges Bild sichtbar: von der Quellspalte über Measure-Ketten bis in das einzelne Visual und den einzelnen Filter.
Anatomie eines vollständigen Modellbilds
Damit das Bild vollständig ist, muss der Graph mehr Objekttypen kennen, als die native Ansicht überhaupt darstellt. Die folgenden beiden Tabellen stammen aus einem real erhobenen Modellgraphen.
Tabelle 6a — Knotentypen eines Power-BI-Lineage-Graphen
| Knotentyp | Beispiel | In nativer Fabric-Lineage sichtbar? |
|---|---|---|
| Data Source | DWH-Tabelle / View | Ja (eine Ebene) |
| Table | Faktentabelle im Modell | Nein (nur das Modell als Ganzes) |
| Column | einzelne Modellspalte | Nein |
| Measure | DAX-Measure | Nein |
| Report Page | Berichtsseite | Nein |
| Visual | Diagramm, Karte, Slicer, Pivot, Textbox | Nein |
| Filter | Visual-, Seiten- und Berichtsfilter | Nein |
Tabelle 6b — Kantentypen (typisierte Beziehungen)
| Kante | Bedeutung |
|---|---|
sources_to | Quelle speist Modelltabelle |
references | Spalte/Measure referenziert Spalte/Measure (DAX-Abhängigkeit) |
relationship | Modellbeziehung Spalte-zu-Spalte |
uses / used_by | Seite/Visual konsumiert ein Feld |
filtered_by | Visual oder Seite wird durch ein Feld gefiltert |
Der oft übersehene Teil ist der Filter als eigener Knotentyp . Ein Feld kann in keinem einzigen Diagramm auftauchen und trotzdem jede Zahl auf der Seite bestimmen — als Visual- oder Seitenfilter. Wer nur „Feld in Visual"-Verwendung prüft, übersieht diese Abhängigkeitsklasse vollständig.
Fallbeispiel: Eine Spalte, 58 abhängige Objekte
Die folgenden Zahlen sind live aus einem realen Modell erhoben (104 Knoten, 353 Kanten; Kunden- und Tabellennamen für die Veröffentlichung generalisiert, die Zahlen sind echt). Ausgangspunkt: eine einzige Faktenspalte — eine Anzahl-Kennzahl in einer wöchentlichen Faktentabelle. Die Graph-Traversierung zeigt:
Tabelle 7 — Downstream-Abhängigkeiten einer einzelnen Spalte
| Ebene | Was hängt daran | Anzahl |
|---|---|---|
| Tiefe 1 | Direkt referenzierende DAX-Measures | 3 |
| Tiefe 2 | Daraus abgeleitete Measures (Ist Gesamt, YTD, Prognose, VJ-Differenz %, …) | 13 |
| Tiefe 2–3 | Visuals, die diese Measures rendern (Combo-Chart, Pivot, Cards, Slicer, Textboxen mit dynamischen Titeln) | 19 |
| Tiefe 2–3 | Visual- und Seitenfilter auf den Measures oder verwandten Spalten | 21 |
| Tiefe 2 | Betroffene Berichtsseiten | 2 |
| Gesamt | abhängige Objekte downstream | 58 |
Die zugehörige Impact-Analyse klassifiziert das Ergebnis: 3 Objekte brechen sicher (direkte Referenzen), 54 können brechen (transitiv), 1 ist entfernt betroffen (Tiefe 4 — ein Alert-Measure, das auf einem Measure auf einem Measure basiert). Risikoeinstufung: kritisch. Dazu ein priorisierter Maßnahmenplan — erst direkte Abhängigkeiten umbauen, dann Berichtsverantwortliche informieren, dann Deprecation-Phase.
Zwei Erkenntnisse sind hier zentral:
Measure-auf-Measure-Ketten sind die unsichtbare Tiefe. Die native Ansicht endet beim semantischen Modell als Item. Real hängen an einer Spalte Ketten über vier Ableitungsebenen: Spalte → Basis-Measure → YTD-Measure → Zielerreichungs-Measure → Alert-Measure. Genau dort entstehen die Fehler, die erst nach dem Go-live auffallen.
Das Verhältnis 1:58 ist der Punkt. Niemand hält 58 Abhängigkeiten einer einzelnen Spalte im Kopf — auch nicht der Entwickler, der das Modell gebaut hat. Ab dieser Komplexität ist Lineage keine Dokumentationsfrage mehr, sondern eine Abfragefrage. Transparenzhinweis: Das Fallbeispiel wurde mit ABIS (DBI Analytics) erhoben; die Konzepte gelten für jeden graphbasierten Lineage-Ansatz.
Vom passiven Bild zur aktiven Prüfung
Wenn der Graph vollständig ist, lässt sich jede geplante Änderung vor der Ausführung gegen ihn simulieren. Aus „Was ist kaputtgegangen?" wird „Was würde kaputtgehen?". Damit erreicht Lineage Reifegrad 5 — und wird vom Nachschlagewerk zum aktiven Schutzmechanismus.
ABIS in der Praxis: Cross-Stack-Lineage als Graph
Wie wir das bei DBI Analytics lösen — der einzige explizit produktbezogene Abschnitt dieses Leitfadens.
Was ABIS ist
ABIS ist eine lokal laufende BI-Governance- und Migrationsplattform von DBI Analytics. Kern ist eine Graph-Engine, die Power BI, SQL Server, SSRS, Excel und CSV-Dateien in einen einzigen verbundenen Lineage-Graphen abbildet. Die Bausteine: abis-core (Graph-Engine), powerbi-sidecar (über 100 Automatisierungswerkzeuge auf dem Tabular Object Model), abis-reporting-mcp (PPTX-/PDF-Reports) und checkpointfähige Migrations-SOPs.
Die fünf Lineage-Fähigkeiten
Alle folgenden Fähigkeiten sind live am Werkzeug verifiziert — die Zahlen aus dem Fallbeispiel oben stammen aus genau diesen Abfragen.
Tabelle 8 — Fähigkeit und die Frage, die sie beantwortet
| Fähigkeit | Beantwortete Frage | Warum das nativ nicht geht |
|---|---|---|
| Cross-Stack-Graph | Wo taucht diese SQL-Spalte über SQL, SSRS, Excel und Power BI hinweg auf? | Native Ansicht endet an der Workspace-Grenze |
| Node Lineage mit Tiefensteuerung | Was ist up- und downstream dieses Knotens, bis Tiefe n, gefiltert nach Kantentyp? | Native Ansicht kennt weder Tiefen- noch Kantentyp-Steuerung |
| Impact Analysis mit Severity | Was bricht, klassifiziert nach „bricht sicher", „kann brechen", „indirekt betroffen", mit priorisiertem Plan? | Item-Ebene ohne Schweregrad |
| Pre-flight (plan_change) | Was passiert, bevor ich es tue? | Nativ gibt es keine Simulation |
| DAX-zu-Graph-Gap-Detection | Welche Measures werden in Visuals referenziert, existieren im Graphen aber nicht mehr? | Verwaiste Measures sind nativ unsichtbar |
In der Praxis heißt das: Die Node Lineage filtert gezielt nach Kantentyp — nur DAX-Referenzen, nur Filter-Beziehungen — und steuert die Tiefe, statt eine unlesbare Gesamtansicht zu produzieren. Die Impact Analysis liefert nicht bloß eine Liste, sondern die im Fallbeispiel gezeigte Dreifach-Klassifikation (3 × bricht sicher, 54 × kann brechen, 1 × indirekt) plus Handlungsempfehlungen in Prioritätsstufen. Das Pre-flight simuliert jede Schreiboperation — Measure-Änderung, Spaltenlöschung, Beziehungsänderung, SQL-Schema-Änderung — zunächst gegen den Graphen und erzeugt einen Risikobericht, bevor irgendetwas ausgeführt wird.
Governance: Von der Analyse zur Heilung
Über dem Graphen sitzt eine konfigurierbare Policy-Ebene aus Compliance-Regeln, Klassifizierern und Blockern. compliance_heal auditiert das gesamte Modell gegen alle Regeln, erzeugt einen priorisierten Heilungsplan mit Kaskadenwirkung je Fix und führt sichere Schritte aus. classify_tables ordnet jede Tabelle automatisch als Dimension, Fakt, Bridge oder Support ein — die Grundlage für die Regelprüfungen. Ein Checkpoint-Trail dient als Audit-Spur für Migrationsprojekte.
Der Migrationsfall: Legacy nach Fabric
Der stärkste Anwendungsfall — und das Kernthema für die DACH-Zielgruppe — ist die Überführung von SSRS- und SQL-Server-Beständen nach Microsoft Fabric. Der Ablauf:
Bestand einlesen — SQL, SSRS/RDL, Excel und bestehende PBI-Modelle in einen Graphen.
Klassifizieren und gegen Regeln prüfen.
Gap-Analyse — verwaiste Measures, ungenutzte Spalten, gebrochene Referenzen.
Änderungen im Pre-flight simulieren.
Migrieren, mit Checkpoints — unterbrochene Sessions setzen exakt an der Abbruchstelle wieder auf.
Statusbericht als PPTX/PDF für Stakeholder erzeugen. Wer diesen Lineage-First-Gedanken auf einen anderen Legacy-Stack übertragen will, findet ihn in unserer Case Study zur KI-gestützten SAS-zu-Oracle-Migration in aller Tiefe wieder.
Datenschutz: Warum lokal ein Architekturargument ist
Der MCP-Server läuft als lokaler Node.js-Prozess über stdio, ohne eigene ausgehende Netzwerkverbindungen, und liest ausschließlich aus dem lokalen Workspace-Ordner. Sobald ein KI-Client angebunden wird, verlässt genau das, was explizit übergeben wird, die Maschine — das gehört klar gesagt. Die daraus folgende Empfehlung: Workflows so gestalten, dass nur strukturelle Metadaten verarbeitet werden — Tabellen- und Spaltennamen, Beziehungsformen, Measure-Ausdrücke — keine Zeilendaten. Bei harter EU-Residency-Anforderung lässt sich die Inferenz über EU-Regionen (z. B. AWS Bedrock Frankfurt) routen. Dieser Punkt ist der eigentliche Differenzierer gegenüber Cloud-Katalogen.
Ehrliche Grenzen
Kein Werkzeug ist für alles die richtige Wahl — auch ABIS nicht:
ABIS verbindet sich mit Power BI Desktop, nicht mit dem Power BI Service. Wer ausschließlich cloud-gehostete Modelle analysieren will, braucht einen anderen oder ergänzenden Weg.
Es setzt eine lokale Desktop-Installation voraus — schwerer als ein reines SaaS-Onboarding.
Für reine Power-BI-Modellarbeit ohne Legacy-Kontext ist ein schlankeres Spezialwerkzeug (etwa aus der Kategorie „Power-BI-Spezialisten" in Tabelle 6) oft die passendere Wahl.
Fazit und nächster Schritt
Data Lineage ist 2026 vom Ordnungswunsch zur Betriebs- und Compliance-Voraussetzung geworden. Microsoft liefert eine solide Basis auf Item-Ebene, aber die teuren Fehler leben eine Etage tiefer — in den Spalten, Measure-Ketten und Filtern, die die native Ansicht nicht kennt. Ein realer Modellgraph mit 58 Abhängigkeiten hinter einer einzigen Spalte macht das greifbar.
Die eigentliche Entscheidung lautet deshalb nicht „native Lineage oder Tool", sondern: Auf welcher Reifegradstufe muss meine Organisation stehen — gemessen an ihren Migrationsvorhaben und ihrer regulatorischen Exposition? Wer nach Fabric migriert, mit Legacy-Beständen aus SSRS und Excel arbeitet oder KI-Agenten auf seine Modelle lassen will, braucht Stufe 4 oder 5. Wer ein kleines, sauberes Modell pflegt, ist mit den Bordmitteln gut bedient.
Der risikoarme nächste Schritt ist klein: eine Cross-Stack-Lineage-Analyse eines bestehenden Power-BI-Modells — daraus entsteht Ihr konkreter Reifegrad und eine belastbare Grundlage, bevor Sie in Werkzeuge investieren.
Häufig gestellte Fragen (FAQ)
Hat Power BI eine eingebaute Data Lineage?
Ja, auf Item-Ebene je Workspace. Jeder Fabric-Workspace erzeugt automatisch einen gerichteten Graphen seiner Artefakte. Spaltengenaue Lineage ist darin nicht enthalten — Sie sehen, dass ein Modell einen Bericht speist, nicht welche Spalte in welchem Visual landet.
Zeigt die Fabric-Lineage-Ansicht Column-Level-Lineage?
Nein. Sie bildet Beziehungen zwischen Artefakten ab — Lakehouse, Modell, Bericht — nicht zwischen Spalten. Für spaltengenaue Nachverfolgung braucht es ein Werkzeug, das Power Query/M und DAX parst.
Was ist der Unterschied zwischen Lineage-Ansicht und Impact Analysis?
Die Lineage-Ansicht zeigt den Graphen innerhalb eines Workspace. Die Impact Analysis findet zusätzlich Downstream-Abhängigkeiten in anderen Workspaces. Beide arbeiten auf Item-Ebene, nicht auf Spaltenebene.
Reicht Microsoft Purview für Data Lineage?
Für tenant-weite Item-Lineage und Klassifizierung: ja. Für spaltengenaue Lineage aus Lakehouse-Transformationen sind Stand 2026 zusätzliche Mittel nötig — Community-Frameworks decken vorhersagbare Muster ab, komplexe Geschäftslogik bleibt manuell.
Wie finde ich heraus, welche Berichte brechen, wenn ich eine Spalte lösche?
Über die Impact Analysis auf Item-Ebene sehen Sie betroffene Berichte. Spaltengenau — welches Measure, welcher Filter, welches Visual — geht das nur mit einem Werkzeug, das M und DAX parst und die Verwendung bis ins einzelne Objekt auflöst.
Ist Data Lineage für die DSGVO verpflichtend?
Die DSGVO fordert den Begriff „Data Lineage" nicht wörtlich. Aber Art. 30 (Verzeichnis von Verarbeitungstätigkeiten) und Art. 15 (Auskunftsrecht) setzen faktisch voraus, dass Sie den Verbleib personenbezogener Daten über alle Verarbeitungen hinweg belegen können.
Was bedeutet der EU AI Act für BI-Systeme?
Ob Pflichten greifen, hängt von der Einstufung des konkreten Anwendungsfalls ab. Wird ein System als hochriskant eingestuft, sind Datenqualität, technische Dokumentation und Protokollierung nachzuweisen — wofür belastbare Lineage die Grundlage ist.
Was ist Cross-Stack-Lineage?
Lineage, die SQL Server, SSRS, Excel und Power BI in einem einzigen Graphen verbindet, statt jede Plattform getrennt zu betrachten. Erst so wird eine Spalte über Systemgrenzen hinweg nachverfolgbar — der Regelfall in gewachsenen DACH-Landschaften.
Warum sind verwaiste DAX-Measures ein Migrationsrisiko?
Sie werden in Visuals referenziert, existieren im Modell aber nicht mehr. Bei einer Migration brechen genau diese Berichte — und meist erst nach dem Go-live, wenn niemand mehr mit dem Zusammenhang rechnet. Nativ sind sie unsichtbar.
Lässt sich Lineage lokal, ohne Cloud-Verarbeitung, erzeugen?
Ja. Graph-basierte Desktop-Werkzeuge analysieren Metadaten lokal. Erst die Anbindung eines KI-Clients verlagert das, was explizit übergeben wird, nach außen — weshalb sich Workflows auf reine Strukturmetadaten beschränken lassen.
Warum reicht es nicht zu prüfen, welche Felder in Visuals verwendet werden?
Weil Filter eine eigene Abhängigkeitsklasse sind. Ein Feld kann in keinem Diagramm auftauchen und trotzdem als Visual- oder Seitenfilter jede angezeigte Zahl bestimmen. Im Fallbeispiel dieses Artikels entfielen 21 von 58 Abhängigkeiten einer einzigen Spalte auf Filter.
Wie tief reichen Measure-Abhängigkeiten in der Praxis?
Vier und mehr Ableitungsebenen sind in gewachsenen Modellen normal: Spalte → Basis-Measure → YTD-Measure → Zielerreichung → Alert. Die native Lineage-Ansicht bildet keine dieser Ebenen ab, weil sie am semantischen Modell als Ganzem endet.
Quellen & Weiterführendes: Microsoft Learn — Lineage in Fabric; Microsoft Learn — Impact analysis; Microsoft Learn — Microsoft Purview (Fabric-Scan). Column-Level-Lineage von Fabric nach Purview via metadatengetriebenem Framework (Erwin de Kreuk, 2026). Measure Killer — Source-to-Visual Lineage (Referenz für die Verwendungsebene). Fallbeispiel Sektion „Eine Spalte, 58 abhängige Objekte" live am ABIS-Graphen eines realen Power-BI-Modells erhoben (17.08.2026); Kunden- und Tabellennamen anonymisiert.