Kurz gesagt: Agent vergleicht Quell- und Zielsystem nach der Migration, generiert auditfertige Reports inklusive Diskrepanz-Listen und Sign-off-Pakete. Stack: Claude (Anthropic direkt) oder Azure OpenAI Switzerland, structured-diff über Records, Tabellen-Hashing für Volumen-Checks, PDF-Render für den Audit-Report. Branchen mit dem grössten Hebel: regulierte Industrien — Banking (FINMA-Rundschreiben), Versicherung (VAG), Pharma (GMP), Energie und der gesamte Enterprise-Bereich mit formaler Abnahme-Pflicht. Pro Migrationsobjekt entsteht ein Audit-Paket: Diff-Resultat, Diskrepanz-Klassifikation, Empfehlung, Sign-off-Block für den qualifizierten Auditor. Anschlussfähig an die agentische SAP-Migration und das Data-Quality-Remediation-Setup — derselbe Audit-Trail-Identifier zieht durch.

Problem

Audit-Vorbereitung kostet Wochen pro Migration

Auditoren erwarten lückenlose Nachweise pro Migrationsobjekt — manuell ist das Wochen Verifikationsarbeit pro Migration. Pro Tabelle und Objekt müssen Quell- und Ziel-Records verglichen, Mengen abgestimmt, Transformationen erklärt und Sonderfälle dokumentiert werden. In regulierten Industrien — Banken nach FINMA-Rundschreiben, Versicherungen nach VAG, Pharma unter GMP — ist die formale Abnahme nicht optional, sondern Voraussetzung für den Go-Live. Wer hier nachträglich Belege rekonstruiert, verbrennt das letzte Drittel des Projekt-Budgets in Excel-Listen.

Das Problem hinter dem Problem: Klassisches Source-vs-Target-Diff scheitert an absichtlichen Transformationen. Datums-Format-Umstellung (DDMMYYYY → ISO-8601), Code-Tabellen-Konsolidierung (alte fünfstellige Schlüssel auf neue dreistellige), Decimal-Präzision (zwei auf vier Nachkomma­stellen), Tabellen-Splits und -Joins, Zeichensatz-Umstellung — alles erwartet, aber alles wird vom naiven Diff als Diskrepanz markiert. Der Auditor erstickt in Rauschen und kann das echte Signal (echte Datenverluste, fehlerhafte Migrationsschritte) nicht mehr von der erwarteten Transformation unterscheiden. Genau hier setzt ein Audit-Agent an: er klassifiziert jeden Unterschied gegen ein vorher definiertes Transformations-Profil.

Lösungsarchitektur

Pro Objekt: diffen, klassifizieren, Audit-Paket erzeugen

Der Agent arbeitet nach dem Cut-over auf Quell-Export und Ziel-Query. Pro Migrationsobjekt liest er den Quell-Snapshot und das Ziel-Tabellenset, führt einen structured-diff auf Record-Ebene durch und ergänzt Tabellen-Hashes für Volumen-Plausibilität. Jede gefundene Diskrepanz wird gegen ein vorher definiertes Transformations-Profil klassifiziert: acceptable transform (Match nach Anwendung des Profils), data loss (Quell-Information fehlt im Ziel), error (Wert verändert ohne Profil-Grundlage), review required (Borderline-Fall, der einen Migrationsexperten braucht). Aus diesen Klassifikationen baut der Agent ein Audit-Paket pro Objekt: Executive Summary, Diskrepanz-Liste mit drill-down zu Records, Empfehlung (sign-off / review / blocker), Cross-References zu Quell- und Ziel-Snapshot.

