Data Quality Agent: KI-gestützte Datenqualität in Fabric

Constantin Budin – Pexon Consulting | 11 Min. Lesezeit | 14.04.2026

TL;DR

Ein Data Quality Agent ist ein KI-System, das Datenqualität in Microsoft Fabric oder Databricks automatisch prüft, ETL-Fehler diagnostiziert und SQL-Queries optimiert — rund um die Uhr, ohne manuelles Monitoring. Pexon Consulting baut diese Agents mit Claude als Managed Agent und Custom Tools gegen das Fabric Lakehouse. Ergebnis bei einem Energieversorger: 87 % weniger manuelle Datenbereinigung, Setup in 6 Wochen.

12,9 Millionen Dollar pro Jahr — und niemand misst es

Gartner beziffert die durchschnittlichen Kosten schlechter Datenqualität auf 12,9 Millionen USD pro Unternehmen pro Jahr. Das allein wäre schon alarmierend. Aber der eigentliche Skandal: 60 % der Unternehmen messen diesen Verlust nicht einmal.

In unseren Projekten sehen wir das Muster immer wieder. Ein Pharmaunternehmen hat 18 ETL-Pipelines in Microsoft Fabric, die täglich Produktionsdaten, Qualitätsprüfungen und Lieferkettendaten konsolidieren. Wenn eine Pipeline nachts um 3 Uhr fehlschlägt, merkt es erst der Schichtleiter um 7 Uhr — wenn die Dashboards leer sind. Dann beginnt die manuelle Fehlersuche: Schemadrift? NULL-Werte in einer Pflichtkolonne? Timeout bei einer Quelle? Das kostet jedes Mal 2–4 Stunden eines Data Engineers.

Ein Data Quality Agent ändert das fundamental. Er überwacht die Pipelines nicht nur — er versteht sie.

Was ein Data Quality Agent konkret tut

Kein abstraktes Konzept. Ein Data Quality Agent ist ein KI-System mit drei spezifischen Fähigkeiten:

Daten-Profiling in Echtzeit. Der Agent scannt Tabellen im Fabric Lakehouse auf NULL-Werte, Duplikate, Ausreißer und Schemadrift. Nicht nach einem festen Regelwerk wie Purview, sondern kontextbasiert: Er erkennt, dass eine Spalte lieferdatum plötzlich 40 % NULLs hat — obwohl der historische Durchschnitt bei 2 % liegt.

ETL-Pipeline-Diagnose. Wenn eine Pipeline fehlschlägt, analysiert der Agent die Spark-Logs, identifiziert die Ursache und schlägt einen Fix vor. In vielen Fällen kann er den Fix direkt deployen — über eine CI/CD-Integration.

SQL-Optimierung. Der Agent erkennt langsame Queries im Lakehouse, schlägt Index-Strategien oder Query-Rewrites vor. Bei einem Fertigungsunternehmen hat das die durchschnittliche Query-Laufzeit von 45 auf 8 Sekunden gedrückt.

Die Architektur: Claude als Data Engineer

Wir setzen auf Claude Managed Agents als Orchestrierungsschicht. Der Agent bekommt drei Custom Tools, die gegen Ihre Fabric-Umgebung arbeiten:

# Tool 1: query_fabric — SQL gegen Fabric Lakehouse
# Läuft im Azure-Tenant des Kunden, nicht bei Anthropic
@tool
def query_fabric(sql: str, warehouse: str = "default") -> dict:
    """Führt Read-Only SQL gegen das Fabric Lakehouse aus.
    Ergebnis: max 1000 Zeilen, Spaltennamen + Typen."""
    conn = fabric_connection(warehouse)  # Azure DE Region
    result = conn.execute(sql)
    return {
        "columns": result.columns,
        "rows": result.rows[:1000],
        "row_count": result.total_rows
    }

# Tool 2: profile_daten — Data Profiling lokal
@tool
def profile_daten(table: str, columns: list = None) -> dict:
    """Profilt eine Tabelle: Nulls, Duplikate, Verteilung,
    Schemadrift vs. letztem Scan. Läuft ON-PREM."""
    # Daten-Sample wird anonymisiert bevor es an Claude geht
    sample = get_anonymized_sample(table, n=500)
    return {
        "null_rates": calculate_null_rates(sample, columns),
        "duplicates": find_duplicates(sample),
        "schema_changes": detect_schema_drift(table),
        "distributions": column_distributions(sample)
    }

