Datenprovenienz vs. Datenherkunft: Den Unterschied verstehen

Die Begriffe „Datenprovenienz” und „Datenherkunft” (Data Provenance und Data Lineage) werden oft so verwendet, als ob sie dasselbe bedeuten, aber sie beantworten unterschiedliche Fragen. Die Datenherkunft (Lineage) beschreibt den gesamten Weg, den Daten von der Quelle bis zum Ziel zurücklegen. Die Provenienz ist im Wesentlichen eine Beweiskette – sie zeigt, woher die Daten stammen, wer sie verarbeitet hat und was ihre Vertrauenswürdigkeit belegt. Die Datenherkunft ist in der Regel auch eher technischer und operativer Natur, während die Provenienz eher auf Governance und Compliance ausgerichtet ist.

Der Rest dieses Leitfadens erklärt die Nuancen zwischen Provenienz und Datenherkunft, wo die Unterscheidung in der Praxis am wichtigsten ist und warum KI-Governance es viel schwieriger macht, die Provenienz zu ignorieren.

Hier ist ein Vergleich der beiden anhand der Dimensionen, die für Governance, Compliance und KI am wichtigsten sind.

Der einfachste Weg, die beiden zu trennen, ist dieser: Bei Lineage geht es um den Fluss, bei Provenienz um den Beweis. Lineage ist das, was sich Engineers ansehen, wenn ein Job fehlschlägt, sich eine Metrik ändert oder eine Migration geplant wird. Provenienz wird wichtiger, wenn die Frage nicht nur lautet, wie sich Daten bewegt haben, sondern ob die Quelle und die Handhabung den Standards entsprechen, die für eine Entscheidung, ein Audit oder ein Modell-Release erforderlich sind.

Es gibt natürlich Überschneidungen. Beide beschreiben, was im Laufe der Zeit mit Daten passiert ist. Aber sie organisieren diese Historie unterschiedlich. Lineage organisiert sie als Pfad durch Systeme und Transformationen, während Provenienz sie als historische Aufzeichnung von Herkunft, Verwahrung, Kontext und Vertrauenssignalen organisiert.

Ein Lineage-Graph kann Ihnen sagen, dass ein Modell-Feature letztendlich aus drei Upstream-Tabellen stammt. Ein Provenienz-Datensatz kann Ihnen sagen, ob diese Tabellen aus autorisierten Daten erstellt, unter akzeptablen Bedingungen erfasst, auf Bias überprüft und vor ihrer Verwendung korrekt getaggt wurden.

Diese Unterscheidung ist heute wichtiger, da KI-Systeme die Kosten von Unklarheiten erhöhen. Eine weltweite Umfrage von McKinsey aus dem Jahr 2025 ergab, dass 47 % der Befragten angaben, dass ihre Unternehmen mindestens eine negative Folge durch die Nutzung von GenAI erfahren haben. Infolgedessen verbessern Unternehmen ihre KI-Governance und zentralisieren Risiko- und Data Governance-Funktionen, um mit diesen KI-bezogenen Folgen umzugehen. Da KI zunehmend in Produktions-Workflows integriert wird, benötigen Teams sowohl den Transformationspfad als auch den Vertrauensnachweis hinter den Daten, die diese Systeme verbrauchen.

Teams verlassen sich in der Regel auf Lineage, wenn sie Abhängigkeiten über Pipelines hinweg nachverfolgen, verstehen müssen, wie Daten in einen Bericht oder ein Modell gelangt sind, und die nachgelagerten Auswirkungen einer Schema-, Logik- oder Plattformänderung bewerten müssen. Betrachten Sie die folgenden Anwendungsfälle.

Bevor ein Team eine Quelltabelle ändert, ein Feld als veraltet markiert oder eine Transformation umschreibt, zeigt Lineage die nachgelagerten Objekte, die mit dieser Entscheidung verbunden sind. Lineage ist eine Möglichkeit, Beziehungen zwischen Objekten zu verstehen und die Auswirkungsanalyse zu unterstützen. Genau das benötigen Teams, wenn sie den Auswirkungsradius einer Änderung kennen möchten, bevor sie die Produktion erreicht.

