Überwachung der Datenqualität & Data Observability

Dashboards, Berichte und ML-Modelle brechen unbemerkt, wenn vorgelagerte Daten zu spät kommen, doppelt vorliegen, abgeschnitten sind oder abdriften. Die Überwachung der Datenqualität verbindet ausdrückliche Regeln (Tests, Datenverträge) mit gelernten Referenzwerten, die ungewöhnliche Änderungen bei Aktualität, Volumen, Schema und Verteilung melden, und mit LLMs, die Regeln entwerfen, Störungen zusammenfassen und wahrscheinliche Ursachen entlang der Lineage nachverfolgen. Der Nutzen liegt darin, Probleme zu finden, bevor es die Fachanwender tun.

Problem & Nutzen

• Heute: Analysten entdecken falsche Zahlen in einem Bericht; Entwickler schreiben SQL-Prüfungen von Hand für einen Bruchteil der Tabellen; Warnungen sind laut, und niemand weiß, welche Dashboards betroffen sind.
• KI-Nutzen: automatische Referenzwerte je Tabelle und Spalte (saisonbewusst), Regelvorschläge aus der Profilierung, weniger Fehlalarme durch Gruppierung von Warnungen, Hinweise auf Ursachen aus Lineage und jüngsten Änderungen, Zusammenfassungen von Störungen in natürlicher Sprache.
• Warum es in der EU wichtig ist: Die DSGVO Art. 5 Abs. 1 Buchst. d verlangt, dass personenbezogene Daten sachlich richtig sind; die KI-Verordnung (AI Act) Art. 10 verlangt Daten-Governance für Trainingsdaten von Hochrisiko-Systemen; BCBS 239 und Solvency II legen im Finanzwesen Pflichten zur Datenqualität auf. Anbieter veröffentlichen ROI-Behauptungen; behandeln Sie diese als Marketing, sofern sie nicht durch Ihre eigene Ausgangslage gestützt sind.

Varianten

• Analyse-Stack im KMU: dbt-Tests plus Aktualitätsprüfungen auf einem einzelnen Data Warehouse, Warnungen an den Chat.
• Unternehmensweite Datenplattform: Observability über hunderte Pipelines, Auswirkungsanalyse auf Basis der Lineage, Datenverträge zwischen Domänen (Data Mesh).
• ML-/Feature-Daten: Überwachung von Drift und Abweichungen zwischen Training und Betrieb, siehe CODE-018.
• Regulatorisches Berichtswesen: Qualitätsschranken vor Meldungen an die Aufsicht oder ESG-Berichten (DATA-012, DATA-020).
• Öffentlicher Sektor / Open Data: Qualitätsbewertung veröffentlichter Datensätze.
• Stammdaten: Die Qualität von Abgleich und Zusammenführung wird über DATA-003 verfolgt.

So funktioniert es

1. sources (warehouse, lakehouse, streams, orchestrator, BI)
2. metadata & metric collection (row counts, freshness, schema, profiles, query logs)
3. rules layer (declarative tests, data contracts, constraints)
4. learned monitors (time-series baselines, anomaly detection per metric)
5. lineage graph (upstream cause, downstream impact)
6. LLM layer (rule suggestion, incident summary, fix proposal as pull request)
7. alert routing (ticket/chat, owner from catalogue)
8. human triage
9. resolution & feedback

• Regeln: deterministische Prüfungen (nicht leer, eindeutig, referenzielle Integrität, zulässige Werte, Aktualität). LLMs können sie aus Profilen und Schema vorschlagen, doch ein Mensch genehmigt.
• Gelernte Monitore: Prognosen je Kennzahl mit Vorhersageintervallen; Warnung, wenn die Istwerte das Band verlassen. Klassische Statistik und Gradient Boosting genügen meist; tiefe Modelle zahlen sich selten aus.
• Ursache: Lineage plus Änderungshistorie (Deployments, Schemamigrationen, fehlgeschlagene Jobs) grenzt die Kandidaten ein; ein LLM fasst die Belege zusammen, muss sie aber angeben.
• Mensch-in-der-Schleife (Human-in-the-Loop): Datenverantwortliche bestätigen oder verwerfen Warnungen; Rückmeldungen justieren die Empfindlichkeit. Einen Pipeline-Lauf bei einer fehlgeschlagenen Prüfung zu blockieren, ist eine Richtlinienentscheidung, keine KI-Entscheidung.

Datenaufbereitung

