Data Lineage: Warum KI-Agenten Column-Level-Lineage brauchen.

Der Fall ist typisch: Eine Quellspalte wird im Data Warehouse umbenannt, weil der Name nicht mehr zur Fachlichkeit passt. Der Entwickler prüft den einen Bericht, in dem er die Spalte kennt. Drei Wochen später ist ein Vorstands-Dashboard leer — weil die Spalte über 16 Measures, 19 Visuals, 21 Filter und zwei Seiten weiterverwendet wurde, die niemand auf dem Schirm hatte.

Lineage macht diese Kette sichtbar, bevor die Änderung passiert. Die Traversierung läuft vom Ausgangsobjekt über jede Abhängigkeitskante bis zum letzten Visual; das Ergebnis ist eine Liste mit Objekt, Typ, Seite und Verantwortlichem. Diese Liste ist der Änderungsantrag.

• Umbenennung: jedes Measure und jede Berechnung, die den alten Namen referenziert, bricht.
• Typänderung (Text → Zahl, Datum → Text): Filter, Slicer und Zeitintelligenz liefern stille Fehler.
• Abschalten der Spalte: Visuals zeigen leere Flächen, ohne Fehlermeldung für den Leser.

Lineage gibt es in drei Auflösungen. Tabellen-Lineage sagt, welche Tabellen voneinander abhängen — ausreichend für Datenschutz-Nachweise und grobe Impact-Analysen. Spalten-Lineage löst auf, welche Spalte welche andere speist — nötig für jede Änderung an Datentyp oder Name. Ausdrucks-Lineage geht in DAX, SQL und Power Query hinein und zeigt, welche Formel welche Spalte nutzt — die Stufe, die ein Agent braucht, um ein Measure sicher zu ändern.

Die meisten Teams haben Stufe eins über das Lineage-View im Power-BI-Dienst, selten Stufe zwei, fast nie Stufe drei über Werkzeuggrenzen hinweg. Genau diese Lücke — SQL-View, DAX-Measure, Excel-Verknüpfung — ist der Ort, an dem Migrationen und Agentenprojekte scheitern.

Microsoft Fabric zeigt Lineage auf Artefaktebene: Lakehouse, Semantikmodell, Bericht. Das ist Stufe eins und für Betrieb und Berechtigungen wertvoll. Innerhalb eines Semantikmodells zeigt der Dienst zusätzlich, welche Tabellen und Measures existieren — nicht, welches Measure welche Spalte in welcher Formel nutzt, und nicht, welche SQL-View dahinter liegt.

Für Spalten- und Ausdrucks-Lineage wird das Modell deshalb als Metadaten ausgelesen (TMDL, PBIP, BIM) und in einen Graphen überführt, der SQL, DAX und Excel in einer Struktur hält. Das Modell selbst bleibt unverändert; es gehen keine Daten, nur Strukturinformationen in den Graphen.

Ein Sprachmodell, das ein Measure ändern soll, sieht die Formel und den Namen. Es sieht nicht, dass dasselbe Measure in drei weiteren Measures und auf zwei Seiten verwendet wird. Es wird die Änderung vorschlagen, die lokal richtig und global falsch ist — und das überzeugend. Mit Graph bekommt der Agent vor jedem Vorschlag die Abhängigkeitsliste und kann sie in die Begründung aufnehmen: „Diese Änderung berührt elf Objekte, davon zwei im Finanzbericht.“

Daraus folgt die Reihenfolge für jedes Agentenprojekt: zuerst Lineage, dann Semantik, dann Anbindung. Das Reifegrad-Kapitel ordnet ein, auf welcher Stufe Ihr Team steht; die Checkliste unten prüft die sieben Punkte, die vor dem ersten Agenten vorhanden sein müssen.

Lineage wird erst wertvoll, wenn sie in einen Ablauf eingebaut ist. In unseren Projekten läuft jede Änderung am Modell, ob von Mensch oder Agent vorgeschlagen, durch dieselben fünf Schritte. Der Aufwand liegt bei Minuten, nicht Tagen, weil der Graph die Liste liefert und nicht ein Kollege, der sich erinnert.