Modellseitig wird Claude für die Klassifikations- und Reasoning-Schritte über das Transformations-Profil eingesetzt; Azure OpenAI Switzerland kommt zum Zug, wenn Daten-Residenz in der Schweiz Vertragsbedingung ist. Tool-seitig: read-only Connectoren auf Quell-Export und Ziel-System, ein Tabellen-Hash-Modul für Volumen-Stichproben, ein PDF-Renderer für den Audit-Report, ein JSON-Export für Folgeprozesse. Guardrails: kuratiertes Eval-Set pro Klassifikations-Klasse, Cost-Caps pro Audit-Run, harte Eskalation auf jedes Objekt mit data loss über Schwellwert oder error-Klassifikation, vollständige Read-only-Sicht auf beide Systeme — der Agent schreibt nichts in Quelle oder Ziel, nur in das Audit-Paket. Alle Output-Formate (PDF, JSON, HTML, CSV) teilen denselben Audit-Trail-Identifier, damit der Auditor zwischen den Sichten wechseln kann, ohne den Bezug zu verlieren.

Flussdiagramm: Source-Export und Target-Query werden pro Objekt diffed, Diskrepanzen klassifiziert (acceptable transform, data loss oder error), und ein Audit-PDF mit Cross-Referenzen für das menschliche Sign-off generiert.

Wichtig: Der Agent entscheidet nicht final über die Abnahme. Er bereitet die Audit-Spur vor und schlägt pro Objekt eine Klassifikation und Empfehlung vor. Die finale Sign-off-Unterschrift bleibt beim qualifizierten Auditor — und genau das ist in regulierten Industrien zwingend so. Der Agent macht die Vorarbeit nachprüfbar; er ersetzt nicht das Audit-Urteil.

Konkretes Beispiel

Versicherung mit 200 Migrationsobjekten

Eine Versicherung mit Aufsichtsbehörde — Komposit, kein realer Klient — die jede Migration formal abnehmen muss. 200 Migrationsobjekte, jeweils 10'000 bis 5 Millionen Records, Mischung aus strukturell ähnlichen Tabellen (1:1-Migration mit Format-Konversion) und strukturell umgebauten Bereichen (Tabellen-Splits, Code-Mappings, Konsolidierung von drei Quell-Systemen in eines). Vor dem Audit-Run definiert das Migrationsteam zusammen mit dem Compliance-Officer ein Transformations-Profil: erwartete Datums-Konversionen, Code-Mapping-Tabellen, Decimal-Präzisions-Änderungen, dokumentierte Tabellen-Umbauten.

Der Agent (Claude, über Azure OpenAI Switzerland für FADP-Datenresidenz) arbeitet das Objekt-Set in einem Audit-Run ab: pro Objekt liest er Quell- und Ziel-Records, führt structured-diff und Tabellen-Hashing aus, klassifiziert jede Diskrepanz gegen das Transformations-Profil. Typische Verteilung: rund 75 % der Objekte schliessen sauber mit Empfehlung sign-off (alle Diskrepanzen sind acceptable transform), rund 20 % landen mit Empfehlung review required in der Migrations-Queue (Borderline-Klassifikationen, die fachliche Bewertung brauchen), rund 5 % kommen als blocker zurück mit klar markierten data loss- oder error-Fällen. Der Auditor öffnet das PDF-Paket pro Objekt, prüft Drill-down zu den Records, gleicht gegen das Transformations-Profil ab und setzt den Sign-off — oder verweigert ihn mit konkreter Begründung.

Outcome-Pattern

Audit-Pakete in Tagen statt Wochen

Typischer Effekt: Audit-Pakete in Tagen statt Wochen; klare Abnahme-Empfehlung pro Objekt — directional, nicht als veröffentlichte Benchmark. Der Hebel sitzt nicht in der reinen Diff-Geschwindigkeit, sondern in der Trennung von Signal und Rauschen: der Auditor sieht strukturiertes PDF mit drill-down zu Records statt Excel-Berge mit zehntausenden naiv-markierten Pseudo-Diskrepanzen. Das beschleunigt den Audit-Lauf selbst und entlastet das Migrationsteam, das vorher Wochen damit verbracht hat, dem Auditor erwartete Transformationen einzeln zu erklären. Als Nebenprodukt entsteht ein vollständiger Audit-Trail pro Objekt mit gemeinsamem Identifier über alle Formate (PDF, JSON, HTML, CSV) — der Trail ist GoBD- und FADP-anschlussfähig und ist nicht nachträglich rekonstruiert, sondern fällt mit dem Audit-Run selbst an. Voraussetzung für den Effekt: ein vorher definiertes, vom Compliance-Officer mitgetragenes Transformations-Profil. Ohne diese Vorarbeit fällt der Agent auf naiven Diff zurück und produziert dasselbe Rauschen wie ein klassisches Reconciliation-Tool.

