Pro Tabelle entscheiden: migrieren, historisieren oder archivieren — mit nachvollziehbarer Compliance-Begründung statt PDF-Anhang.
Kurz gesagt: Bei einem Plattformwechsel muss pro Tabelle entschieden werden, ob Daten in das neue System gehen, archiviert werden, oder rein gesetzlich historisiert werden müssen. Der Agent klassifiziert Legacy-Daten in genau diese drei Kategorien — getrieben von GoBD- und Swiss-FADP-Anforderungen sowie branchenspezifischen Rahmen wie BankG, VAG und GMP. Stack: Claude (Anthropic direkt) oder Azure OpenAI Switzerland für Daten-Residenz, JiVS als Historisierungsplattform, strukturierter Output gegen ein hinterlegtes Compliance-Regelwerk. Resultat: Hunderte Entscheidungen in Stunden statt Wochen, jede mit Begründung und Audit-Trail. Der Compliance-Officer bleibt im Loop — der Agent schlägt vor, der Mensch signiert ab.
Bei einem Plattformwechsel müssen Unternehmen pro Tabelle entscheiden, ob die Daten in das neue System gehen, archiviert werden, oder rein gesetzlich historisiert werden müssen. Manuell ist das Wochen Compliance-Arbeit. Ein Datenmodell mit ein paar hundert Tabellen — typisch für gewachsene ERP-, Banken- oder Versicherungssysteme — bedeutet ein paar hundert Einzelentscheidungen, jede mit eigener regulatorischer Begründung. Die Entscheidung ist nicht technisch, sondern compliance-getrieben: dieselbe Tabelle kann in einem Unternehmen migriert und in einem anderen historisiert werden, je nach Geschäftskontext und Aufbewahrungspflicht.
Branchenspezifisch wird es noch komplexer. Im Bankensektor greifen das BankG sowie FINMA-Rundschreiben mit eigenen Aufbewahrungsfristen, die je nach Datentyp — Kundentransaktionen, KYC-Records, interne Beleg-Daten — unterschiedlich laufen. Versicherer arbeiten mit dem VAG und branchenspezifischen Vertragsdaten-Pflichten, in der Pharma kommt GMP-Aufbewahrung für Produktions- und Chargendaten dazu. Quer dazu wirken GoBD (DE-Bezug bei deutschen Mutterhäusern), Swiss FADP und DSGVO. Pro Tabelle braucht es eine begründbare Entscheidung — und die Begründung muss audittauglich sein, ohne dass sie zwei Jahre später aus E-Mails und Excel-Anhängen rekonstruiert werden muss.
Der Agent bekommt zwei Eingaben: das Quell-Schema (welche Tabellen mit welchen Feldern und welchen Datentypen) und ein strukturiertes Aufbewahrungs-Regelwerk (GoBD, Swiss FADP, plus die für das Unternehmen relevanten Branchenrahmen). Pro Tabelle prüft er das Regelwerk gegen die Datenmerkmale — Datentyp, Personenbezug, Geschäftsrelevanz aus Sample-Daten ableitbar — und klassifiziert in eine von drei Kategorien: migrieren (Daten leben im neuen System weiter), archivieren (raus aus dem aktiven System, abrufbar in einem Archivsystem) oder historisieren (nur noch gesetzlich aufbewahrt, kein aktiver Zugriff, oft mit Lösch-Datum). Jede Entscheidung wird als Decision-Record mit Begründung, herangezogenen Regelwerk-Klauseln und Sample-Datenbezug abgelegt — strukturiert, nicht als Freitext.
Modellseitig: Claude (über Anthropic direkt) für längere Reasoning-Ketten über Regelwerk-Kombinationen; Azure OpenAI Switzerland, wenn Daten-Residenz in der Schweiz vertraglich gefordert ist. Tool-seitig greift der Agent auf JiVS-Connectoren für Quell-Schema und Sample-Daten zu, schreibt Decision-Records in ein durchsuchbares Register und produziert pro Entscheidung einen Audit-Log-Eintrag. Guardrails: structured-output-Validierung gegen das Compliance-Schema, harte Eskalation bei Regelwerk-Konflikten (z. B. wenn BankG und Swiss FADP für dieselbe Tabelle in unterschiedliche Richtungen ziehen), Cost-Caps pro Klassifikations-Lauf, und ein kuratiertes Eval-Set mit historisch entschiedenen Fällen pro Branche.
Wichtig: Der Agent entscheidet nicht final. Er klassifiziert, begründet, legt ab. Historisierungs-Entscheidungen sind regulatorisch bindend — wer hier Black-Box-Automatisierung baut, riskiert Bussen, die kein Compliance-Officer rückwirkend übernehmen will. Stattdessen verschiebt der Agent die Compliance-Arbeit nach oben: weg vom Lesen einzelner Tabellen-Definitionen, hin zum Reviewen aggregierter Decision-Batches.
Eine Schweizer Bank — Komposit, kein realer Klient — steht vor einem Plattform-Wechsel der Kernbanken-Software. Im Bestand: rund 80 Legacy-Tabellen aus dem Vorgänger-System, eine Mischung aus regulatorisch zwingend historisierbaren Daten (Kundentransaktionen mit zehnjähriger BankG-Aufbewahrungspflicht, KYC-Records, Belegdaten für die Steuerbehörde) und Daten mit Aufbewahrungs-Spielraum (interne Kalkulations-Hilfstabellen, archivierbare Reporting-Snapshots, technische Audit-Logs). Der Agent — Claude über Azure OpenAI Switzerland für Daten-Residenz, eingebunden in eine JiVS-Instanz — arbeitet das Tabellen-Inventar mit dem hinterlegten Regelwerk (BankG, FINMA-Rundschreiben, Swiss FADP) ab. Pro Tabelle entsteht ein Decision-Record: Klassifikation, herangezogene Regelwerk-Klauseln, Begründungs-Text, Lösch-Datum (falls historisiert), und ein Verweis auf die Sample-Daten, die der Agent für die Einordnung herangezogen hat. Der Compliance-Officer reviewt das Decision-Register im Batch, eskaliert die Regelwerk-Konflikte, signiert den Rest ab.
Typischer Effekt: Historisierungs-Entscheidungen für mehrere hundert Tabellen entstehen in Stunden statt Wochen — directional, nicht als veröffentlichte Benchmark. Jede Entscheidung kommt mit einer nachvollziehbaren Compliance-Begründung, die auf konkrete Regelwerk-Klauseln verweist statt auf Excel-Erfahrungswerte. Auditoren bekommen ein durchsuchbares Decision-Register, in dem pro Tabelle die Klassifikation, das Regelwerk, die Begründung und die menschliche Bestätigung als zusammenhängender Datensatz vorliegt — statt PDF-Anhängen, die ein Compliance-Officer in Wochenarbeit zusammengestellt hat. Als Nebeneffekt entsteht ein wiederverwertbares Regelwerk: dieselbe Klassifikations-Logik trägt durch spätere Plattformwechsel oder Audit-Zyklen, ohne dass jemand nochmal von vorn anfängt.
Migrieren heisst: das Datum wird aktiv ins neue System übernommen und lebt dort weiter — es ist Teil des laufenden Geschäftsprozesses. Archivieren heisst: das Datum wird aus dem aktiven System genommen und in ein Archiv-System verschoben, bleibt aber bei Bedarf abrufbar — typisch für Reporting-Snapshots oder Audit-Zugriff. Historisieren heisst: das Datum wird nur noch aus gesetzlicher Pflicht aufbewahrt, ohne Zugriff aus einem Geschäftsprozess, oft mit definiertem Lösch-Datum am Ende der Aufbewahrungsfrist. Die Entscheidung ist nicht technisch, sondern compliance-getrieben — dieselbe Kundentransaktions-Tabelle kann in einem Unternehmen migriert und in einem anderen historisiert werden, je nach Geschäftskontext und Aufbewahrungspflicht.
Standardmässig abgedeckt: GoBD (Bezug bei deutschen Mutterhäusern oder DE-Vertriebsstrukturen), Swiss FADP (revidiertes Schweizer Datenschutzgesetz), DSGVO (EU-Geltungsbereich). Branchenspezifisch: BankG und FINMA-Rundschreiben für den Schweizer Bankensektor, VAG für Versicherungen, GMP-Aufbewahrung für Pharma- und Medizintechnik-Produktionsdaten. Das Regelwerk ist als strukturiertes DSL hinterlegt — neue Rahmen lassen sich ergänzen, ohne den Agent selbst neu zu bauen. Wichtiger Hinweis: Der Agent interpretiert das Regelwerk, das ein Compliance-Officer kuratiert und freigegeben hat. Er ersetzt diesen Compliance-Officer nicht — und die finale regulatorische Verantwortung bleibt beim Kunden, nicht beim Tool-Anbieter.
Jede Agent-Entscheidung ist ein begründeter Vorschlag, keine bindende Klassifikation. Standard-Workflow: Der Compliance-Officer reviewt das Decision-Register batch-weise — typisch nach Branche, Datentyp oder Risk-Score gefiltert — und signiert ab. Bei Sonderfällen, in denen das Regelwerk widersprüchliche Anforderungen produziert (etwa BankG-Aufbewahrung versus FADP-Löschungsanspruch), eskaliert der Agent direkt an Datenschutz oder Rechtsabteilung statt selbst eine Klassifikation vorzuschlagen. Der Audit-Trail belegt für jede Tabelle: Wer hat wann was warum entschieden, welche Regelwerk-Klauseln waren herangezogen, welches Sample-Datum lag zugrunde. Das macht spätere Audits zur Lese-Übung statt zur Rekonstruktion.
Dieser Use Case sitzt in der Praktik Agentensysteme & Workflows und greift in benachbarte 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.
Z-Felder, Z-Tabellen und modifizierte Customizing-Einträge automatisiert mit Standard-Datenmodell abgleichen.
Historisierung ist eine Compliance-Entscheidung, kein Tooling-Problem. In einem unverbindlichen 30-Minuten-Discovery-Call besprechen wir zuerst, ob ein Agent für Ihre Datenstruktur überhaupt der richtige Hebel ist.
Discovery-Call anfragen