Data Governance für KI

Ein generatives KI-System liefert plötzlich widersprüchliche Antworten auf interne Richtlinien. Ein Prognosemodell verschlechtert sich schleichend, weil sich die Datenbasis verändert hat. Ein Fachbereich kann nicht mehr erklären, welche Dokumente ein RAG-System für eine Antwort herangezogen hat. Solche Fälle sind selten ein reines Modellproblem. Meist fehlt Data Governance für KI: die Fähigkeit, Datenherkunft, Qualität, Zugriff, Verwendung und Veränderung über den gesamten KI-Lebenszyklus steuerbar zu machen.

Das Thema ist deshalb keine Verlängerung klassischer Data Governance mit einem zusätzlichen KI-Label. KI erhöht Reichweite und Geschwindigkeit von Datenverarbeitung. Sie kombiniert Quellen, verdichtet Inhalte und erzeugt neue Artefakte – von Embeddings über Features bis zu synthetischen Daten und Modellbewertungen. Damit wachsen auch die Anforderungen an Nachvollziehbarkeit, Schutzbedarf und Verantwortlichkeiten.

Warum Data Governance für KI anders gedacht werden muss

Klassische Data Governance konzentriert sich häufig auf Stammdaten, Reporting, Datenmodelle und definierte Datenprodukte. Das bleibt relevant. Für KI reicht es aber nicht, einen Datenkatalog zu pflegen und Zugriffsrechte zu dokumentieren. Entscheidend ist die Kette von der Quelle bis zur konkreten Systementscheidung oder Antwort.

Bei einem Machine-Learning-Modell gehören Trainings-, Validierungs- und Testdaten zu dieser Kette. Bei einem RAG-System kommen Dokumente, Chunking-Regeln, Embedding-Modell, Index, Retrieval-Konfiguration, Prompt-Vorlagen und die Versionsstände der Komponenten hinzu. Bei Agentic-AI-Systemen muss zusätzlich nachvollziehbar sein, auf welche Daten und Werkzeuge ein Agent zugreifen durfte und welche Aktionen er daraus abgeleitet hat.

Das verändert die Kernfrage. Sie lautet nicht nur: „Sind unsere Daten korrekt?“ Sondern auch: „Welche Daten durften dieses System in diesem Kontext verwenden, und können wir seine Ergebnisse später erklären, begrenzen und prüfen?“

Diese Perspektive verbindet mehrere Governance-Domänen, die in vielen Organisationen getrennt arbeiten: Data Management, Informationssicherheit, Datenschutz, Enterprise Architecture, Legal, Risk und die Teams, die KI entwickeln oder betreiben. Ein zentrales Gremium allein löst dieses Problem nicht. Ohne technisch umsetzbare Regeln bleibt Governance ein Freigabeprozess neben dem eigentlichen Betrieb.

Die Datenkette als Steuerungsobjekt

Der praktikabelste Einstieg ist, nicht mit einem umfassenden Zielbild zu beginnen, sondern mit den Datenketten der priorisierten KI-Anwendungsfälle. Für jede Kette sollte klar sein, welche Quelle genutzt wird, wer sie fachlich verantwortet, welche Qualitätsanforderungen gelten, wo Daten gespeichert und transformiert werden und welche Systeme oder Personen Zugriff erhalten.

Dabei kommt es auf die Granularität an. Für einen internen Wissensassistenten ist es wenig hilfreich, lediglich „SharePoint-Dokumente“ als Quelle zu erfassen. Relevant sind etwa Dokumentklassen, Freigabestatus, Berechtigungsvererbung, Aktualität, Mandantentrennung und Ausschlussregeln. Ein Dokument kann fachlich richtig, aber für einen bestimmten Nutzerkreis oder einen bestimmten Zweck trotzdem ungeeignet sein.

Bei prädiktiven Modellen liegt der Schwerpunkt anders. Hier sind Repräsentativität, Vollständigkeit, zeitliche Gültigkeit und Label-Qualität oft ausschlaggebend. Historische Daten bilden nicht automatisch die Zukunft ab. Werden Prozesse geändert, Sensoren ausgetauscht oder Fachdefinitionen angepasst, kann ein Modell an Aussagekraft verlieren, obwohl die Pipeline technisch fehlerfrei läuft.