Wenn ein Bericht falsch aussieht, hilft Lineage dabei, das Problem durch den Stack zurückzuverfolgen. Dies könnte bedeuten, die Upstream-Tabelle zu finden, die nicht mehr aktualisiert wird, den View, dessen Logik sich geändert hat, oder die Transformation, die eine Typumwandlung oder einen Filter mit unbeabsichtigten Auswirkungen eingeführt hat. Da Lineage sowohl Datenbewegungen als auch Abhängigkeiten erfasst, ist es nützlich, um Fehler sowohl über materialisierte Pfade als auch über referenzierte Objekte hinweg zu verfolgen.

Migrationsarbeiten werden riskant, wenn Abhängigkeiten nur teilweise bekannt sind. Ein Programm zur Warehouse-Modernisierung, eine Plattformkonsolidierung oder ein Redesign der semantischen Ebene hängt davon ab, zu wissen, welche Objekte welche Ausgaben speisen, welche Transformationen dazwischen liegen und welche nachgelagerten Konsumenten sich noch auf den alten Pfad verlassen. Die besten Lineage-Lösungen bieten Transparenz über Plattformen und Tools hinweg, was wertvoll ist, wenn Architekturen mehr als eine Plattform umfassen.

Es gibt auch Compliance-Fälle, in denen Lineage wichtig ist, weil es um Bewegung geht. Wenn ein Unternehmen zeigen muss, wo personenbezogene oder sensible Daten über Systeme hinweg fließen, um Vorschriften wie die DSGVO oder den CCPA einzuhalten, bietet Lineage eine strukturierte Möglichkeit, diesen Pfad zu verfolgen und die nachgelagerten Assets zu identifizieren, die mit einer verwalteten Quelle verbunden sind. Das ist nicht dasselbe wie der Nachweis der ursprünglichen Legitimität der Daten, aber es ist unerlässlich, um die Exposition, Verbreitung und den operativen Umfang zu verstehen.

Um mehr darüber zu erfahren, wie automatisiertes Data-Lineage-Tracking Daten über Systeme hinweg abbildet und wie es Governance und Compliance stärkt, lesen Sie Data-Lineage-Tracking: Wie es funktioniert.

Teams greifen auf Provenienz zurück, wenn sie überprüfen müssen, woher ein Dataset stammt, wer es erstellt oder geändert hat, welche Kontrollen dafür gelten und ob es einem Audit, einer Überprüfung oder einer Modellvalidierung standhält.

Provenienz ist immer dann wichtig, wenn Daten für einen neuen Zweck verwendet werden, insbesondere für folgenreiche Zwecke. Es hilft Teams festzustellen, ob die Daten auf eine Weise erfasst wurden – von den richtigen Parteien, unter den richtigen Bedingungen, mit der richtigen Zustimmung oder Autorisierung –, die das, was jetzt vorgeschlagen wird, legitim unterstützt. Access History, Richtlinienreferenzen und vererbte Governance-Metadaten tragen alle zu diesem Bild bei.

Hier wird Provenienz besonders wichtig. Frameworks für verantwortungsvolle KI stützen sich alle auf Provenienz-Metadaten, und Artikel 10 des EU AI Act besagt, dass Trainings-, Validierungs- und Testdatensätze für Hochrisiko-KI-Systeme Data Governance- und Managementpraktiken unterliegen müssen, die dem beabsichtigten Zweck des Systems angemessen sind.

Provenienz ist nicht nur ein EU-Thema, aber der EU AI Act hat explizit gemacht, was viele interne KI-Governance-Programme bereits benötigen: Nachweise darüber, woher Trainingsdaten stammen, wie sie aufbereitet wurden und ob sie unter angemessenen Kontrollen überprüft wurden.