# Tool 3: fix_pipeline — Spark/SQL Fix vorschlagen + deployen
@tool
def fix_pipeline(pipeline_id: str, fix_type: str, fix_code: str) -> dict:
    """Erstellt einen Fix-Branch, committet den Fix,
    triggert CI/CD Pipeline. Braucht Review-Approval."""
    branch = create_fix_branch(pipeline_id)
    commit_fix(branch, fix_code)
    pr = create_pull_request(branch, auto_merge=False)
    return {"pr_url": pr.url, "status": "awaiting_review"}

Der entscheidende Punkt: Daten-Samples werden anonymisiert, bevor sie an Claude gehen. Der Agent sieht Spaltenstrukturen, Verteilungen und Anomalien — aber keine Echtdaten. Personalnummern, Kundennamen, Finanzdaten bleiben in Ihrem Azure-Tenant.

Das ist der Unterschied zu den meisten „AI Data Quality“-Tools am Markt, die Ihre Daten in die Cloud des Anbieters schicken.

Was Purview kann — und wo der Agent übernimmt

Microsoft Purview hat seit 2025 solide Data-Quality-Features: No-Code-Regeln, AI-generierte Qualitätsvorschläge, Inkrementelle Scans seit Februar 2026. Für regelbasierte Prüfungen — „Spalte X darf nicht NULL sein“ — reicht Purview völlig aus.

Aber Purview stößt an Grenzen, sobald es um Kontext geht.

Ein Beispiel: Eine ETL-Pipeline lädt Sensorwerte aus einer Produktionsanlage. Die Werte liegen im Bereich 20–80°C. Plötzlich tauchen Werte von 0°C auf. Purview markiert das nicht als Fehler — die Spalte ist schließlich vom Typ float, der Wert ist technisch gültig. Ein Data Quality Agent erkennt die Anomalie, korreliert sie mit dem Maschinenstatus (Anlage war abgeschaltet, Sensor liefert Defaultwert) und schlägt vor, diese Zeilen in der Pipeline zu filtern.

Unsere Empfehlung: Purview als Basis-Layer für regelbasierte Checks. Den Data Quality Agent als intelligente Schicht darüber, die Muster erkennt, die kein Mensch in Regeln codieren würde.

Praxis: Was der Agent in der ersten Woche findet

Wir haben den Data Quality Agent bei einem Energieversorger in dessen Microsoft-Fabric-Umgebung deployt. ESG-Reporting-Daten aus 12 Quellen, 43 Tabellen, ~15 Millionen Zeilen.

In der ersten Woche hat der Agent identifiziert:

• 2.340 Datensätze mit inkonsistenten Einheiten — kWh und MWh wurden in derselben Spalte gemischt. Die ESG-Reports hatten dadurch um Faktor 1.000 abweichende Werte. Das hatte vorher niemand bemerkt, weil die Aggregation die Ausreißer geglättet hat.

• Ein Schemadrift in der Lieferanten-Pipeline — ein externes System hatte ein Datumsfeld von DD.MM.YYYY auf ISO-8601 umgestellt. Die Pipeline lief weiter, aber 30 % der Datumswerte waren falsch geparst.

• 4 SQL-Queries mit Full-Table-Scans — der Agent hat Predicate-Pushdown-Optimierungen vorgeschlagen, die die tägliche Ladezeit von 2,5 Stunden auf 40 Minuten reduziert haben.

Die manuelle Datenbereinigung sank um 87 %. Nicht weil es weniger Fehler gab, sondern weil der Agent sie fand und fixte, bevor sie in die Reports flossen.

Was das Setup kostet — und ab wann es sich rechnet

Transparent: Ein Data Quality Agent ist kein SaaS-Tool für 99 EUR/Monat.

Das Setup umfasst die Agent-Architektur (Claude Integration, Custom Tools, Fabric-Anbindung), das Daten-Anonymisierungsmodul, CI/CD-Integration für automatische Fixes, und ein Monitoring-Dashboard für die Fachabteilung.

Setup-Kosten: 25.000–50.000 EUR, abhängig von der Anzahl der Pipelines und Datenquellen. Für ein Fabric-Umfeld mit 10–20 Pipelines liegen wir bei etwa 35.000 EUR.

Laufende Kosten: Abhängig vom Volumen — Claude-API-Calls, Fabric-Compute für Profiling-Jobs, und Support. Rechnen Sie mit 1.500–3.000 EUR/Monat. Das klingt nicht wenig, aber vergleichen Sie es mit den Kosten eines Data Engineers, der 20 Stunden pro Woche mit Datenbereinigung verbringt: Bei 80 EUR/Stunde Vollkosten sind das 6.400 EUR/Monat.