Datenqualität ist anwendungsbezogen

„Hohe Datenqualität“ ist kein ausreichend präzises Kontrollziel. Ein KI-System braucht messbare Qualitätskriterien, die zum Risiko und Einsatzzweck passen. Für Retrieval-Anwendungen können Aktualität, Dublettenquote, Dokumentfreigabe und Trefferrelevanz wichtiger sein als lückenlose Feldvollständigkeit. Für Kredit-, Sicherheits- oder Produktionsentscheidungen können Zeitbezug, Abdeckungsgrad, Fehlerquoten und mögliche Verzerrungen kritischer sein.

Diese Kriterien müssen nicht überall identisch streng sein. Ein Pilot mit anonymisierten Daten und begrenztem Nutzerkreis benötigt andere Kontrollen als ein System, dessen Ergebnisse operative Entscheidungen beeinflussen. Governance gewinnt, wenn sie risikobasiert priorisiert wird. Sie verliert, wenn jede Datenverwendung denselben administrativen Prozess durchlaufen muss.

Verantwortlichkeit endet nicht beim Data Owner

Data Owner bleiben unverzichtbar, können aber nicht allein für KI-Ergebnisse geradestehen. Sie verantworten typischerweise Bedeutung, Qualität und zulässige Nutzung einer Datenquelle. Wer ein KI-System betreibt, verantwortet dagegen unter anderem die Auswahl der Datenkette, technische Schutzmaßnahmen, Monitoring und den Umgang mit Fehlern. Fachbereiche wiederum müssen beurteilen, ob Ergebnisse im jeweiligen Prozess sinnvoll und vertretbar eingesetzt werden.

Hilfreich ist eine klare Zuordnung entlang konkreter Entscheidungen: Wer genehmigt eine neue Quelle? Wer bewertet deren Schutzbedarf? Wer darf Retrieval-Regeln ändern? Wer stoppt ein System bei Qualitätsverlust? Wer entscheidet über Aufbewahrung und Löschung von Prompts, Eingaben und Protokollen? Diese Fragen gehören in Betriebs- und Änderungsprozesse, nicht nur in ein Richtliniendokument.

Besonders konfliktträchtig ist der Umgang mit unstrukturierten Informationen. Dokumente enthalten oft vertrauliche Passagen, veraltete Aussagen oder implizite Berechtigungen, die in einem neuen Kontext sichtbar werden können. Eine Freigabe zur Ablage ist keine pauschale Freigabe zur KI-gestützten Auswertung. IT, Informationssicherheit und Fachverantwortliche müssen deshalb Nutzungskontexte getrennt bewerten.

Regulatorik als Architekturfrage

Der EU AI Act rückt Daten-Governance-Anforderungen insbesondere für Hochrisiko-KI-Systeme in den Fokus. Artikel 10 beschreibt Anforderungen an Daten-Governance und Datenmanagement für Trainings-, Validierungs- und Testdatensätze. Dazu zählen unter anderem geeignete Designentscheidungen, Datenerhebung, Aufbereitung, Prüfung möglicher Verzerrungen sowie die Eignung der Daten im Verhältnis zum Zweck.

Für viele Unternehmenssysteme entsteht daraus keine Pflicht, jedes Datenobjekt minutiös zu dokumentieren. Es entsteht aber die Notwendigkeit, begründete und überprüfbare Entscheidungen treffen zu können – gerade dort, wo Menschen, Sicherheit oder wesentliche Geschäftsprozesse betroffen sind. Die technische Architektur entscheidet, ob das realistisch gelingt.

Wenn Datenflüsse nur implizit in Skripten, Notebook-Versionen und Einzellösungen existieren, wird ein Audit zur forensischen Suche. Wenn Herkunft, Transformationen, Zugriffspfade und Modellversionen automatisch erfasst werden, wird Nachweisbarkeit Teil des Betriebs. Das gilt ebenso für Datenschutzanforderungen wie Zweckbindung, Datenminimierung und Löschkonzepte. Ein zentraler Datenbestand kann Governance vereinfachen, ist aber keine Voraussetzung. Föderierte Architekturen funktionieren, wenn Metadaten, Richtlinien und Kontrollmechanismen konsistent zusammenspielen.