Mangelhafte Provenienz wird schnell zu einem praktischen Problem. Wenn Teams die Herkunft und Handhabung von Trainingsdaten nicht verifizieren können, ist die Wahrscheinlichkeit größer, dass Modelle Ergebnisse liefern, die von veralteten, verzerrten, qualitativ minderwertigen oder aus ungeeigneten Quellen stammenden Eingaben geprägt sind. Und sobald ein Modell Kundenentscheidungen, interne Genehmigungen oder regulierte Geschäftsprozesse beeinflusst, wird mangelhafte Provenienz zu einem erheblichen Risikofaktor.

Wenn sensible Daten an einem unerwarteten Ort auftauchen oder wenn ein Team rekonstruieren muss, was während einer Richtlinienverletzung oder eines Sicherheitsvorfalls passiert ist, hilft Provenienz dabei, die Beweiskette nachzuvollziehen. Access History ist hier nützlich, da sie Benutzer, Abfrage, aufgerufene Objekte, geänderte Objekte und referenzierte Richtlinien auf eine Weise verknüpft, die Audits zur Einhaltung gesetzlicher Vorschriften erleichtert.

Forschungs-, klinische und wissenschaftliche Umgebungen benötigen oft Reproduzierbarkeit und eine nachvollziehbare Handhabung, nicht nur Pipeline-Transparenz. Eine Lineage-Map kann zeigen, dass ein Dataset die richtige Abfolge von Systemen durchlaufen hat. Provenienz befasst sich mit der schwierigeren Frage, ob die zugrunde liegenden Daten auf eine Weise erstellt, erfasst, überprüft und gepflegt wurden, die das Vertrauen in das Ergebnis stärkt.

Dies sind sich ergänzende Funktionen, keine konkurrierenden. Lineage ohne Provenienz verrät Ihnen, wie sich Daten bewegt haben, aber nicht, ob die Quelle angemessen oder vertrauenswürdig war. Provenienz ohne Lineage verrät Ihnen, dass der Quelle vertraut werden kann, aber nicht, was passierte, nachdem die Daten in die Plattform gelangt sind. Ausgereifte Governance-Programme benötigen beides.

Stellen Sie sich eine Bank vor, die Kundendaten in einem Kreditrisiko-Workflow verwendet. Provenienz hilft dabei, nachzuweisen, dass die Quelldaten über autorisierte Kanäle erfasst und angemessen verwaltet wurden. Lineage zeigt dann, wie sich diese Daten durch Transformationen, Feature Engineering, Modelle und nachgelagerte Berichte bewegt haben. Ohne beide Sichten bleibt dem Unternehmen entweder ein unvollständiges technisches Bild oder ein unvollständiges Bild in Bezug auf die Vertrauenswürdigkeit.

Das ist auch der Grund, warum KI-Governance diese beiden Konzepte näher zusammenbringt. Ein Modell-Team benötigt möglicherweise Lineage, um nachzuverfolgen, welche Feature-Ansicht, welches Dataset und welche Modellversion miteinander verbunden sind. Dasselbe Team benötigt möglicherweise Provenienz, um zu erklären, woher die zugrunde liegenden Trainingsdaten stammen, welche Kontrollen angewendet wurden und ob das Dataset für den beabsichtigten Verwendungszweck geeignet war.

Erkunden Sie Data-Lineage-Tools: Funktionsweise und die richtige Auswahl, um zu erfahren, worauf Sie bei einer Data-Lineage-Lösung achten sollten.

KI-Governance verändert die Anforderungen von Unternehmen an ihre Datensätze. Sobald ein KI-Modell einen kritischen Vorgang oder eine kritische Entscheidung beeinflusst, wird Provenienz unverzichtbar. Wenn Fragen zur Ausgabe eines Modells auftauchen, bleibt das Problem selten auf die Modellarchitektur oder das Prompt-Design beschränkt. Oft führt es zurück zu den Daten selbst: ob sie angemessen erfasst wurden, ob sie die richtige Population oder den richtigen Geschäftskontext widerspiegeln, ob sie unter den richtigen Kontrollen überprüft wurden und ob diese Entscheidungen so dokumentiert wurden, dass ein technisches Team, ein Auditor oder ein Governance-Verantwortlicher sie später rekonstruieren kann.