Der ROI ist da, sobald der Agent einem einzigen Data Engineer 15+ Stunden pro Woche spart. In unseren Projekten erreichen wir das nach 4–6 Wochen. Ein Pharma-Kunde hat den Agent für seine Chargenrückverfolgung eingesetzt — dort war die Einsparung noch höher, weil fehlerhafte Chargendaten nicht nur teuer sind, sondern regulatorische Konsequenzen haben. Ähnliche Projekte beschreiben wir in unseren Case Studies.

Warum nicht einfach Fabric IQ oder Databricks AI nutzen?

Berechtigte Frage. Fabric IQ und Databricks Agent Bricks bieten eingebaute KI-Funktionen für Datenqualität. Wir nutzen sie auch — als Bausteine.

Aber: Fabric IQ ist an Fabric gebunden. Wenn Sie Daten aus SAP, einem On-Premise-SQL-Server und einem Drittanbieter-API konsolidieren, kann Fabric IQ nur den Fabric-Teil sehen. Ein Custom Agent sieht die gesamte Pipeline.

Databricks Agent Bricks ist leistungsstark, aber locked-in auf Databricks. Wenn Sie Microsoft Fabric und Databricks parallel betreiben — was bei 40 % unserer Kunden der Fall ist — brauchen Sie einen Agent, der beides orchestrieren kann.

Und der entscheidende Punkt: Ein Custom Agent mit Claude bekommt durch die Tool-Architektur Zugang zu jedem System, das eine API hat. Fabric Lakehouse, Databricks Unity Catalog, SAP HANA, REST-APIs — alles über denselben Agent. Die nativen Tools der Plattformen können das nicht.

Häufig gestellte Fragen

Was kostet ein Data Quality Agent für Microsoft Fabric?

Setup: 25.000–50.000 EUR je nach Komplexität (Anzahl Pipelines, Datenquellen, CI/CD-Integration). Laufend: 1.500–3.000 EUR/Monat für API-Calls, Compute und Support. Der Break-even liegt bei 15+ gesparten Data-Engineering-Stunden pro Woche — in unseren Projekten nach 4–6 Wochen erreicht.

Sind meine Daten sicher, wenn ein KI-Agent auf Fabric zugreift?

Ja, mit der richtigen Architektur. Der Agent sieht nur anonymisierte Daten-Samples — keine Echtdaten. Die Custom Tools laufen in Ihrem Azure-Tenant (Region Germany West Central). Der Claude-Agent bekommt Metadaten, Verteilungen und Anomalie-Reports, aber keine personenbezogenen oder geschäftskritischen Rohdaten.

Data Quality Agent vs. Microsoft Purview — was brauche ich?

Beides, aber für unterschiedliche Aufgaben. Purview ist stark bei regelbasierten Checks (Nulls, Formatierung, Referenzintegrität). Der Data Quality Agent erkennt kontextbasierte Anomalien, diagnostiziert Pipeline-Fehler und optimiert SQL. Purview als Fundament, der Agent als intelligente Schicht darüber — das ist das Setup, das wir empfehlen.

Kann der Agent auch Databricks-Pipelines überwachen, nicht nur Fabric?

Ja. Die Tool-Architektur ist plattformunabhängig. Wir haben Kunden, die Fabric und Databricks parallel betreiben. Der Agent verbindet sich über Custom Tools mit beiden Systemen — Microsoft Fabric über die REST API, Databricks über Unity Catalog. Die Agent-Logik bleibt identisch.

Wie lange dauert die Implementierung?

6–8 Wochen von Kick-off bis produktivem Betrieb. Woche 1–2: Analyse der bestehenden Pipelines und Datenquellen. Woche 3–4: Agent-Entwicklung und Tool-Integration. Woche 5–6: Testing mit echten Daten (anonymisiert). Woche 7–8: Rollout, Monitoring-Dashboard, Übergabe an Ihr Team. Für ein Assessment Ihrer Datenplattform starten wir mit einem kostenlosen Erstgespräch.

Nächster Schritt

Wenn Ihre Data Engineers mehr als 15 Stunden pro Woche mit Datenbereinigung und Pipeline-Debugging verbringen: Ein Data Quality Agent kann das übernehmen. Wir bauen den Agent für Ihre Fabric- oder Databricks-Umgebung — mit anonymisierten Daten, in Ihrem Azure-Tenant, produktionsreif in 6 Wochen.

Verwandte Themen