Data Governance & Datenqualität

Wenn Zahlen in verschiedenen Berichten nicht übereinstimmen, leidet das Vertrauen in Daten schnell. Dazu kommen Anforderungen an Datenschutz und Sicherheit, die mit jeder neuen Quelle wachsen. In vielen Unternehmen stehen die Regeln dafür auf dem Papier, geprüft werden sie im Betrieb nicht.

Die Datenstrategie legt fest, wohin ein Unternehmen mit seinen Daten will. Data Governance heißt, dass die Daten im Alltag dafür taugen. Genau diesen operativen Teil setzen wir technisch um. Governance soll die tägliche Arbeit erleichtern, deshalb halten wir den Aufwand klein und fangen dort an, wo ein Fehler am meisten kostet.

Zuerst: wer ist zuständig?

Ohne Zuständige bleibt der Rest Papier. Im Alltag zählen vor allem zwei Rollen. Der Data Owner verantwortet einen Datenbereich fachlich, etwa Kunden- oder Finanzdaten, und entscheidet über Definitionen, Qualitätsanforderungen und Zugriffe. Der Data Steward pflegt im Tagesgeschäft Beschreibungen und Stammdaten, bearbeitet Qualitätsmeldungen und ist Ansprechperson. Wie solche Rollen gefunden und in der Organisation verteilt werden, ist Teil der Datenstrategie.

Beide Rollen funktionieren nur mit Zeit und Mandat. Ein Eintrag im Katalog ohne tatsächliche Zuständigkeit ändert nichts. Meldungen aus der Qualitätsprüfung gehen deshalb direkt an die benannte Person. Kennzahlen wie „Umsatz“ oder „aktiver Kunde“ werden in der Datenmodellierung definiert. Governance stellt sicher, dass es für jede Definition eine verantwortliche Person gibt und dass man sie findet.

Qualität messen statt behaupten

Datenqualität lässt sich nur verbessern, wenn man sie misst. Wir legen mit den Fachbereichen Regeln fest und prüfen sie bei jedem Ladevorgang automatisch. Fehlen Werte, die vorhanden sein müssten? Sind Schlüssel und Kundennummern einmalig? Entsprechen Werte dem erwarteten Format, und stimmen die Beziehungen zwischen Tabellen? Sind die Daten rechtzeitig eingetroffen, und liegen Summen, Mengen und Verläufe im erwarteten Bereich?

Umgesetzt wird das mit dem, was meist ohnehin im Einsatz ist: Tests in dbt oder ein Prüf-Framework, manche Plattformen und Kataloge haben auch eigene Qualitätsfunktionen. Schlägt eine Prüfung fehl, geht eine Meldung an die zuständige Person, und je nach Schwere werden die Daten blockiert oder gekennzeichnet weitergegeben.

Wichtig ist, nicht zu viel auf einmal zu prüfen. Wer täglich Dutzende irrelevante Alarme bekommt, liest bald keinen mehr. Besser ist ein Start mit den Regeln, die den größten Schaden verhindern.

Katalog und Lineage

Ein Datenkatalog verzeichnet Tabellen, Berichte und Kennzahlen mit Beschreibung, Verantwortlichen, Klassifizierung und Herkunft. Er beantwortet die Frage, wo welche Daten liegen und was sie bedeuten. Lineage ergänzt den Weg der Daten von der Quelle über Transformationen bis zum Bericht. Damit lässt sich einschätzen, was eine Änderung betrifft, und bei Fehlern der Ursprung eingrenzen.

Produkte gibt es reichlich, kommerzielle ebenso wie quelloffene. Meist reicht für den Anfang der Katalog, den die eigene Plattform ohnehin mitbringt. Ein übergreifendes Werkzeug lohnt sich eher bei mehreren Plattformen. Entscheidend ist weniger das Produkt als die Pflege: Veraltete Beschreibungen sind schlimmer als keine, weil sie falsche Sicherheit geben. Auch hier gilt, lieber wenige Bereiche mit hohem Nutzen gründlich zu beschreiben, als alle Daten gleichzeitig anzufassen und nirgends fertig zu werden.

Zugriffe, Pseudonymisierung, Löschung

Zugriffe vergeben wir nach Rollen und dem Prinzip der geringsten Rechte, nicht an Einzelpersonen. Rechte für Einzelne sind schwer zu überblicken und werden bei Wechseln im Team selten angepasst. Wo nötig, gelten Einschränkungen auf Zeilen- und Spaltenebene, etwa für Regionen oder Gehaltsdaten. Sensible Daten werden klassifiziert, zum Beispiel als personenbezogen oder vertraulich, und die Klassifizierung steuert Regeln wie Maskierung oder eingeschränkten Zugriff. Zugriffe werden protokolliert. Dauern Freigaben zu lange, weichen Teams auf eigene Lösungen aus, und Self-Service mit klaren Leitplanken funktioniert besser als ein Antragsverfahren.

Bei personenbezogenen Daten kommen zwei Punkte hinzu. Pseudonymisierung ersetzt direkte Kennungen wie Namen durch Schlüssel, sodass Auswertungen ohne direkten Personenbezug möglich sind. Pseudonymisierte Daten gelten dennoch weiter als personenbezogen. Löschkonzepte legen fest, wann welche Daten gelöscht oder anonymisiert werden. Technisch ist das anspruchsvoll, weil Daten in Kopien, Historisierung, Backups und abgeleiteten Tabellen liegen können. Wer nur in der Quelle löscht, lässt den Rest stehen. Wir planen deshalb mit, wo Löschungen überall greifen müssen. Was davon rechtlich verlangt ist, bewertet die Rechtsberatung, wir setzen es technisch um.

Data Contracts und KI-Daten

Ein Data Contract ist eine Vereinbarung zwischen der Seite, die Daten liefert, und der Seite, die sie nutzt. Er beschreibt Struktur, Qualitätsanforderungen, Aktualität und Ansprechpersonen. Mit einem Contract fällt eine Strukturänderung an der Quelle auf, bevor sie Berichte bricht. Dafür gibt es offene Standards wie den Open Data Contract Standard, der Contracts als YAML-Dateien beschreibt, und Vertragsprüfungen in Werkzeugen wie dbt. Die Dateien liegen im Repository und werden in der Pipeline automatisch geprüft. Die Idee passt zu Data Products, bei denen Fachbereiche Daten mit klarer Verantwortung bereitstellen.

Für KI gelten dieselben Grundsätze. Assistenten und Agenten sollen nur Daten sehen, für die die anfragende Person berechtigt ist. Beschreibungen, Qualität und Herkunft der Daten bestimmen, wie gut die Antworten ausfallen. Die rechtlichen Anforderungen an KI-Systeme regelt der EU AI Act, den wir im gleichnamigen Schwerpunkt behandeln. Einige Katalogwerkzeuge stellen Beschreibungen, Lineage und Berechtigungen bereits über Schnittstellen wie das Model Context Protocol für Assistenten bereit. Das ist ein Grund mehr, Metadaten sauber zu pflegen.