Der EU AI Act ist ein sichtbares Zeichen für diesen Wandel, aber der zugrunde liegende Druck ist umfassender als jede einzelne Vorschrift. Unternehmen auf der ganzen Welt stehen vor der Frage, ob Modelleingaben angemessen verwaltet wurden oder ob eine Ausgabe erklärt und verteidigt werden kann. Interne Prüfteams, Kunden, Auditoren und geschäftliche Stakeholder benötigen möglicherweise alle Nachweise dafür, dass die Daten hinter einem Modell auf eine Weise gehandhabt wurden, die den beabsichtigten Verwendungszweck unterstützt.

Ohne diese Aufzeichnung treten Probleme in Trainingsdaten oft erst spät zutage – in Form von ungenauen Ausgaben, verzerrten Empfehlungen oder schlechter Entscheidungsfindung. Provenienz hilft Teams dabei, die Verbindungen zwischen Modellverhalten und Datenhistorie zu identifizieren, indem sie ihnen eine klarere Aufzeichnung von Herkunft, Handhabung und Governance über den gesamten Lebenszyklus der Daten bietet, von denen KI-Systeme abhängen.

In der Praxis sollten sich Unternehmen nicht zwischen Lineage und Provenienz entscheiden müssen. Sie benötigen Lineage, um nachzuverfolgen, wie sich Daten durch Pipelines, Modelle und nachgelagerte Assets bewegt haben, und sie benötigen Provenienz, um zu verstehen, ob die Quelle und Handhabung dieser Daten die nun damit verbundene Nutzung unterstützen. Da KI-Governance, Audit-Erwartungen und funktionsübergreifende Überprüfungen immer anspruchsvoller werden, besteht die Herausforderung darin, beide Arten von Transparenz in einer nutzbaren, aktuellen Form aufrechtzuerhalten.

In Snowflake werden Lineage- und Provenienz-bezogene Signale durch eine Reihe miteinander verbundener Funktionen bereitgestellt. Beziehungen zwischen Objekten werden auf Objekt- und Spaltenebene nachverfolgt, während Access History, Tag-Lineage und ML-Lineage zusätzlichen Kontext darüber liefern, wie Daten verwendet, verwaltet und mit nachgelagerten KI-Assets verbunden wurden. Snowflake Horizon bietet die umfassendere Discovery- und Governance-Schicht, die Teams dabei hilft, mit diesem Kontext in der gesamten Umgebung zu arbeiten.

Für eine Provenienz-orientierte Transparenz zeichnet die Access History (ACCESS_HISTORY) auf, wann Abfragen Daten gelesen oder geschrieben haben, und verknüpft Benutzer, Abfragen, Objekte, Spalten und referenzierte Richtlinien auf eine Weise, die Audits unterstützt. Snowflake stellt außerdem Tag-Lineage-Metadaten über TAG_REFERENCES_WITH_LINEAGE bereit, was Teams dabei hilft zu verstehen, ob Governance-Tags direkt angewendet oder über verwandte Objekte hinweg vererbt wurden.

Snowflake erweitert Lineage zudem über native Objekte hinaus. External Lineage bringt Lineage-Informationen aus externen ETL-Tools und Quelldatenbanken mithilfe von OpenLineage-kompatiblen Ereignissen in den nativen Lineage-Graphen ein und schafft so ein einheitlicheres Bild davon, wie sich Daten über das breitere Ökosystem hinweg bewegen.

Für Workflows in den Bereichen KI und maschinelles Lernen verfolgt ML Lineage die Beziehungen zwischen Quelltabellen, Feature-Ansichten, Datasets, registrierten Modellen und bereitgestellten Modelldiensten. Dies bietet Teams eine Möglichkeit, klassische Lineage-Anforderungen mit Provenienz-orientierten Fragen darüber zu verbinden, welche Daten in welche Modellartefakte eingeflossen sind.