Die Überwachung braucht Zugriff auf Tabellen und Pipeline-Metadaten in ERP, Data Warehouse, BI-Werkzeug und auf die Dateien, die Excel-Berichte speisen. Typische Lücken: keine vereinbarte Definition von „korrekt“, fehlende Verantwortliche, nicht dokumentierte Transformationen, manuell gepflegte Excel-Eingaben, keine Referenzwerte oder Historie und Warnungen, für die niemand zuständig ist.

Aufbereitungsschritte: 1. Kritische Datensätze erfassen und nach geschäftlicher Auswirkung ordnen (PREP-001, PREP-002). 2. Daten zuverlässig über APIs oder Konnektoren statt über manuelle Exporte beziehen (PREP-005). 3. KPI-Definitionen und gültige Wertebereiche mit der Fachabteilung dokumentieren (PREP-012). 4. Pro Datensatz einen Verantwortlichen benennen (PREP-004) und vereinbaren, was bei einer Warnung geschieht. 5. Mit einfachen Regeln beginnen (Aktualität, Volumen, leere Werte, Eindeutigkeit), die KI weitere Regeln aus der Profilierung vorschlagen lassen und diese von den Verantwortlichen genehmigen lassen. 6. Bestätigte Störungen als gelabelte Beispiele für die Anomalieerkennung sammeln (PREP-020).

Werkzeuge: Great Expectations, Soda Core, dbt-Tests. Grober Aufwandsanteil: etwa 30 bis 40 Prozent, überwiegend für die Festlegung von Erwartungen und Zuständigkeiten statt für das Programmieren von Prüfungen. Siehe auch DATA-007 und DATA-003.

Umsetzungswege

Welcher Weg für wen

• smb: Weg C. Great Expectations, Soda Core oder dbt-Tests laufen auf HW1, halten die Daten im Unternehmen und bedienen dieselben Prüfungen über mehrere Pipelines hinweg.
• enterprise: Weg B. Pipelines sind geschäftskritisch und vielfältig; kombinieren Sie eigene Tests mit Cloud-KI-Diensten für Regelvorschläge und Ursachenerklärungen auf Metadaten, oder kaufen Sie für Standardbedürfnisse eine Observability-Plattform.
• developer: Weg C. Open-Source-Test-Frameworks integrieren sich direkt in CI und Orchestrierung und geben volle Kontrolle.
• public: Weg C. Open-Source-Werkzeuge auf souveräner Infrastruktur halten operative Daten in der Verwaltung und vermeiden Abhängigkeiten.

Weg A — Kaufen (Standardsoftware)

• Data-Observability-Plattformen: Monte Carlo, Bigeye, Anomalo, Acceldata, Sifflet (EU, Frankreich), Soda Cloud (EU, Belgien), Telmai, Metaplane (Datadog), Validio (EU, Schweden), Synq (EU, Dänemark).
• Katalog-/Governance-Suiten mit Qualitätsmodulen: Collibra, Informatica, Ataccama (EU, Tschechien), Alation, Atlan, Talend/Qlik.
• Warehouse-nativ: Snowflake-Datenqualitätsüberwachung und Data Metric Functions, Databricks Lakehouse Monitoring und Unity Catalog, BigQuery-/Dataplex-Datenqualitätsscans, Microsoft Purview.
• Wählen Sie A, wenn: viele Pipelines, ein kleines Datenteam und der Bedarf an schneller Anomalieabdeckung ohne das Schreiben von Regeln bestehen. Prüfen Sie das Hosting in der EU, ob nur Metadaten (keine Zeilendaten) Ihre Umgebung verlassen, und die Lineage-Abdeckung für Ihren Stack.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Kennzahlen in SQL in Ihrem Data Warehouse berechnen, in einer Kennzahlentabelle speichern und die Prognose mit den eingebauten Anomaliefunktionen des Warehouse oder einem verwalteten Zeitreihendienst durchführen.
• Eine LLM-API (EU-Region oder EU-Anbieter wie Mistral) nutzen, um Tests zu entwerfen, fehlgeschlagene Läufe aus Protokollen zusammenzufassen und dbt-/SQL-Korrekturen vorzuschlagen. Senden Sie nach Möglichkeit Metadaten und Aggregate, keine Rohzeilen.
• Mit Airflow, Dagster oder Prefect orchestrieren; Warnungen per Chat und Ticketsystem. Wählen Sie B für individuelle Abläufe auf einem bestehenden Data Warehouse.

Weg C — Selbst betreiben (Open Source)

