Datenqualitäts-Defekte im Zielsystem klassifizieren, schema-aware fixen, mit Confidence-Schwelle auto-applien oder zur Review eskalieren — jeder Patch mit Audit-Eintrag.
Kurz gesagt: Nach einer Datenmigration tauchen im Zielsystem Datenqualitäts-Defekte auf, die klassische ETL-Validierung nicht erkennt — Format-Drift, fehlende Pflichtfelder, referentielle Inkonsistenz, Duplikate, Encoding-Mismatch. Der Data-Quality-Remediation-Agent scannt Extrakte, klassifiziert jeden Defekt, schlägt einen schema-aware Fix vor und berechnet eine Confidence pro Vorschlag. Über einem konfigurierten Schwellwert wird der Fix automatisch angewendet, darunter landet er in einer Review-Queue für einen menschlichen Reviewer. Stack: Claude (Anthropic direkt oder Azure OpenAI Switzerland), Azure Document Intelligence für unstrukturierte Quellen, schema-aware diffing gegen das Zielmodell. Cross-industry, besonders wirksam nach SAP-, CRM- oder ERP-Cut-overs mit Tausenden Records und gemischter Defektklasse. Jeder Fix entsteht mit strukturiertem Audit-Eintrag — GoBD- und FADP-anschlussfähig.
Eine Datenmigration ist nicht erledigt, wenn die Records im Zielsystem ankommen — sie ist erledigt, wenn sie dort fachlich nutzbar sind. Genau dazwischen liegt der unsichtbare Teil der Arbeit: Datenqualitäts-Defekte, die durch ETL-Validierung unentdeckt durchlaufen, weil sie kein striktes Schema verletzen. Datumsfelder, die mal als YYYY-MM-DD und mal als DD.MM.YYYY kommen. Telefonnummern mit und ohne Ländervorwahl. Pflichtfelder, die mit Platzhaltern statt Werten gefüllt sind. Fremdschlüssel auf Records, die im Quellsystem gelöscht wurden, im Zielsystem aber referenziert bleiben. UTF-8- und Latin-1-Mischbestand, der erst beim ersten Report-Export auffällt.
Klassische ETL-Validierung greift nur dort, wo eine harte Schema-Regel verletzt wird — alles, was strukturell konform aber semantisch oder kontextuell falsch ist, fällt durch. In der Praxis heisst das: Nach jedem grösseren Cut-over folgt eine Phase manueller Datenbereinigung, in der Fachexperten Records einzeln öffnen, prüfen und korrigieren. Das ist auf Hunderten Records noch vertretbar; auf Zehntausenden ist es ein Quartalsthema. Hinzu kommt: Bei manueller Bereinigung entsteht selten ein verwertbarer Audit-Trail — wer was wann warum geändert hat, lässt sich nachträglich nicht rekonstruieren. Genau diesen Engpass adressiert ein Remediation-Agent: nicht den Datentransfer, sondern die Nachbereinigung.
Der Agent arbeitet auf Extrakten aus dem Zielsystem — strukturiert (Tabellen, JSON) oder unstrukturiert (PDF, Scans, freie Textfelder). Für unstrukturierte Quellen wird Azure Document Intelligence vorgeschaltet, damit der Agent strukturierte Repräsentationen reasonen kann. Pro Record und pro Feld klassifiziert er einen Defekt in eine Fehlerklasse (Format-Drift, fehlendes Pflichtfeld, referentielle Inkonsistenz, Encoding-Mismatch, Duplikat, Logik-Verletzung), schlägt einen schema-aware Fix vor und berechnet eine Confidence. Der schema-aware Diff zeigt explizit, welches Feld auf welchen Wert gesetzt wird und warum — nicht als Black-Box, sondern als strukturierter Patch.
Die Confidence wird gegen einen projektweit konfigurierbaren Schwellwert geprüft. Über dem Schwellwert (z.B. > 0.95) wird der Fix automatisch angewendet, darunter landet er in einer Review-Queue. Reviewer sehen den Original-Wert, den Vorschlag, die Klassifikation und die Begründung — und signieren batch-weise ab. Modellseitig wird Claude für längere Reasoning-Ketten eingesetzt; Azure OpenAI Switzerland kommt zum Zug, wenn Daten-Residenz in der Schweiz Vertragsbedingung ist. Guardrails: kuratiertes Eval-Set pro Fehlerklasse, Cost-Caps pro Run, harte Eskalation auf alles, was Pflichtfelder verändert oder Fremdschlüssel umlenkt, vollständiges Rollback-Set jeder Patch-Batch.
Wichtig: Der Agent ersetzt keine semantische Datenfreigabe. Er erkennt strukturelle und konsistenzbasierte Defekte — er erkennt nicht, ob ein Wert inhaltlich für die reale Welt richtig ist. Eine Postleitzahl, die zur Stadt nicht passt, kann der Agent flaggen, wenn ein Referenzdatensatz vorhanden ist; eine schema-konforme Zahl in einem Betragsfeld, die schlicht falsch ist, fällt durch. Diese Grenze wird explizit kommuniziert, damit der Compliance-Officer und die Fachseite die Schwelle realistisch setzen.
Ein Schweizer Hersteller — Komposit, kein realer Klient — hat eine SAP-Migration abgeschlossen. Im Zielsystem liegen rund 15'000 Kundendatensätze, davon weisen schätzungsweise 3 % Datenqualitäts-Defekte auf — die 3 % sind eine Szenario-Annahme, kein gemessener Wert. Die Mischung ist typisch: rund die Hälfte sind klar fixbare Format-Drifts (Telefonnummer mal mit, mal ohne +41; PLZ mal vier-, mal fünfstellig nach unbeabsichtigter Vorzeichen-Erosion; Datum in zwei Konventionen). Die andere Hälfte ist unklar: Adressdaten mit mehreren plausiblen Schreibweisen (St. Gallen vs. Sankt Gallen vs. St-Gallen), Firmennamen mit unklarer Rechtsform-Konvention, Duplikate, die in einem Feld minimal abweichen.
Der Agent (Claude, über Azure OpenAI Switzerland für FADP-Datenresidenz, mit Azure Document Intelligence für eingescannte Lieferadressen) klassifiziert jeden Record. Bei rund 60 % der Defekte liegt die Confidence über 0.95 — Format-Drifts mit eindeutigem Quell-Pattern werden automatisch gepatched. Die restlichen 40 % landen in der Review-Queue mit offengelegtem Reasoning. Ein Dateneigner-Team aus zwei Personen arbeitet die Queue in einer Woche ab statt in einem Quartal. Jeder applied Patch — auto wie manuell — landet mit Input-Snapshot, Klassifikation, Vorschlag, Confidence und Reviewer-Signatur (falls vorhanden) im Audit-Log.
Typischer Effekt: Die Bereinigungsphase nach einem grösseren Cut-over fällt von Wochen in Richtung Tage — directional, nicht als veröffentlichte Benchmark, und stark abhängig von Defektmix und Schwellwert. Der Hebel sitzt nicht im einzelnen Fix, sondern in der Trennung zwischen klar fixbar und unklar: der Agent übernimmt den Long-Tail strukturell eindeutiger Fixes, die Fachseite konzentriert sich auf die Borderline-Fälle, die fachliche Erfahrung brauchen. Als Nebenprodukt entsteht ein vollständiger Audit-Trail pro Patch: was war der Original-Wert, welche Klassifikation, welcher Vorschlag, welche Confidence, wer hat (falls manuell) abgesignt. Dieser Trail ist GoBD- und FADP-anschlussfähig und wird nicht nachträglich rekonstruiert — er fällt mit der Bereinigung selbst an. Voraussetzung für den Effekt ist eine realistische Schwellwert-Kalibrierung; ein zu hoher Schwellwert reduziert auf nutzlose Automation, ein zu niedriger verschiebt das Problem nur in den Review-Loop.
Strukturell und konsistenzbasiert breit: Format-Drift (Datum-, Telefonnummer-, Postcode-Schreibweisen), fehlende Pflichtfelder mit deduzierbarem Default, referentielle Inkonsistenz (Fremdschlüssel auf nicht-existente Records), Encoding-Probleme (UTF-8/Latin-1-Mix), duplizierte Records mit leicht abweichenden Schreibweisen, Logik-Verletzungen (negative Mengen, Zukunftsdaten als historische Werte). Was er nicht erkennt: semantisch falsche Werte, die schema-konform aber inhaltlich falsch sind — eine reale Adresse mit falscher Postleitzahl wird nur dann geflaggt, wenn ein Referenzdatensatz vorliegt; ein schlicht falscher Betrag in einem Betragsfeld fällt durch. Diese Grenze wird explizit kommuniziert, damit der Schwellwert realistisch gesetzt wird.
Confidence wird pro Fehlerklasse und pro Datensatz berechnet, basierend auf strukturellen Signalen: eine klare Format-Verletzung mit eindeutigem Quell-Pattern → high; ein Vorschlag, der mehrere plausible Lesarten hat → low. Der Schwellwert ist pro Projekt konfigurierbar — wir empfehlen, mit einer hohen Schwelle zu starten (z.B. > 0.95) und sie auf Basis der ersten Review-Runde anzupassen. Initial-Kalibrierung läuft über ein Sample-Set: Sie reviewen die ersten rund 200 Vorschläge manuell, der Agent lernt die Akzeptanzgrenzen Ihres Datenkontexts. Die Kalibrierung gehört zum Setup, nicht zur Black-Box — Sie sehen pro Fehlerklasse, wie der Schwellwert auf die Auto-Apply-Rate wirkt.
Ja, mit Approval-Gate. Standard-Workflow: Der Agent erzeugt einen strukturierten Fix-Patch (Diff pro Record und Feld), ein Reviewer signiert batch-weise ab, der Patch wird angewendet, ein Audit-Eintrag entsteht pro betroffenem Record. Bei sehr hohem Confidence-Niveau kann Auto-Write konfiguriert werden — wir empfehlen das aber nur für sehr enge Fehlerklassen wie reine Datums-Format-Drifts mit eindeutigem Quell-Pattern. Bei allen semantischen oder mehrdeutigen Fixes bleibt der Mensch im Loop. Jede Patch-Batch ist rollbackfähig, sodass ein irrtümlich angewendeter Auto-Write innerhalb des Audit-Trails zurückgenommen werden kann.
Dieser Use Case sitzt in der Praktik Agentensysteme & Workflows und greift in Migrations- und Audit-Use-Cases.
Praktik: Wie Agenten in Produktionsumgebungen gebaut, betrieben und auditfähig gemacht werden — Patterns, Guardrails, Plattformwahl.
Migrations-Objekte pro Backlog-Eintrag vorbereiten — Schema parsen, Z-Tabellen erkennen, Mapping vorschlagen, sauber eskalieren.
Auditfertige Diff-Reports mit Diskrepanz-Klassifikation und Sign-off-Paketen für Cut-over.
Datenqualitäts-Remediation lohnt sich, wenn das Fehlervolumen die menschliche Review-Kapazität sprengt. Bei kleinen Datenmengen ist klassische manuelle Bereinigung oft günstiger. In einem unverbindlichen 30-Minuten-Discovery-Call besprechen wir ehrlich, ob Ihr Fall ein Kandidat ist.
Discovery-Call anfragen