Kernaussage: Für einen wirkungsrelevanten KI-Workflow reicht „wir haben freigegebene Daten verwendet“ nicht aus. Ein Release muss aus einem reproduzierbaren Evidenzpaket beantworten: Welche Quelldatensätze und Transformationen haben dieses Feature, Trainingsset oder diesen Retrieval-Index erzeugt? Sind Zweck-, Aufbewahrungs- und Zugriffsbedingungen noch gültig? Welche Kohorten wurden gemessen? Wer hat eine Ausnahme freigegeben? Bauen Sie diese Lineage, bevor Modell oder Index produktiv gehen.
Dies ist ein Engineering-Muster, keine rechtliche Klassifizierung. Artikel 10 der Verordnung (EU) 2024/1689 enthält Anforderungen an Data Governance für Trainings-, Validierungs- und Testdaten von Hochrisiko-KI-Systemen. Ob ein System hochriskant ist, welche Betreiberrolle einschlägig ist und welche sektoralen Pflichten hinzukommen, muss qualifizierte Rechtsberatung für den Einzelfall beurteilen. Die folgende Architektur macht Fakten, Kontrollen und Entscheidungen nachvollziehbar.
Das Betriebsproblem: Ein Modellrelease hat mehr Datenabhängigkeiten als sein Trainingsset
Produktive Teams pinnen oft Modellgewichte, lassen aber die Datenebene veränderlich. Eine Quelltabelle wird aktualisiert, eine Retention-Bedingung ändert sich, eine Feature-Definition driftet oder Dokumente werden neu gechunked und eingebettet. Der Service liefert weiter Antworten; doch das Team kann nicht mehr belegen, welche Evidenz einen Release geprägt hat. Das ist ein Kontrollfehler, auch wenn ein aggregierter Eval-Wert stabil bleibt.
Diese Disziplin ergänzt den KI-Use-Case-Intake als Policy-as-Code: Der Intake hält Zweck, betroffene Gruppen und Verantwortlichkeit fest; das Lineage-System belegt den tatsächlichen Daten- und Artefaktpfad. Ebenso gehört sie zum LLM-Release-Bundle, das die auslieferbare Konfiguration pinnt.
Ein Lineage-Graph, der einen Release stoppen kann
Vergeben Sie für jeden Knoten unveränderliche IDs und für jede Transformation typisierte Kanten. Ein brauchbares Minimum umfasst DataAsset, DatasetVersion, TransformRun, FeatureDefinition, EmbeddingRun, RetrievalIndexVersion, FineTuneRun, EvaluationSuite und ReleaseBundle. Kanten drücken „abgeleitet aus“, „validiert durch“, „für Zweck freigegeben“, „abgelaufen durch“, „evaluiert auf“ und „ausgerollt als“ aus. Zu den Knoten gehören Quellsystem-Referenz, Content- oder Snapshot-Digest, Schema-Version, Owner, Klassifizierung, erlaubter Zweck, Retention-Bedingung, geografische Grenze und Evidenzlink.
Diagramm — kontrollierter Datenpfad: Quellenregister → Contract-Validator → unveränderlicher Dataset-Snapshot → Transformation/Feature- oder Embedding-Run → Kohorten- und Qualitätsevaluation → Freigabe-Gate → signiertes Release-Bundle → Modell oder Retrieval-Index → Request-Trace führt release_id und index_version → Monitoring-Event startet Re-Review oder Rollback.
Der Graph ist kein Data Catalog mit hübscheren Pfeilen. Er muss zwei Fragen schnell beantworten: „Welche Live-Releases enthalten Datensätze aus dieser Quelle?“ und „Welche Vertragsänderung kann diesen Index ungültig machen?“ Bei hoher Komplexität ist eine Graphdatenbank sinnvoll; zunächst sind relationale, immutable Versionstabellen mit expliziten Kanten oft wartungsärmer.
Verträge: Zweck, Aufbewahrung und Qualität ausführbar machen
Jedes ingestierbare Datenasset braucht einen versionierten Vertrag: erlaubte Nutzung, Kohorte, Nachweis zur Erhebungsgrundlage soweit relevant, Sensitivität/Klassifizierung, Retention- oder Review-Ereignis, Produzentenschema, Frischeerwartung, Qualitätsprüfungen, Owner und Ausnahmeweg. Prüfen Sie den Vertrag beim Ingest und erneut bei der Release-Promotion. Ohne technisches Gate wird er zu Dokumentation mit Drift.
Das unterstützt die Prinzipien aus Artikel 5 DSGVO—unter anderem Zweckbindung, Datenminimierung, Richtigkeit und Speicherbegrenzung—sowie Datenschutz durch Technikgestaltung nach Artikel 25. Es bestimmt jedoch keine Rechtsgrundlage und ersetzt keine DPIA; dafür braucht es die Fakten des Verantwortlichen sowie Datenschutz- und Rechtsprüfung.
Entscheidungsmatrix: Gates nach Release-Wirkung wählen
| Release-Kontext | Minimales Evidenz-Gate | Stop-Bedingung | Verantwortliche Rolle |
|---|---|---|---|
| Interner Wissensassistent ohne personenbezogene Daten | Quellen- und Index-Digests, Frischeprüfung, Retrieval-Stichprobe | unbekannte Quelle oder defekter Digest | Data Product Owner |
| Kundenbezogener Workflow | Zweck- und Retention-Vertrag, Kohortenabdeckung, eingefrorener Eval-Slice, Index-Rollback-Ziel | Vertrag abgelaufen, kritische Kohorte unter Schwelle oder Ausnahme offen | Product Owner + Data Owner |
| Potenziell hochriskanter oder grundrechtsrelevanter Workflow | vollständige Lineage bis zur Quelle, dokumentierte Qualitäts-/Bias-Prüfung, unabhängige Freigabe, Release-Evidenzpaket | erforderliche Legal-/Compliance-Prüfung fehlt, Zweck nicht zulässig, Evidenz veraltet oder kritische Kohorte nicht bestanden | verantwortliche Business-Rolle mit Compliance-/Datenschutzprüfung |
Qualitäts- und Bias-Control-Loops
Abdeckung wird gegen die vorgesehene Population und Aufgabe gemessen, nicht aus der Zeilenzahl abgeleitet. Definieren Sie Kohorten vor dem Eval: Sprache, Region, Dokumenttyp, Kanal, Klassenungleichgewicht und seltene, aber folgenreiche Fälle. Speichern Sie Kohortendefinition, Auswahlabfrage, Sample-Snapshot-Digest, Metrikdefinition, Unsicherheitsmethode soweit passend, Reviewer-Notizen und Schwelle. Vergleichen Sie Kandidat und letzten freigegebenen Release auf demselben eingefrorenen Slice.
Für Retrieval-Systeme ist der Index ein datenabgeleitetes Release-Artefakt. Dokumentieren Sie Chunker-Version, Embedding-Modellrevision, Quell-Dokument-Snapshot, ACL-/Policy-Filterversion, Korpusabdeckung und Build-Parameter. Ein Index-Refresh kann verändern, was das Modell sieht, obwohl das Modell unverändert ist. Ein materieller Index-Refresh braucht deshalb denselben Freigabepfad wie eine Modelländerung.
Das NIST Generative AI Profile (AI 600-1) benennt Governance, Content Provenance und Pre-Deployment-Testing als zentrale Betrachtungsfelder. Nutzen Sie dieses Risikomanagement-Framing für proportionale Kohorten, Tests und Eskalationswege; es ersetzt keine domänenspezifische Schadensanalyse.
Ausnahmen sichtbar, befristet und reversibel halten
Eine veraltete Quelle, unvollständige Kohorte oder ein dringender Incident darf keinen Schattenprozess erzeugen. Erfassen Sie ein Ausnahmeobjekt, das mit dem fehlgeschlagenen Vertrag oder Gate verknüpft ist: Begründung, Impact-Bewertung, kompensierende Kontrolle, Freigabe, Scope, Ablauf, Monitoring-Signal und Rollback-Release. Der Deployment-Service akzeptiert nur eine aktive Ausnahme-ID mit engerer Release-Policy. Nach Ablauf hält er weitere Promotion an und erzeugt eine Owner-Aufgabe. Ein fehlgeschlagenes Gate darf nicht stillschweigend zur Warnung werden.
Ausfallmodi, die Sie testen sollten
Lineage endet am Data Lake: Eine Tabelle ist bekannt, Query, Transform-Version oder Snapshot aber nicht. Gegenmaßnahme: Snapshot-/Content-Digests und TransformRun-IDs im Release-Bundle erzwingen.
Aggregierte Qualität verdeckt Kohortenregression: Der Durchschnitt steigt, während deutschsprachige Langdokumente oder eine seltene Klasse schlechter werden. Gegenmaßnahme: stratifizierte Kohorten einfrieren, kritische Floors setzen und Grenzfälle menschlich prüfen.
Retrieval-Refresh umgeht Modell-Governance: Re-Embedding verändert Antworten ohne Model Deployment. Gegenmaßnahme: Index-Versionen als promotable Artefakte mit Evaluation und Rollback behandeln.
Ausnahme wird dauerhaft: Ein Emergency Waiver hat kein Ablaufdatum. Gegenmaßnahme: Ablauf, Scope, kompensierende Kontrolle und retrospektiven Review maschinell erzwingen.
Was dieser Ansatz nicht löst
Lineage kann belegen, was geschehen ist. Sie macht jedoch keine schwache Quelle repräsentativ, beseitigt keinen gesellschaftlichen Bias, stellt keine Rechtskonformität fest und entscheidet nicht über die Zulässigkeit eines Use Cases. Sie verursacht Speicher-, Instrumentierungs- und Review-Aufwand. Kleine, niedrig wirkende Experimente können mit Quellen- und Transform-Digests plus Owner beginnen; bei wesentlichen Auswirkungen brauchen Sie stärkere Evidenz und counsel-geführte Rechtsprüfung.
Praktischer Einstieg
Wählen Sie ein produktives Feature oder einen Retrieval-Index. Inventarisieren Sie seine Quellen, erstellen Sie für die drei wichtigsten Verträge, emittieren Sie immutable Transform- und Index-IDs, frieren Sie zwei kritische Kohorten ein, definieren Sie einen release-blockierenden Qualitäts-Floor und proben Sie den Rollback zum vorherigen Index-/Modellbundle. Wenn Sie Data Contracts, Release Controls und operative Evidenz verbinden müssen, ist ein fokussierter Architekturworkshop der richtige Start.