• Testen: Great Expectations (GX Core), Soda Core, dbt-Tests und dbt-expectations, Pandera, Deequ (Spark), Pydantic/Frictionless für Dateien.
• Observability: Elementary (dbt-native Anomalietests und Berichte), OpenLineage mit Marquez oder DataHub/OpenMetadata für Lineage und Qualität, Evidently für Drift in ML-Daten.
• Datenverträge: datacontract-cli mit dem Open Data Contract Standard.
• LLM-Unterstützung: Ein kleines Open-Weight-Modell (z. B. Qwen3 oder Mistral Small über Ollama/vLLM) genügt für Regelentwürfe und Zusammenfassungen; die Kennzahlenprognose läuft auf der CPU.
• Hardware: HW1; ein CPU-Server genügt, optional HW2 für lokale LLM-Unterstützung. Der Betriebsaufwand ist gering bis mittel.

Weg D — Eigenes Training

Selten nötig. Erwägenswert für domänenspezifische Anomaliemodelle (z. B. Datenqualität von Sensoren, DATA-016) oder ein per Feintuning angepasstes Modell, das Regeln in Ihrem Hausstil erzeugt. Erfordert gelabelte frühere Störungen; die meisten Organisationen haben zu wenige, beginnen Sie daher mit den Wegen A-C.

Stand der Technik (2026)

• Zusammenführung: Test-Frameworks, Kataloge, Lineage (OpenLineage) und Observability wachsen zu einer gemeinsamen „Data-Reliability“-Schicht zusammen; Anbieter ergänzen LLM-Assistenten für die Regelerzeugung, Fragen zu Störungen in natürlicher Sprache und agentische Triage.
• Datenverträge verlagern Qualitätsprüfungen nach vorn zu den Datenlieferanten; Vertragstests laufen vor dem Deployment in der CI.
• Unüberwachte Monitore funktionieren gut bei Volumen, Aktualität und Schema und mäßig bei Verschiebungen der Verteilung; fachlich-semantische Fehler (eine gültige, aber falsche Währung) brauchen weiterhin ausdrückliche Regeln oder Domänenwissen.
• Grenzen: Alarmmüdigkeit, Kaltstart bei neuen Tabellen, Saisonalität und Feiertage (Kalender nutzen), LLM-Hypothesen zur Ursache, die plausibel klingen, aber falsch sind, und die Kosten für das Scannen großer Tabellen. Bevorzugen Sie metadatenbasierte und stichprobenartige Prüfungen.

Gemeinsame Bausteine & Kombinationen

• Katalog und Lineage: DATA-007 liefert Verantwortliche und Lineage; Qualitätswerte fließen in den Katalog zurück.
• Bereinigung und MDM: DATA-003 behebt, was die Überwachung findet; DATA-022 wendet Prüfungen beim Onboarding von Partnerdaten an.
• Konsumenten: DATA-001 und DATA-002 gewinnen Vertrauen, wenn Antworten den Status von Aktualität und Qualität der Daten zeigen; ANOM-030 erkennt Anomalien bei Geschäftskennzahlen im Gegensatz zu Datenfehlern.
• Entwicklung: CODE-011 (Zusammenfassung von Protokollen) und CODE-018 / AGENT-025 (Observability für LLMs und Agenten) teilen sich Tracing- und Alarmierungsinfrastruktur.
• Gemeinsamer Stack: Zeitreihen-Referenzwerte dienen auch Prognosen der PRED-Familie.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen für die Anbindung; Abonnementpreise typischerweise nach Zahl der Tabellen oder überwachten Objekte.
• Weg B: 1-3 Monate für eine maßgeschneiderte Lösung.
• Weg C: 2-6 Wochen für dbt/GX/Elementary auf einem Data Warehouse, danach laufende Pflege der Regeln; die Rechenkosten der Scans sind der Haupttreiber.
• Kennzahlen: Anteil abgedeckter kritischer Tabellen, durch Überwachung gegenüber durch Nutzer entdeckte Störungen, mittlere Zeit bis zur Erkennung und bis zur Behebung, Anteil falsch positiver Meldungen, Einhaltung des Aktualitäts-SLA, Zahl defekter Dashboards, Datenausfallzeit.

Menschen & Veränderung

Binden Sie die Geschäftsleitung für die Priorisierung ein, die Abteilungsleitung als Prozessverantwortliche für die kritischen Berichte und die Datenverantwortlichen, die Warnungen erhalten und beheben. Die IT baut die Prüfungen und den Warnkanal; die Informationssicherheit prüft den Zugriff auf Produktionsdaten. Die Datenschutzbeauftragte bzw. der Datenschutzbeauftragte wird einbezogen, wenn Tabellen mit personenbezogenen Daten profiliert werden, da Profilierungsstichproben diese offenlegen können; ein AVV ist nötig, wenn ein Cloud-Anbieter Daten sieht.