FAQ

Häufige Fragen

Welche Output-Formate werden erzeugt?

PDF (Audit-Report mit Executive Summary und drill-down zu Diskrepanz-Listen), strukturiertes JSON (für Folgeprozesse und Integration in interne Compliance-Tools), durchsuchbares HTML-Register pro Migrationsobjekt, CSV-Excerpts pro Objekt für direkte Inspektion in Excel oder vergleichbaren Werkzeugen. Format-Auswahl ist pro Audit-Standard konfigurierbar — manche Aufsichtsbehörden erwarten PDF mit Unterschrifts-Block, andere bevorzugen maschinenlesbares JSON für eigene Folgesysteme. Wichtig: alle Formate teilen denselben Audit-Trail-Identifier — der Auditor kann zwischen Sichten wechseln, ohne den Bezug zu verlieren, und Drittsysteme können auf dieselbe ID joinen.

Wie werden akzeptable Transformationen von Fehlern unterschieden?

Vor dem Diff-Run wird ein Transformations-Profil definiert: erwartete Format-Änderungen (Datumsformat, Decimal-Präzision, Zeichensatz), Code-Mappings (alte Schlüssel → neue Schlüssel), strukturelle Umbauten (Tabellen-Splits, -Joins, Konsolidierungen mehrerer Quell-Systeme). Der Agent klassifiziert jeden Unterschied gegen dieses Profil: acceptable transform (Match nach Anwendung des Transformations-Profils), data loss (Quell-Information fehlt im Ziel), error (Wert verändert ohne Profil-Grundlage). Borderline-Fälle, in denen der Agent sich nicht klar festlegen kann, landen als review required beim Migrationsexperten. Pro Objekt entsteht ein Audit-Eintrag mit der Klassifikation und dem Profil-Ausschnitt, der die Klassifikation begründet.

Welche Compliance-Frameworks werden adressiert?

GoBD (DE), Swiss FADP (CH), DSGVO (EU), FINMA-Rundschreiben (CH Banking), VAG (CH Insurance), GMP (Pharma), SOX (EU-listed beziehungsweise US-relevant). Der Agent erzeugt die Spur, der Compliance-Officer bewertet sie gegen das jeweils gültige Framework. Die strukturellen Anforderungen — nachvollziehbare Klassifikation, vollständiger Input-Snapshot, dokumentierte Entscheidungsspur, getrennte Verantwortung zwischen Vorbereitung und finalem Sign-off — sind über die Frameworks hinweg ähnlich; die spezifischen Detailanforderungen unterscheiden sich. Hinweis: Die finale Audit-Freigabe ist immer Sache des qualifizierten Auditors — der Agent macht die Vorarbeit nachprüfbar, ersetzt aber nicht das Audit-Urteil.

Verwandte Anwendungen

Praktik und benachbarte Use Cases

Dieser Use Case sitzt in der Praktik Agentensysteme & Workflows und ist der natürliche Abschluss-Schritt nach SAP-Migration, Historisierung und Data-Quality-Remediation.

Lohnt sich ein agentisches Audit-Setup für Sie?

Audit-Vorbereitung agentisch zu beschleunigen lohnt sich, wenn Audits regelmässig kommen oder die Migration zwingend formal abgenommen werden muss. Bei einmaligen, kleinen Migrationen reicht klassische Manual-Verifikation. In einem unverbindlichen 30-Minuten-Discovery-Call besprechen wir ehrlich, ob Ihr Audit-Profil ein Kandidat ist.

Discovery-Call anfragen