NIST beschreibt im AI Risk Management Framework vier zentrale Funktionen: Govern, Map, Measure und Manage. Für IT-Organisationen ist das eine nützliche Einordnung: Data Governance ist nicht die Vorstufe der KI-Entwicklung, sondern eine kontinuierliche Disziplin im Betrieb. Risiken ändern sich, wenn Datenquellen, Modelle, Nutzergruppen oder Prozesse geändert werden.

Kontrollen, die im Betrieb funktionieren müssen

Eine tragfähige Umsetzung verbindet organisatorische Regeln mit technischen Leitplanken. Dazu gehören Datenklassifikation und Zugriffskontrollen ebenso wie Protokollierung, Versionierung und Freigabeworkflows. Entscheidend ist, dass die Kontrollen an den tatsächlichen Datenpfad gekoppelt sind.

Für RAG-Anwendungen bedeutet das beispielsweise, Berechtigungen beim Retrieval durchzusetzen statt sie nur am ursprünglichen Dokumentablageort anzunehmen. Werden Dokumente in einen Vektorindex überführt, müssen Metadaten zu Mandant, Schutzklasse, Gültigkeit und Zugriffsrechten erhalten bleiben. Andernfalls kann ein technisch gut funktionierender Suchmechanismus Informationen über Berechtigungsgrenzen hinweg verfügbar machen.

Bei Trainingspipelines braucht es reproduzierbare Datenschnitte und Versionen. Eine Modellversion ohne nachvollziehbaren Datenstand ist nur begrenzt bewertbar. Ebenso wichtig sind Regeln für Eingabedaten im laufenden Betrieb: Welche Felder dürfen an externe oder interne Modelle übergeben werden? Werden Prompts gespeichert? Lassen sich sensible Inhalte erkennen oder minimieren? Und wie wird verhindert, dass ein System seine eigene, ungeprüfte Ausgabe später wieder als Wissensquelle verwendet?

Monitoring darf dabei nicht bei Infrastrukturmetriken enden. Neben Latenz, Kosten und Verfügbarkeit gehören Datenaktualität, Retrieval-Qualität, Abweichungen in Eingaben sowie Fehlermuster in die Beobachtung. Welche Metriken sinnvoll sind, hängt vom Einsatzfall ab. Eine pauschale Halluzinationsquote ist oft weniger aussagekräftig als eine prüfbare Evaluation für die Aufgaben, die ein System tatsächlich erfüllen soll.

Mit wenigen kritischen Anwendungsfällen starten

Der falsche Startpunkt ist ein mehrjähriges Governance-Programm, das erst vollständige Ordnung in allen Datenbeständen schaffen will. Der bessere Startpunkt sind zwei oder drei KI-Anwendungsfälle mit erkennbarer Relevanz und unterschiedlichen Risikoprofilen. An ihnen lassen sich Rollen, Datenketten, technische Kontrollen und Nachweispflichten konkret testen.

Daraus entsteht schrittweise ein gemeinsamer Mindeststandard: eine nachvollziehbare Inventarisierung der KI-Systeme, dokumentierte Datenquellen, klare Freigabekriterien, Schutzklassifizierung, reproduzierbare Änderungen und ein Verfahren für Incidents. Auch das NIST AI RMF sieht die Inventarisierung von KI-Systemen als Bestandteil einer organisationsweiten Governance vor.

Data Governance für KI ist damit weder ein Bremsklotz noch eine Compliance-Übung. Richtig umgesetzt verkürzt sie die Zeit bis zur verantwortbaren Produktivsetzung, weil Teams nicht bei jeder neuen Anwendung dieselben Grundsatzfragen neu verhandeln müssen. Die entscheidende Frage für deine Organisation lautet daher nicht, ob Governance vor oder nach dem KI-Rollout kommt. Sie lautet, welche Kontrollen so nah an Daten, Code und Betrieb liegen müssen, dass sie auch unter Änderungsdruck noch wirken.