Die Klassifikation entscheidet über den Freigabeweg: Was sicher bricht, braucht die Freigabe des Verantwortlichen jedes betroffenen Berichts. Was brechen kann, braucht einen Sichttest. Was indirekt betroffen ist, wird informiert.

• 1 Ausgangsobjekt benennen: Tabelle, Spalte oder Measure, das sich ändern soll, plus Art der Änderung (Name, Typ, Formel, Abschaltung).
• 2 Graph traversieren: alle abhängigen Objekte über jede Kante bis zum Visual, als Liste mit Objekt, Typ, Seite, Verantwortlichem.
• 3 Klassifizieren: bricht sicher, kann brechen, indirekt betroffen. Die Klasse folgt aus der Kantenart, nicht aus Einschätzung.
• 4 Pre-flight: die Änderung gegen den Graphen simulieren statt im Produktivmodell testen; verwaiste Objekte und tote Pfade fallen hier mit auf.
• 5 Freigabe mit Protokoll: Wer gibt frei, wann, mit welcher Liste. Das Protokoll ist später die Antwort auf jede Rückfrage.

Vor einer Migration nach Power BI oder Microsoft Fabric beantwortet der Graph drei Fragen, die sonst erst im Projekt auffallen: Was wird überhaupt genutzt, was ist doppelt, und was hängt an welcher Quelle. In einem Modellgraphen mit 104 Knoten und 353 Kanten aus einem laufenden Projekt fanden sich auf diese Weise verwaiste Measures, Spalten ohne einen einzigen Konsumenten und Measure-Ketten über vier Ableitungsebenen, die niemand mehr erklären konnte.

Dieselbe Struktur trägt zwei weitere Nachweise, die sonst von Hand entstehen: Für die DSGVO (Art. 15 Auskunft, Art. 30 Verzeichnis) zeigt der Graph, in welchen Berichten eine personenbezogene Spalte landet. Für die Fabric-Kapazität zeigt er tote Datenpfade, die Refresh-Zeit kosten und keine Miete zahlen.

• Nutzung: Berichte und Measures ohne Konsumenten werden nicht migriert, sondern dokumentiert abgeschaltet.
• Duplikate: gleiche Formel unter anderem Namen, gleicher Name mit anderer Formel; beides wird vor dem Umzug bereinigt.
• Quellen: welche SQL-View, welcher Dataflow, welche Excel-Datei welche Spalte speist; die Reihenfolge der Migrationswellen folgt daraus.
• Nachweise: DSGVO-Verbleib personenbezogener Spalten und Kapazitätsverbrauch je Pfad fallen als Nebenprodukt ab.

Ob ein Werkzeug, ein Fabric-Bordmittel oder ein eigener Graph: Die sieben Fragen der Checkliste trennen Lineage, die für Agenten reicht, von Lineage, die nur hübsch aussieht. Die Checkliste als Arbeitsmaterial enthält zu jeder Frage die erwartete Antwort und ein Beispiel aus einem Modell.

• 1 Granularität: Löst das Werkzeug bis zur Spalte und bis in den Ausdruck (DAX, SQL, M) auf, oder nur bis zum Artefakt?
• 2 Systemgrenzen: Verfolgt es die Kette über SQL-View, Power Query, DAX und Excel hinweg, oder endet es an der Werkzeuggrenze?
• 3 Verwendungsebene: Sieht es Filter, Slicer, Tooltips und bedingte Formatierung, oder nur Visuals?
• 4 Aktualität: Entsteht der Graph bei jedem Deployment neu, oder ist er eine Momentaufnahme?
• 5 Impact-Klassifikation: Unterscheidet es bricht sicher, kann brechen, indirekt betroffen?
• 6 Ort der Erzeugung: Wird der Graph lokal aus Metadaten erzeugt, oder müssen Daten oder Modelle in eine fremde Cloud?
• 7 Abfragbarkeit: Kann ein Agent den Graphen vor einem Vorschlag befragen, oder ist er nur ein Bild für Menschen?