Betriebsrat: grundsätzlich nein, da Tabellen und Pipelines überwacht werden, nicht Menschen. Nennen Warnungen oder Berichte die Beschäftigte, die einen Fehler verursacht hat, könnte der Aufbau Verhalten überwachen, und § 87 Abs. 1 Nr. 6 BetrVG greift; gestalten Sie Warnungen entlang von Datensätzen, nicht von Einzelpersonen, und informieren Sie den Betriebsrat nach § 90 Abs. 1 Nr. 3, wo sich Abläufe ändern.

KI-Kompetenz: Unterstützen Sie das Datenteam mit Schulungen zur Prüfung KI-vorgeschlagener Regeln (Art. 4 KI-Verordnung (AI Act)). Starten Sie einen Pilot mit drei geschäftskritischen Tabellen über einen Monat und zählen Sie die Störungen, die gefunden wurden, bevor Nutzer sie bemerkten. Typische Sorge: Alarmmüdigkeit. Begegnen Sie ihr, indem Sie Schwellenwerte gemeinsam mit den Verantwortlichen abstimmen und Menschen die Kontrolle über jede Regel und jede automatische Aktion behalten. Leitfäden: GUIDE-011, GUIDE-009, GUIDE-003.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko bei Überwachungswerkzeugen; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Trainieren die überwachten Daten ein Hochrisiko-KI-System, gelten die Pflichten zur Daten-Governance nach Art. 10 (Relevanz, Repräsentativität, Prüfung auf Fehler), und Qualitätsnachweise unterstützen sie.
• DSGVO: Die Profilierung liest Spaltenwerte und kann in Stichproben und Warnungen personenbezogene Daten oder Daten besonderer Kategorien offenlegen. Gegenmaßnahmen: reine Metadatenerfassung, Maskierung, Zugriffskontrolle auf Beispielzeilen, Hosting in der EU und ein Auftragsverarbeitungsvertrag. Die Richtigkeit (Art. 5 Abs. 1 Buchst. d) ist ein rechtliches Argument für die Überwachung.
• Branchenregeln: BCBS 239 (Banken), Solvency II (Versicherer), DORA-Vorgaben zur Daten-Governance der IKT, CSRD-Datenprüfung.
• Risiken: unbemerkte falsch negative Ergebnisse, die falsche Sicherheit erzeugen; übermäßiges Blockieren von Pipelines; von LLMs vorgeschlagene Korrekturen, die ungeprüft angewendet werden; Zugriff von Anbietern auf Metadaten der Produktion.
• Gegenmaßnahmen: von Verantwortlichen definierte Regeln für kritische Tabellen, Prüfung KI-vorgeschlagener Tests, Audit-Protokoll, gestufte Einführung im reinen Warnmodus.

Erste Schritte

1. Erfassen Sie die 20 Tabellen und Dashboards, die wichtige Entscheidungen tragen, und benennen Sie für jede einen Verantwortlichen.
2. Ergänzen Sie Tests für Aktualität, Volumen, Eindeutigkeit und leere Werte über dbt oder Soda Core; führen Sie sie in der CI und nach Zeitplan aus.
3. Schalten Sie die Anomalieüberwachung (Elementary oder eine Anbieter-Testversion) vier Wochen lang im reinen Warnmodus ein und justieren Sie sie.
4. Leiten Sie Warnungen mit Zuordnung zum Verantwortlichen an Chat und Ticketsystem weiter; halten Sie Ursache und Behebung jeder Störung fest.
5. Führen Sie Datenverträge für die störungsanfälligsten Schnittstellen der Datenlieferanten ein; fügen Sie einen LLM-Assistenten für Regelentwürfe zuletzt hinzu.

Quellen

1. Great Expectations documentation - https://docs.greatexpectations.io/
2. Soda documentation (Soda Core, data contracts) - https://docs.soda.io/
3. Elementary data observability for dbt - https://docs.elementary-data.com/
4. OpenLineage specification - https://openlineage.io/docs/
5. Open Data Contract Standard (Bitol) - https://bitol.io/
6. Snowflake data quality and data metric functions - https://docs.snowflake.com/en/user-guide/data-quality-intro
7. Databricks Lakehouse Monitoring - https://docs.databricks.com/aws/en/lakehouse-monitoring/
8. Regulation (EU) 2024/1689 (AI Act), Art. 10 and Art. 4 - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
9. Regulation (EU) 2016/679 (GDPR), Art. 5 - https://eur-lex.europa.eu/eli/reg/2016/679/oj
10. Dataplex automatic data quality (Google Cloud) - https://cloud.google.com/dataplex/docs/data-quality-overview